I will start on it Tuesday.
Bob
On 11/20/2016 03:26 AM, Gonzalo Camarillo wrote:
Hi Tom,
thanks. Your comments seem to be the only one we got on this draft
during the WGLC. Authors, could you please revise the draft in order to
address these comments?
Thanks,
Gonzalo
On 20/11/2016 4:32 AM, Tom Henderson wrote:
Gonzalo, I have reviewed HIP DEX again and believe it is ready to
publish, although I spotted a few minor items below that can be handled
in the next revision.
- Tom
Editorial/minor:
Section 1: The numbered list is somewhat tersely written and may be
hard to interpret by the newcomer to HIP specifications. Consider to
elaborate more (using fuller sentences and not sentence fragments). e.g.:
"Forfeit of Perfect Forward Secrecy with the dropping of an ephemeral
Diffie-Hellman key agreement." could be
"Forfeit of the HIPv2 Perfect Forward Secrecy property due to the
removal of the HIPv2 ephemeral Diffie-Hellman key agreement."
Section 1.1, spell out 'DoS' first time usage
Section 4.1: "Note that x and y each constitute half the final session
key material." (change to 'half of the')
The figure in 4.1 does not have a caption, and also, why is 'mac'
lowercased?
Sec 4.1.3.1: "Since only little data is protected by this SA" (perhaps
s/little/a small amount/)
Sec. 5.2.4: "The following new HIT Suite IDs are defined..." (s/IDs
are/ID is/ because there is only one defined)
Sec. 6.3: "sort(HIT-I | HIT-R) is defined as the network byte order
concatenation of the two HITs... comparison of the two HITs interpreted
as positive (unsigned) 128-bit integers in network byte order" what
does it mean to define a sort on a network byte order concatenation? It
seems perhaps clearer to leave endian issues out (they are implicit
everywhere in a protocol) and just define it as a comparison on HITs
interpreted as unsigned 128-bit integers (and by the way, is the full
128 bits including prefix included or just the 96 bits)?
Sec. 6.5 through 6.8: Unlike much of this draft, these sections do not
just specifically call out the differences from the corresponding RFC
7401 sections, but instead restate the modified processing flow, and it
is hard to spot what is different here. I wonder whether it would be
clearer to just refer to those processing steps in RFC 7401 that are
changed.
Sec. 8: Can a MITM reply to I1 with ICMP parameter problem, causing the
true response (coming later) to be ignored because the initiator already
gave up? Maybe clarify here or in sec 5.4 to wait a little while before
accepting the result of an ICMP.
Sec. 10: Consider to update the IANA section in the style that RFC 8003
(and others) used, stating the history of the registry and what exactly
is requested to be changed. For example, something like "RFC 5201 and
later RFC 7401 established the following registry .... This document
defines the following new codepoints for that registry ..."
_______________________________________________
Hipsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/hipsec
_______________________________________________
Hipsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/hipsec
