Bill Strahm wrote:
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)
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...
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).
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
Bill
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
