Subject: mini BOF on mail standard maintenance
From: Tony Hansen <[email-masked]>
To: [email-masked], ietf-822 mailing list <[email-masked]>, [email-masked], IMAP Extensions WG <[email-masked]>
Date: Tue, 29 Jul 2008 04:16:48 -0400
List-Id: <ietf-smtp.imc.org>

The mini BOF mentioned at yesterday's applications area meeting on mail 
standard maintenance will be held today at 1pm in the Gallan Suite:

	http://tools.ietf.org/agenda/72/venue/?room=gallan-suite

Tony Hansen
[email-masked]

Date: Tue, 22 Jul 2008 18:12:00 -0400
From: John C Klensin <[email-masked]>
To: Frank Ellermann <[email-masked]>, [email-masked]
Subject: Re: Approved (was: Unsticking rfc2821bis)
Sender: [email-masked]

--On Tuesday, 22 July, 2008 23:05 +0200 Frank Ellermann
<[email-masked]> wrote:

> 
> https://datatracker.ietf.org/idtracker/draft-klensin-rfc2821bi
> s/comment/84439/?
> 
> https://datatracker.ietf.org/idtracker/ballot/2471/
> 
> That was it.  I don't recall interminable 2821bis
> discussions on the *rfc822* list, but 2821bis was
> certainly discussed on various lists.

It looks like the 2822upd announcement and the 2821bis one got
tangled.  Lisa was clearly the responsible AD for 2821bis, not
Chris, the mailing list is wrong, and, in a perfect world, a few
other little details ought to be tuned.  But I'm happy to just
have it over.

    john

Date: Tue, 22 Jul 2008 17:39:42 -0400
From: John C Klensin <[email-masked]>
To: [email-masked]
Subject: FWD: ID Tracker State Update Notice: draft-klensin-rfc2821bis
Sender: [email-masked]

Hi.

To give others a chance to celebrate even before getting to
Dublin, the message below just popped into my mailbox.

My understanding is that this approval is with the changes
proposed  in the note I circulated to this list last Thursday
and without any additional IESG notes.   

I will consult with the RFC Editor and Lisa next week as to
whether it is worth posting -12 with those changes included or
whether the next document you see will be the published RFC
form.     If anyone has any strong opinions on that subject,
please let me know (probably offlist).

Thanks to everyone, especially Tony and Lisa, for moving this
through the long ordeal and to the IESG for getting the document
unstuck and accepting what I believe is a completely reasonable
solution to the perceived textual problems.

    john

---------- Forwarded Message ----------
Date: Tuesday, 22 July, 2008 11:13 -0700
From: The IESG <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Subject: ID Tracker State Update Notice: draft-klensin-rfc2821bis

'State Changes to Approved-announcement to be sent from IESG
Evaluation::AD Followup by Lisa Dusseault' ID Tracker URL:
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_
id&dTag=13354&rfc_flag=0

---------- End Forwarded Message ----------

To: [email-masked]
From:  "Frank Ellermann" <[email-masked]>
Subject:  Approved (was: Unsticking rfc2821bis)
Date:  Tue, 22 Jul 2008 23:05:53 +0200
Organization:  <http://purl.net/xyzzy>
Lines: 10
Reply-To:  "Frank Ellermann" <[email-masked]>
Sender: [email-masked]

https://datatracker.ietf.org/idtracker/draft-klensin-rfc2821bis/comment/8=
4439/?

https://datatracker.ietf.org/idtracker/ballot/2471/

That was it.  I don't recall interminable 2821bis
discussions on the *rfc822* list, but 2821bis was
certainly discussed on various lists.

 Frank

To: [email-masked]
From:  "Frank Ellermann" <[email-masked]>
Subject:  Re: Unsticking rfc2821bis
Date:  Sun, 20 Jul 2008 10:02:27 +0200
Organization:  <http://purl.net/xyzzy>
Lines: 70
Reply-To:  "Frank Ellermann" <[email-masked]>
Sender: [email-masked]

Ned wrote:

> In particular, I see very little evidence that all these
> rules are helping us get things "right" in the only sense
> that matters: Producing clear technical specifications
> for the protocols people need.

For some RFCs I care about a few written or unwritten rules=20
helped to get it "right":  It is just not allowed to ignore
IPv6, I18N, security, or IANA.

IMHO 2821bis is shorter and clearer since John replaced the
verbatim copies of 2119 definitions by a simple reference,
and his proposal to put that reference above the first use
of these key words would again improve 2821bis.

When somebody proposed to add new key words in a 2119bis to
indicate a SHOULD expected to become a MUST later I thought
"omigod, folks *just* agreed on using 2119, why can't they
stick to it now ?"  (For a value of *just* =3D 2821bis-07 in
2008)

When 2821bis and 2822upd are STDs I hope that MIME can be
also advanced mostly "as is", updating the syntax to ABNF,
plus some on topic remarks in the security considerations.

Using the same STD 68 ABNF everywhere, as far as RFCs use
a form of syntax where that makes sense, is friendlier for
readers, especially implementors and operators.  It's not
that the STD 68 style is especially nice, but it is good
enough, and a consistent style in related RFCs is a good
thing.  E.g. the oddities of #-constructs almost guarantee
interoperability issues, and STD 68 doesn't offer this #-
"feature".  In theory folks could reinvent it <shudder />

 [about the "cut-off" ritual]
> The painful reality is that another effect of all these
> byzantine rules is that fewer and fewer people are=20
> willing and able to navigate the treacherous waters we
> have created.

Getting an RFC number for an Internet Draft is extremely
difficult for folks not familiar with those byzantine
rules.  Now if your proposal boils down to "undocument"
some "de jure" rules while their "de facto" variants are
still used it would be worse.  My approach (after MARID)
was "your only chance is to grok all their weird rules,
and then beat them in their own game".  Quite literally,
IIRC I started to expriment with the "A. Mouse" xml2rfc
example days after that WG was terminated.  At that time
Brian's marauder's map did not yet exist, unfortunately.

And I was determined that RFC 4408 will follow any comma
in any stylistic rules, I-D checklists, or BCPs, expired
or otherwise, that somebody could dig up in a Last Call.

[Various folks including me still missed the detail that
 IETF Last Calls are not required for "IETF experiments"
 in those byzantine rules.  Today I'd know where to find
 "IESG review" at the end of chapter 4.2.3 in RFC 2026.]=20

Unsurprisingly I'm now stunned when folks propose to use
say an IPv6 address not covered by RFC 3849 in examples,
or have syntax errors in their ABNF in an IETF Last Call.

Those "byzantine rules" can also protect folks, and they
might need protection from the PTB far more urgent than
the elimination of some (documented) questionable rules.

 Frank

Date: Sat, 19 Jul 2008 21:34:20 -0700
To: [email-masked]
From: SM <[email-masked]>
Subject: Re: Unsticking rfc2821bis
Sender: [email-masked]

At 16:29 19-07-2008, Ned Freed wrote:
>One thing that contribute to this accretion is narrowness of view. 
>Say a couple
>of documents come along that happen to share a problem. Why not make a rule to
>address that? Seems quite in line with our general goal of trying to produce
>the best documents possible, right? But while such "solutions" may address the
>immediate problem, we almost always fail to consider the long term effects. We

That's why rules should not be crafted on the spur of the moment to 
address specific cases.

>Even worse is the fact that quite often the rules we make fail to actually
>solve the problem they are intended to solve. This is in part because we're

That's classic software engineering.

>good at solving engineering problems but our expertise in solving human factor
>problems is, um, limited.

I can understand that argument in the case of problems discussed in a 
WG.  An organization still has to address such problems for it to 
function as a group of people coming together for a common purpose.

>A good example of this is the I-D cutoff which we're dissuing right now on the
>main IETF list. Irrespective of how important you think having a stable set of

And that was previously discussed not so long ago.  If the same 
problem keeps repeating itself, then there is something wrong.

At 18:34 19-07-2008, Frank Ellermann wrote:
>Without Brian's marauder's map the maze of rules quietly
>attempting to overrule other rules would be a hopeless
>mess.  That the "real" rules are sometimes unrelated to
>the published rules, or are only documented in expired
>drafts and obscure checklists published years ago makes
>it certainly interesting to get technical drafts right.

The published rules were never the "real rules". :-)  That's not a 
problem unless we want a rigid set of rules for technical drafts with 
the implications coming with that.  People new, and not so new, to 
the IETF ask how it works.  Some expect a rule book which can be used 
as a guide to follow to the letter to get things right.

Picture a few good people sitting together discussing about how to 
get others to join the discussion.  They know that some people are 
good at playing the rule game but those people may have motives which 
are at odds with the spirit of the group.  The good people share this 
quaint notion about openness and fairness and as such cannot exclude 
individuals wishing to join the group.  They coin a term which allows 
open participation without permitting a sub-group or a majority of 
one to weigh in unfairly in the decision making process.  The term is 
neither defined nor are there any rules for it for obvious reasons.

Regards,
-sm 

Date: Sat, 19 Jul 2008 20:22:54 -0700 (PDT)
From: [email-masked]
Subject: Re: Unsticking rfc2821bis
To: Frank Ellermann <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

> <[email-masked]> wrote:

> > a few of us, myself included, have consistently pushed
> > back against this accretion. Sadly, most of the time I,
> > and I suspect most others, have been unsuccessful.

> Without Brian's marauder's map the maze of rules quietly
> attempting to overrule other rules would be a hopeless
> mess.  That the "real" rules are sometimes unrelated to
> the published rules, or are only documented in expired
> drafts and obscure checklists published years ago makes
> it certainly interesting to get technical drafts right.

But isn't this begging the question at least a little? In particular, I see
very little evidence that all these rules are helping us get things "right" in
the only sense that matters: Producing clear technical specifications for the
protocols people need.

> > Even the IESG is now having trouble keeping all of it
> > straight.

> The decision to abandon the ION experiment was strange,
> a BCP or updating an existing BCP takes far more energy
> than creating or updating an ION.  OTOH a BCP can have
> real authority for some time, it is supposed to reflect
> a former IETF consensus and survived an IETF Last Call.

Indeed. I wasn't especially happy with IONs myself, but mostly because they
failed to capture enough "stuff".

> > the fact is people have routinely routed around what
> > they perceive as the damage this restiction causes
> > simply by posting revisions elsewhere and calling
> > people's attention to them.

> Right, if folks have an idea what the purpose of rules
> is they'll find ways to break them if necessary.  OTOH
> if somebody prepared for a meeting using the "official"
> draft and asks critical questions, and the editor then
> tries to weasel out of that with some "editor's copy"
> posted elsewhere, they might find that jabber and audio
> can't take snapshots of a middle finger...

Been there, seen that happen, didn't play out that way. The painful reality is
that another effect of all these byzantine rules is that fewer and fewer people
are willing and able to navigate the treacherous waters we have created. We're
now so desperate to get people to take on documents that nobody objects when
the rules are bent this way.

				Ned

To: [email-masked]
From:  "Frank Ellermann" <[email-masked]>
Subject:  Re: Unsticking rfc2821bis
Date:  Sun, 20 Jul 2008 03:34:23 +0200
Organization:  <http://purl.net/xyzzy>
Lines: 45
Reply-To:  "Frank Ellermann" <[email-masked]>
Sender: [email-masked]

<[email-masked]> wrote:

> a few of us, myself included, have consistently pushed
> back against this accretion. Sadly, most of the time I,
> and I suspect most others, have been unsuccessful.

Without Brian's marauder's map the maze of rules quietly
attempting to overrule other rules would be a hopeless
mess.  That the "real" rules are sometimes unrelated to
the published rules, or are only documented in expired
drafts and obscure checklists published years ago makes
it certainly interesting to get technical drafts right.

> Even the IESG is now having trouble keeping all of it
> straight.

The decision to abandon the ION experiment was strange,
a BCP or updating an existing BCP takes far more energy
than creating or updating an ION.  OTOH a BCP can have
real authority for some time, it is supposed to reflect
a former IETF consensus and survived an IETF Last Call.

> the fact is people have routinely routed around what=20
> they perceive as the damage this restiction causes
> simply by posting revisions elsewhere and calling=20
> people's attention to them.

Right, if folks have an idea what the purpose of rules
is they'll find ways to break them if necessary.  OTOH
if somebody prepared for a meeting using the "official"
draft and asks critical questions, and the editor then
tries to weasel out of that with some "editor's copy"
posted elsewhere, they might find that jabber and audio
can't take snapshots of a middle finger...

> worst of all is the inordinate fondness many people
> seem to have for all this dreck we've amassed around
> ourselves.

Maybe, but we often don't agree on what's dreck and what
makes sense.  After some time in the IPR WG I'm not more
90% sure that "worst" WCP 83 is dreck, let's say I'm at
80% now, just an example. =20

 Frank

Date: Sat, 19 Jul 2008 16:29:24 -0700 (PDT)
From: [email-masked]
Subject: Re: Unsticking rfc2821bis
To: Lisa Dusseault <[email-masked]>
Cc: SM <[email-masked]>, [email-masked]
Sender: [email-masked]

> On Jul 18, 2008, at 6:03 PM, SM wrote:

> > Hi Lisa,
> > At 16:17 18-07-2008, Lisa Dusseault wrote:
> >> Or tell me if you have these concerns, or bring specific issues up
> >> publicly.  It's too easy for guidelines to become rules, tools to
> >> create de facto rules, principles to become restrictions, loose
> >> consensus for specific cases to get applied as globally strong
> >> consensus.  Organizations like the IESG accrete rules no matter who's
> >> in the IESG.  Anybody play Fluxx?  We need the rule reset card!
> >
> > I'm surprised that you wrote that. :-)
> >
> > Most forms of governance reach the stage you described above.  Dave
> > posted a comment about whether the sorts of changes asked may be
> > symptomatic of an underlying disease.  Is the situation so bad that
> > even common sense cannot prevail?  Time will tell.
> >
> >
> > If I'm not mistaken, bodies like the IESG are not there to create
> > rules.  It's the community that makes the rules based on consensus.
> > Quoting Dave Clark:

> I meant to say that the IETF accretes rules no matter who's in the
> IESG and I completely agree that the community makes rules based on
> consensus.

Ahem. Not to put too fine a point on it, but a few of us, myself included, have
consistently pushed back against this accretion. Sadly, most of the time I, and
I suspect most others, have been unsuccessful.

