Hi Tom, thanks for your review!
I have addressed most of your comments in the new revision 05 that I just uploaded before. For your remaining comments, I need additional input from you and the rest of this group: 1) The text from Section 6.3 that you refer to is the same as in RFC5201 (HIPv1). I agree with you on the endianess. However, I assume that there was a good reason why the sort() was specified this way in the original HIP version. I would therefore prefer to keep the text as is. Concerning the 96 vs. 128 bit issue, the draft defines HITs the same way as HIPv2, which from my understanding are the full 128bit. 2) Concerning Sec. 6.5 through 6.8, I consciously chose to provide the full specification here in order to significantly increase the readability of these sections. When only stating the differences, I found myself constantly changing between two documents (RFC7401 for the content and the DEX draft to see if the content was relevant, removed, or modified). To support those interested in the changes between RFC7401 and the DEX draft, I specifically call out the main differences at the end of each section. Does this satisfy your comment? 3) If your suggestion for Section 10 is purely cosmetic in nature, I would prefer to not put additional effort into the IANA section. So, are these changes cosmetic or mandatory? BR René 2016-11-20 3:32 GMT+01:00 Tom Henderson <[email protected]>: > 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
