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 <[email protected]> On Behalf Of Esko Dijk
Sent: mercredi 16 novembre 2022 15:46
To: [email protected]; [email protected]
Cc: [email protected]
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:[email protected]> On Behalf Of Carles Gomez Montenegro
Sent: Wednesday, November 16, 2022 14:23
To: mailto:[email protected]
Cc: mailto:[email protected]
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
[email protected]
https://www.ietf.org/mailman/listinfo/6lo
