Locator/ID Separation Protocol (LISP) MIB
RFC 7052

Note: This ballot was opened for revision 11 and is now closed.

(Brian Haberman) Yes

Comment (2013-07-23 for -11)
No email
send info
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.

(Jari Arkko) No Objection

(Richard Barnes) No Objection

(Stewart Bryant) No Objection

(Gonzalo Camarillo) No Objection

(Benoît Claise) No Objection

Comment (2013-07-10 for -11)
No email
send info
- 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

(Spencer Dawkins) No Objection

(Stephen Farrell) No Objection

Comment (2013-07-10 for -11)
No email
send info

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

(Joel Jaeggli) No Objection

Barry Leiba No Objection

Comment (2013-06-27 for -11)
No email
send info
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.

(Pete Resnick) No Objection

(Martin Stiemerling) No Objection

(Sean Turner) No Objection

Comment (2013-06-28 for -11)
No email
send info
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].

(Adrian Farrel) (was Discuss) Abstain

Comment (2013-07-22 for -11)
No email
send info
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.