[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
PROTO writeup for Issues & Fixes
Find enclosed the proposed PROTO writeup for Issues & Fixes, which will
submitted for IESG review once -03 hits the archive. Comment welcome.
------------------------------------------------------------------------
Title:
Common RADIUS Implementation Issues and Suggested Fixes
I-D:
http://www.ietf.org/internet-drafts/draft-ietf-radext-fixes-03.txt
Status: Proposed Standard
(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?
Document Shepherd: Bernard Aboba
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 a WG last call.
(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?
Document review has focused on the RADEXT WG since the document is about
RADIUS protocol issues and fixes.
(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,
8 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:
TBD, pending -03 submission to address IDNits.
(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?
This document has no actions for IANA.
(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 common issues seen in RADIUS implementations
and suggests some fixes. Where applicable, ambiguities and errors in
previous RADIUS specifications are clarified.
- Working Group Summary
This document originally included issues and fixes relating to RFC 3576, but
it
was decided that handling that in a separate document (RFC 3576bis) would be
more appropriate. During the development of this document, a number of
issues
required extended discussion, most recently text relating to handling of
duplicate detection within RADIUS.
- Document Quality
This document describes issues that have been raised as a result of the
widespread
deployment of RADIUS for authentication, authorization and accounting.
- Personnel
Bernard Aboba is the document shepherd. The responsible Area Director is
Dan Romascanu. No IANA expert is needed.
--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>