Re: Appeal against IESG blocking DISCUSS on draft-klensin-rfc2821bis

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]