+1
I believe the issue is the subtle differences between:
SHOULD for something new, i.e. no dependency
SHOULD for something old, i.e. an enhancement or new dependency
the engineer is trying to push hard.
As much as we want to isolate protocols, in practice, we are
integrating many protocols and in theory, it should all work. I
believe it has for the most part. But increasingly a protocol upgrade
or new protocol here requires a "MUST USAGE" dependency of another
otherwise optional protocol there. I believe that is what we are
seeing with this new interpretation.
New protocol X works better if existing optional (and much older)
protocol Y is applied as a SHOULD. It would like to say MUST but it
can't because Y is already optional and not required. This new
interpretation will make software implementing X non-compliant if it
also doesn't support Y.
---
HLS
On Mon, Aug 29, 2011 at 10:44 PM, Eric Burger
<eburger@xxxxxxxxxxxxxxxxxx> wrote:
> Yes, and...
>
> I would offer that for most cases, If Y then MUST X or If Z then MUST NOT X *are* what people usually mean when they say SHOULD. In the spirit of Say What You Mean, a bare SHOULD at the very least raise an ID-nit, suggesting to the author to turn the statement into the if Y then MUST X or if Z then MUST NOT X form. Being pedantic and pedagogic:
> SHOULD send a 1 UNLESS you receive a 0
> really means
> UNLESS you receive a 0, one MUST send a 1.
>
> My vision of the UNLESS clause is not necessarily a protocol state, but an environment state. These are things that I can see fit the SHOULD/UNLESS form:
> SHOULD send a 1 UNLESS you are in a walled garden
> SHOULD flip bit 27 UNLESS you have a disk
> SHOULD NOT explode UNLESS you are a bomb
> are all reasonable SHOULD-level statements.
>
> I would offer that ANY construction of SHOULD without an UNLESS is a MAY. Unless of course one considers us the Protocol Nanny's(tm) - if do not do a SHOULD, we will send you to bed without your treacle! I.e., there IS NO DISTINCTION BETWEEN A BARE SHOULD AND A MAY.
>
> On Aug 29, 2011, at 9:47 PM, ned+ietf@xxxxxxxxxxxxxxxxx wrote:
>
>>> Hi -
>>
>>>> From: "Eric Burger" <eburger-l@xxxxxxxxxxxxxxxxxx>
>>>> To: "Narten Thomas" <narten@xxxxxxxxxx>; "Saint-Andre Peter" <stpeter@xxxxxxxxxx>
>>>> Cc: "IETF discussion list" <ietf@xxxxxxxx>
>>>> Sent: Monday, August 29, 2011 3:08 PM
>>>> Subject: Re: 2119bis
>>>>
>>>> I would assume in the text of the document. This paragraph is simply an enumeration of Burger's Axiom:
>>>> For every SHOULD, there must be an UNLESS, otherwise the SHOULD is a MAY.
>>
>>> I disagree.
>>
>> I concur with your disagreement. SHOULD should *not* be used when the
>> list of exceptions is known and practically enumerable.
>>
>>> If the "UNLESS" cases can be fully enumerated, then
>>> "SHOULD x UNLESS y" is equivalent to "WHEN NOT y MUST X."
>>> (Both beg the question of whether we would need to spell out that
>>> "WHEN y MUST NOT X" is not necessarily an appropriate inference.)
>>
>>> RFC 2119 SHOULD is appropriate when the "UNLESS" cases are
>>> known (or suspected) to exist, but it is not practical to exhaustively
>>> identify them all.
>>
>>> Let's not gild this lily.
>>
>> +1
>>
>> Ned
>> _______________________________________________
>> Ietf mailing list
>> Ietf@xxxxxxxx
>> https://www.ietf.org/mailman/listinfo/ietf
>
>
> _______________________________________________
> Ietf mailing list
> Ietf@xxxxxxxx
> https://www.ietf.org/mailman/listinfo/ietf
>
>
--
hls
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf