Re: [apps-discuss] Review of draft-ietf-appsawg-rfc3536bis-04

[Pete Resnick <[e-mail]>]

On 7/1/11 3:00 PM, John C Klensin wrote:

> --On Friday, July 01, 2011 12:24 -0400 Andrew Sullivan
> <[e-mail]>  wrote:
>
>    
>> Obviously, the draft can't constrain what other documents
>> might do. But it would be nice to encourage other documents,
>> if they're going to come up with different definitions, to use
>> different words.  If someone decided to re-define SHOULD at
>> the beginning of their standards document, we would quite
>> justifiably complain,&  I think the same goes here.  I suggest
>> the following additional sentence:
>>
>>      IETF standards that want different definitions are
>> encouraged, for     clarity's sake, to find terms different to
>> the ones defined here.
>>      
> In drafts of this document up this stage, we have tried to
> preserve the informative/ descriptive/ persuasive tone of RFC
> 3536 while pushing in the direction I think you are encouraging.
> Some IESG members have pointed out that the document doesn't
> sound normative enough to be a BCP.  In retrospect, trying to
> circle around the issue (for which I am more to blame than Paul)
> was probably unwise.  Depending on what the IESG has to say
> (i.e., what Pete tells us), we are contemplating rewriting that
> explanation into RFC 2119 language and simply saying that these
> definitions SHOULD be used in IETF documents and that, if people
> choose to not use them, they MUST define the terms they are
> using exactly and preferably use terminology that does not
> overlap.
>    

As I have mentioned to Paul offline, there was some pretty stiff 
pushback on this being BCP. Some of it was of the form, "You haven't 
said it strongly enough" (like Dan's DISCUSS comment, where he and 
others would *prefer* this document to be a BCP), and I think with some 
changes, those folks are right on board. There are other ADs (nominally 
Russ, though there are others who support his position) who felt that in 
no event was a glossary the appropriate sort of thing for BCP status; it 
is replacing an existing Informational document, and it isn't clear that 
glossaries are appropriate for BCPs. RFC 2026 is not at all precise on 
this; the only category of BCP this could really fall under is if this 
is meant to "document the operation of the IETF itself", which means to 
me that it is a "documentation procedure" (i.e., "we shall use these 
definitions"). The IETF has a perfectly mixed record on whether 
glossaries are BCP Informational, so precedents are unclear, the 
extremes being RFC 2119 (a BCP that defined several terms for use in 
IETF documents as normative protocol interoperability statements) and 
RFC 2828 (an Informational document that has a nice list of security 
terms and their definitions, but their use is strictly informational).

As I suggested, Paul has already written to the IESG some explanation of 
why this document ought to be a BCP. I encourage the document editors to 
continue that discussion. Important to the discussion is why you think 
it is necessary and justified that this document to be a BCP instead of 
an Informational RFC.

This document will at the very least be published as Informational. But 
I have put it back on the next IESG telechat to continue the 
conversation. On 14 July, we're going to make a call one way or the 
other. Please complete your discussion before then.

pr

-- 
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Incorporated - Direct phone: [phone], Fax: [phone]