Brian E Carpenter wrote:
On 2011-09-02 07:45, Melinda Shore wrote:
...
Can anybody point to an incident in which lack of clarity around
2119 language caused problems, and it was determined that 2119
itself was the problem and not authors or editors being careless?
(or implementors being careless)
Indeed. I'm in favour of leaving "good enough" alone and not striving
for perfection, which is impossible anyway.
My assessment.
At some top level, a good bit of this is a "technical writing" style
issue. The IETF RFC document model blends two phases of the software
engineering process: Functional Requirements (what we want) and
Technical Specification (how its done). Its a blessing and curse. We
have a wide degree of multiple discipline audience so you get input
from a wide degree of people. However, we often get into the mess of
satisfying different functional needs and the technical specification
gets really complex. To me, thats an experience factor as you can
clearly see this in RFC different writing styles and you can also see
specific authors get better at it. So it might help for IETF to help
remind authors of the distinction of the multiple disciplines and to
better separate or organize the functional and technical
specifications parts of the RFC. If a charter is not going to do it
with separate functional requirements and technical specification
RFCs, the author should do it within the one RFC.
Second, minimum requirements need to be very clear and hopefully
documented in its own section of a RFC. It should not take a
implementator to carefully analyze every sentence, every word or do
other minding reading activity to figure out what the Author intent
is. The AUTHOR can not assume that every reader has been part of
every stage during the WG and understand every little detail and
reason why this or that is the way it is. Overall, citing the minimum
requirement very quickly in a RFC helps to resolve many of those
unsure readings. This is where the RFC2119 can help I believe by
help authors focus on this.
Third, I think it is still very important that the insights provided
in Section 6 regarding imposing methods that are not required is
extremely important. When author gain realization of this realistic
insight, it will help them better focus on their protocol engineering
and its minimum requirements. I don't believe there is no danger here
because if an Author believe he can use use MUST all the time, he will
find out very quickly how much lower his RFC is less adopted. Yet,
when it carefully consider this, he will be better prepare the RFC for
maximum support.
Finally, I don't think we can do much about this, but if only to
highlight the problem, the IETF Rough Consensus (RC) Decision Tool is
a major factor in RFC conformance conflicts. When a decision is made
based on RC, especially one deciding SHOULD|MUST, its increase the
odds of getting different usages. Here is one example scenario:
- Very Rough Consensus choose MUST,
- Chair or AD overrides this to SHOULD due to the obvious chaos,
- Reluctantly, MUST advocates accept SHOULD because,
- MUST advocates will always implement the SHOULD,
- Overtime, they become dependent on the SHOULD operation,
- But has interops problems with wide support across the board.
So what do MUST advocates do?
MUST people begin to say RFC2119 SHOULD means you MUST implement it
and only an "Act of G-D" reason is valid for not implementing the
SHOULD. And not only MUST implement, it must also be a MUST-USE
by operators.
One can say, "RC would of worked if the Chair/AD didn't change it",
but then you have the problem Pete stated, people on the SHOULD side,
including those who felt a MAY was more appropriate begin to ignore
the MUST especially if possible to work without it and offer it as an
option to operator to turn ON or OFF just in case there is a problem
went its not enabled.
RC may not be the issue, but it might help if its use carefully
measure how much a MUST is required to get the job done.
--
hls
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf