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

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
>