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

[Jen Linkova <[e-mail]>]

Hi Murray,

On Thu, Jul 1, 2021 at 3:21 PM Murray Kucherawy via Datatracker
<[e-mail]> 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
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.
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