One thing that contribute to this accretion is narrowness of view. Say a couple
of documents come along that happen to share a problem. Why not make a rule to
address that? Seems quite in line with our general goal of trying to produce
the best documents possible, right? But while such "solutions" may address the
immediate problem, we almost always fail to consider the long term effects. We
are now up to out proverbial asses in a hodge-podge of rules, guidelines,
checklists,  mandates, and who know what else. Even the IESG is now having
trouble keeping all of it straight. (In fact some would probably say that the
entire 2821bis fiasco is an example of the IESG's failure to keep up.)

Even worse is the fact that quite often the rules we make fail to actually
solve the problem they are intended to solve. This is in part because we're
good at solving engineering problems but our expertise in solving human factor
problems is, um, limited.

A good example of this is the I-D cutoff which we're dissuing right now on the
main IETF list. Irrespective of how important you think having a stable set of
documents prior to a meeting is, the fact is people have routinely routed
around what they perceive as the damage this restiction causes simply by
posting revisions elsewhere and calling people's attention to them.

But worst of all is the inordinate fondness many people seem to have for all
this dreck we've amassed around ourselves. I confess to a considerable degree
of pessimism that anything is going to change, so much so I rarely if ever
bring these sorts of things up any more. To be blunt, I'm going to have to see
some significant bit of forward progress somewhere before I'll be willing to
expend any effort on hashing out some reforms.

				Ned

Date: Sat, 19 Jul 2008 15:46:15 -0700
To: Lisa Dusseault <[email-masked]>
From: SM <[email-masked]>
Subject: Re: Unsticking rfc2821bis
Cc: [email-masked]
Sender: [email-masked]

Hi Lisa,
At 12:43 19-07-2008, Lisa Dusseault wrote:
>Also, I meant to encourage people with specific issues to raise those
>specific issues to me or publicly (not to start a general discussion
>of IESG authority on this list as Dave believes I meant).  Appeals and
>complaints to NomCom are not the only recourses, particularly when we
>can discuss specific issues and how best to resolve them.

I viewed your previous comments as positive.  I also read your 
encouragement as a positive step to resolve specific issues through a 
reasonable discussion.

Regards,
-sm 

Date: Sat, 19 Jul 2008 14:45:09 -0700
From: Dave Crocker <[email-masked]>
Reply-To: [email-masked]
Organization: Brandenburg InternetWorking
To: Lisa Dusseault <[email-masked]>
CC: [email-masked]
Subject: Re: Unsticking rfc2821bis
Sender: [email-masked]

Lisa Dusseault wrote:
> Also, I meant to encourage people with specific issues to raise those 
> specific issues to me or publicly (not to start a general discussion of 
> IESG authority on this list as Dave believes I meant). 

Sorry I wasn't clear.  I did understand that you were soliciting contact 
with you specifically.

My comments were intended with that in mind.

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

Cc: [email-masked]
From: Lisa Dusseault <[email-masked]>
To: SM <[email-masked]>
Subject: Re: Unsticking rfc2821bis
Date: Sat, 19 Jul 2008 12:43:36 -0700
Sender: [email-masked]

On Jul 18, 2008, at 6:03 PM, SM wrote:

> Hi Lisa,
> At 16:17 18-07-2008, Lisa Dusseault wrote:
>> Or tell me if you have these concerns, or bring specific issues up
>> publicly.  It's too easy for guidelines to become rules, tools to
>> create de facto rules, principles to become restrictions, loose
>> consensus for specific cases to get applied as globally strong
>> consensus.  Organizations like the IESG accrete rules no matter who's
>> in the IESG.  Anybody play Fluxx?  We need the rule reset card!
>
> I'm surprised that you wrote that. :-)
>
> Most forms of governance reach the stage you described above.  Dave  
> posted a comment about whether the sorts of changes asked may be  
> symptomatic of an underlying disease.  Is the situation so bad that  
> even common sense cannot prevail?  Time will tell.
>
>
> If I'm not mistaken, bodies like the IESG are not there to create  
> rules.  It's the community that makes the rules based on consensus.   
> Quoting Dave Clark:

I meant to say that the IETF accretes rules no matter who's in the  
IESG and I completely agree that the community makes rules based on  
consensus.

Also, I meant to encourage people with specific issues to raise those  
specific issues to me or publicly (not to start a general discussion  
of IESG authority on this list as Dave believes I meant).  Appeals and  
complaints to NomCom are not the only recourses, particularly when we  
can discuss specific issues and how best to resolve them.

thanks,
Lisa

Date: Fri, 18 Jul 2008 18:03:27 -0700
To: Lisa Dusseault <[email-masked]>
From: SM <[email-masked]>
Subject: Re: Unsticking rfc2821bis
Cc: [email-masked]
Sender: [email-masked]

Hi Lisa,
At 16:17 18-07-2008, Lisa Dusseault wrote:
>Or tell me if you have these concerns, or bring specific issues up
>publicly.  It's too easy for guidelines to become rules, tools to
>create de facto rules, principles to become restrictions, loose
>consensus for specific cases to get applied as globally strong
>consensus.  Organizations like the IESG accrete rules no matter who's
>in the IESG.  Anybody play Fluxx?  We need the rule reset card!

I'm surprised that you wrote that. :-)

Most forms of governance reach the stage you described above.  Dave 
posted a comment about whether the sorts of changes asked may be 
symptomatic of an underlying disease.  Is the situation so bad that 
even common sense cannot prevail?  Time will tell.

If I'm not mistaken, bodies like the IESG are not there to create 
rules.  It's the community that makes the rules based on 
consensus.  Quoting Dave Clark:

   "We reject: kings, presidents and voting"

Somewhere along the way, that seems to have been forgotten.  It's 
easier to stick to the guidelines, let the tools dictate how I-Ds 
should be written, live with the restrictions and follow the proclamations.

>The case of example domain names was, as we've now noticed, one of
>those incrementally developed rules.  The activity of lots of people
>avoiding non-2606 domains in lots of documents, a few case examples of
>harm, then the ID-Nits document, led a bunch of us to believe that the
>IETF had strong consensus not to use domain names except from 2606.
>The discussion on this list as well as the IETF general list made us
>realize there were exceptions.

Most I-Ds avoid using non-2606 domains.  It's not because the authors 
apply their common sense in those cases that it should be turned into 
a rule.  If an I-D goes through the process without having the domain 
names changed, one has to believe that there is consensus for it to 
be that way instead of a strong consensus not to use domain names 
except from 2606.

I hope that the discussion on this list does not turn into a Boston Tea Party.

Regards,
-sm 

Date: Fri, 18 Jul 2008 16:49:59 -0700
From: Dave Crocker <[email-masked]>
Reply-To: [email-masked]
Organization: Brandenburg InternetWorking
To: Lisa Dusseault <[email-masked]>
CC: [email-masked]
Subject: Re: Unsticking rfc2821bis
Sender: [email-masked]

Lisa Dusseault wrote:
> On Jul 18, 2008, at 9:38 AM, John C Klensin wrote:
>> If you, or anyone else, believe that the IESG has gone too far
>> over toward rules and assertions of their own authority
>> vis-a-vis the community, tell it to the Nomcom and hope that
>> helps.
> 
> Or tell me if you have these concerns, or bring specific issues up 
> publicly. 

Lisa,

Since this topic was hash, rehashed and turned into left-overs, through 
extensive public discussion, as well as lots of private exchanges, I'm 
not sure what you think will be added by more discussion.  The concerns 
about misapplication of power were well and completely expressed by 
multiple people in multiple ways.  It can't possibly be true that more 
discussion about it is needed.

As I see John's suggestion, it was about trying to get change in the way 
things are done, not about debating how they are done now.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

Cc: [email-masked]
From: Lisa Dusseault <[email-masked]>
To: John C Klensin <[email-masked]>
Subject: Re: Unsticking rfc2821bis
Date: Fri, 18 Jul 2008 16:17:33 -0700
Sender: [email-masked]

On Jul 18, 2008, at 9:38 AM, John C Klensin wrote:

>
> If you, or anyone else, believe that the IESG has gone too far
> over toward rules and assertions of their own authority
> vis-a-vis the community, tell it to the Nomcom and hope that
> helps.

Or tell me if you have these concerns, or bring specific issues up  
publicly.  It's too easy for guidelines to become rules, tools to  
create de facto rules, principles to become restrictions, loose  
consensus for specific cases to get applied as globally strong  
consensus.  Organizations like the IESG accrete rules no matter who's  
in the IESG.  Anybody play Fluxx?  We need the rule reset card!

The case of example domain names was, as we've now noticed, one of  
those incrementally developed rules.  The activity of lots of people  
avoiding non-2606 domains in lots of documents, a few case examples of  
harm, then the ID-Nits document, led a bunch of us to believe that the  
IETF had strong consensus not to use domain names except from 2606.   
The discussion on this list as well as the IETF general list made us  
realize there were exceptions.

Lisa

To: [email-masked]
From:  "Frank Ellermann" <[email-masked]>
Subject:  Re: Unsticking rfc2821bis
Date:  Fri, 18 Jul 2008 22:38:49 +0200
Organization:  <http://purl.net/xyzzy>
Lines: 115
Reply-To:  "Frank Ellermann" <[email-masked]>
Sender: [email-masked]

John C Klensin wrote:

> If the IESG wants to see 2119 invoked via some specific sentence
> if it is invoked at all, what difference does that make that is
> worth a fight, especially given the tendency to turn IDNits
> suggestions or warnings into firm rules (that tendency may be
> worth fighting, but the text, IMO, is not).
=20
> If you, or anyone else, believe that the IESG has gone too far
> over toward rules and assertions of their own authority
> vis-a-vis the community, tell it to the Nomcom

Hi John, I'm not very interested in fights about trivial IDnits.
AFAIK the IESG has no problem with using a full 2119 boilerlate,
or a boilerplate truncated to the actually used 2199 terminology,
i.e. what I called "Bruce's style" (with a reason, see below).

Truncation requires more attention by authors, it would be wrong
to define only SHOULD, but actually use MUST.  The "IDnits tool"
is a stupid script, it can check that you use 2119 terms without
boilerplate.  It can identify the full boilerplate.  It emits a
warning for a truncated boilerplate, because it does not check
if you use MUST without definition.  That's all, quite harmless,
no fight and no issue an IESG review.=20

Last year you feared that you "MUST" have "I18N considerations"
in a memo that's about I18N starting with the abstract and ending
with the Acknowledgements.  The author of this rule in RFC 2277
and others talked you out of this, it is *NOT* required when it
makes no sense (as in a document about EAI, pure I18N).  Rules
must make sense.  Not talking about I18N without obvious reason
would be wrong. =20

As expected your memo without "I18N considerations" was approved
without any problems.

Just for fun also the opposite case, Bruce didn't believe that
his style is nicer and better readable, as I did.  He believed=20
that his style is REQUIRED, and submitted errata when documents
used the full 2119-boilerplate without using all key words.  IMO
that was nonsense, and his editorial errata should be summarily
rejected (for this issue, not everything he reported).  So if
there was a fight, it was his fight, and I think Bruce lost it.

A different issue are "IANA considerations", they are used as a
flag for IANA to signal "nothing to do", after that they can be
removed in AUTH48.  That makes sense, of course it might be odd
for folks who authored RFCs before that convention was invented.

But it's nothing to fight about, "security considerations" are
also required, even if they end up to repeat what is already
said elsewhere in a memo.  Actually the presence indicates that
the authors tried their best to find potential security issues.

In practice that might not work as expected, but just removing
this requirement because authors could cheat is no good idea.

And for me the 2606 recommendation also makes sense.  Not for
a fight, I wouldn't appeal the publication of 2821bis for the
high crime of using foo.bar in 19 examples or similar nits.

For a fight I'd want big and evil enemies, as in the various
MARID fights.  Or the ooXML fights elsewhere, affecting the=20
IETF only remotely with the broken wannabe-pack: URI scheme.

> I believe that the IESG must have broad discretion in order
> to do its job and to keep the rest of us from getting bogged
> down in even more mechanistic rules that we have to follow
> even if it violates good technical judgment.

ACK.  I'm far from sure that "we" (as the IPR WG) managed that=20
with the new IPR rules, but I still hope "we" at least managed
to make this not worse than it is (with the current rules).

>> Address the real problem:
>> | Readers are cautioned to use examples as described in
>> | RFC 2606 in their texts to avoid the various problems
>> | with real or potential domains in examples as explained
>> | in the security considerations of this BCP.
=20
> I don't believe that there is sufficient consensus in this
> group that there are actually problems the use of bogus
> domains in actual examples or few-time tests.

That's why we don't agree about this.  I think this *is* the=20
problem with using made-up "real" addresses and domains in
examples (without consent of their owners or future owners).

You can certainly tune this in various directions, as long
as readers understand that they are not supposed to make up
similar examples only because 2821bis did it for historical
reasons.  The old examples in 2821 are anyway "burnt", they
are no part of the problem.  Taking FOO + BAR as funny, and
based on that trying something else, say SUN + JCK, could be
a problem. =20

In odd senses, "why is there an ad for SUN, but not for IBM",
or straight forward, address harvester adds JCK to its list.

> Appeals by relatively sensible people protesting apparently
> poor and badly-documented decisions and asking that the IESG
> go back, review them again, and either change their minds or
> at least document their reasoning are an important check on
> the process.

Your gateway appeal back in 2005 certainly influenced one to
three later technical appeals, as you might have guessed. :-)

> I suggest that the process is working.

If they improve the I-D Checklist and maybe tune the tracker.
They could also forget this if more pressing actual events=20
(IPv6 issues, DNS issues, IDN "fights", ...) distract them.

 Frank

Date: Fri, 18 Jul 2008 10:02:13 -0700
From: Dave Crocker <[email-masked]>
Reply-To: [email-masked]
Organization: Brandenburg InternetWorking
To: [email-masked]
Subject: Re: Unsticking rfc2821bis
Sender: [email-masked]

John C Klensin wrote:
>    But, while appreciating Dave's comment about
> underlying disease, I think there are fights that are worth
> having and fights that aren't.  

And just to make sure there is no confusion with anyone:

    I hope that the way I cast my note made it clear that my comments 
about underlying problems were explicitly separate from resolving the 
current document. The first part of my note was for resolution.

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

Date: Fri, 18 Jul 2008 12:38:47 -0400
From: John C Klensin <[email-masked]>
To: [email-masked]
Subject: Re: Unsticking rfc2821bis
Sender: [email-masked]

--On Friday, 18 July, 2008 06:55 +0200 Frank Ellermann
<[email-masked]> wrote:

> 
> John C Klensin wrote:
> 
>  [(1) + (2) +]  
>> (3) Move the 2119 boilerplate from 2.3 to 1.5.
> 
> Right, define terms before they are used.  You could switch it
> to "Bruce Lilly style" if you like that better, i.e. enumerate
> only tems used in 11:  MAY, MUST, MUST NOT, SHOULD, SHOULD NOT.
> 
> No upper case SHALL NOT RECOMMENDED OPTIONAL anywhere.  IDnits
> doesn't support Bruce's style, ignore the warning if you do it.

Frank, as you know, I'm not a big fan of 2119.  I've mostly lost
that argument.  But, while appreciating Dave's comment about
underlying disease, I think there are fights that are worth
having and fights that aren't.  Changes that don't accomplish
much of anything and that risk getting things wrong (either in
the document or in pointers to it) are, IMO, worth fighting.
Changes that can be interpreted as punishment or or petty "we
need to get the last word" retaliation may be worth fighting.
If the IESG wants to see 2119 invoked via some specific sentence
if it is invoked at all, what difference does that make that is
worth a fight, especially given the tendency to turn IDNits
suggestions or warnings into firm rules (that tendency may be
worth fighting, but the text, IMO, is not).

If you, or anyone else, believe that the IESG has gone too far
over toward rules and assertions of their own authority
vis-a-vis the community, tell it to the Nomcom and hope that
helps.  Given motivation, the Nomcom should be able to extract
the names of the people on the IESG who are exerting the worst
judgment in this area even if the rest of us cannot, and to deal
with them appropriately.   Speaking personally, I believe that
the IESG must have broad discretion in order to do its job and
to keep the rest of us from getting bogged down in even more
mechanistic rules that we have to follow even if it violates
good technical judgment.  But that discretion has to be
accompanied with continuous application of care and good
judgment.   And, again, if you don't see that happening, tell it
to the Nomcom.  If you think that the current models of what the
IESG is about and how it operates have become the cause of the
problem rather than its cure, then it is time to start looking
seriously at process reform, whether the IESG favors those
reforms or not.   If the community doesn't care enough to do
that, then we have the process we deserve.

>> | Because this document has a long history and to avoid
>> | the risk of various errors and of confusing readers and
>> | documents that point to this one, most examples and the
>> | domain names they contain are preserved from RFC 2821.
> 
> So far it's clear...
> 
>> | Readers are cautioned that these are illustrative 
>> | examples that should not actually be used in either
>> | code or configuration files.
> 
>> OK?
> 
> ...the second part misses the point.  Readers putting these
> examples in code (e.g. try to spam foo.com) or configuration
> files (e.g. try to buy foo.com) are hopeless.  Telling them
> that they should get a grip is a waste of time. 

Actually, that was precisely the point, "missing the point,
hopelessness, and wasting time" included.   And that is, IMO,
exactly what make this a reasonable proposal.

> Address the real problem:
> 
>  | Readers are cautioned to use examples as described in
>  | RFC 2606 in their texts to avoid the various problems
>  | with real or potential domains in examples as explained
>  | in the security considerations of this BCP.

I don't believe that there is sufficient consensus in this group
that there are actually problems the use of bogus domains in
actual examples or few-time tests.  I don't believe that there
is sufficient consensus that the use of non-2606 examples in
non-IETF examples is actually harmful or that the disadvantages
of doing so outweigh the possible advantages of more clarity
through careful choices of names.  As I understand it, the
sticking point for the IESG is a subject on which there is
probably at least weak consensus here, which is the code, config
files, MIBs, and similar structures.   2821bis doesn't contain
any of those things, which, I assume, is at least part of what
causes you to say "missing the point, hopelessness, and wasting
time".   From my point of view, that sentence could easily be
prefixed by "Just in case you, dear reader, are fool enough to
need to have this explained to you", but that would be rude as
well as unnecessarily provocative.

Because it is related to the meta-points above...

--On Friday, 18 July, 2008 11:19 +0200 Alessandro Vesely
<[email-masked]> wrote:

> I think that kind of danger may become actual harm in the
> absence of suitable expedients, as e.g. in the MARID case that
> Frank recently recalled
> (http://www.imc.org/ietf-smtp/mail-archive/msg05068.html).

And I think there _are_ suitable and adequate expedients.  They
may be more painful than we might like in a perfect world, but
the are there.   We don't even have evidence that they don't
cause learning if pursued carefully enough and with sufficient
determination.

In particular, I believe that another reason we get the process
we have (and may deserve) is that we have too few appeals on
substantive matters that affect standards-track documents.
Appeals by relatively sensible people protesting apparently poor
and badly-documented decisions and asking that the IESG go back,
review them again, and either change their minds or at least
document their reasoning are an important check on the process.
When the majority of the appeals that the IESG receives are from
people whom they perceive as fringe contributors or
non-contributors trying to protect, e.g., their right to be
disruptive, the tendency --and I think it is normal human nature
-- is to see any appeal as an attack on the IESG.  If we had a
larger percentage of them that addressed substantive issues and
asked for reconsideration, maybe responses would be more
constructive and less defensive.

But, in this case, while it has required some patience from both
the list and the IESG, and my personal opinion is that we should
not have needed even the first appeal (but that is true almost
by definition), I suggest that the process is working.

    john

Date: Fri, 18 Jul 2008 02:21:56 -0700
To: John C Klensin <[email-masked]>, [email-masked]
From: SM <[email-masked]>
Subject: Re: Unsticking rfc2821bis
Sender: [email-masked]

Hi John,
At 14:58 17-07-2008, John C Klensin wrote:
>Section references are to -11.  However, neither the section
>numbers nor the relevant text have changed in a _long_ time.
>Most of you will be able to deduce what is being proposed from
>the context of this note.
>
>Proposal:
>
>(1) Rename section 2.3, now called "Terminology" to "SMTP
>Terminology"

That's fine if you move the 2119 boilerplate out of that section as 
mentioned below.

>(2) Create a new section 1.5, titled "Document Conventions"
>(suggestions about better names would be welcome, but I think
>this does the job).

OK.

>(3) Move the 2119 boilerplate from 2.3 to 1.5.  That puts it
>closer to the front of the document, where it probably belongs
>anyway.  <snide> The fact that there is not yet a requirement
>about exactly where 2119 text goes may be an oversight, but is a
>discussion for the proposed new I-D Checklist, not this list.
></snide>

OK.

>(4) Create a new, second (i.e., after the 2119 text), paragraph
>of 1.5 that reads:
>
>         Because this document has a long history and to avoid
>         the risk of various errors and of confusing readers and
>         documents that point to this one, most examples and the
>         domain names they contain are preserved from RFC 2821.
>         Readers are cautioned that these are illustrative
>         examples that should not actually be used in either
>    code or configuration files.

That looks fine.

>response.  I would be happy to discuss the latter group of
>issues in Dublin with anyone interested, ideally in the presence
>of appropriate beverages.  But my instinct right now is that we

If you mellow down in the presence of appropriate beverages, I'm all 
for it. :-)

Regards,
-sm  

Date: Fri, 18 Jul 2008 11:19:48 +0200
From: Alessandro Vesely <[email-masked]>
To: [email-masked]
Subject: Who standardizes the standardization process? (was: Re: Unsticking rfc2821bis)
Sender: [email-masked]

Dave Crocker wrote:
> [...], I'll nonetheless observe that anyone who 
> actually thinks this sort of change is meaningful is suffering from some 
> sort of underlying disease that is frankly dangerous.
> 
> I'm not criticizing making the change as the expedient it is intended to 
> be.  I'm criticizing the fact that there is a situation in which it 
> serves as an expedient.

