RE: I-D ACTION:draft-ietf-disman-remops-mib-v2-07.txt

Hi Bert,

--On 2/11/06 11:17 PM +0100 Wijnen, Bert (Bert) wrote:

> So coming back to this...
> Randy, I don't think I ever got a proto-write-up as per
>
>    draft-ietf-proto-wgchair-doc-shepherding-05.txt
>
> did I?
>
> For the document itself and the MIB modules:
>
>   !! Missing citation for Informative reference:
>   P096 L006: [RFC1812]   F. Baker, "Requirements for IP Version 4 Routers", RFC 1812,
>
>   !! Missing citation for Informative reference:
>   P096 L012: [RFC2474]   Nichols, K., Blake, S., Baker, F. and D. Black, "Definition
>
>   !! Missing citation for Normative reference:
>   P095 L038: [RFC2863]   McCloghrie, K. and F. Kastenholz, "The Interfaces Group
>
>   !! Missing citation for Informative reference:
>   P096 L016: [RFC3260]   D. Grossman, "New Terminology and Clarifications for
>
>   !! Missing citation for Normative reference:
>   P095 L041: [RFC3411]   Harrington, D., Presuhn, R. and B. Wijnen, "An Architecture
>
>   !! Missing citation for Normative reference:
>   P095 L045: [RFC4001]   Daniele, M., Haberman, B., Routhier, S. and J. Schoenwaelder
>
> Can fix with:
>
> OLD:
> 4.  Definitions
>
> 4.1.  DISMAN-PING-MIB
> NEW:
> 4.  Definitions
>
>    The following MIB modules import from [RFC2863], [RFC3411] and [RFC4001].
>    They also use the REFERENCE clause to reference [RFC1812], [RFC2474]
>    and [RFC3260].

This looks like a good solution for the formal problem.
I added the paragraph that you suggested.

> 4.1.  DISMAN-PING-MIB
>
> Further, I am not sure why there is a MIN-ACCESS for these:
>
> W: f(ping.mi2), (1155,19) MIN-ACCESS value identical to access specified for "pi
> ngResultsLastGoodProbe"
> W: f(ping.mi2), (1164,19) MIN-ACCESS value identical to access specified for "pi
> ngProbeHistoryTime"
> W: f(ping.mi2), (1328,19) MIN-ACCESS value identical to access specified for "pi
> ngResultsLastGoodProbe"
> W: f(ping.mi2), (1337,19) MIN-ACCESS value identical to access specified for "pi
> ngProbeHistoryTime"

For pingProbeHistoryTime the DESCRIPTION clauses differ in the two compliance statements.
This also applies to traceRouteResultsLastGoodPath, traceRouteProbeHistoryTime, and
traceRouteHopsLastGoodProbe.

For pingResultsLastGoodProbe the  DESCRIPTION clauses are identical in both compliance
statements.  This looks like I made a mistake.  I suggest changing pingMinimumCompliance:
OLD:
        OBJECT pingResultsLastGoodProbe
        MIN-ACCESS  read-only
        DESCRIPTION
            "This object is mandatory for implementations that have
            access to a system clock and are capable of setting
            the values for DateAndTime objects.  It is RECOMMENDED
            that when this object is not supported that its values
            be reported as '0000000000000000'H."

WITH
        OBJECT pingResultsLastGoodProbe
        MIN-ACCESS  read-only
        DESCRIPTION
            "If the pingHistoryGroup is implemented, then this
            object is mandatory for implementations that have
            access to a system clock and are capable of setting
            the values for DateAndTime objects.  It is RECOMMENDED
            that when this object is not supported that its values
            be reported as '0000000000000000'H."


> Same for:
>
> W: f(traceroute.mi2), (1303,19) MIN-ACCESS value identical to access specified f
> or "traceRouteResultsLastGoodPath"
> W: f(traceroute.mi2), (1325,19) MIN-ACCESS value identical to access specified f
> or "traceRouteProbeHistoryTime"
> W: f(traceroute.mi2), (1346,19) MIN-ACCESS value identical to access specified f
> or "traceRouteHopsLastGoodProbe"
> W: f(traceroute.mi2), (1526,19) MIN-ACCESS value identical to access specified f
> or "traceRouteResultsLastGoodPath"
> W: f(traceroute.mi2), (1547,19) MIN-ACCESS value identical to access specified f
> or "traceRouteProbeHistoryTime"
> W: f(traceroute.mi2), (1569,19) MIN-ACCESS value identical to access specified f
> or "traceRouteHopsLastGoodProbe"

Please see above.

> And for:
> E: f(traceroute.mi2), (1010,16) Index item "traceRouteHopsHopIndex" must be defi
> ned with syntax that includes a range
>
> I wonder why we would not add a range (1..4294967295) I think that is what
> the DESCRIPTION clause does say too.

Yes, the range for the index was missing.

At other places in the document we use range (1..'ffffffff'h) instead of
(1..4294967295).  I suggest using it also here.

Thanks,

    Juergen



> Bert
> 		
>> -----Original Message-----
>> From: Wijnen, Bert (Bert)
>> Sent: Monday, January 16, 2006 12:04
>> To: Randy Presuhn; Wijnen, Bert (Bert)
>> Cc: Disman
>> Subject: RE: [Disman] I-D
>> ACTION:draft-ietf-disman-remops-mib-v2-07.txt
>>
>>
>> OK, so unless you tell me otherwise, I am going to proceed
>> on this document and assume WG consensus.
>>
>> Bert
>>
>> > -----Original Message-----
>> > From: Randy Presuhn [mailto:[email protected]]
>> > Sent: Monday, January 16, 2006 08:54
>> > To: Wijnen, Bert (Bert)
>> > Cc: Disman
>> > Subject: Re: [Disman] I-D
>> > ACTION:draft-ietf-disman-remops-mib-v2-07.txt
>> >
>> >
>> > Hi Bert -
>> >
>> > > From: "Wijnen, Bert (Bert)" <[email protected]>
>> > > To: "Randy Presuhn (E-mail)" <[email protected]>
>> > > Sent: Thursday, January 12, 2006 8:14 AM
>> > > Subject: FW: [Disman] I-D
>> > ACTION:draft-ietf-disman-remops-mib-v2-07.txt
>> > >
>> >
>> > > Randy,
>> > > is this now back on my plate, or does it need another check by WG?
>> > >
>> > > We also still need to do IETF Last Call, and so we need to
>> > start hurry-ing
>> > > if we want to finish this before I step down in March.
>> > ...
>> >
>> > The changes were posted to the disman WG mailing list, and
>> > there was no dissent.
>> > The request is for consideration as PROPOSED STANDARD.
>> > We would have liked to have gone for DRAFT, but I was only able
>> > to obtain adequate implementation reports for two of the three
>> > MIB modules in this document.
>> >
>> > Randy, disman chair
>> >
>> >
>> >
>> >
>>
>
>