Note added by Benoit Claise on Nov 7th 2013:
Despite multiple pings since Feb 2013 to produce a new version (with agreed
changes as far as the doc. shepherd and I can tell), the author has not been
responding. The document shepherd, Lionel Morand, takes over the edit token from
now on. If the author is not responsive during AUTH48, the document shepherd will
also take over.
(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)? Why
is this the proper type of RFC? Is this type of RFC indicated in the
title page header?
This type of RFC request is Proposed Standard in the Standards track.
Standards Track is indicated in the title page header.
This document is a bis version an existing Standards Track RFC (RFC 4005)
and this new version will obsolete the old one if approved.
(2) 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 obsoletes RFC 4005 and is not backward compatible with
that document. The main change compared to the RFC 4005 is the removal
of all of the material related to RADIUS/Diameter protocol interactions,
which was underspecified and misleading. Moreover, the Command Code Format
(CCF) for the Accounting-Request and Accounting-Answer messages has been
changed to explicitly require the inclusion of the Acct-Application-Id AVP and
exclude the Vendor-Specific-Application-Id AVP. The accounting model to be
used with this application is also specified.
Working Group Summary
-----
The document spent almost two years as WG document and the
proposed changes from RFC 4005 were straightforward and roughly
endorsed by the Working Group. There was no controversy on its
final content.
Document Quality
-----
A number of vendors have indicated interest on implementing
the specification due it correcting several known flaws.
There has been no MIB Doctor or Media Type reviews as those
were not seen relevant for the bis version of the specification.
There has not been explicitly requested expert reviews outside
the WG as we believe most if not all important technical experts
are already represented in the WG and its mailing list. The
document has received multiple reviews while in WGLC.
Personnel
Who is the Document Shepherd? Who is the Responsible Area
Director?
Lionel Morand (lionel.morand@orange.com) is the Document Shepherd,
As Dime WG co-chair. Benoit Claise
Benoit Claise (bclaise@cisco.com) is the Responsible Area Director.
(3) Briefly describe the review of this document that was performed by
the Document Shepherd. If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.
I have personally reviewed the draft, exchanged with authors to
clarify some points and concluded that this document was ready for
publication
(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?
The document shepherd has no concern about quality of the reviews,
which were performed by key WG members.
(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.
No.
(6) Describe any specific concerns or issues that the Document Shepherd
has 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.
No concern.
(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.
This document does not introduce any material subject to IPR disclosure,
as the main changes were to remove material or clarify existing part of
the existing RFC (RFC 4005) that IPR free.
(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.
No IPR
(9) 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?
The main objective of this document, i.e. removal of material related
to RADIUS/Diameter protocol interactions in the RFC 4005, was discussed
and agreed in the Dime WG, as well as in the AAA-Doctors directorate.
The resulting document was quite straightforward without controversial
updates. This document has beneficiated of reviews from key members.
(10) 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 publicly available.)
No.
(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.
Idnits was run. No action is required.
(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.
(13) Have all references within this document been identified as
either normative or informative?
Yes.
(14) 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 plan for their completion?
I-D.ietf-dime-rfc3588bis has just been approved by IESG and is in
the RFC Ed Queue.
(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in the
Last Call procedure.
No downward normative references.
(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.
Any existing document making reference to the RFC 4005 will be
automatically updated with the reference of this new RFC, as it will
obsolete the previous one.
(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).
This document does not introduce protocol extensions or new registries.
Existing namespaces used in this document are already managed by the IANA.
(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registry.
No new registry.
(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.
No check has been performed on this document as ABNF description found
in this document is from the existing RFC already checked.