Subject: Re: draft-klensin-rfc2821bis-10: ABNF discuss
From: "Frank Ellermann" <[email-masked]>
To: [email-masked]
Date: Mon, 30 Jun 2008 14:09:19 +0200
List-Id: <ietf-smtp.imc.org>

Magnus Westerlund wrote:

> 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.

JFTR, <dcontent> is also undefined (in 2822upd).

> Thus I wonder why one can't specify it like:
> Standardized-tag = ehlo-keyword

You could also say <subdomain>, same idea never ending with 
a hyphen.  And because the concept has nothing to do with a
<subdomain> or <ehlo-keyword> you could expand it:

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

> Is there a any problem with defining a rule for what characters
> is allowed in future tag for identifying literal address 
> formats

It's hard to talk about potential problems with hypothetical
IPvFuture versions, but picking "IPv6" would be unwise... :-)  

 Frank

Date: Mon, 30 Jun 2008 12:02:41 +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]

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]
----------------------------------------------------------------------

Date: Mon, 30 Jun 2008 08:48:14 +0200
From: "'Stephane Bortzmeyer'" <[email-masked]>
To: [email-masked]
Subject: An interesting proposal for SMTP
Sender: [email-masked]

--tjCHc7DPkfUGtrlw
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

:-)

--tjCHc7DPkfUGtrlw
Content-Type: message/rfc822
Content-Disposition: inline

Resent-From: [email-masked]
Resent-Date: Mon, 30 Jun 2008 08:35:48 +0200
Resent-Message-ID: <[email-masked]>
Resent-To: [email-masked]
Old-From: "Tuc at T-B-O-H.NET" <[email-masked]>
Old-Subject: Re: ICANN opens up Pandora's Box of new TLDs
To: [email-masked]
Date: Sun, 29 Jun 2008 17:55:53 -0400 (EDT)
Cc: [email-masked] ('Stephane Bortzmeyer'), [email-masked]
Return-Receipt-To: <[email-masked]>
Disposition-Notification-To: <[email-masked]>
Old-Subject: Re: ICANN opens up Pandora's Box of new TLDs
Old-From: "Tuc at T-B-O-H.NET" <[email-masked]>
Subject: Re: ICANN opens up Pandora's Box of new TLDs
From: "Tuc at T-B-O-H.NET" <[email-masked]>

> 
> You do have a choice if you're not concerned about the deliverability of
> your e-mail.  Remember, the Internet remains a group of service
> providers/organizations/subscribers that voluntarily work together and can
> choose what goes in or out.  And so if they decide not to receive traffic
> from you, for any reason at all, there's no legal requirement.  If they
> require that all e-mail servers that want to send e-mail to them have rDNS
> entries then persons who want to deliver e-mail to that entity need to
> comply.
> 
> Frank
> 
	So can I change my SMTP greeting to be :

220-host.example.com SMTP
220-Company agrees to the following rate chart to accept mail :
220-EHLO - $5.00 
220-HELO - $2.50
220-MAIL FROM:<*> - Free
220-RCPT TO:<*> - 1-5/$4.00 , 6-10/$6.00, 11-15/$8.00, 15+/$10.00
220-DATA: $.01 per character until final ".<CR>"
220-Delivery confirmation (Return-Receipt-To, X-Confirm-Reading-To, Disposition-Notification-To) - $1.50
220 Sending HELO/EHLO constitutes acceptance of this agreement

			Thanks, Tuc/TBOH

--tjCHc7DPkfUGtrlw--

Date: Mon, 23 Jun 2008 14:25:05 +0200
From: Francesco Gennai <[email-masked]>
Subject: Re: name and filename parameters
To: [email-masked]
Sender: [email-masked]

Thank you Ned and Keith for the clear description.

Francesco

> > Question about composing a MIME part where I would suggest
> > also the file name.

> > Question:
> > In the case that I would suggest a file name to the remote
> > MIME client could I use only the name parameter of the content-type
> > or MUST I add the content-disposition header with the filename parameter?

> The situation is as follows. The original MIME specifications only provided a
> means to associated filenames with application/octet-stream parts. This was
> done through the use of a name= parameter on the content-type. The theory here
> was that filenames were mostly used for type information and therefore did not
> need to be present in most cases.

> This was a mistake on our part. It seems a lot of people really like to
> associate file  *names* with parts. So, when we didn't initially provide a
> standard means to do this, people just started using name= parameters for all
> sorts of different types.

> Even worse was the presence of some agents that, in flagrant defiance of
> MIME requirements, looked at file names for type information and ignored
> the media type completely.

> The specification of content-disposition attempted to provide a more general
> means of providing file name information by defining a filename parameter as
> part of the  content-disposition field. Unfortunately in the process another
> mistake was made: No name was defined for the nominal "default" disposition
> that corresponds to no content-disosition being present. The result is that the
> now-standardized mechanism for associating a filename with a part cannot be
> used without in some cases change the part semantics, since no
> content-disposition isn't equivalent to inline , attachment or any other
> disposition value.

> So what are the operational implications of all this? There are several. One is
> that there are agents that only look at the name= parameter for filenames, and
> other agents that only look at filename=. This in turn has led in some cases to
> attempts to bridge the gap by in effect copying the name= parameter value to
> the filename= parameter value, either implicitly or explicitly. And that
> behavior has the side effect that now the presence of a name= parameter can
> effectively force a content-disposition setting onto a part.

> So what should a generating agent do? The first thing to note is that
> attempting to cater to any remaining agents that preferentially or exclusively
> look to filenames for type information is an exercise in futility: Such agents
> are deeply broken along several axes, the most important of which is security.
> "Shoot on sight" is the only realistic answer here.

> Beyond that I advocate restraint: If there's a way in your application to only
> include filename information when it is absolutely necessary, use it. At a
> minimum it will save embarassment when that proposal you just sent out doesn't
> retain the filename "boondoggle.doc".

> Finally, if you have to include filename information, either put it in a
> filename= parameter or both a filename= and name= parameter. Never ever use
> just a name= parameter because that opens you up to gratuitous interpretation
> of the part using some disposition value you didn't intend. (I note in passing
> that this is what Thunderbird now dows, with the added nuance of using
> nonstandard RFC 2047 encoding for the name= paramter and standard RFC 2231
> encoding for the filename= parameter.)

> > My doubt come also from the following sentence in RFC3851
> > (Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1
> >                          Message Specification):

> > .. ..... .
> > 3.2.1.  The name and filename Parameters

> >    For the application/pkcs7-mime, sending agents SHOULD emit the
> >    optional "name" parameter to the Content-Type field for compatibility
> >    with older systems.  Sending agents SHOULD also emit the optional
> >    Content-Disposition field [CONTDISP] with the "filename" parameter.
> >    If a sending agent emits the above parameters, the value of the
> >    parameters SHOULD be a file name with the appropriate extension:
> >  .... ..... ...

> > where a system using only the name parameter is considered an "old system".
> > So, I don't understand if "old system" is related to some old S/MIME
> > system, or to a generic old MIME system....

> Unfortunately, given operational realities I would have to characterize this as
> somewhere between suboptimal and broken.

> 				Ned

Date: Sat, 21 Jun 2008 14:39:07 -0700 (PDT)
From: [email-masked]
Subject: Re: name and filename parameters
To: Francesco Gennai <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

> Question about composing a MIME part where I would suggest
> also the file name.

> Question:
> In the case that I would suggest a file name to the remote
> MIME client could I use only the name parameter of the content-type
> or MUST I add the content-disposition header with the filename parameter?

The situation is as follows. The original MIME specifications only provided a
means to associated filenames with application/octet-stream parts. This was
done through the use of a name= parameter on the content-type. The theory here
was that filenames were mostly used for type information and therefore did not
need to be present in most cases.

This was a mistake on our part. It seems a lot of people really like to
associate file  *names* with parts. So, when we didn't initially provide a
standard means to do this, people just started using name= parameters for all
sorts of different types.

Even worse was the presence of some agents that, in flagrant defiance of
MIME requirements, looked at file names for type information and ignored
the media type completely.

The specification of content-disposition attempted to provide a more general
means of providing file name information by defining a filename parameter as
part of the  content-disposition field. Unfortunately in the process another
mistake was made: No name was defined for the nominal "default" disposition
that corresponds to no content-disosition being present. The result is that the
now-standardized mechanism for associating a filename with a part cannot be
used without in some cases change the part semantics, since no
content-disposition isn't equivalent to inline , attachment or any other
disposition value.

So what are the operational implications of all this? There are several. One is
that there are agents that only look at the name= parameter for filenames, and
other agents that only look at filename=. This in turn has led in some cases to
attempts to bridge the gap by in effect copying the name= parameter value to
the filename= parameter value, either implicitly or explicitly. And that
behavior has the side effect that now the presence of a name= parameter can
effectively force a content-disposition setting onto a part.

So what should a generating agent do? The first thing to note is that
attempting to cater to any remaining agents that preferentially or exclusively
look to filenames for type information is an exercise in futility: Such agents
are deeply broken along several axes, the most important of which is security.
"Shoot on sight" is the only realistic answer here.

Beyond that I advocate restraint: If there's a way in your application to only
include filename information when it is absolutely necessary, use it. At a
minimum it will save embarassment when that proposal you just sent out doesn't
retain the filename "boondoggle.doc".

Finally, if you have to include filename information, either put it in a
filename= parameter or both a filename= and name= parameter. Never ever use
just a name= parameter because that opens you up to gratuitous interpretation
of the part using some disposition value you didn't intend. (I note in passing
that this is what Thunderbird now dows, with the added nuance of using
nonstandard RFC 2047 encoding for the name= paramter and standard RFC 2231
encoding for the filename= parameter.)

> My doubt come also from the following sentence in RFC3851
> (Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1
>                          Message Specification):

> .. ..... .
> 3.2.1.  The name and filename Parameters

>    For the application/pkcs7-mime, sending agents SHOULD emit the
>    optional "name" parameter to the Content-Type field for compatibility
>    with older systems.  Sending agents SHOULD also emit the optional
>    Content-Disposition field [CONTDISP] with the "filename" parameter.
>    If a sending agent emits the above parameters, the value of the
>    parameters SHOULD be a file name with the appropriate extension:
>  .... ..... ...

> where a system using only the name parameter is considered an "old system".
> So, I don't understand if "old system" is related to some old S/MIME
> system, or to a generic old MIME system....

Unfortunately, given operational realities I would have to characterize this as
somewhere between suboptimal and broken.

				Ned

Date: Sat, 21 Jun 2008 10:08:16 -0400
From: Keith Moore <[email-masked]>
To: Francesco Gennai <[email-masked]>
CC: [email-masked]
Subject: Re: name and filename parameters
Sender: [email-masked]

as far as I know, the name parameter is only defined for the 
application/octet-stream content-type.  content-disposition is the 
standard way to associate a filename with a MIME body part.

many user agents have supplied a name parameter with other 
content-types, but this is not standard and never has been. 
content-disposition was defined some time after the original MIME 
specifications that defined the name parameter for 
application/octet-stream, so many user agents borrowed the name 
parameter for use with other content-types.

