[v6ops] Gorry Fairhurst's No Objection on draft-ietf-v6ops-nd-considerations-11: (with COMMENT)

[Gorry Fairhurst via Datatracker <[e-mail]>]

Gorry Fairhurst has entered the following ballot position for
draft-ietf-v6ops-nd-considerations-11: 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/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-v6ops-nd-considerations/



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


(1) One of my issues is the way the document mixes different document statuses
without an attempt  separate them for a reader - to me this is really
confusing. If the document is to form a valuable reference, I think there
should be much more clarity on the status of what is being presented. (Thanks
for addressing this issue.)

(2) The following are non-blocking comments, but I do hope the editors take the
opportunity to improve this document to make it a valuable RFC. These comments
relate to specific text:

“The protocol uses multicast extensively.” I think this ought to read “The
protocol uses multicast IPv6 packets.” - It might generate extensive multicast
traffic in the writer’s mind, but the important point seems this is multicast.

I don’t think ICMPv6 redirect is a ND problem. It is atrocious best a related
problem.

“Neighbor Discovery (ND) [RFC4861] defines the protocol mechanisms that nodes
(hosts and routers) on a link interact with each other.” - This seems confused
- I thought this was to discover information about the next-hop?

It would be really helpful to provide a reference to where info about GUA and
ULA can be found.

“Given that a unique prefix can be allocated per host on shared media, hosts in
different subnets may be in the same link.” - what does in the same link mean?
- is this same layer 2 VLAN, use the same pair of MAC unicast addresses, share
the same physical link? “ L2 Isolation - taking measures to prevent a host from
reaching other hosts directly in Layer 2 (L2) so that every host is in a
 different link. “
- what does a different link mean? - is this same layer 2 VLAN, use the same
pair of MAC unicast addresses, share the same physical link?

/Routers respond with unicast Router Advertisements/ Is this correct, please
check RFC 4861.

/Node Solicitations NSs),/Node Solicitations (NSs),/ - please add an open
bracket.

“to a higher probability of interference,” - Is this radio interference -
please explain why this is so?

“lower data rate, and lack of acknowledgements. [RFC9119].” - remove extra
period before reference.

“messages may wake them up and create battery life issues” - what are the
issues, does this mean can deplete the battery, or is there some other issue?

Issue 13: “The resulting resource exhaustion may render the router unable to
function.“ - why please explain, I understand that the might fill the Neighbor
Cache - and that could prevent learning new Neighbor Cache entries, but why
would this prevent a router functioning?

/2.4. Summary of ND Issue/ - is there a missing final ’s’?

“All issues solved” is slightly misleading, is this all identified issues
solved?

What is: 7772 - is this RFC 7772? please update or cite in the table.
What is: 6583 - is this RFC 6583? please update or cite in the table

It took me a little while to realise that each subsection of section 3 denoted
a case in the table. Could you prefix each following section title please with
the abbreviations used in Table 1.

“Scalable Address Resolution Protocol [RFC7586] was an experimental solution
that ended in 2017.” What does ‘ended’ mean in this context? - This is an EXP
RFC, whose experiment has concluded. I think the text needs to be clearer about
this. Why is this needed to be listed alongside other methods that are current?
I think the document would be better without this.

“Prioritizing NDP processing for existing NCEs over creating new
NCEs”/“Prioritise …”

References:
* RFC 4291 is not cited, please remove.
* Gratuitous ARP is defined in RFC 5227, not [TCPIP] - Please correct this
reference .

===