Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E1EC28C11C; Mon, 14 Dec 2009 08:06:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.391 X-Spam-Level: X-Spam-Status: No, score=-1.391 tagged_above=-999 required=5 tests=[AWL=-1.208, BAYES_40=-0.185, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FHC7GL5p21KW; Mon, 14 Dec 2009 08:06:04 -0800 (PST) Received: from flower.research.telcordia.com (flower.research.telcordia.com [128.96.41.5]) by core3.amsl.com (Postfix) with ESMTP id 977E63A6A19; Mon, 14 Dec 2009 08:06:04 -0800 (PST) Received: from fajardov1 (vpntnlB33.research.telcordia.com [128.96.59.33]) by flower.research.telcordia.com (8.14.2/8.14.2) with ESMTP id nBEG5m16027612; Mon, 14 Dec 2009 11:05:48 -0500 (EST) From: "Victor Fajardo" To: "'Romascanu, Dan \(Dan\)'" , Date: Mon, 14 Dec 2009 11:05:48 -0500 Organization: Applied Research, Telcordia Technologies Message-ID: <000001ca7cd7$4d6b7020$e8425060$@telcordia.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01CA7CAD.64956820" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acp810yQ9v4heTvaTs2E2IniWZGQXA== Content-Language: en-us Cc: dime@ietf.org Subject: [Dime] PROTO Writeup for draft-ietf-dime-diameter-base-protocol-mib-03.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: vfajardo@research.telcordia.com List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2009 16:06:06 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01CA7CAD.64956820 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit PROTO WRITEUP for draft-ietf-dime-diameter-base-protocol-mib-03.txt =================================================================== http://www.ietf.org/id/draft-ietf-dime-diameter-base-protocol-mib-03.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? The document shepherd is Victor Fajardo (vf0213@gmail.com). I have personally reviewed the document and I believe it is ready for publication. (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 document defines the MIB module for the Diameter base protocol. It contains the minimum set of objects needed to manage a Diameter entity. These definitions are based on an implementation of Diameter and therefore gone through a good level of sanity checks. It has also been reviewed by members of the WG. The document shepherd has no concerns about the depth of the reviews. (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? There are no concerns with this document. (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 consensus in the WG behind the document. The document is an essential/required part of the Diameter base protocol deployment and so the problem space address by the doc is well understood. (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.) There is no opposition to 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. The document does not contain nits. (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 been split into normative and informative references. There are no normative references that are work in progress or downward references. (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? The document has an IANA considerations section that is consistent with the body. The document only request allocations of new OID under MIB-2. (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? The document contains MIB definitions. They have been validated and all definitions follow mib-2 syntax. (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 The document specifies the minimum required set of MIB objects necessary to manage a Diameter node using SNMP. The document specifies a MIB module that is compliant to the SMIv2. In particular it describes the MIB objects used for managing the Diameter base protocol (RFC3588). Working Group Summary There was consensus in the WG to publish the document. Document Quality The document has been reviewed by members of the DIME WG for its sanity in terms of the tunable objects and variables necessary for managing a Diameter node. It has also been reviewed by external folks who have vested interest in having a MIB module standardized. Additionally, the document has been passed through automated MIB checking tools to verify sanity of syntax and structure. Personnel Victor Fajardo is the document shepherd for this document. ------=_NextPart_000_0001_01CA7CAD.64956820 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

PROTO WRITEUP for = draft-ietf-dime-diameter-base-protocol-mib-03.txt

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

 

 

http://www.ietf.org/id/draft-ietf-dime-diameter-base-protocol-mi= b-03.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?

 

The document shepherd is Victor Fajardo (vf0213@gmail.com). I have personally reviewed the

document and I believe it is ready for = publication.

 

   (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 document defines the MIB module for the Diameter base protocol.

It contains the minimum set of objects needed = to manage a Diameter

entity. These definitions are based on an implementation of Diameter

and therefore gone through a good level of = sanity checks. It has also been

reviewed by members of the WG. The document = shepherd has no concerns

about the depth of the = reviews.

 

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

 

There are no concerns with this = document.

 

   (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 consensus in the WG behind the = document. The document is an

essential/required part of the Diameter base protocol deployment and

so the problem space address by the doc is = well understood.

 

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

 

There is no opposition to 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.

 

The document does not contain = nits.

 

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

There are no normative references that are = work in progress or downward

references.

 

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

 

The document has an IANA considerations = section that is consistent with the body.

The document only request allocations of new = OID under MIB-2.

 

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

 

The document contains MIB definitions. They = have been validated and all definitions

follow mib-2 syntax.

 

   (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

 

     The document = specifies the minimum required set of MIB objects

     necessary to manage = a Diameter node using SNMP. The document

     specifies a MIB = module that is compliant to the SMIv2. In

     particular it = describes the MIB objects used for managing

     the Diameter base = protocol (RFC3588).

 

   Working Group = Summary

 

     There was consensus = in the WG to publish the document.

 

   Document = Quality

 

     The document has = been reviewed by members of the DIME WG

     for its sanity in = terms of the tunable objects and variables

     necessary for = managing a Diameter node. It has also been reviewed

     by external folks = who have vested interest in having a MIB module

     standardized. = Additionally, the document has been passed through

     automated MIB = checking tools to verify sanity of syntax and

     = structure.

 

   Personnel

 

     Victor Fajardo is = the document shepherd for this document.

 

 

------=_NextPart_000_0001_01CA7CAD.64956820--