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

[S Moonesamy <sm+ietf at elandsys.com>]

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