[Gen-art] Genart early review of draft-ietf-6lo-nd-gaao-03

[Joel Halpern via Datatracker <[e-mail]>]

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 <[e-mail]>

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?