Subject: Re: [Hipsec] RFC5201-bis and RFC5202-bis status

From: Miika Komu <[email-masked]>
Date: Tue, 28 Oct 2014 16:00:59 +0200

Hi,

On 09/16/2014 08:20 AM, Tom Henderson wrote:
> On 09/15/2014 04:37 AM, Gonzalo Camarillo wrote:
>> Hi Tom (Henderson),
>>
>> Jari, Brian, and Ted still have discusses on this document. Could you
>> please summarize for each of them the status of this draft with respect
>> to their particular comments?
>>
>> Thanks,
>>
>> Gonzalo
>>
>>
>
> Gonzalo, the most recent status on this draft was posted to the HIP list
> in this message:
>
> http://www.ietf.org/mail-archive/web/hipsec/current/msg03942.html
>
> Since then, it seems that Jari and Brian have cleared their discusses.
>   I believe that the IANA issues have been mostly resolved (Ted's
> discuss).  Ted's discuss was against version -14 of the draft, while we
> are at version -17 now.  There is a lingering comment that I haven't
> picked up from Barry (item 5 in the above email) that pertains to IANA
> text; I plan to publish those in version -18.
>
> I could probably put out a version -18 shortly that may resolve all of
> the open issues, but it just requires that I generate a new Appendix C
> example packet.  I'll try to get to that in the next day or two.

I wrote a checksum generator, and I have independently verified that the 
checksums in RFC5201-bis are correct.

---

From: Tom Henderson <[email-masked]>
Date: Tue, 28 Oct 2014 09:44:25 -0700

> checksums in RFC5201-bis are correct.

Miika, thank you for checking this.

This leaves one open issue, regarding the clarifications to 
HIT_SUITE_LIST.  I originally put a diff proposal here:

http://trac.tools.ietf.org/wg/hip/trac/attachment/ticket/51/rfc5201-bis-19-to-20-pre.diff

This proposal drew one review on the list from Rene, who suggested the 
following:

1) swap the encoding of the HIT Suite IDs to use the lower four-order 
bits instead of the higher four-order bits

2) fix an editorial reference to “HMAC parameter” -> “HIP_MAC and 
HIP_MAC_2 parameters” (or RHASH function).

3) change one of the proposed 'should' words to 'SHOULD'

While I am sympathetic to Rene's argument in 1), no one else has 
supported this change on the list, so given the late stage of this 
document, I would suggest to keep the encoding as is.  The changes 
proposed in 2) and 3) are editorial, in my view, so I don't see a 
problem to accept them.

I regenerated the diff according to Rene's suggestions, and posted it here:

http://trac.tools.ietf.org/wg/hip/trac/attachment/ticket/51/rfc5201-bis-19-to-20-pre-2.diff

So in summary, I would like to now convey to our AD that we have a diff 
to the version -19 draft that is editorial/clarification in nature, and 
ask whether and how it can be handled procedurally, such as:

- publish a -20 and revisit some of the reviews (since version -19 was 
officially reviewed and approved, I don't know what it means to now post 
a -20 version)
- avoid publishing a -20 and handle these changes similar to AUTH48 changes
- scrap the diff and just publish version -19

Our AD can let us know how he prefers to handle it.

- Tom

---

From: Ted Lemon <[email-masked]>
Date: Tue, 28 Oct 2014 14:07:36 -0400

On Oct 28, 2014, at 12:44 PM, Tom Henderson <[email-masked]> wrote:
> While I am sympathetic to Rene's argument in 1), no one else has supported this change on the list, so given the late stage of this document, I would suggest to keep the encoding as is.  The changes proposed in 2) and 3) are editorial, in my view, so I don't see a problem to accept them.

I would definitely concur with this.   This is not the time to do further engineering.

> So in summary, I would like to now convey to our AD that we have a diff to the version -19 draft that is editorial/clarification in nature, and ask whether and how it can be handled procedurally, such as:
> 
> - publish a -20 and revisit some of the reviews (since version -19 was officially reviewed and approved, I don't know what it means to now post a -20 version)

I would prefer that you publish the -20.   Assuming that that is the working group's final say, we can then push the publish button.