Subject: [Disman] Re: disman remops

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 16 Mar 2006 15:32:02 -0800

Hi -

> From: "Wijnen, Bert (Bert)" <[email-masked]>
> To: "Juergen Quittek (E-mail)" <[email-masked]>; "Randy Presuhn (E-mail)" <[email-masked]>
> Cc: "Dan Romascanu (E-mail)" <[email-masked]>
> 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.
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????

Randy

---

From: Juergen Quittek <[email-masked]>
Date: Fri, 17 Mar 2006 02:54:02 +0100

Hi Randy,

> As a technical contributor, I believe that (A) is the way to go.

I agree.

>            consecutive) values for subsequent hops.

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

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 16 Mar 2006 19:55:40 -0800

Hi -

> From: "Juergen Quittek" <[email-masked]>
> To: "Randy Presuhn" <[email-masked]>; "Wijnen, Bert (Bert)" <[email-masked]>
> Cc: "Dan Romascanu (E-mail)" <[email-masked]>; "Disman" <[email-masked]>
> Sent: Thursday, March 16, 2006 5:54 PM
> Subject: Re: disman remops
...
>              identical with the number of the hop on the traced path.
...

I have no problem with the idea of being more explicit.  So
how about this:

OLD:

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  values for
           subsequent hops.  The value of traceRouteHopsHopIndex
           is not necessarily the number of the hop on the traced path.

Ok?

Randy

---

From: Juergen Quittek <[email-masked]>
Date: Fri, 17 Mar 2006 08:59:13 +0100

Hi Randy,

This sounds like a very good solution.

    Juergen