Hi Gonzalo, draft-ietf-hip-dex-05 is ready to be sent to the IESG.
BR René -----Original Message----- From: Gonzalo Camarillo [mailto:[email protected]] Sent: Donnerstag, 4. Mai 2017 14:47 To: René Hummen <[email protected]> Cc: Tom Henderson <[email protected]>; HIP <[email protected]> Subject: Re: [Hipsec] WGLC: draft-ietf-hip-dex-04 Rene, I am re-sending my email below. Thanks! Gonzalo On 27/04/2017 2:14 PM, Gonzalo Camarillo wrote: > 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
