[Dime] PROTO Writeup for draft-ietf-dime-diameter-cmd-iana-01.txt

["Victor Fajardo" <[e-mail]>]

PROTO Writeup for "Updated IANA Considerations for Diameter Command Code
Allocations"

============================================================================
=========

 

http://www.ietf.org/id/draft-ietf-dime-diameter-cmd-iana-01.txt

 

   (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?

 

Victor Fajardo ([e-mail]). 

Yes, this version is ready for publication. I have reviewed this document. 

 

   (1.b)  Has the document had adequate review both from key WG members

          and from key non-WG members?  Does the Document Shepherd have

          any concerns about the depth or breadth of the reviews that

          have been performed?

 

This content of this document has been subject of a design team and is part
of the 

Diameter extensibility story. There has been sufficient review and
discussion 

about this topic in DIME. 

 

 

   (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?

 

No further review is required. 

 

   (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.

 

There are no concerns with this document. 

 

   (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 solid agreement behind this document. 

 

   (1.f)  Has anyone threatened an appeal or otherwise indicated extreme

          discontent?  If so, please summarize 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.)

 

Nobody has threatened appeal or extreme discontent with this document. 

 

   (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?  If the document

          does not already indicate its intended status at the top of

          the first page, please indicate the intended status here.

 

No nits have been found. 

 

   (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 has references split into normative and informative references.


There is no problem with the normative references. No DOWNREF is necessary. 

 

 

   (1.i)  Has the Document Shepherd verified that the document's IANA

          Considerations 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 the Document

          Shepherd conferred with the Responsible Area Director so that

          the IESG can appoint the needed Expert during IESG Evaluation?

 

Yes, the IANA consideration section is in-sync with the body of the
document. 

This document changes the allocation policy of an existing registry
established

with RFC 3588. 

 

   (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 parts that are written in a formal language. 

 

   (1.k)  The IESG approval announcement includes a Document

      Announcement Write-Up.  Please provide such a Document

      Announcement Writeup?  Recent examples can be found in the

      "Action" announcements for approved documents.  The approval

      announcement contains the following sections:

 

      Technical Summary

 

   The Diameter Base specification, described in RFC 3588, provides a

   number of ways to extend Diameter, with new Diameter commands, i.e.

   messages used by Diameter applications, and applications as the most

   extensive enhancements.  RFC 3588 illustrates the conditions that

   lead to the need to define a new Diameter application or a new

   command code.  Depending on the scope of the Diameter extension IETF

   actions are necessary.  Although defining new Diameter applications

   does not require IETF consensus, defining new Diameter commands

   requires IETF consensus per RFC 3588.  This has lead to questionable

   design decisions by other Standards Development Organizations which

   chose to define new applications on existing commands rather than

   asking for assignment of new command codes for the pure purpose of

   avoiding bringing their specifications to the IETF.  In some cases

   interoperability problems were causes as an effect of the poor design

   caused by overloading existing commands.

 

   This document aligns the extensibility rules of Diameter application

   with the Diameter commands offering ways to delegate work on Diameter

   to other SDOs to extend Diameter in a way that does not lead to poor

   design choices.

 

      Working Group Summary

 

   This document is the product of the DIME working group. The 

   extensibility rules of Diameter have been investigated by a 

   design team and the alignment of policy for extending 

   Diameter applications and Diameter commands has been agreed.  

 

      Document Quality

 

    This document focuses on the description of the allocation 

                policy change in the IANA consideration section and 

                has been discussed for some time. 

 

 

      Personnel

 

    Victor Fajardo is the document shepherd for this document. 

    Dan Romascanu is the responsible AD.