Hi Rene, to be clear, you had 3 questions on your email below and you said you needed further input from the group. Do you mean version 05 of the draft is ready to be sent to the IESG (i.e., ready for publication request), or you will revise the draft once more before it is ready?
Thanks, Gonzalo On 26/03/2017 7:16 PM, René Hummen wrote: > Hi Gonzalo, > > I did not receive any comments indicating the need to make further > changes. From my side, we are ready to finalize the draft. > > BR > René > > 2017-03-16 16:25 GMT+01:00 Gonzalo Camarillo > <[email protected] <mailto:[email protected]>>: > > 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]> > > <mailto:[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]> > <mailto:[email protected] <mailto:[email protected]>> > > https://www.ietf.org/mailman/listinfo/hipsec > <https://www.ietf.org/mailman/listinfo/hipsec> > > <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
