Draft reviews

[Sébastien Barré <[e-mail]>]

Hi,

While writing the shim6-impl draft, I have noted some minor things with 
the drafts. Most of them are editorial comments, I have found also some 
may/must/should conflicts.
Comments about shim6-proto-09,failure-detection-10, 
locator-pair-selection-02 and multihome-shim-api are detailed below.

regards,

Sébastien.


draft-ietf-shim6-proto-09.txt
-----------------------------------------------

Section 5.6  : ULID pair : ... addresses in the IPv6 header does not 
match ->
    do not match
           CGA PDS : ...so the receiver...-> so that the receiver
Section 5.15 : C : critical, One if the parameter is critical, and MUST 
be recognized by the recipient -> I don't think this is a MUST in the 
sense of RFC2119, since currently no option is defined as critical. The 
draft thus specifies as an "absolute requirement of the specification" 
something that does not exist yet. I would say that this may be rather a 
"must" of a given implementation, and as such I just would prefer to see 
it in lowercase.
Section 5.15.3 (at the end) : a of a 1 octet flag field followed... -> a 
sequence of a 1 octet ...
Section 7.1 : ...cycle through the unstrucutred -> unstructured
Section 7.2 : different than the ULID -> different from the ULID
Section 7.6 : I would add a pointer to section 7.15 : "A more detailed 
description of what should be done to detect confusions is given in 
section 7.15"
Section 7.15 : Forked Intance Identifier different than the ones... -> 
are different from the ones...
Section 7.15 : Conflicting MAY and MUST with section 7.6 : 7.6 says "The 
requirement is that the old context which used the context tag MUST be 
removed" while 7.15 says "the host MUST NOT use the old context, it MAY 
just discard the old context."
Section 8 : with an payload extension header -> with a payload...
Section 11 : Then it there is also no effect -> Then there is also...
Section 12.1 : for reachability detection porpuses -> purposes
Section 12.2 : for packets that does not have -> that do not have
Section 12.3 : it checks that the neither the ->it check that neither the...
Section 12.3 : I think that the checksum should be verified _after_ the 
length
    field, since this field is used by the checksum verification procedure.
    Failing to do that could result in reading memory areas past the end
    of the IPv6 packet.
Section 12.3 : Conflicting SHOULD and MUST with section 5.15 : 5.15 says 
"If a host receives an option that it does not understand and If C=1 
then the host SHOULD send back a Shim6 Error Message with Error 
Code=1..." while 12.3 says "If there is any option in the message with 
C=1 that isn't known to the host, the host MUST send a Shim6 Error 
Message with Error Code=1...".
Section 15.1 : it recommended -> it is recommended
Section 15.2 : §1 : the presudoheader -> pseudoheader
Section 15.2 : §2 : ...the next header header -> the next header
Section 15.2 : §3 : unless they implement are able -> unless they are able


draft-ietf-shim6-failure-detection-10.txt
-------------------------------------------------------------------

Section 3.3 : §5 : explicit rechability tests -> reachability
Section 4.1 : "Nodes SHOULD employ techniques listed in Section 3.1 and
   Section 3.2 to track the local situation." : These two sections are 
already
   completely covered by MUST/MAY statements. IMHO this creates a
   SHOULD/MUST/MAY conflict
   between section 3.1/3.2 and 4.1.
Section 4.1, item 5 : "REAP keepalive
       packets SHOULD continue to be sent at the Keepalive Interval
       until either a data packet in the SHIM6 context has been received
       from the peer or the Keepalive Timeout expires" : I would replace
       "has been received from" with "has been sent to"
Section 4.2 : §4 : so that the ULP SHOULD be informed -> thus the ULP 
SHOULD be informed.
Section 5.1 and 5.2 : The same field has name Reserved1 for keepalive 
and   
    Reserved for Probe. Probably it should also be Reserved1 for probe
    (since the probe has a Reserved2 field as well).
Section 5.1 and 5.2 : Strange use of the MUST statement regarding the 
Reserved*
    fields : All those fields MUST be ignored on receipt, but only
    the Reserved2 field of the probe message MUST be set to 0 upon
    transmission. I would replace this MUST with the usual 'It is set to 0
    ...'

draft-ietf-shim6-locator-pair-selection-02.txt
---------------------------------------------------------------------------

Section 2.2 : a locator pair is know to be...-> is known to be

draft-ietf-shim6-multihome-shim-api-03.txt
------------------------------------------------------------------------

Section 1 : §5 : a singed integer of... -> a signed integer

-- 
Sébastien Barré
Researcher,
CSE department, UCLouvain, Belgium
http://inl.info.ucl.ac.be/sbarre