Early Review of draft-ietf-6lo-nd-gaao-03
review-ietf-6lo-nd-gaao-03-genart-early-halpern-2025-03-22-00

Request Review of draft-ietf-6lo-nd-gaao
Requested revision No specific revision (document currently at 09)
Type Early Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2025-04-30
Requested 2025-03-20
Requested by Shwetha Bhandari
Authors Luigi Iannone , David Lou , Adnan Rashid
I-D last updated 2026-03-09 (Latest revision 2026-02-13)
Completed reviews Genart Early review of -03 by Joel M. Halpern (diff)
Intdir Early review of -03 by Brian Haberman (diff)
Comments 
The 6lo WG is working on "Generic Address Assignment Option for 6LoWPAN ND" (draft-ietf-6lo-nd-gaao), which modifies IPv6 Neighbor Discovery for constrained environments. Given its impact on ND and IPv6 autoconfiguration, we would like to request an early review from Gen-ART and INTDIR to identify any architectural, interoperability, or deployment concerns.

Specifically, we would appreciate feedback on:

Architectural alignment with IETF principles (Gen-ART).

Interactions with existing IPv6 ND mechanisms and Internet Area expectations (INTDIR).

Any potential operational or deployment concerns in constrained networks.


We aim to incorporate early feedback to improve the draft before wider IETF review. Any insights would be greatly appreciated
Assignment Reviewer Joel M. Halpern
State Completed
Request Early review on draft-ietf-6lo-nd-gaao by General Area Review Team (Gen-ART) Assigned
Posted at https://mailarchive.ietf.org/arch/msg/gen-art/xJ0ASIzu07XJOJFj7FOsR0F9rMU
Reviewed revision 03 (document currently at 09)
Result Almost ready
Completed 2025-03-22
review-ietf-6lo-nd-gaao-03-genart-early-halpern-2025-03-22-00
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 <jmh@joelhalpern.com>

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"? 
    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? 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.

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?