• Revised I-D Needed - Issue raised by WG
  • Awaiting Expert Review/Resolution of Issues Raised
  • Awaiting External Review/Resolution of Issues Raised
  • Awaiting Merge with Other Document
  • Author or Editor Needed
  • Waiting for Referenced Document
  • Waiting for Referencing Document
  • Revised I-D Needed - Issue raised by WGLC
  • Revised I-D Needed - Issue raised by AD
  • Revised I-D Needed - Issue raised by IESG
  • Doc Shepherd Follow-up Underway
  • Other - see Comment Log

IETF :: v6ops

Current state: WG Document

Viewing the last 20 entries. Show full log.

2012-11-02 05:07 Amy Vezza

State changed to RFC Ed Queue from Approved-announcement sent

2012-11-01 10:58 (System)

IANA Action state changed to No IC

2012-11-01 08:23 Amy Vezza

State changed to Approved-announcement sent from Approved-announcement to be sent

2012-11-01 08:23 Amy Vezza

IESG has approved the document

2012-11-01 08:23 Amy Vezza

Closed "Approve" ballot

2012-11-01 08:20 Amy Vezza

Ballot approval text was generated

2012-11-01 08:10 Amy Vezza

Ballot writeup was changed

2012-11-01 06:30 Ron Bonica

State changed to Approved-announcement to be sent from IESG Evaluation::AD Followup

2012-10-30 20:00 Ralph Droms

[Ballot comment]
I've cleared my Discuss; thanks for addressing all of my Discuss points.

1. (cleared)

2. (cleared)

3. (cleared)

4. (cleared)

5. (cleared)

2012-10-30 20:00 Ralph Droms

[Ballot Position Update] Position for Ralph Droms has been changed to No Objection from Discuss

2012-10-30 12:54 Cindy Morgan

New revision available

2012-10-29 10:47 Sean Turner

[Ballot comment]
Apologies for the delay.

2012-10-29 10:47 Sean Turner

[Ballot Position Update] Position for Sean Turner has been changed to No Objection from Discuss

2012-10-23 10:00 Ralph Droms

[Ballot comment]
1. (cleared)

2. (cleared)

3. (cleared)

4. (cleared)

5. (cleared)

2012-10-23 10:00 Ralph Droms

Ballot comment text updated for Ralph Droms

2012-10-19 07:21 Ralph Droms

[Ballot discuss]
1. (resolved)

2. (resolved)

3. Is it the intention of this document to preclude the use of DHCPv6
PD if neither the M or O bit are set in a received router
advertisement?

(2012-10-19) More specifically, referencing WPD-4, what is the
behavior of the CE router in the case where neither bit is set in a
received RA?

4. I know I read and approved WPD-5 in RFC 6204. I think I know the
intent of WPD-5, but now I'm not sure that the words actually match
the intent. I'd like to discuss the intent to make sure I have it
right, and then discuss the specific words to agree that they
accurately convey that intent.

(2012-10-19) Now I understand the intent: black-hole packets that have
a destination address in the delegated prefix but are not in any
prefix assigned out of the delegated prefix by the CE router. Can you
rewrite WPD-5 to be more clear? Perhaps:

WPD-5: Any packet received by the CE router with a destination
address in the prefix(es) delegated to the CE router but
not in the set of prefixes assigned by the CE router to the
LAN must be dropped. In other words, the next hop for the
prefix(es) delegated to the CE router should be the null
destination. This is necessary to prevent forwarding loops
when some addresses covered by the aggregate are not
reachable [RFC4632].

(a) The IPv6 CE router SHOULD send an ICMPv6 Destination
Unreachable message in accordance with Section 3.1 of
[RFC4443] back to the source of the packet, if the
packet is to be dropped due to this rule.

5. (cleared)

6. How is the use of 6rd and DS-lite controlled -specifically enabled
and disabled?

(2012-10-19) For example, does requirement 6RD-1 imply that the CE
router is assumed to run 6rd with no mechanism for disabling it?

2012-10-19 07:21 Ralph Droms

[Ballot comment]
1. (cleared)

2. (cleared)

3. (cleared)

4. There are several requirements in the text that are not explicitly
labeled as such; e.g., from section 4.4.2:

The IPv6 CE Router SHOULD implement DS-Lite functionality.

Is there a reason for the inconsistency?

(2012-10-19) Specifically, why is this requirement (and other
sentences using RFC 2119 language but not in a labeled requirement)
not a labeled requirement?

5. (cleared)

2012-10-19 07:21 Ralph Droms

Ballot comment and discuss text updated for Ralph Droms

2012-10-10 19:31 Pete Resnick

[Ballot comment]
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.

2012-10-10 19:31 Pete Resnick

[Ballot Position Update] Position for Pete Resnick has been changed to Abstain from Discuss

Viewing the last 20 entries. Show full log.