Re: [Gen-art] Gen-ART review of draft-ietf-behave-lsn-requirements-07

[Pete Resnick <[e-mail]>]

On 7/17/12 5:14 PM, John C Klensin wrote:

> --On Tuesday, July 17, 2012 13:57 -0500 Pete Resnick
> <[e-mail]>  wrote:
>
>    
>> Perhaps I'm just being contrarian today, but I *do* think this
>> document should be BCP and not Informational. It is not a
>> requirements document in the sense that it is laying out
>> requirements for future protocol documents being developed by
>> a WG; it is a consensus document listing the requirements for
>> the operation and administration of a type of device. If that
>> doesn't fall within the 2nd paragraph of RFC 2026 section 5, I
>> don't know what does.
>>      
> Just to be disagreeable...
>
> I think "requirements for the operation and administration of a
> type of device" puts it squarely into the "Applicability
> Statement" range, in part of permit testing of those
> requirements and advancement along the standards track.  Of
> course, the precedent is RFCs 1122 and 1123 which requirements
> for operation and administration as well as for protocol
> conformance and are clearly applicability statements (and more
> or less the prototype for that category).
>    

Just to be somewhat agreeable... ;-)

Normally, I would be right with you and say, "This should be on the 
standards track." However, this document is about CGNs. It's about 
things that are almost by definition not nice interoperable players on 
the Internet. They are messy local devices for (albeit large) local 
networks. Indeed, there are many folks who think that horrific plagues 
be visited upon those who deploy CGNs and that they should be dismantled 
as soon as humanly possible, if not before. But in any event, this is 
not really a spec "for hardware and software required for computer 
communication across interconnected networks", but rather is a document 
for "networks operated by a great variety of organizations, with diverse 
goals and rules" to provide "operators and administrators of the 
Internet follow some common guidelines for policies and operations". Or 
at least I think a strong case can be made for that. I think that's why 
several other behave documents ended up being BCPs. I could make an 
argument for standards track, but I think BCP is a reasonable 
alternative conclusion to come to as well for this particular document.

pr

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