RFC 3851 appears to be recommending nonstandard behavior, though it is 
probably mostly harmless.

Keith

Francesco Gennai wrote:
> Question about composing a MIME part where I would suggest
> also the file name.
> 
> Question:
> In the case that I would suggest a file name to the remote
> MIME client could I use only the name parameter of the content-type
> or MUST I add the content-disposition header with the filename parameter?
> 
> My doubt come also from the following sentence in RFC3851
> (Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1
>                          Message Specification):
> 
> .. ..... .
> 3.2.1.  The name and filename Parameters
> 
>    For the application/pkcs7-mime, sending agents SHOULD emit the
>    optional "name" parameter to the Content-Type field for compatibility
>    with older systems.  Sending agents SHOULD also emit the optional
>    Content-Disposition field [CONTDISP] with the "filename" parameter.
>    If a sending agent emits the above parameters, the value of the
>    parameters SHOULD be a file name with the appropriate extension:
>  .... ..... ... 
> 
> where a system using only the name parameter is considered an "old system".
> So, I don't understand if "old system" is related to some old S/MIME
> system, or to a generic old MIME system....
> 
> Francesco
> 

Date: Sat, 21 Jun 2008 14:52:38 +0200
From: Francesco Gennai <[email-masked]>
Subject: name and filename parameters
To: [email-masked]
Sender: [email-masked]

Question about composing a MIME part where I would suggest
also the file name.

Question:
In the case that I would suggest a file name to the remote
MIME client could I use only the name parameter of the content-type
or MUST I add the content-disposition header with the filename parameter?

My doubt come also from the following sentence in RFC3851
(Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1
                         Message Specification):

.. ..... .
3.2.1.  The name and filename Parameters

   For the application/pkcs7-mime, sending agents SHOULD emit the
   optional "name" parameter to the Content-Type field for compatibility
   with older systems.  Sending agents SHOULD also emit the optional
   Content-Disposition field [CONTDISP] with the "filename" parameter.
   If a sending agent emits the above parameters, the value of the
   parameters SHOULD be a file name with the appropriate extension:
 .... ..... ... 

where a system using only the name parameter is considered an "old system".
So, I don't understand if "old system" is related to some old S/MIME
system, or to a generic old MIME system....

Francesco

Date: Thu, 12 Jun 2008 13:33:52 -0400
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To: Pete Resnick <[email-masked]>
CC: Arnt Gulbrandsen <[email-masked]>, [email-masked]
Subject: Re: Handling of Missing Required Fields
Sender: [email-masked]

Pete Resnick wrote:
> 
> On 6/12/08 at 4:05 PM +0200, Arnt Gulbrandsen wrote:
> 
>> Pete Resnick wrote:
>>> You will note that 2822 requires you to accept messages with *none* 
>>> of these fields. (See section 4.)
>>
>> I don't see that. Elaborate?
>>
>> I do see that 2822 section 4 requires me to accept lots of additional 
>> "syntax forms", but I do not see where it requires me to accept an 
>> empty string and interpret that as an email message.
> 
> I guess I will back off of that statement: I had always assumed that 
> since section 4.5 relax the restriction on multiple occurrences of 
> fields, it also relaxed the minimums. But it never says that, and unlike 
> section 3.6, it does not add a new table and it does not make any 
> statement about which (if any) fields are required.
> 
> That said, I will stick by the statement that 822 (and 2822 for that 
> matter) make no claims about what a receiver ought to do when it 
> receives a message without the minimum required fields.

Well, there is an implied semantic with the term "minimum requirement".

But the issue is not when there are no x822 header - *none*.  That's 
simple.  Local systems always handle this one way or another i.e. smtp 
servers acting a "posting" device.

The issue in production/practice is two folds:

    - incomplete, and
    - supporting 2822 vs 822

and I guess I can add the "renewed" focus and attention towards proper 
compliance in an era of high abuse/spam.

In addition, in our case:

    - Filling in the missing header, versus
    - Writing a new required set of header.

Anyway, I missed 2821 6.3 (thanks SM) and it covers everything I was 
thinking, the concerns, the issues, the realities.

-- 
Sincerely

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

 
 <p06250104c474b6b61ecb@[75.145.176.242]> <48512D2 [email-masked]>|User-Agent: Eudora 6.2.5b1(Macint osh)|Date: Thu, 12 Jun 2008 09:08:04 -0500 |To: Arnt Gulbrandsen <[email-masked]>|From: Pete  Resnick <[email-masked]>|Subject: Re: Han dling of Missing Required Fields|Cc: ietf-smtp@ imc.org, Hector Santos <[email-masked]> |Content-Type: text/plain; charset="us-ascii"  ; format="flowed"|X-IronPort-AV: E=McAfee;i ="5200,2160,5315"; a="3698871"; bh=9I6VTCbVjkJgPfklqGnoiOgsIo1iC3WH56xBE9HDW4s=; b=M6u+b/hFv3RBUQpTxEBqcc305OA2yuVSNvY+ChN65m3HrgAOhHtrsOfu 3D8F5Ptj4LqnjnrxbXEXKLi6k+OSY6+cr2BtuCNYKbZOFBx8J9Z0SLdsL Ka+zs+OHzqE3bsQi8XjD62ULK+2rtP389+/YO5fc6QxxtAHz4TZfAIlED Q=;
Date: Thu, 12 Jun 2008 09:08:04 -0500
To: Arnt Gulbrandsen <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: Re: Handling of Missing Required Fields
Cc: [email-masked], Hector Santos <[email-masked]>
Sender: [email-masked]

On 6/12/08 at 4:05 PM +0200, Arnt Gulbrandsen wrote:

>Pete Resnick wrote:
>>You will note that 2822 requires you to accept messages with *none* 
>>of these fields. (See section 4.)
>
>I don't see that. Elaborate?
>
>I do see that 2822 section 4 requires me to accept lots of 
>additional "syntax forms", but I do not see where it requires me to 
>accept an empty string and interpret that as an email message.

I guess I will back off of that statement: I had always assumed that 
since section 4.5 relax the restriction on multiple occurrences of 
fields, it also relaxed the minimums. But it never says that, and 
unlike section 3.6, it does not add a new table and it does not make 
any statement about which (if any) fields are required.

That said, I will stick by the statement that 822 (and 2822 for that 
matter) make no claims about what a receiver ought to do when it 
receives a message without the minimum required fields.

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

Date: Thu, 12 Jun 2008 16:05:27 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Cc: Pete Resnick <[email-masked]>, Hector Santos <[email-masked]>
Subject: Re: Handling of Missing Required Fields
Sender: [email-masked]

Pete Resnick wrote:
> You will note that 2822 requires you to accept messages with *none* of 
> these fields. (See section 4.)

I don't see that. Elaborate?

I do see that 2822 section 4 requires me to accept lots of additional 
"syntax forms", but I do not see where it requires me to accept an empty 
string and interpret that as an email message.

Arnt

Date: Tue, 10 Jun 2008 18:01:32 -0500
To: Hector Santos <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: Re: Handling of Missing Required Fields
Cc: [email-masked]
Sender: [email-masked]

On 6/9/08 at 6:00 PM -0400, Hector Santos wrote:

>Neither RFC x822, x8221 goes into the guidelines of how to handle 
>"missing fields" but do indicate the minimum requirements:
>
>   822:
>
>      Date:
>      From:
>      To:  (or bcc:, doesn't say cc:?)
>
>  2822:  relaxes To:
>
>      Date:
>      From:

You will note that 2822 requires you to accept messages with *none* 
of these fields. (See section 4.) It only requires you to *send* 
messages with these fields (section 3). Now, you may decide that 
those restrictions are too lax and do something interesting in 
response to messages lacking any particular fields, but that's a 
local decision and not endorsed by 2822.

822 makes no claims about what a receiver ought to do when it 
receives a message without the minimum required fields.

For the record.

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

Date: Tue, 10 Jun 2008 11:54:33 -0700
To: [email-masked]
From: SM <[email-masked]>
Subject: Re: Handling of Missing Required Fields
Sender: [email-masked]

Hi Hector,
At 15:00 09-06-2008, Hector Santos wrote:
>We are updating our mail system, one which a rich history of uucp, 
>822, 821 semantics and within the last 3-4 years mixed in 2822, 2821 semantics.
>
>We few recent reports highlighted or open up the need to rethink how 
>some the handling of missing fields is done.
>
>I would like to get the feel or BCP for the following:
>
>   - missing To: fields
>   - missing Date: fields
>   - missing From: fields
>   - 822 vs 2822
>   - Local vs Remote Routing (i.e, Passthrus)

I'll use draft-resnick-2822upd as the reference as that's what most 
of the participants agreed upon.  Section 3.6 defines two fields, 
i.e. the Date: and From: which should be included.

>To illustrate the issue, we had a customer who was wondering why our 
>server reacted differently to what he thought was the same message 
>received two different ways. But in fact:
>
>    a) The original message had a missing date:
>    b) Route #1, added a date before it was sent to his server
>    c) Route #2, did not add a date before it was sent to his server
>
>I'm still trying to figure out how he got this to happen (the 
>original message took two different routes), but the with the route 
>taken not having a date, it was flagged on our system.

Some MTAs "fix" the headers.

>I have no problem with local created mail for outbound corrective 
>actions (or PORT 587), but I have a problem with correction of 
>incoming remote mail, especially if its anonymous.
>
>But thats a specific issue, and I would like to hear what would be a 
>general case ideals for these type of things.

Section 6.3 of RFC 2821 talks about "Compensating for Irregularities".

