Negotiation for IPv6 Datagram Compression Using IPv6 Control Protocol
RFC 5172

Received changes through RFC Editor sync (changed abstract to 'The Point-to-Point Protocol (PPP) provides a standard method of encapsulating network-layer protocol information over point-to-point links. PPP also defines an extensible Link Control Protocol, and proposes a family of Network Control Protocols (NCPs) for establishing and configuring different network-layer protocols.

The IPv6 Control Protocol (IPV6CP), which is an NCP for a PPP link, allows for the negotiation of desirable parameters for an IPv6 interface over PPP.

This document defines the IPv6 datagram compression option that can be negotiated by a node on the link through the IPV6CP. [STANDARDS-TRACK]')

[Ballot discuss]
I am missing in this document any information about the observability of the IPv6 compression capabilities and of the status of the negotiation process for a compression algorithm on a link. I believe that from an operational point of view the information about the advertised capability and the negociated algorithm on the link wshould be made available by management objects which could be visible for example via an extension of the Interfaces MIB. If such objects are defined some other place please include a reference.

[Ballot discuss]
This is a discuss discuss, and I will clear on the call.

The RFC Editor Notes indicate this obsoletes RFC 2472, but it does not seem to cover
all the same topics.  Specifically, IPv6CP is specified in 2472, and seems to be necessary
for this specification.  Shouldn't this be considered an update to 2472?

[Ballot discuss]
This is a discuss discuss, and I will clear on the call.

The RFC Editor Notes indicate this obsoletes RFC 2472, but it does not seem to cover
all the same topics.  Why isn't this considered an update to 2472?

IANA Last Call comments:

We are not clear on what this document is asking IANA to do. Is this
document trying to register a value in
http://www.iana.org/assignments/ipv6-parameters section 5.b.,
Options Types? If so, the suggested value of 2 seems to conflict
with value C2 (Jumbogram). Also, if the document is asking for a
registration in that section, it needs to specify what the act, chg,
and rest flags are.

[Ballot comment]
The RFC editor notes are a bit excessive for this document and made it
harder to review.

Should the IANA considerations add/replace this new RFC number to the
reference list in the IANA registration for the option?  Perhaps:

  2      IPv6-Compression-Protocol                  [RFC2472]
would become:
  2      IPv6-Compression-Protocol                  [RFC2472],[RFCXXXX]
or
  2      IPv6-Compression-Protocol                  [RFCXXXX]