I think that kind of danger may become actual harm in the absence of 
suitable expedients, as e.g. in the MARID case that Frank recently 
recalled (http://www.imc.org/ietf-smtp/mail-archive/msg05068.html).

I'm not acknowledgeable in the intricacies of the standardization 
process, but I consider it an exercise in global democracy, and wonder 
if it is any better than traditional territorial-based representative 
politics.

To: [email-masked]
From:  "Frank Ellermann" <[email-masked]>
Subject:  Re: Unsticking rfc2821bis
Date:  Fri, 18 Jul 2008 06:55:19 +0200
Organization:  <http://purl.net/xyzzy>
Lines: 37
Reply-To:  "Frank Ellermann" <[email-masked]>
Sender: [email-masked]

John C Klensin wrote:

 [(1) + (2) +] =20
> (3) Move the 2119 boilerplate from 2.3 to 1.5.

Right, define terms before they are used.  You could switch it
to "Bruce Lilly style" if you like that better, i.e. enumerate
only tems used in 11:  MAY, MUST, MUST NOT, SHOULD, SHOULD NOT.

No upper case SHALL NOT RECOMMENDED OPTIONAL anywhere.  IDnits
doesn't support Bruce's style, ignore the warning if you do it.

>| Because this document has a long history and to avoid
>| the risk of various errors and of confusing readers and
>| documents that point to this one, most examples and the
>| domain names they contain are preserved from RFC 2821.

So far it's clear...

>| Readers are cautioned that these are illustrative=20
>| examples that should not actually be used in either
>| code or configuration files.

> OK?

...the second part misses the point.  Readers putting these
examples in code (e.g. try to spam foo.com) or configuration
files (e.g. try to buy foo.com) are hopeless.  Telling them
that they should get a grip is a waste of time.  Address the
real problem:

 | Readers are cautioned to use examples as described in
 | RFC 2606 in their texts to avoid the various problems
 | with real or potential domains in examples as explained
 | in the security considerations of this BCP.

 Frank

Date: Thu, 17 Jul 2008 16:01:30 -0700
From: Dave Crocker <[email-masked]>
Reply-To: [email-masked]
Organization: Brandenburg InternetWorking
To: [email-masked]
Subject: Re: Unsticking rfc2821bis
Sender: [email-masked]

John C Klensin wrote:
> I'd like to propose the following as a way of moving the
> document forward without an IESG Note or other (IMO) nonsense.
> Note that parts of it are probably an improvement to the
> document and its organization.  The rest is, IMO, _very_
> innocuous

+1 to the assessment and intent.

+1 to the changes

> Proposal:
> 
> (1) Rename section 2.3, now called "Terminology" to "SMTP
> Terminology"

With my above tally in mind, I'll nonetheless observe that anyone who 
actually thinks this sort of change is meaningful is suffering from some 
sort of underlying disease that is frankly dangerous.

I'm not criticizing making the change as the expedient it is intended to 
be.  I'm criticizing the fact that there is a situation in which it 
serves as an expedient.

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

Date: Thu, 17 Jul 2008 18:16:56 -0400
From: Tony Hansen <[email-masked]>
To: [email-masked]
Subject: Re: Unsticking rfc2821bis
Sender: [email-masked]

<techie hat> +1 </techie hat>
<shepherd hat> +1 </shepherd hat>

	Tony

John C Klensin wrote:
> ...
> I'd like to propose the following as a way of moving the
> document forward without an IESG Note or other (IMO) nonsense.
> ...

Date: Thu, 17 Jul 2008 17:58:30 -0400
From: John C Klensin <[email-masked]>
To: [email-masked]
Subject: Unsticking rfc2821bis
Sender: [email-masked]

Hi.

I had a lengthy, and very constructive and helpful, conversation
with Lisa yesterday.  Among other things we discussed the state
of rfc2821bis and how to get it un-stuck.

I'd like to propose the following as a way of moving the
document forward without an IESG Note or other (IMO) nonsense.
Note that parts of it are probably an improvement to the
document and its organization.  The rest is, IMO, _very_
innocuous and might actually be helpful to any complete fool who
actually reads it and might otherwise think that the examples
should be coded and placed in an inner, frequent-iteration, loop.

Of course, Lisa needs to try to "sell" this to the IESG.  I
don't believe there are any guarantees about that, but I want to
be sure I'm ready to go if the IESG is willing to sign off.

Section references are to -11.  However, neither the section
numbers nor the relevant text have changed in a _long_ time.
Most of you will be able to deduce what is being proposed from
the context of this note.

Proposal:

(1) Rename section 2.3, now called "Terminology" to "SMTP
Terminology"

(2) Create a new section 1.5, titled "Document Conventions"
(suggestions about better names would be welcome, but I think
this does the job).

(3) Move the 2119 boilerplate from 2.3 to 1.5.  That puts it
closer to the front of the document, where it probably belongs
anyway.  <snide> The fact that there is not yet a requirement
about exactly where 2119 text goes may be an oversight, but is a
discussion for the proposed new I-D Checklist, not this list.
</snide>

(4) Create a new, second (i.e., after the 2119 text), paragraph
of 1.5 that reads:

 	Because this document has a long history and to avoid
 	the risk of various errors and of confusing readers and
 	documents that point to this one, most examples and the
 	domain names they contain are preserved from RFC 2821.
 	Readers are cautioned that these are illustrative
 	examples that should not actually be used in either 
   code or configuration files.

OK?   If the IESG is willing to agree to this, silence on the
list will probably be taken as consent.

--john

p.s. This proposed agreement has to do with getting the document
published and avoiding any further delays that might be caused
by the need to fight over an IETF Note imposed as a note to the
RFC Editor or even to have further discussions about whether or
not to have that fight.  Any remaining issues are, IMO, part of
unresolved questions associated with the earlier appeal and
response.  I would be happy to discuss the latter group of
issues in Dublin with anyone interested, ideally in the presence
of appropriate beverages.  But my instinct right now is that we
should get 2821bis finished and published if we can do so
without having negative and/or distracting text inserted into
the document.

Date: Fri, 11 Jul 2008 11:53:24 -0400
From: John C Klensin <[email-masked]>
To: SM <[email-masked]>, [email-masked]
Subject: Re: rfc2821bis-11 posted -- contents and status report
Sender: [email-masked]

--On Friday, 11 July, 2008 08:43 -0700 SM <[email-masked]>
wrote:

> At 01:29 11-07-2008, John C Klensin wrote:
>> I have just queued draft-klensin-rfc2821bis-11 for posting.
> 
> I read that draft.  The following comment is not an issue.  In
> Section 2.2.1:
> 
>    "However, the Internet community now considers some
> services to be important
>     that were not anticipated when the protocol was first
> designed."
> 
> Shouldn't that be split into two sentences?
> 
>    However, the Internet community now considers some services
> to be important.
>    That were not anticipated when the protocol was first
> designed.

Your proposed second sentence is not a sentence (although it
could be fixed without too much trouble).   The original one is
correct.  

However, there is hope for your suggestion of breaking that
sentence up.  The RFC Editor has a long and successful history
of editing my long, complex-structure, sentences into multiple
shorter ones.  Usually I don't fight them on it :-)

regards,
     john

Date: Fri, 11 Jul 2008 08:43:55 -0700
To: [email-masked]
From: SM <[email-masked]>
Subject: Re: rfc2821bis-11 posted -- contents and status report
Cc: John C Klensin <[email-masked]>
Sender: [email-masked]

At 01:29 11-07-2008, John C Klensin wrote:
>I have just queued draft-klensin-rfc2821bis-11 for posting.

I read that draft.  The following comment is not an issue.  In Section 2.2.1:

   "However, the Internet community now considers some services to be important
    that were not anticipated when the protocol was first designed."

Shouldn't that be split into two sentences?

   However, the Internet community now considers some services to be important.
   That were not anticipated when the protocol was first designed.

>* Three changes have been made (again, relative to -10) in
>addition to the ones in the list in Tony's note of a few days
>ago.  I have added an explicit note asking the RFC Editor to
>remove the Change Log (Appendix G) before publication.  That was
>always the intent but the note wasn't inserted due to a
>technical glitch.   I have also added an informative reference
>to RFC 5248 (BCP 138) (the Enhanced Mail System Status Code
>registry spec).  Again, that was always the intention since this
>work motivated that specification.

That's fine with me.

Regards,
-sm 

Date: Fri, 11 Jul 2008 11:01:59 -0400
From: John C Klensin <[email-masked]>
To: Tony Hansen <[email-masked]>
cc: [email-masked]
Subject: Re: rfc2821bis-11 posted -- contents and status report
Sender: [email-masked]

--On Friday, 11 July, 2008 10:27 -0400 Tony Hansen
<[email-masked]> wrote:

> Thanks John! I'll buy you a <your-choice-of-beverage> in
> Dublin!

Enthusiastically accepted -- I need it at this stage and hope
others can join us.

>...
One additional comment...

>> * Three changes have been made (again, relative to -10) in
>> addition to the ones in the list in Tony's note of a few days
>> ago.  I have added an explicit note asking the RFC Editor to
>> remove the Change Log (Appendix G) before publication.  That
>> was always the intent but the note wasn't inserted due to a
>> technical glitch.   I have also added an informative reference
>> to RFC 5248 (BCP 138) (the Enhanced Mail System Status Code
>> registry spec).  Again, that was always the intention since
>> this work motivated that specification.

I should have explicitly thanked Frank for catching both of
those glitches.   While I've occasionally been irritated and/or
frustrated by his many detailed and nit-picking messages and
have disagreed with many of them, I appreciate his careful and
critical reading of each draft -- this document would be of
significantly lower quality without those efforts.

    john

Date: Fri, 11 Jul 2008 10:27:52 -0400
From: Tony Hansen <[email-masked]>
To: John C Klensin <[email-masked]>
CC: [email-masked]
Subject: Re: rfc2821bis-11 posted -- contents and status report
Sender: [email-masked]

Thanks John! I'll buy you a <your-choice-of-beverage> in Dublin!

	Tony Hansen
	[email-masked]

John C Klensin wrote:
> Hi.
> 
> I have just queued draft-klensin-rfc2821bis-11 for posting.
> 
> It reflects:
> 
> * The results of Tony's poll on the use of RFC 2606 names in
> comments.  I count 17 people as having responded. Neither Tony
> nor I recorded a position.  That 17 includes most of those who
> actively participated in the 2821bis development and discussions
> (again, other than Tony and myself).  Of the 17, 14 favored no
> change from the examples and domain names that appeared in the
> -10 version (option 1 in the poll) and three, including one
> person who did not participate in any of the development
> discussions, favoring changing all but the ISI/USC examples
> (option 2 in the poll).  The instruction I infer from this is
> clear; the examples are the same as they were in -10 (the second
> Last Call version and the one that the IESG reviewed).
> 
> * Three changes have been made (again, relative to -10) in
> addition to the ones in the list in Tony's note of a few days
> ago.  I have added an explicit note asking the RFC Editor to
> remove the Change Log (Appendix G) before publication.  That was
> always the intent but the note wasn't inserted due to a
> technical glitch.   I have also added an informative reference
> to RFC 5248 (BCP 138) (the Enhanced Mail System Status Code
> registry spec).  Again, that was always the intention since this
> work motivated that specification.
> 
> In addition, some of the usual editorial smoothing has been
> done, this time just to save the RFC Editor time.  In this
> version, the primary ones of those were elimination of some
> additional spaces that were artifacts of the XML and
> rationalization of text describing RFCs to use "RFC nnnn" rather
> than "RFCnnnn" (the former versions used those forms
> interchangeably, which was unattractive).
> 
> Those changes, and the ones in Tony's earlier list (all included
> in the Change Log excerpt below) reflect all last call and other
> comments agreed with the IESG.
> 
> The proposed IESG Note has not been incorporated.   As I
> understand the procedures, the IESG proposal for that note and
> its text are not final until the evaluation ballot is closed and
> a Protocol Action notice issued.
> 
> Serious showstopper comments welcome.  Otherwise, this version
> is provided for information and for the convenience of the RFC
> Editor.
> 
>     john
> 
> 
> 
> The Change Log section associated with this draft is as follows
> (this has been copied from the Change Log in the text and is
> provided, with some reformatting, for convenience):
> 
>   G.13.  Changes from version -10 to -11
> 
>    This version incorporates changes developed during IESG
>    evaluation and associated notes.
> 
>    1.  Removed "in in" in Appendix A
> 
>    2.  Added definition for dcontent
> 
>    3.  Production for Standardized-tag restored to 2821 form.
> 
>    4.  Changed 'text' in productions for Greeting and
>        Reply-line to 'textstring' and added production for the
> 	   latter. 
> 
>    5.  Added RFC 1123 to the "updates" header.
> 
>    6.  Editorial changes to make the spellings
>        (capitalization) of Forward-path, address-literal, and
> 	   QcontentSMTP internally consistent.
> 
>    7.  Added a reference to RFC 5248 (the desire to reference
>        that document from here was part of the reason for
>        producing it) and noted explicitly that this section
>        should be removed before final publication.
> 
>    8.  Editorial cleanups: removal of excess blank spaces,
>        changing "RFCnnnn" forms to "RFC nnnn" ones (previous
> 	    versions used both with no consistency).
> 
> 
> If this section were a permanent part of the text, it would make
> sense to consolidate items 1, 6, and 8 into one "editorial
> corrections" entry but, given that the section goes away before
> publication, it seemed better to reflect these separately since
> they originated from different comments or instructions.

Date: Fri, 11 Jul 2008 04:29:02 -0400
From: John C Klensin <[email-masked]>
To: [email-masked]
cc: [email-masked]
Subject: rfc2821bis-11 posted -- contents and status report
Sender: [email-masked]

Hi.

I have just queued draft-klensin-rfc2821bis-11 for posting.

It reflects:

* The results of Tony's poll on the use of RFC 2606 names in
comments.  I count 17 people as having responded. Neither Tony
nor I recorded a position.  That 17 includes most of those who
actively participated in the 2821bis development and discussions
(again, other than Tony and myself).  Of the 17, 14 favored no
change from the examples and domain names that appeared in the
-10 version (option 1 in the poll) and three, including one
person who did not participate in any of the development
discussions, favoring changing all but the ISI/USC examples
(option 2 in the poll).  The instruction I infer from this is
clear; the examples are the same as they were in -10 (the second
Last Call version and the one that the IESG reviewed).

* Three changes have been made (again, relative to -10) in
addition to the ones in the list in Tony's note of a few days
ago.  I have added an explicit note asking the RFC Editor to
remove the Change Log (Appendix G) before publication.  That was
always the intent but the note wasn't inserted due to a
technical glitch.   I have also added an informative reference
to RFC 5248 (BCP 138) (the Enhanced Mail System Status Code
registry spec).  Again, that was always the intention since this
work motivated that specification.

In addition, some of the usual editorial smoothing has been
done, this time just to save the RFC Editor time.  In this
version, the primary ones of those were elimination of some
additional spaces that were artifacts of the XML and
rationalization of text describing RFCs to use "RFC nnnn" rather
than "RFCnnnn" (the former versions used those forms
interchangeably, which was unattractive).

Those changes, and the ones in Tony's earlier list (all included
in the Change Log excerpt below) reflect all last call and other
comments agreed with the IESG.

The proposed IESG Note has not been incorporated.   As I
understand the procedures, the IESG proposal for that note and
its text are not final until the evaluation ballot is closed and
a Protocol Action notice issued.

Serious showstopper comments welcome.  Otherwise, this version
is provided for information and for the convenience of the RFC
Editor.

    john

The Change Log section associated with this draft is as follows
(this has been copied from the Change Log in the text and is
provided, with some reformatting, for convenience):

  G.13.  Changes from version -10 to -11

   This version incorporates changes developed during IESG
   evaluation and associated notes.

   1.  Removed "in in" in Appendix A

   2.  Added definition for dcontent

   3.  Production for Standardized-tag restored to 2821 form.

   4.  Changed 'text' in productions for Greeting and
       Reply-line to 'textstring' and added production for the
	   latter. 

   5.  Added RFC 1123 to the "updates" header.

   6.  Editorial changes to make the spellings
       (capitalization) of Forward-path, address-literal, and
	   QcontentSMTP internally consistent.

   7.  Added a reference to RFC 5248 (the desire to reference
       that document from here was part of the reason for
       producing it) and noted explicitly that this section
       should be removed before final publication.

   8.  Editorial cleanups: removal of excess blank spaces,
       changing "RFCnnnn" forms to "RFC nnnn" ones (previous
	    versions used both with no consistency).

If this section were a permanent part of the text, it would make
sense to consolidate items 1, 6, and 8 into one "editorial
corrections" entry but, given that the section goes away before
publication, it seemed better to reflect these separately since
they originated from different comments or instructions.

Date: Thu, 10 Jul 2008 16:53:10 -0700
To: John C Klensin <[email-masked]>
From: SM <[email-masked]>
Subject: Re: More new text for 2821bis
Cc: [email-masked]
Sender: [email-masked]

At 12:11 09-07-2008, John C Klensin wrote:
>Three things occur to me.  Neither is a solution, but I believe
>that they would be helpful:
>
>(1) Unless there is a technical issue that affects the protocol
>itself (not the form of the specification), IESG Statements and
>notes on Protocol Action notices should be favored over IESG
>modifications to, or disclaimers on, actual Standards Track RFC
>text.

People won't see the IESG Statements when they read the RFC.  Unless 
there is a serious technical issue, I don't see why an IESG 
disclaimer is needed in a Standard Track document.  But if it helps 
the IESG feel good ...  :-)

>(2) As was discussed in other contexts, any assertion of
>substantive harm needs to be backed up by clear evidence and/or
>community consensus.  If neither is possible, the third
>provision becomes even more important.

If IESG notes are to be taken seriously, then any assertion should be 
backed by clear evidence, or if that's not possible, community consensus.

>(3) Any time the IESG decides it is important to put one of
>these statements into RFC text without clear and demonstrated
>community (not just IESG consensus), all of the IESG members
>supporting that move should be required to identify themselves
>explicitly in the Protocol Action Notice or some other location
>that is visible to the community and the Nomcom.  The Nomcom is
>the communities main way or judging, and protecting itself
>against, behavior that might be considered petty or otherwise
>inappropriate.  ADs should be required to identify themselves
>and take responsibility for their decisions, not to hide behind
>"the IESG finds".

Either the IESG speaks as a collective body or else it's a group of 
individuals where we might see dissenting arguments published.  If 
it's the first (speaking in general terms), then any dissenting 
member should resign in case of serious disagreement.  If it's the 
second, then we have to rethink the notion of consensus.

For argument's sake, let's assume member X did something 
inappropriate.  As a collective it's for the group to see that it 
doesn't happen as it reflects badly on the body as a whole.  If that 
cannot be avoided, then the group has to take action against member 
X.  Some groups may only be ready to do that in extreme 
situations.  Meanwhile, member X will continue causing damage.  As 
long as everything is tightly held within the group, there is no 
transparency.  If we apply the preceding sentence to groups regulated 
by Nomcom, then there is no way for Nomcom to do the judging.

The comments about the subject line provides a view how things work 
in the IETF.  Participants can fight a decision.  That works quite 
well in Working Groups as the flame wars will attest.  As we move 
higher up the pecking chain, fighting a decision can have 
consequences.  Authors will back down from doing that unless the 
stakes are worth it.  Anywhere in the chain, we might see 
participants turning off as the situation becomes frustrating or else 
they'll settle for the lesser evil.  The latter is more common as we 
move up the chain as it's generally viewed as a lost battle beforehand.

Regards,
-sm 

To: [email-masked]
From:  "Frank Ellermann" <[email-masked]>
Subject:  Re: Auto-Submitted and Autosubmitted
Date:  Thu, 10 Jul 2008 14:53:31 +0200
Organization:  <http://purl.net/xyzzy>
Lines: 11
Reply-To:  "Frank Ellermann" <[email-masked]>
Sender: [email-masked]

Pete Resnick wrote:

> I will take it upon myself to be that "somebody".=20
> I'll submit the registration this evening.

Thanks.  For =D0=94=D0=B8=D0=BB=D1=8F=D0=BD, the initial registry in =
4021
was created at the same time as RFCs 3834 + 3864,
the new Auto-Submitted did not make it into 4021.

 Frank

Date: Wed, 09 Jul 2008 16:01:33 -0700 (PDT)
From: [email-masked]
Subject: Re: More new text for 2821bis (was: Re: Response to appeal  from John Klensin dated 13-Jun-2008)
To: Pete Resnick <[email-masked]>
Cc: John C Klensin <[email-masked]>, [email-masked]
Sender: [email-masked]

Pete, you are quite correct that:

(1) The current IESG statement is, at best, somewhat incoherent.
(2) IESG authority for doing this seems to be lacking.

I nevertheless support progressing 2821bis with the note. Why? Two reasons.

First and foremost, I want this sucker published. 2821 is a vital document and
this is an important revision.

Second - and this may seem a bit perverse - I actually welcome the opportunity
to document for posterity what I see as a hamfisted blunder by the IESG.

I have long been skeptical of the true efficacy of several aspects of our
various processes. In particular, I have often wondered to what extent we allow
the best to be the enemy of the good. I have seen many cases where the amount
of effort involved in addressing issues raised by the IESG - especially these
sorts of late surprises - is clearly grossly disprportionate to the criticality
of the issue itself. And while the present case is an extreme example, I think
as the complexity of specifications increases and the abillity of generalists
to assess them diminishes this is becoming more and more of a problem.

Getting real metrics on any of this is difficult, mostly because of our own
adaptability. Many times I've seen a specification changed solely because it
was easier to do that in order to make some silly DISCUSS comment go away than
to argue about it. And in a lot of those cases changes were done to WG
documents by private agreement between the document authors, WG chairs, and the
IESG. (This last is pretty clearly an accident waiting to happen.)

But what if the IESG were required to document their assessment of a document
in such notes? If they did after a few years I'm pretty sure we'd look back in
amazement at how often we focused on the irrelevant (and no doubt how we also
managed to miss the really relevant).

Of course this isn't going to happen. But if in this one case we have such a
note to look back on maybe, just maybe, it will knock some tiny bit of sense
into our collected damnfool heads a few years from now. 

				Ned

Date: Wed, 09 Jul 2008 17:32:28 -0700
From: Chris Newman <[email-masked]>
Subject: Re: More new text for 2821bis (was: Re: Response to appeal from John Klensin dated 13-Jun-2008)
To: John C Klensin <[email-masked]>, [email-masked]
Sender: [email-masked]

--On July 9, 2008 2:51:20 -0400 John C Klensin <[email-masked]> wrote:
> Advice or instructions welcome.

The technical matter is that we want to publish RFC 2821bis that is better 
than RFC 2821.  As the IESG Note does not change the fact that 2821bis is 
better than 2821, it is irrelevant from a technical perspective.

Now we get to the matter of human/interpersonal interactions.

There are basically two camps: 1. People who find use of non-example 
domains in RFCs technically harmful in many/most cases.  2. People who find 
non-example domains rarely or never technically harmful.

The IESG note is an excellent human resolution for both camps.  For camp 1, 
it allows 2821bis to be published while preserving the ability to defend 
their belief about technical harm in the future.  It also allows people in 
camp 1 to save face without continuing to be obstructionist.  For camp 2, 
it allows use of non-example domain names in this case _and_ it makes the 
IESG look stupid to everyone in camp 2.  Speaking as a member of the IESG 
in camp 2, I find that a satisfying outcome. ;-)

So my advice is to let this outcome go forward as is.  Other actions aren't 
going to improve anything significant on the technical front.  And frankly 
the IETF seems lousy at human process engineering so I'm not a big fan of 
spending too much time on that.

		- Chris

Date: Wed, 9 Jul 2008 19:23:55 -0500
To: [email-masked]
From: Pete Resnick <[email-masked]>
Subject: Re: Auto-Submitted and Autosubmitted
Cc: =?UTF-8?B?0JTQuNC70Y/QvSDQn9Cw0LvQsNGD0LfQvtCy?= <[email-masked]>, IETF SMTP <[email-masked]>
Sender: [email-masked]

On 7/9/08 at 3:35 PM -0700, [email-masked] wrote:

>RFC 3834 defines Auto-submitted:, including providing ABNF. There is no
>previous definition and no need for one.
>
>>At http://www.iana.org/assignments/message-headers/perm-headers.html
>>only Autosubmitted is listed.
>
>Which is apropos of almost nothing, more's the pity. Although things have
>improved in recent times, omissions in IANA registries are legion. Spurious
>entries aren't exactly unknown either. IANA is always working to try and get
>things up to date, but the problem is that too many things managed to slip
>through the cracks for too long, making this a herculian task.

For which the right answer is: Somebody submit the registration to 
IANA since there is already a standards track document with the 
definition.

Being silly enough to respond to this message, I will take it upon 
myself to be that "somebody". I'll submit the registration this 
evening.

pr
-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

Date: Wed, 09 Jul 2008 16:02:27 -0700
From: Chris Newman <[email-masked]>
Subject: Re: Response to appeal from John Klensin dated 13-Jun-2008
To: Tony Hansen <[email-masked]>, [email-masked]
Sender: [email-masked]

--On July 7, 2008 18:35:07 -0400 Tony Hansen <[email-masked]> wrote:
> Now that the appeal is done and out of the way, do people prefer
>
> 1) none of the domain names be changed?
> 2) all domain names be changed, except Jon Postel's isi.edu and usc.edu
> references
> 3) all domain names be changed
>
> I would like to get a quick consensus call for this question. Please
> respond by Thursday, July 10.

I consider it impolite to use a domain name without permission, so as a 
matter of common courtesy I prefer option 2.  Option 1 is also acceptable 
to me.  I find option 3 offensive and completely unacceptable.

		- Chris

Date: Wed, 09 Jul 2008 15:35:30 -0700 (PDT)
From: [email-masked]
Subject: Re: Auto-Submitted and Autosubmitted
To: =?UTF-8?B?0JTQuNC70Y/QvSDQn9Cw0LvQsNGD0LfQvtCy?= <[email-masked]>
Cc: IETF SMTP <[email-masked]>
Sender: [email-masked]

