Path Computation Element Communication Protocol (PCEP) Management Information Base (MIB) Module
draft-ietf-pce-pcep-mib-11
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2014-12-19
|
11 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2014-12-15
|
11 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2014-12-01
|
11 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
2014-11-11
|
11 | Gunter Van de Velde | Closed request for Last Call review by OPSDIR with state 'No Response' |
2014-11-04
|
11 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2014-11-03
|
11 | Cindy Morgan | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2014-11-03
|
11 | (System) | RFC Editor state changed to EDIT |
2014-11-03
|
11 | (System) | Announcement was received by RFC Editor |
2014-11-03
|
11 | (System) | IANA Action state changed to Waiting on RFC Editor from Waiting on Authors |
2014-11-03
|
11 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2014-11-03
|
11 | (System) | IANA Action state changed to In Progress |
2014-11-03
|
11 | Amy Vezza | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
2014-11-03
|
11 | Amy Vezza | IESG has approved the document |
2014-11-03
|
11 | Amy Vezza | Closed "Approve" ballot |
2014-10-30
|
11 | Tero Kivinen | Request for Last Call review by SECDIR Completed: Has Issues. Reviewer: Carl Wallace. |
2014-10-30
|
11 | Cindy Morgan | IESG state changed to Approved-announcement to be sent from IESG Evaluation |
2014-10-30
|
11 | Adrian Farrel | Ballot approval text was generated |
2014-10-30
|
11 | Adrian Farrel | Ballot writeup was changed |
2014-10-30
|
11 | Adrian Farrel | Changed consensus to Yes from Unknown |
2014-10-30
|
11 | Joel Jaeggli | [Ballot Position Update] New position, No Objection, has been recorded for Joel Jaeggli |
2014-10-30
|
11 | Spencer Dawkins | [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins |
2014-10-29
|
11 | Richard Barnes | [Ballot Position Update] New position, No Objection, has been recorded for Richard Barnes |
2014-10-29
|
11 | Ted Lemon | [Ballot Position Update] New position, No Objection, has been recorded for Ted Lemon |
2014-10-29
|
11 | Alissa Cooper | [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper |
2014-10-29
|
11 | Amanda Baber | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2014-10-29
|
11 | Benoît Claise | [Ballot Position Update] New position, No Objection, has been recorded for Benoit Claise |
2014-10-29
|
11 | Martin Stiemerling | [Ballot Position Update] New position, No Objection, has been recorded for Martin Stiemerling |
2014-10-29
|
11 | Pete Resnick | [Ballot comment] Barely a skim. No obvious apps issues. |
2014-10-29
|
11 | Pete Resnick | [Ballot Position Update] New position, No Objection, has been recorded for Pete Resnick |
2014-10-29
|
11 | Jari Arkko | [Ballot Position Update] New position, No Objection, has been recorded for Jari Arkko |
2014-10-28
|
11 | Barry Leiba | [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba |
2014-10-28
|
11 | Peter Yee | Request for Telechat review by GENART Completed: Ready with Nits. Reviewer: Peter Yee. |
2014-10-27
|
11 | Kathleen Moriarty | [Ballot comment] Thanks for the detailed security considerations section. |
2014-10-27
|
11 | Kathleen Moriarty | Ballot comment text updated for Kathleen Moriarty |
2014-10-27
|
11 | Kathleen Moriarty | [Ballot Position Update] New position, No Objection, has been recorded for Kathleen Moriarty |
2014-10-27
|
11 | Alia Atlas | [Ballot Position Update] New position, No Objection, has been recorded for Alia Atlas |
2014-10-24
|
11 | Jonathan Hardwick | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2014-10-24
|
11 | Jonathan Hardwick | New version available: draft-ietf-pce-pcep-mib-11.txt |
2014-10-23
|
10 | Jean Mahoney | Request for Telechat review by GENART is assigned to Peter Yee |
2014-10-23
|
10 | Jean Mahoney | Request for Telechat review by GENART is assigned to Peter Yee |
2014-10-20
|
10 | Brian Haberman | [Ballot comment] I trust the shepherding AD and his review of this document. |
2014-10-20
|
10 | Brian Haberman | [Ballot Position Update] New position, No Objection, has been recorded for Brian Haberman |
2014-10-13
|
10 | Adrian Farrel | Ballot has been issued |
2014-10-13
|
10 | Adrian Farrel | [Ballot Position Update] New position, Yes, has been recorded for Adrian Farrel |
2014-10-13
|
10 | Adrian Farrel | Created "Approve" ballot |
2014-10-13
|
10 | Adrian Farrel | IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead |
2014-10-13
|
10 | Adrian Farrel | Placed on agenda for telechat - 2014-10-30 |
2014-10-13
|
10 | (System) | IESG state changed to Waiting for AD Go-Ahead from In Last Call |
2014-10-10
|
10 | (System) | IANA Review state changed to IANA OK - Actions Needed from IANA - Review Needed |
2014-10-10
|
10 | Amanda Baber | IESG/Authors/WG Chairs: IANA has reviewed draft-ietf-pce-pcep-mib-10. Please report any inaccuracies and respond to any questions as soon as possible. IANA's reviewer has the following comments/questions: … IESG/Authors/WG Chairs: IANA has reviewed draft-ietf-pce-pcep-mib-10. Please report any inaccuracies and respond to any questions as soon as possible. IANA's reviewer has the following comments/questions: IANA understands that, upon approval of this document, there is a single action which IANA must complete. In the SMI Network Management MGMT Codes Internet-standard MIB registry (iso.org.dod.internet.mgmt.mib-2 [1.3.6.1.2.1]) 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: pcePcepMIB Description: Path Computation Element Communications Protocol References: [ RFC-to-be ] 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. |
2014-10-02
|
10 | Jean Mahoney | Request for Last Call review by GENART is assigned to Peter Yee |
2014-10-02
|
10 | Jean Mahoney | Request for Last Call review by GENART is assigned to Peter Yee |
2014-10-02
|
10 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Lionel Morand |
2014-10-02
|
10 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Lionel Morand |
2014-10-02
|
10 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Carl Wallace |
2014-10-02
|
10 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Carl Wallace |
2014-09-29
|
10 | Amy Vezza | IANA Review state changed to IANA - Review Needed |
2014-09-29
|
10 | 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: (Path Computation Element Communications Protocol … The following Last Call announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: ietf@ietf.org Sender: Subject: Last Call: (Path Computation Element Communications Protocol (PCEP) Management Information Base (MIB) Module) to Proposed Standard The IESG has received a request from the Path Computation Element WG (pce) to consider the following document: - 'Path Computation Element Communications Protocol (PCEP) Management Information Base (MIB) Module' 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-10-13. 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 managed objects for modeling of Path Computation Element communications Protocol (PCEP) for communications between a Path Computation Client (PCC) and a Path Computation Element (PCE), or between two PCEs. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-pce-pcep-mib/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-pce-pcep-mib/ballot/ No IPR declarations have been submitted directly on this I-D. |
2014-09-29
|
10 | Amy Vezza | IESG state changed to In Last Call from Last Call Requested |
2014-09-29
|
10 | Amy Vezza | Last call announcement was changed |
2014-09-28
|
10 | Adrian Farrel | Last call was requested |
2014-09-28
|
10 | Adrian Farrel | Ballot approval text was generated |
2014-09-28
|
10 | Adrian Farrel | IESG state changed to Last Call Requested from AD Evaluation::AD Followup |
2014-09-28
|
10 | Adrian Farrel | Last call announcement was changed |
2014-09-28
|
10 | Adrian Farrel | Last call announcement was generated |
2014-09-28
|
10 | Adrian Farrel | Last call announcement was generated |
2014-09-28
|
10 | Adrian Farrel | Ballot writeup was changed |
2014-09-23
|
10 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2014-09-23
|
10 | Jonathan Hardwick | New version available: draft-ietf-pce-pcep-mib-10.txt |
2014-08-10
|
09 | Adrian Farrel | AD review ====== Hello authors, This is very substantial and detailed piece of work. Many thanks for the considerable effort it represents. I have done … AD review ====== Hello authors, This is very substantial and detailed piece of work. Many thanks for the considerable effort it represents. I have done my usual AD review of this document in order to process the publication request. The purpose of the review is to catch any issues that might otherwise show up in IETF last call or IESG review, and to ensure that I can fully support the document. I'm glad to hear that there are implementations underlying this work and that should be used as a moderating influence on my comments and questions. For many of the points I raise it may be OK to answer "We have thought about it, but this is how we chose to implement it." Please look through the comments and let me know your thoughts either by providing a new revision, or by answering via email. Thanks for the work, Adrian ===== Section 1 para 2 The PCE communication protocol (PCEP) The convention these days seems to be "Path Computation Element Communications Protocol" or "Path Computation Element communications Protocol". You might apply that to the document title as well. --- Section 1 The PCE communication protocol (PCEP) is the communication protocol between a PCC and PCE for point-to-point (P2P) path computations and is defined in [RFC5440]. That reference to P2P seemed odd to me. Any reason to include it? In particular, nothing in this module appears to be specific to whether P2P or P2MP request are being supported. --- That previous point does cause me to wonder about "PCE capabilities". I can see that you have tried to limit this module to describing the features that are core to 5440, but I wonder whether that is wise. For example, RFCs 5088 and 5089 define a set of PCE capabilities that may be advertised in the IGPs and are surely relevant to the model of a PCE that speaks PCEP. That information might usefully be seen in the module at the PCE, and also at the PCC so that an operator can check "why does that PCC keep sending these requests to the wrong PCE?" Similarly, the Open Object can carry TLVs that indicate further capabilities. Obviously you can't just include all future capabilities TLVs since you don't know what they are (well, you know some, but that have already been defined, but you can't know the undefined ones). But you might want to to look at how those capabilities will be hooked in for future accessibility. Of particular interest will be the OF-list TLV of RFC 5541. --- Convention has it that you have written a "MIB module" which is part of "the MIB", so can you look through the document and mainly change "MIB" to "MIB module". --- I'm wondering under what circumstances the pcepEntityTable has more than one entry. You might describe that in 4.1 and also in the Description clause for the table. That would tie in with explaining why you have an index of Unsigned32 (1..2147483647) which allows for quite a lot of entities! For a moment I thought that maybe there would be one entry when acting as PCE and one when acting as PCC (i.e., a max of 2 < 2147483647) but there is no mode field in the entityTable, only the peerTable. Actually, I'm a bit confused about the indexing of the three tables. I think you think that every PCE and PCC in the network shows in the entityTable. But that isn't how you have set up the entityTable to contain information that is about the local PCEP entity/entities. So my confusion... Now, looking at the indexes to pcePcepPeerTable. There are two questions. 1. Why do you use pcePcepEntityIndex as an index? It points back into entityTable which we have established is basically the local PCEP speaker or which there is probably just one. The text in 4.2 says... The pcePcepPeerTable contains one row for each PCEP peer that the PCEP entity (PCE or PCC) knows about. I think your intention is that pcePcepEntityIndex is different for each peer. But pcePcepEntityIndex is the index to PcePcepEntityTable which is full of local PCEP entity information and (I suspect) will only ever have one entry. Shouldn't the peerTable have its own unique index for each peer? 2. Making pcePcepPeerAddrType and pcePcepPeerAddr indexes as well would appear to allow two or more entries for the same peer with different addresses. Is that the intention? If so, you might make it clear in section 4.2. And you would also need to make clear that there is an expectation that an implementation will assign the same value of pcePcepEntityIndex (or the new per-peer index) to each table entry that represents the same peer. OTOH, if a peer has multiple addresses, will this allow you to have multiple sessions to the same peer. Is that what you intended? Alternatively, it seems unlikely that two different peers will have the same address. So why is any additional index (i.e., pcePcepEntityIndex) needed? The same questions apply to the indexing of pcePcepSessTable although pcePcepSessInitiator is understandable. The solution to all this will be: - Decide how many entries you really expect in entityTable. - Decide whether entries in peerTable and sessTable should be indexed from entityTable, or with an index from peerTable. --- A small worked example would be cool (either between Sections 4 and 5, or in an Appendix). I would draw a figure such as: PCE1---PCE2 PCE3 | / | / | | / | / | PCCa/ PCCb PCCc ...and give an example of the module as read at PCE2 and PCCb. --- The OID structure is unusual. I'm not saying it is wrong, but it is different around pcePcepObjects. It would probably help to include a diagrammatic representation. I think you have something like the following. (BTW, the "unusual" is the additional indirection between pcePcepObjects and the various tables.) mib-2 | |--- XXX pcePcepMIB | |--- 0 pcePcepNotifications | | | |--- 1 pcePcepSessUp | : : | |--- 1 pcePcepObjects | | | |--- 1 pcePcepEntityObjects | | | | | |--- 1 pcePcepEntityTable | | | |--- 2 pcePcepPeerObjects | | | | | |--- 1 pcePcepPeerTable | | | |--- 3 pcePcepSessObjects | | | |--- 1 pcePcepSessTable | |--- 2 pcePcepConformance | |--- 1 pcePcepCompliances |--- 2 pcePcepGroups --- I'd also like to see a short section (probably just containing a figure) that shows the relationship between the three tables in this module. It can't be complex (there are only three tables!), but a figure that shows which objects in which tables lead you to find rows in other tables would be a help. And where the relationship is shared indexes or augmentation that can be called out. --- I am quite happy that this module is entirely read-only. But it makes some of the "usual" objects a little odd without additional information in their Description clauses. For example, pcePcepEntityAdminStatus says "The administrative status of this PCEP Entity." That is fine, but what does it mean? You could probably add: "... This is the desired operational status as currently set by an operator or by default in the implementation. The value of pcePcepEntityOperStatus represents the current status of an attempt to reach this desired status." --- I like the values you have offered in pcePcepEntityOperStatus A common accompaniment to the failure cases (and maybe the inactive / deactivating cases) is an unformatted reason string. Did you consider adding one of these? --- Do you support values of pcePcepEntityAddrType other than ipv4(1) and ipv6(2)? Maybe unknown(0) is used when pcePcepEntityAddr has not been set up? If there is some limit on the full range of values from the Syntax InetAddressType you should: - say so in the Description clause - say so in the Conformance statement. That will make the text in pcePcepEntityAddr easier to cope with unchanged. --- Just asking... Is there a value of pcePcepEntityConnectTimer that means "never give up"? You could use zero if you wanted to, but you don't have to. (18 hours is probably long enough.) --- Similar for pcePcepEntityConnectMaxRetry Is there a value that means continue indefinitely? Although 2^32 attempts sounds like quite a few. The Description for this object says "...before going back to the Idle state." Could you reference that back to an object (presumably in the peerTable since the entry in the sessTable does not exist in idle state) and the associated value. --- pcePcepEntityOpenWaitTimer same question about "wait forever". Also, perhaps clarify that this is the time after the TCP connection has come up. I know the protocol spec makes this clear, but "...aborts the session setup attempt" could be enhanced with "...terminates the TCP connection and removes the associate entry from the sessTable" --- pcePcepEntityDeadTimer is recommended to be 4 times the pcePcepEntityKeepAliveTimer value. I don't think that giving this advice is helpful since this object is read-only and can only report the configured (through other means) value. --- pcePcepEntityMaxDeadTimer DESCRIPTION "The maximum value that this PCEP entity will accept from a peer for the Dead timer. Zero means that the PCEP entity will allow not running a Dead timer. A Dead timer will not be accepted unless it is both greater than the session Keepalive timer and less than this field." Are you sure? Where does a zero Dead timer fit with that statement? --- pcePcepEntityAllowNegotiation seems out of order in amidst the various timer objects. Not important, but odd. --- pcePcepEntityMinDeadTimer OBJECT-TYPE DESCRIPTION "In PCEP session parameter negotiation, the minimum value that this PCEP entity will accept for the Dead timer. Zero means that the PCEP entity insists on not running a Dead timer. A Dead timer will not be accepted unless it is both greater than the session Keepalive timer and greater than this field." Again, the second paragraph seems to conflict with the use of zero. --- pcePcepEntitySyncTimer needs to clarify that this object only has meaning if the entity is a PCE. So you should give a value that a PCC can return in this object, or say that a PCC should not return this object. Furthermore, the syncTimer is only recommended in RFC 5440. How should an implementation that does not implement a syncTimer return this object? --- The backoff timer objects (pcePcepEntityInitBackoffTimer and pcePcepEntityMaxBackoffTimer) might be better grouped next to the other session-related timers (especially the OpenTimer). --- pcePcepEntityMaxUnknownReqs OBJECT-TYPE DESCRIPTION "The maximum number of unrecognized requests and replies that any session on this PCEP entity is willing to accept per minute. pcePcepEntityMaxUnknownMsgs OBJECT-TYPE DESCRIPTION "The maximum number of unknown messages that any session on this PCEP entity is willing to accept per minute." ...before doing what? --- Same issue wrt pcePcepPeerAddrType as for pcePcepEntityAddrType --- In pcePcepPeerRole it might be more usual to have unknown(0). --- It is not clear (to me) whether pcePcepPeerNumSessSetupFail is incremented each time a retry fails or only each time a session set-up attempt is abandoned. --- pcePcepPeerSessionFailTime DESCRIPTION "The value of sysUpTime the last time a session with this peer failed to be established. This is consistent with other fields, but does not record a session that was up, but then failed. --- Now, I'll grant that pcePcepEntityMaxUnknownMsgs allows for a remarkably high rate of receipt of unknown messages with... SYNTAX Unsigned32 DESCRIPTION "The maximum number of unknown messages that any session on this PCEP entity is willing to accept per minute." But, given that rate, it seems that pcePcepPeerNumUnknownRcvd could overflow within just one minute. SYNTAX Counter32 DESCRIPTION "The number of unknown messages received from this peer." The same is going to apply to pcePcepEntityMaxUnknownReqs and pcePcepPeerNumReqRcvdUnknown. Also, of course, the same applies to the counters in the sessTable. --- Many of the same comments apply to the objects in the sessEntry as applied to the peerEntry and entityEntry, and I won't repeat them here. --- I don't think pcePcepSessOverloadTime and pcePcepSessPeerOverloadTime are very useful. The values are presumably stored from sent or received OVERLOADED-DURATION TLVs in PCNtf messages that indicate 'Overloaded'. However, if I come and look at the object some time later I have no idea how much longer the overloaded state may last. I think you need (I use the peer as an example) pcePcepSessPeerOverload TruthValue Whether or not this peer is overloaded. pcePcepSessPeerLastOverloaded Timestamp Time at which last overload event occurred for this peer. Not cleared when pcePcepSessPeerOverload becomes false. pcePcepSessPeerLastOverloadTime Unsigned32 Duration of last overload event for this peer. Not cleared when pcePcepSessPeerOverload becomes false. --- Although this is carefully a read-only MIB module, I wonder whether you need a way to quiesce the Notifications issued by an implementation. Something like... pcePcepNotificationsMaxRate OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-write STATUS current DESCRIPTION "This variable indicates the maximum number of notifications issued per second. If events occur more rapidly, the implementation may simply fail to emit these notifications during that period, or may queue them until an appropriate time. A value of 0 means no notifications are emitted and all should be discarded (i.e., not queued)." ...or... pcePcepNotificationsEnable OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "If this object is true, then it enables the generation of notifications." Without one of these, your management station will be bombed with Notifications from the PCCs in the network. |
2014-08-10
|
09 | Adrian Farrel | IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation |
2014-08-08
|
09 | Adrian Farrel | Notification list changed to : pce-chairs@tools.ietf.org, draft-ietf-pce-pcep-mib@tools.ietf.org, kirankoushik.agraharasreeniv@gmail.com |
2014-08-08
|
09 | Adrian Farrel | Ballot writeup was changed |
2014-08-08
|
09 | Adrian Farrel | Ballot writeup was generated |
2014-08-08
|
09 | Adrian Farrel | IESG state changed to AD Evaluation from Publication Requested |
2014-07-30
|
09 | Julien Meuric | 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. (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? -> PS Why is this the proper type of RFC? -> MIB specification Is this type of RFC indicated in the title page header? -> Yes (ST) (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary This memo defines a portion of the Management Information Base for use with network management protocols in the Internet community. In particular, it describes managed objects for modeling of Path Computation Element communication Protocol (PCEP) for communications between a Path Computation Client (PCC) and a Path Computation Element (PCE), or between two PCEs. Working Group Summary Was there anything in WG process that is worth noting? -> Moving to YANG modules has been discussed. For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? -> No Document Quality Are there existing implementations of the protocol? -> Yes (but not a protocol) Have a significant number of vendors indicated their plan to implement the specification? -> Not really significant 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? -> Juergen Schoenwaelder: "The document is in a pretty good shape. [...] well put together" If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? -> Review by MIB Doctor (Juergen) In the case of a Media Type review, on what date was the request posted? -> N/a Personnel Who is the Document Shepherd? -> Julien Meuric Who is the Responsible Area Director? -> Adrian Farrel (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. -> Looks ready for publication (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? -> No (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. -> No (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. -> N/a (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why. -> Yes (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. -> No (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? -> WG members interested in MIBs agree (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) -> No (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. -> Kiran Koushik's address needs to be updated (kirankoushik.agraharasreeniv@gmail.com) (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. -> MIB specification, thus MIB Doctor review performed by Juergen (13) Have all references within this document been identified as either normative or informative? -> Yes (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? -> No (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. -> No (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. -> No (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. -> OK Confirm that any referenced IANA registries have been clearly identified. -> OK 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). -> N/a (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. -> N/a (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. -> http://www.simpleweb.org/ietf/mibs/validate/ |
2014-07-30
|
09 | Julien Meuric | State Change Notice email list changed to pce-chairs@tools.ietf.org, draft-ietf-pce-pcep-mib@tools.ietf.org |
2014-07-30
|
09 | Julien Meuric | Responsible AD changed to Adrian Farrel |
2014-07-30
|
09 | Julien Meuric | IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up |
2014-07-30
|
09 | Julien Meuric | IESG state changed to Publication Requested |
2014-07-30
|
09 | Julien Meuric | IESG process started in state Publication Requested |
2014-07-30
|
09 | Julien Meuric | Intended Status changed to Proposed Standard from None |
2014-07-30
|
09 | Julien Meuric | Changed document writeup |
2014-07-25
|
09 | Jonathan Hardwick | New version available: draft-ietf-pce-pcep-mib-09.txt |
2014-07-22
|
08 | Julien Meuric | Reference section to be updated |
2014-07-22
|
08 | Julien Meuric | Tag Doc Shepherd Follow-up Underway set. |
2014-07-22
|
08 | Julien Meuric | IETF WG state changed to WG Consensus: Waiting for Write-Up from WG Document |
2014-07-22
|
08 | Julien Meuric | Document shepherd changed to Julien Meuric |
2014-04-02
|
08 | Jonathan Hardwick | New version available: draft-ietf-pce-pcep-mib-08.txt |
2014-02-06
|
07 | Jonathan Hardwick | New version available: draft-ietf-pce-pcep-mib-07.txt |
2014-01-09
|
06 | Jonathan Hardwick | New version available: draft-ietf-pce-pcep-mib-06.txt |
2013-07-15
|
05 | Jonathan Hardwick | New version available: draft-ietf-pce-pcep-mib-05.txt |
2013-02-19
|
04 | Jonathan Hardwick | New version available: draft-ietf-pce-pcep-mib-04.txt |
2012-07-10
|
03 | Jonathan Hardwick | New version available: draft-ietf-pce-pcep-mib-03.txt |
2011-01-07
|
02 | (System) | Document has expired |
2010-07-06
|
02 | (System) | New version available: draft-ietf-pce-pcep-mib-02.txt |
2010-03-08
|
01 | (System) | New version available: draft-ietf-pce-pcep-mib-01.txt |
2009-01-27
|
00 | (System) | New version available: draft-ietf-pce-pcep-mib-00.txt |