Subject: Re: Last Call: 'Definitions of Managed Objects for Remote Ping, Traceroute, and Lookup Operations' to Proposed Standard

From: "Tom.Petch" <[email-masked]>
Date: Sat, 25 Feb 2006 12:18:26 +0100

I find the following unclear and would like to see it spelt out in detail

"traceRouteHopsHopIndex
<snip>
           MUST start at 1 and increase monotonically."

Recent discussions on the ietf main list identified two meanings for
'monotonically' - a sequence where each value is greater than or equal to its
predecessor, or a sequence where each value is strictly greater than its
predecessor - and I am unsure whether this means either or neither.

Tom Petch

----- Original Message -----
From: "The IESG" <[email-masked]>
To: "IETF-Announce" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, February 23, 2006 9:21 PM
Subject: Last Call: 'Definitions of Managed Objects for Remote Ping, Traceroute,
and Lookup Operations' to Proposed Standard

> The IESG has received a request from the Distributed Management WG to consider
the following document:
>
> - 'Definitions of Managed Objects for Remote Ping, Traceroute, and Lookup
>    Operations '
>    <draft-ietf-disman-remops-mib-v2-09.txt> as a Proposed Standard
>
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action.  Please send any comments to the
> [email-masked] or [email-masked] mailing lists by 2006-03-09.
>
> The file can be obtained via
> http://www.ietf.org/internet-drafts/draft-ietf-disman-remops-mib-v2-09.txt
>
>
> _______________________________________________
> IETF-Announce mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ietf-announce

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sat, 25 Feb 2006 18:22:49 +0100

> predecessor - and I am unsure whether this means either or neither.

Since this object is part of an INDEX, the meaning of the words is
unambiguous and I suggest no change needed.

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany

---

From: Sam Hartman <[email-masked]>
Date: Sat, 25 Feb 2006 13:29:57 -0500

When you combine increase with monotonically you rule out the
possibility that it is equal.

However I'd expect for an index you want increasing by one, which is
more strict than monotonically increasing.

---

From: Frank Ellermann <[email-masked]>
Date: Sat, 25 Feb 2006 20:52:25 +0100

> possibility that it is equal.

Depending on the definition as discussed here.  I'd have no
problem if somebody claims that trunc(x) or timestamp2date(t)
are "monotically increasing".  

> I'd expect for an index you want increasing by one, which is

Maybe the author allows to skip some hops (indices) - I didn't
look into the draft.  Simply saying "strictly" with or without
"monotically" might be better.
                                Bye, Frank

---

From: Robert Elz <[email-masked]>
Date: Sun, 26 Feb 2006 18:26:38 +0700

I cannot see why there's a debate going on here.   If someone, anyone,
can read a spec, and, in good faith, point out a possible ambiguity in
the text, before the doc is finalised, and if fixing it to avoid the problem 
is easy, what possible justification can there be for not adding a few
words to clarify things, and make sure that confusion does not happen?

Whenever someone points out a problem like this, the response should be
something like "OK, if we write it like ... does that make it clear?" or
perhaps "What would you suggest as clearer wording?" but never "It is
clear enough as it is" as the latter is already demonstrated to be false.

Certainly it is possible to explain the wording on the list, and convince
the objector that very careful understanding of the context makes the
intent clear - but that does nothing for the next person who comes along
and makes the same interpretation "mistake" (perhaps without even
realising the possibility for ambiguity, but simply interpreting the text
a different way).

kre

---

From: Bill Strahm <[email-masked]>
Date: Sun, 26 Feb 2006 15:48:30 -0800

> clear enough as it is" as the latter is already demonstrated to be false.
My mother can't read internet drafts either.  Should we change our 
language so that my mother can read and comprehend them.

It is assumed that there is a baseline knowledge when we write drafts... 
If you don't know how MIBs work in general - there are a LOT of problems 
that you have to sort out before you can provide technical feedback to 
the community.  Someone who is practiced in the art of 
reading/writting/implementing MIBs isn't going to have a problem with 
strictly monotonically increasing Indexes - knowing what that means, and 
how to implement it and test the implementation for correctness.

Somone who has been watching a rant on the list recently invovling the 
work monotonically increasing, MIGHT see the word and get confused.  I 
am not to worried about that - the document really isn't for their eyes 
anyway (I'm not about to comment on various security drafts either - 
should they be simplified so I can understand them, I hope I am expected 
to put in the work so that I understand them instead)

> realising the possibility for ambiguity, but simply interpreting the text

Bill

---

From: Elwyn Davies <[email-masked]>
Date: Mon, 27 Feb 2006 00:44:29 +0000

