Re: Murray Kucherawy's No Objection on draft-ietf-6man-grand-06: (with COMMENT)

"Murray S. Kucherawy" <> Thu, 01 July 2021 08:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 488173A1B98; Thu, 1 Jul 2021 01:04:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id DIDhaxD5EAQn; Thu, 1 Jul 2021 01:04:29 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::935]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 54CE53A1B91; Thu, 1 Jul 2021 01:04:29 -0700 (PDT)
Received: by with SMTP id x37so2115252uac.13; Thu, 01 Jul 2021 01:04:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=lUIQbXK0ByBydTrxEpA+L9VC4VuzAn9VRjvh8GvLnt0=; b=CdrFr1jrPJ1N690PXoCut5keA1ylDVqL6m7Mpo4ExL1onPb2y5ZCsDPSvBFOrT+PaE pgmkOfooevyZg8eVigtgr1/eQAxdmA0pxxqZ5A/RIqDr7P03nsJ4CwazsMWdQ7F3oufz wLbipMAiu9Y8Ji/LsiJMLPTl8vdjG01Izh4ZAnOE85iKax4/wsThdU3dR9a0YRhhrr2s R3KNNeh74BDzB4snu3rdlhf2m4/O5+8wS1MnOdlLCErs0GVCH9R+BUy9b+cFgsqMme4F giJAkiLBz4b61Pijao8iwjLpB55IsjDgS2Ahndx8mFfzP9hv4CY7LqoLWqvzcxY5u1BY Kagw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=lUIQbXK0ByBydTrxEpA+L9VC4VuzAn9VRjvh8GvLnt0=; b=hxGKeqtuh0+6oYes2YBbw+MOL5sFq5TJoP6CBwazXt5bAWLLYQlP79wH+voyncQtg/ 7Z+og56cH9SGEoO90E9VK1JfIG7/xOGzgM6n2ZqVVowb1U5YNbjTe4exOARmvHGBR+ND eUYvmvZq0dShhJXkGDypZsCqnGtzp6ej0SMQKOCtOmAZN/AerHSWrGOPUT9OzqdJuS7O +/roOA1hDU6Sv43wq/3qznAtwisuFnWw2/MjhHPb3iMvJj5qmKn3Kun7iE/WCaNTXg5E iKoLwMp7qlQxMJDtgfqYUu30OwRe8065jJvryzJjo8sVPMAGHngmxPORvGo0cmbcxPej dYTw==
X-Gm-Message-State: AOAM530IqZ947mKvHH4Awb0/dUIbUcdemO8iu0c+8b6NG3ArEQMSeIZz 8I+WmNSnYvTdxpVO/us4r/9fgcqStdssG3sPZG4=
X-Google-Smtp-Source: ABdhPJwsFher+ASYMLoSv6L1Hu0JszDqEuOv2qo9ag85YsP5eGCSjG5nndBBnTI1yG6GC/PRRTbeeZBa+T3Z3Rs3V84=
X-Received: by 2002:ab0:4a6:: with SMTP id 35mr37741053uaw.76.1625126667268; Thu, 01 Jul 2021 01:04:27 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: "Murray S. Kucherawy" <>
Date: Thu, 01 Jul 2021 01:04:16 -0700
Message-ID: <>
Subject: Re: Murray Kucherawy's No Objection on draft-ietf-6man-grand-06: (with COMMENT)
To: Jen Linkova <>
Cc: The IESG <>, Bob Hinden <>,, 6man <>, 6man Chairs <>
Content-Type: multipart/alternative; boundary="000000000000b7b8d505c60b492c"
Archived-At: <>
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 01 Jul 2021 08:04:34 -0000

On Thu, Jul 1, 2021 at 12:14 AM Jen Linkova <> wrote:

> Hi Murray,
> On Thu, Jul 1, 2021 at 3:21 PM Murray Kucherawy via Datatracker
> <> wrote:
> > I don't see a lot of transport documents that make me think this, but:
> Kudos
> > for an easy read.
> One of the reasons might be that it's not really a transport document..;))
> Thank you, I'm glad you find this document easy to read.

Oh yeah, you're right!  Somehow I saw "6man" and thought about TCP for some
reason.  It's late and I'm tired.  Well still, I think it's well done.

> To a transport expert the answer to this may be obvious, but I'm left
> wondering
> > why these are only SHOULD [NOT]s.  Is there a ever a good reason to
> deviate
> > from those instructions?  I generally find it helps to, when using SHOULD
> > [NOT], include a sentence or two about why it might be necessary to do
> > something else, to guide novice readers.  It's not strictly necessary,
> but
> > something to consider here.
> Well...AFAIR we discussed it during one of the meetings - should some
> of SHOULD be MUST?
> It's always such a grey area. In this case it's not like there are
> good reasons or scenarios to deviate from SHOULD. It's more about
> "MUST is a very strong requirement". IMHO "MUST" means "if we don't do
> this, smth bad will happen, smth will get broken". It's definitely not
> the case here.
> What this document proposes is an optimization, a mechanism to make
> IPv6 a bit more reliable.
> So I agree that it would be nice to always enumerate scenarios when
> it's OK to deviate from SHOULD but I do not think it's possible.  [...]

Yeah, I understand.  And I think we've had this conversation before too.

My problem with SHOULD when used this way is that it does make it clear you
could do something else and still interoperate successfully, but the
implementer is left without any particular guidance about when it might
actually be appropriate or justified to do something other than what the
SHOULD says.  If you can think of a valid reason, it's often a good idea to
include it as such guidance, even if just as an example.  If there is no
such good reason really, then it's worth considering whether it really
ought to be a MUST.  That's why I bring it up when I see this pattern.

Sometimes the answer is simply backward compatibility with older
implementations, for example.

To sum up, I'm just not sure if we can put any meaningful text there
> to address your comment ;(

Fair enough, thanks for the discussion.  I'm glad this got due
consideration already.