From gonzalo.camarillo@ericsson.com Wed Apr 8 23:09:10 2009 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 399E43A6B18 for ; Wed, 8 Apr 2009 23:09:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.2 X-Spam-Level: X-Spam-Status: No, score=-5.2 tagged_above=-999 required=5 tests=[AWL=1.049, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZKXfXEfhm-bg for ; Wed, 8 Apr 2009 23:09:08 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 030933A67EE for ; Wed, 8 Apr 2009 23:09:07 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 657AB21347; Thu, 9 Apr 2009 08:10:14 +0200 (CEST) X-AuditID: c1b4fb3e-aa81cbb0000024d5-72-49dd91460137 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 37EFC21281; Thu, 9 Apr 2009 08:10:14 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Apr 2009 08:10:13 +0200 Received: from [131.160.126.142] ([131.160.126.142]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Apr 2009 08:10:13 +0200 Message-ID: <49DD9145.8030405@ericsson.com> Date: Thu, 09 Apr 2009 09:10:13 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Robert Moskowitz References: <49CD3EB2.30303@htt-consult.com> In-Reply-To: <49CD3EB2.30303@htt-consult.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Apr 2009 06:10:13.0716 (UTC) FILETIME=[D88AD140:01C9B8D9] X-Brightmail-Tracker: AAAAAA== Cc: hipsec@ietf.org Subject: Re: [Hipsec] Developing a todo list for getting HIP on the standards track X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2009 06:09:10 -0000 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 > Hipsec@ietf.org > https://www.ietf.org/mailman/listinfo/hipsec > From gonzalo.camarillo@ericsson.com Wed Apr 8 23:18:07 2009 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA3D83A6D70 for ; Wed, 8 Apr 2009 23:18:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.212 X-Spam-Level: X-Spam-Status: No, score=-5.212 tagged_above=-999 required=5 tests=[AWL=1.037, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CNFzyHOCMlMC for ; Wed, 8 Apr 2009 23:18:06 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id C3FCA3A6B38 for ; Wed, 8 Apr 2009 23:15:59 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 76DE62144E; Thu, 9 Apr 2009 08:17:06 +0200 (CEST) X-AuditID: c1b4fb3e-ab01dbb0000024d5-c8-49dd92e29722 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 428FA2144D; Thu, 9 Apr 2009 08:17:06 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Apr 2009 08:17:05 +0200 Received: from [131.160.126.142] ([131.160.126.142]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Apr 2009 08:17:05 +0200 Message-ID: <49DD92E1.5020901@ericsson.com> Date: Thu, 09 Apr 2009 09:17:05 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: hipsec@ietf.org References: <49CD3EB2.30303@htt-consult.com> <49DD9145.8030405@ericsson.com> In-Reply-To: <49DD9145.8030405@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Apr 2009 06:17:05.0358 (UTC) FILETIME=[CDE666E0:01C9B8DA] X-Brightmail-Tracker: AAAAAA== Subject: Re: [Hipsec] Developing a todo list for getting HIP on the standards track X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2009 06:18:07 -0000 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: > 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 >> Hipsec@ietf.org >> https://www.ietf.org/mailman/listinfo/hipsec >> > > _______________________________________________ > Hipsec mailing list > Hipsec@ietf.org > https://www.ietf.org/mailman/listinfo/hipsec >