Please publish draft-ietf-ccamp-gmpls-mln-reqs-07
"Adrian Farrel" <adrian@olddog.co.uk> Mon, 17 December 2007 21:40 UTC
Return-path: <owner-ccamp@ops.ietf.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4Nhr-0001YN-Oa for ccamp-archive@ietf.org; Mon, 17 Dec 2007 16:40:59 -0500
Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J4Nhp-0002j4-LI for ccamp-archive@ietf.org; Mon, 17 Dec 2007 16:40:59 -0500
Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from <owner-ccamp@ops.ietf.org>) id 1J4NWb-000MFC-Kz for ccamp-data@psg.com; Mon, 17 Dec 2007 21:29:21 +0000
X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com
X-Spam-Level:
X-Spam-Status: No, score=-102.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE, STOX_REPLY_TYPE,USER_IN_ALL_SPAM_TO autolearn=no version=3.2.3
Received: from [62.128.201.248] (helo=asmtp1.iomartmail.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from <adrian@olddog.co.uk>) id 1J4NW2-000MCO-EW for ccamp@ops.ietf.org; Mon, 17 Dec 2007 21:29:06 +0000
Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id lBHLSP4S021042; Mon, 17 Dec 2007 21:28:26 GMT
Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp1.iomartmail.com (8.12.11.20060308/8.12.11) with ESMTP id lBHLSHpf020995; Mon, 17 Dec 2007 21:28:25 GMT
Message-ID: <034f01c840f3$bd511f60$9200a8c0@your029b8cecfe>
Reply-To: Adrian Farrel <adrian@olddog.co.uk>
From: Adrian Farrel <adrian@olddog.co.uk>
To: Ross Callon <rcallon@juniper.net>
Cc: ccamp@ops.ietf.org, WG Milestone Tracker <iesg-secretary@ietf.org>, dward@cisco.com
Subject: Please publish draft-ietf-ccamp-gmpls-mln-reqs-07
Date: Mon, 17 Dec 2007 21:25:39 -0000
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"; charset="iso-8859-1"; reply-type="original"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.3138
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
Sender: owner-ccamp@ops.ietf.org
Precedence: bulk
X-Spam-Score: -3.8 (---)
X-Scan-Signature: 86f85b2f88b0d50615aed44a7f9e33c7
Here is the proto write-up for draft-ietf-ccamp-gmpls-mln-reqs-07 Thanks, Adrian === Proto-write-up for draft-ietf-ccamp-gmpls-mln-reqs-07 Intended status : Informational Recommend that this I-D is progressed in parallel with draft-ietf-ccamp-gmpls-mln-eval-05.txt requested for publication at the same time. > (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? Adrian Farrel is the document shepherd. He has personally reviewed the I-D and believes it is ready for forwarding to the IESG 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? Long list of authors/contributors. This document has been reviewed by the CCAMP working group and discussed quite extensively at IETF meetings and on the mailing list. In addition, the I-D received thorough review on liaison from Question 14 of Study Group 15 of the ITU-T. These reviews have been sufficiently deep and broad. > (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 concerns. > (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. The document is sound. An IPR disclosure can be found at https://datatracker.ietf.org/ipr/518/ and was filed against the -00 version of this I-D when it was still an individual submission. This was brought to the attention of the working group, but no-one had any issues. Since this is an Informational Requirements I-D, it might be unlikely that there would be any implementation of the I-D to be impacted by the IPR claim. > (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 were no problems with consensus for this document. > (1.f) 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 > entered into the ID Tracker.) No threats. No discontent. > (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? All checks made. > (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]. References split. No downrefs. > (1.i) Has the Document Shepherd verified that the document IANA > consideration 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 Shepherd > conferred with the Responsible Area Director so that the IESG > can appoint the needed Expert during the IESG Evaluation? This is an Informational I-D. A null IANA section is present. > (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? No such sections. > (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 > Relevant content can frequently be found in the abstract > and/or introduction of the document. If not, this may be > an indication that there are deficiencies in the abstract > or introduction. Most of the initial efforts to utilize Generalized MPLS (GMPLS) have been related to environments hosting devices with a single switching capability. The complexity raised by the control of such data planes is similar to that seen in classical IP/MPLS networks. By extending MPLS to support multiple switching technologies, GMPLS provides a comprehensive framework for the control of a multi- layered network of either a single switching technology or multiple switching technologies. In GMPLS, a switching technology domain defines a region, and a network of multiple switching types is referred to in this document as a Multi-Region Network (MRN). When referring in general to a layered network, which may consist of either a single or multiple regions, this document uses the term, Multi-Layer Network (MLN). This document defines a framework for GMPLS based multi-region/ multi-layer networks and lists a set of functional requirements. > 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? There was some unresolved debate about the term "virtual TE link" and whether it should be replaced with "potential TE link". However, since the former had been in use for a long time and was used in published RFCs, and since there was not great support for a change, we retained "virtual". > 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? This is an Informational I-D with no protocol specifications. Expert review of multi-layer network architecture was received from the ITU-T.
- Please publish draft-ietf-ccamp-gmpls-mln-reqs-07 Adrian Farrel