Subject: Re: [Hipsec] Developing a todo list for getting HIP on the standards track

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 09 Apr 2009 09:10:13 +0300

Hi,

thanks Bob for getting this started.

Yes, we need to come up with a list of things that would need to be 
revised in order to move to PS. Most importantly, we need to work on the 
experiment report (handled in the RG) so that the IESG understands the 
reasons why the HIP experiment is a success. In Tom's presentation to 
the IAB, the need for a good experiment report that answers the 
questions that made HIP experimental in the first place was stressed 
many times. These are the questions we did not have answers for before 
starting experimenting with the protocol.

Regarding time frames, as soon as we finish the work on HIP-based 
overlays and NAT traversal, we can start more serious discussions with 
our new AD in order to get this work chartered.

Also note that one of the questions we will get from the IESG is whether 
or not the level of energy in the WG is enough to revise all the specs 
we want to revise. Therefore, knowing who can commit serious cycles to 
this will be very useful.

Cheers,

Gonzalo

Robert Moskowitz wrote:
> THE HIP EXPERIMENT IS A SUCCESS.
> 
> Or at least that is my position and I will hold to it.
> 
> Yes there are pieces that still need more work and more business cases 
> are needed but it is time for the work to move to standards track which 
> means work for many and time commitments.  Myself included.
> 
> So first which RFCs are impacted?  All the HIP RFCs?  For example, 5207 
> is informational; does it need changes even while staying informational?
> 
> IMO ALL the other HIP RFCs (4423 included) will need to be reved.  So we 
> have to look at them all to see what needs to be thought out (like the 
> LSI discussion that I started to a small group and Miika has brought to 
> the list) and what else is impacted.  For example, ORCHIDs (RFC4843) 
> will either need to go to Standards as well or we will need to NOT 
> reference ORCHIDs.
> 
> There is also the BEET draft that has timed out yet again.  I have 
> already started working with Tim Polk on this an I spoke with Sheila 
> Frankel about it thursday.  Tim has asked Sheila to give it an expert 
> review.  Sheila wanted to know if all BEET is is tunnel without 
> tunneling, and if so is it really worth saving those handful or 2 of 
> bytes per packet.  Off the cuff, I responded that BEET is a header 
> compression in the classical mode of header compressions.  That those 
> that implemented HIP figured out that my original intent to run HIP over 
> Transport mode had issues, and that Tunnel was better, but that the 
> whole Tunnel header could be compressed out.  That there are use cases 
> for HIP where that overhead IS an issue and so we should be allowed a 
> tunnel compression mode.
> 
> Further we have actual experience with the Linux 2.6.27 kernel that 
> IPsec and HIP can coexist.  That the presence of BEET mode support in 
> the kernel is not a problem with IPsec implementations.  But it is clear 
> at least to me that text is needed in draft 10 of BEET.
> 
> Anyway, I will begin to post areas of discussion on items we need to 
> address in each of our documents and hope that editors will step forward 
> (myself included) that will make the needed changes and shepard through 
> the revised documents over the next year.
> 
> One other thing is will we need a charter revision?  If so, what 
> political energy will be needed to accomplish this?   IMO, those that 
> have invested time and money will want to see HIP through to Standards 
> and will lend the effort to get this in place.
> 
> I am putting in my request to go to Stockholm.  At this point, though, I 
> will not be attending Hiroshima (I have avoided asia venues because of 
> Shabbos challenges, and for 2 years now Verizon has canceled all Q4 
> non-sales travel, it took quite a bit for me to attend Minneapolis last 
> year; Japan would never have gotten approved).
> 
> Kudos to all HIP authors, developers, testers, implmentors, and most 
> importantly, chairs.
> 
> 
> _______________________________________________
> Hipsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hipsec
>

---

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 09 Apr 2009 09:17:05 +0300

Hi,

some of the questions that came up during Tom's presentation to the IAB 
were what type of load does the DNS see when HIP is deployed, 
scalability of the solutions, performance decrease, benefits, how HIP 
works with legacy applications, and how it enables new applications.

We already have answers to some of these but, in any case, they give you 
an idea of questions we may be getting in the future.

Cheers,

Gonzalo

Gonzalo Camarillo wrote:
>> are needed but it is time for the work to move to standards track 
>> which means work for many and time commitments.  Myself included.
>>
>> So first which RFCs are impacted?  All the HIP RFCs?  For example, 
>> 5207 is informational; does it need changes even while staying 
>> informational?
>>
>> IMO ALL the other HIP RFCs (4423 included) will need to be reved.  So 
>> we have to look at them all to see what needs to be thought out (like 
>> the LSI discussion that I started to a small group and Miika has 
>> brought to the list) and what else is impacted.  For example, ORCHIDs 
>> (RFC4843) will either need to go to Standards as well or we will need 
>> to NOT reference ORCHIDs.
>>
>> that implemented HIP figured out that my original intent to run HIP 
>> over Transport mode had issues, and that Tunnel was better, but that 
>> the whole Tunnel header could be compressed out.  That there are use 
>> cases for HIP where that overhead IS an issue and so we should be 
>> allowed a tunnel compression mode.
>>
>> the kernel is not a problem with IPsec implementations.  But it is 
>> clear at least to me that text is needed in draft 10 of BEET.
>>
>> address in each of our documents and hope that editors will step 
>> forward (myself included) that will make the needed changes and 
>> shepard through the revised documents over the next year.
>>
>> I am putting in my request to go to Stockholm.  At this point, though, 
>> I will not be attending Hiroshima (I have avoided asia venues because 
>> of Shabbos challenges, and for 2 years now Verizon has canceled all Q4 
>> non-sales travel, it took quite a bit for me to attend Minneapolis 
>> last year; Japan would never have gotten approved).
>>