>Neither RFC x822, x8221 goes into the guidelines of how to handle 
>"missing fields" but do indicate the minimum requirements:
>
>   822:
>
>      Date:
>      From:
>      To:  (or bcc:, doesn't say cc:?)
>
>  2822:  relaxes To:
>
>      Date:
>      From:
>
>Our history of enforcing this was:
>
>  198?-1998   ~822 rule    -> Date: && To:
>  1998-2003   ~822 rule    -> To: && (Date: || Received: || From:)
>  2003-now    2822 option: -> Date: && From:
>
>In the early 90, the mail system was still modeled over a UUCP 
>system, and the router had only a Date: and To: requirement.  I 
>guess because the "From " or the Return-Path was part of the 
>received email or file it was handling.
>
>I did not take over the engineering until 1998, but it was one of 
>the first thing we changed, and at best I can recall to reduce a 
>high rate of missing date: errors, was to relaxed it to a rule:
>
>        To: && (Date: || Received: || From:)
>
>this worked very well.

I've come across cases where any one or more of these fields missing.

>In our on-going efforts to support 2822/2821, we few years back we 
>added the 2822 support to relaxed the to: requirement.  But with 
>this 2822 rule enabled, we introduced again the Date: and From: requirement.
>
>Probably, our mistake, again in an effort to support 2822, we made 
>this option default, so this is why we are getting more reports.   I 
>am thinking of turning off the default to stop surprising customers.
>
>I guess what I would like to hear is how systems should deal with all this.

If you look at it from a MUA perspective (receiver), a missing From: 
or Date: affects the rendering of that information.  From a sender's 
perspective, missing some of these fields would get the message 
flagged by mail filters.  That can be addressed during message 
submission.  Please see the Section 3.6 of RFC 2821 if the MTA is 
acting as a relay.  It has a "MUST NOT" for applying changes.

The general idea is that the less information you have about the 
client, the less likely the changes will be correct.  For example, 
the Date: conveys more information than a simple date field and a 
receiver cannot synthesize that.

Regards,
-sm

Date: Mon, 09 Jun 2008 18:00:36 -0400
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To:  [email-masked]
Subject: Handling of Missing Required Fields
Sender: [email-masked]

Folks,

We are updating our mail system, one which a rich history of uucp, 822, 
821 semantics and within the last 3-4 years mixed in 2822, 2821 semantics.

We few recent reports highlighted or open up the need to rethink how 
some the handling of missing fields is done.

I would like to get the feel or BCP for the following:

   - missing To: fields
   - missing Date: fields
   - missing From: fields
   - 822 vs 2822
   - Local vs Remote Routing (i.e, Passthrus)

To illustrate the issue, we had a customer who was wondering why our 
server reacted differently to what he thought was the same message 
received two different ways. But in fact:

    a) The original message had a missing date:
    b) Route #1, added a date before it was sent to his server
    c) Route #2, did not add a date before it was sent to his server

I'm still trying to figure out how he got this to happen (the original 
message took two different routes), but the with the route taken not 
having a date, it was flagged on our system.

I have no problem with local created mail for outbound corrective 
actions (or PORT 587), but I have a problem with correction of incoming 
remote mail, especially if its anonymous.

But thats a specific issue, and I would like to hear what would be a 
general case ideals for these type of things.

