On Fri Jun 20 18:14:33 2008, Russ Housley wrote:
First, looking at a diff of RFC 2821 and draft-klensin-rfc2821bis,
I do not find the argument about continuity very questionable.
This document does include some clarification and lessons learned,
and it includes much more too.
Your first sentence contains a freudian slip, I think.
But so people can sing along at home:
http://tools.ietf.org/rfcdiff?url2=http://tools.ietf.org/id/draft-klensin-rfc2821bis-10.txt&url1=http://tools.ietf.org/rfc/rfc2821.txt
I am not saying that any of the changes are inappropriate, but that
it is hard to claim that the changes are minimal.
I think it's a demonstrably easy claim to make:
Important to note is that the only new domain introduced by the
document is an example.com one (a change in section 4.3.1 of both
documents).
This also represents one of four cases where the examples or
explanatory text surrounding them were changed at all. The others
were:
Section 4.1.1.3, the word "appendix" was capitalized to "Appendix" in
one paragraph, and another paragraph was (very) slightly reworded.
(Removal of "Of course", and captilization of "MAY"). I'm not sure
this counts at all, but it's offered as a straw for the IESG to
clutch at.
Appendix D.3, the example was reworked to change from a source route
relay to an MX lookup - this is a comparitively major change, but
note from the diff that essentially it's adding some explanatory
text, and then changing the MAIL FROM lines - nothing else in the
examples is changed.
Finally, Appendix D.4 corrects an error - it's a single word change
from SEND to MAIL.
I don't think it would be at all fair to claim that the changes to
the examples - which is the significant item here - are anything but
minimal, and it's quite obvious to me as to why this is the case.
Examples, and particularly changing them, is a tough thing to get
right in application protocols. By my own experience, I tend to find
that my own example mismatch the text in early stages (and that often
leaks through to late stages); changing examples can often lead to
mismatches between discussion and example, for example if xyz.com and
foo.com were inconsistently changed to example.com and example.net;
and finally I see broken examples in the documents I review.
This is of special concern because whilst we publically chastise
implementors for only reading the examples, the fact remains that
most of us certainly rely on the examples for getting the jist of a
protocol, and turn to the rest of the text afterward, having formed
our preconceptions nice and early on.
Moving back from the general to the specific, then, it's important to
note that the examples are therefore substantially unchanged from
those which DRUMS WG carefully weighed and understood the full
implications thereof.
I'd note, as an aside, that whilst it could be argued that
ID-Checklist has a SHOULD which covers the later part of the sentence
and therefore SHOULDs the RFC 2606 names, the ID-Checklist does not
itself specify that SHOULD is to be interpreted using RFC 2119, and
therefore arguably doesn't even say SHOULD, as such.
It'd be fairly petty to argue this as a significant point, but I hope
that even if this and the (rather more serious) odd phrasing in the
ID-Checklist is overlooked, the resultant argument - that rfc2821bis
ignores a SHOULD - is essentially baseless, as the examples in
question were substantially the result of heavy consideration from a
working group, and have been previously accepted by the IESG.
Second, from my perspective, the dialogue about this document did
not happen as you suggest.
And that's a fine explanation of why the situation has arisen, but it
doesn't (or shouldn't) affect the outcome of the appeal - I'd have
thought that one of the great benefits of an appeal is that more
information is made available to the IESG so as to enable them to
correct a bad decision or confirm a good one. It's unfortunate that
appeals are sometimes perceived as a way to slap wrists.
Appeals are, surely, meant as a mechanism for the community to say:
Are you really sure you want to go down this route, because it looks
to me like there's stuff you've missed, and/or you've not thought
this through, and I'd like you to carefully reconsider.
In another message, you state: "Don't we select leaders because we
have some confidence in their judgement?" - we do, of course, select
them because we think they'll be right the majority of the time, and
willing to accept when they're wrong, too.
Dave.
--
Dave Cridland - mailto:dave@xxxxxxxxxxxx - xmpp:dwd@xxxxxxxxxxxxxxxxx
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
_______________________________________________
IETF mailing list
IETF@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf