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

Hi Bert,

I misunderstood your comment on the MIN-ACCESS clauses
for objects pingResultsLastGoodProbe, pingProbeHistoryTime,
traceRouteResultsLastGoodPath, traceRouteProbeHistoryTime, and
traceRouteHopsLastGoodProbe.

Now I see that they are just redundant.
I removed all of them from the compliance statements.

I will post a new version including all requested changes soon.

Thanks,

    Juergen
-- 
Juergen Quittek        [email protected]       Tel: +49 6221 90511-15
NEC Europe Ltd.,       Network Laboratories        Fax: +49 6221 90511-55
Kurfuersten-Anlage 36, 69115 Heidelberg, Germany   http://www.netlab.nec.de


--On 2/12/06 3:37 AM +0100 Juergen Quittek wrote:

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