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

["Cole, Robert G CIV USARMY CERDEC (US)" <[e-mail]>]

Classification: UNCLASSIFIED
Caveats: NONE

Randy,

Please see my responses below.  We'll take care of these all this week and rev version 11.

Thanks, Bob

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Randy Presuhn
Sent: Monday, June 10, 2013 12:37 AM
To: [e-mail]; [e-mail]
Subject: Re: [MIB-DOCTORS] initial responses to: MIB doctor review of draft-ietf-manet-olsrv2-mib-08.txt

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.

RGC>  This was what I did not understand.  I'll take care of all this.

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.

RGC>  I believe that these Object descriptions always have an associated REFERENCE clause.  But I suspect you are looking for text in the DESCRIPTION that reads something like "This is done in Section 24.5 in OLSRv2 (RFC XXXX)".  Is this true?


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

RGC> The algorithm in RFC 5497 converts time (t) to (a,b), the parameters of the exponent-mantissa format.  The (a,b) are derived such that t<T(a,b) where T(a,b) is the time value derived from these (a,b) parameter choices and T is the smallest time representation greater than t.   So I suggest the following:

If a net mgmt sets the time value t thru the MIB module, then the OLSRv2 code can derive t' = T(a,b) according to the algorithm in RFC 5497 and t' is the value represented in the OLSRv2 messages. But the value t is persistently stored by the MIB-module. If the MIB-module is pulling this time parameter from some other source, i.e., the protocol instance, then this value is stored as is.

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

RGC> I'll put this into a TC for the affected objects to use.

...

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"

RGC> Thanks,  I'll fixed these.  Bob

Randy
_______________________________________________
MIB-DOCTORS mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/mib-doctors

Classification: UNCLASSIFIED
Caveats: NONE