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

[Alex Zinin <[e-mail]>]

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 <[e-mail]> 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
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/vpn-dir


_______________________________________________
Vpn-dir mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/vpn-dir