IPv6 Neighbor Discovery Prefix Registration
draft-ietf-6lo-prefix-registration-18

# Andy Newton, ART AD, comments for draft-ietf-6lo-prefix-registration-12
CC @anewton1998

* line numbers:
  - https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-6lo-prefix-registration-12.txt&submitcheck=True

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

I have no objection to the public of this document as an RFC.

# Gunter Van de Velde, RTG AD, comments for draft-ietf-6lo-prefix-registration-12

# The line numbers used are rendered from IETF idnits tool: https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-6lo-prefix-registration-12.txt

# Many thanks for this write up. It is a non-trivial update touching many parts in various specifications. It represents a significant amount of detailed work. 

# when running idnits there disclaimer message is observed. I didn't see this addressed in the shepherd writeup. 

"
  -- The document seems to lack a disclaimer for pre-RFC5378 work, but may
     have content which was first submitted before 10 November 2008.  If you
     have contacted all the original authors and they are all willing to grant
     the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
     this comment.  If not, you may need to add the pre-RFC5378 disclaimer. 
     (See the Legal Provisions document at
     https://trustee.ietf.org/license-info for more information.)
"

# section 4 suggests amending RFC4861, section 5 suggest extending RFC7400. But section 6 describes "Updating RFC6550". How is Updating any different from ammending or extending? Maybe that should be clarified in the section where amending/Extending is described? (note that other sections use Updating keyword)

# the text uses often the "*" to make a keyword appear *bold* in markdown. When reading that in text only it reads odd. Is that the intent? many tables are exposed to this idnit 

# Detailed Review
# ===============

234	   *Amends/Amended by:*  This tag pair is used with an amending RFC that
235	          changes the amended RFC.  This could include bug fixes,
236	          behavior changes etc.  This is intended to specify mandatory
237	          changes to the protocol.  The goal of this tag pair is to
238	          signal to anyone looking to implement the amended RFC that
239	          they MUST also implement the amending RFC.
240	   *Extends/Extended by:*  This tag pair is used with an extending RFC
241	          that defines an optional addition to the extended RFC.  This
242	          can be used by documents that use existing extension points or
243	          clarifications that do not change existing protocol behavior.
244	          This signals to implementers and protocol designers that there
245	          are changes to the extended RFC that they need to consider but
246	          not necessarily implement.

GV> I found this not easy to fully understand. I tried to reword this. Does this reworked definition work for you?

"
Amends / Amended by:
This tag pair is used when an RFC formally modifies the protocol behavior defined in another RFC. Such modifications may include corrections, updates to normative behavior, or other substantive changes. The presence of this tag pair indicates that the amending RFC introduces mandatory changes to the amended RFC. Implementers of the amended RFC MUST also implement the corresponding changes described in the amending RFC.

Extends / Extended by:
This tag pair is used when an RFC introduces an optional extension or clarification to another RFC, without altering its existing normative behavior. Such extensions may utilize defined extension points or provide additional informational content. The presence of this tag pair indicates that there are supplementary specifications or enhancements to consider. Implementation of the extending RFC is OPTIONAL, but protocol designers and implementers SHOULD be aware of its existence when working with the extended RFC.
"

302	   SND:  Subnet Neighbor Discovery (protocol)

GV> idnit observation. The other entries in this list have "*" to make the keyword bold, but this SND keyword does accidently not have this

324	   otherwise therein, the behavior of the 6LBR that acts as RPL Root, of

GV> The "6LBR" seems forgotten within the terminology list

473	   [RFC9685] defines a 2-bits P-Field with values from 0 to 2, and
474	   reserves value 3.  This specification defines value 3 for the
475	   P-Field, and uses it to signal that the Registered Address is a
476	   prefix.  When the P-Field is set to 3, the receiver installs a route
477	   to the prefix via the sender's address used as source address in the
478	   NS(EARO) registration message.
479
480	   This specification assigns the value of 3, resulting in the complete
481	   table as follows:

GV> What about the following? (i sneaked in a normative MUST):

"
[RFC9685] defines a 2-bit P-Field with values 0 through 2 and reserves the value 3 for future use. This specification defines the semantics of P-Field value 3.

When the P-Field is set to 3, it indicates that the Registered Address represents a prefix rather than a single address. Upon receiving an NS(EARO) message with the P-Field set to 3, the receiver MUST install a route to the indicated prefix via the source address of the NS(EARO) message.

This specification assigns the value 3 to the P-Field, resulting in the following complete set of defined values:
"

548	   New and updated Option Fields:
549
550	   *F:*  1-bit flag; set to 1 to indicate that the sender expects other
551	      routers to forward packets to self when the packets are sourced
552	      within the registered prefix.
553
554	   *Prefix Length:*  7-bit integer; this field contains a prefix length
555	      expressed in bits if the P-Field is set to 3 and the EARO is
556	      placed in an NS message.  In that case the value MUST be between
557	      16 and 120, both included.  The field contains a Status if the
558	      EARO is placed in an NA message regardless of the setting of the P
559	      flag.  In all other cases it is reserved, so it MUST be set to 0
560	      by the sender and ignored by the receiver.
561
562	   *r (reserved):*  1-bit reserved field; it MUST be set to zero by the
563	      sender and MUST be ignored by the receiver.

GV> What about:

"
New and Updated Option Fields

F (Forwarding Flag):
A 1-bit flag. When set to 1, it indicates that the sender expects other routers to forward packets to the sender when those packets are sourced from within the registered prefix.

Prefix Length:
A 7-bit unsigned integer. When the P-Field is set to 3 and the EARO is included in a Neighbor Solicitation (NS) message, this field MUST contain a prefix length expressed in bits, with a value between 16 and 120 inclusive.
When the EARO is included in a Neighbor Advertisement (NA) message, this field MUST carry a Status value, regardless of the setting of the P-Field.
In all other cases, this field is reserved; it MUST be set to zero by the sender and MUST be ignored by the receiver.

r (Reserved):
A 1-bit reserved field. It MUST be set to zero by the sender and MUST be ignored by the receiver.
"

598	   New and updated Option Fields:
589
600	   *Reserved:*  6-bit field; reserved, MUST be set to 0 and ignored by
601	      the receiver
602
603	   *Prefix:*  15 bytes field; carries up to 120 bits of prefix, and MUST
604	      be padded with zeros.  The padding MUST be overwritten with zeros
605	      when the prefix is being used by the receiver.
606
607	   *r:*  1-bit field; reserved, MUST be set to 0 and ignored by the
608	      receiver
609
610	   *Prefix Length:*  7-bit integer; signals the length of the prefix, in
611	      bits.  The value MUST be at least 16 and at most 120.

GV> What about:

"
New and Updated Option Fields

Reserved:
A 6-bit field reserved for future use. It MUST be set to zero by the sender and MUST be ignored by the receiver.

Prefix:
A 15-byte field that carries up to 120 bits of the prefix. If the prefix is shorter than 120 bits, the remaining bits MUST be padded with zeros. The receiver MUST treat the padding as zeroed and MUST overwrite any unused bits with zeros before using the prefix.

r (Reserved):
A 1-bit field reserved for future use. It MUST be set to zero by the sender and MUST be ignored by the receiver.

Prefix Length:
A 7-bit unsigned integer indicating the length of the prefix in bits. The value MUST be in the inclusive range of 16 to 120.
"

Many thanks for this document,
Gunter Van de Velde,
Routing AD

Thanks to the author and the WG for this very useful extension for Prefix Discovery in 6LoWPAN.

Thanks for the discussion and making the changes. I am clearing my DISCUSS position.

I will let the INT ADs review the current set of RFCs listed on the "updates" metadata for their correctness. They seem OK to me.

This document is very dense, and I can tell that you've made efforts to connect it to the context of existing documents in this space. Thank you for that investment. I have a few comments that I hope will help improve the document; they can be incorporated at the editor's and the responsible AD's discretion.

In Section 2.1, there is no Extends or Amends "tag" per se. I think it's fine to define the terms as you're using them for precision in this document, but draft-kuehlewind-update-tag has been replaced and its replacement expired without being adopted by RSWG. It has no formal standing at this point.

In Section 2.2, there's already a References section at the end of the document. Consider instead specifying what terminology you're importing from each document.

In Section 3, the second sentence is difficult to parse due to the descriptive clauses for each item in your list. Consider breaking this up into multiple sentences or using a bulleted list to isolate the elements.

In Section 7.3, there is an inconsistency between "less than 120 bits long" and "up to 120 bits" / "at most 120". I suspect the first intends to say "at most 120 bits long." 

It might be worth mentioning earlier in the document that this design excludes support for prefixes longer than 120 bits. That's almost certainly a reasonable restriction, but discovering it in the encoding rules of the message is sub-optimal.

In Section 12.1, is there a citation for "brown field use case"? Is this phrase needed, or could this sentence begin with "A mix of devices that support any or all of..."

===NITS FOLLOW===

Abstract, "allows to request" => "allows the node to request" or "allows requesting"

Section 1, paragraph 3 has odd spacing. Please check whether you have extraneous whitespace or nbsp characters in your input that might be causing this.

Section 3, "that it participates to" => "that it participates in" or "in which it participates"; "enables to decouple" => "enables decoupling"; "to stimulate the" => "to request"

Section 7.2, Should "The Status field that is used only when the EARO is placed in an NA message." be "The Status field is used only when the EARO is placed in an NA message."?

Section 7.4, "similar as" => "similar to that"; "it is of" => "it is"

Hi Pascal, 

Thanks for the the discussion and for taking care of most of the points in [1].

The pending point about I-flag will be discussed as part of my draft-ietf-6lo-updating-rfc-8928 ballot [2]. 

Cheers,
Med

[1] https://mailarchive.ietf.org/arch/msg/6lo/A8K5rsUHTcQvqgwS7KbeCjDUJdM/

[1] https://mailarchive.ietf.org/arch/msg/6lo/YHNtP6qllKSuJg3FtVgcUF8lWkI/

Thanks for addressing my concerns and explaining the choice of bits. I have updated my ballot to No Objection.

Thank you to Dan Romascanu for the GENART review.

Thank you for addressing my DISCUSS and COMMENT feedback.