IP Version 6 over PPP
RFC 5072

Note: This ballot was opened for revision 03 and is now closed.

(Brian Carpenter) Discuss

Discuss (2006-11-16 for -** No value found for 'p.get_dochistory.rev' **)
A specific point on interop reports (i.e. add this to Cullen's DISCUSS):

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

Are there two demonstrated-interoperable implementations of this option-to-carry-no-defined-field-values?

(from Gen-ART review by Spencer Dawkins)
Comment (2006-11-16 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
(From Gen-ART review by Spencer Dawkins)

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.

(Jari Arkko) Yes

(Mark Townsley) Yes

(Ron Bonica) No Objection

(Ross Callon) No Objection

(Lisa Dusseault) No Objection

(Lars Eggert) No Objection

Comment (2007-05-24)
No email
send info
Section 9.1, paragraph 4:
>    [4]   IANA, "Assigned Numbers," http://www.iana.org/numbers.html

  Can't be a normative reference.

Section 9.1, paragraph 5:
>    [5]   IEEE, "Guidelines for 64-bit Global Identifier (EUI-64)
>          Registration Authority", April 2004.

  Need to cite the IEEE standard number.

(Bill Fenner) (was Discuss) No Objection

Comment (2006-11-16)
No email
send info
We have basically no standards for implementation reports.  We leave it up to the submitters to submit something, and then shoot holes in it willy nilly.  We again and again find that we need to have guidance in this area, so that:
a) people will have something to shoot for, and
b) the IESG will have something to evaluate against
since right now it depends on peoples' mood, how closely they read the implementation report (tell me truthfully, of those who looked at it, who would have looked at it if Jari hadn't brought specific attention to it?), phase of the moon, etc etc etc.

(Ted Hardie) No Objection

(Sam Hartman) No Objection

(Russ Housley) No Objection

Comment (2006-11-16 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
  Please indicate that this document obsoletes RFC 2472 to the Title
  Page header and the Introduction.

  From the SecDir Review by Steve Kent:
  > This section seems awfully minimal and should be substantially
  > improved. For example, it should start with a brief mention what
  > security services (e.g., confidentiality, integrity, access control
  > or authentication) may be appropriate for link security. The
  > security considerations section for EAP (RFC 3748) is a very good
  > model and directly relevant here. At least the threat model
  > described there should be included here, if only by reference.
  > This document also should cite specific RFCs that define the
  > security mechanisms alluded to in the first sentence. For example,
  > are the authors referring only to mechanisms that are PPP-specific
  > (e.g., RFC 1934, 3748, et al.) or do they also intend to refer to
  > mechanisms like IPsec that apply to the IPv6 packets being carried
  > by PPP? I'm guessing the former, but absent any references to any
  > RFCs here, I can only surmise.

(Cullen Jennings) (was Discuss) No Objection

(David Kessens) No Objection

(Chris Newman) No Objection

(Jon Peterson) No Objection

(Tim Polk) No Objection

(Dan Romascanu) No Objection

Comment (2006-11-14 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
I agree with Cullen's comment in his DISCUSS regarding the need of consistency with status of PPP. It does bear however only the weight of a COMMENT to me, because O believe that this is not the only such case of inconsistency between layered protocols in the IETF.

Magnus Westerlund No Objection