Re: [IPv6] [6lo] WG Last Call on draft-ietf-6lo-multicast-registration-11

["Pascal Thubert (pthubert)" <[e-mail]>]

Hello Esko:

Much appreciated! I’m fixing the typos silently.
For the other issues please see below:
https://github.com/pthubert/6lo-multicast-registration/commit/799b3919ecfa9010a031e196ca47bf4ab14d878d

Let's see in details:

> Section 3 first paragraph mentions “RPL” as if RPL would be the only 
> routing protocol of choice.
> (Third paragraph on the other hand mentions RPL as being optional, 
> which is the better way probably. RFC 8505 also consistently describes
> RPL as one of the options here so as ‘example’.) 
> So we should make clear that can be a RPL case and a non-RPL case and 
> that the behavior of 6LBR being the RPL Root or having a RPL graph is
> only applicable in the RPL-case.

Makes sense to me. What about:

"
3.  Overview

   This specification extends [RFC8505] and inherits from [RFC8928] to
   provide a registration method - called subscription in this case -
   for anycast and multicast address.  As for the unicast address
   registration, the subscription to anycast and multicast addresses is
   agnostic to the routing protocol in which this information may be
   redistributed.

   In the case of LLNs, RPL [RFC6550] is the routing protocol of choice
   and [RFC9010] specifies how the unicast address advertised with
   [RFC8505] is redistributed in RPL.  This specification also provides
   RPL extensions for anycast and multicast address operation and
   redistribution.  In the RPL case and unless specified otherwise, the
   behavior of the 6LBR that acts as RPL Root, of the intermediate
   routers down the RPL graph, of the 6LR that act as access routers and
   of the 6LNs that are the RPL-unaware destinations, is the same as for
   unicast.  In particular, forwarding a packet happens as specified in
   section 11 of [RFC6550], including loop avoidance and detection,
   though in the case of multicast multiple copies might be generated.
"

> Section says “Wi-SUN and 6TiSCH meshes [Wi-SUN]” -> should the Wi-SUN 
> reference be placed after Wi-SUN, and 6TiSCH get its own reference?

Yes, fixed

> Table 1 has for value 3: “Reserved, MUST be set to 0 and ignored by the
> receiver” -> the following would be more clear I think: “Reserved, 
> MUST be ignored by the receiver”.  The part about “MUST be set to 0” is
> unclear – a receiver can’t do that, only a sender. And the sender when
> setting to ‘3’ obviously doesn’t set it to ‘0’ at the same time?

Fun and true. Done.

> Section 7.1 grammar issue in sentence “This specification adds a new P
> field to the EARO flags is set to 1 to signal that … “

Reshuffled to:

"
7.1.  Placing the New P field in the EARO

   Section 4.1 of [RFC8505] defines the EARO as an extension to the ARO
   option defined in [RFC6775].  This specification adds a new P field
   placed in the EARO flags that is set as follows:

   *  The P field is set to 1 to signal that the Registered Address is a
      multicast address.  When the P field is 1 and the R flag is set to
      1 as well, the 6LR that conforms to this specification joins the
      multicast stream, e.g., by injecting the address in the RPL
      multicast support that is extended in this specification for Non-
      Storing Mode.

   *  The P field is set to 2 to signal that the Registered Address is
      an anycast address.  When the P field is 2 and the R flag is 1,
      the 6LR that conforms to this specification injects the anycast
      address in the routing protocol(s) that it participates to, e.g.,
      in the RPL anycast support that is introduced in this
      specification for both Storing and Non-Storing Modes.
"

> Section 14 could augment the note to the RFC Editor a bit – since 
> there are some references in the main text to “IANA” that need to be
> removed by the editor also and these are not marked with a
> particular label. (Maybe just say to check any sentence that
> mentions “IANA”.)

Sure. 
"
14.  IANA Considerations

   Note to RFC Editor, to be removed: please replace "This RFC"
   throughout this document by the RFC number for this specification
   once it is allocated; also, requests to IANA must be edited to
   reflect the IANA actions once performed.

   Note to IANA, to be removed: the I Field is defined in [RFC9010] but
   is missing from the registry, so the bit positions must be added for
   completeness in conformance with the RFC.
"

> In 14.1 / 14.2 a new registry is requested but the desired allocation
> policy is missing. See rfc 8126, e.g. “Standards action”.

