BGP/MPLS IP Virtual Private Networks (VPNs)
draft-ietf-l3vpn-rfc2547bis-03

document: draft-ietf-l3vpn-as2547-05.txt
- references section has:

   [IF-MIB] "The Interfaces Group MIB using SMIv2", McCloghrie,
   Kastenholtz, RFC 2233, November 1997
  Should point to RFC2863 instead since 2863 obsoletes 2233!

- references section also hs:

   [RFC2570] "Introduction to Version 3 of the Internet-standard Network
   Management Framework", Case, Mundy, Partain, Stewart, RFC 2570, April
   1999

   [RFC2571] "An Architecture for Describing SNMP Management
   Frameworks", Harrington, Presuhn, Wijnen, RFC 2571, April 1999

   [RFC2572] "Message Processing and Dispatching for the Simple Network
   Management Protocol (SNMP)" Case, Harrington, Presuhn, Wijnen, RFC
   2572, April 1999

  These 3 have been obsoleted. New RFCs are: 3410, 3411 and 3412.
  But... there are no citations to these references, so they probably 
  should be removed.

- At most places where they talk about "MIB" or even worse "MIBs" they
  mean "MIB modules" and "MIB modules" respectively. Would be good to fix
  that.

- I am worried about them using MIB module names that (as far as I know)
  will NOT get published under that name. The reason why that will not happen
  is that they tend to rename their mib modules when they get approved.
  Several of the MIB modules they mention are not even in AD evaluation.
  Maybe it is better to just name the title of the MIB module they intend
  to speak about. They say that "...can be maneged with XXX" so the "can"
  I think makes it OK to be informative reference. But that will let these
  module names (that most probably will change) go into a PS document.
  In fact the "title" of the MIB module for [L3VPN-MIB] has already changed,
  so using the title seems risky too.

- They talk about (page 17):
           Presumably the PE routers will not accept unauthorized TCP
           connections or SNMP commands, so such traffic will be thrown
           away; the danger is that the PE may need to use a significant
  I can live with it. But SNMP has a noAuthnoPriv mode which means that
  SNMP commands (under configuration control) can be OK to come in as
  unauthenticated. There is still the normal authorization, but if not
  authenticated, then that does not help of course.

DISCUSS by Steve already covers my concerns and concerns received
from the ops directorate. For completeness sake, I list the comment
that I received from Pekka Savola from the opsn directorate:

rfc2547bis
----------

(I didn't read this document, just scanned through the typical nits.)

editorial
=========

 - cut down the abstract!  40+ lines is ridiculously long.  I'd say
10-15 is the maximum!  Most of this could probably go at the top of
the Introduction.

 - maybe rename Authors' Addresses to "Contributors" and tail down the
list a bit; take off Erik and Yakov to a separate "Editors' Addresses"
section?

 - there is no Security Considerations section.

applicability statement
-----------------------

 substantial
 ===========

 - security considerations section is missing.

 - more verbiage on security issues for section 1 should be added;
  maybe add something like the follows as the second-last paragraph:

  If the customer's network has high security requirements and/or the
  customer cannot trust the service provider to be able to secure its
  network sufficiently so that the VPNs would neverbe compromised, the
  customer may want to consider using a different approach for VPNs,
  e.g., IPsec-protected CE-CE VPNs [IPSEC-VPN].  Doing the VPNs on
  your own may also be an attractive approach if the customer is
  worried that the service prodiver might be performing or be forced
  to perform (without telling the customers) wire-tapping, "lawful
  interception", intelligence gathering, etc. which would compromise
  the confidentiality of the intra-site communications.

(the key point here, compared to the already existing paragraph, is
the trust in the SPs ability to secure the network properly, and the
trust to in the SP to provide confidential service.  With all kinds of
wiretapping etc. getting more and more common, I think this should be
spelled out.)

 editorial
 =========
 - some of those normative references have not been approved yet (just
stating to call it out explicitly that the doc won't be published
before the others are done as well)

 - the abstract seems a bit half-assed ("..  and other documents
listed in the References section"

 - includes some use of uppercase keywords, which may be inappropriate
for an applicability statement..

 - the text in section 7 of non-support of IPv6 might not hold the
test of time, i.e., if this ends up being published as an RFC, the RFC
might be factually wrong in a year or two.  Maybe a reason to reword,
and to look for similar issues elsewhere in the doc ?

 - section 14 on QoS might mention traffic shaping (or similar) at the
egress interface (i.e.: traffic from the Internet to the site),
because that's what's the more ifficult problems, worms, DDoS etc.
considereed.  Of course, there are no MPLS/VPN -specificity there.

 nits
 ====
 - old boilerplates
 - reference in the abstract
 - in section 2, s/In an IGP/If an IGP/
 - in section 3, s/wherea/where a/
 - in section 6.2, s/routers to/routers do/
 - in section 15, s|RFC BGP/MPLS|BGP/MPLS|

Reviewed by Lucy Lynch, Gen-ART

The rfc2547bis document is not a model of clarity, but as2547 explains a lot. Perhaps it would be appropriate to add to the abstract of rfc2547bis a note saying "READ AS2547 FIRST"?

Because there are already DISCUSSes on the document, I'm not casting a DISCUSS based on the large number of language comments in the review. But they should be looked at.

draft-ietf-l3vpn-rfc2547bis-01:

  The Abstract is very long.  There must be a way to make it shorter.

  Please spell out acronyms the first time they are used.  

  In section 1.6: s/privacy/confidentiality/

  In section 13.1: s/Cryptographic privacy/Cryptographic confidentiality/

  Please rename section 13 to "Security Considerations."  To be consistent,
  you might consider adding "Considerations" to the end of the section 14
  and section 15 titles too.

draft-ietf-l3vpn-as2547-05:

  In the Abstract, please replace "[BGP-MPLS-IP-VPN]" with the RFC number
  once it is assigned.

  Please rename section 6 to "Security Considerations."

draft-ietf-l3vpn-rfc2547bis-01:

The abstract is pretty long -- most of what's there would be better used as "Introduction" text.

The document is missing a "Security Considerations" section, though it does talk about security in several places -- most notbaly section 13.  Perhaps section 13 should be titled "Security Considerations".

draft-ietf-l3vpn-as2547-05.txt:

Same comment on "Security Considerations", though section 6 is titled "Security".

draft-ietf-l3vpn-as2547:

I liked it a lot.  I hope there's no static because there's no section labeled "Security Considerations"; the "Security" section is quite good.