Applicability Statement for Layer 1 Virtual Private Network (L1VPN) Basic Mode
RFC 5253

Note: This ballot was opened for revision 05 and is now closed.

(Ross Callon) Yes

Comment (2008-03-26 for -)
No email
send info
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

Comment (2008-03-26)
No email
send info
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 -)
No email
send info
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.

Magnus Westerlund No Objection