Re: disman remops

Hi Randy,

--On 3/16/06 3:32 PM -0800 Randy Presuhn wrote:

> Hi -
>
>> From: "Wijnen, Bert (Bert)" <[email protected]>
>> To: "Juergen Quittek (E-mail)" <[email protected]>; "Randy Presuhn (E-mail)" <[email protected]>
>> Cc: "Dan Romascanu (E-mail)" <[email protected]>
>> Sent: Thursday, March 16, 2006 5:12 AM
>> Subject: disman remops
>>
>> So we ended up to not make any editorial changes w.r.t. the
>> monotonically increasing issue.
>>
>> Are we happy with that? Or do qwe want to add one or 2 lines
>> of clarifying text for that too. If not, we should probably
>> send an email to Tom explaining why we kept it as is.
>
> Based on the discussion, I would welcome some clarifying text.
>
> However, I'm not sure which of the possible readings work for
> the deployed implementations.   It is clear that "monotonically"
> means "strictly monotonically", since this is an INDEX.  What is
> less clear is whether anyone intended that the values taken by
> traceRouteHopsHopIndex should be considered as a hop count;
> something that would be supported by the requirement that they
> start with 1.  Here are two proposals for the WG mailing list:
>
> (A) that "monotonically" means "strictly monotonically", and
>       index values will be increasing, but cannot be understood
>       as a hop count.   The number of entries would provide
>       this information.
>
> (B) that the intent was that consecutive integers, starting with 1,
>       are to be used for traceRouteHopsHopIndex, and that
>       consequently, the index value can be used as a hop count,
>       except when there has been a path change.
>
> As a technical contributor, I believe that (A) is the way to go.

I agree.

> Any implementation conforming to (B) would conform to (A),
> but not vice cersa.  Furthermore, useful operations like finding
> the total number of hops, or even finding the "Nth" hop in the
> presence of a path change, are no easier with (B) than with (A).
> (A) covers the largest set of possible implementation
> strategies, and there is no advantage to limiting implementations
> to strategy (B).
>
> Consequently, as a technical contributor, I propose the following
> change to the text as a clarification to address Tom's comment:
>
> OLD:
>            "Specifies the hop index for a traceroute hop.  Values
>            for this object with respect to the same
>            traceRouteCtlOwnerIndex and traceRouteCtlTestName
>            MUST start at 1 and increase monotonically.
>
> NEW:
>            "Specifies the hop index for a traceroute hop.  Values
>            for this object with respect to the same
>            traceRouteCtlOwnerIndex and traceRouteCtlTestName
>            MUST start at 1 and be given increasing (not necessarily
>            consecutive) values for subsequent hops.
>
> Comments????

Wouldn't it be helpful to be more explicit, for example, by appending

             The value of traceRouteHopsHopIndex is not necessarily
             identical with the number of the hop on the traced path.

to the description?

Thanks,

    Juergen



> Randy
>