Draft:  draft-ietf-ipv6-over-ppp-v2-02.txt
Reviewer: Spencer Dawkins [spencer@mcsr-labs.org]
Review Date: Friday 12/16/2005 2:08 PM CST
LC Date: 12/22/2005

Summary: This document is almost ready for publication, with a few nits
below, and one question.

Question: The ID-Tracker shows this document as balloted for Draft Standard.

>From RFC 2026:

   The requirement for at least two independent and interoperable
   implementations applies to all of the options and features of the
   specification.  In cases in which one or more options or features
   have not been demonstrated in at least two interoperable
   implementations, the specification may advance to the Draft Standard
   level only if those options or features are removed.

>From the draft:

         No IPv6-Compression-Protocol field values are currently
         assigned. Specific assignments will be made in documents that
         define specific compression algorithms.

... so you KNOW I've got to ask if there are two demonstrated-interoperable
implementations of this option-to-carry-no-defined-field-values. There may
be, and that's fine.

I also note that two authors (Dmitri and Ed) have no contact information
provided at all, which will be inconvenient at AUTH-48.

Good luck with your Last Call!

Thanks,

Spencer

Nits:

Abstract

      This document is an update to RFC 2472 and, hence, obsoletes it.

May confuse the reader (since UPDATES and OBSOLETES are two different 
things). Suggest "This document obsoletes RFC 2472"?

2. Sending IPv6 Datagrams

      Before any IPv6 packets may be communicated, PPP MUST reach the
      Network-Layer Protocol phase, and the IPv6 Control Protocol MUST
      reach the Opened state.

Section 3 is very clear about what to do with IPV6VP packets received before
Network-Layer Protocol phase ("silently discard them") - is it worth
providing more detail for unexpected IPv6 packets in Section 2?

4.1 Interface-Identifier

      Description

      This Configuration Option provides a way to negotiate an unique
      64-bit interface identifier to be used for the address
      autoconfiguration [3] at the local end of the link (see
      section 5).  A Configure-Request MUST contain exactly one
      instance of the Interface-Identifier option [1].  The interface
      identifier MUST be unique within the PPP link; i.e. upon
      completion of the negotiation different Interface-Identifier
      values are to be selected for the ends of the PPP link.  The
      interface identifier MAY also be unique over a broader scope.

I think this is a MAY-for-emphasis, not a 2119 MAY ("Oh, no, my interface 
identifer is unique over too broad a scope - is that OK?"). Might not even 
need emphasis.

      A new Configure-Request SHOULD NOT be sent to the peer until
      normal processing would cause it to be sent (that is, until a
      Configure-Nak is received or the Restart timer runs out).

Can "the Restart timer" be qualified in any way, or a reference provided?

4.2 IPv6-Compression-Protocol

      IPv6 compression negotiated with this option is specific to IPv6
      datagrams and is not to be confused with compression resulting
      from negotiations via Compression Control Protocol (CCP), which
      potentially effect all datagrams.

s/effect/affect/

5. Stateless Autoconfiguration and Link-Local Addresses

      As long as the Interface-Identifier is negotiated in the IPV6CP
      phase of the PPP connection setup, it is redundant to perform
      duplicate address detection (DAD) as a part of the IPv6 Stateless
      Address Autoconfiguration protocol [3] on the IPv6 link-local
      address generated by the PPP peer.  It MAY also be redundant to
      perform DAD on any global unicast addresses configured (using an
      Interface-Identifier that is either negotiated during IPV6CP or
      generated, for instance, as per [9]) for the interface as part of
      the IPv6 Stateless Address Autoconfiguration protocol [3] provided
      that the following two conditions are met:

I don't think "MAY also be redundant to perform DAD" is a 2119 MAY. I
wouldn't capitalize it at all.

6. Security Considerations

      The information learned via the NCP protocol SHOULD not be trusted
      for making security relevant decisions.

If there are any particularly tempting bad decisions about trust based on
NCP information, it might be nice to give an example or two.