Re: [MIB-DOCTORS] initial responses to: MIB doctor review of draft-ietf-manet-olsrv2-mib-08.txt

[Randy Presuhn <[e-mail]>]

Hi -

...
>On 06/09/2013 03:28 PM, Cole wrote:
>> Hi Randy,
>>
>> We have updated and posted as draft-ietf-manet-olsrv2-mib-10.txt the 
>> last set of corrections to the OLSRv2-MIB module.

Thanks. I've skimmed through -10 and am largely happy with the changes,
but please note a few comments below.

>> Please see our responses below. Also, I attached the 
>> IANAolsrv2LinkMetricType-MIB.txt.

This is RMP-036, for anyone keeping track. Re-stating what we've
already discussed, tThat material should go into its own section
in the document (proabably an appendix) with instructions to the
RFC editor to remove it upon publication, and the "IANA
Considerations" section should instruct IANA to take over that
material and to keep it in syn with the registry.
The commented-out IMPORTS needs to be activated, etc. This needs
to be dealt with before it will be ready for publication.

On page 12 "This is done in Section 24.5 in OLSRv2" - Opinions
vary about citations in DESCRIPTION clauses. I'm in the camp
that thinks they're ok, *but*, mindful of the fact that modules
are frequently extracted from their context, would like to see
a reference that can be traced (e.g., RFC number) when this
text is extracted.


The DESCRIPTION of Olsrv2MetricValueCompressedFormTC seems to cover
the issues I raised in my comments, but a (minor!) new question I'd
ask is whether it would be helpful to say anything about the "holes"
in this representation, and what (if any) special course of action
a management action should take if one of those "impossible"
values shows up in reponse to a query. (Developers sometimes
use "impossible" values for proprietary hack^Wkludge^Wfeatures.)

...
RMP-012
...
>> RGC:> Where there was the potential of OLSRv2 using the 
>> exponent-mantissa form to transmit this information between OLSRv2 
>> instances, will included text in the description to define the mapping 
>> between the MIB representation of these times in Unsigned32 
>> milliseconds to the exponent-mantissa values. The algortihm for this 
>> mapping is defined in Section 5 of RFC 5497 and we explicitly 
>> reference this in the object descriptions. This text shows up in 
>> olsrv2TcInterval, olsrv2TcMinInterval, olsrv2THoldTime and 
>> olsrv2AHoldTime objects.

Ok. I'd suggest wrapping up all this common syntax and DESCRIPTION
into a textual convention. I'm not insisting on it, but it seems
a really obvious thing to do that would improve readability and
might assist some code generators.

...

RMP-056 
>> RGC:> We converted back to using the IP addresses and associated Type 
>> (and PrefixLen where appropriate)
>> the following tables: olsrv2LibOrigSetTable, 
>> olsrv2LibLocAttNetSetTable, olsrv2TibAdRemoteRouterSetTable, 
>> olsrv2TibRouterTopologySetTable and the 
>> olsrv2TibRoutableAddressTopologySetTable. We updated all associated 
>> text in the descriptions of the objects and in the introductory 
>> material in the draft.
>>
>> As you pointed out, this will simplify the operation of the index 
>> selection and will also improve the use-ability of the module by 
>> allowing net managers to more efficiently search tables for 
>> interesting entries, e.g., who is advertising this (IpAddrType, 
>> IpAddr,PrefixLen) network address, without having to perform a bulk 
>> download of the entire table.

I'm happy if you're happy. :-)

A few very trivial things that jumped out at me on this reading,
none of which require action, IMO:

- bottom of page 3 "allowing to monitor" sounds like a word or
two is missing. Perhaps "allowing management applications to
monitor" is intended?

- 4.1 "State Objects" still mentions "process". Depending on how
pedantic one is, this might sound like an implementation detail.

- 5.1, second sentence. verb/subject number agreement problem.
"are found" -> "is found"

Randy