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

[Dave Cridland <[e-mail]>]

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:[e-mail] - xmpp:[e-mail]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
_______________________________________________
IETF mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ietf