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

[Ned Freed <[e-mail]>]

> The IESG has completed its evaluation of
> draft-ietf-yam-rfc1652bis-pre-evaluation-00.  There is an outstanding
> issue about Security Considerations.  I posted a message about that
> at http://www.ietf.org/mail-archive/web/yam/current/msg00132.html

The reqson I haven't bothered to answer is AFAICT there's really nothing to
say. Lisa's DISCUSS states:

  One of the big questions discussed about whether older email standards could
  go to Full Standard was whether the security provisions were sufficient --
  whether authentication and privacy met our modern requirements, or if not,
  whether Full Standard was acceptable anyway because of historical
  considerations.

  If that is in fact going to be an issue, then this pre-eval document doesn't
  address that or or make the IESG think about that.  Future pre-eval documents,
  if we stick with this WG model, could reasonably compare the standard's
  security to modern requirements.  This DISCUSS position is so that we can
  talk about these issues on the call.

if there's anything in there about the security considerations in RFC 1652
needing to change, or for the discussion of such changes in this pre-evaluation
meta-document, I for one sure don't see where they are identified in this
DISCUSS.

It is of course self-evidenct that RFC 1652 doesn't raise as many (or any)
security issues as other specifications YAM is chartered to work on will. But
this is hardly RFC 1652's fault - in fact I thought it was supposed to be sort
of a Good Thing when documents don't have many (or any) security concerns. And
when specifications that do have security concerns are processed, it will be up
to the WG to propose and the IESG to review whatever changes are deemed
appropriate to address those concerns. I would hope that this is all blindingly
obvious.

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.

> I received some feedback from the Alexey.  I edited the information for
> this status update.

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.

> The IESG is fine with all the changes except for the
> downreferences.  The format is generally Ok, several ADs commented
> that the pre-evaluation document was useful.

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.

If this is a more selective thing (and I see no evidence that it is or isn't - 
the IESG evaluation record is singularly unhelpful on figuring out exactly what
this downref problem is), then the IESG needs to explain the actual policy
behindd their selective allowance of downrefs.

> The following paragraphs are about the process.  The general view was
> that the IESG cannot really judge the process by doing a simple
> document.

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.

> It doesn't make sense to approve extensions first, then
> run into the possibility of not approving changes to the document
> being  extended.  The WG should move the main documents first instead
> of the dependent documents.

And again, if that's supposed to be generally applicable rule, this effort is
effectively over.

> The IESG would like to ask the YAM WG to evaluate a core document
> such as RFC 5321 or RFC 5322.  It is viewed that the evaluation of
> these documents is more likely to highlight issues that might be
> relevant to all the other documents.

OK, so let me play process weenie for a minute, and point out that while this
might arguably make sense as a better way to vet the YAM process, this makes no
sense at all in the context of 1652bis.

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
process generalities, nobody bothered to, you know, actually look at the
*technical* details of the current proposal.

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.

Moreover, if you're going to worry about downrefs in the context of RFC 1652,
the thing to be looking at isn't SMTP or core message format stuff, but MIME.
An argument that a downref to MIME could be problematic could be made a lot
more easily. Mind you. I still don't think rises to the necessary level to
prohibit the downref, but it's a vastly more credible arugment than one
involving 5321/5322. So does this mean we also need to advance MIME to Standard
first?

> The next step the AD recommends is to review RFC 5321 and come back
> to 8BITMIME once the pre-evaluation of RFC 5321 is complete.

> Please comment on the above.

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.

				Ned