Applicability Statement for Layer 1 Virtual Private Network (L1VPN) Basic Mode
RFC 5253
Yes
(David Ward)
No Objection
(Chris Newman)
(Cullen Jennings)
(Jari Arkko)
(Magnus Westerlund)
(Ron Bonica)
(Russ Housley)
(Tim Polk)
Note: This ballot was opened for revision 05 and is now closed.
David Ward Former IESG member
Yes
Yes
()
Unknown
Ross Callon Former IESG member
Yes
Yes
(2008-03-26)
Unknown
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).
Chris Newman Former IESG member
No Objection
No Objection
()
Unknown
Cullen Jennings Former IESG member
No Objection
No Objection
()
Unknown
Jari Arkko Former IESG member
No Objection
No Objection
()
Unknown
Magnus Westerlund Former IESG member
No Objection
No Objection
()
Unknown
Mark Townsley Former IESG member
(was Discuss, No Objection)
No Objection
No Objection
(2008-03-27)
Unknown
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.
Ron Bonica Former IESG member
No Objection
No Objection
()
Unknown
Russ Housley Former IESG member
No Objection
No Objection
()
Unknown
Tim Polk Former IESG member
(was No Record, Discuss)
No Objection
No Objection
(2008-03-26)
Unknown
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.