Subject: Re: [yam] Status: draft-ietf-yam-rfc4409bis-00

From: S Moonesamy <[email-masked]>
Date: Wed, 20 Jul 2011 07:44:50 -0700

Hi John, Randy,

I posted a rough summary of the WGLC at 
http://www.ietf.org/mail-archive/web/yam/current/msg00636.html  Could 
you please submit a revision of draft-ietf-yam-rfc4409bis-00 that 
takes into account the comments received during the WGLC?

I recommend avoiding any document changes that might even 
accidentally introduce protocol changes, destabilize the protocol, or 
introduce semantic or syntactic changes.

Regards,
S. Moonesamy
YAM WG co-chair

---

From: John C Klensin <[email-masked]>
Date: Wed, 20 Jul 2011 12:35:22 -0400

--On Wednesday, July 20, 2011 07:44 -0700 S Moonesamy
<[email-masked]> wrote:

> http://www.ietf.org/mail-archive/web/yam/current/msg00636.html
> Could you please submit a revision of
> draft-ietf-yam-rfc4409bis-00 that takes into account the
> comments received during the WGLC?
> 
> accidentally introduce protocol changes, destabilize the
> protocol, or introduce semantic or syntactic changes.

Hi.

I believe that I have already responded to that note at least
once.   A newly-constructed summary of the three issues listed
in that note follows:

(1) "SHOULD for RFC 6186".  Such a normative requirement would
be a very significant downreference.  It would also be a new
normative requirement, which is inappropriate when going to Full
Standard under current rules, especially since I've seen little
evidence that 6186 is widely enough deployed to justify a
requirement in a Full Standard.  As you note, I suggested that
it might be appropriate to consider this if there were an
implementation report on 6186 and (at least my implication)
significant steps toward getting it to Draft Standard at least.
I have seen no evidence of progress on either of those
dimensions.   I also note that RFC 6186 is not shown as Updating
4409.    IMO, the proper course of action, consistent with your
advice above, is to not include an explicit normative pointer to
6186.  When 6186 is updated, the revised version might well be
identified as updating 4409bis with the relevant pointers.  No
action in the current document is needed unless the co-chairs
indicate that there is consensus to do something and provide
clear instructions.

(2) Mentioning RFC 5451.  The only comments received indicated
that this should be a matter for either 5451bis or 5322bis, not
4409.  No action in the current document is needed unless the
co-chairs indicate that there is consensus to do something and
provide clear instructions.

(3) "not able to determine a return path".  I did not detect
consensus to do anything about this.  If the Chairs disagree,
please advise.

regards,
    john

---

From: S Moonesamy <[email-masked]>
Date: Wed, 20 Jul 2011 11:43:56 -0700

Hi John,
>indicate that there is consensus to do something and provide

RFC 6186 is a Proposed Standard and was published in March 2011.  I 
am not aware of any effort to move it to Draft Standard.  As you 
mentioned, RFC 6186 does not update RFC 4409.    A normative 
reference to RFC 6186 would be a downward reference.  As there hasn't 
been consensus for such a change and based on the current status of 
RFC 6186, I recommend no action in the current document.

>provide clear instructions.

There isn't consensus about mentioning RFC 5451 in the current document.

>consensus to do anything about this.  If the Chairs disagree,

After reading the YAM Charter and the WGLC comments, my advice is no 
action on this.

Regards,
S. Moonesamy
YAM WG co-chair

---

From: John C Klensin <[email-masked]>
Date: Wed, 20 Jul 2011 17:07:50 -0400

Hi.

--On Wednesday, July 20, 2011 11:43 -0700 S Moonesamy
<[email-masked]> wrote:

>...
> After reading the YAM Charter and the WGLC comments, my advice
> is no action on this.

Ok.  From the above and as far as I know, the only two changes
needed for -01 are:

	* The text about "aliases" discussed earlier.  The real
	issue is exactly what RFC 5321 prohibits when it
	prohibits the use of aliases.  IMO, that problem needs
	to be addressed there, not in 4409bis.  But, modulo that
	concern, the text is, IMO, now clear about what
	Submission servers are expected/ permitted to do.
	
	* A few small typographical errors, mostly resulting
	from the 4409-> 4409bis conversion, that were not caught
	earlier.

