|
On behalf of the RADEXT WG,
I am requesting the publication of the Internet Draft described
herein as an Informational RFC. WGLC on This document concluded on
June 27, 2007. All issues have been addressed. -------------------------------------------------------------------- Title: Common Dynamic Authorization
Extensions to Remote Authentication Dial In User Service (RADIUS) I-D: http://www.ietf.org/internet-drafts/draft-ietf-radext-rfc3576bis-08.txt Status: Informational (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
David Nelson. I have personally reviewed the document. (1.b) Has the document had
adequate review from both key WG members And key non-WG members? Does
the Document Shepherd have any concerns about the depth or breadth
of the reviews that have been performed? Yes. This document has been
through two RADEXT WG last calls. (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? This document is a revision
of RFC 3576, so there is existing operational experience. (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. No 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? There is consensus behind
this document. At various points, 6 people have posted review
comments or made contributions relating to the document. The issues raised and the
resolutions are available for inspection at http://www.drizzle.com/~aboba/RADEXT/ (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? Yes. An output of the run on
this revision of the ID by the online nits checker: idnits 2.04.09 tmp/draft-ietf-radext-rfc3576bis-08.txt: Checking boilerplate
required by RFC 3978 and 3979, updated by RFC 4748: ---------------------------------------------------------------------------- No
issues found here. Checking nits
according to http://www.ietf.org/ietf/1id-guidelines.txt: ---------------------------------------------------------------------------- No
issues found here. Checking nits according
to http://www.ietf.org/ID-Checklist.html: ---------------------------------------------------------------------------- No
issues found here. Miscellaneous
warnings: ---------------------------------------------------------------------------- No
issues found here. Checking references
for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference:
'Note 1' is mentioned on line 956, but not
defined
'[Note 1] Where NAS or session identification attributes are inclu...' == Missing Reference:
'Note 3' is mentioned on line 970, but not
defined '[Note 3] When included
within a CoA-Request, these attributes...' == Missing Reference:
'Notes 1' is mentioned on line 908, but not
defined '0+
0 0 97
Framed-IPv6-Prefix [Notes 1,6]...' -- Looks like a
reference, but probably isn't: '6' on line 908
'0+
0 0 97
Framed-IPv6-Prefix [Notes 1,6]...' == Missing Reference:
'Note 2' is mentioned on line 962, but not
defined
'[Note 2] The Reply-Message Attribute is used to present a display...' == Missing Reference:
'Note 7' is mentioned on line 998, but not
defined
'[Note 7] Within CoA-Request packets, Vendor-Specific Attributes...' == Missing Reference:
'Note 5' is mentioned on line 982, but not
defined '[Note 5] When included
within a CoA-Request, these attributes...' == Missing Reference:
'Note 4' is mentioned on line 976, but not
defined
'[Note 4] When included within a successful Disconnect-Request (wh...' == Missing Reference:
'Note 6' is mentioned on line 987, but not
defined
'[Note 6] Since the Framed-IP-Address, Framed-IPv6-Prefix and Fram...' ** Obsolete normative
reference: RFC 2409 (Obsoleted by RFC 4306)
Summary: 1 error (**), 8 warnings (==), 1 comment (--). (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 splits
normative and informative references. There are no normative
references to IDs. (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 [RFC2434]. 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? The document only requests
assignment of additional values of existing attributes, since
most parameters were already allocated in RFC 3575 and 3576. (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? This document does not
contain sections written in a formal language. (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 describes a
currently deployed extension to the Remote Authentication Dial In User
Service (RADIUS) protocol, allowing dynamic changes to a user
session, as implemented by network access server products. This
includes support for disconnecting users and changing authorizations
applicable to a user session. - Working Group
Summary This document represents an
update to RFC 3576, addressing issues and fixes that have been
identified since the document was originally published. Originally, these
issues were included in the RADIUS Issues and Fixes document, but were
sufficient in number and size to require a revision to RFC 3576. - Document Quality This document describes
issues that were encountered by implementers of RFC 3576. As a result, it
has been reviewed by implementers as well as operators. - Personnel David Nelson is the document
shepherd. The responsible Area Director is Dan Romascanu. |