Subject: [Dime] Publication request for RFC4005bis -draft-ietf-dime-rfc4005bis-09

From: <[email-masked]>
Date: Sun, 20 May 2012 19:41:08 +0200

Dear Secretary,

This is a request for publication of draft-ietf-dime-rfc4005bis-09 as a
standards track RFC
(http://tools.ietf.org/html/draft-ietf-dime-rfc4005bis-09). 

Hereafter is the document shepherd proto write-up, using current version
of the document shepherd writeup template.

Regards,

Lionel

***************************

(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 ([email-masked]) is the Document Shepherd, 

  As Dime WG co-chair. Benoit Claise

  Benoit Claise ([email-masked]) 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.