Bob, Rene when do you think you will get around to revising the draft, per our emails below? Thanks!
Cheers, Gonzalo On 22/11/2016 7:34 AM, Robert Moskowitz wrote: > 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
