Re: disman remops

"Randy Presuhn" <[email protected]> Thu, 16 Mar 2006 15:32:02 -0800
Newsgroups gmane.ietf.disman
Message-ID <009f01c64951$d47a47c0$6401a8c0@oemcomputer>
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.
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