Locator/ID Separation Protocol (LISP) MIB
draft-ietf-lisp-mib-13
Yes
No Objection
(Gonzalo Camarillo)
(Jari Arkko)
(Joel Jaeggli)
(Martin Stiemerling)
(Pete Resnick)
(Richard Barnes)
(Spencer Dawkins)
(Stewart Bryant)
Abstain
Note: This ballot was opened for revision 11 and is now closed.
Brian Haberman Former IESG member
Yes
Yes
(2013-07-23 for -11)
Unknown
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.
Barry Leiba Former IESG member
No Objection
No Objection
(2013-06-27 for -11)
Unknown
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.
Benoît Claise Former IESG member
No Objection
No Objection
(2013-07-10 for -11)
Unknown
- 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
Gonzalo Camarillo Former IESG member
No Objection
No Objection
(for -11)
Unknown
Jari Arkko Former IESG member
No Objection
No Objection
(for -11)
Unknown
Joel Jaeggli Former IESG member
No Objection
No Objection
(for -11)
Unknown
Martin Stiemerling Former IESG member
No Objection
No Objection
(2013-07-03 for -11)
Unknown
Pete Resnick Former IESG member
No Objection
No Objection
(for -11)
Unknown
Richard Barnes Former IESG member
No Objection
No Objection
(for -11)
Unknown
Sean Turner Former IESG member
No Objection
No Objection
(2013-06-28 for -11)
Unknown
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].
Spencer Dawkins Former IESG member
No Objection
No Objection
(for -11)
Unknown
Stephen Farrell Former IESG member
No Objection
No Objection
(2013-07-10 for -11)
Unknown
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
Stewart Bryant Former IESG member
No Objection
No Objection
(for -11)
Unknown
Adrian Farrel Former IESG member
(was Discuss)
Abstain
Abstain
(2013-07-22 for -11)
Unknown
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.