Skip to main content

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