ietf
[Top] [All Lists]

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

2006-02-27 05:44:05
----- Original Message -----
From: "Bill Strahm" <bill(_at_)strahm(_dot_)net>
To: "Robert Elz" <kre(_at_)munnari(_dot_)OZ(_dot_)AU>
Cc: "iesg" <iesg(_at_)ietf(_dot_)org>; "ietf" <ietf(_at_)ietf(_dot_)org>
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


Robert Elz wrote:
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.

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)

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


Bill

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


_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf

<Prev in Thread] Current Thread [Next in Thread>