Hello Pascal, Thanks for the updates - I checked the -12 revision and I think all my comments are now addressed.
Regards Esko -----Original Message----- From: Pascal Thubert (pthubert) <pthub...@cisco.com> Sent: Thursday, November 17, 2022 14:36 To: Esko Dijk <esko.d...@iotconsultancy.nl>; carles.go...@upc.edu; 6lo@ietf.org Cc: i...@ietf.org Subject: RE: [6lo] WG Last Call on draft-ietf-6lo-multicast-registration-11 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 <6lo-boun...@ietf.org> On Behalf Of Esko Dijk Sent: mercredi 16 novembre 2022 15:46 To: carles.go...@upc.edu; 6lo@ietf.org Cc: i...@ietf.org 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:6lo-boun...@ietf.org> On Behalf Of Carles Gomez Montenegro Sent: Wednesday, November 16, 2022 14:23 To: mailto:6lo@ietf.org Cc: mailto:i...@ietf.org 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 _______________________________________________ 6lo mailing list 6lo@ietf.org https://www.ietf.org/mailman/listinfo/6lo
