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]