Unless you identify something else, I will get -01 posted as
soon after the posting window reopens Monday as I can manage.  I
believe the specification is then ready for IETF Last Call.

   john

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 21 Jul 2011 13:04:17 +0100

S Moonesamy wrote:

> RFC 6186 is a Proposed Standard and was published in March 2011.  I am 
> not aware of any effort to move it to Draft Standard.  As you 
> mentioned, RFC 6186 does not update RFC 4409.    A normative reference 
> to RFC 6186 would be a downward reference.  As there hasn't been 
> consensus for such a change and based on the current status of RFC 
> 6186, I recommend no action in the current document.

I would love for RFC 6186 being mentioned (can I bribe you guys :-)?). 
However I do agree that making it normative via use of SHOULD is too 
strong. Maybe an Informative reference?

<rant>
I do find all arguments around "we can't add this reference because it 
is going to be a downref" to be quite counter productive. Why are we 
being so process oriented when having a downref might be the right thing 
to do?
</rant>

> There isn't consensus about mentioning RFC 5451 in the current document.

I think mentioning RFC 5451 falls into a similar category to RFC 6186.

---

From: S Moonesamy <[email-masked]>
Date: Thu, 21 Jul 2011 08:54:00 -0700

Hi Alexey,
At 05:04 AM 7/21/2011, Alexey Melnikov wrote:
>I would love for RFC 6186 being mentioned (can I bribe you guys 
>:-)?). However I do agree

You can try. :-)

>  that making it normative via use of SHOULD is too strong. Maybe an 
> Informative reference?

That can be considered if an implementation report of RFC 6186 is provided.

><rant>
>I do find all arguments around "we can't add this reference because 
>it is going to be a downref" to be quite counter productive. Why are 
>we being so process oriented when having a downref might be the 
>right thing to do?
></rant>

I am not waving the "downref" argument from a purely process 
perspective.  The draft is intended to be published as a Full 
Standard.  In creating dependencies it is good if the maturity of the 
dependency is taken into account.  If the document has been stable 
for some time, it can be assumed that it has matured irrespective of 
what the label says.  For example, RFC 4409 may be a Draft Standard 
but the working group might recognize it as effectively at Full Standard.

There are changes that are "good to have" and changes that are a 
"must have".  The line between the two is not always clear.  The 
process angle is not about a "downref".   It is about figuring out 
what to do and drawing that line; and it should not be based on the 
whims of a WG Chair.

>I think mentioning RFC 5451 falls into a similar category to RFC 6186.

The proposed changes were evaluated on a case to case basis.  Murray, 
who happens to be the author of RFC 5451, agreed [1] that 
"Authentication-Results:" is not a 4409 field and that the work can 
be done in a 5451bis.

Regards,
S. Moonesamy
YAM WG co-chair

1. http://www.ietf.org/mail-archive/web/yam/current/msg00619.html

---

From: John C Klensin <[email-masked]>
Date: Thu, 21 Jul 2011 11:54:29 -0400

Alexey,

As editor, I consider it much more important to get this
document finished and out than to have extended arguments about
references or philosophy.   That said, I was trying to respond
to Subramanian's note and issue list as the issues were stated
there.  Comments below from a slightly different and more
personal perspective, leaving the Full Standard and current YAM
requirements aside entirely...

--On Thursday, July 21, 2011 13:04 +0100 Alexey Melnikov
<[email-masked]> wrote:

>...
>> RFC 6186 is a Proposed Standard and was published in March
>> 2011.  I am  not aware of any effort to move it to Draft
>> Standard.  As you  mentioned, RFC 6186 does not update RFC
>> 4409.    A normative reference  to RFC 6186 would be a
>> downward reference.  As there hasn't been  consensus for such
>> a change and based on the current status of RFC  6186, I
>> recommend no action in the current document.
> 
> I would love for RFC 6186 being mentioned (can I bribe you
> guys :-)?). However I do agree that making it normative via
> use of SHOULD is too strong. Maybe an Informative reference?
> 
> <rant>
> I do find all arguments around "we can't add this reference
> because it is going to be a downref" to be quite counter
> productive. Why are we being so process oriented when having a
> downref might be the right thing to do?
> </rant>

