[Ballot comment]
I think one should consider switching the reference to RFC 3095 to that of the approved document: draft-ietf-rohc-rfc3095bis-framework

Nits:

Section 2:
compressed Real Time Protocol (cRTP)

Should be:

compressed Real-time Transport Protocol (cRTP)

Enhanced Compressed Real Time Porotocol (ECRTP)

Should be:

Enhanced Compressed Real-time Transport Protocol (ECRTP)

Section 2:
  Label Switching Router (LSR): an MPLS node which is capable of
  forwarding native L3 packets label stack an ordered set of labels

It seems another definition for "Label stack" has been sucked into this definition.

[Ballot comment]
One author response to Spencer Dawkins' Gen-ART review remains open.
This would be an improvement:

If you prefer I could replace the phrasing "These sub-options do not
occur together" with the following text: "These sub-options MUST NOT
occur together, if they do (e.g., if misconfigured) a decompressor MUST
reject this option and send an explicit error message to the compressor
[RFC3544]."

IANA Last Call Comments:

IANA understands that there are three actions required
upon approval of this document.

First, in the Pseudo Wires Name Spaces registry located at:

http://www.iana.org/assignments/pwe3-parameters

in the subregistry named MPLS Pseudowire Types Registry,
the following values will be added:

PW type Description Reference
------- ----------------------------------------------- ---------
0x001A ROHC Transport Header-compressed Packets [RFC3095]
0x001B ECRTP Transport Header-compressed Packets [RFC3545]
0x001C IPHC Transport Header-compressed Packets [RFC2507]
0x001D cRTP Transport Header-compressed Packets [RFC2508]

Second, also in the Pseudo Wires Name Spaces registry
located at:

http://www.iana.org/assignments/pwe3-parameters

in the subregistry named, Pseudowire Interface Parameters
Sub-TLV type Registry the following values will be added:

Parameter ID Length Description References
--------- --------------- ----------------------------- -----------
0x0D up to 256 bytes ROHC over MPLS configuration RFC 3241
0x0F up to 256 bytes CRTP/ECRTP/IPHC HC over MPLS RFC 3544
configuration

Finally, also in the Pseudo Wires Name Spaces registry
located at:

http://www.iana.org/assignments/pwe3-parameters

a new subregistry will be created called Header
Compression Over MPLS PW Control Word Packet Type.

Header Compression Over MPLS PW Control Word Packet Type
Registration Rules for values 11 to 15 - Expert Review

Packet
Type Description
-------- --------------------------------------------------
0 ROHC Small-CIDs
1 ROHC Large-CIDs
2 FULL_HEADER
3 COMPRESSED_TCP
4 COMPRESSED_TCP_NODELTA
5 COMPRESSED_NON_TCP
6 COMPRESSED_RTP_8
7 COMPRESSED_RTP_16
8 COMPRESSED_UDP_8
9 COMPRESSED_UDP_16
10 CONTEXT_STATE

IANA understands that these are the only IANA Actions
required for this document.

Please consider the following as an IETF LC comment that needs to be addressed

This document defines a new Control Word for PWs. Section 4:
In addition to the PW label and PSN label(s), HC over MPLS packets
  also carry a PW control word.  The control word contains both a
  packet type field and a packet length field.  The packet type field
  is needed because each HC scheme supported by this specification
  defines multiple packet types, for example "full header" packets,
And 5.3:

5.3 Encapsulation of Header Compressed Packets

  The PW control word is used to identify the packet types for IPHC
  [RFC2507], cRTP [RFC2508], and ECRTP [RFC3545], as shown in Figure 4:

                                    1
                0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
              +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
              |0 0 0 0|Pkt Typ|  Length  |Res|
              +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Figure 4 - PW Control Word

  where:

  "Packet Type" encoding:
  0: ROHC Small-CIDs
  1: ROHC Large-CIDs
  2: FULL_HEADER
  3: COMPRESSED_TCP
                  :
                  :

This is a 16-bit "Word" rather than the 32-bit length one typically considers a "Word." RFC 4385, which defines how MPLS PW Control Words are to be specified, states that an MPLS Control Word MUST follow the format in Figure 1 of said document, and SHOULD follow the format in Figure 2. The HC PW completely dismisses the SHOULD, which I suppose is acceptable, but it is also dismissing the MUST as control words clearly need to be the size of a 32-bit word based on what we see in that document.

