Basic Requirements for IPv6 Customer Edge Routers
draft-ietf-v6ops-6204bis-12

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

(Ron Bonica) Yes

(Stewart Bryant) No Objection

Comment (2012-08-11 for -09)
Brian raises a number of important points.

(Ralph Droms) (was Discuss) No Objection

Comment (2012-10-30)
I've cleared my Discuss; thanks for addressing all of my Discuss points.

1. (cleared)

2. (cleared)

3. (cleared)

4. (cleared)

5. (cleared)

(Wesley Eddy) No Objection

(Adrian Farrel) No Objection

Stephen Farrell No Objection

Comment (2012-08-13 for -09)
Three near-discusses to which I'd like to see responses,
but I'm going no-objection taking the "perfect is enemy of
the good" approach as requested in the writeup, which I
think is a reasonable one for this document.

- W-6: Why is *use* of PCP a SHOULD? The doucment says the
CE device SHOULD use PCP to discover a server but then says
that it takes no position on whether PCP is enabled by
default. Maybe just saying "When PCP is in use the PCP
client SHOULD...<discover stuff>" would be better?

- Don't you need to note anything about the THIRD_PARTY PCP
feature here? I would guess it MUST NOT be supported for
the PCP client on the WAN i/f of this kind of device.  I
can't recall if PCP base already says that or not, but I
suspect its worth adding here to the security
considerations here just in case.

- Please consider the secdir review [1] question as to
whether filtering of decapsulated packets is better as a
MUST, and if it remains a SHOULD, then say what's the
exception.

   [1] http://www.ietf.org/mail-archive/web/secdir/current/msg03446.html

Brian Haberman (was Discuss) No Objection

(Russ Housley) No Objection

Barry Leiba No Objection

(Robert Sparks) No Objection

Martin Stiemerling No Objection

(spt) (was Discuss) No Objection

Comment (2012-10-29 for -11)
Apologies for the delay.

(Pete Resnick) (was Discuss) Abstain

Comment (2012-10-10 for -11)
I have moved to "Abstain" on this document since I really don't think that further discussion is going to be fruitful. If the WG is willing to make the following changes, great. If not, I'm not really willing to argue about it; this is, after all, an update to a document that does almost the same thing. I simply disagree with claiming that the keywords "are to be interpreted as described in RFC 2119"; they are not being used as 2119 intended, but rather to be industry cudgels as part of protocol policing. So, here are my two suggested changes:

Change the first paragraph of section 1 to:

   This document defines basic IPv6 features for a residential or small-
   office router, referred to as an IPv6 CE router, in order to
   establish an industry baseline for features to be implemented on such
   a router.

   These routers typically also support IPv4.

And in section 1.1:

   Take careful note: Unlike other IETF documents, the key words "MUST",
   "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT",
   "RECOMMENDED", "MAY", and "OPTIONAL" in this document are not used as
   described in RFC 2119 [RFC2119]. This document uses these keyword not
   strictly for the purpose of interoperability, but rather for the
   purpose of establishing industry-common baseline functionality.  As
   such, the document points to several other specifications (preferable
   in RFC or stable form) to provide additional guidance to implementers
   regarding any protocol implementation required to produce a
   successful CPE router that interoperates successfully with a
   particular subset of currently deploying and planned common IPv6
   access networks.

3.1: I think it should be made clearer (either by separating it out or by signposting it a bit better) that this section is more about the current state of deployment than it is about the desired architecture. It caused me a bit of confusion, thinking that this was talking about what was desired, not simply what is.