What is said when a few of these things were being discussed
earlier wasn't really about downrefs.  I have a bias that, if we
are going to direct someone from a Full Standard (or usually
even a Draft Standard) to something in a way that encourages
them to look at and use it, it should be relatively proven
rather than something we might take a look at in a few years and
say "never mind" (or worse, with the current 6to4 snit being an
example).  "Direct someone" is deliberately informal and vague.
Certainly it applies to a normative requirement, so we agree
about SHOULD.

For an informative reference, my threshold for "relatively
proven" is fairly low, but it is still higher than "no known
defects" or "looks good in theory and on paper".  That is
precisely why I asked about implementation reports: if it can be
shown that there is significant conforming implementation and
non-trivial deployment of the 5451 or 6186 specs, then a note
that essentially says "others have found these useful in
conjunction with submission servers, you ought to consider them
too" is appropriate, even if it doesn't get to a SHOULD-level
requirement.  On the other hand, to the extent to which there
are few production implementations and deployments, it would be,
IMO, better to think about the right timing for either updates
to 5451 and 6186 or an Applicability Statement that would update
both and 4409bis to specify that implementers of submission
servers should look at those specs and MAY (or SHOULD) support
them.

> I think mentioning RFC 5451 falls into a similar category to

Yeah.  See above.

Just my opinion.
    john

---

From: S Moonesamy <[email-masked]>
Date: Thu, 21 Jul 2011 11:26:07 -0700

Hi John,
>believe the specification is then ready for IETF Last Call.

I am okay with the above.  If WG participants do not have any 
concerns about the above changes and -01, an IETF Last Call will be requested.

Even if some of the changes proposed have not made it into the draft, 
it does not mean that they do not have any merit.

Regards,
S. Moonesamy
YAM WG co-chair

---

From: John C Klensin <[email-masked]>
Date: Mon, 25 Jul 2011 17:56:46 -0400

--On Thursday, 21 July, 2011 11:26 -0700 S Moonesamy
<[email-masked]> wrote:

> Even if some of the changes proposed have not made it into the
> draft, it does not mean that they do not have any merit.

Per the above, 4409bis-01 has been posted.
   john

---

From: S Moonesamy <[email-masked]>
Date: Tue, 26 Jul 2011 00:37:48 -0700

Hi John,
>Per the above, 4409bis-01 has been posted.

The following nits could be fixed by the RFC Editor:

  1. Appendix B mentions that RFC 5322 is a downward reference but the
     MESSAGE-FORMAT reference is under Informative References.

  2. The DKIM reference can be changed to point to the "Draft Standard"
     that is already in the RFC Editor queue.  I suggest that Tony asks
     Barry about that.

I noticed a few other nits but I won't mention them as they fall 
under stylistic changes.    I do the write-up after the YAM session.

Regards,
S. Moonesamy

---

From: Barry Leiba <[email-masked]>
Date: Tue, 26 Jul 2011 12:00:09 -0400

>    that is already in the RFC Editor queue.  I suggest that Tony asks

No one needs to ask me.  Both DKIM references, [RFC4871][RFC5672],
should be changed to one reference to [draft-ietf-dkim-rfc4871bis],
and the editors know how to do that.

Barry

---

From: Randall Gellens <[email-masked]>
Date: Tue, 26 Jul 2011 13:57:38 -0700

Sorry for not replying sooner.  I concur with John.

One thing I miss from the Internet Mail Consortium days was Paul's 
web page listing all email RFCs grouped by protocol.  Such a resource 
would be an excellent place to list RFC 6186 in reference to 
submission.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
Look Bruce, the bat signal!!!

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 27 Jul 2011 14:44:04 +0200

> and the editors know how to do that.

Can the same be done for draft-ietf-yam-5321bis-smtp-pre-evaluation?

