Re: [Hipsec] WGLC: draft-ietf-hip-dex-04

[Gonzalo Camarillo <[e-mail]>]

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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/hipsec
>>
>