Re: WGLC: draft-ietf-hip-dex-04

Oh,

And Tom, thanks for the solid review.

Bob

On 11/19/2016 09:32 PM, 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
>