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

[Pete Resnick <[e-mail]>]

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: [phone], Fax: [phone]
_______________________________________________
IETF mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ietf