Applicability Statement for Layer 1 Virtual Private Network (L1VPN) Basic Mode
Note: This ballot was opened for revision 05 and is now closed.
(Ross Callon) Yes
Comment (2008-03-26 for -)
Note that the CCAMP working group email list was very appropriately informed of the last call that took place on the L1VPN WG list, in order ensure that CCAMP folks were aware of this (although there was already a large overlap in participation).
(David Ward) Yes
(Jari Arkko) No Objection
(Ron Bonica) No Objection
(Russ Housley) No Objection
(Cullen Jennings) No Objection
(Chris Newman) No Objection
(Tim Polk) (was No Record, Discuss) No Objection
The following issue was raised by Catherine Meadows in a secdir review: 2. The description of how RSVP-TE provides tamper protection is actually in RFC 2205 (on RSVP), not RFC 3209. RFC 3209 makes no changes to the way tamper-protection is done in RSVP as far as I can tell. It would probably be best to reference both. I agree with her opinion, but this issue is not blocking.
(Mark Townsley) (was Discuss, No Objection) No Objection
Comment (2008-03-27 for -)
In general, there seems to be a lot of overlap with rfc4847 in this document. Is it really necessary? Section 6.1: "In the L1VPN Basic Mode, L1VPN connection topology is controlled by the customer. That is, a customer can request" Please clarify that this is the CE-CE connection topology, not the provider network topology which in basic mode is not under direct customer control (at least as I understand the difference between basic and enhanced l1vpn modes). I believe there may be some overlap in function between the CPIs/PPIs described here, and the (TAI/SAI) constructs which we have in L2VPN (draft-ietf-l2vpn-signaling, in RFC Ed. Q). I strongly suggest a review of this, and when it comes time to write the solution perhaps some of this work can be reused.