[Hipsec] more comments on draft-ietf-hip-rfc5201-bis-04

["Ahrenholz, Jeffrey M" <[e-mail]>]

Here are some additional comments on the 5201-bis draft.

Section 5.4.2 says:
"However, an implementation MUST NOT send an ICMP message if the checksum fails; instead, it MUST silently drop the packet." If we MUST silently drop a packet, why do we have NOTIFY type 26, "CHECKSUM_FAILED"? (Debugging?)

Section 6.11 item 4: this says the association is considered broken if an
UPDATE is not ACKed, but one circumstance where the association is NOT broken
would be when a host is informing its peer of its current address list
(without changing the current preferred locators used.) In that case, the
association may continue happily without going to CLOSING.

Below are more minor editorial nits...

-Jeff


5.2.4, 5.2.5 - suggest changing "n bytes" in parameter diagram to "n bits"
the descriptions that follow (for random #I, solution #J) discuss n-bit
integers, and RHASH_len is stated as a bit length

in 5.3.2
To support the "<ECHO_REQUEST_UNSIGNED>i" used in the diagram, may want to add
a note about multiple ECHO_REQUEST_UNSIGNEDs as described in 5.2.20 with text such as:
"The R1 packet may contain zero or more ECHO_REQUEST_UNSIGNED parameters as
described in Section 5.2.20."

Then in 5.3.3 may change s/parameter/parameter(s)/ to support the
 "<ECHO_RESPONSE_UNSIGNED>i" diagram notation.

in 5.3.7 and 9
s/an HIP_MAC/a HIP_MAC/
(for consistency with "a HIP..." elsewhere in the document)

5.3.8, suggest changing:
"The receiver peer MUST validate both the HMAC and the signature."
to:
"The receiver MUST verify the echo response and validate both the HIP_MAC and the signature."
(because 5.3.7 says you MUST include the ECHO_REQUEST_SIGNED)

Section 6.4.1 s/SAH-1/SHA-1/

Section 6.7 s/the Responder a HIT with/the Responder selects a HIT with/

Section 6.8 item 6 s/a Initiator/an Initiator/

Section 5.3.2 and 6.8 item 7 s/SHOULD not/SHOULD NOT/

Section 6.9 item 12 s/packet I2/I2 packet/
Section 6.9 item 13 s/verify the HMAC/verify the HIP_MAC/  for consistency?
(elsewhere, "verify the HIP_MAC" is used)

Section 6.11 s/steps below ./steps below./

Section 6.11 item 2: support multiple ACKs?
replace:
"The UPDATE packet MAY also include an ACK of the peer's Update
ID found in a received UPDATE SEQ parameter, if any."
with:
"The UPDATE packet MAY also include zero or more ACKs of the peer's Update
ID(s) from previously received UPDATE SEQ parameter(s)."

Section 7
suggest defining the first occurrence of ACL:
"This access control list (ACL) SHOULD also include..."

s/representing which hosts/representing for which hosts/
s/for such ACL also/for such ACLs, and also/ ?

Appendix C.2 suggest re-wording slightly:
"The IPv4 checksum value for the example I1 packet equals the IPv6 checksum
 value (since the checksum components due to the IPv4 and IPv6 pseudo-header are the same)."

Appendix D 
s/Today should be used only when/Today these groups should only be used when/