Re: [v6ops] I-D Action: draft-baker-6man-hbh-header-handling-00.txt

[James Woodyatt <[e-mail]>]

On Fri, Jun 5, 2015 at 1:22 PM, Fred Baker (fred) <[e-mail]> wrote:
>
>
> That's not a joking matter.
>
> > 1. MUST   This word, or the terms "REQUIRED" or "SHALL", mean that the
> >    definition is an absolute requirement of the specification.
> >
> > 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.
>
> In Fred-speak, MUST means "if you don't do this, something will break",
> and I like to say what will break. SHOULD means "I'd like to say 'MUST',
> but I can think of a case in which it might be the wrong answer, or at
> least can't prove to myself that it is never the wrong answer". When an
> implementor decides to not do a SHOULD, I'd like to see their online
> documentation say why they chose to not do it, and if not that, I'd like
> them to be able to respond sensibly to the question.
>

Fred, you and I had this discussion verbally at some point, but I thought I
would post it. I think your SHOULD can often be re-phrased better as MUST
NOT. This is because when you'd like to say MUST, but you can't think of a
case where it might be the wrong answer, or at least you can't prove that
it's never the wrong answer, the thing you MUST do at that point is to
figure out what in particular *can* break and expressly specify that it
MUST NOT break.

At IETF 92 in Dallas, I was amused to learn from a colleague that the
unfortunate soul at UNH IOL tasked with translating RFC 6092 into a test
plan had some rather colorful expressions for the trick I used in that
document to prevent problems like this from arising. He said, "I've never
seen an RFC with so many g*dd*mn MUST NOT keywords in my entire life." (To
which my reply was: yep, ain't I a stinker? I know what it's like to be on
the implementer side of this stuff, and I know all the tricks.)

In the real world, product engineers routinely consider SHOULD as
equivalent to OPTIONAL. That's why it's good to raise as many things to the
level of MUST or MUST NOT as possible in specifications. Everything else
can and will be ignored when the clock is ticking and the sharp knives come
out.


-- 
james woodyatt <[e-mail]>
Nest Labs, Communications Engineering