Re: [tcpm] WGLC: draft-ietf-tcpm-tcpsecure-10.txt

[David Borman <[e-mail]>]

On Sep 19, 2008, at 2:04 PM, Joe Touch wrote:

...
>> But even if you do view it as a hierarchy, it is nothing out of the
>> ordinary.  No optional standard is going to be a MUST for who needs  
>> to
>> implement it, but then the rest of the standard itself will have  
>> still
>> have MUSTs in it for how to do the implementation.
>
> This is the part that others have commented to me on, and the primary
> point of my note. If we can point to an optional standard that has  
> MUSTs
> therein, fine. If not, we're blazing new ground.

That's easy, just look at any optional standards track RFC.  Here are  
a few recent RFCs that I just picked at random:

RFC 5001 "DNS Name Server Identifier (NSID) Option"
RFC 5007 "DHCPv6 Leasequery"
RFC 5010 "The Dynamic Host Configuration Protocol Version 4 (DHCPv4)  
Relay Agent Flags Suboption"
RFC 5044 "Marker PDU Aligned Framing for TCP Specification"

None of these are mandatory, so at best they would be SHOULD for the  
overall document, and yet they all have MUSTs in them.  Need I go on?   
The only difference I can see is that these standards don't have  
explicit SHOULD/MAY in their applicability sections.


>> The only thing that
>> might be unique here is that the applicability statement has an  
>> explicit
>> SHOULD/MAY in it; they could be changed to should/may and I don't  
>> think
>> anything would be lost, but I also think it is fine as it is.
>
> It would definitely be lost; the doc would then have only MUSTs for
> certain items, which are not MUSTs if the overall document is a  
> SHOULD.
>
> This is the punchline; i.e., if we feel that we can't make document- 
> wide
> recommendations at different levels than individual items, then the
> document-wide concern needs to be reflected in the level of individual
> items, and then I would claim that the current MUSTs should be  
> converted
> to SHOULDs. (I don't see other impacts).

Again, the SHOULD/MAY in the applicability section is about who can  
benefit from tcpsecure, and has nothing to do with how to implement  
tcpsecure.  The other MUST/SHOULD/MAYs in tcpsecure are about how to  
implement tcpsecure.

It's "you SHOULD/MAY implement this, but if you do, you MUST do it  
this way".  That's just normal standards stuff.

			-David Borman

_______________________________________________
tcpm mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/tcpm