MPLS Transport Profile (MPLS-TP) Traffic Engineering (TE) Management Information Base (MIB)
draft-ietf-mpls-tp-te-mib-11
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2015-02-25
|
11 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2015-02-02
|
11 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2015-01-29
|
11 | (System) | RFC Editor state changed to RFC-EDITOR from AUTH |
2015-01-27
|
11 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2015-01-26
|
11 | (System) | IANA Action state changed to Waiting on RFC Editor from In Progress |
2015-01-26
|
11 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2015-01-16
|
11 | (System) | RFC Editor state changed to AUTH from EDIT |
2015-01-02
|
11 | Tero Kivinen | Closed request for Last Call review by SECDIR with state 'No Response' |
2014-12-23
|
11 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2014-12-19
|
11 | Cindy Morgan | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2014-12-19
|
11 | (System) | IANA Action state changed to In Progress |
2014-12-19
|
11 | (System) | RFC Editor state changed to EDIT |
2014-12-19
|
11 | (System) | Announcement was received by RFC Editor |
2014-12-19
|
11 | Amy Vezza | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
2014-12-19
|
11 | Amy Vezza | IESG has approved the document |
2014-12-19
|
11 | Amy Vezza | Closed "Approve" ballot |
2014-12-19
|
11 | Adrian Farrel | IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup |
2014-12-19
|
11 | Adrian Farrel | Ballot approval text was generated |
2014-12-19
|
11 | Adrian Farrel | Ballot writeup was changed |
2014-12-18
|
11 | Venkatesan Mahalingam | New version available: draft-ietf-mpls-tp-te-mib-11.txt |
2014-12-18
|
10 | Cindy Morgan | IESG state changed to IESG Evaluation::AD Followup from IESG Evaluation |
2014-12-18
|
10 | Benoît Claise | [Ballot comment] I'm confident that the responsible AD will take care of the Security Guidelines for IETF MIB Modules (http://trac.tools.ietf.org/area/ops/trac/wiki/mib-security) in the next … [Ballot comment] I'm confident that the responsible AD will take care of the Security Guidelines for IETF MIB Modules (http://trac.tools.ietf.org/area/ops/trac/wiki/mib-security) in the next draft version. I know that this MIB was the source of much debate. Thanks for this paragraph: At the time of writing, SNMP SET is no longer recommended as a way to configure MPLS networks as was described in [RFC3812]. However, since the MIB modules specified in this document extend and are intended to work in parallel with the MIB modules for MPLS specified in [RFC3812], certain objects defined here are specified with MAX-ACCESS of read-write or read-create so that specifications of the base tables in [RFC3812] and the extensions in this document are consistent. Although the examples described in Section 9 specify means to configure MPLS-TP tunnels in a similar way to the examples in [RFC3812], this should be seen as indicating how the MIB values would be returned in the specified circumstances having been configured by alternative means. |
2014-12-18
|
10 | Benoît Claise | [Ballot Position Update] Position for Benoit Claise has been changed to No Objection from Discuss |
2014-12-18
|
10 | Richard Barnes | [Ballot Position Update] New position, No Objection, has been recorded for Richard Barnes |
2014-12-18
|
10 | Adrian Farrel | [Ballot comment] Thanks for addressing my Comment. |
2014-12-18
|
10 | Adrian Farrel | Ballot comment text updated for Adrian Farrel |
2014-12-18
|
10 | Jari Arkko | [Ballot Position Update] New position, No Objection, has been recorded for Jari Arkko |
2014-12-18
|
10 | Benoît Claise | [Ballot discuss] One easy to fix DISCUSS. As noted by other IESG members, the Security Considerations don't match the Security Guidelines for IETF MIB Modules … [Ballot discuss] One easy to fix DISCUSS. As noted by other IESG members, the Security Considerations don't match the Security Guidelines for IETF MIB Modules at http://trac.tools.ietf.org/area/ops/trac/wiki/mib-security |
2014-12-18
|
10 | Benoît Claise | [Ballot comment] I know that this MIB was the source of much debate. Thanks for this paragraph: At the time of writing, SNMP SET is … [Ballot comment] I know that this MIB was the source of much debate. Thanks for this paragraph: At the time of writing, SNMP SET is no longer recommended as a way to configure MPLS networks as was described in [RFC3812]. However, since the MIB modules specified in this document extend and are intended to work in parallel with the MIB modules for MPLS specified in [RFC3812], certain objects defined here are specified with MAX-ACCESS of read-write or read-create so that specifications of the base tables in [RFC3812] and the extensions in this document are consistent. Although the examples described in Section 9 specify means to configure MPLS-TP tunnels in a similar way to the examples in [RFC3812], this should be seen as indicating how the MIB values would be returned in the specified circumstances having been configured by alternative means. |
2014-12-18
|
10 | Benoît Claise | [Ballot Position Update] New position, Discuss, has been recorded for Benoit Claise |
2014-12-18
|
10 | Joel Jaeggli | [Ballot Position Update] New position, No Objection, has been recorded for Joel Jaeggli |
2014-12-17
|
10 | Gunter Van de Velde | Request for Last Call review by OPSDIR Completed: Ready. Reviewer: Niclas Comstedt. |
2014-12-17
|
10 | Cindy Morgan | Changed consensus to Yes from Unknown |
2014-12-17
|
10 | Alia Atlas | [Ballot Position Update] New position, Yes, has been recorded for Alia Atlas |
2014-12-17
|
10 | Martin Stiemerling | [Ballot Position Update] New position, No Objection, has been recorded for Martin Stiemerling |
2014-12-16
|
10 | Spencer Dawkins | [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins |
2014-12-16
|
10 | Alissa Cooper | [Ballot comment] I realize the security considerations might get updated based on comments from Stephen/Benoit, but wanted to ask about this in case this text … [Ballot comment] I realize the security considerations might get updated based on comments from Stephen/Benoit, but wanted to ask about this in case this text stays in the document: "When MIB is used to configure ICC_Operator_ID, as specified in [RFC6370], it should be considered sensitive operation. Hence proper protection should be taken to allow configuration via SET operation in order to ensure its purpose of providing globally unique MPLS-TP identifiers." This is a little confusing for a number of reasons. ICC_Operator_ID does not appear to be specified in RFC 6370, but rather in RFC 6923. Global_ID is specified in RFC 6370. Was this text meant to apply to both? Also, it's not clear why the configuration of ICC_Operator_ID "should be considered a sensitive operation." Is it because failing to use a unique ICC_Operator_ID can cause operational problems (as described in RFC 6370 for Global_ID)? Isn't uniqueness guaranteed in the way that both ICC_Operator_IDs and Global_IDs themselves are generated, such that the only real risk with the MIB is that these IDs would be somehow transformed from their originals to no longer be unique? Or are they sensitive for some other reason not related to uniqueness? |
2014-12-16
|
10 | Alissa Cooper | [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper |
2014-12-16
|
10 | Ted Lemon | [Ballot Position Update] New position, No Objection, has been recorded for Ted Lemon |
2014-12-15
|
10 | Stephen Farrell | [Ballot comment] The security considerations doesn't appear to match the guidance for MIBs. ([1] that may possibly still have an update to come, not sure.) … [Ballot comment] The security considerations doesn't appear to match the guidance for MIBs. ([1] that may possibly still have an update to come, not sure.) I think Benoit is onto this as well so I'll leave it to him as he knows MIBs better. [1] http://trac.tools.ietf.org/area/ops/trac/wiki/mib-security |
2014-12-15
|
10 | Stephen Farrell | [Ballot Position Update] New position, No Objection, has been recorded for Stephen Farrell |
2014-12-15
|
10 | Brian Haberman | [Ballot Position Update] New position, No Objection, has been recorded for Brian Haberman |
2014-12-14
|
10 | Venkatesan Mahalingam | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2014-12-14
|
10 | Venkatesan Mahalingam | New version available: draft-ietf-mpls-tp-te-mib-10.txt |
2014-12-13
|
09 | Pete Resnick | [Ballot comment] 6.1 and 10: Maybe this is crystal clear in the MPLS and SNMP communities, and if it is you can ignore this comment, … [Ballot comment] 6.1 and 10: Maybe this is crystal clear in the MPLS and SNMP communities, and if it is you can ignore this comment, but "alphabetic character" is ambiguous. You probably mean "ASCII alphabetic character", and you could simply make the substitution throughout if you like (and reference RFC 20 is you were feeling especially pedantic), but if there is no chance for misinterpretation, I certainly won't stand on ceremony. |
2014-12-13
|
09 | Pete Resnick | [Ballot Position Update] New position, No Objection, has been recorded for Pete Resnick |
2014-12-12
|
09 | Elwyn Davies | Request for Last Call review by GENART Completed: Not Ready. Reviewer: Elwyn Davies. |
2014-12-09
|
09 | Barry Leiba | [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba |
2014-12-09
|
09 | Adrian Farrel | [Ballot comment] IANA notes that it would be clearer if the four instances of "xxx" for codepoint assignment were replaced with distinctive markers (such as … [Ballot comment] IANA notes that it would be clearer if the four instances of "xxx" for codepoint assignment were replaced with distinctive markers (such as www, xxx, yyy, and zzz) so that the assignments and editing will be sure to be correct. This can be done as an edit post approval or batched with other changes necessary to resolve any Discusses that arise. |
2014-12-09
|
09 | Adrian Farrel | Ballot comment text updated for Adrian Farrel |
2014-12-08
|
09 | (System) | IANA Review state changed to IANA OK - Actions Needed from IANA - Review Needed |
2014-12-08
|
09 | Pearl Liang | IESG/Authors/WG Chairs: IANA has reviewed draft-ietf-mpls-tp-te-mib-09. Authors should review the comments and/or questions below. Please report any inaccuracies and respond to any questions as soon … IESG/Authors/WG Chairs: IANA has reviewed draft-ietf-mpls-tp-te-mib-09. Authors should review the comments and/or questions below. Please report any inaccuracies and respond to any questions as soon as possible. IANA has one comment for the requested assignments by this draft. We received the following comments/questions from the IANA's reviewer: IANA understands that, upon approval of this document, there are four actions which IANA must complete. First, in the SMI Network Management MGMT Codes Internet-standard MIBsubregistry of the Network Management Parameters registry located at: http://www.iana.org/assignments/smi-numbers a new MIB will be registered as follows: Decimal: [ TBD by IANA at time of registration ] Name: mplstcextstdMIB Description: MPLS Textual Convention Extension MIB References: [ RFC-to-be ] Second, also in the SMI Network Management MGMT Codes Internet-standard MIBsubregistry of the Network Management Parameters registry located at: http://www.iana.org/assignments/smi-numbers a new MIB will be registered as follows: Decimal: [ TBD by IANA at time of registration ] Name: mplsidstdMIB Description: MPLS Identifier MIB References: [ RFC-to-be ] Third, also in the SMI Network Management MGMT Codes Internet-standard MIBsubregistry of the Network Management Parameters registry located at: http://www.iana.org/assignments/smi-numbers a new MIB will be registered as follows: Decimal: [ TBD by IANA at time of registration ] Name: mplslsrextstdMIB Description: MPLS LSR Extension MIB References: [ RFC-to-be ] Fourth, also in the SMI Network Management MGMT Codes Internet-standard MIBsubregistry of the Network Management Parameters registry located at: http://www.iana.org/assignments/smi-numbers a new MIB will be registered as follows: Decimal: [ TBD by IANA at time of registration ] Name: mplsteextstdMIB Description: MPLS Tunnel Extension MIB References: [ RFC-to-be ] IANA understands these four requests to be the only actions required of IANA upon approval of this document. Comment: IANA understands that the authors intended to obtain four *different" values for the new requested MPLS MIB Module OIDs as per this draft. However the whole document mentioned one single place holder 'xxx' and another single place holder 'OID' in the IANA considerations section specifically. Do the authors want to consider four different placeholders for different values? For example, use of TBD1, TBD2, etc. Please note that IANA does not require how you like to write your document. Note: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed. Please note that IANA cannot reserve specific values. However, early allocation is available for some types of registrations. For more information, please see RFC 7120. |
2014-12-08
|
09 | Adrian Farrel | IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead |
2014-12-08
|
09 | Adrian Farrel | Ballot approval text was generated |
2014-12-08
|
09 | Adrian Farrel | Ballot has been issued |
2014-12-08
|
09 | Adrian Farrel | [Ballot Position Update] New position, Yes, has been recorded for Adrian Farrel |
2014-12-08
|
09 | Adrian Farrel | Created "Approve" ballot |
2014-12-08
|
09 | Adrian Farrel | Placed on agenda for telechat - 2014-12-18 |
2014-12-08
|
09 | (System) | IESG state changed to Waiting for AD Go-Ahead from In Last Call |
2014-12-01
|
09 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Niclas Comstedt |
2014-12-01
|
09 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Niclas Comstedt |
2014-11-28
|
09 | Jean Mahoney | Request for Last Call review by GENART is assigned to Elwyn Davies |
2014-11-28
|
09 | Jean Mahoney | Request for Last Call review by GENART is assigned to Elwyn Davies |
2014-11-27
|
09 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Klaas Wierenga |
2014-11-27
|
09 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Klaas Wierenga |
2014-11-24
|
09 | Amy Vezza | IANA Review state changed to IANA - Review Needed |
2014-11-24
|
09 | Amy Vezza | The following Last Call announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: ietf@ietf.org Sender: Subject: Last Call: (MPLS-TP Traffic Engineering (TE) Management … The following Last Call announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: ietf@ietf.org Sender: Subject: Last Call: (MPLS-TP Traffic Engineering (TE) Management Information Base (MIB)) to Proposed Standard The IESG has received a request from the Multiprotocol Label Switching WG (mpls) to consider the following document: - 'MPLS-TP Traffic Engineering (TE) Management Information Base (MIB)' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2014-12-08. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes additional managed objects of Tunnels, Identifiers, Label Switching Router and Textual conventions to support Multiprotocol Label Switching (MPLS) MIB modules for transport networks. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-te-mib/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-te-mib/ballot/ No IPR declarations have been submitted directly on this I-D. |
2014-11-24
|
09 | Amy Vezza | IESG state changed to In Last Call from Last Call Requested |
2014-11-23
|
09 | Adrian Farrel | Last call announcement was changed |
2014-11-23
|
09 | Adrian Farrel | Last call was requested |
2014-11-23
|
09 | Adrian Farrel | Ballot approval text was generated |
2014-11-23
|
09 | Adrian Farrel | IESG state changed to Last Call Requested from AD Evaluation |
2014-11-23
|
09 | Adrian Farrel | Last call announcement was changed |
2014-11-23
|
09 | Adrian Farrel | Last call announcement was generated |
2014-11-23
|
09 | Adrian Farrel | Last call announcement was generated |
2014-11-23
|
09 | Adrian Farrel | Ballot writeup was changed |
2014-11-23
|
09 | Adrian Farrel | Shepherd write-up related to version -09 ============================ As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are … Shepherd write-up related to version -09 ============================ As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated 23 September 2014. The MPLS Working Group request that MPLS-TP Traffic Engineering (TE) Management Information Base (MIB) draft-ietf-mpls-tp-te-mib-09 is published as a RFC on the standards track (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? We reqeust: Type of RFC: Proposed Standard This is a MIB module and needs to be on the standards track, since it specifies new Protocol Elements. The Document Header says: Standards Track. (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 The document defines a portion of the MIB for use with network management protocols, and describes managed objects for Tunnels, Identifiers, Label Switching Router and Textual conventions for MPLS-TP. These MIB modules extend the existing MPLS MIB objects for both MPLS and MPLS-TP operations, because of this the MPLS-TP name is not included in the MIB module names. The existing MPLS-TE MIB [RFC3812] and the GMPLS-TE MIB [RFC4802] do not support the transport network requirements of NON-IP based management and static bidirectional tunnels. The MIB modules defined in draft-ietf-mpls-tp-te-mib should be used in conjunction with [RFC3812] and its companion document [RFC3813] for MPLS-TP tunnel configuration and management. 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 has been no such rough consensus decisions. Document Quality We know of several implementations of the MIB module. There are significant number of vendors that either has or will implement the MIB module. Personnel Young Lee is the Document Shepherd. Adrian Farrel 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. The Document Shepherd has reviewed the document after the current version has been uploaded (v.09) and believed that the document is ready to be forwarded to the IESG. However it should be noted that the Document Shepherd is not an MIB expert, the real detailed review has been performed by Joan Cucchiara, both in the MPLS-RT review and during wglc (as a repreentative) for the MIB Doctors. This version 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 such 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 reviews performed by the working group and the MIB doctors are what is needed. (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 such 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. Each author has confirmed on the mpls mailing list that they are unaware of any IPR that relates to this document. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. There are no IPR disclosures against this document. (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 working group supports this document. (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 such conflicts or discontent. (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. The document passes the not-check clean. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. The document has been reviewed by and discussed with the MIB Doctors. (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? All the normative references are to existing RFCs. (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 - no downward 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. No such changes to other RFCs. (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 IANA section is well and clearly written, all the registries are clearly identified. (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. No new IANA registries, no new future expert reviews needed. (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. The Shepherd has not personally verified the MIB definitions. The authors confirmed that the MIB module has been compiled and verified. Shepherd write-up related to version -07: =========================== This version of the write-up is kept for historical reasons, but should not necessarily be considered by the IESG, As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated 24 February 2012. The MPLS Working Group request that MPLS-TP Traffic Engineering (TE) Management Information Base (MIB) draft-ietf-mpls-tp-te-mib-07 Is published as a RFC on the standards track (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? We reqeust: Type of RFC: Proposed Standard This is a MIB module and needs to be on the standards track, since it specifies new Protocol Elements. The Document Header says: Standards Track. (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 The document defines a portion of the MIB for use with network management protocols, and describes managed objects for Tunnels, Identifiers, Label Switching Router and Textual conventions for MPLS-TP. These MIB modules extend the existing MPLS MIB objects for both MPLS and MPLS-TP operations, because of this the MPLS-TP name is not included in the MIB module names. The existing MPLS-TE MIB [RFC3812] and the GMPLS-TE MIB [RFC4802] do not support the transport network requirements of NON-IP based management and static bidirectional tunnels. The MIB modules defined in draft-ietf-mpls-tp-te-mib should be used in conjunction with [RFC3812] and its companion document [RFC3813] for MPLS-TP tunnel configuration and management. 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 has been no such rough consensus decisions. 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? We know of several implementations of the MIB module. There are significant number of vendors that either has or will implement the MIB module. Personnel Who is the Document Shepherd? Who is the Responsible Area Director? Loa Andersson is the Document Shepherd. Adrian Farrel 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. The Document Shepherd has review the document priori to the poll to make it a working document and prior to the working group last call. However it should be noted that the Document Shepherd is not an MIB expert, the real detailed review has been performed by Joan Cucchiara, both in the MPLS-RT review and during wglc (as a repreentative) for the MIB Doctors. This version 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 such 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 reviews performed by the working group and the MIB doctors are what is needed. (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 such 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. Each author has confirmed on the mpls mailing list that they are unaware of any IPR that relates to this document. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. There are no IPR disclosures against this document. (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 working group supports this document. (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 such conflicts or discontent. (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. The document passes the not-check clean. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. The document has been reviewed by and discussed with the MIB Doctors. (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? All the normative references are to existing RFCs. (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 - no downward 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. No such changes to other RFCs. (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 IANA section is well and clearly written, all the registries are clearly identified. (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. No new IANA registries, no new future expert reviews needed. (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. The Shepherd has not personally verified the MIB definitions. The authors confirmed that the MIB module has been compiled and verified. |
2014-11-23
|
09 | Adrian Farrel | IESG state changed to AD Evaluation from Publication Requested |
2014-10-28
|
09 | Loa Andersson | Shepherd write-up related to version -09 ============================ As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are … Shepherd write-up related to version -09 ============================ As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated 23 September 2014. The MPLS Working Group request that MPLS-TP Traffic Engineering (TE) Management Information Base (MIB) draft-ietf-mpls-tp-te-mib-09 Is published as a RFC on the standards track (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? We reqeust: Type of RFC: Proposed Standard This is a MIB module and needs to be on the standards track, since it specifies new Protocol Elements. The Document Header says: Standards Track. (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 The document defines a portion of the MIB for use with network management protocols, and describes managed objects for Tunnels, Identifiers, Label Switching Router and Textual conventions for MPLS-TP. These MIB modules extend the existing MPLS MIB objects for both MPLS and MPLS-TP operations, because of this the MPLS-TP name is not included in the MIB module names. The existing MPLS-TE MIB [RFC3812] and the GMPLS-TE MIB [RFC4802] do not support the transport network requirements of NON-IP based management and static bidirectional tunnels. The MIB modules defined in draft-ietf-mpls-tp-te-mib should be used in conjunction with [RFC3812] and its companion document [RFC3813] for MPLS-TP tunnel configuration and management. 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 has been no such rough consensus decisions. 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? We know of several implementations of the MIB module. There are significant number of vendors that either has or will implement the MIB module. Personnel Who is the Document Shepherd? Who is the Responsible Area Director? Young Lee is the Document Shepherd. Adrian Farrel 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. The Document Shepherd has reviewed the document after the current version has been uploaded (v.09) and believed that the document is ready to be forwarded to the IESG. However it should be noted that the Document Shepherd is not an MIB expert, the real detailed review has been performed by Joan Cucchiara, both in the MPLS-RT review and during wglc (as a repreentative) for the MIB Doctors. This version 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 such 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 reviews performed by the working group and the MIB doctors are what is needed. (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 such 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. Each author has confirmed on the mpls mailing list that they are unaware of any IPR that relates to this document. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. There are no IPR disclosures against this document. (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 working group supports this document. (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 such conflicts or discontent. (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. The document passes the not-check clean. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. The document has been reviewed by and discussed with the MIB Doctors. (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? All the normative references are to existing RFCs. (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 - no downward 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. No such changes to other RFCs. (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 IANA section is well and clearly written, all the registries are clearly identified. (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. No new IANA registries, no new future expert reviews needed. (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. The Shepherd has not personally verified the MIB definitions. The authors confirmed that the MIB module has been compiled and verified. Shepherd write-up related to version -07: =========================== This version of the write-up is kept for historical reasons, but should not necessarily be considered by the IESG, As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated 24 February 2012. The MPLS Working Group request that MPLS-TP Traffic Engineering (TE) Management Information Base (MIB) draft-ietf-mpls-tp-te-mib-07 Is published as a RFC on the standards track (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? We reqeust: Type of RFC: Proposed Standard This is a MIB module and needs to be on the standards track, since it specifies new Protocol Elements. The Document Header says: Standards Track. (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 The document defines a portion of the MIB for use with network management protocols, and describes managed objects for Tunnels, Identifiers, Label Switching Router and Textual conventions for MPLS-TP. These MIB modules extend the existing MPLS MIB objects for both MPLS and MPLS-TP operations, because of this the MPLS-TP name is not included in the MIB module names. The existing MPLS-TE MIB [RFC3812] and the GMPLS-TE MIB [RFC4802] do not support the transport network requirements of NON-IP based management and static bidirectional tunnels. The MIB modules defined in draft-ietf-mpls-tp-te-mib should be used in conjunction with [RFC3812] and its companion document [RFC3813] for MPLS-TP tunnel configuration and management. 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 has been no such rough consensus decisions. 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? We know of several implementations of the MIB module. There are significant number of vendors that either has or will implement the MIB module. Personnel Who is the Document Shepherd? Who is the Responsible Area Director? Loa Andersson is the Document Shepherd. Adrian Farrel 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. The Document Shepherd has review the document priori to the poll to make it a working document and prior to the working group last call. However it should be noted that the Document Shepherd is not an MIB expert, the real detailed review has been performed by Joan Cucchiara, both in the MPLS-RT review and during wglc (as a repreentative) for the MIB Doctors. This version 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 such 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 reviews performed by the working group and the MIB doctors are what is needed. (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 such 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. Each author has confirmed on the mpls mailing list that they are unaware of any IPR that relates to this document. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. There are no IPR disclosures against this document. (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 working group supports this document. (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 such conflicts or discontent. (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. The document passes the not-check clean. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. The document has been reviewed by and discussed with the MIB Doctors. (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? All the normative references are to existing RFCs. (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 - no downward 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. No such changes to other RFCs. (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 IANA section is well and clearly written, all the registries are clearly identified. (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. No new IANA registries, no new future expert reviews needed. (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. The Shepherd has not personally verified the MIB definitions. The authors confirmed that the MIB module has been compiled and verified. |
2014-10-28
|
09 | Loa Andersson | IETF WG state changed to Submitted to IESG for Publication from WG Document |
2014-10-28
|
09 | Loa Andersson | IESG state changed to Publication Requested from AD is watching |
2014-10-26
|
09 | Loa Andersson | Notification list changed to mpls-chairs@tools.ietf.org, draft-ietf-mpls-tp-te-mib@tools.ietf.org, "Young Lee" <youngleetx@yahoo.com> from mpls-chairs@tools.ietf.org, draft-ietf-mpls-tp-te-mib@tools.ietf.org |
2014-10-26
|
09 | Loa Andersson | Document shepherd changed to Young Lee |
2014-10-24
|
09 | Loa Andersson | Shepherd write-up related to version -09 ============================ As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are … Shepherd write-up related to version -09 ============================ As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated 23 September 2014. The MPLS Working Group request that MPLS-TP Traffic Engineering (TE) Management Information Base (MIB) draft-ietf-mpls-tp-te-mib-09 Is published as a RFC on the standards track (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? We reqeust: Type of RFC: Proposed Standard This is a MIB module and needs to be on the standards track, since it specifies new Protocol Elements. The Document Header says: Standards Track. (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 The document defines a portion of the MIB for use with network management protocols, and describes managed objects for Tunnels, Identifiers, Label Switching Router and Textual conventions for MPLS-TP. These MIB modules extend the existing MPLS MIB objects for both MPLS and MPLS-TP operations, because of this the MPLS-TP name is not included in the MIB module names. The existing MPLS-TE MIB [RFC3812] and the GMPLS-TE MIB [RFC4802] do not support the transport network requirements of NON-IP based management and static bidirectional tunnels. The MIB modules defined in draft-ietf-mpls-tp-te-mib should be used in conjunction with [RFC3812] and its companion document [RFC3813] for MPLS-TP tunnel configuration and management. 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 has been no such rough consensus decisions. 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? We know of several implementations of the MIB module. There are significant number of vendors that either has or will implement the MIB module. Personnel Who is the Document Shepherd? Who is the Responsible Area Director? Young Lee is the Document Shepherd. Adrian Farrel 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. The Document Shepherd has reviewed the document after the current version has been uploaded (v.09) and believed that the document is ready to be forwarded to the IESG. However it should be noted that the Document Shepherd is not an MIB expert, the real detailed review has been performed by Joan Cucchiara, both in the MPLS-RT review and during wglc (as a repreentative) for the MIB Doctors. This version 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 such 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 reviews performed by the working group and the MIB doctors are what is needed. (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 such 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. Each author has confirmed on the mpls mailing list that they are unaware of any IPR that relates to this document. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. There are no IPR disclosures against this document. (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 working group supports this document. (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 such conflicts or discontent. (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. The document passes the not-check clean. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. The document has been reviewed by and discussed with the MIB Doctors. (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? All the normative references are to existing RFCs. (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 - no downward 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. No such changes to other RFCs. (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 IANA section is well and clearly written, all the registries are clearly identified. (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. No new IANA registries, no new future expert reviews needed. (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. The Shepherd has not personally verified the MIB definitions. The authors confirmed that the MIB module has been compiled and verified. Shepherd write-up related to version -07: =========================== This version of the write-up is kept for historical reasons, but should not necessarily be considered by the IESG, As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated 24 February 2012. The MPLS Working Group request that MPLS-TP Traffic Engineering (TE) Management Information Base (MIB) draft-ietf-mpls-tp-te-mib-07 Is published as a RFC on the standards track (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? We reqeust: Type of RFC: Proposed Standard This is a MIB module and needs to be on the standards track, since it specifies new Protocol Elements. The Document Header says: Standards Track. (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 The document defines a portion of the MIB for use with network management protocols, and describes managed objects for Tunnels, Identifiers, Label Switching Router and Textual conventions for MPLS-TP. These MIB modules extend the existing MPLS MIB objects for both MPLS and MPLS-TP operations, because of this the MPLS-TP name is not included in the MIB module names. The existing MPLS-TE MIB [RFC3812] and the GMPLS-TE MIB [RFC4802] do not support the transport network requirements of NON-IP based management and static bidirectional tunnels. The MIB modules defined in draft-ietf-mpls-tp-te-mib should be used in conjunction with [RFC3812] and its companion document [RFC3813] for MPLS-TP tunnel configuration and management. 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 has been no such rough consensus decisions. 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? We know of several implementations of the MIB module. There are significant number of vendors that either has or will implement the MIB module. Personnel Who is the Document Shepherd? Who is the Responsible Area Director? Loa Andersson is the Document Shepherd. Adrian Farrel 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. The Document Shepherd has review the document priori to the poll to make it a working document and prior to the working group last call. However it should be noted that the Document Shepherd is not an MIB expert, the real detailed review has been performed by Joan Cucchiara, both in the MPLS-RT review and during wglc (as a repreentative) for the MIB Doctors. This version 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 such 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 reviews performed by the working group and the MIB doctors are what is needed. (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 such 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. Each author has confirmed on the mpls mailing list that they are unaware of any IPR that relates to this document. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. There are no IPR disclosures against this document. (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 working group supports this document. (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 such conflicts or discontent. (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. The document passes the not-check clean. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. The document has been reviewed by and discussed with the MIB Doctors. (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? All the normative references are to existing RFCs. (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 - no downward 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. No such changes to other RFCs. (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 IANA section is well and clearly written, all the registries are clearly identified. (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. No new IANA registries, no new future expert reviews needed. (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. The Shepherd has not personally verified the MIB definitions. The authors confirmed that the MIB module has been compiled and verified. |
2014-10-06
|
09 | Adrian Farrel | Document shepherd changed to Young Lee |
2014-10-06
|
09 | Adrian Farrel | Tags Revised I-D Needed - Issue raised by AD, Revised I-D Needed - Issue raised by WG cleared. |
2014-09-22
|
09 | Venkatesan Mahalingam | New version available: draft-ietf-mpls-tp-te-mib-09.txt |
2014-08-21
|
08 | Loa Andersson | Document shepherd changed to Young Lee |
2014-05-06
|
08 | Venkatesan Mahalingam | New version available: draft-ietf-mpls-tp-te-mib-08.txt |
2014-02-01
|
07 | Adrian Farrel | Returned to WG on request of WG chair for more work. |
2014-02-01
|
07 | Adrian Farrel | Tags Revised I-D Needed - Issue raised by AD, Revised I-D Needed - Issue raised by WG set. |
2014-02-01
|
07 | Adrian Farrel | IETF WG state changed to WG Document from Submitted to IESG for Publication |
2014-02-01
|
07 | Adrian Farrel | IESG state changed to AD is watching from AD Evaluation::Revised I-D Needed |
2013-12-28
|
07 | Adrian Farrel | AD Review ======== Hello authors, I have performed my usual AD review of your draft on receipt of the publication request. As you can see … AD Review ======== Hello authors, I have performed my usual AD review of your draft on receipt of the publication request. As you can see below, it has generated quite a few comments and as a result I have placed the document into "Revised I-D Needed" state. I have tried to flag where I think my comment might be a function of "I wouldn't have done it like this" and I am open to discussion of all of the points I have raised. Thanks for your work. Adrian === I think Tom may want to change his coordinates. --- It would be nice if someone could do a pass on this document for English and format. It is not essential because the RFC Editor will resolve these issues, but it is wise because the fewer changes the RFC Editor makes, the less chance there is of an accidental error. --- You have the RFC 2119 boilerplate present twice. --- What does it mean to use RFC 2119 language in the examples in Section 9? --- I see a contradiction in In particular, it describes managed objects of Tunnels, Identifiers, Label Switching Router and Textual conventions for Multiprotocol Label Switching (MPLS) based Transport Profile (TP). These MIB modules extend the existing MPLS MIB objects for both MPLS-TP and Non-MPLS-TP operations, so the MPLS-TP name is not included in the MIB module name. Either the extensions are for MPLS-TP or they are not. Your second sentence says they are for more general applicability, and I agree with that. So why does the first sentence and the document title talk about MPLS-TP? --- I think the Introduction would be made more useful and relevant if it described the purpose and content of this document. Currently it says what the existing documents don't do (although even that is pretty vague). The existing Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Management Information Base (MIB) [RFC3812] and Generalized Multiprotocol Label Switching (GMPLS) Traffic Engineering Management Information Base [RFC4802] do not support the transport network requirements of NON-IP based management and static bidirectional tunnels. There is also an implication here that this MIB module supports non-IP based management. I looked but didn't see any description of how to run SNMP in the absence of IP. It goes on... These MIB modules should be used in conjunction with [RFC3812] and companion document [RFC3813] for MPLS-TP tunnel configuration and management. What is an "MPLS-TP tunnel"? --- Section 4 might have been an opportunity to provide the information I think is missing from the Introduction. But unfortunately it repeats some of the text form the Introduction and then gives a very scanty description of the purpose of the work. Here, however, I find the text As the existing MPLS- TE-STD-MIB is not sufficient to capture all the characteristics of the tunnels, enhancing the MIB to support MPLS TP tunnels is required. As most of the attributes of MPLS Traffic Engineering tunnels are also applicable to MPLS-TP tunnels, it is optimal to re-use the existing MIB definition instead of a new MIB. This doesn't explain why you don't leverage GMPLS-TE-STD-MIB and GMPLS-LSR-STD-MIB. Naively, it seems that the co-routed case is already handled, and the associated case can be handled with just one cross- pointer (the association) between the forward and reverse entries in MPLS-TE-STD-MIB. I hate to say "I would not have done it this way", but you seem to be introducing a lot of complexity. --- I think the boilerplate in Section 2 is supposed to have the references in square brackets as citations. --- Not sure you need all of your acronyms GMPLS is only used in the same place as it is expanded. IP is surely too well known ITU and ITU-T are "well-known" according to the RFC editor MIB is "well-known" according to the RFC editor MPLS is "well-known" according to the RFC editor OSPF is "well-known" according to the RFC editor --- Why does section 5 only discuss MPLS-TE-EXT-STD-MIB? What about the other MIB modules defined in this document? --- Why does section 6 only discuss MPLS-TE-EXT-STD-MIB? What about the other MIB modules defined in this document? --- Section 6 introduces 5 new tables. Section 8 shows a figure containing only 3 of the new tables. Something missing? --- Section 6 is titled 6. Brief description of MPLS-TE-EXT-STD-MIB Objects but I think it really only describes the tables. --- Section 6.1 has Each ICC_Operator_ID::Node_ID or Global_ID::Node_ID contains one unique entry in the table representing a node. What does this containing relationship mean? --- Section 6.1 As the regular TE tunnels use IP address as LSR ID, the local identifier should be below the first valid IP address, which is 16777216[1.0.0.0]. What does "should" mean in this context? --- There is no clear mention of the dependency on MPLS-TC-STD-MIB. I think this should be added to Section 7. It is probably best to not attempt to add this to the figure. Instead you could add text to say: Note that all of the MB modules shown in the figure also have a dependency on MPLS-TC-STD-MIB. --- I think you could usefully clarify the meanings of "extends" versus "augments" versus "sparse augments". In 6.4 you have: mplsTunnelExtTable extends the mplsTunnelTable In 6.5 you have: This table sparse augments the mplsTunnelTable In Section 7 you have: MPLS-TE-STD-MIB [RFC3812] is extended by MPLS-TE-EXT-STD-MIB MIB module for associating the reverse direction tunnel information. Note that the nature of the 'extends' relationship is a sparse augmentation so that the entry in the mplsTunnelExtTable has the same index values as the in the mplsTunnelTable. MPLS-LSR-STD-MIB [RFC3813] is extended by MPLS-LSR-EXT-STD-MIB MIB module for pointing back to the tunnel entry for easy tunnel access from XC entry. Note that the nature of the 'extends' relationship is a sparse augmentation so that the entry in the mplsXCExtTable has the same index values as the in the mplsXCTable. I think that all of uses of "table A extends table B" mean "sparse augments" so I suggest you just use the latter language and avoid confusion and the need to explain the meaning of "extends". --- There is an awful lot of write-access in these MIB modules. Haven't we moved on from 2004 to a view that SNMP SETs on this type of complex data are not useful? Why did the working group decide that creatable/writeable objects were valuable? --- Section 9 would be a lot clearer if it began with a description of the LSP being "configured". --- Entries in MplsTunnelExtNodeConfigEntry are indexed by mplsTunnelExtNodeConfigLocalId. A combination of [Global_ID and Node_ID] or [CC::ICC and Node_ID] has a unique entry. Suppose I have a new LSP in my hand. It has [CC=AB, ICC=123456]. I want to create an entry or use an existing one. Do I have to read every entry in the table to find out if one already exists? --- The first and only mention of pseudowires is in the Description clause of MPLS-TC-EXT-STD-MIB. This either means you are missing lots of explanations and examples, or that the Description clause (and terminology section) should have PW removed. --- Shouldn't the description and definition of MplsGlobalId be more proscriptive and precise? The Description says... the Global_ID can contain the 2-octet or 4-octet value of the operator's Autonomous System Number (ASN). I.e. "can". Also... It is expected that the Global_ID will be derived from the globally unique ASN of the autonomous system hosting the PEs containing the actual AIIs. I.e. "expected". And... When the Global_ID is derived from a 2-octet AS number, the two high-order octets of this 4-octet identifier MUST be set to zero. I.e. "derived from". And finally a "MUST" but still "derived from" A non-zero Global_ID MUST be derived from an ASN owned by the operator." But the Syntax is given as... SYNTAX OCTET STRING (SIZE (4)) ...and since the mechanism for derivation is not explained and there is no limitation stated that the characters in the Octet String be digits, I can think of many ways to "derive" the Global ID. Furthermore, in... When the Global_ID is derived from a 2-octet AS number, the two high-order octets of this 4-octet identifier MUST be set to zero. ... Does "set to zero" mean set to 0x00 or set to 0x30? --- Why is it necessary to allow a zero length of MplsIccId when you don't allow a zero length of MplsGlobalId or MplsCcId. I don't see why the ICC is special in this respect. --- In MplsIccId what does this mean? Alphabetic characters in the ICC SHOULD be represented with upper case letters. How does that change the implementation? I think it means that it has to accept upper and lower case characters. Furthermore, what might be signaled? I suggest you should be consistent with T.50 for the CC and ICC character sets. --- MplsNodeId ::= TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "The Node_ID is assigned within the scope of the Global_ID/ICC_Operator_ID. The value 0(or 0.0.0.0 in dotted decimal notation) is reserved and MUST NOT be used. When IPv4 addresses are in use, the value of this object can be derived from the LSR's IPv4 loop back address. When IPv6 addresses are in use, the value of this object can be a 32-bit value unique within the scope of a Global_ID. Is the mention of 0.0.0.0 meaningful? The display hint is "d" and the value might just be a 32 bit number for the IPv6 case or for the non-IP case. --- MplsNodeId ::= TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "The Node_ID is assigned within the scope of the Global_ID/ICC_Operator_ID. The value 0(or 0.0.0.0 in dotted decimal notation) is reserved and MUST NOT be used. SYNTAX Unsigned32 (0|1..4294967295) If zero MUST NOT be used, why is it allowed in the Syntax? What is it reserved for? --- What is the point of defining -- notifications mplsIdNotifications OBJECT IDENTIFIER ::= { mplsIdStdMIB 0 } if you don't use it? --- I am slightly bothered that MPLS-ID-STD-MIB includes TCs with wider applicability and scalar objects. I suspect that the CC and ICC TCs could be used more generally in the IETF. I suspect that many uses of these TCs would not be interested in the scalar MPLS objects, or that those scalar objects are not limited to MPLS. And I wonder why the scalars are not in the MPLS-LSR-EXT-STD-MIB module as they, like the LSR ID, apply to the local node. --- The objects in MPLS-ID-STD-MIB are read-write (not read-create). Taking one as an example, you have... mplsIdGlobalId OBJECT-TYPE SYNTAX MplsGlobalId MAX-ACCESS read-write STATUS current DESCRIPTION "This object allows the operator to assign a unique operator identifier also called MPLS-TP Global_ID. If this value is used in mplsTunnelExtNodeConfigGlobalId for mapping Global_ID::Node_ID with the local identifier then this object value SHOULD NOT be changed." ::= { mplsIdObjects 1 } Since the object is not read-create, we can assume that it is pre- populated by the node (from configuration). The meaning of "SHOULD NOT be changed" is then in conflict with the writeability of the object. Furthermore, "SHOULD NOT" is not "MUST NOT" so I think you need to explain the circumstances under which it can be changed - that probably really means explaining the consequences if it is changed. And anyway, I think you mean "...SET operations on this object SHOULD be rejected by the node with the return code foo" since the management agent is unlikely to know that the condition applies. But really... Why are any of these objects writeable? --- mplsIdNodeId OBJECT-TYPE SYNTAX MplsNodeId MAX-ACCESS read-write STATUS current DESCRIPTION "This object allows the operator or service provider to assign a unique MPLS-TP Node_ID. Why can operators and service providers assign Node_IDs, but only operators assign Global_IDs in mplsIdGlobalId? --- mplsIdCc OBJECT-TYPE SYNTAX MplsCcId MAX-ACCESS read-write STATUS current DESCRIPTION "This object allows the operator or service provider to assign a unique Country Code (CC). Global uniqueness is assured by concatenating the ICC with a Country Code (CC). "...assign a unique CC" to what? "Global uniqueness" of what? --- mplsIdIcc OBJECT-TYPE SYNTAX MplsIccId MAX-ACCESS read-write STATUS current DESCRIPTION "This object allows the operator or service provider to assign a unique MPLS-TP ITU-T Carrier Code (ICC) to a network. I don't think so! This object is going to be realised on a node, not "on a network". Setting this object will not make a change to the ICC applied to the rest of the network. --- mplsIdModuleFullCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "Compliance statement for agents that provide full support the MPLS-ID-STD-MIB module." MODULE -- this module -- The mandatory group has to be implemented by all -- LSRs that originate/terminate MPLS-TP paths. This may be true, but it implies that other nodes do not need to support this module. Surely it is needed for MPLS-TP OAM support. --- The definition of mplsIdModuleReadOnlyCompliance seems to imply that an IP-capable node MUST support mplsIdIcc and mplsIdCc. Why is that? --- Odd, but maybe not important, that the objects in mplsIdModuleReadOnlyCompliance and mplsIdScalarGroup are not in the same order as those in mplsIdObjects. --- I don't see why you need mplsXCExtTable. I think there may be some confusion about how the TE MIB and LSR MIB are related. In 3812 and 3813 it is entirely deliberate that there is no back pointer from the XC to the tunnel. The point being that you do not look up an XC and then try to find out which tunnel it belongs to. Perhaps you were looking at how to associate the forward and reverse XCs, but I note (in your example in 9.2) that you have used the same XC index for the forward and reverse XCs (which is the right way to do it). You should note that the extensions in 4803 give directions to the segments to support this and allow you to distinguish between the forward XC and the reverse XC. You should also note that mplsTunnelXCPointer gives a pointer from tunnel to XC, so all that is missing is the association between forward and reverse tunnels. I would think that the correct way is with an extension to the mplsTunnelTable to point to "associated tunnels" in a generic way that supports all association types not just this one specific association. So I am left wondering what is the purpose of mplsXCExtTable Ah, is it the case that you think the forward and reverse tunnels and their corresponding XCs might be set up *before* you know that they are associated? I don't think this happens. To try to clarify this, I think you have... Tunnel1-->XC1<-------------- A | | | | | |-->InSeg1 | | | |-->OutSeg1 | | v | ------XCext1 | | | v | Tunnel2-->XC2 | A | | | | | |-->InSeg2 | | | |-->OutSeg2 | | v | ------XCext2------------ And it might be useful to show this figure somewhere. But your example doesn't do this. What I was expecting is: Tunnel1-->XC1 A A | | | |-->InSeg1 | | |-->OutSeg1 V V Tunnel2-->XC2 | |-->InSeg2 |-->OutSeg2 Where the only thing that is not already in the existing MIB modules is the pointers associating Tunnel1 and Tunnel2. Noting that for a bidir tunnel what you currently have (in the existing MIB modules) is: Tunnel1-->XC1 A | | |-->InSeg1 | |-->OutSeg1 V XC2 | |-->InSeg2 |-->OutSeg2 And if you insist on knowing the tunnel that applies to an XC (which, as you point out would be read-only information) then your extension table only needs a pointer from XC to tunnel to give: Tunnel1<->XC1 A A | | | |-->InSeg1 | | |-->OutSeg1 V V Tunnel2<->XC2 | |-->InSeg2 |-->OutSeg2 I can't decide how much of this is "I wouldn't have done it this way" and how much is broken. You are certainly failing to take advantage of the fact that all related XCs have the same XCindex value. --- Assuming that you continue with the mplsXCExtTable, what happens when the entry in mplsXCTable corresponding to mplsXCExtOppositeDirXCPtr is deleted? --- When I create a new entry in mplsTunnelExtNodeConfigTable, how do I know what is a suitable value for mplsTunnelExtNodeConfigLocalId? You probably need an mplsTunnelExtNodeConfigLocalIdNextFree scalar. --- The Description clause of mplsTunnelExtOppositeDirPtr is pretty hard to read. It might be easier if used the term "associated bidirectional". "This object is applicable only for the bidirectional tunnel that has the forward and reverse LSPs in the same tunnel or in the different tunnels. ...is quite confusing. The value of zeroDotZero indicates single tunnel entry is used for bidirectional tunnel setup." Surely it is also used when only one of the two tunnels has been set up. That means that you cannot use the value of zeroDotZero to determine that a single bidirectional tunnel is in use. And this is presumably why you have mplsTunnelExtOppositeDirTnlValid --- I have the same problem understanding the Description of mplsTunnelExtDestTnlIndex "This object is applicable only for the bidirectional tunnel that has the forward and reverse LSPs in the same tunnel or in the different tunnels. --- Why did you need to define mplsTunnelExtReversePerfTable? If you have two associated tunnels then each has its own mplsTunnelPerfEntry. If you have a single bidirectional tunnel then GMPLS-TE-STD-MIB has gmplsTunnelReversePerfTable. --- Section 14 should also mention objects with MAX-ACCESS of read-create. |
2013-12-28
|
07 | Adrian Farrel | State changed to AD Evaluation::Revised I-D Needed from AD Evaluation |
2013-12-10
|
07 | Adrian Farrel | Ballot writeup was changed |
2013-12-10
|
07 | Adrian Farrel | Ballot writeup was generated |
2013-11-29
|
07 | Adrian Farrel | State changed to AD Evaluation from Publication Requested |
2013-11-04
|
07 | Cindy Morgan | Document shepherd changed to Loa Andersson |
2013-11-04
|
07 | Cindy Morgan | As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated … As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated 24 February 2012. The MPLS Working Group request that MPLS-TP Traffic Engineering (TE) Management Information Base (MIB) draft-ietf-mpls-tp-te-mib-07 Is published as a RFC on the standards track (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? We reqeust: Type of RFC: Proposed Standard This is a MIB module and needs to be on the standards track, since it specifies new Protocol Elements. The Document Header says: Standards Track. (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 The document defines a portion of the MIB for use with network management protocols, and describes managed objects for Tunnels, Identifiers, Label Switching Router and Textual conventions for MPLS-TP. These MIB modules extend the existing MPLS MIB objects for both MPLS and MPLS-TP operations, because of this the MPLS-TP name is not included in the MIB module names. The existing MPLS-TE MIB [RFC3812] and the GMPLS-TE MIB [RFC4802] do not support the transport network requirements of NON-IP based management and static bidirectional tunnels. The MIB modules defined in draft-ietf-mpls-tp-te-mib should be used in conjunction with [RFC3812] and its companion document [RFC3813] for MPLS-TP tunnel configuration and management. 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 has been no such rough consensus decisions. 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? We know of several implementations of the MIB module. There are significant number of vendors that either has or will implement the MIB module. Personnel Who is the Document Shepherd? Who is the Responsible Area Director? Loa Andersson is the Document Shepherd. Adrian Farrel 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. The Document Shepherd has review the document priori to the poll to make it a working document and prior to the working group last call. However it should be noted that the Document Shepherd is not an MIB expert, the real detailed review has been performed by Joan Cucchiara, both in the MPLS-RT review and during wglc (as a repreentative) for the MIB Doctors. This version 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 such 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 reviews performed by the working group and the MIB doctors are what is needed. (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 such 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. Each author has confirmed on the mpls mailing list that they are unaware of any IPR that relates to this document. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. There are no IPR disclosures against this document. (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 working group supports this document. (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 such conflicts or discontent. (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. The document passes the not-check clean. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. The document has been reviewed by and discussed with the MIB Doctors. (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? All the normative references are to existing RFCs. (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 - no downward 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. No such changes to other RFCs. (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 IANA section is well and clearly written, all the registries are clearly identified. (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. No new IANA registries, no new future expert reviews needed. (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. The Shepherd has not personally verified the MIB definitions. The authors confirmed that the MIB module has been compiled and verified. |
2013-11-04
|
07 | Cindy Morgan | Changed document writeup |
2013-11-04
|
07 | Loa Andersson | IETF WG state changed to Submitted to IESG for Publication |
2013-11-04
|
07 | Loa Andersson | IESG state changed to Publication Requested |
2013-11-04
|
07 | Loa Andersson | State Change Notice email list changed to mpls-chairs@tools.ietf.org, draft-ietf-mpls-tp-te-mib@tools.ietf.org |
2013-11-04
|
07 | Loa Andersson | Responsible AD changed to Adrian Farrel |
2013-11-04
|
07 | Loa Andersson | Working group state set to Submitted to IESG for Publication |
2013-11-04
|
07 | Loa Andersson | IESG state set to Publication Requested |
2013-11-04
|
07 | Loa Andersson | IESG process started in state Publication Requested |
2013-11-04
|
07 | Loa Andersson | Intended Status changed to Proposed Standard from None |
2013-11-04
|
07 | Loa Andersson | Changed document writeup |
2013-11-04
|
07 | Loa Andersson | IETF WG state changed to WG Consensus: Waiting for Write-Up from Waiting for WG Chair Go-Ahead |
2013-11-04
|
07 | Loa Andersson | Annotation tag Revised I-D Needed - Issue raised by WG cleared. |
2013-11-04
|
07 | Venkatesan Mahalingam | New version available: draft-ietf-mpls-tp-te-mib-07.txt |
2013-10-30
|
06 | Loa Andersson | Changed document writeup |
2013-10-03
|
06 | Loa Andersson | Changed document writeup |
2013-10-03
|
06 | Loa Andersson | Changed document writeup |
2013-10-03
|
06 | Loa Andersson | Changed document writeup |
2013-10-03
|
06 | Loa Andersson | Changed document writeup |
2013-10-03
|
06 | Loa Andersson | Changed document writeup |
2013-10-03
|
06 | Loa Andersson | Changed document writeup |
2013-10-03
|
06 | Loa Andersson | Changed document writeup |
2013-10-01
|
06 | Loa Andersson | Implementation poll running |
2013-10-01
|
06 | Loa Andersson | IETF WG state changed to Waiting for WG Chair Go-Ahead from Waiting for WG Chair Go-Ahead |
2013-10-01
|
06 | Loa Andersson | IETF WG state changed to Waiting for WG Chair Go-Ahead from Waiting for WG Chair Go-Ahead |
2013-09-30
|
06 | Loa Andersson | Changed document writeup |
2013-09-07
|
06 | Loa Andersson | Document shepherd changed to Loa Andersson |
2013-05-08
|
06 | Venkatesan Mahalingam | New version available: draft-ietf-mpls-tp-te-mib-06.txt |
2013-04-12
|
05 | Loa Andersson | Annotation tag Revised I-D Needed - Issue raised by WG set. Annotation tag Awaiting Expert Review/Resolution of Issues Raised cleared. |
2013-04-12
|
05 | Loa Andersson | IETF WG state changed to Waiting for WG Chair Go-Ahead from WG Document |
2013-04-12
|
05 | Loa Andersson | Annotation tag Awaiting Expert Review/Resolution of Issues Raised set. |
2013-01-14
|
05 | Loa Andersson | Document is in MIB-doctor review. |
2013-01-14
|
05 | Venkatesan Mahalingam | New version available: draft-ietf-mpls-tp-te-mib-05.txt |
2012-07-16
|
04 | Venkatesan Mahalingam | New version available: draft-ietf-mpls-tp-te-mib-04.txt |
2012-04-13
|
03 | Venkatesan Mahalingam | New version available: draft-ietf-mpls-tp-te-mib-03.txt |
2012-03-12
|
02 | Venkatesan Mahalingam | New version available: draft-ietf-mpls-tp-te-mib-02.txt |
2011-12-15
|
01 | (System) | New version available: draft-ietf-mpls-tp-te-mib-01.txt |
2011-06-17
|
00 | (System) | New version available: draft-ietf-mpls-tp-te-mib-00.txt |