This is non-blocking because I am not sure about the resolution. Hopefully discussion with the authors and the responsible AD will help.

I was puzzled to see the following paragraph in Section 7.2.2:

> The recovered clock MUST comply with the jitter and wander requirements applicable to the type of attachment circuit, specified in:
> 
> [G.825] and [G.823] for SDH
> 
> [GR253] for SONET
> 
> [G.8261] for synchronous Ethernet
> 
> [G.8251] for OTN

and at the same time all of these references are informative. I understand that depending on which of these you are considering, the others might be unnecessary to read, however with the requirement text I still feel those would have made more sense as normative references.

Note that a similar comment could be made for the following text in Section 3.2, motivating the need for [G.8262] and [G.8261.1] being normative:

> While using external timing inputs (aka BITS [ATIS-0900105.09.2013]) or synchronous Ethernet as defined in [G.8261] the characteristics and limits defined in [G.8262] have to be considered.
>
> While relying on precision time protocol (PTP) as defined in [G.8265.1], the network limits defined in [G.8261.1] have to be considered.

Thank you to Joel Halpern for the GENART review.


** Section 4.5

The PSN-bound NSP function MUST terminate the FEC and replace the
   OTUk overhead in row 1 columns 8-14 with all-0s fixed stuff which
   results in a extended ODUk frame as illustrated in Figure 3.

What is ‘all 0s fixed stuff’?

** Section 7.2

   While the PLOS defect is declared the CE-bound NSP function SHOULD
   inject the appropriate native downstream fault indication signal.
   Also the PSN-bound IWF SHOULD set the R bit in the PLE control word
   of every packet transmitted.

…

   Whenever the R bit is set in the PLE control word of a received PLE
   packet the PLE performance monitoring statistics SHOULD get updated.

In what cases would the behavior described above not be followed? Why are these a SHOULD and not a MUST?

** Section 7.4

… and SHOULD be provided by a YANG model.  The YANG model
   specification is out of scope for this document.

Why is this sections prescribing normative behavior for something that is out of scope?

** Section 9

    Control
   plane mechanisms for signaling the expected SSRC value are described
   in [I-D.draft-schmutzer-bess-bitstream-vpws-signalling] and
   [I-D.draft-schmutzer-pals-ple-signaling].

Are the signaling mechanisms described in these drafts mandatory to follow? 

** Section 11

   The authors would like to thank all reviewers, contributors and the
   working group for reviewing this document and providing useful
   comments and suggestions

(Editorial) Consider actually naming the parties who provided reviews or feedback that contributed to the document.

Apart from my discuss point - I had hard time to understand the following section 

   The RTP header is purely a formal reuse and RTP mechanisms, such as header extensions, contributing source (CSRC) list, padding, RTP Control Protocol (RTCP), RTP header compression, Secure Realtime Transport Protocol (SRTP), etc., are not applicable to PLE VPWS.

Specially, what does "purely a formal reuse" mean? My "formal" reuse will mean a proper RTP endpoint with RTCP.

Also please explain the need ofr PT in PLE header.