Proto Writeup for this draft:
(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?
The Document Shepherd is Lyndon Ong. He has personally reviewed
this version of the document and believes that it is ready for forwarding to
the IESG for publication as an Experimental RFC.
(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?
The document has had adequate review from key WG members. The
Document Shepherd has no particular concerns about the depth and breadth of the
reviews.
(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?
The Document Shepherd has no particular concerns that the document
needs more review.
(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.
The Document Shepherd has no particular additional concerns for the
Area Director or IESG. The question of need was raised on the mailing
list and elicited a number of responses from participants who were interested
in the MIB. No IPR disclosures related to the document have been filed.
(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 a firm WG consensus behind the document. It is (as a
MIB) primarily of interest to a subset of participants in the WG, but has been
reviewed and supported by WG members both interested in the MIB and familiar
with the protocols that would be managed by the MIB.
(1.f) Has anyone threatened an appeal or otherwise indicated
extreme
discontent? If so,
please summarize 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.)
There has been no dispute over the document or expression of
discontent.
(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? If the document
does not already
indicate its intended status at the top of
the first page, please
indicate the intended status here.
The Document Shepherd has checked the document against nits and as far
as he could tell all nits have been satisfied. The document has not had a
formal MIB Doctor review, however it has been run through an automated checker
(see below). The document has its intended status (Experimental RFC) at
the top of the first page.
(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].
The document has allocated references to normative and informative. It
should be noted that some normative references are to Experimental RFCs since
the MIB is intended to manage protocols that have been defined in Experimental
RFCs. This seems appropriate since the MIB itself will be Experimental.
(1.i) Has the Document Shepherd verified that the document's
IANA
Considerations 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 [RFC2434]. If the
document describes an
Expert Review process, has the Document
Shepherd conferred with
the Responsible Area Director so that
the IESG can appoint the
needed Expert during IESG Evaluation?
As far as the Document Shepherd has been able to verify, the document’s
IANA Considerations section exists and is in order. It does not describe
any Expert Review process.
(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?
As mentioned above, the MIB definitions in the document have been run
through an automated checker, in this case the smilint compiler package.
(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:
The Announcement Write-Up follows:
Technical
Summary:
This
document defines a SMIv2 compliant Management
Information
Base (MIB) providing access to managed objects in an
implementation of the Reliable Server Pool architecture and protocols. It
is
intended as an Experimental Track RFC.
Working
Group Summary
This
document has been reviewed by Rserpool protocol experts within the
WG
and no controversy or difficulty was encountered with obtaining consensus
on
this document.
Document
Quality
There
are no implementations of the MIB at this time, but
a
number of researchers have implemented the protocols and reviewed the MIB
specification
based on their work.
.
Personnel
Lyndon
Ong, co-chair of the Rserpool WG, is shepherd for this document.
Magnus
Westerlund provided review as the responsible Area Director.
Lyndon Y. Ong | Senior Technology Director
lyong <at> ciena.com
| PO Box 308 | Cupertino, CA95015USA
Direct +1.408.962.4929 | Mobile
+1.408.768.7872 | Fax +1.408.962.4929
RSS Feed