Jari,
On behalf of the 16ng WG, please find below the request to publish
draft-ietf-16ng-ipv6-over-ipv6cs-06.txt as a proposed standard.
thanks,
-16ng co-chairs (gab and daniel)
--------------------------------------------------------
Document writeup for
http://www.ietf.org/internet-drafts/draft-ietf-16ng-ipv6-over-ipv6cs-06.txtTarget: Proposed Standard
Document shepherd questions and writeup format (21 November 2006)
(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?
Gabriel Montenegro, the shepherding co-chair, has read this
version and thinks it is ready to advance.
(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?
There has
been considerable review on this draft from WG members,
an AD and the WG's technical advisors. It has also been the subject
of discussion in face-to-face meetings at regular IETF
sessions as well as an interim meeting last September.
Also very important is the review done at the WiMax forum,
where this document is now being referred to from their
specifications.
(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?
I believe there is sufficient review. This document has
undergone two WG LC periods, an initial 2-week period in
October and a shorter 1-week period which ended on Jan 5.
(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.
None.
(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?
There is strong consensus behind the approach. There was
considerable discussion during both WG LC period. In particular,
this version clarifies some points discussed during the last
WG LC related to multicast support, router discovery and some
additional information about the 802.16 procedures.
(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
http://www.ietf.org/ID-Checklist.html 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?
No issues found.
(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].
No issues here.
(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 suggested a
reasonable name for the new registry? See
[I-D.narten-iana-considerations-rfc2434bis]. 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?
IANA section does not require any actions.
(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?
No such sections.
(1.k) The IESG approval announcement includes a Document
Announcement Write-Up. Please provide such a Document
Announcement Writeup? Recent examples can be found in the
"Action" announcements for approved documents. The approval
announcement contains the following sections:
Technical Summary
This document specifies the addressing and operation of IPv6 over
the IPv6 specific part of the packet CS for hosts served by a
network that utilizes the IEEE Std 802.16 air interface. It
recommends the assignment of a unique prefix (or prefixes) to each
host
and allows the host to use multiple identifiers within that
prefix, including support for randomly generated identifiers.
Working Group Summary
There was much initial debate about the link model to adopt.
The interim made it clear that the "per-MS" prefix was
preferable. Beyond that, there has been debate about how much
802.16-specific details to include (e.g., on network entry
procedure) for clarity.
Document
Quality
There are no currently known implementations of this document.
However, the per-MS prefix model has been deployed in 3GPP, so
at least that part is known to work, and this was a major point
in deciding in its favor. The WiMax forum sees this document as one
of its pilars, so it is expected that it will see significant
deployment within the next years.
Personnel
Who is the Document Shepherd for this
document? Who is the
Responsible Area Director?
Shepherd: Gabriel Montenegro
AD: Jari Arkko