Basic Requirements for IPv6 Customer Edge Routers
draft-ietf-v6ops-ipv6-cpe-router-09

[Ballot comment]
For IPv6 multicast traffic the IPv6 CE router may act as an MLD proxy
  [RFC4605] and may support a dynamic multicast routing protocol.

>> MLD not expanded on first use

> (1.a) Who is the Document Shepherd for this document? Has the
> Document Shepherd personally reviewed this version of the
> document and, in particular, does he or she believe this
> version is ready for forwarding to the IESG for publication?

Fred Baker. Yes, I believe that it is ready for publication.

> (1.b) Has the document had adequate review both from key WG members
> and from key non-WG members? Does the Document Shepherd have
> any concerns about the depth or breadth of the reviews that
> have been performed?

I believe so. It was originally developed by two engineers from Cisco working with Cable Labs, and was divided into two parts - that which is generally agreed and that which needs RFC development to support. This is the first part. The author list derives from Broadband Forum, Cable Labs, and IETF participants, and the Acknowledgements section notes 31 people that directly contributed either comments or text. It has passed working group last call after an active discussion.

> (1.c) Does the Document Shepherd have concerns that the document
> needs more review from a particular or broader perspective,
> e.g., security, operational complexity, someone familiar with
> AAA, internationalization or XML?

There would be no harm in a Security or operational review. It does not contain or specify anything in a formal grammar; it does make recommendations regarding the IPv6 CPE router feature set.

> (1.d) Does the Document Shepherd have any specific concerns or
> issues with this document that the Responsible Area Director
> and/or the IESG should be aware of? For example, perhaps he
> or she is uncomfortable with certain parts of the document, or
> has concerns whether there really is a need for it. In any
> event, if the WG has discussed those issues and has indicated
> that it still wishes to advance the document, detail those
> concerns here. Has an IPR disclosure related to this document
> been filed? If so, please include a reference to the
> disclosure and summarize the WG discussion and conclusion on
> this issue.

I have no such concerns.

> (1.e) How solid is the WG consensus behind this document? Does it
> represent the strong concurrence of a few individuals, with
> others being silent, or does the WG as a whole understand and
> agree with it?

In the IPv6 Operations Working Group, 31 people is a large subset of the active participants. I believe it reflects a strong working group consensus.

> (1.f) Has anyone threatened an appeal or otherwise indicated extreme
> discontent? If so, please summarise the areas of conflict in
> separate email messages to the Responsible Area Director. (It
> should be in a separate email because this questionnaire is
> entered into the ID Tracker.)

No

> (1.g) Has the Document Shepherd personally verified that the
> document satisfies all ID nits? (See the
> Internet-Drafts Checklist
>
> and
> http://tools.ietf.org/tools/idnits/
> ). Boilerplate checks are
> not enough; this check needs to be thorough. Has the document
> met all formal review criteria it needs to, such as the MIB
> Doctor, media type and URI type reviews?

As noted, it contains no formal grammar. The document fails the idnits check at http://tools.ietf.org/tools/idnits/idnits.pyht (version 2.12.04), due to complaints about a missing RFC 2119 reference. That said, the document both references RFC 2119 and contains, in section 1.1, the stipulated boilerplate. idnits is wrong.

> (1.h) Has the document split its references into normative and
> informative? Are there normative references to documents that
> are not ready for advancement or are otherwise in an unclear
> state? If such normative references exist, what is the
> strategy for their completion? Are there normative references
> that are downward references, as described in [RFC3967]? If
> so, list these downward references to support the Area
> Director in the Last Call procedure for them [RFC3967].

Yes. Some of the normative references are to internet drafts, which means that the document will have to wait in queue with them for publication.

> (1.i) Has the Document Shepherd verified that the document IANA
> consideration section exists and is consistent with the body
> of the document? If the document specifies protocol
> extensions, are reservations requested in appropriate IANA
> registries? Are the IANA registries clearly identified? If
> the document creates a new registry, does it define the
> proposed initial contents of the registry and an allocation
> procedure for future registrations? Does it suggest a
> reasonable name for the new registry? See [RFC5226]. If the
> document describes an Expert Review process has Shepherd
> conferred with the Responsible Area Director so that the IESG
> can appoint the needed Expert during the IESG Evaluation?

This memo includes no request to IANA, and says as much in section 7.

> (1.j) Has the Document Shepherd verified that sections of the
> document that are written in a formal language, such as XML
> code, BNF rules, MIB definitions, etc., validate correctly in
> an automated checker?

There is no formal language specification in the document.

> (1.k) The IESG approval announcement includes a Document
> Announcement Write-Up. Please provide such a Document
> Announcement Write-Up? Recent examples can be found in the
> "Action" announcements for approved documents. The approval
> announcement contains the following sections:
>
> Technical Summary

This document specifies requirements for an IPv6 Customer Edge (CE) router. It focuses on the basic provisioning of an IPv6 CE router and the provisioning of IPv6 hosts attached to it.

> Working Group Summary

Most notable in the working group process was direct collaboration with the primary consumers of its recommendations - Broadband Forum, Cable Labs, broadband ISPs, and CPE vendors.

> Document Quality

This document does not specify a protocol. It does specify a CPE router that might be useful in residential broadband networks and the non-security feature set they need. The security feature set is specified in a separate working group document, draft-ietf-v6ops-cpe-simple-security, which it reference on that topic. BBF and Cable Labs involvement has resulted in the recommendations being in keeping with the expectations of those prominent fora.