![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
Robert Elz wrote: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).I cannot see why there's a debate going on here. If someone, anyone,My mother can't read internet drafts either. Should we change our language so that my mother can read and comprehend them.
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.
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)
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.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).
Regards, Elwyn
Bill
_______________________________________________ Ietf mailing list Ietf at ietf.org https://www1.ietf.org/mailman/listinfo/ietf
_______________________________________________ Ietf mailing list Ietf at ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.