Locator/ID Separation Protocol (LISP) MIB
draft-ietf-lisp-mib-13

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.