> Hello,

> Could somebody briefly explain me the difference between
> "Auto-Submitted" and "Autosubmitted" MIME headers?

> RFC 4021 (Registration of Mail and MIME Header Fields) talks only about
> Autosubmitted, with reference to RFC 2156 ( MIXER (Mime Internet X.400
> Enhanced Relay): Mapping between X.400 and RFC 822/MIME).

Autosubmitted: is a straight mapping of an X.400 message attribute into an RFC
822 header field. The semantics of that attribute are fairly specific to X.400
and have no well-defined meaning in Internet email. (I could go on and talk
about how well I think X.400 defines these things for its own use, but that's
not especially relevant here.)

> On the other side, RFC 3834 (Recommendations for Automatic Responses to
> Electronic Mail) "keywords for the Auto-Submitted header field", hence
> Auto-Submitted shall have been defined before RFC 3834.

Nope. RFC 3834 defines Auto-submitted:, including providing ABNF. There is no
previous definition and no need for one.

> RFC 5230 (Sieve Email Filtering: Vacation Extension) relies on
> "Auto-Submitted".

It uses it, yes. Relies on it is a bit of an overstatement, I think.

> At http://www.iana.org/assignments/message-headers/perm-headers.html
> only Autosubmitted is listed.

Which is apropos of almost nothing, more's the pity. Although things have
improved in recent times, omissions in IANA registries are legion. Spurious
entries aren't exactly unknown either. IANA is always working to try and get
things up to date, but the problem is that too many things managed to slip
through the cracks for too long, making this a herculian task.

				Ned

X-Mail-Sent-By-AEGEE.org-Account: didopalauzov
Date: Thu, 10 Jul 2008 00:03:20 +0200
From: =?UTF-8?B?0JTQuNC70Y/QvSDQn9Cw0LvQsNGD0LfQvtCy?= <[email-masked]>
To: IETF SMTP <[email-masked]>
Subject: Auto-Submitted and Autosubmitted
Sender: [email-masked]

Hello,

Could somebody briefly explain me the difference between 
"Auto-Submitted" and "Autosubmitted" MIME headers?

RFC 4021 (Registration of Mail and MIME Header Fields) talks only about 
Autosubmitted, with reference to RFC 2156 ( MIXER (Mime Internet X.400 
Enhanced Relay): Mapping between X.400 and RFC 822/MIME).

On the other side, RFC 3834 (Recommendations for Automatic Responses to 
Electronic Mail) "keywords for the Auto-Submitted header field", hence 
Auto-Submitted shall have been defined before RFC 3834. RFC 5230 (Sieve 
Email Filtering: Vacation Extension) relies on "Auto-Submitted".

At http://www.iana.org/assignments/message-headers/perm-headers.html 
only Autosubmitted is listed.

Thanks in advance for your opinion.

	Ð¡ÑŠÑ Ð·Ð´Ñ€Ð°Ð²Ðµ,
		Ð”Ð¸Ð»ÑÐ½

To: [email-masked]
From:  "Frank Ellermann" <[email-masked]>
Subject:  Re: I-D Action:draft-hathcock-minger-05.txt
Date:  Wed, 9 Jul 2008 23:10:33 +0200
Organization:  <http://purl.net/xyzzy>
Lines: 23
Reply-To:  "Frank Ellermann" <[email-masked]>
Sender: [email-masked]

> Title           : The Minger Email Address Verification Protocol
> Author(s)       : A. Hathcock, J. Merkel
> Filename        : draft-hathcock-minger-05.txt

Great.  But a fresh date oddity, expired before publication :-)

Some observations minus the few simple nits reported by IDnits:

s/are therefore often decide/therefore often decide/ (to accept)
or maybe "are therefore often forced to accept".=20

Status codes 0..5:  Intuitively I'd expect "0" to be "okay".

Digest =3D MD5( secret ":" mailbox ) could attract the attention
of security folks, how about using HMAC(x, y) instead of MD5 ?

Anonymous mode, is that MD5( ":" mailbox ) or MD5( mailbox ) ?

Security:  The secret is defined to be 1*50(VCHAR), maybe say
at least 16 VCHARs instead of 128 bits.  MD5 could handle bit
strings if you'd want this, but you want ordinary VCHAR bytes.

 Frank

Date: Wed, 09 Jul 2008 15:37:45 -0400
From: John C Klensin <[email-masked]>
To: SM <[email-masked]>, [email-masked]
Subject: Re: More new text for 2821bis (was: Re: Response to appeal   from John Klensin dated 13-Jun-2008)
Sender: [email-masked]

--On Wednesday, 09 July, 2008 12:20 -0700 SM <[email-masked]>
wrote:

> 
> At 10:54 09-07-2008, John C Klensin wrote:
>> But 3932 applies exclusively to independent submissions.  It
>> has nothing at all to do with Standards Track documents.
> 
> Yes.  That's the only document I could find that covers IESG
> notes.  Unless I missed it, there isn't anything in 2026 or
> 3710 about such notes for Standard Track documents.  Is this
> practice documented anywhere?

Not that I'm aware of.

   john

Date: Wed, 09 Jul 2008 12:20:32 -0700
To: [email-masked]
From: SM <[email-masked]>
Subject: Re: More new text for 2821bis (was: Re: Response to appeal  from John Klensin dated 13-Jun-2008)
Sender: [email-masked]

At 10:54 09-07-2008, John C Klensin wrote:
>But 3932 applies exclusively to independent submissions.  It has
>nothing at all to do with Standards Track documents.

Yes.  That's the only document I could find that covers IESG 
notes.  Unless I missed it, there isn't anything in 2026 or 3710 
about such notes for Standard Track documents.  Is this practice 
documented anywhere?

Regards,
-sm 

Date: Wed, 09 Jul 2008 15:11:34 -0400
From: John C Klensin <[email-masked]>
To: Keith Moore <[email-masked]>
cc: [email-masked]
Subject: Re: More new text for 2821bis
Sender: [email-masked]

--On Wednesday, 09 July, 2008 09:33 -0400 Keith Moore
<[email-masked]> wrote:

> 
>> But, unless it contains significant and important information,
>> this stuff clutters up documents and, when there _is_
>> consensus about the technical specification and publication,
>> can constitute the IESG saying "regardless of the community
>> consensus, we, the all-seeing and all-knowing IESG, know
>> better and are going to take advantage of our privileged
>> position to state our opinion of the document --not in a
>> dissenting RFC (which the IESG claims an absolute right to
>> publish if they feel like it), or in an IESG statement, but
>> by changing the Standards Track RFC itself.   There may be
>> situations where even that is appropriate, but the question
>> is what the limits are on this mechanism being used, largely
>> invisibly (unless, as Frank notes, the author notices on
>> AUTH48 and protests), and how far things can descend, to use
>> your words, toward "fairly petty concerns", on the IESG's own
>> authority.
> 
> well, yeah.
> 
> Though as the entire purpose of the note is, in some sense, to
> let the IESG move on and get documents published when there
> remains disagreement between the document author/editor/wg and
> IESG, a process that required agreement on those notes would
> seem to defeat their purpose. And without such notes,
> presumably more documents would be delayed.  So I am having a
> bit of trouble coming up with a process remedy that works
> better than what we have now.

Three things occur to me.  Neither is a solution, but I believe
that they would be helpful:

(1) Unless there is a technical issue that affects the protocol
itself (not the form of the specification), IESG Statements and
notes on Protocol Action notices should be favored over IESG
modifications to, or disclaimers on, actual Standards Track RFC
text.

(2) As was discussed in other contexts, any assertion of
substantive harm needs to be backed up by clear evidence and/or
community consensus.  If neither is possible, the third
provision becomes even more important.

(3) Any time the IESG decides it is important to put one of
these statements into RFC text without clear and demonstrated
community (not just IESG consensus), all of the IESG members
supporting that move should be required to identify themselves
explicitly in the Protocol Action Notice or some other location
that is visible to the community and the Nomcom.  The Nomcom is
the communities main way or judging, and protecting itself
against, behavior that might be considered petty or otherwise
inappropriate.  ADs should be required to identify themselves
and take responsibility for their decisions, not to hide behind
"the IESG finds".

   john

Date: Wed, 09 Jul 2008 14:54:56 -0400
From: John C Klensin <[email-masked]>
To: John Leslie <[email-masked]>, Pete Resnick <[email-masked]>
cc: [email-masked]
Subject: Re: More new text for 2821bis (was: Re: Response to appeal  from John Klensin dated 13-Jun-2008)
Sender: [email-masked]

John,

I agree with some of what you write and disagree with much of
it.  Probably, at least for the present, it is best that we
agree to disagree (in part because, of those who participated in
the development of 2821bis, you are so far the only person who
participated in Tony's poll for whom "change the examples" was
the first preference.

However, in the interest of transparency and disclosure...

--On Wednesday, 09 July, 2008 13:19 -0400 John Leslie
<[email-masked]> wrote:

>> So I object to this note appearing in that it does not
>> represent the truth of the matter.
> 
>    None of us need to like it. Only John Klensin needs to sign
> off on it during AUTH48.

While I realize that I have that authority and responsibility, I
don't want it.  To the extent feasible, I've tried to act as a
pure editor on this document, reflecting list consensus, and I
don't see any need to change that now.  Getting guidance on what
people prefer that I do is a large part of the reason I sent the
proposed RFC Editor note to the list.  Unless one of two things
happens, the odds of my signing off (during AUTH48 or otherwise)
on text added to the document that this group has not approved
are <insert your favorite metaphor for a low-likelihood event
here>.

Those two things are:

	(i) The groups decides that it _likes_ the note.  I
	might settle for consensus that it is just more
	boilerplate and doesn't matter, but, at the moment, I'm
	not inclined to do so.
	
	(ii) The IESG changes the note in a way that identifies
	the harm they believe could occur and clearly identifies
	that as their opinion _and_ issues a clear statement
	indicating that they will attach similar notes to any
	document that, for any reason, is permitted to progress
	with examples or text containing non-2606 domains.
	They could do the latter via the pending "Checklist"
	revision or via a separate statement.

Otherwise, to paraphrase and extend Keith's comment a bit, this
whole thing looks to me to be too much of a petty demonstration
of "we dropped the DISCUSSes on appeal, but still have the power
to poke a stick in your eye".

Lisa is aware of my general position on this, or will be the
next time she reads her mail.  I have offered to help the IESG
wordsmith a mutually-acceptable note (which I would take back to
this list) or other way to proceed.

As far as any further appeals are concerned, my interpretation
of 2026 is that the posting of a Protocol Action notice that
contains a RFC Editor note is a separate IESG act from the
DISCUSS issues and authority identified in the appeal to which
the IESG has recently responded.   I don't know whether I would
generate such an appeal or not, but do suggest to the list that
everyone would be better served by resolving the issue earlier
than after a nearly-100-page document makes its way through the
RFC Editor queue.

>    Honestly, anything posted here is pretty much orthogonal to
> the question of judging IETF consensus. Things posted to
> ietf-general are _an_ input to the judgment process. Things
> _not_ posted are also _an_ input.

I have made a personal decision to not raise this on the IETF
list, at least until there is a Protocol Action notice and some
decision (by me or someone else) about an appeal.  Right now,
I'm much more interested in getting guidance from this group
than in initiating another flame-war. Of course, nothing
prevents anyone who feels that it should be raised there sooner
from doing so.

    john

To: [email-masked]
From:  "Frank Ellermann" <[email-masked]>
Subject:  Re: More new text for 2821bis
Date:  Wed, 9 Jul 2008 20:20:37 +0200
Organization:  <http://purl.net/xyzzy>
Lines: 29
Reply-To:  "Frank Ellermann" <[email-masked]>
Sender: [email-masked]

Keith Moore wrote:

> So I am having a bit of trouble coming up with a process
> remedy that works better than what we have now.

Those DISCUSS-objections and COMMENT-discussions should=20
have a time-out.  After that one or both sides obviously
were not interested in a real discussion, or they were,
but did not find a solution, and then the DISCUSS should
turn into ABSTAIN, and the COMMENT into NO-OBJECTION.

It is odd to see a reference to an expired draft in the
updated ID-checklist.  That apparently expired, because
there are three pending DISCUSSes.  Now does the IESG see
this draft as important enough to reference it in the ID-
checklist, and is it simultaneously too controversial to
approve it ?  Any user considering to write an I-D will
look into the Checklist and find this oddity.

Like any user interested in e-mail will find the examples
in 2821bis, and might arrive at the conclusion that this
as it should be, but picking other domains could be more
interesting.  That is the danger nobody sees here; here
all are ready with 2821bis (minus one Last Call for STD),
but thousands haven't read it yet.  And they'll find any
possible absurd interpretation - as it was with (2)822
and (2)821 before.

 Frank

Date: Wed, 09 Jul 2008 13:54:52 -0400
From: John C Klensin <[email-masked]>
To: SM <[email-masked]>, [email-masked]
Subject: Re: More new text for 2821bis (was: Re: Response to appeal  from John Klensin dated 13-Jun-2008)
Sender: [email-masked]

--On Wednesday, 09 July, 2008 09:35 -0700 SM <[email-masked]>
wrote:

>...
>> I can also find no authority, in RFC 2026 or elsewhere, for
>> the IESG adding text to a Standards-track document without
>> such consultation.  In particular, while Section 6.1.2 of RFC
>> 2026 contains an extended discussion of the IESG changing
>> categories, forming WGs, etc., it appears clear that the IESG
>> is to "approve or disapprove", not to start adding text
>> reflecting its own observations, observations that may or may
>> not represent community consensus.
> 
> At the moment, I cannot find any text from RFC 2026 which
> covers the area of disagreement.    RFC 3932 (BCP 92)
> discusses procedures and has some text about IESG notes.

But 3932 applies exclusively to independent submissions.  It has
nothing at all to do with Standards Track documents.

   john

Date: Wed, 9 Jul 2008 13:19:18 -0400
From: John Leslie <[email-masked]>
To: Pete Resnick <[email-masked]>
Cc: [email-masked]
Subject: Re: More new text for 2821bis (was: Re: Response to appeal  from John Klensin dated 13-Jun-2008)
Sender: [email-masked]

Pete Resnick <[email-masked]> wrote:
> 
>>	"The IESG notes the use of several non-example domains
>>	(see RFC2606) in examples in this document.  These
>>	domains appear in the same examples in RFC2821.  RFC2821
>>	will continue to exist although its status will be
>>	marked as obsoleted by this document.  Thus, the IESG
>>	estimates that use of these particular examples in a
>>	revision to RFC2821 causes less harm than the good done
>>	by publishing this revision."
> 
> On the one hand, I am not entirely sure what this means.

   So what? Unless it somehow changes the meaning of the remainder of
the document, we can think of it as mere boilerplate.

> That's not even logically coherent.

   So what? That makes it even less likely to change the meaning of
the rest of the document.

> So I object to this appearing in the document as is.

   So what? (sorry... ;^)

   None of us need to like it. Only John Klensin needs to sign off on
it during AUTH48.

> However, the last sentence *seems* to imply that the examples 
> themselves still cause harm, which is not the consensus of the IETF, 

   It is the job of the IESG to judge IETF consensus, not ours.

   Honestly, anything posted here is pretty much orthogonal to the
question of judging IETF consensus. Things posted to ietf-general are
_an_ input to the judgment process. Things _not_ posted are also _an_
input.

   Besides, it's an _IESG_ note: it doesn't need to reflect IETF
consensus.

> and I'm not even sure it's the consensus of the IESG.

   There are some pretty clear indications that the IESG spent hours
of telechat time working this wording out. I think we need to accept
it as an IESG consensus -- however uncomfortable we think it may be
for certain IESG members.

> So I object to this note appearing in that it does not represent the
> truth of the matter.

   None of us need to like it. Only John Klensin needs to sign off on
it during AUTH48.

> My opinion: First get a clarification on what they are talking about. 

   Understand, I fully agree that John Klensin is in no way obligated
to sign off on this: the document can stay in AUTH48 until we get a
new IESG. I _will_ not criticize John K if he chooses that path.

   But, to tell truth, a "clarification" would mean nothing. The IESG
note means exactly what it says -- no more and no less.

   If John K doesn't like this language, he needs to talk with Lisa,
and see if she believes there's room for compromise. (IMHO, there
might be significant room if he changed the examples that refer to
currently registered domains.)

> If they persist, appeal again.

   More exactly, RFC 2026 Section 6.5.2 says:
] 
] Should the complainant not be satisfied with the outcome of the IESG
] review, an appeal may be lodged to the IAB. The IAB shall then review
] the situation and attempt to resolve it in a manner of its own
] choosing and report to the IETF on the outcome of its review.

   (I am not recommending this; but it is the next step in the published
process: my recommendation remains that he talk with Lisa.)

> The original appeal was, in part, about the fact that the IESG is
> insisting on changes to documents without consensus. 

   I'm sorry Pete thinks this (but I know he's not alone).

   The IESG has a long-established process for reaching _IESG_
consensus. The details change from time to time, but it is IESG
consensus they're seeking.

   The individual ADs individually try to divine IETF consensus. It
should be no surprise that they don't always agree. Nor do they all
necessarily agree with our judgment of IETF consensus. But neither
of these should be taken as evidence that they aren't _trying_ to
judge IETF consensus.

   Like any consensus process, this IESG process sometimes leads to
delays. If we don't like those delays, we always have the option of
talking to the responsible AD, who will generally have advice on
the most effective way to speed the process. Sometimes, that advice
will be, "Humor him!".

   We don't have to take the advice, of course. We can let it stew,
we can try to talk to other ADs, we can organize letter-writing
campaigns, we can even appeal. But we should, IMHO, at least _try_
to respect that advice as representing experienced judgment of
the dynamics of the IESG consensus process.

   And we should not assume, even if "Humor him" is the advice,
that any AD voting DISCUSS is expressing only a personal preference.

--
John Leslie <[email-masked]>

Date: Wed, 9 Jul 2008 17:40:03 +0100
From: Tony Finch <[email-masked]>
To: [email-masked]
cc: Tony Hansen <[email-masked]>, [email-masked]
Subject: Re: Response to appeal from John Klensin dated 13-Jun-2008
Sender: [email-masked]

On Mon, 7 Jul 2008, [email-masked] wrote:
>
> > 1) none of the domain names be changed?
> > 2) all domain names be changed, except Jon Postel's isi.edu and usc.edu
> > references
> > 3) all domain names be changed
>
> Strongly prefer (1). (2) is tolerable. (3) is unacceptable and frankly
> offensive.

+1

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
WIGHT PORTLAND PLYMOUTH NORTH BISCAY: SOUTHWEST 5 TO 7, OCCASIONALLY GALE 8 IN
PLYMOUTH AT FIRST, DECREASING 4 OR 5 LATER. MODERATE OR ROUGH. RAIN THEN
SHOWERS. MODERATE OR GOOD, OCCASIONALLY POOR.

Date: Wed, 09 Jul 2008 09:35:18 -0700
To: John C Klensin <[email-masked]>, [email-masked]
From: SM <[email-masked]>
Subject: Re: More new text for 2821bis (was: Re: Response to appeal from John Klensin dated 13-Jun-2008)
Sender: [email-masked]

