I agree with the first part of Magnus' comment. However, since he
already has a "discuss" on this, and it seems like a simple matter
to resolve using an RFC editor's note (assuming that the authors do
not object), I figured that I could register a "no objection".

Section 2., para. 2:

>    The following figure describes the reference models which are derived
>    from [ARCH] to support the HDLC/PPP PW emulated services. The reader
>    is also asummmed to be familiar with the content of the [ARCH]
>    Document.

        Then [ARCH] should be normative.

Section 3., para. 2:

>    The applicability statements in [FRAME] also apply to the Frame Relay
>    port mode PW described in this document.

        Then [FRAME] should probably be normative.

Section 3., para. 5:

>      - A Frame Relay Port mode PW, or HDLC PW, does not process any
>        packet relay status messages or alarms as described in [Q922]
>        [Q933]

        [Q922] and [Q933] are not referenced.

Section 4.1., para. 12:

>    The next 2 bits are reserved for future use, and MUST be ignored.

        See Magnus' DISCUSS on this.

Section 4.1., para. 13:

>    The next 16 bits provide a sequence number that can be used to
>    guarantee ordered packet delivery. The processing of the sequence
>    number field is OPTIONAL.

        What if more packets can be in flight (long, fat pipe)?
        "Processing" is vague, what does it involve? Cite [CW].

>    The sequence number space is a 16 bit, unsigned circular space. The
>    sequence number value 0 is used to indicate an unsequenced packet.

        If it is circular, it wraps to zero. I think [CW] says that zero
        needs to be skipped for this reason - reference?

Section 4.1.1., para. 1:

>    The procedures described in section 4 of [CW] MUST be followed to
>    process the sequence number field.

        Odd to have this sentence in its own section. Previous paragraphs
        should have already referred to [CW] for details of sequence number
        processing.

Section 4.2., para. 1:

>    The network MUST be configured with an MTU that is sufficient to
>    transport the largest encapsulation packets. 

        Not sure if we can have RFC2119 text about a configuration requirement
        on the underlying network.

Section 7., para. 1:

>    As explained in [ARCH], the PSN carrying the PW may be subject to
>    congestion, with congestion characteristics depending on PSN type,
>    network architecture, configuration, and loading. During congestion
>    the PSN may exhibit packet loss that will impact the service carried
>    by the PPP/HLDC PW.  In addition, since PPP/HDLC PWs carry an
>    unspecified type of services across the PSN, they cannot behave in a
>    TCP-friendly manner prescribed by [RFC2914]. In the presence of
>    services that reduce transmission rate, PPP/HDLC PWs will thus
>    consume more than their fair share and SHOULD be halted.

        In addition, if a PW carries multiple TCP-friendly connections,
        the aggregate may still not necessarily be TCP-friendly.

The technical summary appears to be missing a verb:

 This draft describes how a Point to Point Protocol (PPP), or High-
 Level Data Link Control (HDLC) Protocol Data Units over an 
 MPLS network without terminating the PPP/HDLC protocol.

  In many places: s/port to port transport/port-to-port transport/

  A space needs to be inserted at the beginning of Figure 5b to align
  the arrow at the top of the figure.

  Section 9: s/in [ARCH][CONTROL]/in [ARCH] and [CONTROL]/