Subject: Re: [MIB-DOCTORS] New Version Notification for draft-ietf-lisp-mib-10.txt

From: Harrie Hazewinkel <[email-masked]>
Date: Thu, 6 Jun 2013 13:09:38 +0200

Hello,

Sorry for the delay. Got side-tracked into other work. Below are a few points I see.
The minor/editorial isses are not a MUST fix.

problem with LispAddressType)

Earlier I mentioned in my review that I found the combination of the length field and address type combined for an index a little bit odd. The part that I found odd is that there is already a length included in the LispAddressType and, therefore, the separate length element is not always required, because the address type field infcluded a lenght element for the address value that was contained in it. Now I better understand why this was defined as it was, I reviewed it again.

However, I now might have found a different problem with the LispAddressType. The value of the LispAddressType includes 1 number field and 2 lenght fields. Although, SNMP defines rather precise how a value such as an Integer is encoded over the wire, I believe this is not the case for the number and length fields that are placed in the octets.

Is it, therefore, not required to mentioned the encoding of those fields?
For instance, big endian/little endian/...

minor editorial issue)

With respect to section 5 it kind of suggests that one could enable LISP features via the MIB module.
>  Provide a means for obtaining an ON/OFF list of LISP features
>       configured on a device, and the current status of configuration
>       attributes related to those features.  As an example, LISP
>       features that could be enabled might include ITR, ETR, PITR, PETR,
>       MS or MR support for IPv4 or IPv6 address families.  Other
>       examples could include indicating whether rloc-probing is enabled,
>       or whether the use of a PETR is enabled.  Configuration attributes
>       related to these features could include the setting of a
>       configured map-cache limit value, or the setting of a mapping
>       time-to-live value.
I understand that the intend is that the 'enabling' process will not occur via SNMP. However, the text "As an example, LISP features that could be enabled" suggests that this MIB somehow could perform the 'enabling' action of a LISP feature.

minor editorial)

>   DESCRIPTION
>             "Locator/ID Separation Protocol (LISP) MIB Managed Object
>              module. The LISP MIB is intended for management of LISP
>              devices.

I would reword this as

  DESCRIPTION
            "This MIB module contains managed objects to support monitoring devices that support the Locator/ID Separation Protocol (LISP).

minor editorial)

If a clause DEFVAL { 0 } is provided for managed objects it is not needed to place that also in the DESCRIPTION, but is not wrong to be more informative in the DESCRIPTION.

minor editorial)

In the DESCRIPTION of lispMapCacheLocatorRlocLastWeightChange there is a space missing "… prefix.Note…." should be "..prefix. Note…"

Harrie
[email-masked]

---

From: "Gregg Schudel (gschudel)" <[email-masked]>
Date: Thu, 13 Jun 2013 17:41:06 +0000

> Sorry for the delay. Got side-tracked into other work. Below are a few points I see.

Hi Harrie - once again - thank you for the review and comments
replies in line.

> For instance, big endian/little endian/...

[gs] endian concepts apply to OS's (and related c-compilers). The 'bits on the wire' are 
given in the packet formats described in the base documents (RFC 6830/31/33). I will add 
a note here, however, to point back to the base documents again - just to be sure that
people understand the ordering of the bits.

> I understand that the intend is that the 'enabling' process will not occur via SNMP. However, the text "As an example, LISP features that could be enabled" suggests that this MIB somehow could perf…

[gs] sure - happy to add a new comment to remove the ambiguity.

>            "This MIB module contains managed objects to support monitoring devices that support the Locator/ID Separation Protocol (LISP).

[gs] sure - happy to modify. thanks for providing the words.

> In the DESCRIPTION of lispMapCacheLocatorRlocLastWeightChange there is a space missing "… prefix.Note…." should be "..prefix. Note…"

[gs] sure - good catch!

It appears that we're down to the small mods now - i'll go ahead and
make a -11 submittal. I'll plan to upload this quickly.

thanks all!

Best regards,
Gregg

--------------------------------------------------------------------
.:|:.:|:. | gregg schudel (ccie#9591) LISP technical marketing engr
  cisco   | mobile: +1 571 332 2222   email: [email-masked]
--------------------------------------------------------------------
cisco corporate legal statement: 
http://www.cisco.com/web/about/doing_business/legal/cri/index.html
--------------------------------------------------------------------