Re: [secdir] review of draft-ietf-dnsext-dnssec-gost-05

[Jeffrey Hutzelman <[e-mail]>]

--On Thursday, February 11, 2010 01:15:23 PM -0500 Andrew Sullivan 
<[e-mail]> wrote:

>> SHOULD is not mere advice or encouragement; it is a requirement almost
>> as  strong as MUST.  It doesn't mean "we think it's a good idea for you
>> to do  this"; it means "you absolutely have to do this unless...".
>
> To be fair to Basil, the actual text of 2119 is not as tight as you're
> claiming:
>
> 3. 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.

That's exactly as tight as I'm claiming; I simply omitted the details of 
the "unless..." part.



> That seems to me to say that, as long as you know what you're doing
> and have thought about it a lot, you can go ahead with your decision
> not to do the RECOMMENDED thing and still be considered conforming.

Yes.

> The reason I prefer that authors and editors include the limiting
> conditions is because of that "full implications" condition.  I think
> that if you leave the full implications undefined, you're inviting the
> reader to make their own determination.  Interoperability is not best
> served thereby, so I think it better to state the
> counter-considerations (even indirectly).

When possible, yes.  But sometimes you can't do any better than mentioning 
things to think about, and sometimes you can't even do that.  SHOULD is 
really for those cases -- if it's possible to list the exceptions, then 
list them, and use MUST.


> As Basil pointed out, there are plenty of SHOULDs in documents that
> don't actually say when you're allowed to violate them.  In practice,
> this means that people will violate them when it's really really
> convenient, as opposed to the mere bar of convenient we get from MAY.

Certainly people do that.  But that doesn't mean we should further dilute 
the meaning of SHOULD by assuming that it will always be interpreted more 
loosely than intended, or by saying that a particular algorithm SHOULD be 
implemented when what we really mean is that we would like people to 
implement it.


> (Note that by this argument and with the current text, resolver
> implementers could decide that they won't support GOST on the grounds
> that their user base doesn't really need GOST, and they don't care
> about interoperating with such an algorithm anyway.  Since there's no
> limiting condition in the text, I'd be willing to make this argument
> were I playing protocol lawyer.)

Generally, if we believe the argument "I don't care about interoperating 
with foo" is a reasonable one, then saying "SHOULD foo" is just as wrong as 
saying "MUST foo".  SHOULD needs a good interop/security/stability reason 
just as much as MUST.


-- Jeff