Carles, Thanks for incorporating the comments and feedback. I did a round of review and the comments are handled according to what I had in mind. Thanks.
There are some more comments I had during my subsequent review. Please have a look. I will provide the shepherd write-up after this. Best, Rahul --------Comments------- 1) Section 2 "The IPv6 forwarding devices of the mesh have to implement both Node and Router roles, while simpler leaf-only nodes can implement only the Node role." The roles here refer to roles as described in Bluetooth IPSP Spec. I was confused with the Host and Route mode as described in RFC 4861. I would suggest adding explicit ref here. [Later I found that a para above has a context for IPSP and the Node/Router roles. Thus I would leave it up to you to add an explicit ref.] 2) Section 3.3.1: "Multihop DAD functionality as defined ... MUST be supported." RFC7668 didn't mandate DAD. I am not sure if we should mandate it here. If an implementation decides to use SLAAC with a static link address then DAD won't be necessary. The cost of multihop DAD is high. 3) Section 3.3.2: "A Bluetooth LE host MUST register its non-link-local addresses ... " This stmt contradicts with another stmt in section 3.3.3 which says, "A 6LN SHOULD register its non-link-local address with EARO in the next-hop router. Note that in some cases (e.g. very short-lived connections) it may not be worthwhile for a 6LN to send an NS with EARO for registering its address." My suggestion would be to use SHOULD even in Section 3.3.2. 4) Section 3.3.3: "... non-link-local packet transmissions originated and performed by a 6LN, and non-link-local packets intended for a 6LN that are originated or forwarded by a neighbor of that 6LN." What does "performed by a 6LN" imply here? Suggest just keeping originated by a 6LN, unless I am missing sth here. 5) [nit] Section 3.3.3: "..., context- based compression MAY be used." remove space between "context- based" --------End of Comments------- On Sun, 29 Sep 2019 at 01:04, Carles Gomez Montenegro < [email protected]> wrote: > Dear Rahul, > > First of all, apologies for the late response. > > Thank you very much for your review. > > We have just submitted -06, which is intended to address your comments: > https://www.ietf.org/rfcdiff?url2=draft-ietf-6lo-blemesh-06 > > Should you have any further concerns, please do not hesitate to let us > know. > > Cheers, > > Carles (as a WG participant) > > > > Dear authors, > > > > Following are some review comments based on the latest updates to the > > document: > > 1. In the last revision, the draft mandated the use of NS(EARO) in > > place NS(ARO). This change is not consistently applied in the > > document. E.g., in section 3.3.3, the draft continues to use NS(ARO). > > 2. Section 3.3.3 also mandates the use of the 6CO option. 6CO option > > may not be necessary in case a single prefix is used in the network. > > The CID defaults to zero which results in the use of default prefix. > > 3. Section 3.3.3 the following statement is not clear, "In particular, > > the latter comprise link-local interactions, non-link- local packet > > transmissions originated and performed by a 6LN, and non-link-local > > packets transmitted (but not necessarily originated) by the neighbor > > of a 6LN to that 6LN." > > 4. I think the draft will benefit from a call flow diagram depicting > > the node joining procedure. > > 6LN ----(RS)-------> 6LR > > 6LN <---(RA-PIO)---- 6LR > > 6LN ----(NS-EARO)--> 6LR > > [Multihop DAD procedure] > > 6LN <---(NA)-------- 6LR > > 6LN can now start acting as 6LR and advertise its own RA > > 6LN ----(RA)-- > > > > Regards, > > Rahul > > > > _______________________________________________ > > 6lo mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/6lo > > > > >
_______________________________________________ 6lo mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lo
