Service Requirements for Layer 2 Provider-Provisioned Virtual Private Networks
RFC 4665

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

(Mark Townsley) Yes

(Brian Carpenter) No Objection

(Ted Hardie) No Objection

(Sam Hartman) (was Discuss) No Objection

Comment (2006-01-18)
No email
send info
I'm rather frustrated that the IESG is seeing the l2vpn requirements
document at the same time as we see the protocols documents.  As in
this case when an AD believes there are missing requirements,
presenting the documents along with the protocol misses an important
opportunity for early engineering review.

(Russ Housley) (was Discuss) No Objection

Comment (2006-01-16)
No email
send info
  s/802.1d/802.1D/

  s/IPSec/IPsec/

(David Kessens) No Objection

(Dan Romascanu) No Objection

Comment (2006-05-31 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
   Service management MAY include the TMN 'FCAPS' functionalities, as 
   follows: Fault, Configuration, Accounting, Provisioning, and 
   Security, as detailed in [RFC4031].  
    
It is not clear what this phrase means. Is [RFC4031] referenced for the definition of the FCAPS functions, or because a l2vpn MAY in clude FCAPS functionality similar to what is defined in 4031 for l3vpns? 

Also, as suggested in a different comment s/Provisioning/Performance/

Magnus Westerlund No Objection

(Bert Wijnen) No Record

Comment (2006-01-19 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
I see:
   4.11 Management
   Standard interfaces to manage L2VPN services MUST be provided
   (e.g., standard SNMP MIBs).  These interfaces SHOULD provide access
   to configuration, verification and runtime monitoring protocols.

   Service management MAY include the TMN 'FCAPS' functionalities, as
   follows: Fault, Configuration, Accounting, Provisioning, and
   Security, as detailed in [RFC4031].

Pls s/MIBs/MIB Modules/ and pls do so too in sect 5.4 and sect 7.

And as far as I know, the P in FCAPS stands for Performance and not for
Provisioning.

It is also unclear to me why a capitalized MAY is used here??
In general, I think the use of capitalized SHOULD/MUST/MAY/SHALL etc
seems quite voluminous and not always appropriate in this document.

In any event, it seems to me that if you use MUST/MAY/SHOULD/SHALL
language from RFC2119, then that RFC must be cited and listed as a
normative reference, which has not been done.

Sect 4.7.1
  s/L2PVN/L2VPN/ !!??

IN this:
  4.7.2  Service Models
   A service provider MUST be able to offer QoS service to a customer
   for at least the following generic service types: managed access VPN
   service or an edge-to-edge QoS service.  The details of the service
   models can be found in [RFC3809] and in [RFC4031].  In L2VPN service,
   both DSCP ([RFC2474]) and 802.1p ([IEEE_802.1D]) fields MAY be used
   for this purpose.
it feels to me as if the doc is prescribing a business model or some such
for a service provider. Do we have anything to say about that?
I guess the requirement is that the protocols need to allow for it.