Neither RFC x822, x8221 goes into the guidelines of how to handle 
"missing fields" but do indicate the minimum requirements:

   822:

      Date:
      From:
      To:  (or bcc:, doesn't say cc:?)

  2822:  relaxes To:

      Date:
      From:

Our history of enforcing this was:

  198?-1998   ~822 rule    -> Date: && To:
  1998-2003   ~822 rule    -> To: && (Date: || Received: || From:)
  2003-now    2822 option: -> Date: && From:

In the early 90, the mail system was still modeled over a UUCP system, 
and the router had only a Date: and To: requirement.  I guess because 
the "From " or the Return-Path was part of the received email or file it 
was handling.

I did not take over the engineering until 1998, but it was one of the 
first thing we changed, and at best I can recall to reduce a high rate 
of missing date: errors, was to relaxed it to a rule:

        To: && (Date: || Received: || From:)

this worked very well.

In our on-going efforts to support 2822/2821, we few years back we added 
the 2822 support to relaxed the to: requirement.  But with this 2822 
rule enabled, we introduced again the Date: and From: requirement.

Probably, our mistake, again in an effort to support 2822, we made this 
option default, so this is why we are getting more reports.   I am 
thinking of turning off the default to stop surprising customers.

I guess what I would like to hear is how systems should deal with all 
this.

Any feedback would be appreciated.

-- 
Sincerely

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

Cc: Pete Resnick <[email-masked]>, Keith Moore <[email-masked]>, John Leslie <[email-masked]>, [email-masked], Tony Hansen <[email-masked]>
From: Lisa Dusseault <[email-masked]>
To: John C Klensin <[email-masked]>
Subject: Re: IESG approval status of  rfc2821bis
Date: Mon, 9 Jun 2008 13:16:35 -0700
Sender: [email-masked]

I've never seen a bug-tracking system in a development team, that  
didn't constrain or encourage people into different and sometimes  
difficult behavior, particularly when "Design Change Requests" or  
"enhancements" or things that might not totally be bugs were  
concerned.  IOW,  I don't consider the problem of fitting human  
behavior in an issue tracking system to be solvable at any cost we're  
willing to pay.

For that matter, the technical choices made in email constrains people  
or changes their behavior in ways we hardly even notice any more.   
Look at me replying all here...

Lisa

On Jun 9, 2008, at 12:05 PM, John C Klensin wrote:

> Lisa,
>
> --On Monday, 09 June, 2008 10:45 -0700 Lisa Dusseault
> <[email-masked]> wrote:
>
>> ...
>> The way the IETF Issue tracker works is that if you enter a
>> COMMENT, nobody can track whether the issue is still open, has
>> been resolved etc.  But a DISCUSS is trackable, and in this
>> case trackable = blocking.
>> ...
>
> Just one observation about this, which is that the community has
> invested huge levels of resources in administrative
> restructurings, new organizations and management structures, new
> secretariats, and the like over the last few years.  I say
> "huge" because the level of investment has been sufficient to
> disrupt the main work of the IETF on a number of occasions
> during the various transitions, which is a high price to pay --
> probably worth it if we get good results and ROI, but
> nonetheless a high price.
>
> On the other hand, if, after all of that, the IESG is being
> constrained to do unreasonable things by the tools it is using
> and how those tools are organized, one has to wonder whether all
> of that effort and resource investment has left us no better off
> than we were before in the areas that really count.
>
> Just a thought...
>
>    john
>

Date: Mon, 09 Jun 2008 15:29:43 -0400
From: Keith Moore <[email-masked]>
To: John C Klensin <[email-masked]>
CC: Lisa Dusseault <[email-masked]>, Pete Resnick <[email-masked]>, John Leslie <[email-masked]>, [email-masked], Tony Hansen <[email-masked]>
Subject: Re: IESG approval status of  rfc2821bis
Sender: [email-masked]

FWIW, Lisa's description of how things work with the tools in place 
today pretty well matches my recollection of how things worked (without 
those tools) when I was on IESG from 1996-2000.  So to me it doesn't 
seem that the tools have changed the procedures much.

Basically IESG had to keep track of so many different things that a 
"blocking" action was pretty much required to keep things from falling 
through the cracks.  So DISCUSS was used, among other things, as a way 
to make sure that various kinds of details got proper attention.  This 
wasn't as bad as it might sound, because any item with a DISCUSS 
automatically got put on IESG's biweekly telechat agenda - which pretty 
well served to keep those items from getting buried.

Keith

John C Klensin wrote:
> Lisa,
> 
> --On Monday, 09 June, 2008 10:45 -0700 Lisa Dusseault
> <[email-masked]> wrote:
> 
>> ...
>> The way the IETF Issue tracker works is that if you enter a
>> COMMENT, nobody can track whether the issue is still open, has
>> been resolved etc.  But a DISCUSS is trackable, and in this
>> case trackable = blocking.
>> ...
> 
> Just one observation about this, which is that the community has
> invested huge levels of resources in administrative
> restructurings, new organizations and management structures, new
> secretariats, and the like over the last few years.  I say
> "huge" because the level of investment has been sufficient to
> disrupt the main work of the IETF on a number of occasions
> during the various transitions, which is a high price to pay --
> probably worth it if we get good results and ROI, but
> nonetheless a high price.
> 
> On the other hand, if, after all of that, the IESG is being
> constrained to do unreasonable things by the tools it is using
> and how those tools are organized, one has to wonder whether all
> of that effort and resource investment has left us no better off
> than we were before in the areas that really count.
> 
> Just a thought...
> 
>     john
> 

Date: Mon, 09 Jun 2008 15:05:02 -0400
From: John C Klensin <[email-masked]>
To: Lisa Dusseault <[email-masked]>, Pete Resnick <[email-masked]>
cc: Keith Moore <[email-masked]>, John Leslie <[email-masked]>, [email-masked], Tony Hansen <[email-masked]>
Subject: Re: IESG approval status of  rfc2821bis
Sender: [email-masked]

Lisa,

--On Monday, 09 June, 2008 10:45 -0700 Lisa Dusseault
<[email-masked]> wrote:

>...
> The way the IETF Issue tracker works is that if you enter a
> COMMENT, nobody can track whether the issue is still open, has
> been resolved etc.  But a DISCUSS is trackable, and in this
> case trackable = blocking.
>...

Just one observation about this, which is that the community has
invested huge levels of resources in administrative
restructurings, new organizations and management structures, new
secretariats, and the like over the last few years.  I say
"huge" because the level of investment has been sufficient to
disrupt the main work of the IETF on a number of occasions
during the various transitions, which is a high price to pay --
probably worth it if we get good results and ROI, but
nonetheless a high price.

On the other hand, if, after all of that, the IESG is being
constrained to do unreasonable things by the tools it is using
and how those tools are organized, one has to wonder whether all
of that effort and resource investment has left us no better off
than we were before in the areas that really count.

Just a thought...

    john

Cc: Keith Moore <[email-masked]>, John Leslie <[email-masked]>, John C Klensin <[email-masked]>, [email-masked], Tony Hansen <[email-masked]>
From: Lisa Dusseault <[email-masked]>
To: Pete Resnick <[email-masked]>
Subject: Re: IESG approval status of  rfc2821bis
Date: Mon, 9 Jun 2008 10:45:53 -0700
Sender: [email-masked]

On Jun 6, 2008, at 12:03 PM, Pete Resnick wrote:

> On 6/6/08 at 2:36 PM -0400, Keith Moore wrote:
>
>>> DISCUSS should only be used if the document has a showstopper that  
>>> needs discussion. The IESG needs to get their act together on that.
>>
>> I disagree with the statement on how DISCUSS should be used.  I  
>> don't think that's either the intent of DISCUSS or the way that it  
>> should be interpreted.
>>
>> I believe DISCUSS simply means that an AD believes some item of a  
>> document needs further discussion before it should be approved for  
>> publication and/or its intended status.
>
> OK, but go back to my two criteria:
>
> (a) The issue cannot be addressed by a non-blocking comment.
> (b) The issue is so controversial that they cannot be dealt with by  
> an RFC Editor note at publication time.

Trying not to comment on the present document but on the DISCUSS  
discussion:  What we see in DISCUSS usage is, as is so often the case,  
an artifact of what the tools allow.  If ADs take their document  
review role seriously, then they end up with hundreds of issues found  
on hundreds of documents after a few years.  Email is not a good way  
to track these issues and whether they've been resolved.  Issue  
trackers are the canonical way to track issues that can be resolved.

The way the IETF Issue tracker works is that if you enter a COMMENT,  
nobody can track whether the issue is still open, has been resolved  
etc.  But a DISCUSS is trackable, and in this case trackable =  
blocking.  That is why (a) is used only when the AD really does not  
care to track the issue and ensure that it's resolved.

As for (b), if an AD, either the sponsoring or the DISCUSSing AD, were  
to send a note to the RFC Editor to modify a document in a way the  
author did not agree with, I think we'd have a more serious problem.   
A DISCUSS is a better way to achieve consensus than battling document  
changes.

Whenever an author and the ADs involved agree to some text that  
resolves an issue, it doesn't matter much if it goes into an RFC  
Editor note or into a revised I-D.  The essential thing is to get the  
agreement first!

Lisa

Date: Fri, 6 Jun 2008 14:03:28 -0500
To: Keith Moore <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: Re: IESG approval status of  rfc2821bis
Cc: John Leslie <[email-masked]>, John C Klensin <[email-masked]>, [email-masked], Lisa Dusseault <[email-masked]>, Tony Hansen <[email-masked]>
Sender: [email-masked]

On 6/6/08 at 2:36 PM -0400, Keith Moore wrote:

>>DISCUSS should only be used if the document has a showstopper that 
>>needs discussion. The IESG needs to get their act together on that.
>
>I disagree with the statement on how DISCUSS should be used.  I 
>don't think that's either the intent of DISCUSS or the way that it 
>should be interpreted.
>
>I believe DISCUSS simply means that an AD believes some item of a 
>document needs further discussion before it should be approved for 
>publication and/or its intended status.

OK, but go back to my two criteria:

(a) The issue cannot be addressed by a non-blocking comment.
(b) The issue is so controversial that they cannot be dealt with by 
an RFC Editor note at publication time.

The present document is supposed to be (a). The 2822upd problem is 
supposed to be (b). In the 2822upd case, I think it's perfectly 
clear: No "further discussion" was needed; it was just an ABNF typo. 
It should have been dealt with by an RFC Editor note or just a quick 
note to the editor. DISCUSS was the wrong mechanism.

But let's assume that the AD who put the discuss on 2821bis felt that 
they needed a DISCUSS and not just a non-blocking comment because 
discussion really needed to take place. I'm not convinced of that, 
but I'm happy to make that assumption. Let's look at your path for 
resolution:

>What is needed, fundamentally, is a response to the AD's concerns. 
>This might take the form of:
>
>- a revised version of the document(s) with changes along the lines 
>of the AD's request, or
>- a revised version of the document(s) with other changes intended 
>to address the AD's concern, or
>- an explanation of why the AD's concerns do not warrant changes to 
>the document, or
>- some combination of the above - e.g. a revised document with some 
>of the AD's requested changes, or concerns otherwise addressed, 
>along with an explanation of why the remaining changes/concerns do 
>not warrant changes to the document.

Well, in this case, the third item was used: An explanation was sent 
by the author saying that the AD's concerns do not warrant changes. 
The answer back from the AD was, "No, sorry. Not satisfied." That's 
the appeal point.

I agree with you that DISCUSS is warranted for things that actually 
require discussion. We may disagree on how serious something needs to 
be in order to warrant such discussion. But in the two cases I cited, 
neither of our criteria warranted the DISCUSS, in 2821bis because the 
DISCUSS remains after the explanation was sent, and in the 2822upd 
case because no discussion was actually required.

pr

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

Date: Fri, 06 Jun 2008 14:36:48 -0400
From: Keith Moore <[email-masked]>
To: Pete Resnick <[email-masked]>
CC: John Leslie <[email-masked]>, John C Klensin <[email-masked]>, [email-masked], Lisa Dusseault <[email-masked]>, Tony Hansen <[email-masked]>
Subject: Re: IESG approval status of  rfc2821bis
Sender: [email-masked]

> 
> DISCUSS should only be used if the document has a showstopper that needs 
> discussion. The IESG needs to get their act together on that. 

I disagree with the statement on how DISCUSS should be used.  I don't 
think that's either the intent of DISCUSS or the way that it should be 
interpreted.

I believe DISCUSS simply means that an AD believes some item of a 
document needs further discussion before it should be approved for 
publication and/or its intended status.  Yes, it does impede progress of 
the document until such discussion takes place.  And yes, the AD is 
expected to provide an example of what, in his mind, would remove the 
need for that DISCUSS.  But it is not (or should not be) tantamount to a 
demand that the document be changed in a way that the AD specifies - or 
at all.

What is needed, fundamentally, is a response to the AD's concerns.  This 
might take the form of:

- a revised version of the document(s) with changes along the lines of 
the AD's request, or
- a revised version of the document(s) with other changes intended to 
address the AD's concern, or
- an explanation of why the AD's concerns do not warrant changes to the 
document, or
- some combination of the above - e.g. a revised document with some of 
the AD's requested changes, or concerns otherwise addressed, along with 
an explanation of why the remaining changes/concerns do not warrant 
changes to the document.

At least when I was on IESG, there was considerable pressure on ADs from 
other IESG members to move documents forward, as long as a WG or 
document author made a reasonable effort to address the AD's concerns. 
It was not considered appropriate for an AD to dictate a set of changes 
to a WG or document author.

However, outside of the IESG people often interpreted a DISCUSS as being 
a mandate.   This actually made it more difficult to get resolution on 
issues and to move documents forward.  It put the AD in a Catch-22 
situation where he was expected to "solve the WG's problem" by stating, 
in detail, what would allow him to remove his DISCUSS (and to do so in a 
very short amount of time).  But on receiving those suggestions, the WG 
would often interpret them as a mandate and push back strongly or 
threaten appeal when really only some discussion was necessary.

Assuming that perpetual gap still exists (and it certainly looks like it 
from here), I think that's what needs to be fixed.

Basically I don't think DISCUSS should cause WG chairs or document 
editors to get their backs against the wall.

Date: Fri, 6 Jun 2008 12:03:47 -0500
To: John Leslie <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: Re: IESG approval status of  rfc2821bis
Cc: John C Klensin <[email-masked]>, [email-masked], Lisa Dusseault <[email-masked]>, Tony Hansen <[email-masked]>
Sender: [email-masked]

I, for one, recommend appeal, but I want to explain why by way of a 
particular part of JL's response:

On 6/6/08 at 5:06 AM -0400, John Leslie wrote:

>I can't speak for anyone who'd consider an appeal; but it looks to 
>be to be a waste of time. It can't possibly be faster; it will 
>_really_ annoy folks who would be better friends than enemies; and 
>it's hard to imagine any outcome close to what you want.

So, there are tactics and there are strategies. If the result we are 
looking for is fast publication, appeal is a stupid idea. But that's 
not what's behind the idea of an appeal. It is so we can stop 
repeatedly going through this exercise. The IESG has several 
mechanisms for recommend change to a document, but DISCUSS seems to 
be the "club of choice". And DISCUSS has some implications, as the 
DISCUSS Criteria ION says:

"The DISCUSS identifies one or more issues that must be discussed in 
relation to the document before the document can become an RFC. As 
such, 'DISCUSS' is a blocking position; the document cannot proceed 
until any issues are resolved to the satisfaction of the Area 
Director who issued the DISCUSS."

DISCUSS is for show-stoppers that (a) cannot be addressed by a 
non-blocking comment and (b) are so controversial that they cannot be 
dealt with by an RFC Editor note at publication time. Consistently, 
the IESG seems to choose DISCUSS over these two other choices, and 
DISCUSS serves to seriously delay documents, where the others allow 
it to continue through the process. The present document is an 
example of (a): Instead of sending a comment back to the author 
saying, "The IESG believes that the examples use the 2606 
recommendations" and let the document progress while the author works 
that out (or decides not to), the IESG felt that publication of this 
document as-is would be so harmful that it deserves to be stopped in 
its tracks. That's just nonsense.

I had a recent example of (b) with 2822upd: There was a missing set 
of parens in the ABNF which clearly made the syntax ambiguous, but 
also where the intent was exceedingly obvious. Instead of writing up 
an RFC Editor note which simply added the parens, and/or dropping the 
author an e-mail saying, "Hey, you need to fix this!", the AD in 
question instead put a DISCUSS on the document. There was no 
"DISCUSSion" needed in this case. I ended up IMing the AD, told the 
AD that this was an inappropriate use of DISCUSS, and the DISCUSS was 
cleared within hours.

DISCUSS should only be used if the document has a showstopper that 
needs discussion. The IESG needs to get their act together on that. 
Apparently "really annoying" them (as JL puts it) and threatening 
appeals is the only way to get them to fix their procedures.

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

Date: Fri, 06 Jun 2008 12:45:51 -0400
From: John C Klensin <[email-masked]>
To: John Leslie <[email-masked]>
cc: [email-masked], Lisa Dusseault <[email-masked]>, Tony Hansen <[email-masked]>
Subject: Re: IESG approval status of  rfc2821bis
Sender: [email-masked]

--On Friday, 06 June, 2008 05:06 -0400 John Leslie
<[email-masked]> wrote:

>    OK, John, you've had your rant, and hopefully slept on it.
> Calm down a bit, and pay more attention to where you actually
> stand.
> 
> John C Klensin <[email-masked]> wrote:
>> 
>> We have reached an impasse with the IESG about how to proceed
>> with 2821bis. 
> 
>    Not so. 2821bis is in status "Revised-ID needed". This is
> one of the two normal states for a draft that's not approved
> the first time it's brought up at an IESG telechat. You can
> submit a revised draft or you can let it sit in that state.
> 
>    There is no "impasse" unless you refuse to submit any
> changes at all; and the impasse, if any, is not with "the
> IESG" -- it's between you and Lisa.
>...

John,

There is some lack of precision and fine gradation in the
tracker and its mechanisms for threading comments (as you
presumably know, part of that has been the subject of a recent
discussion on the IETF list.  The precise tracker state used
initially confused me as well; my recollection is that, after
one discussion, Lisa offered to change it to something else, to
which my response was, more or less, that, as long as I
understood the situation, it made little difference.

If the precise tracker state used confuses you, or seems
problematic to you for other reasons, please discuss it with
Lisa.

Regardless of  the tracker state, the situation is exactly as I
described.  There is an AD holding a DISCUSS about the domain
names used in the examples.  He has made it clear, after some
off-list correspondence, that he isn't going to change the
DISCUSS.   The exact words in his most recent note were "The
IESG has been enforcing the BCP for at least five years.  I
await a revised document or an appeal.  That choice is yours."
Perhaps there is another way to interpret that statement, but I
can't figure out what it is.  And, given that, posting another
version of the document that does not make the domain changes
appears to me to be a complete waste of everyone's time.

     john

Date: Fri, 6 Jun 2008 05:06:05 -0400
From: John Leslie <[email-masked]>
To: John C Klensin <[email-masked]>
Cc: [email-masked], Lisa Dusseault <[email-masked]>, Tony Hansen <[email-masked]>
Subject: Re: IESG approval status of  rfc2821bis
Sender: [email-masked]

   OK, John, you've had your rant, and hopefully slept on it.
Calm down a bit, and pay more attention to where you actually stand.

John C Klensin <[email-masked]> wrote:
> 
> We have reached an impasse with the IESG about how to proceed
> with 2821bis. 

   Not so. 2821bis is in status "Revised-ID needed". This is one of
the two normal states for a draft that's not approved the first time
it's brought up at an IESG telechat. You can submit a revised draft
or you can let it sit in that state.

   There is no "impasse" unless you refuse to submit any changes at
all; and the impasse, if any, is not with "the IESG" -- it's between
you and Lisa.

> The problem is an outstanding DISCUSS about changing all of the
> examples that do not use RFC 2606 (e.g., "example.com" and friends)
> names to use that convention, with the possible exception of those
> that point to ISI or USC. 

   That's not precisely true. The balloting on 2821bis-10 had
DISCUSSes from Russ Housley and Magnus Westerlund. DISCUSS is a
status for balloting on a particular draft. The _text_ listed in
the "Open Web Ballot" link is guidance to the shepherding AD, not
a non-negotiable demand.

   At the telechat May 8th, Lisa chose the status "Revised-ID
needed", apparently figuring you'd change a few example domains
and submit a new draft, while she investigated the implementation
report problem. You are not required to make any particular
changes, least of all to slavishly follow the DISCUSS comments
(which, to tell truth, were jotted rather quickly under serious
time constraints). And please don't forget the four ADs that had
non-DISCUSS comments. "Revised-ID needed" _means_ you're expected
to pay some attention to them also.

> I now have an explicit note in hand that says "I await a revised
> document or an appeal",

   Presumably from Lisa...

> so we are now at a choice point. I'm inclined toward an appeal

   That's a normal first reaction...

> or other push-back action

   There's a lot of potential ground there, I guess: you certainly
could email Lisa your reaction to _all_ the comments, showing why
you believe _none_ of them justify a revised ID, or you could even
submit a new draft changing nothing but the date...

> but am not the only one who would be affected by a further delay
> with this document, so want to explain the situation as I see it.

   (I'm going to skip over most of this.)

> My position in general is that
> 
> 	(i) The IESG does not get to invent rules that are then
> 	used to block progression of a document without
> 	consulting the community.

   You are quite correct that we have a problem of process here,
but you seriously mischaracterize the process problem.

   "The IESG" is not inventing any rules here: individual ADs are
trying to apply existing rules as they see them. You know who they
are -- you can corner them in Dublin, or wherever, and explain why
you think they misunderstand those rules.

> 	(ii) Given the pressure on authors --especially WG
> 	Chairs and document editors-- to simply go along with AD
> 	demands and preferences, reasonable or not, in order to
> 	get documents published rather than permanently stalled,

   As you well know, that's an unfortunate misunderstaning. ADs
are expected to state what it would take to make them consent to
publication -- but that's strictly in order to ensure that _some_
path forward exists. That authors choose that as the road of least
resistance is, frankly, wrong but very understandable. That authors
then blame "the IESG" for this is wrong, period.

> 	I do not believe that "the IESG has been doing this for
> 	years" constitutes evidence that the community has
> 	approved of the IESG's doing so.

   I stipulate your belief, but I do not share it.

> 	(iii) Even if one were to concede that the IESG has the
> 	authority to make this a requirement (which I do not),

   Nor do they. They are following a process aiming at consensus
among themselves. No such "requirement" exists.

> 	it is abusive [snip]

   You make a reasonable case; but you argue a straw-man.

> The one issue that _is_ specific to 2821bis (and 2821) is that
> DRUMS explicitly considered the question of what to do about the
> 821 examples.

   DRUMS has closed. Few, if any, of the current ADs remember it.
None of them worship it. Life goes on...

> I believe that there are four possible ways forward, at least
> ones that I wouldn't find very offensive (I'm open to other
> ideas):
> 
> (1) I have offered the AD in question the option of changing the
> DISCUSS to a Comment,

   This is silly. The _document_ is in "Revised-ID needed". You
can revise it, or not. If you do, it will get fresh balloting.

> (2) People can convince me that the principles I see here aren't
> very important and we should just give in, make the changes, and
> get the document published.

   I don't volunteer to try to convince you of anything. But I
do remind you that Lisa very likely hoped you'd also address the
non-DISCUSS comments.

> (3)  I can launch an appeal,

   I can't speak for anyone who'd consider an appeal; but it looks
to be to be a waste of time. It can't possibly be faster; it will
_really_ annoy folks who would be better friends than enemies;
and it's hard to imagine any outcome close to what you want.

> (4) Either instead of (3) or in addition to it, people could
> conclude that the behavior and argument that the IESG can and
> should do this because it thinks it can and has been doing so,
> despite any documentation or evidence of consensus, is
> sufficiently abusive that the AD in question should be singled
> out as an illustrative example and recalled. 

   I couldn't possibly support a recall action against Lisa,
Russ, or Magnus (you do mean one of those three, right?).

> What is your pleasure?

   Personally, I hope you'll simply submit _some_ "revised ID"
or drop it.

   The _problem_, as I said before, is the process. We have been
trying to follow a model of "maturity" advancement which we all
know just isn't working. "Advancement" to Draft Standard simply
doesn't happen in any ordinary cases. Many good folks have
exhausted themselves trying to get consensus for a real revision
of RFC 2026. Our whole exercise to try to follow it here looks
very much like battling windmills.

   There is another option I almost hesitate to mention. Some of
us, at least, have invested the effort into this because of a
belief that RFC 2821 needs a few "maturity" updates. We _could_
try to write up a WG charter for this work, and ask Lisa and
Chris to charter a real Working Group. (Some of your problem,
I believe, stems from having to submit 2821bis as an
Individual Submission.)

--
John Leslie <[email-masked]>

To: [email-masked]
From:  "Frank Ellermann" <[email-masked]>
Subject:  New 2606bis draft (was: IESG approval status of  rfc2821bis)
Date:  Fri, 6 Jun 2008 07:09:40 +0200
Organization:  <http://purl.net/xyzzy>
Lines: 16
Reply-To:  "Frank Ellermann" <[email-masked]>
Sender: [email-masked]

> John C. Klensin wrote:

>> initiate an update to 2606 that changes "can be used" into
>> "MUST be used unless the IESG grants a waiver".

> ...yes, adding it elsewhere (idnits, idguidelines) can then
> simply follow when the editors of these tools / documents want
> it.

Meanwhile a 2606bis draft is available at the usual places:
<http://tools.ietf.org/html/draft-ellermann-idnabis-test-tlds>

Ignoring unrelated points this upper cases RECOMMENDED adding
a normative RFC 2119 refererence for the key word.

 Frank

Date: Thu, 05 Jun 2008 14:55:47 -0700
To: John C Klensin <[email-masked]>, [email-masked]
From: SM <[email-masked]>
Subject: Re: IESG approval status of  rfc2821bis
Cc: Lisa Dusseault <[email-masked]>, Tony Hansen <[email-masked]>
Sender: [email-masked]

Hi John,
At 08:52 05-06-2008, John C Klensin wrote:
>We have reached an impasse with the IESG about how to proceed
>with 2821bis.  The problem is an outstanding DISCUSS about
>changing all of the examples that do not use RFC 2606 (e.g.,
>"example.com" and friends) names to use that convention, with
>the possible exception of those that point to ISI or USC.   I

I saw that DISCUSS.  A long time back, I sent you comments about the 
draft together with suggested changes to the examples to have them 
conform to RFC 2606.  Your arguments against my suggestions were 
valid in my opinion.  I'm not going to post the arguments as it was 
in a private email.

>Neither 2606, nor the "Guidelines", nor even "IDNits" require
>those names.  2606 (the only consensus document on the subject)
>says things like "can be used" and does not even express an
>explicit preference for them.

[snip]

> > (2) The I-D Checklist (IDnits,
> > http://www.ietf.org/ID-Checklist.html), Section 6, says
> >
> >         "Addresses used in examples SHOULD preferably use
> >         fully qualified domain names instead of literal IP
> >         addresses, and preferably use example fqdn's such as
> >         foo.example.com instead of real-world fqdn's."
> >
> > "SHOULD preferably" and "preferably" are, I believe obviously,
> > statements of preference, not firm requirements.  That is
> > especially true of the second one, which doesn't even contain
> > the word "SHOULD".

Unless you have a good reason not to, it is preferable to use domain 
names as mentioned in RFC 2606.  Now, if we want to treat that as a 
firm requirement, then I could argue that even the ISI or USC domain 
names should be changed so as to conform with RFC 2606.  2821bis lays 
down a lot of rules.  It however gives us some leeway under local 
considerations instead of setting everything in stone.  That applies 
to the above as well.

> > (3) The DISCUSS Criteria document
> > (http://www.ietf.org/IESG/STATEMENTS/discuss-criteria.html)
> > does not list the use of non-2026 names as an item on the
> > list of criteria in Section 3.1.  Indeed, it explicitly
> > discourages DISCUSSion for "Pedantic corrections to
> > non-normative text" and "Stylistic issues of any kind" in
> > section 3.2.
>
>The AD holding the DISCUSS (you can easily find out from the
>tracker, but I believe this is about principles rather than
>personalities and am generally happy with that AD's performance)
>has indicated that he doesn't like these names and considers
>their use "rude" and that the IESG has been enforcing the use of
>2606 names as a firm rule for "at least five years".

Under which DISCUSS Criteria (Section 3.1) does this rule fall?

>The one issue that _is_ specific to 2821bis (and 2821) is that
>DRUMS explicitly considered the question of what to do about the
>821 examples.  In fairness, I don't know how much the WG was
>influenced by my personal preferences, but the conclusion was to
>eliminate the references to .ARPA (because they were distracting
>and clearly impossible given the current role of that domain)
>but otherwise to preserve Jon Postel's examples (not just the
>ones that used USC or ISI domains) to the extent possible.
>DRUMS reached consensus on what became 2821 and the IESG signed
>off on it.   So this DISCUSS within the IESG now effectively
>overrides, not only discussions and conclusions on this mailing
>list, but the presumably-informed discussions of the original
>WG.   And, for better or worse, another few months of delay in
>getting 2821bis published probably makes less difference than
>would be the case for a new Proposed Standard for which people
>are anxious to deploy conforming implementations, so I'm feeling
>less pressure to "just go along" than the typical WG editor
>might.

As 2821 was approved by the IESG two years after the publication of 
RFC 2606, then why is this an issue now?

>I believe that there are four possible ways forward, at least
>ones that I wouldn't find very offensive (I'm open to other
>ideas):
>
>(1) I have offered the AD in question the option of changing the
>DISCUSS to a Comment, thereby dropping the implicit assertion
>that the IESG (or, even worse, one AD) has the right to
>_require_ this type of change at this point in the process.  I
>have indicated informally that, if that change were made, I
>would "probably" change the examples.   While I haven't said it
>explicitly to the AD or IESG, the only condition on the changes
>would be my checking with this list to see if anyone strongly
>and persuasively objected.   In either this case or the next
>one, I would rewrite the Acknowledgments to explicitly point to
>Jon's role and examples and clear the text with this list (in
>retrospect, that may be what we should have done for 2821).
>The option of making the DISCUSS -> Comment change has been
>declined (at least I have gotten no response to it in any of the
>discussions).
>
>(2) People can convince me that the principles I see here aren't
>very important and we should just give in, make the changes, and
>get the document published.  To me, that is equivalent to
>agreeing that it is ok for the IESG to have essentially-secret
>rules, developed without community consensus and undocumented in
>any description for I-D requirements, and then impose those
>rules using permanent blocking DISCUSS positions after Last
>Call.  I believe that agreement would be bad news, but perhaps
>I'm being naive and the relevant horse is sufficiently out of
>the barn that it is time to acknowledge that, e.g., selection to
>the IESG is equivalent to anointment as a member of a group with
>imperial powers and divine right.

Principles are important.  If we follow that line alone, then we have 
to agree that it is reasonable to follow RFC 2606 when writing an I-D.

I appreciate your stand on this as a matter of principle.  However, 
as the editor, you serve at the pleasure of the "WG".  The question 
is whether the "WG" believes that examples in the 2821bis that went 
through the Last Call should be preserved as such.

Changing the examples overrides a DRUMS WG decision.  During the 
discussions on 2821bis, several points were rejected based on the 
argument that we should not revisit DRUMS decisions.  2821bis 
received extensive review and also went through an IETF-wide Last 
Call where such RFC 2606 nits are generally picked up.  Unless I am 
mistaken, the question was not raised.  I assume that there was 
community consensus on keeping the examples as they are now.

>(3)  I can launch an appeal, following the outline above and
>asking for two specific remedies: (i) approval of this document
>as-is and (ii) a firm requirement that no AD issue a blocking
>DISCUSS on any editorial or other non-technical subject unless
>the requirement is clearly documented in a BCP or formal
>position statement that is subject to appeal at the time of
>publication and that is published prior to the document's
>entering Last Call.   This is the default option unless people
>persuade me otherwise, presumably that we should fall back to
>(2).

I favor option (3).

Regards,
-sm 

To: [email-masked]
From:  "Frank Ellermann" <[email-masked]>
Subject:  Re: IESG approval status of  rfc2821bis
Date:  Thu, 5 Jun 2008 23:30:17 +0200
Organization:  <http://purl.net/xyzzy>
Lines: 108
Reply-To:  "Frank Ellermann" <[email-masked]>
Sender: [email-masked]

John C Klensin wrote:
 
> The problem is an outstanding DISCUSS about changing all of the
> examples that do not use RFC 2606 (e.g., "example.com" and friends)
> names to use that convention, with the possible exception of those
> that point to ISI or USC.

Just fix it and be done with it.  For obvious reasons they'd be
in a shaky position if they let it pass depending on the name of
the author.

> 2606 (the only consensus document on the subject) says things
> like "can be used" and does not even express an explicit 
> preference for them.

RFC 2606 needs to be updated.  RFC 3330 for IPv4 examples and an
RFC for IPv6 examples exist, maybe there's also another RFC for
example telephone numbers - I forgot the details, but the theory
is very simple, stay away from "real" examples unless you have a
very good excuse, e.g., the consent of the affected parties.

"Never ever publish e-mail addresses unless you are ready to deal
with tons of spam" is simply common practice - it would be odd if
2821bis ignores the issue, readers could ask if the IETF is aware
of the spam problem, or if it's still living in the 20th century.

> the IESG has been enforcing the use of 2606 names as a firm rule
> for "at least five years".

That's what they do, in fact it's the only style I know, because I
had no idea what "IETF" really is before MARID and an unscheduled
USEFOR boot camp organized by Bruce in 2004.  Thinking about it,
it won't surprise me if he he's one the inventors of this "rule".

> I do not believe that "the IESG has been doing this for years" 
> constitutes evidence that the community has approved of the
> IESG's doing so.

As always TINW, I think the rule makes sense, but it would be nice
to note it in 2606bis.  While at it adding the 11 IDN test TLDs to
2606bis would be also good...

> initiate an update to 2606 that changes "can be used" into
> "MUST be used unless the IESG grants a waiver".

...yes, adding it elsewhere (idnits, idguidelines) can then simply
follow when the editors of these tools / documents want it.

> excerpting from RFC 2026, Section 6.5.3

IMO that is for things that are *worse* than the RFC 4406 scandal,
it is the level of "ISO 29500" or open corruption.  Section 6.5.3
is for cases where ISOC needs to decide if it wishes to shut down
the IETF.  

> The one issue that _is_ specific to 2821bis (and 2821) is that
> DRUMS explicitly considered the question of what to do about
> the 821 examples. 

Whenever somebody said "DRUMS" in the last two years it was as
an exccuse for an utter dubious decision years ago, where they
didn't wish to discuss what the DRUMS participants were smoking.
Just my personal impression as somebody who read only the DRUMS
output, not the list archive.

> I would rewrite the Acknowledgments to explicitly point to
> Jon's role and examples and clear the text with this list

Without a WG only the IESG is supposed to judge the "consensus",
but I say there was strong support for keeping Jon's address in
examples "as is" here.  Adding something about this decision in
the Acknowledgements is a good idea, maybe link to RFC 2468 (?)

 [just fix it]
> To me, that is equivalent to agreeing that it is ok for the
> IESG to have essentially-secret rules, developed without
> community consensus and undocumented in any description for
> I-D requirements, and then impose those rules using permanent
> blocking DISCUSS positions after Last Call.

The (undocumented) rule was no secret for me, it was completely
unnecessary that I forgot to get the explicit prior consent for
a violation of this rule in the news-URI memo (fixed meanwhile).

What's wrong here is the "undocumented", not the rule.  I don't
see the point of involving the IAB in this issue (by an appeal),
let's just admit that 2606 has to be fixed.  Most likely the IAB
would also pick this as solution.

> e.g., selection to the IESG is equivalent to anointment as a
> member of a group with imperial powers and divine right.

Dunno, in a case like RFC 4406, where an entity known as Redmond
in essence tried to steal the work of an entity known as openSPF
endorsed by the IESG I'd share your concern, but for "addresses
in examples" I think it's slightly exaggerated.  

There is also the question of "do (un)documented rules depend on
the name of the author".  To some degree they do, it's only fair,
but they can't do this too obviously, everybody could later say
"but RFC 5821 also did this".

> What is your pleasure?

Let's fix RFC 2606.  If you are sufficiently angry we could move
RFC 3710 to historic, it clearly violates RFC 2418.

 Frank

Date: Thu, 5 Jun 2008 22:43:43 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: IESG approval status of rfc2821bis
Cc: Tony Hansen <[email-masked]>, John C Klensin <[email-masked]>, Lisa Dusseault <[email-masked]>
Sender: [email-masked]

John C Klensin writes:
>> (2) The I-D Checklist (IDnits,
>>  http://www.ietf.org/ID-Checklist.html), Section 6, says
>>
>>          "Addresses used in examples SHOULD preferably use fully 
>>          qualified domain names instead of literal IP addresses, and 
>>          preferably use example fqdn's such as foo.example.com 
>>          instead of real-world fqdn's."
>>
>>  "SHOULD preferably" and "preferably" are, I believe obviously, 
>>  statements of preference, not firm requirements. That is especially 
>>  true of the second one, which doesn't even contain the word 
>>  "SHOULD".

One might say that the suggestion is a stronger one for documents that 
have advanced along the standards track.

But even a very strong suggestion allows refutation. The refutation just 
ought to be very well considered.

And that's really the key, IMO. So:

> The one issue that _is_ specific to 2821bis (and 2821) is that
> DRUMS explicitly considered the question of what to do about the
> 821 examples.  In fairness, I don't know how much the WG was
> influenced by my personal preferences, but the conclusion was to
> eliminate the references to .ARPA (because they were distracting
> and clearly impossible given the current role of that domain)
> but otherwise to preserve Jon Postel's examples (not just the
> ones that used USC or ISI domains) to the extent possible.

This says: The examples that had concrete bad effects have been fixed 
already, and the rest were carefully considered already.

The IESG can consider whether it wants to turn the almost-rule into a 
proper rule. But that hasnn't been done yet AFAICT, and I think there 
are good reasons why it hasn't, and 2821bis should be allowed to 
proceed under the actual rules in place. Conventions are fine, but 
there's a difference between a rule and a convention: those who think 
hard about it and discuss is thoroughly can break conventions.

Arnt

Date: Thu, 05 Jun 2008 14:37:48 -0400
From: Keith Moore <[email-masked]>
To: [email-masked]
CC: John C Klensin <[email-masked]>, [email-masked], Lisa Dusseault <[email-masked]>, Tony Hansen <[email-masked]>
Subject: Re: IESG approval status of  rfc2821bis
Sender: [email-masked]

> 
> Two points are missing:
> 
>    1) Undue cost for making a *bis revision

Strongly agree with this.  It's already too difficult for IETF to revise 
documents.  There is too much tendency for IESG to insist on rewrites 
that raise this cost far out of proportion to the value gained in 
exchange for the extra work and the delay - and often, IMHO, the 
rewrites actually harm the documents.

We really need to be making it easier to revise documents in IETF so 
that we can do a better job of keeping them current.  It's one thing for 
IESG to hold up a revision because of some newly-discovered bug that 
harms interoperability or clarity of the document, but it seems like a 
waste of precious resources to hold up a revision merely to insist on 
some new editorial convention.

>    2) Protecting the installed base.

