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

[David Borman <[e-mail]>]

Ok,

(WG chair hat on)

It looks like we have consensus on this.  The wording in the  
Applicability section with SHOULD/MUST is fine, and when I write up  
the proto for passing tcpsecure on to the IESG, I'll include a comment  
that this issue was brought up during WGLC and cite references to  
other RFCs as examples.

			-David Borman

On Sep 19, 2008, at 3:28 PM, Joe Touch wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi, David,
>
> If we have docs we can point to, we're fine. I had questions from  
> others
> on this point; if we have precedent, we're set.
>
> Joe
>
> David Borman wrote:
>>
>> 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
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.3 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFI1AthE5f5cImnZrsRAmTuAJ9reCQq4gM4b9Yzbidr61YRrFvbQwCfSkr9
> uf1SV+aHEvZkmsUr9TUIf8A=
> =iUCX
> -----END PGP SIGNATURE-----

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