Re: draft-touch-ipsec-vpn-06.txt

Alex Zinin <zinin@psg.com> Wed, 21 January 2004 06:04 UTC

Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11710 for <vpn-dir-archive@odin.ietf.org>; Wed, 21 Jan 2004 01:04:19 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjBSw-0002tS-9G for vpn-dir-archive@odin.ietf.org; Wed, 21 Jan 2004 01:03:50 -0500
Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0L63o4p011116 for vpn-dir-archive@odin.ietf.org; Wed, 21 Jan 2004 01:03:50 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjBSw-0002tD-2t for vpn-dir-web-archive@optimus.ietf.org; Wed, 21 Jan 2004 01:03:50 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11706 for <vpn-dir-web-archive@ietf.org>; Wed, 21 Jan 2004 01:03:48 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjBSt-0000ch-00 for vpn-dir-web-archive@ietf.org; Wed, 21 Jan 2004 01:03:47 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjBS2-0000bC-00 for vpn-dir-web-archive@ietf.org; Wed, 21 Jan 2004 01:02:54 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AjBR9-0000ZA-00 for vpn-dir-web-archive@ietf.org; Wed, 21 Jan 2004 01:01:59 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjBRB-0002nL-9Z; Wed, 21 Jan 2004 01:02:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjBR4-0002n6-VG for vpn-dir@optimus.ietf.org; Wed, 21 Jan 2004 01:01:55 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11671 for <vpn-dir@ietf.org>; Wed, 21 Jan 2004 01:01:53 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjBR2-0000Xy-00 for vpn-dir@ietf.org; Wed, 21 Jan 2004 01:01:52 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjBQ4-0000Vd-00 for vpn-dir@ietf.org; Wed, 21 Jan 2004 01:00:53 -0500
Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1AjBPg-0000Tf-00 for vpn-dir@ietf.org; Wed, 21 Jan 2004 01:00:28 -0500
Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AjBPg-000PP7-E9; Wed, 21 Jan 2004 06:00:28 +0000
Date: Tue, 20 Jan 2004 17:54:50 -0800
From: Alex Zinin <zinin@psg.com>
X-Mailer: The Bat! (v1.62i) Personal
Reply-To: Alex Zinin <zinin@psg.com>
X-Priority: 3 (Normal)
Message-ID: <104101484507.20040120175450@psg.com>
To: Thomas Narten <narten@us.ibm.com>
CC: Ross Callon <rcallon@juniper.net>, vpn-dir@ietf.org
Subject: Re: draft-touch-ipsec-vpn-06.txt
In-Reply-To: <200401210035.i0L0ZVV07875@cichlid.raleigh.ibm.com>
References: <200401210035.i0L0ZVV07875@cichlid.raleigh.ibm.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: vpn-dir-admin@ietf.org
Errors-To: vpn-dir-admin@ietf.org
X-BeenThere: vpn-dir@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/vpn-dir>, <mailto:vpn-dir-request@ietf.org?subject=unsubscribe>
List-Id: VPN Directorate <vpn-dir.ietf.org>
List-Post: <mailto:vpn-dir@ietf.org>
List-Help: <mailto:vpn-dir-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/vpn-dir>, <mailto:vpn-dir-request@ietf.org?subject=subscribe>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org
X-Spam-Status: No, hits=0.7 required=5.0 tests=AWL,DATE_IN_PAST_03_06, RCVD_NUMERIC_HELO autolearn=no version=2.60
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Thomas, et al-

 Rereading the e-mail from Ross, I think the main point is that the
 document should be brought before the WGs dealing with the related
 issues (Ross suggests L3VPN and IPSEC). I think this is a reasonable
 request--a 2-week Last Call with a careful explanation of the reasons
 should do it, I think.

-- 
Alex
http://www.psg.com/~zinin/

Tuesday, January 20, 2004, 4:35:31 PM, Thomas Narten wrote:
> Hi Ross.

> Digging through some old mail, I have this note. This document has
> come up to the IESG again for approval as an informational document
> and will be discussed Thursday. If there is a problem with publishing
> this, we need to be specific about why not.

