Re: [yam] Status: draft-ietf-yam-rfc1652bis-pre-evaluation-00

[S Moonesamy <[e-mail]>]

Hi Ned,
At 10:45 02-11-2009, Ned Freed wrote:
The reqson I haven't bothered to answer is AFAICT there's really nothing to
>say. Lisa's DISCUSS states:

Alexey mentioned off-list that the matter [1] is no longer outstanding.

>And if you want to have a discussion of how old specifications that have
>inadequate security considerations will be updated, fine, but let's 
>not pretend
>that having this discussion in the context of 1652bis is going to produce
>meaningful results. Indeed, it seems to me that this DISCUSS is, properly
>spealing, a DISCUSS about the overall YAM process that the IESG 
>needs to decide
>for itself. But as a topic for a WG response pertaining to the document at
>hand, it is entirely inappropriate and wrongminded.

The comments are about the YAM process.  The first pre-evaluation I-D 
was a way to determine how the overall YAM process would work.

>With all due respect, I think we're WAY past the point where this degree of
>indirection is anything but a hindrance to forward progress. The IESG needs to
>state, clearly and directly to this WG, what their concerns are.

I posted all the (formal) information I have available.  I'll pass 
the above to the WG Chairs.

>Well, if that's the case in general, then this effort is effectively over, and
>we might as well disband this group right now and save ourselves a lot of
>pother. Because if downrefs aren't going to be allowed, we're screwed because
>references to things like TLS are never going to make it to standard in the
>necessary time frame.

I agree with you about the downrefs (personal opinion).

>And I think the appropriate response to that is, "So what?" We appear to be so
>wrapped up in nailing down every last detail of the process for every
>conceivable document we might consider that we're losing sight of the actual
>goal here, which is to address the minimal set of *technical* issues needed to
>get the various core email specifications to Standard.

Personal opinion again, it is not possible to nail down every detail.

>For starters, the reference to RFC 822 in RFC 1652 is for ABNF and nothing
>else, so it upgrades cleanly to RFC 5234 - already a Standard, no downref
>needed. There's no need to reference RFC 5322 for this purpose at all.
>
>I'll also take this opportunity to point out that this is actually an error in
>draft-ietf-yam-rfc1652bis-pre-evaluation-00, which states that what 
>needs to be
>done is update the reference to RFC 5322. So it seems that while 
>frothing about

I made a note of the above.

>As for the reference to RFC 821, the purpose of it is to get at the definition
>of what's allowed in a message. I don't think a credible argument can be made
>that the definition of the overall syntax of a basic message (i.e., 998
>chearacter or less CRLF delimited lines of 7bit ASCII), is ever going to
>change. Pigs will travel at lightspeed first.
>
>Finally there's the reference to RFC 1651. The plan is to replace this with a
>reference to RFC 5321, which is a fine plan, but if that's a downref 
>issue then
>a reference to RFC 1651 - a Full Standard - could simply be retained.

Noted.

>Well, you asked. My comment is that I think this feedback has the 
>direct effect
>of hanging this entire effort on the slenderest of threads, and the indirect
>effect of locking in the present reality that our real process operates in two
>steps, not three, irrepective of what our process documents say.

I caught what you meant in the last sentence on the second reading.

Regards,
S. Moonesamy
YAM WG Secretary

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