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

[René Hummen <[e-mail]>]

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 <[e-mail]
>:

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