agree with this also, for reasons stated in a separate message.

Keith

Date: Thu, 05 Jun 2008 14:31:34 -0400
From: Keith Moore <[email-masked]>
To: John C Klensin <[email-masked]>
CC: [email-masked], Lisa Dusseault <[email-masked]>, Tony Hansen <[email-masked]>
Subject: Re: IESG approval status of  rfc2821bis
Sender: [email-masked]

In general, I think the IESG should have broad discretion to object to 
any technical shortcoming of a document - certainly anything that would 
make a protocol less robust is grounds for a DISCUSS.  Editorial 
shortcomings are a grayer area, but I still think the IESG should have 
broad discretion - for instance any ambiguity that could reasonably lead 
to an interoperability failure is grounds for a DISCUSS.

But I think IESG's goals for standards-track documents should center 
around technical soundness and the likelihood of such documents being 
interpreted consistently by different readers.

So I don't think IESG should be constrained to issuing DISCUSS votes 
only when there's a consensus-based rule already in place.  At the same 
time I think that DISCUSS votes should always be justified in terms of 
making the resulting protocol (or its implementations) more robust or 
more likely to interoperate.  Any counterarguments should probably be 
made based on the same values.

Applying this value to the "goodness" of the example domains in rfc 
2821bis I generally find that the domain names chosen for examples should

