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 <j...@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?
_______________________________________________
6lo mailing list -- 6lo@ietf.org
To unsubscribe send an email to 6lo-le...@ietf.org