Hi John,
At 23:51 08-07-2008, John C Klensin wrote:
>This is the "surprise" referred to in one of my earlier notes.
>
>Just so everyone knows, the appeal response says, in part...
>
>         "The IESG came to consensus that the use of non-example
>         domain names should not prevent publication of
>         RFC2821bis, even though the IESG finds this practice can
>         cause harm. The arguments made in public list discussion
>         of the appeal have been a factor in the IESG being able
>         to come to consensus on this point."
>
>I thought that wording was a little odd when I first read it
>but, other than noting that the IESG "finding" of harm did not
>appear to be consistent with community consensus, didn't pay a
>lot of attention to it.
>
>However, while it is apparently not final and still has not
>appeared in the tracker (see
>https://datatracker.ietf.org/idtracker/draft-klensin-rfc2821bis/),
>the apparent intent of the IESG, reflected in the ballot at
>https://datatracker.ietf.org/idtracker/ballot/2471/, is to add
>an IESG note to the front of the document that reads:
>
>         "The IESG notes the use of several non-example domains
>         (see RFC2606) in examples in this document.  These
>         domains appear in the same examples in RFC2821.  RFC2821
>         will continue to exist although its status will be
>         marked as obsoleted by this document.  Thus, the IESG
>         estimates that use of these particular examples in a
>         revision to RFC2821 causes less harm than the good done
>         by publishing this revision."
>
>I presume that this text has been signed off on by all of those
>listed as "Yes" or "No-Objection" on the ballot and note that
>their numbers are sufficient to have a Protocol Action notice
>issued.

Weighing only the examples against the rest of the specifications to 
determine which is less harmful seems odd.  It's not like an 
appropriate reuse of "free" bits.

>I'm going to avoid making editorial comments on that text at
>this time.  I do note, however, that this sort of note has never
>before been applied to a document that does not use 2606 names.
>I also note that the IESG has made no attempt to engage in a
>dialog on the subject of whether a note or this sort should be
>added, or about what it should contain with either this list or
>the IETF list.

By reviewing the document, the IESG is being asked to apply its 
technical judgement in determining the fitness and suitability of the 
specifications.  The term "technical" can be quite subjective in some 
circumstances as we have seen with the 2606 discussion on the IETF list.

>I can also find no authority, in RFC 2026 or elsewhere, for the
>IESG adding text to a Standards-track document without such
>consultation.  In particular, while Section 6.1.2 of RFC 2026
>contains an extended discussion of the IESG changing categories,
>forming WGs, etc., it appears clear that the IESG is to "approve
>or disapprove", not to start adding text reflecting its own
>observations, observations that may or may not represent
>community consensus.

At the moment, I cannot find any text from RFC 2026 which covers the 
area of disagreement.    RFC 3932 (BCP 92) discusses procedures and 
has some text about IESG notes.

Regards,
-sm 

Date: Wed, 9 Jul 2008 09:54:15 -0500
To: John C Klensin <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: Re: More new text for 2821bis (was: Re: Response to appeal  from John Klensin dated 13-Jun-2008)
Cc: [email-masked]
Sender: [email-masked]

On 7/9/08 at 2:51 AM -0400, John C Klensin wrote:

>	"The IESG notes the use of several non-example domains
>	(see RFC2606) in examples in this document.  These
>	domains appear in the same examples in RFC2821.  RFC2821
>	will continue to exist although its status will be
>	marked as obsoleted by this document.  Thus, the IESG
>	estimates that use of these particular examples in a
>	revision to RFC2821 causes less harm than the good done
>	by publishing this revision."

On the one hand, I am not entirely sure what this means. "2821 used 
these examples. 2821 still exists. Therefore, having the rev. 
published is more good than the harm from using the examples." That's 
not even logically coherent. So I object to this appearing in the 
document as is.

However, the last sentence *seems* to imply that the examples 
themselves still cause harm, which is not the consensus of the IETF, 
and I'm not even sure it's the consensus of the IESG. So I object to 
this note appearing in that it does not represent the truth of the 
matter.

Finally:

>I can also find no authority, in RFC 2026 or elsewhere, for the IESG 
>adding text to a Standards-track document without such consultation. 
>In particular, while Section 6.1.2 of RFC 2026 contains an extended 
>discussion of the IESG changing categories, forming WGs, etc., it 
>appears clear that the IESG is to "approve or disapprove", not to 
>start adding text reflecting its own observations, observations that 
>may or may not represent community consensus.

Indeed. See also RFC 3710.

My opinion: First get a clarification on what they are talking about. 
If the meaning is that they believe the examples do harm, point out 
that this may not be the consensus of the IETF. If they persist, 
appeal again. The original appeal was, in part, about the fact that 
the IESG is insisting on changes to documents without consensus. 
Unlike other documents where this is simply capitulated to, they got 
pushback here. As painful as it may be, this should continue to be 
pushed.

pr
-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Incorporated

Date: Wed, 09 Jul 2008 09:33:55 -0400
From: Keith Moore <[email-masked]>
To: John C Klensin <[email-masked]>
CC: [email-masked]
Subject: Re: More new text for 2821bis
Sender: [email-masked]

> But, unless it contains significant and important information,
> this stuff clutters up documents and, when there _is_ consensus
> about the technical specification and publication, can
> constitute the IESG saying "regardless of the community
> consensus, we, the all-seeing and all-knowing IESG, know better
> and are going to take advantage of our privileged position to
> state our opinion of the document --not in a dissenting RFC
> (which the IESG claims an absolute right to publish if they feel
> like it), or in an IESG statement, but by changing the Standards
> Track RFC itself.   There may be situations where even that is
> appropriate, but the question is what the limits are on this
> mechanism being used, largely invisibly (unless, as Frank notes,
> the author notices on AUTH48 and protests), and how far things
> can descend, to use your words, toward "fairly petty concerns",
> on the IESG's own authority.

well, yeah.

Though as the entire purpose of the note is, in some sense, to let the 
IESG move on and get documents published when there remains disagreement 
between the document author/editor/wg and IESG, a process that required 
agreement on those notes would seem to defeat their purpose. And without 
such notes, presumably more documents would be delayed.  So I am having 
a bit of trouble coming up with a process remedy that works better than 
what we have now.

Date: Wed, 09 Jul 2008 09:07:25 -0400
From: John C Klensin <[email-masked]>
To: Keith Moore <[email-masked]>
cc: [email-masked]
Subject: Re: More new text for 2821bis
Sender: [email-masked]

--On Wednesday, 09 July, 2008 08:04 -0400 Keith Moore
<[email-masked]> wrote:

> Adding an IESG note to a standards-track RFC is longstanding
> practice as a way for IESG members to "hold their noses" and
> feel better about approving a document which they dislike.
> Less frequently, it could also be used as a way to document
> irreconcilable differences between the document
> author/editor/wg and IESG while still letting the document
> move forward.  But mostly I think it was a way for IESG
> members to "feel better" about approving a document when there
> was something they didn't like and they were under pressure
> (usually from other IESG members) to approve it anyway.
> 
> I think they started using it around the time I was on IESG
> (1996-2000) - at least it seemed to become increasingly common
> during that time).  I don't know if the practice is documented
> anywhere - it was (IIRC) an informal agreement between IESG
> and the RFC Editor.
> 
> Such notes have been useful when there were important
> technical considerations that a WG refused to address.  But
> IMHO they have also frequently been used for fairly petty
> concerns, as in this case.

Keith,

Now I'm going to make an editorial comment...

Certainly I know the history.  To a greater or lesser degree,
most of us do.   Certainly it is just good sense, and therefore
entirely appropriate, for the IESG to use a note to record a
comment about technical controversy or weak consensus.   For
example, I would consider a note on a document that said:

	"Consensus in the community for publishing this document
	as a Proposed Standard was extremely weak, with many
	people questioning ... or preferring ...".  The IESG
	concluded that it should be published on the Standards
	Track anyway because... Readers are encouraged to note
	that, while many IETF Standards Track documents are
	implemented and deployed at Proposed Standard, the
	definition of that maturity level does not require a
	complete and tested specification and to check even more
	carefully than usual for revised documents and
	accumulated experience after publication."

entirely appropriate, even if it is very strong (assuming it
reflected the actual situation). 

While there were clearly issues that clouded the decisions, and
the decisions themselves may or may not have been correct, the
SPF case that Frank cites in his message about the notes on RFC
4408 (etc.), very definitely reflected a case in which there was
ongoing controversy and no clear consensus in the community.
The IESG also took the action that is clearly permitted to them
in such cases, which was to publish documents as Experimental or
Informational rather than on the Standards Track

But, unless it contains significant and important information,
this stuff clutters up documents and, when there _is_ consensus
about the technical specification and publication, can
constitute the IESG saying "regardless of the community
consensus, we, the all-seeing and all-knowing IESG, know better
and are going to take advantage of our privileged position to
state our opinion of the document --not in a dissenting RFC
(which the IESG claims an absolute right to publish if they feel
like it), or in an IESG statement, but by changing the Standards
Track RFC itself.   There may be situations where even that is
appropriate, but the question is what the limits are on this
mechanism being used, largely invisibly (unless, as Frank notes,
the author notices on AUTH48 and protests), and how far things
can descend, to use your words, toward "fairly petty concerns",
on the IESG's own authority.

sigh

regards,
     john

Date: Wed, 09 Jul 2008 08:04:11 -0400
From: Keith Moore <[email-masked]>
To: John C Klensin <[email-masked]>
CC: [email-masked]
Subject: Re: More new text for 2821bis
Sender: [email-masked]

Adding an IESG note to a standards-track RFC is longstanding practice as 
a way for IESG members to "hold their noses" and feel better about 
approving a document which they dislike.  Less frequently, it could also 
be used as a way to document irreconcilable differences between the 
document author/editor/wg and IESG while still letting the document move 
forward.  But mostly I think it was a way for IESG members to "feel 
better" about approving a document when there was something they didn't 
like and they were under pressure (usually from other IESG members) to 
approve it anyway.

I think they started using it around the time I was on IESG (1996-2000) 
- at least it seemed to become increasingly common during that time).  I 
don't know if the practice is documented anywhere - it was (IIRC) an 
informal agreement between IESG and the RFC Editor.

Such notes have been useful when there were important technical 
considerations that a WG refused to address.  But IMHO they have also 
frequently been used for fairly petty concerns, as in this case.

Keith

John C Klensin wrote:
> Folks,
> 
> This is the "surprise" referred to in one of my earlier notes.
> 
> Just so everyone knows, the appeal response says, in part...
> 
> 	"The IESG came to consensus that the use of non-example
> 	domain names should not prevent publication of
> 	RFC2821bis, even though the IESG finds this practice can
> 	cause harm. The arguments made in public list discussion
> 	of the appeal have been a factor in the IESG being able
> 	to come to consensus on this point."
> 
> I thought that wording was a little odd when I first read it
> but, other than noting that the IESG "finding" of harm did not
> appear to be consistent with community consensus, didn't pay a
> lot of attention to it.
> 
> However, while it is apparently not final and still has not
> appeared in the tracker (see
> https://datatracker.ietf.org/idtracker/draft-klensin-rfc2821bis/),
> the apparent intent of the IESG, reflected in the ballot at
> https://datatracker.ietf.org/idtracker/ballot/2471/, is to add
> an IESG note to the front of the document that reads:
> 
> 	"The IESG notes the use of several non-example domains
> 	(see RFC2606) in examples in this document.  These
> 	domains appear in the same examples in RFC2821.  RFC2821
> 	will continue to exist although its status will be
> 	marked as obsoleted by this document.  Thus, the IESG
> 	estimates that use of these particular examples in a
> 	revision to RFC2821 causes less harm than the good done
> 	by publishing this revision."
> 
> I presume that this text has been signed off on by all of those
> listed as "Yes" or "No-Objection" on the ballot and note that
> their numbers are sufficient to have a Protocol Action notice
> issued.
> 
> I'm going to avoid making editorial comments on that text at
> this time.  I do note, however, that this sort of note has never
> before been applied to a document that does not use 2606 names.
> I also note that the IESG has made no attempt to engage in a
> dialog on the subject of whether a note or this sort should be
> added, or about what it should contain with either this list or
> the IETF list.   
> 
> I can also find no authority, in RFC 2026 or elsewhere, for the
> IESG adding text to a Standards-track document without such
> consultation.  In particular, while Section 6.1.2 of RFC 2026
> contains an extended discussion of the IESG changing categories,
> forming WGs, etc., it appears clear that the IESG is to "approve
> or disapprove", not to start adding text reflecting its own
> observations, observations that may or may not represent
> community consensus.
> 
> Advice or instructions welcome.
> 
>       john
> 
> 

To: [email-masked]
From:  "Frank Ellermann" <[email-masked]>
Subject:  Re: More new text for 2821bis
Date:  Wed, 9 Jul 2008 10:53:11 +0200
Organization:  <http://purl.net/xyzzy>
Lines: 104
Reply-To:  "Frank Ellermann" <[email-masked]>
Sender: [email-masked]

John C Klensin wrote:
=20
> However, while it is apparently not final and still has not
> appeared in the tracker (see
> https://datatracker.ietf.org/idtracker/draft-klensin-rfc2821bis/),
> the apparent intent of the IESG, reflected in the ballot at
> https://datatracker.ietf.org/idtracker/ballot/2471/, is to
> add an IESG note to the front of the document

That's how those RFC-editor and IESG notes are prepared, they
appear in the (draft) approval mail at the end of the ballot.

It is one of two weak points (the other being AUTH48) with
drafts.  But authors are free to reject it in AUTH48 by not
signing an annotated draft.

For RFC 4408 folks caught an "RFCed note" attempt to remove
an absolutely critical NOT RECOMMENDED, and rejected it.

After that it popped up again as "IESG note" and went to an
IAB review.  The IAB decided that conflicting experiments
offering a convoluted IESG note "opt-out" for participants
of the 1st experiment not interested in the 2nd experiment
are no issue.

With that on public record the case was closed and the RFC
published (with the complete revised IESG note, see below).

> the IESG has made no attempt to engage in a dialog on the
> subject of whether a note or this sort should be added, or
> about what it should contain

Yes, interested folks have to check the proposed approval or
read the final announcement, and they also have to check the
final AUTH48 outcome.  Even a good faith "RFC-editor note"
can introduce massive side-effects like blocking RFCs 4645
and 4646 for many months until RFC 4647 was ready.

> while Section 6.1.2 of RFC 2026 contains an extended=20
> discussion of the IESG changing categories, forming WGs,
> etc., it appears clear that the IESG is to "approve or
> disapprove", not to start adding text reflecting its own
> observations, observations that may or may not represent
> community consensus.

Did you ever read the rather long IESG note in RFC 4408 ? =20

| there is no general technical consensus and efforts to
| reconcile the two approaches have failed
=3D After the WG had consensus that the two approaches are=20
  incompatible it was terminated in violation of RFC 2418

| these documents have not received full IETF review
=3D a request for an IETF Last Call was rejected by the IESG

| Note that the Sender ID experiment may use DNS records
| that may have been created for the current SPF experiment
| or earlier versions in this set of experiments.
=3D Three Sender ID ABSTAINs failed to reach 1/3 for a DO NOT
  PUBLISH by one vote (IIRC)

| Depending on the content of the record, this may mean that
| Sender-ID heuristics would be applied incorrectly to a=20
| message.  Depending on the actions associated by the
| recipient with those heuristics, the message may not be
| delivered or may be discarded on receipt.
=3D A 100% accurate description of the problem.

| Participants relying on Sender ID experiment DNS records
| are warned that they may lose valid messages in this set
| of circumstances.
=3D That is about receivers applying the Sender ID algorithm
  on an SPF polic; they may lose legit inbound mails.  This
  statement apparently missed the point in two dimensions.

| aParticipants publishing SPF experiment DNS records should
| consider the advice given in section 3.4 of RFC 4406 and
| may wish to publish both v=3Dspf1 and spf2.0 records to avoid
| the conflict.
=3D Sender ID offers a weird "opt-out" from its own bugs; it
  is no problem to publish more than one TXT record; about
  a million (back in 2006) of existing SPF publishers will
  read IESG notes.

The next eight lines are mostly unrelated to RFC 4408, they
note that RFC 4406 can be not published on standards track
"as is" due to interoperability issues with RFC 822 + 2822.
(Among others, there are also issues with RFC 4409)

The longest IESG note I've ever seen in IETF RFCs (exactly
the same text went into RFCs 4405, 4406, and 4407).

> Advice or instructions welcome.

Readers will hopefully see that using real domains or mail
addresses in examples is not recommended, as it can cause
harm or other unexpected (SEO) effects.

At some point in time, e.g., in a next 2026bis round, the
"IESG notes" deserve a critical review.  They are free to
publish their thoughts in separate documents, unsolicited
annotations sometimes annoy authors and interested users.

 Frank

Date: Wed, 09 Jul 2008 02:51:20 -0400
From: John C Klensin <[email-masked]>
To: [email-masked]
Subject: More new text for 2821bis (was: Re: Response to appeal from John Klensin dated 13-Jun-2008)
Sender: [email-masked]

Folks,

This is the "surprise" referred to in one of my earlier notes.

Just so everyone knows, the appeal response says, in part...

	"The IESG came to consensus that the use of non-example
	domain names should not prevent publication of
	RFC2821bis, even though the IESG finds this practice can
	cause harm. The arguments made in public list discussion
	of the appeal have been a factor in the IESG being able
	to come to consensus on this point."

I thought that wording was a little odd when I first read it
but, other than noting that the IESG "finding" of harm did not
appear to be consistent with community consensus, didn't pay a
lot of attention to it.

However, while it is apparently not final and still has not
appeared in the tracker (see
https://datatracker.ietf.org/idtracker/draft-klensin-rfc2821bis/),
the apparent intent of the IESG, reflected in the ballot at
https://datatracker.ietf.org/idtracker/ballot/2471/, is to add
an IESG note to the front of the document that reads:

	"The IESG notes the use of several non-example domains
	(see RFC2606) in examples in this document.  These
	domains appear in the same examples in RFC2821.  RFC2821
	will continue to exist although its status will be
	marked as obsoleted by this document.  Thus, the IESG
	estimates that use of these particular examples in a
	revision to RFC2821 causes less harm than the good done
	by publishing this revision."

I presume that this text has been signed off on by all of those
listed as "Yes" or "No-Objection" on the ballot and note that
their numbers are sufficient to have a Protocol Action notice
issued.

I'm going to avoid making editorial comments on that text at
this time.  I do note, however, that this sort of note has never
before been applied to a document that does not use 2606 names.
I also note that the IESG has made no attempt to engage in a
dialog on the subject of whether a note or this sort should be
added, or about what it should contain with either this list or
the IETF list.   

I can also find no authority, in RFC 2026 or elsewhere, for the
IESG adding text to a Standards-track document without such
consultation.  In particular, while Section 6.1.2 of RFC 2026
contains an extended discussion of the IESG changing categories,
forming WGs, etc., it appears clear that the IESG is to "approve
or disapprove", not to start adding text reflecting its own
observations, observations that may or may not represent
community consensus.

Advice or instructions welcome.

      john

Date: Tue, 08 Jul 2008 22:29:59 -0700
To: Tony Hansen <[email-masked]>, [email-masked]
From: SM <[email-masked]>
Subject: Re: IESG response fixes for 2821bis
Sender: [email-masked]

Hi Tony,
At 20:17 07-07-2008, Tony Hansen wrote:
>Trying to be transparent in the process here.
>
>The following changes were made during the IESG go-around and will 
>be included in the version of 2821bis passed to the RFC editor. 
>Hopefully they're all non-controversial.

The changes are fine.

Regards,
-sm 

Date: Tue, 08 Jul 2008 21:50:50 -0400
From: Tony Hansen <[email-masked]>
To: [email-masked]
Subject: Re: IESG response fixes for 2821bis
Sender: [email-masked]

John C Klensin wrote:
> 
> 
> --On Tuesday, 08 July, 2008 08:15 +0200 Frank Ellermann
> <[email-masked]> wrote:
> 
>>
>> To be consistent with RFC 2821, this needs a header:
>>   Updates: 1123 
> 
> This has been done and presumably should have been on Tony's
> list.  Tony, I've fixed the change log to call this out.

My eyes flew right by that one.

> and
> 
>> Suggestion: STD 66 (URI RFC 3986) defines an "IPv6address"
>> rule that could be referenced or copied.  It got the ABNF
>> cleaner than we got it here (and yes, that ABNF was my fault
>> in RFC 2821 but I recognize when someone else does it better).
> 
> I considered this and decided to let it go and did not receive
> any comments from Tony to the contrary.   The existing ABNF is
> not broken and it is late to be making changes.

Any suggestion of the form "it would be nice if" (compared to "this is 
wrong" or "such and such is out and out broken") always went through the 
filter of: is there a call for it to be done by enough people for there 
to be considered a consensus to do it. This particular suggestion fell 
in the category of insufficient backing.

	Tony Hansen
	[email-masked]

Date: Thu, 03 Jul 2008 15:12:37 -0400
From: John C Klensin <[email-masked]>
To: Magnus Westerlund <[email-masked]>
cc: [email-masked], IESG <[email-masked]>
Subject: Re: draft-klensin-rfc2821bis-10: ABNF discuss
Sender: [email-masked]

--On Thursday, 03 July, 2008 20:41 +0200 Magnus Westerlund
<[email-masked]> wrote:

>> The "not discussed at all" issue is one that could open up yet
>> another whole discussion of the information the tracker gives
>> to authors, editors, mailing lists, etc., and just what the
>> expectations are of both IESG members and document shepherds.
>> Since those topics are probably as controversial as the ones
>> associated with the pending appeal, I'm going to try to avoid
>> them here and hope that, if people do want to raise them, they
>> will at least change the subject line.
> 
> I only tried to express that if one tries to resolve a discuss
> one needs
> to involve the Discuss holding AD somehow. And I have
> personally not
> heard a single beep from anyone until a week ago about this
> part of the discuss.

Understood.

Part of the problem here is similar to one that the RFC Editor
discovered and fixed some years ago. 

Because "DISCUSS" can mean, among other things:

	* I want to think about this for a while
	
	* I want to discuss it with other IESG members and find
	out what they think
	
	* I am expecting further input from the developers of
	the document

it is a little bit too easy for the third case to get lost.  It
obviously did in this case, for which I apologize.  On the other
hand, it would be, IMO, very helpful if the IESG cleaned that
situation up.

I'll let others comment on the substance of your note -- you
have probably heard enough from me.

regards,
    john

To: [email-masked]
From:  "Frank Ellermann" <[email-masked]>
Subject:  Re: borderline offtopic about examples
Date:  Tue, 8 Jul 2008 18:47:10 +0200
Organization:  <http://purl.net/xyzzy>
Lines: 16
Reply-To:  "Frank Ellermann" <[email-masked]>
Sender: [email-masked]

Arnt Gulbrandsen wrote:

> Examples should be realistic, in the sense that they=20
> remind readers of the real thing. "foo.example" doesn't
> strike me as a good example of a fully-qualified domain
> name. ("foo.arpa" isn't too good either, now that .arpa
> is long forgotten.)

At some point it's a matter of taste, yet another "Alice"
and "Bob" example can be also surreal, if they don't do
anything remotely related to crypto.

Some days ago I counted the foos and bars in RFC 2821:
<http://www.rfc-editor.org/errata_search.php?rfc=3D3092>

 Frank

Date: Tue, 08 Jul 2008 09:15:12 -0700
To: [email-masked]
From: SM <[email-masked]>
Subject: Re: borderline offtopic about examples
Sender: [email-masked]

Hi Arnt,
At 01:53 08-07-2008, Arnt Gulbrandsen wrote:
>If an example is to be changed and still keep its value to the 
>reader, then it has to be edited with care. A global search and 
>replace isn't care.

Agreed.

>And an on-topic remark: I tried to edit the examples in either 2821 
>or 2822 into 2606ese a couple of years ago, but gave up. 2606 didn't 
>provide enough domains for me to do the job well. Maybe a better 
>editor could do it. Or maybe not. Jon Postel chose to use more 
>domains than 2606 provides, and IMNSHO Jon Postel was good enough at 
>writing RFCs.

I think that with a few iterations this group might get it 
right.  2821 would not be what it is without Jon Postel's 
examples.  The examples also provide an insight on how SMTP has 
evolved over the years.

Regards,
-sm 

Date: Tue, 8 Jul 2008 17:49:08 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: borderline offtopic about examples
Cc: Frank Ellermann <[email-masked]>, Frank Ellermann <[email-masked]>
Sender: [email-masked]

Frank Ellermann writes:
> Arnt Gulbrandsen wrote:
>
>>  Jon Postel chose to use more domains than 2606 provides
>
> JFTR, 821 < 2606.

Yes.

> All RFC 821 examples use TLD .arpa, s/.arpa/.example/g in RFC 821 =
could work.

IMO: Not at all. Examples should be realistic, in the sense that they=20
remind readers of the real thing. "foo.example" doesn't strike me as a=20
good example of a fully-qualified domain name. ("foo.arpa" isn't too=20
good either, now that .arpa is long forgotten.)

> Maybe you tried your exampl-ification later, not based on RFC 821 (?)

I looked it up: The place that made me give up is 2821 appendix D.

Arnt

Date: Tue, 08 Jul 2008 10:25:44 -0400
From: Cyrus Daboo <[email-masked]>
To: Tony Hansen <[email-masked]>, [email-masked]
Subject: Re: Response to appeal from John Klensin dated 13-Jun-2008
Sender: [email-masked]

Hi Tony,

--On July 7, 2008 6:35:07 PM -0400 Tony Hansen <[email-masked]> wrote:

> 1) none of the domain names be changed?
> 2) all domain names be changed, except Jon Postel's isi.edu and usc.edu
> references
> 3) all domain names be changed

