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

James Woodyatt <> Fri, 05 June 2015 23:11 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 07C721A89A7 for <>; Fri, 5 Jun 2015 16:11:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.378
X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 4UYwA94oz3UN for <>; Fri, 5 Jun 2015 16:11:08 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7A4FC1ABD3F for <>; Fri, 5 Jun 2015 16:05:46 -0700 (PDT)
Received: by wiga1 with SMTP id a1so34564630wig.0 for <>; Fri, 05 Jun 2015 16:05:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=6zrFtzSYTrX90iFvIbt+MByBNrbw/4zFWb4R8niplt0=; b=jEdqKR4PigRi0cE01D8D+vxZuP4EOT2eJl2nD2GHJLMA8w5o52rFXrYSuvEOCkkMLQ xxUosDnwi3KwE5WuWbElwSJ2pNwTzR1UwvrVYmdFpCmt2NOMotLlxvQ+1BEjoscMGc/X X33lerMScc+f7yyqDF0YEExmLmEJA+arnWixo=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=6zrFtzSYTrX90iFvIbt+MByBNrbw/4zFWb4R8niplt0=; b=Wdsatxlv5uaHr2ivk1P8LZRplCmjaWzn21tBC10MdTMoO8dTxf2BlQRSt/grs12oCF gIKiyAfRVxpOFSyzsMpA96HmjvHF/mJ1/MV11b40ZgUonLxK9V1PJYaFJ23q4A1Zd71H s3JGXAWVAcC+M4XtdOH+s0cdtusZMaP2CPvO6EenXsEEcp5bGjttw+ghiwm6a+10R1mI 45uyEnqPRzMIzCkCDglcgyjcKvYV9Byk2WdOHgZid0enSxxpaaKZiwTxf6gPetkgiom7 VaBY7HXm/ocKj0HwYUdi4mnS4em/WCx4w7mgnMUdNt+0fTt9ZoA7kL49sUTa9H5T4Gox QrYQ==
X-Gm-Message-State: ALoCoQkLo7dmGwSipcLmW/pf5Cv3oMLAG5k0z/ST5gXO9Z4dJrrAGiuk06QjvxH6r/Lpa3D8Lgjb
MIME-Version: 1.0
X-Received: by with SMTP id tc4mr912679wic.27.1433545545210; Fri, 05 Jun 2015 16:05:45 -0700 (PDT)
Received: by with HTTP; Fri, 5 Jun 2015 16:05:45 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <>
Date: Fri, 5 Jun 2015 16:05:45 -0700
Message-ID: <>
From: James Woodyatt <>
To: IPv6 Ops WG <>
Content-Type: multipart/alternative; boundary=001a1134cc28fdec560517cd5433
Archived-At: <>
Subject: Re: [v6ops] I-D Action: draft-baker-6man-hbh-header-handling-00.txt
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 05 Jun 2015 23:11:10 -0000

On Fri, Jun 5, 2015 at 1:22 PM, Fred Baker (fred) <> 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

james woodyatt <>
Nest Labs, Communications Engineering