Claudio Lordello wrote:
The issue is exactly that the result is implementation specific, and should not be.My 2 cents: 1) Using ipsec tunnels for provisioning private networks running dynamic protocols over a public infrastructure works just fine and existing equipment, my company's included, has had that functionality for years, without any of the issues mentioned in the draft. While it is true that some other implementations may have limitations with running dynamic routing over IPsec tunnels, that's more an implementation issue than one intrinsic to the IPsec protocol.
The IPsec WG recommended that we proceed with publishing it as an individual informational submission (which is where we are in the process), since any changes to RFC2401 would be better rolled into the (then pending, now emerging) update to 2401 rather than endorsed in a separate WG document (such changes have already been incorporated in the current 2401bis draft). Our draft adds to that primarily in discussing the issues - which is why we are proceeding with publication as informational.2) Some versions of this draft have been submitted to the ipsec WG in the past, and it did not progress in that WG. I am not sure I understand the motivation for publishing this document. Perhaps someone could clarify.
Claudio.Date: Wed, 21 Jan 2004 15:53:02 -0500
To: l3vpn@ietf.org
From: Ross Callon <rcallon@juniper.net>
Subject: draft-touch-ipsec-vpn-06.txt
Cc: Thomas Narten <narten@us.ibm.com>
We have been notified that the IESG is considering publication of an individual contribution entitled: Use of IPsec Transport Mode for Dynamic Routing
draft-touch-ipsec-vpn-06.txt
http://www.ietf.org/internet-drafts/draft-touch-ipsec-vpn-06.txt
This document is related to use of IPsec for support of VPNs. From the abstract of the document, it states in part:
This document addresses the use of IPsec to secure the links of a virtual (private) network (VN/VPN)...
Given that the document overlaps with our work, the issue has come
up regarding whether the document should be published without any
working group consideration, or whether the author should be requested
to bring the work to the l3vpn working group for consideration.
This leads to two questions:
- Does the l3vpn working group feel that this document should be reviewed by a public working group, such as the l3vpn working group, prior to publication?
- Do we have any technical comments on the document?
Comments to the list, please.
Thanks, Ross