Locator/ID Separation Protocol (LISP) MIB
draft-ietf-lisp-mib-13
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2013-10-25
|
13 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2013-10-21
|
13 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2013-09-20
|
13 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
2013-09-16
|
13 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2013-09-16
|
13 | Amy Vezza | State changed to RFC Ed Queue from Approved-announcement sent |
2013-09-13
|
13 | (System) | RFC Editor state changed to EDIT |
2013-09-13
|
13 | (System) | Announcement was received by RFC Editor |
2013-09-13
|
13 | (System) | IANA Action state changed to Waiting on RFC Editor from Waiting on Authors |
2013-09-13
|
13 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2013-09-13
|
13 | (System) | IANA Action state changed to In Progress |
2013-09-13
|
13 | Amy Vezza | State changed to Approved-announcement sent from Approved-announcement to be sent |
2013-09-13
|
13 | Amy Vezza | IESG has approved the document |
2013-09-13
|
13 | Amy Vezza | Closed "Approve" ballot |
2013-09-13
|
13 | Amy Vezza | State changed to Approved-announcement to be sent from IESG Evaluation::AD Followup |
2013-09-13
|
13 | Brian Haberman | Changed consensus to Yes from Unknown |
2013-09-13
|
13 | Brian Haberman | Ballot writeup was changed |
2013-09-13
|
13 | Brian Haberman | Ballot approval text was generated |
2013-09-13
|
13 | Gregg Schudel | New version available: draft-ietf-lisp-mib-13.txt |
2013-09-09
|
12 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2013-09-09
|
12 | Gregg Schudel | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2013-09-09
|
12 | Gregg Schudel | New version available: draft-ietf-lisp-mib-12.txt |
2013-08-12
|
11 | Suresh Krishnan | Request for Telechat review by GENART Completed: Ready with Nits. Reviewer: Suresh Krishnan. |
2013-07-23
|
11 | Brian Haberman | [Ballot comment] I am adding this comment for posterity... While I still support the publication of this document, I do still believe that Adrian's concern … [Ballot comment] I am adding this comment for posterity... While I still support the publication of this document, I do still believe that Adrian's concern is a valid one. Per the authors, there is no implementation of this MIB at the time of publication. There is a high probability that the MIB will require changes in the future to address limitations discovered during preliminary use. A revised version of the MIB will incur the same costs (new anchor point, new object names, ...as moving the MIB from the experimental branch to the mib-2. So, I would have preferred having the MIB start in the experimental branch and then migrate to mib-2 once some operational experience has been gained and the community determined that it is worthwhile to put LISP on the standards track. However, the consensus is to start with the experimental LISP MIB located in mib-2. |
2013-07-23
|
11 | Brian Haberman | Ballot comment text updated for Brian Haberman |
2013-07-22
|
11 | Adrian Farrel | [Ballot comment] I have moved my two Discuss points into this Abstain Comment. I held the final Discuss on this document and do not wish … [Ballot comment] I have moved my two Discuss points into this Abstain Comment. I held the final Discuss on this document and do not wish to hold it up in interminable conversations over these points. I have heard the input from the OPS ADs and the MIB Doctors on the first issue and remain *completely* unconvinced by the reasoning. If this document was for a Standards Track protocol, or if MIB modules were more significant, I might dig in further. --- While it is not against the allocation policy to assign this module under mib-2, I should have thought that given the Experimental nature of this work, it would be better placed under 1.3.6.1.3 experimental. --- lispUseProxyEtrAddressLength OBJECT-TYPE SYNTAX Integer32 (5..259) MAX-ACCESS not-accessible STATUS current DESCRIPTION "This object is used to get the octet-length of lispUseProxyEtrAddress." ::= { lispUseProxyEtrEntry 1 } lispUseProxyEtrAddress OBJECT-TYPE SYNTAX LispAddressType MAX-ACCESS not-accessible STATUS current DESCRIPTION "Address of Proxy ETR configured on this device." ::= { lispUseProxyEtrEntry 2 } ...but... LispAddressType ::= TEXTUAL-CONVENTION DISPLAY-HINT "39a" SYNTAX OCTET STRING (SIZE (5..39)) So what would it mean if lispUseProxyEtrAddressLength had length 40? ==== Original Comment follows... --- The RFC Editor will want the Introduction to be Section 1. --- Section 2 This draft describes the Management Information Base (MIB) module for s/draft/document/ --- I think the document would benefit from a description of how SNMP is exepected to work across the locator/ID separation. --- Section 7 The Imports clauses have comments that are direct citations. The same applies to some Description clauses. This is generally not done because when the module is extracted (which it often is) the references section is lost. --- Time to clean up idnits before passing this to the RFC Editor? Shepherd write-up says I checked the ID nits and there are no warning or errors. However, idnits shows me an unused reference. --- lispMappingDatabaseTable OBJECT-TYPE DESCRIPTION In general, this table would be representative of all such mappings for the given LISP site to which this device belongs." In general? --- lispFeaturesInstanceID OBJECT-TYPE MAX-ACCESS not-accessible DESCRIPTION "This represents the Instance ID of the LISP header. An Instance ID in the LISP address encoding helps uniquely identify the AFI-based address space to which a given EID belongs. It's default value is 0." DEFVAL { 0 } How does a defualt for a not-accessible object work? --- Truth values. For example... lispFeaturesRlocProbeEnabled OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates the status of rloc-probing feature on this device. If this object is TRUE, then this feature is enabled." ::= { lispFeaturesEntry 12 } I think it is normal to use lower case "true" and "false" to be consistent with the definition of TruthValue. In text, it is even preferable to use "true(1)" and "false(2)". --- lispFeaturesRouterTimeStamp OBJECT-TYPE MAX-ACCESS read-only DEFVAL { 0 } lispMappingDatabaseTimeStamp OBJECT-TYPE MAX-ACCESS read-only DEFVAL { 0 } ...etc. How does a default for a read-only object work? --- lispMappingDatabaseDecapOctets OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of octets of LISP packets that were decapsulated by this device addressed to a host within this EID-prefix. Is it clear that this count is after decapsulation? --- The name of the LispAddressType TC is confusing. The TC may have the address type embedded in it, but the TC is actually used to define objects that contain addresses. LispAddress would be a better name. |
2013-07-22
|
11 | Adrian Farrel | [Ballot Position Update] Position for Adrian Farrel has been changed to Abstain from Discuss |
2013-07-11
|
11 | Cindy Morgan | State changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation |
2013-07-10
|
11 | Spencer Dawkins | [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins |
2013-07-10
|
11 | Jari Arkko | [Ballot Position Update] New position, No Objection, has been recorded for Jari Arkko |
2013-07-10
|
11 | Benoît Claise | [Ballot comment] - Section 5 Provide a means for obtaining (read-only) a current status of LISP features enabled on … [Ballot comment] - Section 5 Provide a means for obtaining (read-only) a current status of LISP features enabled on a device, and (read-only) a current status of configuration attributes related to those features. (This MIB provides read-only capabilities; it does not provide any capablities for setting or changing features.) I'm confused by "provides read-only capabilities". Please change this sentence. These are not capabilities, but a list of enabled/disabled features. lispFeaturesTable OBJECT-TYPE SYNTAX SEQUENCE OF LispFeaturesEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table represents the ON/OFF status of the various LISP features that can be enabled on LISP devices." "Capabilities" means: I support A, B, C, D, ... This is at least what the capabilities tables in previous MIB tables meant. lispFeaturesTable means: A, B, and D are enabled. - I was (slightly) confused by the fact that you combine parameters (lispFeaturesMapCacheSize, lispFeaturesMapCacheLimit) in a lispFeaturesTable - I agree with Adian's comments (not DISCUSS) regarding the MIB module Editorial Section 5: s/meachanism/mechanism |
2013-07-10
|
11 | Benoît Claise | [Ballot Position Update] New position, No Objection, has been recorded for Benoit Claise |
2013-07-10
|
11 | Gonzalo Camarillo | [Ballot Position Update] New position, No Objection, has been recorded for Gonzalo Camarillo |
2013-07-10
|
11 | Stephen Farrell | [Ballot comment] I didn't go back and re-read the LISP RFCs so there might be nothing here, but did anyone really check whether or not … [Ballot comment] I didn't go back and re-read the LISP RFCs so there might be nothing here, but did anyone really check whether or not the information exposed here about mappings could assist a bad actor in mounting an attack against a LISP deployment? My concern is that the base LISP RFCs could have an inbuilt assumption that the mapping tables aren't known to all attackers, but this does expose some of that, and that might make an attack feasible that previously was not, e.g. by reducing the size of a space from which a bad actor would have to guess values. If someone tells me that "yes, we looked at that and its ok" that'll be fine. If you didn't look, it'd be great if someone could do that now just in case since it could be painful later if something does turn up. There are a few nits in the secdir review [1] that are worth a look, and one change that the authors said they want to make. [1] http://www.ietf.org/mail-archive/web/secdir/current/msg04038.html |
2013-07-10
|
11 | Stephen Farrell | [Ballot Position Update] New position, No Objection, has been recorded for Stephen Farrell |
2013-07-09
|
11 | Joel Jaeggli | [Ballot Position Update] New position, No Objection, has been recorded for Joel Jaeggli |
2013-07-08
|
11 | Pete Resnick | [Ballot Position Update] New position, No Objection, has been recorded for Pete Resnick |
2013-07-08
|
11 | Richard Barnes | [Ballot Position Update] New position, No Objection, has been recorded for Richard Barnes |
2013-07-07
|
11 | Adrian Farrel | [Ballot discuss] Two relatively small and easy-to-fix Discuss points While it is not against the allocation policy to assign this module under mib-2, I should … [Ballot discuss] Two relatively small and easy-to-fix Discuss points While it is not against the allocation policy to assign this module under mib-2, I should have thought that given the Experimental nature of this work, it would be better placed under 1.3.6.1.3 experimental. Please let me know that this was considered and sicussed with the MIB Doctor. --- lispUseProxyEtrAddressLength OBJECT-TYPE SYNTAX Integer32 (5..259) MAX-ACCESS not-accessible STATUS current DESCRIPTION "This object is used to get the octet-length of lispUseProxyEtrAddress." ::= { lispUseProxyEtrEntry 1 } lispUseProxyEtrAddress OBJECT-TYPE SYNTAX LispAddressType MAX-ACCESS not-accessible STATUS current DESCRIPTION "Address of Proxy ETR configured on this device." ::= { lispUseProxyEtrEntry 2 } ...but... LispAddressType ::= TEXTUAL-CONVENTION DISPLAY-HINT "39a" SYNTAX OCTET STRING (SIZE (5..39)) So what would it mean if lispUseProxyEtrAddressLength had length 40? |
2013-07-07
|
11 | Adrian Farrel | [Ballot comment] The RFC Editor will want the Introduction to be Section 1. --- Section 2 This draft describes the Management Information Base (MIB) … [Ballot comment] The RFC Editor will want the Introduction to be Section 1. --- Section 2 This draft describes the Management Information Base (MIB) module for s/draft/document/ --- I think the document would benefit from a description of how SNMP is exepected to work across the locator/ID separation. --- Section 7 The Imports clauses have comments that are direct citations. The same applies to some Description clauses. This is generally not done because when the module is extracted (which it often is) the references section is lost. --- Time to clean up idnits before passing this to the RFC Editor? Shepherd write-up says I checked the ID nits and there are no warning or errors. However, idnits shows me an unused reference. --- lispMappingDatabaseTable OBJECT-TYPE DESCRIPTION In general, this table would be representative of all such mappings for the given LISP site to which this device belongs." In general? --- lispFeaturesInstanceID OBJECT-TYPE MAX-ACCESS not-accessible DESCRIPTION "This represents the Instance ID of the LISP header. An Instance ID in the LISP address encoding helps uniquely identify the AFI-based address space to which a given EID belongs. It's default value is 0." DEFVAL { 0 } How does a defualt for a not-accessible object work? --- Truth values. For example... lispFeaturesRlocProbeEnabled OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates the status of rloc-probing feature on this device. If this object is TRUE, then this feature is enabled." ::= { lispFeaturesEntry 12 } I think it is normal to use lower case "true" and "false" to be consistent with the definition of TruthValue. In text, it is even preferable to use "true(1)" and "false(2)". --- lispFeaturesRouterTimeStamp OBJECT-TYPE MAX-ACCESS read-only DEFVAL { 0 } lispMappingDatabaseTimeStamp OBJECT-TYPE MAX-ACCESS read-only DEFVAL { 0 } ...etc. How does a default for a read-only object work? --- lispMappingDatabaseDecapOctets OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of octets of LISP packets that were decapsulated by this device addressed to a host within this EID-prefix. Is it clear that this count is after decapsulation? --- The name of the LispAddressType TC is confusing. The TC may have the address type embedded in it, but the TC is actually used to define objects that contain addresses. LispAddress would be a better name. |
2013-07-07
|
11 | Adrian Farrel | [Ballot Position Update] New position, Discuss, has been recorded for Adrian Farrel |
2013-07-03
|
11 | Stewart Bryant | [Ballot Position Update] New position, No Objection, has been recorded for Stewart Bryant |
2013-07-03
|
11 | Martin Stiemerling | Ballot comment text updated for Martin Stiemerling |
2013-07-03
|
11 | Martin Stiemerling | [Ballot comment] No objection to the draft, but I wonder if the write-up is correct, as this draft specifies a MIB module and the write-up … [Ballot comment] No objection to the draft, but I wonder if the write-up is correct, as this draft specifies a MIB module and the write-up says under point (12) "No formal review is required.? I assume that at least the MIB doctors are going to the check this, isn't it? |
2013-07-03
|
11 | Martin Stiemerling | [Ballot Position Update] New position, No Objection, has been recorded for Martin Stiemerling |
2013-06-28
|
11 | Sean Turner | [Ballot comment] The MIB doctors boilerplate for security has changed ever so slightly: http://trac.tools.ietf.org/area/ops/trac/wiki/mib-security The big change is the 2nd to last paragraph needs to … [Ballot comment] The MIB doctors boilerplate for security has changed ever so slightly: http://trac.tools.ietf.org/area/ops/trac/wiki/mib-security The big change is the 2nd to last paragraph needs to be: Implementations SHOULD provide the security features described by the SNMPv3 framework (see [RFC3410]), and implementations claiming compliance to the SNMPv3 standard MUST include full support for authentication and privacy via the User-based Security Model (USM) [RFC3414] with the AES cipher algorithm [RFC3826]. Implementations MAY also provide support for the Transport Security Model (TSM) [RFC5591] in combination with a secure transport such as SSH [RFC5592] or TLS/DTLS [RFC6353]. |
2013-06-28
|
11 | Sean Turner | Ballot comment text updated for Sean Turner |
2013-06-28
|
11 | Sean Turner | [Ballot comment] The MIB doctors boilerplate for security has changed ever so slightly: http://trac.tools.ietf.org/area/ops/trac/wiki/mib-security The big change is the 2nd to last paragraph needs to … [Ballot comment] The MIB doctors boilerplate for security has changed ever so slightly: http://trac.tools.ietf.org/area/ops/trac/wiki/mib-security The big change is the 2nd to last paragraph needs to be: Implementations SHOULD provide the security features described by the SNMPv3 framework (see [RFC3410]), and implementations claiming compliance to the SNMPv3 standard MUST include full support for authentication and privacy via the User-based Security Model (USM) [RFC3414] with the AES cipher algorithm [RFC3826]. Implementations MAY also provide support for the Transport Security Model (TSM) [RFC5591] in combination with a secure transport such as SSH [RFC5592] or TLS/DTLS [RFC6353]. |
2013-06-28
|
11 | Sean Turner | [Ballot Position Update] New position, No Objection, has been recorded for Sean Turner |
2013-06-28
|
11 | Peter Yee | Request for Telechat review by GENART is assigned to Suresh Krishnan |
2013-06-28
|
11 | Peter Yee | Request for Telechat review by GENART is assigned to Suresh Krishnan |
2013-06-27
|
11 | Tero Kivinen | Request for Last Call review by SECDIR Completed: Has Nits. Reviewer: Warren Kumari. |
2013-06-27
|
11 | Barry Leiba | [Ballot comment] Totally ignorable, completely non-blocking comments here: In Section 5... I get the impression that all this stuff is read-only. Is that right? You … [Ballot comment] Totally ignorable, completely non-blocking comments here: In Section 5... I get the impression that all this stuff is read-only. Is that right? You don't say it enough. OK, sorry for the light sarcasm: seriously, I think it would be adequate to say it only in the first sentence, and get rid of the other instances, as the section as a whole isn't long: The objectives for this LISP MIB module are to provide a read-only meachanism to support the functions below. All objects in this MIB are read-only; there is nothing writeable here. In Section 9... As there's recently been a discussion of how "RECOMMENDED" can be a problematic 2119 key word, and as its use here seems strained, forcing passive voice unnecessarily, I suggest (again, completely non-blocking, so ignore me if you particularly like it as it is, but I think it reads better this way): - Implementers SHOULD consider the security features as provided by the SNMPv3 framework. - Deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Deployment SHOULD be SNMPv3 with cryptographic security enabled. |
2013-06-27
|
11 | Barry Leiba | Ballot comment text updated for Barry Leiba |
2013-06-27
|
11 | Barry Leiba | [Ballot comment] Totally ignorable, completely non-blocking comments here: In Section 5... I get the impression that all this stuff is read-only. Is that right? You … [Ballot comment] Totally ignorable, completely non-blocking comments here: In Section 5... I get the impression that all this stuff is read-only. Is that right? You don't say it enough. OK, sorry for the light sarcasm: seriously, I think it would be adequate to say it in the first sentence, as the section as a whole isn't long: The objectives for this LISP MIB module are to provide a read-only meachanism to support the functions below. All objects in this MIB are read-only; there is nothing writeable here. In Section 9... As there's recently been a discussion of how "RECOMMENDED" can be a problematic 2119 key word, and as its use here seems strained, forcing passive voice unnecessarily, I suggest (again, completely non-blocking, so ignore me if you particularly like it as it is, but I think it reads better this way): - Implementers SHOULD consider the security features as provided by the SNMPv3 framework. - Deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Deployment SHOULD be SNMPv3 with cryptographic security enabled. |
2013-06-27
|
11 | Barry Leiba | [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba |
2013-06-17
|
11 | (System) | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2013-06-17
|
11 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA - Review Needed |
2013-06-17
|
11 | Brian Haberman | State changed to IESG Evaluation from Waiting for AD Go-Ahead::External Party |
2013-06-17
|
11 | Brian Haberman | Ballot has been issued |
2013-06-17
|
11 | Brian Haberman | [Ballot Position Update] New position, Yes, has been recorded for Brian Haberman |
2013-06-17
|
11 | Brian Haberman | Created "Approve" ballot |
2013-06-17
|
11 | Brian Haberman | Ballot writeup was changed |
2013-06-17
|
11 | Brian Haberman | Placed on agenda for telechat - 2013-07-11 |
2013-06-17
|
11 | Gregg Schudel | New version available: draft-ietf-lisp-mib-11.txt |
2013-05-28
|
10 | Brian Haberman | State changed to Waiting for AD Go-Ahead::External Party from Waiting for AD Go-Ahead::AD Followup |
2013-05-23
|
10 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2013-05-23
|
10 | Gregg Schudel | New version available: draft-ietf-lisp-mib-10.txt |
2013-02-26
|
09 | Brian Haberman | State changed to Waiting for AD Go-Ahead::Revised ID Needed from Waiting for AD Go-Ahead::External Party |
2013-02-06
|
09 | Brian Haberman | Awaiting MIB Doctor review |
2013-02-06
|
09 | Brian Haberman | State changed to Waiting for AD Go-Ahead::External Party from Waiting for AD Go-Ahead |
2013-02-04
|
09 | Amit Jain | New version available: draft-ietf-lisp-mib-09.txt |
2013-01-21
|
08 | (System) | State changed to Waiting for AD Go-Ahead from In Last Call |
2013-01-17
|
08 | Miguel García | Request for Last Call review by GENART Completed: Ready. Reviewer: Miguel Garcia. |
2013-01-14
|
08 | Pearl Liang | IANA has reviewed draft-ietf-lisp-mib-08 and has the following comments: IANA understands that, upon approval of this document, there is a single action which IANA must … IANA has reviewed draft-ietf-lisp-mib-08 and has the following comments: 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 subregistry 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: lispMIB Description: Locator/ID Separation Protocol (LISP) References: [ RFC-to-be ] IANA understands this to be the only action required of IANA upon approval of this document. Note: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. |
2013-01-10
|
08 | Jean Mahoney | Request for Last Call review by GENART is assigned to Miguel Garcia |
2013-01-10
|
08 | Jean Mahoney | Request for Last Call review by GENART is assigned to Miguel Garcia |
2013-01-10
|
08 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Warren Kumari |
2013-01-10
|
08 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Warren Kumari |
2013-01-07
|
08 | Amy Vezza | The following Last Call announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: ietf@ietf.org Subject: Last Call: (LISP MIB) to Experimental RFC The … The following Last Call announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: ietf@ietf.org Subject: Last Call: (LISP MIB) to Experimental RFC The IESG has received a request from the Locator/ID Separation Protocol WG (lisp) to consider the following document: - 'LISP MIB' as Experimental RFC 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 2013-01-21. 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 document defines managed objects for the Locator/ID Separation Protocol (LISP). These objects provide information useful for monitoring LISP devices, including basic configuration information, LISP status, and operational statistics. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-lisp-mib/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-lisp-mib/ballot/ No IPR declarations have been submitted directly on this I-D. |
2013-01-07
|
08 | Amy Vezza | State changed to In Last Call from Last Call Requested |
2013-01-07
|
08 | Brian Haberman | Last call was requested |
2013-01-07
|
08 | Brian Haberman | Last call announcement was generated |
2013-01-07
|
08 | Brian Haberman | Ballot approval text was generated |
2013-01-07
|
08 | Brian Haberman | Ballot writeup was generated |
2013-01-07
|
08 | Brian Haberman | State changed to Last Call Requested from AD Evaluation::AD Followup |
2013-01-03
|
08 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2013-01-03
|
08 | Amit Jain | New version available: draft-ietf-lisp-mib-08.txt |
2012-11-13
|
07 | Brian Haberman | State changed to AD Evaluation::Revised ID Needed from AD Evaluation |
2012-10-19
|
07 | Brian Haberman | State changed to AD Evaluation from Publication Requested |
2012-10-18
|
07 | Brian Haberman | Intended Status changed to Experimental |
2012-10-18
|
07 | Brian Haberman | IESG process started in state Publication Requested |
2012-10-18
|
07 | (System) | Earlier history may be found in the Comment Log for draft-schudel-lisp-mib |
2012-10-17
|
07 | Terry Manderson | IETF state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up |
2012-10-17
|
07 | Terry Manderson | Annotation tag Doc Shepherd Follow-up Underway cleared. |
2012-10-17
|
07 | Luigi Iannone | Annotation tag Doc Shepherd Follow-up Underway set. |
2012-10-17
|
07 | Luigi Iannone | Changed protocol writeup |
2012-10-17
|
07 | Luigi Iannone | Changed protocol writeup |
2012-10-17
|
07 | Luigi Iannone | Changed protocol writeup |
2012-10-16
|
07 | Terry Manderson | Writeup submitted by shepherd, passing to IESG |
2012-10-16
|
07 | Terry Manderson | Changed shepherd to Luigi Iannone |
2012-10-15
|
07 | Gregg Schudel | New version available: draft-ietf-lisp-mib-07.txt |
2012-10-11
|
06 | Terry Manderson | IETF state changed to WG Consensus: Waiting for Write-Up from In WG Last Call |
2012-10-01
|
06 | Terry Manderson | WG LC was issued, and the re-issued due to lack of response and review. Sufficient review now received. Moving to next stage. Shepherd will be … WG LC was issued, and the re-issued due to lack of response and review. Sufficient review now received. Moving to next stage. Shepherd will be assigned soon. |
2012-10-01
|
06 | Gregg Schudel | New version available: draft-ietf-lisp-mib-06.txt |
2012-08-15
|
05 | Terry Manderson | IETF state changed to In WG Last Call from WG Document |
2012-06-29
|
05 | Terry Manderson | WGLC initiated on 2012-08-13 |
2012-06-29
|
05 | Gregg Schudel | New version available: draft-ietf-lisp-mib-05.txt |
2012-06-25
|
04 | Gregg Schudel | New version available: draft-ietf-lisp-mib-04.txt |
2011-11-29
|
03 | (System) | New version available: draft-ietf-lisp-mib-03.txt |
2011-05-31
|
02 | (System) | New version available: draft-ietf-lisp-mib-02.txt |
2011-03-14
|
01 | (System) | New version available: draft-ietf-lisp-mib-01.txt |
2011-01-05
|
00 | (System) | New version available: draft-ietf-lisp-mib-00.txt |