[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Request to publish draft-ietf-radext-design as a BCP
The RADEXT WG has completed its "last look" at the RADIUS Design Guidelines Document,
draft-ietf-radext-design-05.txt. We would therefore like to request that the IESG consider
publication of this document as a Best Current Practice.
==============================================
Title: RADIUS Design Guidelines
I-D:
http://www.ietf.org/internet-drafts/draft-ietf-radext-design-05.txt
Status: Best Current Practice
Response to template:
1) Have the chairs personally reviewed this version of the ID and do
they believe this ID is sufficiently baked to forward to the IESG
for publication?
Yes.
2) Has the document had adequate review from both key WG members and
key non-WG members? Do you have any concerns about the depth or
breadth of the reviews that have been performed?
Yes. The ID has had 2 working group last calls.
3) Do you have concerns that the document needs more review from a
particular (broader) perspective (e.g., security, operational
complexity, someone familiar with AAA, etc.)?
No concerns.
4) Do you have any specific concerns/issues with this document that
you believe the ADs and/or IESG should be aware of? For example,
perhaps you are uncomfortable with certain parts of the document,
or whether there really is a need for it, etc., but at the same
time these issues have been discussed in the WG and the WG has
indicated it wishes to advance the document anyway.
No.
5) 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 solid consensus behind this document. The overall approach
to the document has been extensively discussed, both in IETF meetings
and on the mailing list. Over a dozen people have commented on various
aspects of the document during its development. The issues raised in
WG last call, available for inspection at
http://www.drizzle.com/~aboba/RADEXT/, were resolved in the -05
version of the document.
6) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarize what are they upset about.
No.
7) Have the chairs verified that the document adheres to _all_ of the
ID nits? (see http://www.ietf.org/ID-nits.html).
Yes. An output of the run on this revision of the ID by the online nits
checker:
idnits 2.08.10
tmp/draft-ietf-radext-design-05.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: Best Current Practice
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative
references
to lower-maturity documents in RFCs)
-- Looks like a reference, but probably isn't: '8' on line 1431
'The Text field consists of UTF-8 encoded 10646 [8] characters....'
Summary: 0 errors (**), 0 warnings (==), 1 comment (--).
8) Does the document a) split references into normative/informative,
and b) are there normative references to IDs, where the IDs are not
also ready for advancement or are otherwise in an unclear state?
(Note: the RFC editor will not publish an RFC with normative
references to IDs, it will delay publication until all such IDs are
also ready for publication as RFCs.)
The document does split references into normative and informative ones.
There are no normative references to IDs.
9) For Standards Track and BCP documents, the IESG approval
announcement includes a writeup section with the following
sections:
- Technical Summary
This document provides guidelines for the design of attributes used
by the Remote Authentication Dial In User Service (RADIUS) protocol.
It is expected that these guidelines will prove useful to authors and
reviewers of future RADIUS attribute specifications, both within the
IETF as well as other Standards Development Organizations (SDOs).
- Working Group Summary
There have been 2 WGLCs on the document. Much of the discussion on
the document has centered around the design guidelines
surrounding complex attributes, as well as the relationship of the
RADIUS Vendor-Specific Attribute (VSA) and the Standard attribute
space. There was also considerable discussion relating to the
process for review of RADIUS attributes specified by SDOs.
Ultimately, a consensus developed behind a model similar to that
described in [RFC4663].
--
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/>