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

Jen Linkova <> Thu, 01 July 2021 07:14 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 449683A18DB; Thu, 1 Jul 2021 00:14:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.848
X-Spam-Status: No, score=-1.848 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_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=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 Qf9rZHWGXuUB; Thu, 1 Jul 2021 00:14:17 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::535]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 516B53A18DA; Thu, 1 Jul 2021 00:14:17 -0700 (PDT)
Received: by with SMTP id l24so6857170edr.11; Thu, 01 Jul 2021 00:14:17 -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=es1nG6aDeswhYG+SrvLHqfqDLOe19Gh/mff60KsCfb8=; b=tMJiVnh+MWy1S7AaNWZpLipoKYcevLu21oY3UIz0g9XQG9lM9O4hQ6yTZXio+VdT4+ mINnEs7N39H6vromv2Xy53WvSZn5YG3h4iSTj3hY89ixRQVhrxtwmWgDTQnV9sBKaDH4 9E0xfJ7uZz+KtSQPwl/uV9d/C7iQMVln/UJXkGCtlbrPgrIedjMU41a6Wsq4gY1YbQnK pHf0n6xTM+e2kNJdcb1PALHHXPzc5bpBxM/ZvCWaTvs16AntmWVv1o8yUtwiW9oV5G+C Ia9jJxDy9CTUFQ7s7coLY6DckpzXX9cv+I5KSIATFTIG7sgmiNtaQX4JSDYKC2ZJ6Auf HHsQ==
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=es1nG6aDeswhYG+SrvLHqfqDLOe19Gh/mff60KsCfb8=; b=l7lvUuRUm70TueSqbHVphIObTrd2iCflAVgNGhiqHmWTktGXEp2ZXboq8eDQ0z3fk3 gC1yProqT0BBFr8i+0UvgkWSIEfLLOWcKnf0fSD+hICuGwotldtW8xjFaqdlyFeB2YhK VERBUZkfYHDnQ9FOaXlAIz5gfkcC4JiV51E4030YF2zb1/dizYsbT9GVV8q2/v8I5OP+ zZSC+Igwm2yIlFevHFjKi9IEP02xqZT+MWHZJXQNUFI0QWtz+XhS8co3cJ23/qFbTCYr crQhYbeUkdWYMacTqCRkf9LnAgWqoE4y/W8vIVza7/ZUF/aPaFuMD2aS3/gC4qYbbTBr kstA==
X-Gm-Message-State: AOAM532lP2sk5GGg88Ib9XC+oMNqXLf2bJzC+5p+zDTvV6geR0PJQQeM bNwA4XAmmwhAYiAuc0J7Aw0wCOHatXBmEwf8BnQ=
X-Google-Smtp-Source: ABdhPJx19LgzB8cc+VpFcEa8RI7NjvhbXvybKVVUJ54x9i4RuC49gCfgUO6ViIPs4HK2yljy42R4jw5VFYaUllVPe9k=
X-Received: by 2002:aa7:dc53:: with SMTP id g19mr51235295edu.226.1625123650523; Thu, 01 Jul 2021 00:14:10 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Jen Linkova <>
Date: Thu, 01 Jul 2021 17:13:58 +1000
Message-ID: <>
Subject: Re: Murray Kucherawy's No Objection on draft-ietf-6man-grand-06: (with COMMENT)
To: Murray Kucherawy <>
Cc: The IESG <>, Bob Hinden <>,, 6man <>, 6man Chairs <>
Content-Type: text/plain; charset="UTF-8"
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 07:14:22 -0000

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.

> In Sections 6.1.1 and 6.1.2, there are the following uses of BCP 14 language:
> * "Routers SHOULD create a new entry ..."
> * "In such cases a node SHOULD send up to MAX_NEIGHBOR_ADVERTISEMENT Neighbor
> Advertisement messages."
> * "If the address is preferred then the Override flag SHOULD NOT be set."
> * "The destination address SHOULD be set to the all-routers multicast address."
> * "The first advertisement SHOULD be sent as soon as one of the following
> events happens:"
> 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
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.
In this case, for example - I just can not justify MUST here (because
nobody would be broken, it's just a useful thing to do).
But "MAY" is not a good choice either. First of all, MAYs usually do
not get implemented. Secondly, the whole draft is not needed if we
replace SHOULD with MAY here:  strictly speaking, both routers and
hosts could do what described here already, w/o violating any RFC (and
some of them do..). That's why the draft was intially in v6ops, not in
6man even.
Routers creating STALE entries from unsolicited NAs would violate
"SHOULD", so if there is a reason to do so, it's OK (in other words,
they MAY do it even now). There is nothing explicitly prohibiting
hosts from sending unsolicited NAs right now. What that draft does is
explicitly defining the expected behaviour. Making it a bit more
official, kind of. However the whole mechanism is a pure optimization,
designed to make hosts.

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

> Apart from that, I have only a couple of boring nits to offer:
> Section 1:
> * "It can causes ..." -- s/causes/cause/
> Section 5:
> * "The section 2.2 of ..." -- s/The section/Section/

Thanks! I've missed those typos in -07 but I think there will be more
typos to fix before the document gets published, so I'll fix those in
the next version.

SY, Jen Linkova aka Furry