datatracker.ietf.org
Sign in
Version 5.3.0, 2014-04-12
Report a bug

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

Yes
Abstain
(was Discuss)

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

Summary: Needs a YES.

Pete Resnick

Comment (2012-10-10)

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.

Stephen Farrell

Comment (2012-08-13)

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

[Ralph Droms]

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)

[Sean Turner]

Comment (2012-10-29)

Apologies for the delay.

[Stewart Bryant]

Comment (2012-08-11)

Brian raises a number of important points.