(a) be syntactically valid domains for DNS, SMTP, and RFC[2]822;
(b) not be confusing.  this might imply, for instance, using only 
recognizable TLDs and not coining new ones).
(c) avoid conflicts with existing or future domain names - because this 
could cause disruption for some parties and thus harm the robustness of 
their operations.  (I remember being told, long ago, that a significant 
portion of the traffic to nic.ddn.mil was ICMP echo requests because 
"ping nic.ddn.mil" was a widely published test for determining whether 
you were "on the net".)

Restricting the examples to the names in section 3 of RFC 2606 is a 
well-established way to accomplish these.  But if these goals can also 
be met in a different way, that should also suffice.

(However, I would recommend _against_ the use of TLDs in section 2 of 
RFC 2606 when not talking specifically about new TLDs - because I think 
they could be confusing.  Some readers might not recognize foo.test as a 
domain name.)

I also think that any unnecessary changes between RFC 2821 and RFC 
2821bis will make the task of identifying those changes more difficult 
than it needs to be.  This might conceivably harm robustness or 
interoperability.  There's a lot of value in consistency, even for 
something as trivial as this.

Finally I remember that when writing RFC 1891, I coined a large number 
of new domain names (Pure-Heart.ORG, Big-Bucks.COM, Ivory.EDU, 
Bombs.AF.MIL, Tax-ME.GOV, Boondoggle.GOV), simply because I needed lots 
of examples and I wanted the reader to be able to clearly distinguish 
between the different cases.  I don't think the examples would have been 
as readable had I constrained myself to use the names available in RFC 
2606.   I was also trying to pick names that would be easy for readers 
to remember so that the examples would be more accessible.  (it's a lot 
easier to distinguish Pure-Heart.ORG from Ivory.EDU than it is to 
distinguish A.EXAMPLE.COM from B.EXAMPLE.ORG)

