Re: gen-art review of draft-ietf-ipv6-2461bis-09.txt

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Thomas, I agree with everything you say below except that some of what
you say may, in fact, be the justifications we are looking for.  I
didn't say examples, I said explanations.  See below ...

On 11/22/2006 09:06 AM, Thomas Narten allegedly wrote:
> Scott W Brim <swb@xxxxxxxxxxxxx> writes:
> 
>> I have one question on the protocol, and several on documentation.
>> Since this is a significant protocol, documentation is very important.
>> For the sake of new implementors I have a number of suggestions for
>> clarity.  Many of them have to do with the use of "SHOULD", since we
>> have been polishing up its use and advice to implementors.
> 
> ...
> 
>>     We've been tightening up "SHOULD"s recently.  RFC2119 says:
>>     
>>       SHOULD   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.
>>   
>>     In this draft, "otherwise ...  SHOULD" implies that there are
>>     situations in which the link layer address is known, and the
>>     source address is included, but the link layer address may be
>>     omitted.  RFC2119 says that deserves explanation.
> 
> I don't agree with your last sentence. Where exactly does 2119 say
> "that deserves explanation"? 

It says "the full implications must be understood and carefully
weighed before choosing a different course".  How do you expect
implementors to carefully way the full implications if you don't give
them information with which to do so?  Why did you choose to say only
"SHOULD"?  Tell them.  The point is to give implementors the benefit
of the weeks of debate that went on in the WG.  If you say something
SHOULD be done, you should also go on to say, for example, "in the
case of implementations that don't support option Y, it can't, and you
need to take that into account".

> If the IESG is now requring all uses of SHOULD to give examples of
> when the SHOULD might not apply, I think that goes a bit far. In some
> cases, SHOULD is chosen because we can imagine a future spec taking
> advantage of something that would not be consistent with the
> SHOULD. 

If that's the justification for the SHOULD, then that is all you need
to say.

> Also, anyone familiar with WG discussions knows that there is often
> support for SHOULD, but not for MUST.

Absolutely.  This isn't about SHOULD versus MUST, it's about helping
implementors understand your reasoning.

swb

_______________________________________________

Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]