> If this  conflicts with existing WG work and it would be better to
> delay publication until after some RFCs are published, that is a
> possibility, but we will need to have cause

> Can one of you review (or get someone to review) this to see if you
> have any real issues?

> Thomas

> Ross Callon <rcallon@juniper.net> writes:


>> At 03:39 PM 9/19/2003 -0400, Thomas Narten wrote:

>> >Ron, Russ and Rick:
>> >
>> >Has this document been discussed in the VPN WGs at all? Is there any
>> >issue with publishing them as informational? (Joe has asked the RFC
>> >editor to publish them as info documents).
>> >
>> >Thomas

>> I have a problem with this being published as an RFC in any
>> form, prior to proper working group review. We have in the past
>> (in the IETF) had a number of cases of people publishing things
>> as informational in order to get around the need for IETF review.
>> While I understand why people want to avoid having their work
>> reviewed, I don't think that this is something that we should
>> encourage. In some cases in fact the document that was 
>> published as informational was fine. In some other cases the 
>> approach was fine, but the spec was incomplete. In a few
>> cases the approach had flaws. 

>> Note that I don't actually know whether there is anything that
>> should be changed in the document (in a very quick look this
>> evening I didn't see any problems with the actual approach). 

>> However, I don't think that it is correct to let them subvert the
>> process. There are numerous places in the ppvpn working group
>> minutes where the document has been referred to, in one case
>> as a reason to avoid progressing a different document. How can
>> someone say "we have an alternate document, which we are
>> not going to discuss, but this other document is the reason that
>> the working group shouldn't progress your document"? This 
>> doesn't seem like a valid process to me. 

>> Thus I think that both the L3VPN working group and the IPSec
>> working group should explicitly review the draft before it is 
>> published as an RFC in any form. 


>> While I am not aware of it being explicitly discussed, it has 
>> apparently come up by reference in a number of discussions,
>> and appears to have been presented once during a different
>> presentation in spite of not appearing on the agenda. 

>> This is what I was able to find looking through one minutes 
>> (I only looked back as far as IETF 49):


>>  From the minutes of IETF 56, during the discussion of 
>> draft-declercq-ppvpn-ce-based-sol-00. 

>>          Joe Touch: We have running code that is similar to this draft, except 
>>          it is push-based, and not pull-based. Also it has not been cited as 
>>          reference. 90% is similar to this document, 10 % is different. We have 
>>          running code. 


>> There was a brief reference in passing in IETF 55 during the 
>> discussion of IPsec protected Virtual Links for PPVPNs 
>> (Mark Duffy). (again this was along the line of "how can you
>> progress a document as a working group document when it
>> doesn't conform to this non-working-group document). 


>>  From the minutes of IETF 53, March 2002:

>>          Joe Touch gave a background for dynamic routing for IPSec transport mode. 
>>          Didn't go to standards track to avoid confusion to already existing RFC 2401 
>>          (and therefore informational). 

>> This seemed to have occurred during or just after a presentation of 
>> draft-knight-ppvpn-ipsec-dynroute-00.txt

>> The alleged reason for not going standards track doesn't make sense
>> to me. 


>> During the 51st IETF (London, August 2001), in the discussion 
>> of draft-declercq-ppvpn-ce-based-00.txt (renamed as 
>> draft-ietf-ppvpn-ce-based-00.txt) there was a mention:

>>          Can use IPSec in tunnel mode (ipsec does SA selection, encapsulation 
>>          and authentication/encryption) or transport mode (draft-touch-ipsec-..).


>> During the 50th IETF, during a discussion of "Use of IPSEC with PPVPN" (Bryan Gleeson, 
>> draft-gleeson-IPSec-ppVPN-00.txt):

>>          Comment - Joe Touch: This has been addressed in my draft. Read draft-touch-IPSec-VPN-01.txt 
>>          (used IP-in-IP encapsulation within IPSec transport mode).

>> Ross


> _______________________________________________
> Vpn-dir mailing list
> Vpn-dir@ietf.org
> https://www1.ietf.org/mailman/listinfo/vpn-dir


_______________________________________________
Vpn-dir mailing list
Vpn-dir@ietf.org
https://www1.ietf.org/mailman/listinfo/vpn-dir