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 <6lo-boun...@ietf.org> On Behalf Of Carles Gomez Montenegro Sent: Wednesday, November 16, 2022 14:23 To: 6lo@ietf.org Cc: 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