#1 please.

-- 
Cyrus Daboo

Date: Tue, 08 Jul 2008 16:02:57 +0200
From: Francesco Gennai <[email-masked]>
Subject: Re: Response to appeal from John Klensin dated 13-Jun-2008
To: John Leslie <[email-masked]>, Tony Hansen <[email-masked]>, [email-masked]
Sender: [email-masked]

> > Tony Hansen <[email-masked]> wrote:
> > >
> > > Now that the appeal is done and out of the way, do people prefer
> > >
> > > 1) none of the domain names be changed?
> > > 2) all domain names be changed, except Jon Postel's isi.edu and usc.edu
> > > references
> > > 3) all domain names be changed
> > >
> > > I would like to get a quick consensus call for this question. Please
> > > respond by Thursday, July 10.

> >    Since you ask, I'd recommend #2 (assuming isi.edu is OK with it).

> >    Understand, it's inevitable that future documents will copy text
> > from 2821bis, and either have to face this issue when it's no longer
> > fresh in people's mind, or ask for an exception to the RECOMMENDED.
> > There can be no _fully_ satisfactory resolution to that.

> You could insert a paragraph (appendix?) to explains the exception.... so
> that also for documents that will copy text from 2821bis or for future
> revision that will remain a valid exception and .... it could help to maintain
> this issue fresh in people's mind.

Ok,
I see now that John has already added an aknowledgement.... so -1- is the best
solution IMHO.

Francesco

> Francesco

> >    I do not mean to lobby for changing _all_ examples, least of all
> > mechanically changing _all_ examples -- changing the ones we're
> > confident we can get right is certainly sufficient.

> >    We should, at a minimim, consider changing the examples which
> > reference domains which _are_ registered to folks today.

> > --
> > John Leslie <[email-masked]>

Date: Tue, 08 Jul 2008 15:42:56 +0200
From: Francesco Gennai <[email-masked]>
Subject: Re: Response to appeal from John Klensin dated 13-Jun-2008
To: John Leslie <[email-masked]>
Cc: Tony Hansen <[email-masked]>, [email-masked]
Sender: [email-masked]

> Tony Hansen <[email-masked]> wrote:
> >
> > Now that the appeal is done and out of the way, do people prefer
> >
> > 1) none of the domain names be changed?
> > 2) all domain names be changed, except Jon Postel's isi.edu and usc.edu
> > references
> > 3) all domain names be changed
> >
> > I would like to get a quick consensus call for this question. Please
> > respond by Thursday, July 10.

>    Since you ask, I'd recommend #2 (assuming isi.edu is OK with it).

>    Understand, it's inevitable that future documents will copy text
> from 2821bis, and either have to face this issue when it's no longer
> fresh in people's mind, or ask for an exception to the RECOMMENDED.
> There can be no _fully_ satisfactory resolution to that.

You could insert a paragraph (appendix?) to explains the exception.... so 
that also for documents that will copy text from 2821bis or for future 
revision that will remain a valid exception and .... it could help to maintain
this issue fresh in people's mind.

Francesco  

>    I do not mean to lobby for changing _all_ examples, least of all
> mechanically changing _all_ examples -- changing the ones we're
> confident we can get right is certainly sufficient.

>    We should, at a minimim, consider changing the examples which
> reference domains which _are_ registered to folks today.

> --
> John Leslie <[email-masked]>

Date: Tue, 08 Jul 2008 09:47:51 -0400
From: Tony Hansen <[email-masked]>
To: Magnus Westerlund <[email-masked]>
CC: [email-masked]
Subject: Re: IESG response fixes for 2821bis
Sender: [email-masked]

Thank you Magnus.

	Tony Hansen

Magnus Westerlund wrote:
> 
> Hi,
> 
> For your knowledge: I am happy with the below ABNF changes and they 
> fully address my DISCUSS so it has been cleared.
> 
> Best Regards
> 
> Magnus
> 
> Tony Hansen skrev:
>>
>> Tony Hansen wrote:
>>>
>>> PS. John has also made some minor ABNF tweaks in response to the IESG 
>>> comments, as well as adding an explicit acknowledgment to Jon 
>>> Postel's work. I'll post a note about these separately.
>>
>> Trying to be transparent in the process here.
>>
>> The following changes were made during the IESG go-around and will be 
>> included in the version of 2821bis passed to the RFC editor. Hopefully 
>> they're all non-controversial.
>>
>> 1) Added ; to last comment line for ehlo-param
>>
>> 2) Made consistent the names Forward-path, QcontentSMTP, address-literal
>>
>> 3) Restored the Standardized-tag production from 2821
>>
>>     Standardized-tag = Ldh-str
>>
>> 4) There were a couple definitions that were originally pulled in from 
>> 2822, but 2822upd does not have comparable definitions.
>>
>>     provided a "dcontent" definition
>>
>>     dcontent = %d33-90 /    ; Printable US-ASCII           %d94-126    
>> ; excl. "[", "\", "]"
>>
>>     renamed "text" name to be "textstring" and gave it this definition
>>
>>     textstring = 1*(%d09 / %d32-126) ; HT, SP, Printable US-ASCII
>>
>> 5) Typo: "implementating" => "implementing"
>>
>> 6) John added this acknowledgment paragraph:
>>
>>     Neither this document nor RFC 2821 would have been possible without
>>     the many contribution and insights of the late Jon Postel. Those
>>     contributions of course include the original specification of SMTP
>>     in RFC 821. A considerable quantity of text from RFC 821 still
>>     appears in this document as do several of Jon's original examples
>>     which have been updated only as needed to reflect other changes in
>>     the specification.
>>
>> 7) Typo: "in in" => "in"
>>
>>     Tony Hansen
>>
>>
> 
> 

Date: Tue, 8 Jul 2008 09:23:38 -0400
From: John Leslie <[email-masked]>
To: Tony Hansen <[email-masked]>
Cc: [email-masked]
Subject: Re: Response to appeal from John Klensin dated 13-Jun-2008
Sender: [email-masked]

Tony Hansen <[email-masked]> wrote:
> 
> Now that the appeal is done and out of the way, do people prefer
> 
> 1) none of the domain names be changed?
> 2) all domain names be changed, except Jon Postel's isi.edu and usc.edu 
> references
> 3) all domain names be changed
> 
> I would like to get a quick consensus call for this question. Please 
> respond by Thursday, July 10.

   Since you ask, I'd recommend #2 (assuming isi.edu is OK with it).

   Understand, it's inevitable that future documents will copy text
from 2821bis, and either have to face this issue when it's no longer
fresh in people's mind, or ask for an exception to the RECOMMENDED.
There can be no _fully_ satisfactory resolution to that.

   I do not mean to lobby for changing _all_ examples, least of all
mechanically changing _all_ examples -- changing the ones we're
confident we can get right is certainly sufficient.

   We should, at a minimim, consider changing the examples which
reference domains which _are_ registered to folks today.

--
John Leslie <[email-masked]>

Date: Tue, 08 Jul 2008 14:17:30 +0100
From: Alexey Melnikov <[email-masked]>
To: [email-masked]
Subject: Re: Response to appeal from John Klensin dated 13-Jun-2008
Sender: [email-masked]

Arnt Gulbrandsen wrote:

> Tony Hansen writes:
>
>> Now that the appeal is done and out of the way, do people prefer
>>
>> 1) none of the domain names be changed?
>> 2) all domain names be changed, except Jon Postel's isi.edu and 
>> usc.edu references
>> 3) all domain names be changed
>>
>> I would like to get a quick consensus call for this question. Please 
>> respond by Thursday, July 10.
>
> If it isn't broke, don't fix it. 1.

+1.

> (Yes, I know that using non-2606 names has caused problems in many 
> other documents. But I don't see what problems 2821bis will bring over 
> and above what 821 and 2821 already have brought.)
>
> Arnt
>

Date: Tue, 08 Jul 2008 09:03:46 -0400
From: Keith Moore <[email-masked]>
To: Tony Hansen <[email-masked]>
CC: [email-masked]
Subject: Re: Response to appeal from John Klensin dated 13-Jun-2008
Sender: [email-masked]

> Now that the appeal is done and out of the way, do people prefer
> 
> 1) none of the domain names be changed?
> 2) all domain names be changed, except Jon Postel's isi.edu and usc.edu 
> references
> 3) all domain names be changed

option 1.  is there a good reason to change them?

Keith

Date: Tue, 08 Jul 2008 14:46:39 +0200
From: Alessandro Vesely <[email-masked]>
To: [email-masked]
Subject: Re: Response to appeal from John Klensin dated 13-Jun-2008
Sender: [email-masked]

Tony Hansen wrote:
> Quick poll:
> 
> John has said to me that he's always been willing to change the 
> non-example domain names to 2606 example domain names.
> 
> Now that the appeal is done and out of the way, do people prefer
> 
> 1) none of the domain names be changed?
> 2) all domain names be changed, except Jon Postel's isi.edu and usc.edu 
> references
> 3) all domain names be changed

I vote #1, since s/[a-z]*[.][a-z]*/example.com/ would obviously ruin 
the document. However, I find of historical significance the examples 
with Jon Postel's addresses and I appreciate the effort to keep them 
as they are.

To: [email-masked]
From:  "Frank Ellermann" <[email-masked]>
Subject:  Re: borderline offtopic about examples
Date:  Tue, 8 Jul 2008 14:25:55 +0200
Organization:  <http://purl.net/xyzzy>
Lines: 20
Reply-To:  "Frank Ellermann" <[email-masked]>
Sender: [email-masked]

Arnt Gulbrandsen wrote:

> Jon Postel chose to use more domains than 2606 provides

JFTR, 821 < 2606.

All RFC 821 examples use TLD .arpa, s/.arpa/.example/g in
RFC 821 could work.  Maybe you tried your exampl-ification
later, not based on RFC 821 (?)

John Klensin wrote:

> Please remember this line of argument and experience when
> the IESG issues the promised document promoting 2606 to a
> firm requirement.  :-(

Nobody can redefine RECOMMENDED to mean REQUIRED.  Nobody
seriously proposed to say MUST.

 Frank

From: Steve Atkins <[email-masked]>
To: SMTP Interest Group <[email-masked]>
Subject: Re: Response to appeal from John Klensin dated 13-Jun-2008
Date: Tue, 8 Jul 2008 12:28:26 +0100
Sender: [email-masked]

On Jul 8, 2008, at 6:19 AM, SM wrote:

>
> Hi Tony,
> At 15:35 07-07-2008, Tony Hansen wrote:
> Quick poll:
>
>> John has said to me that he's always been willing to change the non- 
>> example domain names to 2606 example domain names.
>>
>> Now that the appeal is done and out of the way, do people prefer
>>
>> 1) none of the domain names be changed?
>> 2) all domain names be changed, except Jon Postel's isi.edu and  
>> usc.edu references
>> 3) all domain names be changed
>
> I prefer (1) as such changes may entail more than simply  
> adding .example at the end of the domain names.

+1, both for that pragmatic reason and the issues raised by Ned and  
Dave, amongst others.

Cheers,
   Steve

To: [email-masked]
From:  "Frank Ellermann" <[email-masked]>
Subject:  Re: IESG response fixes for 2821bis
Date:  Tue, 8 Jul 2008 13:13:27 +0200
Organization:  <http://purl.net/xyzzy>
Lines: 107
Reply-To:  "Frank Ellermann" <[email-masked]>
Sender: [email-masked]

John C Klensin wrote:

> since the IESG apparently has at least one more <Surprise>
> coming for this group (watch the list)

Watching... =20

> I am strongly disinclined to make any further changes that
> have not already been signed off by them, or that are direct
> consequences of things they have insisted on, and that are
> not the result of absolute showstoppers.

They didn't insist on fixing <dcontent>, I insisted on it ;-)

And while checking that your fix matches 2822upd I saw that
you already picked <qtextSMTP> in a similar case, and you
might like to stick to this style also for the <dtext>.  Or
not, because <dcontent> was the name in RFC 2822.   =20

> we might have to insist on another IETF Last Call on such
> changes

IIRC I reported the <dcontent> bug in both IETF Last Calls,
IMO you are perfectly entitled to fix it as you see fit. ;-)

>|   Updates: 1123=20
> This has been done

Good, thanks.

>| It got the ABNF cleaner than we got it here (and yes, that
>| ABNF was my fault in RFC 2821 but I recognize when someone
>| else does it better).
=20
> I considered this and decided to let it go and did not receive
> any comments from Tony to the contrary.

Also reported several times. =20

> The existing ABNF is not broken and it is late to be making
> changes.

We often disagree when it's about ABNF.  I like it when I can
see a consistent "story" in different RFCs, provided that it
really is supposed to be the same story.  In that case it's
propaganda for exactly the same idea of IPv6 literals.

That two RFCs ended up with two different interpretations of
the same RFC 3696 idea of a <toplabel> bothered me even before
you overruled your RFC with an erratum... ;-)  Of course I had
no idea that something like RFC 952 exists, and that somebody
still considers it as relevant, or that it is a major part in
various political flame wars.  [[But I understand the concept,
1032 vs. 3912 is a similar hair splitting exercise]]

> I'd be especially reluctant to reference 3986

You could copy the ABNF, because it is KISS, and obvious, and
exactly expresses what you now have in a (convoluted) comment.

> yet another normative reference

Not if you copy it, only if you import it.

> it introduces some small amount of circularity (2821bis ->
> 3986 -> mailto -> 2821[bis]

RFC 2368 (mailto) is still based on 1738, and erroneously
used the 822 <mailbox> instead of the 821 <mailbox>, which
is the 2821(bis) <Mailbox> and not the 2822(upd) <mailbox>.

Mailto-bis will use 3986 and 2821bis, and I very much doubt
that it will talk about IPv6 literals in mailto addresses...

But if it does this having the same syntax could be a "Good
Thing" (tm).

> If it were six months ago

<http://article.gmane.org/gmane.ietf.smtp/4482/match=3Dipvfuture>
| While you're at it grab also the other address literals=20
| from STD 66, they are simply better.

That was even *before* you posted -00 back in June 2005.=20

<http://article.gmane.org/gmane.ietf.smtp/5926>
| An IPv6 is an IPv6, and I think the 3986 folks got this right.
|
| It's potentially harmful for interoperability if 2821bis and
| 3986 have different ideas about the syntax of an IPv6 literal.
[...]
| SPF uses 3513 "syntax", and as far as I can tell it 3986 is
| the formal ABNF of what 3513 says in prose by example.

That was in April 2007, and the SPF remark was wrong:  We used
3513, because 3513 obsoleted 2373; and we missed that the IPv6
*syntax* in 2373 went via 2732 into 3986.  Meanwhile 3513 is
obsolete.  Getting a consistent IPv6 "story" can be difficult.

> in case there is ever an rfc2821ter.

For that somebody has to find a bug in 2821bis within, *WHAT*,
four months ?!?  I didn't know that 2821bis will be STD 10 in
January 2009.  July + two months for appeals + four months...
now that's fast, isn't it ?

 Frank

Date: Tue, 08 Jul 2008 05:24:34 -0400
From: John C Klensin <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>, [email-masked]
Subject: Re: borderline offtopic about examples
Sender: [email-masked]

Please remember this line of argument and experience when the
IESG issues the promised document promoting 2606 to a firm
requirement.  :-(

FWIW, I completely agree.  Further fwiw, I tried, long before I
got upset at the blocking DISCUSS, to edit the example changes
into the working copy of 2821bis, trying to preserve the
diversity of the 821/2821 example domains in the process.   I
didn't run out of domains (having not tried the "append
'.example' to everything trick, partially on the theory that it
would add, rather than reduce, confusion).  I spent hours, not
days, on it, but... Tony and I have now discovered several
domains that I missed, at least one place where the example was
changed but text referring to it was not, etc.   Maybe I would
have gotten it right if I spent more time on it.  Probably we
could get it right if a lot of people looked at it.   But the
notion that one can just go in and quickly change the examples
in a document this large is, from my experience (and apparently
yours), just a fantasy.

I do believe that I have all of the places identified now so
that, if people wanted option (2), we could get it right with
one more pass by me and a review/recheck by others, so I don't
intend this note to influence the outcome of the poll.  But, in
the general case, I think it would be a bad mistake for the IESG
to insist on changing examples to 2606 form in revised large and
complex documents, just because of the risk of introducing new
errors.

    john

--On Tuesday, 08 July, 2008 10:53 +0200 Arnt Gulbrandsen
<[email-masked]> wrote:

> 
>> I prefer (1) as such changes may entail more than simply
>> adding  .example at the end of the domain names.
> 
> A little off-topic, but I feel like ranting.
> 
> IMO, adding .example to all the domains would be entirely
> insufficient. Both people and software are good at recognizing
> the common TLDs, and turning something like [email-masked]
> into [email-masked] doesn't change everyone's
> perception. Too many people will pick up the "TLD" .com while
> skimming or reading, too many scrapers will ignore .example.
> 
> If an example is to be changed and still keep its value to the
> reader, then it has to be edited with care. A global search
> and replace isn't care.
> 
> And an on-topic remark: I tried to edit the examples in either
> 2821 or 2822 into 2606ese a couple of years ago, but gave up.
> 2606 didn't provide enough domains for me to do the job well.
> Maybe a better editor could do it. Or maybe not. Jon Postel
> chose to use more domains than 2606 provides, and IMNSHO Jon
> Postel was good enough at writing RFCs.
> 
> Arnt
> 

Date: Tue, 08 Jul 2008 04:56:26 -0400
From: John C Klensin <[email-masked]>
To: Frank Ellermann <[email-masked]>
cc: [email-masked]
Subject: Re: IESG response fixes for 2821bis
Sender: [email-masked]

--On Tuesday, 08 July, 2008 08:15 +0200 Frank Ellermann
<[email-masked]> wrote:

> 
> Tony Hansen wrote:
>  
>> dcontent = %d33-90 / ; Printable US-ASCII 
>>            %d94-126  ; excl. "[", "\", "]"
> 
> Renaming this beast to dtextSMTP consistent with qtextSMPT
> is an option.  2822upd says:
> 
>  dtext   =   %d33-90 /          ; Printable US-ASCII
>              %d94-126 /         ;  characters not including
>              obs-dtext          ;  "[", "]", or "\"
> 
> Of course a matter of taste.

