review of draft-ietf-shim6-proto-03.txt, sections 1-2

[Jari Arkko <jari.arkko@piuha.net>]

Technical:

> However, it
>   might turn out that the shim6 protocol can be a useful component,
>   e.g., for route optimization in the context of host mobility.
Not sure why the usefulness would have to be limited
to route optimization.

Maybe "... can be a useful component in the context of
host mobility". Or don't say anything.

>   This potential source for confusion can be avoided if we require that
>   any communication using a ULID must be terminated when the ULID
>   becomes invalid (due to the underlying prefix becoming invalid).  If
>   that behavior is desired, it can be accomplished by explicitly
>   discarding the shim state when the ULID becomes invalid.  The context
>   recovery mechanism will then make the peer aware that the context is
>   gone, and that the ULID is no longer present at the same locator(s).
>  
Invalid... or if you move away from the link on which you had
the ULID? The HBA draft does allow dynamic case, so it seems
that this can happen.

Editorial:

Introduction: I'd prefer writing this in a style that focuses
less on what the history with the WGs and approaches
was, and more on the what the protocol does. Same for
the abstract, e.g., s/The SHIM6 working group is specifying
a layer 3 shim approach/The SHIM6 protocol is a layer 3 shim/

>   15.   Open Issues  . . . . . . . . . . . . . . . . . . . . . . .   81
>   19.   Possible Protocol Extensions . . . . . . . . . . . . . . .   88
>  
These should probably go to an appendix.

>   identifiers to locators, such a name space isn't necessary (and
>   furthermore doesn't seem to help) to solve the multihoming problem.
>  
I thought "is not" is better style than "isn't" (and same for
"doesn't"), but I'm this is not my native language...

>   and Provide Independent IP addresses.
s/Provide/Provider/

> The format allows adding additional notions of
>   "metrics" over time.  But this is merely a place holder; even in
>   order to use this there would have to be a mechanism by which the
>   host can find out what preference values to use, either statically
>   (e.g., some new DHCPv6 option) or dynamically.
Is the latter part talking about the preferences in general
or just the additional notions of metrics? For the former,
even if the protocol is fully defined now, one still has to
find out the preferences locally. For the latter, presumably
the receiver just ignores the unknown metrics, if any.

>   Context tag         Each end of the context allocates a context tag
Capitalized or not? Some of the other terms are not, and here we have
inconsistent capitalization.

>   Forked Instance Identifier (FII) In order to handle context forking,
add <vspace blankLines='1'/>

--Jari