[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Draft reviews
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