Frank, especially since the IESG apparently has at least one
more <Surprise> coming for this group (watch the list), I am
strongly disinclined to make any further changes that have not
already been signed off by them, or that are direct consequences
of things they have insisted on, and that are not the result of
absolute showstoppers.  In order to maintain a consistent
position, I/we might have to insist on another IETF Last Call on
such changes, resulting in further delays that accomplish very
little.  So, while I'm willing to be talked out of it, I prefer
to not see any more editorial suggestions right now.

>  What happened with two
> suggestions at the begin and the end of this comment:
> 
> https://datatracker.ietf.org/idtracker/draft-klensin-rfc2821bi
> s/comment/80585/  

If you are referring to 

>  FYI, to compare with previous RFC try this URI:
> 
> http://tools.ietf.org/rfcdiff?url2=http://www.ietf.org/interne
> t-drafts/draft-klensin-rfc2821bis-10.txt&url1=http://www.ietf.
> org/rfc/rfc2821.txt
> 
> To be consistent with RFC 2821, this needs a header:
>   Updates: 1123 

This has been done and presumably should have been on Tony's
list.  Tony, I've fixed the change log to call this out.

and

> Suggestion: STD 66 (URI RFC 3986) defines an "IPv6address"
> rule that could be referenced or copied.  It got the ABNF
> cleaner than we got it here (and yes, that ABNF was my fault
> in RFC 2821 but I recognize when someone else does it better).

I considered this and decided to let it go and did not receive
any comments from Tony to the contrary.   The existing ABNF is
not broken and it is late to be making changes.  I'd be
especially reluctant to reference 3986 because (i) it introduces
yet another normative reference and document that people have to
have virtually open to read 2821bis and (ii) it introduces some
small amount of circularity (2821bis -> 3986 -> mailto ->
2821[bis]).  If it were six months ago, I'd immediately make
this change.

Both of these remaining comments (renaming the production and
altering the IPv6address syntax) have been noted in case there
is ever an rfc2821ter.  Please do not take that as
encouragement; I'll stop trying to keep that list if there are
many more additions to it.

    john

Date: Tue, 8 Jul 2008 10:53:03 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: borderline offtopic about examples
Sender: [email-masked]

> I prefer (1) as such changes may entail more than simply adding 
> .example at the end of the domain names.

A little off-topic, but I feel like ranting.

IMO, adding .example to all the domains would be entirely insufficient. 
Both people and software are good at recognizing the common TLDs, and 
turning something like [email-masked] into [email-masked] 
doesn't change everyone's perception. Too many people will pick up the 
"TLD" .com while skimming or reading, too many scrapers will ignore 
.example.

If an example is to be changed and still keep its value to the reader, 
then it has to be edited with care. A global search and replace isn't 
care.

And an on-topic remark: I tried to edit the examples in either 2821 or 
2822 into 2606ese a couple of years ago, but gave up. 2606 didn't 
provide enough domains for me to do the job well. Maybe a better editor 
could do it. Or maybe not. Jon Postel chose to use more domains than 
2606 provides, and IMNSHO Jon Postel was good enough at writing RFCs.

Arnt

Date: Tue, 08 Jul 2008 10:49:55 +0200
From: Magnus Westerlund <[email-masked]>
To: Tony Hansen <[email-masked]>
CC: [email-masked]
Subject: Re: IESG response fixes for 2821bis
Sender: [email-masked]

Hi,

For your knowledge: I am happy with the below ABNF changes and they 
fully address my DISCUSS so it has been cleared.

Best Regards

Magnus

Tony Hansen skrev:
> 
> Tony Hansen wrote:
>>
>> PS. John has also made some minor ABNF tweaks in response to the IESG 
>> comments, as well as adding an explicit acknowledgment to Jon Postel's 
>> work. I'll post a note about these separately.
> 
> Trying to be transparent in the process here.
> 
> The following changes were made during the IESG go-around and will be 
> included in the version of 2821bis passed to the RFC editor. Hopefully 
> they're all non-controversial.
> 
> 1) Added ; to last comment line for ehlo-param
> 
> 2) Made consistent the names Forward-path, QcontentSMTP, address-literal
> 
> 3) Restored the Standardized-tag production from 2821
> 
>     Standardized-tag = Ldh-str
> 
> 4) There were a couple definitions that were originally pulled in from 
> 2822, but 2822upd does not have comparable definitions.
> 
>     provided a "dcontent" definition
> 
>     dcontent = %d33-90 /    ; Printable US-ASCII   
>         %d94-126    ; excl. "[", "\", "]"
> 
>     renamed "text" name to be "textstring" and gave it this definition
> 
>     textstring = 1*(%d09 / %d32-126) ; HT, SP, Printable US-ASCII
> 
> 5) Typo: "implementating" => "implementing"
> 
> 6) John added this acknowledgment paragraph:
> 
>     Neither this document nor RFC 2821 would have been possible without
>     the many contribution and insights of the late Jon Postel. Those
>     contributions of course include the original specification of SMTP
>     in RFC 821. A considerable quantity of text from RFC 821 still
>     appears in this document as do several of Jon's original examples
>     which have been updated only as needed to reflect other changes in
>     the specification.
> 
> 7) Typo: "in in" => "in"
> 
>     Tony Hansen
> 
> 

-- 

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Färögatan 6                | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

Date: Tue, 08 Jul 2008 04:22:59 -0400
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To: Tony Hansen <[email-masked]>
CC:  [email-masked]
Subject: Re: Response to appeal from John Klensin dated 13-Jun-2008
Sender: [email-masked]

Preference is #1.

That said. My opinion:

I'm was trained with the Westinghouse motto of "Getting it right the 
first time."   I can't say if its was wrong to begin with, but obvious 
progress was made, the bridge and highways were built.  So it probably 
wasn't wrong - obviously.

However, it does appears the "docs" people wish to "clean things" up 
believing it will be "better".

What is better?

Well, to me, it can only make sense to be better for "new people", the 
future generation of internet mail system engineers.

I see no harm with the current engineers in charge of their wares and/or 
operations evolving.

So option #3 is ok by me as well.

If the IETF believes "Getting it right, the 2nd time" will improve 
technical communications with consistent nomenclature for future 
generations, then I don't see any harm to changes all the domains to 
follow the recommended technical writing guidelines.

Its funny that what comes to mind about all this, I recall a few years 
back I posted an SMTP topic showing an example SMTP client/server 
session and few responses I got was related to correcting the smtp 
session example, including the domain name I used. Completely unrelated 
to the topic, but I was still green with IETF ways and clearly 
understood it is best to use nomenclature that is considered useful for 
technical communications.

-- 
Sincerely

Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com

Tony Hansen wrote:
> 
> IESG Secretary wrote:
>> The IESG received an appeal from John Klensin dated June 13, 2008.
>> This is a response to that appeal.
>>
>> 1. The appeal asked for the IESG to approve RFC2821bis. The
>> IESG came to consensus that the use of non-example domain names
>> should not prevent publication of RFC2821bis, even though the IESG
>> finds this practice can cause harm. The arguments made in public
>> list discussion of the appeal have been a factor in the IESG being
>> able to come to consensus on this point.
> 
> Quick poll:
> 
> John has said to me that he's always been willing to change the 
> non-example domain names to 2606 example domain names.
> 
> Now that the appeal is done and out of the way, do people prefer
> 
> 1) none of the domain names be changed?
> 2) all domain names be changed, except Jon Postel's isi.edu and usc.edu 
> references
> 3) all domain names be changed
> 
> I would like to get a quick consensus call for this question. Please 
> respond by Thursday, July 10.
> 
> Thank you!
> 
>     Tony Hansen
> 
> PS. John has also made some minor ABNF tweaks in response to the IESG 
> comments, as well as adding an explicit acknowledgment to Jon Postel's 
> work. I'll post a note about these separately.
> 
> 
> 

-- 
Sincerely

Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com

Date: Tue, 8 Jul 2008 09:44:23 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: Response to appeal from John Klensin dated 13-Jun-2008
Cc: Tony Hansen <[email-masked]>
Sender: [email-masked]

Tony Hansen writes:
> Now that the appeal is done and out of the way, do people prefer
>
> 1) none of the domain names be changed?
> 2) all domain names be changed, except Jon Postel's isi.edu and 
> usc.edu references
> 3) all domain names be changed
>
> I would like to get a quick consensus call for this question. Please 
> respond by Thursday, July 10.

If it isn't broke, don't fix it. 1.

(Yes, I know that using non-2606 names has caused problems in many other 
documents. But I don't see what problems 2821bis will bring over and 
above what 821 and 2821 already have brought.)

Arnt

To: [email-masked]
From:  "Frank Ellermann" <[email-masked]>
Subject:  Re: IESG response fixes for 2821bis
Date:  Tue, 8 Jul 2008 08:15:02 +0200
Organization:  <http://purl.net/xyzzy>
Lines: 19
Reply-To:  "Frank Ellermann" <[email-masked]>
Sender: [email-masked]

Tony Hansen wrote:
=20
> dcontent =3D %d33-90 / ; Printable US-ASCII=20
>            %d94-126  ; excl. "[", "\", "]"

Renaming this beast to dtextSMTP consistent with qtextSMPT
is an option.  2822upd says:

 dtext   =3D   %d33-90 /          ; Printable US-ASCII
             %d94-126 /         ;  characters not including
             obs-dtext          ;  "[", "]", or "\"

Of course a matter of taste.  What happened with two
suggestions at the begin and the end of this comment:

https://datatracker.ietf.org/idtracker/draft-klensin-rfc2821bis/comment/8=
0585/
=20
 Frank

Date: Mon, 07 Jul 2008 22:19:29 -0700
To: Tony Hansen <[email-masked]>, [email-masked]
From: SM <[email-masked]>
Subject: Re: Response to appeal from John Klensin dated 13-Jun-2008
Sender: [email-masked]

Hi Tony,
At 15:35 07-07-2008, Tony Hansen wrote:
Quick poll:

>John has said to me that he's always been willing to change the 
>non-example domain names to 2606 example domain names.
>
>Now that the appeal is done and out of the way, do people prefer
>
>1) none of the domain names be changed?
>2) all domain names be changed, except Jon Postel's isi.edu and 
>usc.edu references
>3) all domain names be changed

I prefer (1) as such changes may entail more than simply adding 
.example at the end of the domain names.

Regards,
-sm 

Date: Mon, 07 Jul 2008 23:17:14 -0400
From: Tony Hansen <[email-masked]>
To: [email-masked]
Subject: IESG response fixes for 2821bis
Sender: [email-masked]

Tony Hansen wrote:
> 
> PS. John has also made some minor ABNF tweaks in response to the IESG 
> comments, as well as adding an explicit acknowledgment to Jon Postel's 
> work. I'll post a note about these separately.

Trying to be transparent in the process here.

The following changes were made during the IESG go-around and will be 
included in the version of 2821bis passed to the RFC editor. Hopefully 
they're all non-controversial.

1) Added ; to last comment line for ehlo-param

2) Made consistent the names Forward-path, QcontentSMTP, address-literal

3) Restored the Standardized-tag production from 2821

     Standardized-tag = Ldh-str

4) There were a couple definitions that were originally pulled in from 
2822, but 2822upd does not have comparable definitions.

     provided a "dcontent" definition

	dcontent = %d33-90 /	; Printable US-ASCII	
		%d94-126	; excl. "[", "\", "]"

     renamed "text" name to be "textstring" and gave it this definition

	textstring = 1*(%d09 / %d32-126) ; HT, SP, Printable US-ASCII

5) Typo: "implementating" => "implementing"

6) John added this acknowledgment paragraph:

     Neither this document nor RFC 2821 would have been possible without
     the many contribution and insights of the late Jon Postel. Those
     contributions of course include the original specification of SMTP
     in RFC 821. A considerable quantity of text from RFC 821 still
     appears in this document as do several of Jon's original examples
     which have been updated only as needed to reflect other changes in
     the specification.

7) Typo: "in in" => "in"

	Tony Hansen

Date: Tue, 8 Jul 2008 03:25:38 +0200
From: Keld =?iso-8859-1?Q?J=F8rn?= Simonsen <[email-masked]>
To: [email-masked]
Cc: Tony Hansen <[email-masked]>, [email-masked]
Subject: Re: Response to appeal from John Klensin dated 13-Jun-2008
Sender: [email-masked]

On Mon, Jul 07, 2008 at 05:26:12PM -0700, [email-masked] wrote:
> 
> 
> >IESG Secretary wrote:
> >> The IESG received an appeal from John Klensin dated June 13, 2008.
> >> This is a response to that appeal.
> >>
> >> 1. The appeal asked for the IESG to approve RFC2821bis. The
> >> IESG came to consensus that the use of non-example domain names
> >> should not prevent publication of RFC2821bis, even though the IESG
> >> finds this practice can cause harm. The arguments made in public
> >> list discussion of the appeal have been a factor in the IESG being
> >> able to come to consensus on this point.
> 
> >Quick poll:
> 
> >John has said to me that he's always been willing to change the
> >non-example domain names to 2606 example domain names.
> 
> >Now that the appeal is done and out of the way, do people prefer
> 
> >1) none of the domain names be changed?
> >2) all domain names be changed, except Jon Postel's isi.edu and usc.edu
> >references
> >3) all domain names be changed
> 
> Strongly prefer (1). (2) is tolerable. (3) is unacceptable and frankly
> offensive.

I agree with Ned's position.

keld

Date: Mon, 07 Jul 2008 18:16:29 -0700
From: Dave Crocker <[email-masked]>
Reply-To: [email-masked]
Organization: Brandenburg InternetWorking
To: [email-masked]
Subject: Re: Response to appeal from John Klensin dated 13-Jun-2008
Sender: [email-masked]

> Now that the appeal is done and out of the way, do people prefer
> 
>> 1) none of the domain names be changed?
>> 2) all domain names be changed, except Jon Postel's isi.edu and usc.edu
>> references
>> 3) all domain names be changed
> 
> Strongly prefer (1). (2) is tolerable. (3) is unacceptable and frankly
> offensive.

Whereas the history of this makes even 2 pretty offensive, IMO.

In other words, 1, please.

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

Date: Mon, 07 Jul 2008 17:26:12 -0700 (PDT)
From: [email-masked]
Subject: Re: Response to appeal from John Klensin dated 13-Jun-2008
To: Tony Hansen <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

> IESG Secretary wrote:
> > The IESG received an appeal from John Klensin dated June 13, 2008.
> > This is a response to that appeal.
> >
> > 1. The appeal asked for the IESG to approve RFC2821bis. The
> > IESG came to consensus that the use of non-example domain names
> > should not prevent publication of RFC2821bis, even though the IESG
> > finds this practice can cause harm. The arguments made in public
> > list discussion of the appeal have been a factor in the IESG being
> > able to come to consensus on this point.

> Quick poll:

> John has said to me that he's always been willing to change the
> non-example domain names to 2606 example domain names.

> Now that the appeal is done and out of the way, do people prefer

> 1) none of the domain names be changed?
> 2) all domain names be changed, except Jon Postel's isi.edu and usc.edu
> references
> 3) all domain names be changed

Strongly prefer (1). (2) is tolerable. (3) is unacceptable and frankly
offensive.

				Ned

Date: Mon, 07 Jul 2008 16:33:33 -0700
From: Jim Fenton <[email-masked]>
To: Tony Hansen <[email-masked]>
CC: [email-masked]
Subject: Re: Response to appeal from John Klensin dated 13-Jun-2008
Sender: [email-masked]

Tony Hansen wrote:
> Now that the appeal is done and out of the way, do people prefer
>
> 1) none of the domain names be changed?
> 2) all domain names be changed, except Jon Postel's isi.edu and 
> usc.edu references
> 3) all domain names be changed
I prefer (2).

-Jim

Date: Mon, 07 Jul 2008 18:35:07 -0400
From: Tony Hansen <[email-masked]>
To: [email-masked]
Subject: Re: Response to appeal from John Klensin dated 13-Jun-2008
Sender: [email-masked]

IESG Secretary wrote:
> The IESG received an appeal from John Klensin dated June 13, 2008.
> This is a response to that appeal.
> 
> 1. The appeal asked for the IESG to approve RFC2821bis. The
> IESG came to consensus that the use of non-example domain names
> should not prevent publication of RFC2821bis, even though the IESG
> finds this practice can cause harm. The arguments made in public
> list discussion of the appeal have been a factor in the IESG being
> able to come to consensus on this point.

Quick poll:

John has said to me that he's always been willing to change the 
non-example domain names to 2606 example domain names.

Now that the appeal is done and out of the way, do people prefer

1) none of the domain names be changed?
2) all domain names be changed, except Jon Postel's isi.edu and usc.edu 
references
3) all domain names be changed

I would like to get a quick consensus call for this question. Please 
respond by Thursday, July 10.

Thank you!

	Tony Hansen

PS. John has also made some minor ABNF tweaks in response to the IESG 
comments, as well as adding an explicit acknowledgment to Jon Postel's 
work. I'll post a note about these separately.

From: IESG Secretary <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked]
Subject: Response to appeal from John Klensin dated 13-Jun-2008 
Date: Mon,  7 Jul 2008 10:00:01 -0700 (PDT)
Sender: [email-masked]

The IESG received an appeal from John Klensin dated June 13, 2008.
This is a response to that appeal.

1. The appeal asked for the IESG to approve RFC2821bis. (The
wording was that "the blocking DISCUSS must be removed" but that's a
detail of determining IESG consensus to approve a document.) The
IESG came to consensus that the use of non-example domain names
should not prevent publication of RFC2821bis, even though the IESG
finds this practice can cause harm. The arguments made in public
list discussion of the appeal have been a factor in the IESG being
able to come to consensus on this point.

The IESG believes the appeal has surfaced several important issues
with respect to the use of non-example names in IETF stream RFCs.
First, current IESG practice goes beyond the explicit requirements in
BCP 32. An IESG Statement that documents and explains this practice
is being developed to ensure transparency and avoid late surprises in
the publication process. Second, given that the non-example domain
names are already published in RFC 2821, and some were used with
permission, the possibility of harm to the Internet is less clear
than with new specifications. Community input is needed with respect
to the application of this policy to revision of specifications.

2. The appeal asked for the IESG to clarify its DISCUSS
terminology. The IESG agrees that all DISCUSS positions are
blocking for as long as that position exists. But it is normal, and
indeed encouraged, to establish a dialog between the holder of the
DISCUSS, the document shepherd (see RFC 4858), the authors, the
working group, and the sponsoring AD. In some cases such dialog
results in clearing the DISCUSS without changes to the document, such
as when additional information convinces the AD that there actually
is no significant issue. In other cases the parties should come to an
understanding on how the DISCUSS can be resolved. In its May 2008
retreat, the IESG talked about the DISCUSS resolution process. One of
the items that was felt important in improving this process was that
the role of the shepherds should be more central than it currently is.

3. The appeal asked the IESG to "prohibit the use of a blocking
DISCUSS on a specification for any editorial or other non-technical
reason unless the requirement is clearly documented". The IESG
Statement "DISCUSS Criteria in IESG Review" is consistent in spirit
with this request, noting that stylistic issues and pedantic
corrections are not appropriate for a DISCUSS. (See http://
www.ietf.org/IESG/STATEMENTS/discuss-criteria.html) However, several
ADs felt that the issue was technical, not stylistic, thus the IESG
as a whole did not have consensus that the issue was non-technical in
this case. Further, the IESG notes that the recommendations
regarding use of non-example domains are documented in section 6 of
the ID-Checklist (version 1.7).

The IESG is granted certain authority by RFC 2026 and the published
BCP revisions of that RFC. The current IESG unanimously believes
that the IESG member(s) who entered a discuss position on this
document over this issue were acting within the authority granted
them by these rules. An appeal is not an appropriate mechanism to
revise the rules. Forming IETF consensus on a BCP that revises the
rules is the appropriate mechanism.

