Hi Rene, did you get answers to your questions below and, in general, enough input to finalize the draft?
Thanks, Gonzalo On 05/02/2017 11:59 PM, René Hummen wrote: > 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] > <mailto:[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 <http://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] <mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/hipsec > <https://www.ietf.org/mailman/listinfo/hipsec> > > _______________________________________________ Hipsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/hipsec