When the WG defined the Control Word in RFC4385, it tried hard to make it possible for future PWs to include things like a "Channel Type" and such multiplexed into the PW. You will see in Figure 5 of RFC 4385 that there is a Control Word defined explicitly for carriage of an "Associated Channel" to the PW - the case it was defined for was for carrying OAM (VCCV) packets associated with a given PW. Perhaps the WG could consider using this format, though I am afraid that the large number of "Reserved" bits would give someone paranoid about header sizes heartburn.

At a minimum, this is going to require consensus from the PWE3/MPLS community to allow a 16-bit "Control Word" into the PW ranks. If approved, an explicit acknowledgment of the deviation from RFC4385 would be in order in this document (with perhaps an RFC4385-bis in the works for the MPLS/PWE3 folks as well).

- Mark

PS. It would also be *much* clearer if this document referred to the new control word it is defining as the "HC PW Control Word" rather than just "PW Control Word" - people use the latter to refer to the canonical control word in figure 2 of RFC4385

PROTO Write-up

> 1.a) Have the chairs personally reviewed this version of the ID and
> do they believe this ID is sufficiently baked to forward to
> the
> IESG for publication?

Yes.

> 1.b) Has the document had adequate review from both key WG members
> and key non-WG members? Do you have any concerns about the
> depth or breadth of the reviews that have been performed?

The document has had extensive reviewed in AVT, and follows from an
earlier requirements effort [RFC 4247]. I have no concerns.

> 1.c) Do you have concerns that the document needs more review
> from a
> particular (broader) perspective (e.g., security, operational
> complexity, someone familiar with AAA, etc.)?

I have no concerns. The document has been reviewed by the PWE3, ROHC
and MPLS working groups, in addition to AVT.

> 1.d) Do you have any specific concerns/issues with this document
> that
> you believe the ADs and/or IESG should be aware of? For
> example, perhaps you are uncomfortable with certain parts
> of the
> document, or have concerns whether there really is a need for
> it, etc. If your issues have been discussed in the WG and the
> WG has indicated it wishes to advance the document anyway,
> note
> if you continue to have concerns.

I have no technical concerns.

> 1.e) How solid is the WG consensus behind this document? Does it
> represent the strong concurrence of a few individuals, with
> others being silent, or does the WG as a whole understand and
> agree with it?

There is reasonable consensus.

> 1.f) Has anyone threatened an appeal or otherwise indicated extreme
> discontent? If so, please summarise what are they upset
> about.

No.

> 1.g) Have the chairs verified that the document adheres to _all_ of
> the ID nits? (see http://www.ietf.org/ID-Checklist.html).

Yes, although idnits 1.103 erroneously gives a missing reference
warning (which has been reported as a bug).

> 1.h) Does the document a) split references into normative/
> informative, and b) are there normative references to IDs,
> where
> the IDs are not also ready for advancement or are otherwise in
> an unclear state? (Note: the RFC editor will not publish an
> RFC
> with normative references to IDs, it will delay publication
> until all such IDs are also ready for publication as RFCs.)

References have been split. There is an incorrect normative reference
to the draft on "PWE3 Control Word for use over an MPLS PSN", which
should refer to RFC 4385.

> 1.i) For Standards Track and BCP documents, the IESG approval
> announcement includes a writeup section with the following
> sections:
>
>
> * Technical Summary

This specification defines how to use Multi-Protocol Label Switching
(MPLS) to route Header-Compressed (HC) packets over an MPLS label
switched path. HC can significantly reduce packet-header overhead
and, in combination with MPLS, can also increases bandwidth
efficiency and processing scalability in terms of the maximum number
of simultaneous compressed flows that use HC at each router). Here
we define how MPLS pseudowires are used to transport the HC context
and control messages between the ingress and egress MPLS label
switching routers. This is defined for a specific set of
existing HC
mechanisms that might be used, for example, to support voice over
IP.
This specification also describes extension mechanisms to allow
support for future, as yet to be defined, HC protocols. In this
specification, each HC protocol operates independently over a single
pseudowire instance very much as it would over a single
point-to-point link.

> * Working Group Summary

This draft has been in development for several years, with the
initial proposal being refined significantly in the course of the
discussion, to provide a solid framework for header compression over
MPLS pseudo-wires.

> * Protocol Quality

This draft is a product of the AVT working group, with input from
MPLS, ROHC and PWE3. Extensive working group last call comments were
provided by Kristofer Sandlund and Eric Gray. PROTO write-up by Colin
Perkins.