---

From: John C Klensin <[email-masked]>
Date: Wed, 27 Jul 2011 11:10:33 -0400

--On Tuesday, 26 July, 2011 12:00 -0400 Barry Leiba
<[email-masked]> wrote:

>>  2. The DKIM reference can be changed to point to the "Draft
>> Standard"    that is already in the RFC Editor queue.  I
>> suggest that Tony asks    Barry about that.
> 
> No one needs to ask me.  Both DKIM references,
> [RFC4871][RFC5672], should be changed to one reference to
> [draft-ietf-dkim-rfc4871bis], and the editors know how to do
> that.

The editor has changed the citation to use "DKIM" rather than
the RFC number and added instructions to the RFC Editor.

   john

---

From: John C Klensin <[email-masked]>
Date: Wed, 27 Jul 2011 12:12:45 -0400

--On Wednesday, 27 July, 2011 14:44 +0200 Alessandro Vesely
<[email-masked]> wrote:

> Can the same be done for
> draft-ietf-yam-5321bis-smtp-pre-evaluation?

I'm not sure what you are asking, since that document isn't
going anywhere, but I think you can safely assume that any new
version of 5321bis will have up-to-date references even if the
relevant documents changed after the pre-eval document was
completed.

At the risk of being a little impolite, give me credit for
having a bit of a clue and for caring enough about 5321 that I'm
not going to open it without planning to do a competent job.

    john

    john

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 28 Jul 2011 17:08:53 +0200

On 27/Jul/11 18:12, John C Klensin wrote:
> going anywhere [...]

Does that mean it will just get lost in oblivion?

> not going to open it without planning to do a competent job.

Don't mention it, I certainly do.

However, that document contains knowledge that will not be properly
available for a long time, if yam is shut down so abruptly as to not
even complete half-baked work.  If that's the fate of yam, I'd rather
publish the pre-evaluation document as-is (much like what was done
with RFC 5672.)

jm2c

---

From: S Moonesamy <[email-masked]>
Date: Fri, 29 Jul 2011 13:50:02 -0700

Hi Alessandro,
>Does that mean it will just get lost in oblivion?

draft-ietf-yam-5321bis-smtp-pre-evaluation-05 has expired.

>publish the pre-evaluation document as-is (much like what was done

draft-ietf-yam-5321bis-smtp-pre-evaluation-05 is different from RFC 
5672.  That RFC updates RFC 4871 whereas the pre-evaluation I-D was 
generated for IESG processing.  The Abstract section clearly states 
that the I-D is not meant to be published as a RFC.

Regards,
S. Moonesamy

---

From: Alessandro Vesely <[email-masked]>
Date: Sat, 30 Jul 2011 10:49:49 +0200

Hi SM,

> that the I-D is not meant to be published as a RFC.

Correct, that meaning was derived from the two-step method.  Since we
changed our mind on the method, as well as on yam itself, we could as
well change the destiny of that draft and publish it.  I think it will
take less than an hour to amend the abstract by replacing that
restriction with an explicative paragraph.  The WG and the IESG
already approved that document, so it can go to the RFC editor
directly, AFAICS.

Getting the document together roughly took the time from John's
setting aside his rfc5321-numbered on 14 Dec 2008, through first
pre-evaluation version on 12 Nov 2009, to IESG's approval announced on
26 May 2010.  I see no need to rot it away.

---

From: S Moonesamy <[email-masked]>
Date: Sat, 30 Jul 2011 20:35:27 -0700

Hi Alessandro,
>already approved that document, so it can go to the RFC editor

The YAM WG approved the document for IESG processing.  The IESG 
processed the document and provided feedback to the YAM WG.  The IESG 
did not approve the publication of the document as a RFC.  Amending 
the document for publication is not a trivial effort.  It will have 
to go through IESG Evaluation.

The WG Chairs cannot change the destiny of the document or violate 
the working group charter.  The Responsible Area Director, the WG 
co-chair and the editors of the document will ask me to get a clue if 
I suggest publishing the document.

Regards,
S. Moonesamy