From exim@www1.ietf.org Sun Sep 21 23:44:37 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA17541 for ; Sun, 21 Sep 2003 23:44:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1HcU-0001OB-Lj for vpn-dir-archive@odin.ietf.org; Sun, 21 Sep 2003 23:44:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8M3iEJ8005340 for vpn-dir-archive@odin.ietf.org; Sun, 21 Sep 2003 23:44:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1HcU-0001O3-E1 for vpn-dir-web-archive@optimus.ietf.org; Sun, 21 Sep 2003 23:44:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA17532 for ; Sun, 21 Sep 2003 23:44:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1HcS-0001sL-00 for vpn-dir-web-archive@ietf.org; Sun, 21 Sep 2003 23:44:12 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A1HcN-0001sH-00 for vpn-dir-web-archive@ietf.org; Sun, 21 Sep 2003 23:44:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1HcH-0001Nv-6Q; Sun, 21 Sep 2003 23:44:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1HbH-0001NG-CA for vpn-dir@optimus.ietf.org; Sun, 21 Sep 2003 23:43:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA17513 for ; Sun, 21 Sep 2003 23:42:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1HbA-0001rd-00 for vpn-dir@ietf.org; Sun, 21 Sep 2003 23:42:52 -0400 Received: from natint2.juniper.net ([207.17.136.150] helo=merlot.juniper.net) by ietf-mx with esmtp (Exim 4.12) id 1A1Haz-0001r5-00 for vpn-dir@ietf.org; Sun, 21 Sep 2003 23:42:41 -0400 Received: from rcallon-lt.juniper.net (securepptp071.static.jnpr.net [172.24.253.71]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h8M3fij94076; Sun, 21 Sep 2003 20:41:44 -0700 (PDT) (envelope-from rcallon@juniper.net) Message-Id: <4.3.2.20030921233800.02bc4e90@zircon.juniper.net> X-Sender: rcallon@zircon.juniper.net X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Sun, 21 Sep 2003 23:40:33 -0400 To: Thomas Narten , vpn-dir@ietf.org From: Ross Callon Subject: Re: draft-touch-ipsec-vpn-05.txt In-Reply-To: <200309191939.h8JJdWgw019928@rotala.raleigh.ibm.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_94503819==_.ALT" Sender: vpn-dir-admin@www1.ietf.org Errors-To: vpn-dir-admin@www1.ietf.org X-BeenThere: vpn-dir@www1.ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: VPN Directorate List-Post: List-Help: List-Subscribe: , --=====================_94503819==_.ALT Content-Type: text/plain; charset="us-ascii" 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 --=====================_94503819==_.ALT Content-Type: text/html; charset="us-ascii" 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

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