Skip to main content

Locator/ID Separation Protocol (LISP) MIB
RFC 7052

Revision differences

Document history

Date Rev. By Action
2020-01-21
13 (System) Received changes through RFC Editor sync (added Verified Errata tag)
2015-10-14
13 (System) Notify list changed from lisp-chairs@ietf.org, draft-ietf-lisp-mib@ietf.org to (None)
2013-10-31
13 (System) RFC published
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