Provider Provisioned Virtual Private Network (VPN) Terminology
RFC 4026

In the title of section 5.1.1.2, I believe CE-bS should be CE-S

In section 7.3, what's [DTLS-xxx] mean?  Is it an unresolved reference, or another name for an MTU, or something else?

I was very close to putting in a DISCUSS based on the following:

This document depends heavely on a long list of informational references.
Strictly speaking,
they are indeed informational (that is why this is a COMMENT and not a DISCUSS), but several sections would become fairly hard to read if work
doesn't progress or changes substantially. I think it would be a good idea
to review the list of references and see if the document can become
less depended on work in progress.

Comments received from the ops directorate by Pekka Savola:

 - there is just one normative reference, RFC2119, which is not even
used (remove!).  This document relies so heavily on other L2/3VPN
documents that going forward without making them normative seems like
a bad approach for two reasons: reading the framework/reqs documents
seem to be necessary for understanding this document, and because if
the those documents haven't been approved yet, the contents might
still change.

Editorial issues:

 - abstract, introduction and section 2 in particular have language
which will no longer be valid 5 years from now when this is an RFC.
Maybe the wording needs to be tuned a bit to be more future-proof?
This also happens throughout the document.

 - should section 3.1 on IPLS be tuned a bit to state IPv6 explicitly?
(This was updated in the l2vpn documents recently.)

 - would it make sense to subsectionize 3 so that you'd first have the
"current terminology", and then a separate "legacy terminology" (such
as (TLS, VPSN, etc.etc.) -- this might make it clearer? (or just move
the legacy terms under the last 3.x subsection as their own 3.x.y
subsections).  Some wording should probably be inserted in 5.4 as
well.

Nits:
 - spell out PPVPN in the title
 - in section 2, I-D.ietf-l3vpn-framework is listed twice.
 - in section 5.1.1.2, s/CE-bS/CE-S/ ?

Typo in the Security Considerations:

"This is a terminology document and as such don't have direct security implications."

s/don't/doesn't/
or something else like "there are no direct security implications".

I was expecting to see relevant security terminology listed, and in particular terms used to distinguish VPNs with cryptographic traffic authentication and/or separation.

In 3.3,
 An L3VPN is a solution that interconnects several sets of hosts and
   routers and allows them to communicate based on L3 addresses, see
   [I-D.ietf-l3vpn-framework].

"solution" makes it sounds like we have hosts dissolved into a L3vpn solvent...
"An L3VPN interconnects hosts and routers based on Layer 3 addresses,
see[]"?

In 3.6, the document confuses the purpose of a vlan with the mechanism used
to create one:

  A VLAN is a way of separating traffic on a LAN, e.g., between
   different departments within a company.  This acronym is not defined
   by former PPVPN working group, but is defined by IEEE 802.1Q.  The
   VLANID is used to mark an Ethernet frame with a tag to create user
   groups on a LAN.

   "Ther term VLAN was specified by IEEE 802.1Q; it defined a method to differentiate
     traffic on a LAN by tagging the Ethernet frames.  By extension, VLAN is used to mean
     the traffic separated by Ethernet frame tagging or similar mechanisms."

In 3.11:


   A Virtual Private Wire Service (VPWS) is a point-to-point circuit
   (link) connecting two Customer Edge devices.  The CE in the customer
   network is connected to a PE in the provider network via an
   Attachment Circuit (see 6.1); the Attachment Circuit is either a
   physical or a logical circuit.

Should the first sentence also note that the point-to-point circuit
at issue may be a logical one?  Otherwise it looks like a not-so-virtual
Private Wire.

In 5:

 The building
   blocks are often used in day-to-day talk treated as if it were
   physical boxes, common for all services.

"treated' seems unnecessary, and there is a number disagreement
between the noun (blocks) and the pronoun (it).

In 6.4  Flooding


   Flooding is a function related to L2 and L3 services; when a PE
   receives a frame with an unknown destination MAC-address, that frame
   is send out over (flooded) every other interface.

So the L3 service uses MAC addresses?