Bill Strahm wrote:
>> the text, before the doc is finalised, and if fixing it to avoid the 
>> problem is easy, what possible justification can there be for not 
>> adding a few
> It is assumed that there is a baseline knowledge when we write 
> drafts... If you don't know how MIBs work in general - there are a LOT 
> of problems that you have to sort out before you can provide technical 
> feedback to the community.  Someone who is practiced in the art of 
> strictly monotonically increasing Indexes - knowing what that means, 
> and how to implement it and test the implementation for correctness.
>
> am not to worried about that - the document really isn't for their 
> eyes anyway (I'm not about to comment on various security drafts 
> either - should they be simplified so I can understand them, I hope I 
> am expected to put in the work so that I understand them instead)
>
>
There is a fine line between endeavouring to make drafts and RFCs 
comprehensible to the casual, but technically competent, reader and 
requiring them to spell out every last convention and piece of 'common 
knowledge'.  The problem, in my experience as a gen-art reviewer, is 
that most drafts are created and reviewed by what are essentially closed 
communities (smaller than the total IETF and certainly smaller than the 
technical community that might expect to read these documents).  These 
communities share a common set of assumptions and 'jargon'.  This 
occasionally (well actually, quite frequently) results in pieces of text 
which may well be clear to those immersed in the particular art today, 
but that are less than clear to somebody with a reasonable grounding but 
not an intimate knowledge of the subject (such as MIBs) (i.e, me in the 
first instance, and, hopefully, lots of new implementors over the next 
few years).

On the other hand, I would expect the audience to be literate and use a 
dictionary if a word is unfamiliar (as it might be given that not all 
our readers have English as a first language or mathematical training).  
So I am quite happy if a precise word which I can find in the dictionary 
is used correctly.  Or alternatively there is an upfront pointer to a 
clear definition of the term.

Authors should be expecting that their works will be read by people who 
need to get the background right as well as those actually studying 
every line, so it is best to use clear and unambiguous language if at 
all possible:  accordingly I agree wholeheartedly with the next comment...
>> realising the possibility for ambiguity, but simply interpreting the 
For the record, although there is some discussion about monotonic vs 
strictly monotonic, all the cases which I looked at appeared to be used 
(mathematically and linguistically) correctly and unambiguously, given 
the surrounding words (since strictly monotonic sequences are also 
monotonic).  In cases where timestamps are involved it has to be 
monotonic anyway since we don't have clocks with infinitesimal 
resolution or arbitrarily large numbers of bits to represent timestamps.

Regards,
Elwyn

---

From: John Leslie <[email-masked]>
Date: Mon, 27 Feb 2006 07:12:31 -0500

Elwyn Davies <[email-masked]> wrote:
>>> can read a spec, and, in good faith, point out a possible ambiguity
>>> in the text, before the doc is finalised, and if fixing it to avoid
>>> the problem is easy, what possible justification can there be for
>>> not adding a few words to clarify things, and make sure that confusion
>>> does not happen?
>>
> Authors should be expecting that their works will be read by people
> who need to get the background right as well as those actually studying 
> all possible...

   Over many years, I have noticed a characteristic group dynamic where
folks put their effort into agreeing on words, without bothering to ever
agree on what the words mean. 

   This _often_ leads to seemingly irrational defense of the exact words