True, and yes, “Standards action” seems fit for the P field where we 
really want to lock value 3 for the prefix registration. For 6LoWPAN ND
we tend to use "IETF Review" or "IESG Approval" to avoid side effects 
with other ND specs. I used it for the New EDAR Message Flags Registry.

> Section 15 Acknowledgements is empty – If none it probably can be
> removed? Or maybe this is pending additions later on?

You're in now 😊


> Nit: Section 7.3 says “With [RFC8505]:” and Section 8 has a similar
> construct. -> maybe just clarify to a more clear “The following 
> behaviors are defined by [RFC8505]:” or so.

OK, but I prefer the direct form like
 "[RFC9010] specifies the following behaviors:"

> Nit: the in-text [RFC6282] reference is not a link in the HTML
> version.

A bug in the tool. I inserted a space. We'll see.

Many thanks Esko!

Please let me know if the comments are properly understood and addressed.

All the best

Pascal



From: 6lo <[e-mail]> On Behalf Of Esko Dijk
Sent: mercredi 16 novembre 2022 15:46
To: [e-mail]; [e-mail]
Cc: [e-mail]
Subject: Re: [6lo] WG Last Call on draft-ietf-6lo-multicast-registration-11

I’ve read the document and the technical solution that is defined looks complete, and ready to pass WGLC. 
On the document editorial side I found a couple of issues as listed below. Ideally these issues would be resolved before progressing further with the draft. Pascal & all feel free to responds to my remarks or correct me if I’m wrong.

Best regards
Esko

---

Glossary: “6BBR” defined twice, second one should be “6LBR”.

Section 3 first paragraph mentions “RPL” as if RPL would be the only routing protocol of choice.
(Third paragraph on the other hand mentions RPL as being optional, which is the better way probably. RFC 8505 also consistently describes RPL as one of the options here so as ‘example’.) 
So we should make clear that can be a RPL case and a non-RPL case and that the behavior of 6LBR being the RPL Root or having a RPL graph is only applicable in the RPL-case.

Section says “Wi-SUN and 6TiSCH meshes [Wi-SUN]” -> should the Wi-SUN reference be placed after Wi-SUN, and 6TiSCH get its own reference?

“updates the EARO with a new two bit fields”
-> 
“updates the EARO with a new two-bit field”
(best to update this to avoid reader confusion)

Table 1 has for value 3: “Reserved, MUST be set to 0 and ignored by the receiver”
-> the following would be more clear I think: “Reserved, MUST be ignored by the receiver”.  The part about “MUST be set to 0” is unclear – a receiver can’t do that, only a sender. And the sender when setting to ‘3’ obviously doesn’t set it to ‘0’ at the same time?

Section 7.1 grammar issue in sentence “This specification adds a new P field to the EARO flags is set to 1 to signal that … “

Typo: “speciel” 

Section 14 could augment the note to the RFC Editor a bit – since there are some references in the main text to “IANA” that need to be removed by the editor also and these are not marked with a particular label. (Maybe just say to check any sentence that mentions “IANA”.)

In 14.1 / 14.2 a new registry is requested but the desired allocation policy is missing. See rfc 8126, e.g. “Standards action”.

Section 15 Acknowledgements is empty – If none it probably can be removed? Or maybe this is pending additions later on?

Nit: Section 7.3 says “With [RFC8505]:” and Section 8 has a similar construct.
-> maybe just clarify to a more clear “The following behaviors are defined by [RFC8505]:” or so.

Nit: the in-text [RFC6282] reference is not a link in the HTML version.

Nit: “IN a "green field"”
-> In a "green field"



From: 6lo <mailto:[e-mail]> On Behalf Of Carles Gomez Montenegro
Sent: Wednesday, November 16, 2022 14:23
To: mailto:[e-mail]
Cc: mailto:[e-mail]
Subject: [6lo] WG Last Call on draft-ietf-6lo-multicast-registration-11

Dear 6lo WG,

(CC'ing 6man.)

This message initiates WG Last Call on the following document:

"IPv6 Neighbor Discovery Multicast Address Listener Subscription"
https://datatracker.ietf.org/doc/html/draft-ietf-6lo-multicast-registration-11

The Last Call will end on Wednesday, 30th of November.

Please provide your feedback on this document on the mailing list. 
Short confirmation messages such as "it looks fine" are also welcome.

Thanks,

Shwetha and Carles