Packet Pseudowire Encapsulation over an MPLS PSN
draft-ietf-pwe3-packet-pw-04

1. In the Abstract s/is the case/in the case/

2. In Section 6 - VLANs, 802.1p and 802.1Q are not Ethernet but bridging fucntions

So I suggest the following changes: 

in the title s/Ethernet/Ethernet and IEEE 802.1/

and: 

OLD: 

The use and applicability of Ethernet VLANs, 802.1p, and 802.1Q
   between PEs is not supported.


NEW: 

The use and applicability of VLANs, IEEE 802.1p, and IEEE 802.1Q 
   between PEs is not supported.

Maybe adding 'tagging' after 802.1Q would help if this is the intent.

Sometimes I feel like people do fun things with 2119 language entirely for my entertainment when it's a document outside of my area. :-)

Seriously, these are all simply comments that I think will improve the comprehensibility of the document. I hope they help.

Section 1:

   Where the client equipment is connected to the server equipment via a
   physical interface, the same data-link type MUST be used to attach
   the clients to the Provider Edge equipments (PE)s, and a pseudowire
   (PW) of the same type as the data-link MUST be used [RFC3985].

Something is odd here. RFC3985 is Informational and is not a normative reference, and it doesn't include any MUSTs, so those requirements can't be coming from 3985 per se. And I suspect they are not new requirements in this document at all. Do you actually mean the following?

   The architecture in [RFC3985] says that, where the client equipment
   is connected to the server equipment via a physical interface, the
   same data-link type will be used to attach the clients to the Provider
   Edge (PE) equipment, and a pseudowire (PW) of the same type as
   the data-link will be used.

Also in Section 1:

   Non-normative Appendix Appendix A provides information...

This verbal tic of inserting the words "non-normative" I find completely silly. It is absolutely clear from the contents of the appendix that it is non-normative, and we're heading down the path where sections will be titled, "Non-normative Table of Contents" and "Non-normative Acknowledgements". Please remove those words.

Section 5:

   The PEs MAY use a local Ethernet address for the Ethernet header used
   to encapsulate the client network layer packet.  Alternatively the
   PEs may use the following procedure.

I found the above confusing. The first "procedure" after this is an IANA procedure, and the "may" there looks like it should be a "MAY". Perhaps instead:

   The PEs MAY use a local Ethernet address for the Ethernet header used
   to encapsulate the client network layer packet, or MAY use one of the
   special Ethernet addresses "PacketPWEthA" or "PacketPWEthB" as
   described below.

Also in section 5:

   IANA are requested to allocate two unicast Ethernet addresses
   [RFC5342] to this protocol (PacketPWEthA and PacketPWEthB).
   PacketPWEthA is the value lower Ethernet address and PacketPWEthB is
   the higher value Ethernet address.  Where [RFC4447] signalling is
   used to set up the PW, the LDP peers compare IP addresses and with
   the PE with the higher IP address uses PacketPWEthA, whilst the LDP
   peer with the lower IP address uses PacketPWEthB.

Very awkwardly worded and confusing to me. Instead maybe:

   IANA is requested to allocate [ed note: RFC Editor will change to
   "has allocated"] two unicast Ethernet addresses [RFC5342] for use
   with this protocol, referred to as "PacketPWEthA" and
   "PacketPWEthB". Where [RFC4447] signalling is used to set up the PW,
   the LDP peers numerically compare their IP addresses. The LDP PE
   with the higher value IP address will use PacketPWEthA, whilst the
   LDP peer with the lower value IP address uses PacketPWEthB.

Also in section 5:

   Not withstanding the fact that this PW represents a point-to-point
   connection, some client layer protocols require the use of a
   destination multicast address in the Ethernet encapsulation.  This
   mode of operation MUST be supported.

The passive voice in the last sentence is problematic. Do you mean, "Peers MUST be prepared to handle a destination mulitcast address in the Ethernet encapsulation"?

Section 6:

   Thus, for example, the Ethernet OAM is NOT REQUIRED.

"NOT REQUIRED" is not a 2119 term. I think you might mean "Thus, for example, a server LSR MAY choose not to use Ethernet OAM". Or you might simply mean "not required".

Appendix A:

   This appendix is non-normative.

Please strike.