Basic Requirements for IPv6 Customer Edge Routers
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
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  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.  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
(Sean Turner) (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.