(Though when revising RFC 1891 (to become RFC 3461) I found it necessary 
to change Pure-Heart.ORG and Big-Bucks.COM because those domains had 
since been registered.)

Bottom line: IMHO, RFC 2606 is fine for documents that only need a small 
number of example domains, but not adequate for documents than need more 
than 2 or 3 different example domains.  I also think there's 
considerable value in maintaining as much consistency as possible 
between versions of a specification.  I don't think IESG is overstepping 
its authority by DISCUSSing this point, but I do think that on balance 
they'd be harming robustness and interoperability by blocking the 
document until such a change were made.

As for whether to appeal, I'd apply the same values - which would result 
in better robustness and interoperabilty?  Getting the document out 
sooner by changing it to use RFC 2606 domain names, or waiting for the 
appeal to complete before publishing the document?

I do think it's worth another round trip to IESG to say "here's why we 
think it would be better to use the existing examples."  As to whether 
it's worth the time to ask IAB the same thing - maybe, but only if it 
can be done quickly.  At least this particular issue is fairly simple. 
But I don't think it's a process issue, but rather a clarity issue and a 
matter of editorial judgment.

Keith

John C Klensin wrote:
> Hi.
> 
> We have reached an impasse with the IESG about how to proceed
> with 2821bis.  The problem is an outstanding DISCUSS about
> changing all of the examples that do not use RFC 2606 (e.g.,
> "example.com" and friends) names to use that convention, with
> the possible exception of those that point to ISI or USC.   I
> now have an explicit note in hand that says "I await a revised
> document or an appeal", so we are now at a choice point.   I'm
> inclined toward an appeal or other push-back action but am not
> the only one who would be affected by a further delay with this
> document, so want to explain the situation as I see it.
> 
> There has been fairly extensive correspondence on this subject.
> I've tried to summarize the situation from my point of view
> below in as short a form as possible.  Lisa and Tony have, I
> believe, seen all of it and may have a different take on what is
> going on.  If either does, I hope they will say something.
> 
> Neither 2606, nor the "Guidelines", nor even "IDNits" require
> those names.  2606 (the only consensus document on the subject)
> says things like "can be used" and does not even express an
> explicit preference for them.
> 
> There are three IESG position statements that might bear on the
> issue.  Quoting from one of the earlier notes...
> 
>> (1) The "Guidelines to Authors of Internet Drafts"
>> (http://www.ietf.org/ietf/1id-guidelines.html) does not
>> mention the issue of examples at all.
>>
>> (2) The I-D Checklist (IDnits,
>> http://www.ietf.org/ID-Checklist.html), Section 6, says
>>
>>         "Addresses used in examples SHOULD preferably use
>>         fully qualified domain names instead of literal IP
>>         addresses, and preferably use example fqdn's such as
>>         foo.example.com instead of real-world fqdn's."
>>
>> "SHOULD preferably" and "preferably" are, I believe obviously,
>> statements of preference, not firm requirements.  That is
>> especially true of the second one, which doesn't even contain
>> the word "SHOULD".
>>
>> (3) The DISCUSS Criteria document
>> (http://www.ietf.org/IESG/STATEMENTS/discuss-criteria.html)
>> does not list the use of non-2026 names as an item on the
>> list of criteria in Section 3.1.  Indeed, it explicitly
>> discourages DISCUSSion for "Pedantic corrections to
>> non-normative text" and "Stylistic issues of any kind" in
>> section 3.2.
> 
> The AD holding the DISCUSS (you can easily find out from the
> tracker, but I believe this is about principles rather than
> personalities and am generally happy with that AD's performance)
> has indicated that he doesn't like these names and considers
> their use "rude" and that the IESG has been enforcing the use of
> 2606 names as a firm rule for "at least five years".
> 
> My position in general is that
> 
> 	(i) The IESG does not get to invent rules that are then
> 	used to block progression of a document without
> 	consulting the community.
> 	
> 	(ii) Given the pressure on authors --especially WG
> 	Chairs and document editors-- to simply go along with AD
> 	demands and preferences, reasonable or not, in order to
> 	get documents published rather than permanently stalled,
> 	I do not believe that "the IESG has been doing this for
> 	years" constitutes evidence that the community has
> 	approved of the IESG's doing so.
> 	
> 	(iii) Even if one were to concede that the IESG has the
> 	authority to make this a requirement (which I do not),
> 	it is abusive --an example of a completely unnecessary
> 	very late review "gotcha" surprise-- for the IESG to
> 	impose this rule without documenting it in any of the
> 	criteria statement documents identified above.   I have
> 	suggested in a few of my notes that, if the IESG wants
> 	to impose rules like this, it should move to revise one
> 	of more of those documents (presumably the I-D
> 	Checklist) to specify the requirement and see if the
> 	community accepts that additional rule once it is
> 	written down.   Of course, they could also initiate an
> 	update to 2606 that changes "can be used" into "MUST be
> 	used unless the IESG grants a waiver".  There has been
> 	no response to either of those suggestions.
> 	
> 	(iv) Since this blocking DISCUSS is inconsistent with
> 	the IESG's published statements about conditions for
> 	such actions (in the absence of a mandate from a
> 	consensus document, it appears to be an "editorial
> 	preference") and there seems to be no practical way to
> 	un-block it, it is a case in which, excerpting from RFC
> 	2026, Section 6.5.3, "the procedures themselves ... are
> 	... inadequate or insufficient to the protection of the
> 	rights of all parties in a fair and open Internet
> 	Standards Process".  Of course, that would be irrelevant
> 	if the IESG were to reverse itself and unblock this
> 	document during the appeal process.
> 
> I note that none of those three issues is specific to 2821bis.
> They are really about how the IESG manages and expresses its
> authority and discretion.  There is one more general issue,
> which is what changes it is reasonable to demand to a document
> being progressed from one maturity level to the next.  2026 is
> not specific about this, but I believe that its language
> combines with a presumed general belief that we should put as
> few unnecessary stumbling blocks in the path of advancing
> documents to argue that late-review/ late-surprise requirements
> for cosmetic changes are inappropriate.
> 
> The one issue that _is_ specific to 2821bis (and 2821) is that
> DRUMS explicitly considered the question of what to do about the
> 821 examples.  In fairness, I don't know how much the WG was
> influenced by my personal preferences, but the conclusion was to
> eliminate the references to .ARPA (because they were distracting
> and clearly impossible given the current role of that domain)
> but otherwise to preserve Jon Postel's examples (not just the
> ones that used USC or ISI domains) to the extent possible.
> DRUMS reached consensus on what became 2821 and the IESG signed
> off on it.   So this DISCUSS within the IESG now effectively
> overrides, not only discussions and conclusions on this mailing
> list, but the presumably-informed discussions of the original
> WG.   And, for better or worse, another few months of delay in
> getting 2821bis published probably makes less difference than
> would be the case for a new Proposed Standard for which people
> are anxious to deploy conforming implementations, so I'm feeling
> less pressure to "just go along" than the typical WG editor
> might.
> 
> I believe that there are four possible ways forward, at least
> ones that I wouldn't find very offensive (I'm open to other
> ideas):
> 
> (1) I have offered the AD in question the option of changing the
> DISCUSS to a Comment, thereby dropping the implicit assertion
> that the IESG (or, even worse, one AD) has the right to
> _require_ this type of change at this point in the process.  I
> have indicated informally that, if that change were made, I
> would "probably" change the examples.   While I haven't said it
> explicitly to the AD or IESG, the only condition on the changes
> would be my checking with this list to see if anyone strongly
> and persuasively objected.   In either this case or the next
> one, I would rewrite the Acknowledgments to explicitly point to
> Jon's role and examples and clear the text with this list (in
> retrospect, that may be what we should have done for 2821).
> The option of making the DISCUSS -> Comment change has been
> declined (at least I have gotten no response to it in any of the
> discussions).
> 
> (2) People can convince me that the principles I see here aren't
> very important and we should just give in, make the changes, and
> get the document published.  To me, that is equivalent to
> agreeing that it is ok for the IESG to have essentially-secret
> rules, developed without community consensus and undocumented in
> any description for I-D requirements, and then impose those
> rules using permanent blocking DISCUSS positions after Last
> Call.  I believe that agreement would be bad news, but perhaps
> I'm being naive and the relevant horse is sufficiently out of
> the barn that it is time to acknowledge that, e.g., selection to
> the IESG is equivalent to anointment as a member of a group with
> imperial powers and divine right.
> 
> (3)  I can launch an appeal, following the outline above and
> asking for two specific remedies: (i) approval of this document
> as-is and (ii) a firm requirement that no AD issue a blocking
> DISCUSS on any editorial or other non-technical subject unless
> the requirement is clearly documented in a BCP or formal
> position statement that is subject to appeal at the time of
> publication and that is published prior to the document's
> entering Last Call.   This is the default option unless people
> persuade me otherwise, presumably that we should fall back to
> (2).
> 
> (4) Either instead of (3) or in addition to it, people could
> conclude that the behavior and argument that the IESG can and
> should do this because it thinks it can and has been doing so,
> despite any documentation or evidence of consensus, is
> sufficiently abusive that the AD in question should be singled
> out as an illustrative example and recalled.  I will not
> initiate such an action, partially because I believe it would be
> justified only if an AD continued to resist after losing an
> appeal (remember that the IAB cannot require the IESG to take a
> particular standards action) but, if someone else decided to do
> so, I would probably feel obligated to sign a well-designed
> petition.
> 
> What is your pleasure?
> 
>      john
> 

Date: Thu, 05 Jun 2008 10:52:28 -0700
From: Dave Crocker <[email-masked]>
Reply-To: [email-masked]
Organization: Brandenburg InternetWorking
To: John C Klensin <[email-masked]>
CC: [email-masked], Lisa Dusseault <[email-masked]>, Tony Hansen <[email-masked]>
Subject: Re: IESG approval status of  rfc2821bis
Sender: [email-masked]

John C Klensin wrote:
> Neither 2606, nor the "Guidelines", nor even "IDNits" require
> those names. 
...
>> "SHOULD preferably" and "preferably" are, I believe obviously,
>> statements of preference, not firm requirements. 
...
>> (3) The DISCUSS Criteria document
>> (http://www.ietf.org/IESG/STATEMENTS/discuss-criteria.html)
>> does not list the use of non-2026 names as an item on the
>> list of criteria in Section 3.1.  Indeed, it explicitly
>> discourages DISCUSSion for "Pedantic corrections to
>> non-normative text" and "Stylistic issues of any kind" in
>> section 3.2.

A nicely compelling bit of background. But then, it *is* from John...

And I really am quite loathe to suggest that John's typically lengthy and
typically thorough analysis is incomplete, but this time, I must:

> My position in general is that
> 
> 	(i) The IESG does not get to invent rules that are then
...
> 	I do not believe that "the IESG has been doing this for
> 	years" constitutes evidence that the community has
> 	approved of the IESG's doing so.
...
> 	it is abusive --an example of a completely unnecessary
> 	very late review "gotcha" surprise-- for the IESG to
> 	impose this rule without documenting it in any of the
> 	criteria statement documents identified above. 
...
> 	2026, Section 6.5.3, "the procedures themselves ... are
> 	... inadequate or insufficient to the protection of the
> 	rights of all parties in a fair and open Internet
> 	Standards Process".  
...
> The one issue that _is_ specific to 2821bis (and 2821) is that
> DRUMS explicitly considered the question of what to do about the
> 821 examples.  

Two points are missing:

    1) Undue cost for making a *bis revision

    2) Protecting the installed base.

Seriously.

Imagine hiring a licensed electrician to add a new outlet to a room in your 
house and having them tell you that making this small change means that you 
also are required to bring the entire house up to conformance with all health 
and safety building codes that have been added since the house was built, 
thirty years ago.  This include making all earthquake, insulation and 
electrical modifications to meet current building requirement.

The basis for the cited Discuss has exactly this sort of logic and implication.

When revising a document, the cost of the revision should be commensurate with 
the community need for the changes.  RFC2821bis is a very small effort to make 
minimal changes to a successful document.  It is simply not reasonable to 
start imposing more recent requirements -- assuming they really are valid 
requirements -- absent a compelling demonstration of damage that will accrue 
without the change.

RFC2821 has extremely broad use by industry.  When designing changes to a 
successful protocol, we are careful to make changes in a way that protect the 
installed base of technology.  We look for ways to make small, incremental 
changes so that what worked before works now.  The same criterion should be 
applied to the specification document, itself:  There is a large installed 
base of people who are familiar with RFC2821.  The revised document should 
remain as familiar in style and details as possible.  Changes imposed on the 
trained population of technicians should only be for fixing compelling problems.

That is, after all, why this is a *bis, rather than a brand new effort.

The examples don't qualify as having a compelling need to be changed.

> (3)  I can launch an appeal, following the outline above and
> asking for two specific remedies: 

I think your assessment of the facts and the implications are exactly correct.

I think that alternative 3 should, indeed, be the default path.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

Date: Thu, 05 Jun 2008 11:52:35 -0400
From: John C Klensin <[email-masked]>
To: [email-masked]
cc: Lisa Dusseault <[email-masked]>, Tony Hansen <[email-masked]>
Subject: IESG approval status of  rfc2821bis
Sender: [email-masked]

Hi.

We have reached an impasse with the IESG about how to proceed
with 2821bis.  The problem is an outstanding DISCUSS about
changing all of the examples that do not use RFC 2606 (e.g.,
"example.com" and friends) names to use that convention, with
the possible exception of those that point to ISI or USC.   I
now have an explicit note in hand that says "I await a revised
document or an appeal", so we are now at a choice point.   I'm
inclined toward an appeal or other push-back action but am not
the only one who would be affected by a further delay with this
document, so want to explain the situation as I see it.

There has been fairly extensive correspondence on this subject.
I've tried to summarize the situation from my point of view
below in as short a form as possible.  Lisa and Tony have, I
believe, seen all of it and may have a different take on what is
going on.  If either does, I hope they will say something.

Neither 2606, nor the "Guidelines", nor even "IDNits" require
those names.  2606 (the only consensus document on the subject)
says things like "can be used" and does not even express an
explicit preference for them.

There are three IESG position statements that might bear on the
issue.  Quoting from one of the earlier notes...

> (1) The "Guidelines to Authors of Internet Drafts"
> (http://www.ietf.org/ietf/1id-guidelines.html) does not
> mention the issue of examples at all.
>
> (2) The I-D Checklist (IDnits,
> http://www.ietf.org/ID-Checklist.html), Section 6, says
>
>         "Addresses used in examples SHOULD preferably use
>         fully qualified domain names instead of literal IP
>         addresses, and preferably use example fqdn's such as
>         foo.example.com instead of real-world fqdn's."
>
> "SHOULD preferably" and "preferably" are, I believe obviously,
> statements of preference, not firm requirements.  That is
> especially true of the second one, which doesn't even contain
> the word "SHOULD".
>
> (3) The DISCUSS Criteria document
> (http://www.ietf.org/IESG/STATEMENTS/discuss-criteria.html)
> does not list the use of non-2026 names as an item on the
> list of criteria in Section 3.1.  Indeed, it explicitly
> discourages DISCUSSion for "Pedantic corrections to
> non-normative text" and "Stylistic issues of any kind" in
> section 3.2.

The AD holding the DISCUSS (you can easily find out from the
tracker, but I believe this is about principles rather than
personalities and am generally happy with that AD's performance)
has indicated that he doesn't like these names and considers
their use "rude" and that the IESG has been enforcing the use of
2606 names as a firm rule for "at least five years".

My position in general is that

	(i) The IESG does not get to invent rules that are then
	used to block progression of a document without
	consulting the community.
	
	(ii) Given the pressure on authors --especially WG
	Chairs and document editors-- to simply go along with AD
	demands and preferences, reasonable or not, in order to
	get documents published rather than permanently stalled,
	I do not believe that "the IESG has been doing this for
	years" constitutes evidence that the community has
	approved of the IESG's doing so.
	
	(iii) Even if one were to concede that the IESG has the
	authority to make this a requirement (which I do not),
	it is abusive --an example of a completely unnecessary
	very late review "gotcha" surprise-- for the IESG to
	impose this rule without documenting it in any of the
	criteria statement documents identified above.   I have
	suggested in a few of my notes that, if the IESG wants
	to impose rules like this, it should move to revise one
	of more of those documents (presumably the I-D
	Checklist) to specify the requirement and see if the
	community accepts that additional rule once it is
	written down.   Of course, they could also initiate an
	update to 2606 that changes "can be used" into "MUST be
	used unless the IESG grants a waiver".  There has been
	no response to either of those suggestions.
	
	(iv) Since this blocking DISCUSS is inconsistent with
	the IESG's published statements about conditions for
	such actions (in the absence of a mandate from a
	consensus document, it appears to be an "editorial
	preference") and there seems to be no practical way to
	un-block it, it is a case in which, excerpting from RFC
	2026, Section 6.5.3, "the procedures themselves ... are
	... inadequate or insufficient to the protection of the
	rights of all parties in a fair and open Internet
	Standards Process".  Of course, that would be irrelevant
	if the IESG were to reverse itself and unblock this
	document during the appeal process.

I note that none of those three issues is specific to 2821bis.
They are really about how the IESG manages and expresses its
authority and discretion.  There is one more general issue,
which is what changes it is reasonable to demand to a document
being progressed from one maturity level to the next.  2026 is
not specific about this, but I believe that its language
combines with a presumed general belief that we should put as
few unnecessary stumbling blocks in the path of advancing
documents to argue that late-review/ late-surprise requirements
for cosmetic changes are inappropriate.

The one issue that _is_ specific to 2821bis (and 2821) is that
DRUMS explicitly considered the question of what to do about the
821 examples.  In fairness, I don't know how much the WG was
influenced by my personal preferences, but the conclusion was to
eliminate the references to .ARPA (because they were distracting
and clearly impossible given the current role of that domain)
but otherwise to preserve Jon Postel's examples (not just the
ones that used USC or ISI domains) to the extent possible.
DRUMS reached consensus on what became 2821 and the IESG signed
off on it.   So this DISCUSS within the IESG now effectively
overrides, not only discussions and conclusions on this mailing
list, but the presumably-informed discussions of the original
WG.   And, for better or worse, another few months of delay in
getting 2821bis published probably makes less difference than
would be the case for a new Proposed Standard for which people
are anxious to deploy conforming implementations, so I'm feeling
less pressure to "just go along" than the typical WG editor
might.

I believe that there are four possible ways forward, at least
ones that I wouldn't find very offensive (I'm open to other
ideas):

(1) I have offered the AD in question the option of changing the
DISCUSS to a Comment, thereby dropping the implicit assertion
that the IESG (or, even worse, one AD) has the right to
_require_ this type of change at this point in the process.  I
have indicated informally that, if that change were made, I
would "probably" change the examples.   While I haven't said it
explicitly to the AD or IESG, the only condition on the changes
would be my checking with this list to see if anyone strongly
and persuasively objected.   In either this case or the next
one, I would rewrite the Acknowledgments to explicitly point to
Jon's role and examples and clear the text with this list (in
retrospect, that may be what we should have done for 2821).
The option of making the DISCUSS -> Comment change has been
declined (at least I have gotten no response to it in any of the
discussions).

(2) People can convince me that the principles I see here aren't
very important and we should just give in, make the changes, and
get the document published.  To me, that is equivalent to
agreeing that it is ok for the IESG to have essentially-secret
rules, developed without community consensus and undocumented in
any description for I-D requirements, and then impose those
rules using permanent blocking DISCUSS positions after Last
Call.  I believe that agreement would be bad news, but perhaps
I'm being naive and the relevant horse is sufficiently out of
the barn that it is time to acknowledge that, e.g., selection to
the IESG is equivalent to anointment as a member of a group with
imperial powers and divine right.

(3)  I can launch an appeal, following the outline above and
asking for two specific remedies: (i) approval of this document
as-is and (ii) a firm requirement that no AD issue a blocking
DISCUSS on any editorial or other non-technical subject unless
the requirement is clearly documented in a BCP or formal
position statement that is subject to appeal at the time of
publication and that is published prior to the document's
entering Last Call.   This is the default option unless people
persuade me otherwise, presumably that we should fall back to
(2).

(4) Either instead of (3) or in addition to it, people could
conclude that the behavior and argument that the IESG can and
should do this because it thinks it can and has been doing so,
despite any documentation or evidence of consensus, is
sufficiently abusive that the AD in question should be singled
out as an illustrative example and recalled.  I will not
initiate such an action, partially because I believe it would be
justified only if an AD continued to resist after losing an
appeal (remember that the IAB cannot require the IESG to take a
particular standards action) but, if someone else decided to do
so, I would probably feel obligated to sign a well-designed
petition.

What is your pleasure?

     john