[CCAMP] Please publish draft-ietf-ccamp-gmpls-ted-mib-13.txt

Lou Berger <lberger@labn.net> Tue, 22 May 2012 14:09 UTC

Return-Path: <lberger@labn.net>
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E01C921F85FD for <ccamp@ietfa.amsl.com>; Tue, 22 May 2012 07:09:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.858
X-Spam-Level:
X-Spam-Status: No, score=-99.858 tagged_above=-999 required=5 tests=[AWL=0.303, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9IwQjYqyOKfX for <ccamp@ietfa.amsl.com>; Tue, 22 May 2012 07:09:31 -0700 (PDT)
Received: from oproxy1-pub.bluehost.com (oproxy1.bluehost.com [IPv6:2605:dc00:100:2::a1]) by ietfa.amsl.com (Postfix) with SMTP id BE81D21F8623 for <ccamp@ietf.org>; Tue, 22 May 2012 07:09:30 -0700 (PDT)
Received: (qmail 24795 invoked by uid 0); 22 May 2012 14:09:28 -0000
Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy1.bluehost.com with SMTP; 22 May 2012 14:09:28 -0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=5dBcwJ9OPCmoEGDrtf+Ar09Glsk4hbk7IoCs4s/qbNc=; b=EP5T2shsJGEpwkyKs6uM0XnR+z/UO62pb43RgYEWw7R3Smvg47rtO5MZwmKII7uQaznzp+NdI7G6gWE7EnJZQbU7s9+p0E0AHpg2yAwlUbHE3bIIVpYGj6bbQlW9zCnk;
Received: from box313.bluehost.com ([69.89.31.113]:54387 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.76) (envelope-from <lberger@labn.net>) id 1SWpmC-0006ZM-1j; Tue, 22 May 2012 08:09:28 -0600
Message-ID: <4FBB9E14.5040400@labn.net>
Date: Tue, 22 May 2012 10:09:24 -0400
From: Lou Berger <lberger@labn.net>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4
MIME-Version: 1.0
To: Adrian Farrel <afarrel@juniper.net>, CCAMP <ccamp@ietf.org>, The IESG <iesg-secretary@ietf.org>
X-Enigmail-Version: 1.0.1
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net}
Subject: [CCAMP] Please publish draft-ietf-ccamp-gmpls-ted-mib-13.txt
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for the CCAMP working group <ccamp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ccamp>, <mailto:ccamp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ccamp>
List-Post: <mailto:ccamp@ietf.org>
List-Help: <mailto:ccamp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ccamp>, <mailto:ccamp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 22 May 2012 14:09:32 -0000

Proto-write-up for: draft-ietf-ccamp-gmpls-ted-mib-13.txt

> (1) What type of RFC is being requested (BCP, Proposed Standard,
> Internet Standard, Informational, Experimental, or Historic)?

Standards Track.
> Why is this the proper type of RFC?

It defines a Management Information Base.

> Is this type of RFC indicated in the title page header?

Yes.

>
>
> (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 memo defines the Management Information Base (MIB)
   objects in order to manage traffic engineering database (TED)
   information with extension in support of Multi-Protocol Label
   Switching (MPLS) with traffic engineering (TE) as well as
   Generalized MPLS (GMPLS) for use with network management
   protocols.


> Working Group Summary
>
>   Was there anything in WG process that is worth noting? For
>   example, was there controversy about particular points or
>   were there decisions where the consensus was particularly
>   rough?

This document has been in the WG for a very long time, with
significant time/delays due to extended review and revision
cycles. There were no objections raised to it's publication.

> Document Quality
>
>   Are there existing implementations of the protocol? Have a
>   significant number of vendors indicated their plan to
>   implement the specification? Are there any reviewers that
>   merit special mention as having done a thorough review,
>   e.g., one that resulted in important changes or a
>   conclusion that the document had no substantive issues? If
>   there was a MIB Doctor, Media Type or other expert review,
>   what was its course (briefly)? In the case of a Media Type
>   review, on what date was the request posted?
>

Implementation status is unknown (as is often the case).  The
document has been through many review cycles, including review by
a MIB Doctor.  Details are on the WG list.

>
> Personnel
>
>   Who is the Document Shepherd? Who is the Responsible Area
>   Director?

Lou Berger is the Document Shepherd. Adrian Farrel is the
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.


To document was reviewed a number of times as it progressed
through the WG, as well as during WG last call.  The document is
ready for publication.

>
>
> (4) Does the document Shepherd have any concerns about the depth or
> breadth of the reviews that have been performed?
>

No concerns.

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

The document has been revied by a MIB Doctor.

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

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

Yes.

> (8) Has an IPR disclosure been filed that references this document?
> If so, summarize any WG discussion and conclusion regarding the IPR
> disclosures.

No.

> (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 WG supports this document, but not may are passionate about it.

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

No issues.

> (12) Describe how the document meets any required formal review
> criteria, such as the MIB Doctor, media type, and URI type reviews.

This document has been reviewed by a, Joan Cucchiara.

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

No.

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

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

No.

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

The sole IANA consideration is as follows, and appears appropriate
to the Document Shepherd:

   The IANA is requested to assign {transmission XXX } to the TED-MIB
   module specified in this document.

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

Not applicable.

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

MIB definitions were verified by the MIB Doctor.