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

[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.

[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.

[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

[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

[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?

[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.

[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?

[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].

[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].

[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.

[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.

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.

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.

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.