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

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

 



On 6/18/08 at 10:35 PM -0400, Russ Housley wrote:

The I-D Checklist (IDnits, http://www.ietf.org/ID-Checklist.html), Section 6, says:

    Addresses used in examples SHOULD preferably use
    fully qualified domain names instead of literal IP
    addresses, and preferably use example fqdn's such as
    foo.example.com instead of real-world fqdn's.

RFC 2119 has a pretty clear definition of "SHOULD".  It says:

    This word, or the adjective "RECOMMENDED", mean that there
    may exist valid reasons in particular circumstances to ignore a
    particular item, but the full implications must be understood and
    carefully weighed before choosing a different course.

Ahem. RFC 2119 is also pretty clear about two other things:

   In many standards track documents several words are used to signify
   the requirements in the specification.  These words are often
   capitalized.  This document defines these words as they should be
   interpreted in IETF documents.

I-D Nits ain't no "standards track document", and it barely qualifies as an "IETF document". It's certainly not an IETF consensus document.

But also:

6. Guidance in the use of these Imperatives

   Imperatives of the type defined in this memo must be used with care
   and sparingly.  In particular, they MUST only be used where it is
   actually required for interoperation or to limit behavior which has
   potential for causing harm (e.g., limiting retransmisssions)  For
   example, they must not be used to try to impose a particular method
   on implementors where the method is not required for
   interoperability.

Indeed, the real potential for causing harm or failure to interoperate in the case of 2821bis would be to change all of the examples to "example.org", inadvertently screw it up in some interesting way, and cause people to implement incorrectly. In the case of a document where almost all of the examples have been left alone, and those examples have been in use for 7 years without problems, the burden of proof is on you to demonstrate harm if you want to put a DISCUSS on the document. If you want to put a COMMENT on the document, it is incumbent on the document editors to review the decision of 7 years ago and have them explain why that path was chosen. But unless there is *demonstrable* harm at this point in the life cycle of the document, it's an editorial issue that does not warrant a DISCUSS.

(To wit: Wouldn't it have been amusing if John had changed all of the examples to fit 2606 names and some AD came along and said, "DISCUSS: This document is heading for Draft Standard after 7 years of deployment. Even though I can't see an overt problem in the examples now used, changing them from perfectly good examples that have interoperated for 7 years without problem has the potential for harm. Please change them back to their original forms." I'd be far less in favor of an appeal against *that* DISCUSS.)

pr
--
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102
_______________________________________________
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]