Many thanks for your review and your confirmation, Joel! Cheers,
Shwetha and Carles El dissabte, 19 de juliol del 2025, Joel Halpern (<[email protected]>) va escriure: > MY apologies for the delay in responding. As expected, the revisions > address my concerns. > > Yours, > > Joel > On 7/14/2025 4:37 AM, Carles Gomez Montenegro wrote: > > Hi Joel, > > First of all, we would like to thank you for your valuable review of > draft-ietf-6lo-nd-gaao-03. Your effort is really appreciated. > > Do you think the updated version of the draft addresses your concerns > satisfactorily? > > (It would be great if you could state so on the 6lo WG mailing list.) > > Many thanks! > > Cheers, > > Shwetha and Carles (6lo chairs) > > > > > ---------- Forwarded message --------- > From: Luigi IANNONE <[email protected]> > Date: Mon, 23 Jun 2025 at 15:54 > Subject: RE: Genart early review of draft-ietf-6lo-nd-gaao-03 > To: Joel Halpern <[email protected]>, [email protected] <[email protected] > > > Cc: [email protected] <[email protected]>, [email protected] < > [email protected]> > > > Hi Joel, > > Thanks for your review of the GAAO document. > We just submitted a new revision addressing your comments. > Please see inline. > > > -----Original Message----- > > From: Joel Halpern via Datatracker <[email protected]> > > Sent: Saturday, March 22, 2025 10:20 PM > > To: [email protected] > > Cc: [email protected]; [email protected] > > Subject: Genart early review of draft-ietf-6lo-nd-gaao-03 > > > > Reviewer: Joel Halpern > > Review result: Almost Ready > > > > This a request gen-art early review of draft-ietf-6lo-nd-gaao. > > > > As it is an early review, these comments are intended to help the > > working group as it proceeds with the document. > > > > Reviewer: Joel Halpern <[email protected]> > > > > Ovarall status: Mostly, this is in quite good shape. It is clear, > > describes the goal, and describes the protocol elements > > > > Major issue: > > I have one major concern. Error cases. > > The draft is very clear that all nodes in the lowpan network must > use the > > same AAF, and by implication if this is being used, all nodes when > > registering must send the new option and process the response. This > makes > > sense. There is an error code for the case where the responding > node does > > not support the requested AAF. But what if the software supports > several > > AAF, but the one selected with the upstream is different from the one > > requested by the downstream? Is this still considered "not > supported"? > [LI] To address this concern we made several changes. > - The error is now named "AAF Not Used" indicating that the 6LoWPAN > network the node joined is not using that AAF. > Whether is because it is not supported by some nodes or just an explicit > configuration choice is beyond the point, since there is one single AAF for > the whole 6LoWPAN network. > - Text in section 8 has been updated to accommodate the above. > - A node that decides not to participate in the AAF-based 6LowPAN may > still use other mechanisms to configure an address > > > Should we flag a network management because there appears to be > > inconsistent configuration? Similarly, but presumably less > disruptive, what > > happens if a node receives a request that should have a gaao, but it > > doesn't. This may be detectable earlier, if the requester did not > indicate > > the gaao capability, but I am still left wondering what the neighbor > will > > do? > [LI] Nodes can have the GAAO capability but no use it. The choice is made > by configuration. > [LI] If a router does not receive a request with GAAO then it will do > nothing. > [LI] Did we get the question right? > > > > Further, but probably less disruptive, it is unclear what happens if > a > > requesting node receives a response with the C bit set, but just > doesn't > > perform the confirmation steps. > [LI] Excellent point! The address should be reserved only for a limited > amount of time. The registration part comes from other documents, which in > turn leverage on RFC4861 that defines the timer defaults. We added text in > section 7.2 about this case. > > > > > Nit: > > The "do nothing" response to the AAF error condition in section 8 > probably > > should say "do nothing and do not participate in the 6lowpan > network", > > shouldn't it? > [LI] Good point. > > Thanks a lot for you review. > > Luigi > > > > >
_______________________________________________ 6lo mailing list -- [email protected] To unsubscribe send an email to [email protected]
