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

Alex Zinin <> Wed, 21 January 2004 06:04 UTC

Received: from ([]) by (8.9.1a/8.9.1a) with ESMTP id BAA11710 for <>; Wed, 21 Jan 2004 01:04:19 -0500 (EST)
Received: from localhost.localdomain ([] by with esmtp (Exim 4.20) id 1AjBSw-0002tS-9G for; Wed, 21 Jan 2004 01:03:50 -0500
Received: (from exim@localhost) by (8.12.8/8.12.8/Submit) id i0L63o4p011116 for; Wed, 21 Jan 2004 01:03:50 -0500
Received: from ([] by with esmtp (Exim 4.20) id 1AjBSw-0002tD-2t for; Wed, 21 Jan 2004 01:03:50 -0500
Received: from ietf-mx ( []) by (8.9.1a/8.9.1a) with ESMTP id BAA11706 for <>; Wed, 21 Jan 2004 01:03:48 -0500 (EST)
Received: from ietf-mx ([]) by ietf-mx with esmtp (Exim 4.12) id 1AjBSt-0000ch-00 for; 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; Wed, 21 Jan 2004 01:02:54 -0500
Received: from [] ( by ietf-mx with esmtp (Exim 4.12) id 1AjBR9-0000ZA-00 for; Wed, 21 Jan 2004 01:01:59 -0500
Received: from localhost.localdomain ([] by with esmtp (Exim 4.20) id 1AjBRB-0002nL-9Z; Wed, 21 Jan 2004 01:02:01 -0500
Received: from ([] by with esmtp (Exim 4.20) id 1AjBR4-0002n6-VG for; Wed, 21 Jan 2004 01:01:55 -0500
Received: from ietf-mx ( []) by (8.9.1a/8.9.1a) with ESMTP id BAA11671 for <>; Wed, 21 Jan 2004 01:01:53 -0500 (EST)
Received: from ietf-mx ([]) by ietf-mx with esmtp (Exim 4.12) id 1AjBR2-0000Xy-00 for; 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; Wed, 21 Jan 2004 01:00:53 -0500
Received: from ([] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1AjBPg-0000Tf-00 for; Wed, 21 Jan 2004 01:00:28 -0500
Received: from [] (helo= by 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 <>
X-Mailer: The Bat! (v1.62i) Personal
Reply-To: Alex Zinin <>
X-Priority: 3 (Normal)
Message-ID: <>
To: Thomas Narten <>
CC: Ross Callon <>,
Subject: Re: draft-touch-ipsec-vpn-06.txt
In-Reply-To: <>
References: <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <>, <>
List-Id: VPN Directorate <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on
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.


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 <> 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 mailing list