which have been agreed upon. :^(

   I suggest that folks take note of this feature as we move in the
direction of having documents shepharded by WGCs through the process
leading to publication as an RFC: Folks who have been intimately
involved in choosing exact words will often prefer to defend the words,
rather than defend the meaning.

   This looks like a situation in which only a DISCUSS by an IESG
member would be sufficient to get the wording clarified.

   :^( :^(

--
John Leslie <[email-masked]>

---

From: "Tom.Petch" <[email-masked]>
Date: Mon, 27 Feb 2006 12:41:37 +0100

----- Original Message -----
From: "Bill Strahm" <[email-masked]>
To: "Robert Elz" <[email-masked]>
Cc: "iesg" <[email-masked]>; "ietf" <[email-masked]>
Sent: Monday, February 27, 2006 12:48 AM
Subject: Re: Last Call: 'Definitions of Managed Objects for Remote Ping,
Traceroute, and Lookup Operations' to Proposed Standard

> > realising the possibility for ambiguity, but simply interpreting the text

My own mathematical background taught me that monotonic increasing was always
equal or greater than (as opposed to strictly increasing), so Yaakov Stein's
post (on 'monotonic increasing') opened my eyes somewhat:-) but also left me
thinking, more strongly than before, that monotonic is not a good word to use in
RFC when there is a simpler substitute available (eg strictly increasing, if
that is what is meant).

In this case, I am familiar with MIBs and so know that the index must be unique,
ie that the combination of
INDEX {  traceRouteCtlOwnerIndex, traceRouteCtlTestName, traceRouteHopsHopIndex}
must be unique within that table, of the results of traceroute tests on a per
hop basis.

Here my impression is that the traceRouteHopsHopIndex be a numbered integer
sequence, 'MUST start at 1' and then going 2,3,4,5,6 ... and monotonic is
intending to convey this (but this is not a sense of monotonic that anyone came
up with in the recent thread).

Alternatively, if a hop, eg 3, does not respond, then is the intention that that
the entries go 1,2,4,5,6?

I don't know, and calling the sequence monotonic confuses me.  Juergen sees the
meaning of the words as unambiguous.  I don't - hence my post.

Tom Petch

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 27 Feb 2006 14:14:18 +0100

On Mon, Feb 27, 2006 at 12:41:37PM +0100, Tom.Petch wrote:
 
> Alternatively, if a hop, eg 3, does not respond, then is the
> intention that that the entries go 1,2,4,5,6?

traceRouteHopsMinRtt:

        "The minimum traceroute round-trip-time (RTT) received for
        this hop.  A value of 0 for this object implies that no
        RTT has been received."

traceRouteHopsMaxRtt:

        "The maximum traceroute round-trip-time (RTT) received for
        this hop.  A value of 0 for this object implies that no
        RTT has been received."

I read this as "instantiate a row for all hops and set the RTT to 0 in
case a node did not respond". If rows would not be instantiated, there
would not be a need for the special values. (And of course it makes
sense to instantiate these rows because otherwise a truely broken
traceroute would not instantiate any rows, leaving ambiguity whether
the traceroute did actually run.)

While words can always be improved, I stick to my opinion that once
you write the code, it will be difficult to get this wrong. And
replacing "monotonic" with "strictly monotonic" does IMHO not answer
the question whether you instantiate a row if you do not get a
response or not. Perhaps you want to make a more concrete suggestion
what you think needs to be changed in this document.

/js

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Mon, 27 Feb 2006 13:38:52 +0100

At 13:12 27/02/2006, John Leslie wrote:
>This _often_ leads to seemingly irrational defense of the exact 
>words which have been agreed upon. :^(

Please remember that words may become the name of a doctrine having 
influence on many other things. Also, it is precisely because the 
meaning of the word is uncertain that it permits compromises by 
confusion. People do not then defend the word but the doctrine and 
the compromise - showing that it may be uncertain. This is why it is 
technically highly rewarding to work in English and to specify in 
French. This dual work demands a very precise analysis of the 
proposed solution, as English is better at empathy and French at precision.
jfc

---

From: "Bill Fenner" <[email-masked]>
Date: Mon, 27 Feb 2006 22:48:58 -0800

Juergen,

  I assumed, from reading in traceRouteHopsHopIndex about the behavior
when a path changes, that the only safe thing for a manager to do is
to read the hops from the table and render them to the user in order
of increasing traceRouteHopsHopIndex but without necessarily showing
the traceRouteHopsHopIndex to the user -- that it was perfectly
reasonable for hops 1,2,3,4 of a 4-hop path to be numbered 1,8,12,35
(assuming that they started 1,2,3,4 but there were lots of path
changes during the test).

  I think some people are assuming that the intention was that the
values should be 1,2,3,4 (i.e., HopIndex == hop number) and that's why
they're asking for a different definition.  Perhaps the right
direction could be to clarify that there is no connection between the
value of HopIndex and traceroute hop, other than the ordering.

  Bill

---

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 28 Feb 2006 13:16:02 -0800

Hi -

If the document gives a false impression that the values of
traceRouteHopsHopIndex could be interpreted as hop numbers,
an editorial change to dispel that notion would make sense.
(Likewise, if "consecutive integers starting at one" was the intent, and
is what current implementations actually do, then we should say so.)

I can see how the last two sentences of the last paragraph of
the DESCRIPTION might lead to such a reading.  Does
someone have some replacement text they'd like to propose
to make things clearer?

Randy, disman chair

----- Original Message ----- 
From: "Bill Fenner" <[email-masked]>
To: <[email-masked]>; "Tom.Petch" <[email-masked]>; "Bill Strahm" <[email-masked]>; "iesg" <[email-masked]>;
"ietf" <[email-masked]>
Sent: Monday, February 27, 2006 10:48 PM
Subject: Re: Last Call: 'Definitions of Managed Objects for Remote Ping,Traceroute, and Lookup Operations' to Proposed Standard

Juergen,

  Bill