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

[Murray Kucherawy via Datatracker <[e-mail]>]

Murray Kucherawy has entered the following ballot position for
draft-ietf-6man-grand-06: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-6man-grand/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I don't see a lot of transport documents that make me think this, but: Kudos
for an easy 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.

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/