Basic Requirements for IPv6 Customer Edge Routers
draft-ietf-v6ops-6204bis-12
Yes
(Ron Bonica)
No Objection
(Adrian Farrel)
(Barry Leiba)
(Brian Haberman)
(Martin Stiemerling)
(Robert Sparks)
(Russ Housley)
(Wesley Eddy)
Abstain
Note: This ballot was opened for revision 09 and is now closed.
Ron Bonica Former IESG member
Yes
Yes
(for -09)
Unknown
Adrian Farrel Former IESG member
No Objection
No Objection
(for -09)
Unknown
Barry Leiba Former IESG member
No Objection
No Objection
(for -09)
Unknown
Brian Haberman Former IESG member
(was Discuss)
No Objection
No Objection
(2012-09-25 for -11)
Unknown
Martin Stiemerling Former IESG member
No Objection
No Objection
(for -09)
Unknown
Ralph Droms Former IESG member
(was Discuss)
No Objection
No Objection
(2012-10-30)
Unknown
I've cleared my Discuss; thanks for addressing all of my Discuss points. 1. (cleared) 2. (cleared) 3. (cleared) 4. (cleared) 5. (cleared)
Robert Sparks Former IESG member
No Objection
No Objection
(for -09)
Unknown
Russ Housley Former IESG member
No Objection
No Objection
(for -09)
Unknown
Sean Turner Former IESG member
(was Discuss)
No Objection
No Objection
(2012-10-29 for -11)
Unknown
Apologies for the delay.
Stephen Farrell Former IESG member
No Objection
No Objection
(2012-08-13 for -09)
Unknown
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
Stewart Bryant Former IESG member
No Objection
No Objection
(2012-08-11 for -09)
Unknown
Brian raises a number of important points.
Wesley Eddy Former IESG member
No Objection
No Objection
(for -09)
Unknown
Pete Resnick Former IESG member
(was Discuss)
Abstain
Abstain
(2012-10-10 for -11)
Unknown
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.