4. The appeal asked the IESG to "explicitly recognize that the
interests of the IETF and the Internet community are served by
encouraging the advancement of documents in maturity level on the
standards track.". The IESG explicitly recognizes this. However,
the IESG does not agree that the interests of the IETF and Internet
community are always served by prohibiting changes when documents
advance.

In addition to the remedies suggested in the appeal, the IESG is
considering other improvements in transparency of its actions. The
IESG continues to welcome feedback from the community on its
procedures. Comments may be directed to the [email-masked] or
[email-masked] mailing lists.

Date: Fri, 04 Jul 2008 01:12:06 -0700
To: John Leslie <[email-masked]>, Magnus Westerlund <[email-masked]>
From: SM <[email-masked]>
Subject: Re: Standardized tag (was: draft-klensin-rfc2821bis-10: ABNF discuss)
Cc: [email-masked]
Sender: [email-masked]

At 14:12 03-07-2008, John Leslie wrote:
>    At first blush, this seems sufficient if the ABNF says what we need
>(mostly how to parse the "tag").

 From RFC 2821:

   General-address-literal = Standardized-tag ":" 1*dcontent
   Standardized-tag = Ldh-str
             ; MUST be specified in a standards-track RFC
             ; and registered with IANA

   Let-dig = ALPHA / DIGIT
   Ldh-str = *( ALPHA / DIGIT / "-" ) Let-dig

In draft-10:

   General-address-literal  = Standardized-tag ":" 1*dcontent
   Standardized-tag  ; MUST be specified in a standards-track RFC
                     ; and registered with IANA

A few days ago, Frank suggested using:

   Standardized-tag = Let-dig [Ldh-str]

Or we could have:

  Standardized-tag = ALPHA *( ALPHA / DIGIT / "-" )

That should address the "how to parse" question.

>    Obviously, the answer is "maybe". ;^)

Some people are exasperated when they hear the "maybe" answer. :-)

>    Even purest garbage can be "valid". And, a lot of the time, we don't
>even need to process the "address" for the mail system to function. At
>first blush, I'd say it's sufficient to specify how to isolate the
>string which constitutes the "address". We can punt to other document(s)
>how to make sense of it.

Agreed.

>    One shouldn't need to "fully understand the rationale" in order to
>use this spec. But one _should_ find sufficient specification to know
>how to parse the constituent parts.

I agree that the specifications should be clear about the "how to 
parse".  I don't think we would do a good job of revising a 
specification like this one if we don't understand the rationale.  We 
may overlook some specific cases if we do not know why the previous 
WG and those before them took a decision.

At 01:30 01-07-2008, Magnus Westerlund wrote:
>However, my personal objection against this resolution of the error is
>that it leaves use with a undefined rule that is intended for future
>extensions. I see this as a interoperability issue as any parser
>implemented according to the rules in this document will have the
>potential to fail on any future tag. If one could clarify what possible
>syntax that the future tags could have then this would not be an issue.

I posted a suggestion for Standardized-tag.  Note that "there are 
many instances in which provisions in the text constrain or otherwise 
modify the syntax or semantics implied by the grammar".

Regards,
-sm 

Date: Thu, 03 Jul 2008 18:13:33 -0400
From: John C Klensin <[email-masked]>
To: John Leslie <[email-masked]>, SM <[email-masked]>
cc: [email-masked], Magnus Westerlund <[email-masked]>
Subject: Re: Standardized tag (was: draft-klensin-rfc2821bis-10: ABNF discuss)
Sender: [email-masked]

John,

Thanks for the reminder -- I just remembered why we concluded
that specifying the specific characters that might be used in
the tag was not necessary...

--On Thursday, 03 July, 2008 17:12 -0400 John Leslie
<[email-masked]> wrote:

>...
>>> Is there a any problem with defining a rule for what
>>> characters are allowed in future tag for identifying literal
>>> address formats that  is large enough to motivate living
>>> with the interoperability issue?
> 
>    I see no problem -- it's mostly a matter of finding a round
> tuit.
> 
>> A point raised during the discussion was whether something is
>> valid  because it is permitted by the syntax. 
> 
>    Obviously, the answer is "maybe". ;^)
> 
>    Even purest garbage can be "valid". And, a lot of the time,
> we don't even need to process the "address" for the mail
> system to function. At first blush, I'd say it's sufficient to
> specify how to isolate the string which constitutes the
> "address". We can punt to other document(s) how to make sense
> of it.

And, for that purpose, the rule is "[" ... "]" or, if one
prefers regular expressions (and thinks that backslash is the
escape), 
    \[.*\]

I still don't see the suggestion to restrict the tag to an
alphanumeric string starting with a letter as harmful and think
it would be a good idea.   2821 defined the tag as an "ldh-str"
and neither Tony nor I can reconstruct why we changed that -- in
retrospect, I suspect it just got lost during fine-tuning of
some other bit of metasyntax, which may actually reinforce the
view that such tampering is a bad idea.   As a minimal
alternative, one could be explicit that the tag not contain "]".
But, as far as interoperability problems are concerned, if
(deliberately not using ABNF to avoid getting sucked into
nit-picking)

    "[" digit ...
is an IPv4 address, and
    "[" "IPv6:" ...
is an IPv6 address, anything else is unacceptable until and
unless the standard is updated to reflect a different type of
literal.   Given the way that SMTP is specified, that means
there is no interoperability problem.   Address literals are
permitted in very few contexts (MAIL and RCPT commands and, with
some restrictions, EHLO and Trace fields).   If, e.g., "[xyz
..." were encountered in one of them, the result would be either
a syntax error or an address rejection, which are fine.  Whether
one could find the end of the tag, or even the end of the
address, in the command has to do with what text went into the
string associated with the reply code, but those strings are not
specified normatively in any event.  And trace fields are a
non-issue because there is an explicit warning against machine
interpretation of them.

Put differently, give the way SMTP and its syntax work, not
being able to correctly interpret whatever follows an
unintelligible address literal in a command line is really of no
particular consequence.

So, whatever the issue here and whatever tuning improvements
might be possible, I don't see an interoperability problem, even
a potential future one.

>> One might have to go back all the way to 821 to fully
>> understand the  rationale of what's in this draft.  And even
>> then, it's not that  obvious unless you talk to the people
>> who actually wrote the text.
> 
>    One shouldn't need to "fully understand the rationale" in
> order to use this spec. But one _should_ find sufficient
> specification to know how to parse the constituent parts.

Indeed.  But part of the question has been about the rationale
for the decisions.

     john

Date: Thu, 3 Jul 2008 17:12:16 -0400
From: John Leslie <[email-masked]>
To: SM <[email-masked]>
Cc: [email-masked]
Subject: Re: Standardized tag (was: draft-klensin-rfc2821bis-10: ABNF discuss)
Sender: [email-masked]

SM <[email-masked]> wrote:
> At 03:02 30-06-2008, Magnus Westerlund wrote:
> 
>> My discuss was started due to there was a rule which wasn't a rule, 
>> i.e. it didn't contain any elements. A clear syntax violation in 
>> ABNF. The rule in the issue was "Standardized-tag", this can be seen 
>> in version 10 of the draft in section 4.1.3.
> 
> Quoting the section from RFC 2821:
> 
>    "For IPv6 and other forms of addressing that might eventually be
>    standardized, the form consists of a standardized "tag" that
>    identifies the address syntax, a colon, and the address itself, in a
>    format specified as part of the IPv6 standards [17]."

   (now the first paragraph of 4.1.3)

> That might have to be changed as well.

   At first blush, this seems sufficient if the ABNF says what we need
(mostly how to parse the "tag").

>> Is there a any problem with defining a rule for what characters are
>> allowed in future tag for identifying literal address formats that 
>> is large enough to motivate living with the interoperability issue?

   I see no problem -- it's mostly a matter of finding a round tuit.

> A point raised during the discussion was whether something is valid 
> because it is permitted by the syntax. 

   Obviously, the answer is "maybe". ;^)

   Even purest garbage can be "valid". And, a lot of the time, we don't
even need to process the "address" for the mail system to function. At
first blush, I'd say it's sufficient to specify how to isolate the
string which constitutes the "address". We can punt to other document(s)
how to make sense of it.

> One might have to go back all the way to 821 to fully understand the 
> rationale of what's in this draft.  And even then, it's not that 
> obvious unless you talk to the people who actually wrote the text.

   One shouldn't need to "fully understand the rationale" in order to
use this spec. But one _should_ find sufficient specification to know
how to parse the constituent parts.

--
John Leslie <[email-masked]>

Date: Thu, 03 Jul 2008 15:12:37 -0400
From: John C Klensin <[email-masked]>
To: Magnus Westerlund <[email-masked]>
cc: [email-masked], IESG <[email-masked]>
Subject: Re: draft-klensin-rfc2821bis-10: ABNF discuss
Sender: [email-masked]

--On Thursday, 03 July, 2008 20:41 +0200 Magnus Westerlund
<[email-masked]> wrote:

>> The "not discussed at all" issue is one that could open up yet
>> another whole discussion of the information the tracker gives
>> to authors, editors, mailing lists, etc., and just what the
>> expectations are of both IESG members and document shepherds.
>> Since those topics are probably as controversial as the ones
>> associated with the pending appeal, I'm going to try to avoid
>> them here and hope that, if people do want to raise them, they
>> will at least change the subject line.
> 
> I only tried to express that if one tries to resolve a discuss
> one needs
> to involve the Discuss holding AD somehow. And I have
> personally not
> heard a single beep from anyone until a week ago about this
> part of the discuss.

Understood.

Part of the problem here is similar to one that the RFC Editor
discovered and fixed some years ago. 

Because "DISCUSS" can mean, among other things:

	* I want to think about this for a while
	
	* I want to discuss it with other IESG members and find
	out what they think
	
	* I am expecting further input from the developers of
	the document

it is a little bit too easy for the third case to get lost.  It
obviously did in this case, for which I apologize.  On the other
hand, it would be, IMO, very helpful if the IESG cleaned that
situation up.

I'll let others comment on the substance of your note -- you
have probably heard enough from me.

regards,
    john

Date: Thu, 03 Jul 2008 20:41:33 +0200
From: Magnus Westerlund <[email-masked]>
To: John C Klensin <[email-masked]>
CC: [email-masked], IESG <[email-masked]>
Subject: Re: draft-klensin-rfc2821bis-10: ABNF discuss
Sender: [email-masked]

John C Klensin skrev:
> A few personal comments in the hope of getting a discussion
> started and this resolved quickly...
> 
> --On Tuesday, 01 July, 2008 10:30 +0200 Magnus Westerlund
> <[email-masked]> wrote:
> 
>> (resending after having subscribed to ietf-smtp)
>>
>> Dear SMTP interested people,
>>
>> As some may have seen I held a discuss in two parts. The
>> second part was
>> unfortunately not discussed until last week at all with me. I
>> would like to get your input into this question.
> 
> The "not discussed at all" issue is one that could open up yet
> another whole discussion of the information the tracker gives to
> authors, editors, mailing lists, etc., and just what the
> expectations are of both IESG members and document shepherds.
> Since those topics are probably as controversial as the ones
> associated with the pending appeal, I'm going to try to avoid
> them here and hope that, if people do want to raise them, they
> will at least change the subject line.

I only tried to express that if one tries to resolve a discuss one needs
to involve the Discuss holding AD somehow. And I have personally not
heard a single beep from anyone until a week ago about this part of the
  discuss.

>  
>> My discuss was started due to there was a rule which wasn't a
>> rule, i.e.
>> it didn't contain any elements. A clear syntax violation in
>> ABNF. The
>> rule in the issue was "Standardized-tag", this can be seen in
>> version 10 of the draft in section 4.1.3.
> 
>> I have received a proposal from John Klensin that would make
>> section
>> 4.1.3 read as below. The change is in the rule for
>> General-address-literal and removal of Standardized-tag as a
>> defined rule.
>>
>>     General-address-literal  = <Standardized-tag> ":"
>> 1*dcontent
>>          ; Standardized-tag MUST be specified in a
>>          ; standards-track RFC and registered with IANA
>>
>>
>> However, my personal objection against this resolution of the
>> error is
>> that it leaves use with a undefined rule that is intended for
>> future
>> extensions. I see this as a interoperability issue as any
>> parser
>> implemented according to the rules in this document will have
>> the
>> potential to fail on any future tag. If one could clarify what
>> possible
>> syntax that the future tags could have then this would not be
>> an issue.
>> I fully understand that the old implementation will still not
>> understand
>> the content, however, by not having the parsing fail an
>> implementation
>> can at least take the correct action. Thus I wonder why one
>> can't specify it like:
>>
>> Standardized-tag = ehlo-keyword
> 
>>From my point of view, it certainly could.  If I recall, Tony
> and the list discussions gave me three options for solving this.
> I was told to pick one.  I did.  My main reason for doing so was
> to minimize the number of placeholder productions we needed.
> 
> I can certainly see Magnus's point that limiting the syntax for
> the tag lexically would be an advantage.  My recollection is
> that we decided to not do that during the DRUMS discussions, but
> I no longer remember why.  
> 
> But, given the controversy about what I believe are stylistic
> issues, I'm not willing to make any further changes in this
> document without list review because some AD has a preference
> for a different approach or language.

And so far I haven't seen it as stylistic issues. I also think it is
correct that you are not doing changes that you are not comfortable
without discussing them with the interested group.

> 
>> Any rule that defines what combination of character are
>> allowed in any
>> future tag would be fine as a solution to this issue from my
>> perspective.
>  
>> Is there a any problem with defining a rule for what
>> characters is
>> allowed in future tag for identifying literal address formats
>> that is
>> large enough to motivate living with the interoperability
>> issue?
> 
> The question, for me, has never been about "is there any problem
> with doing it <this way> rather than the way the group decided
> to do it?" (even if the group decision was a trust a lazy and
> incompetent editor).  The question is whether this approach
> provides enough of an improvement to make a change that might
> risk unintended consequences.     In this particular area, my
> own, personal, guess is "probably it is".  But that is, IMO, up
> to the list to decide.

Maybe poor choice of words from my side. The fundamental question I like
to understand where people stand on the matter and if there is need for 
corrections if they are reasonable.

Cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Färögatan 6                | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

Date: Tue, 01 Jul 2008 17:05:28 -0700
To: [email-masked]
From: SM <[email-masked]>
Subject: Standardized tag (was: draft-klensin-rfc2821bis-10: ABNF discuss)
Sender: [email-masked]

At 03:02 30-06-2008, Magnus Westerlund wrote:
>As some may have seen I held a discuss in two parts. The second part 
>was unfortunately not discussed until last week at all with me. I 
>would like to get your input into this question.
>
>My discuss was started due to there was a rule which wasn't a rule, 
>i.e. it didn't contain any elements. A clear syntax violation in 
>ABNF. The rule in the issue was "Standardized-tag", this can be seen 
>in version 10 of the draft in section 4.1.3.

The question was raised by Frank in 2007.

Quoting the section from RFC 2821:

    "For IPv6 and other forms of addressing that might eventually be
    standardized, the form consists of a standardized "tag" that
    identifies the address syntax, a colon, and the address itself, in a
    format specified as part of the IPv6 standards [17]."

That might have to be changed as well.

>Is there a any problem with defining a rule for what characters is 
>allowed in future tag for identifying literal address formats that 
>is large enough to motivate living with the interoperability issue?

A point raised during the discussion was whether something is valid 
because it is permitted by the syntax.  Some future document might 
have a case where IPv6 addresses with a scope identifier are covered 
in SMTP.  That's where the standardized tag comes in.  It can also 
apply to other forms of addressing.

One might have to go back all the way to 821 to fully understand the 
rationale of what's in this draft.  And even then, it's not that 
obvious unless you talk to the people who actually wrote the text.

Regards,
-sm 

Date: Tue, 01 Jul 2008 14:22:14 -0400
From: John C Klensin <[email-masked]>
To: Magnus Westerlund <[email-masked]>, [email-masked]
cc: IESG <[email-masked]>
Subject: Re: draft-klensin-rfc2821bis-10: ABNF discuss
Sender: [email-masked]

A few personal comments in the hope of getting a discussion
started and this resolved quickly...

--On Tuesday, 01 July, 2008 10:30 +0200 Magnus Westerlund
<[email-masked]> wrote:

> (resending after having subscribed to ietf-smtp)
> 
> Dear SMTP interested people,
> 
> As some may have seen I held a discuss in two parts. The
> second part was
> unfortunately not discussed until last week at all with me. I
> would like to get your input into this question.

The "not discussed at all" issue is one that could open up yet
another whole discussion of the information the tracker gives to
authors, editors, mailing lists, etc., and just what the
expectations are of both IESG members and document shepherds.
Since those topics are probably as controversial as the ones
associated with the pending appeal, I'm going to try to avoid
them here and hope that, if people do want to raise them, they
will at least change the subject line.
 
> My discuss was started due to there was a rule which wasn't a
> rule, i.e.
> it didn't contain any elements. A clear syntax violation in
> ABNF. The
> rule in the issue was "Standardized-tag", this can be seen in
> version 10 of the draft in section 4.1.3.

> I have received a proposal from John Klensin that would make
> section
> 4.1.3 read as below. The change is in the rule for
> General-address-literal and removal of Standardized-tag as a
> defined rule.
> 
>     General-address-literal  = <Standardized-tag> ":"
> 1*dcontent
>          ; Standardized-tag MUST be specified in a
>          ; standards-track RFC and registered with IANA
> 
> 
> However, my personal objection against this resolution of the
> error is
> that it leaves use with a undefined rule that is intended for
> future
> extensions. I see this as a interoperability issue as any
> parser
> implemented according to the rules in this document will have
> the
> potential to fail on any future tag. If one could clarify what
> possible
> syntax that the future tags could have then this would not be
> an issue.
> I fully understand that the old implementation will still not
> understand
> the content, however, by not having the parsing fail an
> implementation
> can at least take the correct action. Thus I wonder why one
> can't specify it like:
> 
> Standardized-tag = ehlo-keyword

>From my point of view, it certainly could.  If I recall, Tony
and the list discussions gave me three options for solving this.
I was told to pick one.  I did.  My main reason for doing so was
to minimize the number of placeholder productions we needed.

I can certainly see Magnus's point that limiting the syntax for
the tag lexically would be an advantage.  My recollection is
that we decided to not do that during the DRUMS discussions, but
I no longer remember why.  

But, given the controversy about what I believe are stylistic
issues, I'm not willing to make any further changes in this
document without list review because some AD has a preference
for a different approach or language.

> Any rule that defines what combination of character are
> allowed in any
> future tag would be fine as a solution to this issue from my
> perspective.
 
> Is there a any problem with defining a rule for what
> characters is
> allowed in future tag for identifying literal address formats
> that is
> large enough to motivate living with the interoperability
> issue?

The question, for me, has never been about "is there any problem
with doing it <this way> rather than the way the group decided
to do it?" (even if the group decision was a trust a lazy and
incompetent editor).  The question is whether this approach
provides enough of an improvement to make a change that might
risk unintended consequences.     In this particular area, my
own, personal, guess is "probably it is".  But that is, IMO, up
to the list to decide.

best,
   john

Date: Tue, 01 Jul 2008 10:30:48 +0200
From: Magnus Westerlund <[email-masked]>
To: [email-masked], John C Klensin <[email-masked]>
CC: IESG <[email-masked]>
Subject: draft-klensin-rfc2821bis-10: ABNF discuss
Sender: [email-masked]

(resending after having subscribed to ietf-smtp)

Dear SMTP interested people,

As some may have seen I held a discuss in two parts. The second part was
unfortunately not discussed until last week at all with me. I would like
to get your input into this question.

My discuss was started due to there was a rule which wasn't a rule, i.e.
it didn't contain any elements. A clear syntax violation in ABNF. The
rule in the issue was "Standardized-tag", this can be seen in version 10
of the draft in section 4.1.3.

I have received a proposal from John Klensin that would make section
4.1.3 read as below. The change is in the rule for
General-address-literal and removal of Standardized-tag as a defined rule.

    General-address-literal  = <Standardized-tag> ":" 1*dcontent
         ; Standardized-tag MUST be specified in a
         ; standards-track RFC and registered with IANA

However, my personal objection against this resolution of the error is
that it leaves use with a undefined rule that is intended for future
extensions. I see this as a interoperability issue as any parser
implemented according to the rules in this document will have the
potential to fail on any future tag. If one could clarify what possible
syntax that the future tags could have then this would not be an issue.
I fully understand that the old implementation will still not understand
the content, however, by not having the parsing fail an implementation
can at least take the correct action. Thus I wonder why one can't
specify it like:

Standardized-tag = ehlo-keyword

Any rule that defines what combination of character are allowed in any
future tag would be fine as a solution to this issue from my perspective.

Is there a any problem with defining a rule for what characters is
allowed in future tag for identifying literal address formats that is
large enough to motivate living with the interoperability issue?

Cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Färögatan 6                | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------