On 19/03/2010 12:14 PM, Paul Hoffman wrote:
At 10:33 AM -0400 3/19/10, Olafur Gudmundsson wrote:
Well here a proposed problem statement for the requirement:
How does an implementer of a protocol X, find which ones of the many
features listed in registry Y, he/she needs to implement and which
ones are obsolete.
and
How does an "evaluator" of an implementations assess if
implementation Z is compliant with current recommended state
of protocol X.
The second problem my draft is addressing is:
How to express the implementation and operational level of support.
RFC2119 words only apply to IMPLEMENTATIONS.
This problem statement does not match the one in the draft. The one here is a better
problem statement, and it already has a simple solution: write an RFC that say "This
RFC defines X; a sending implementation must be able emit A and SHOULD be able to emit B;
a receiving implementation must be able to process A and SHOULD be able to process
B". This has nothing to do with the IANA registry other than A and B had better be
listed there.
Well it benefits from comments from the many good people that have
commented on the draft after the LC started :-)
I still do not believe that "Publish a new RFC" is the solution.
It still leaves the issue of matching operations to current best
practices, your statements only reflect "interoperability" out of the
box, not what we recommend that people operate/disable/plan-for/etc.
The +- words are on the right track but I think they do not go far
enough.
Further, there is nothing in your draft that says that X is a protocol. The
draft is completely vague as to what is being conformed to.
Because the definitions are trying to cover both implementations and
operations.
As how things have been done I think that process is broken thus I want
people to figure out a better way to provide this information.
So do many of us, but it is not from lack of many well-intentioned people
trying to fix it: it is from a lack of consensus.
The question is how do we make the system more user friendly, remember
we have over 5700 RFC's published so far and we are generating almost
an RFC/day. It is not unlikely that we will have RFC 9000
published before 2020!
Why is this any more true now that a few years ago when the newtrk work failed?
The pain is greater than it was, proposals for changes seem to
get traction when certain pain threshold is reached.
Have we reached it?
In my mind there are basically three kinds of IETF working groups:
1) New protocols/protocol extensions frequently with limited
attention to operations.
2) Protocol maintainance groups
3) Operational groups
RFC2119 words are aimed at the first type, and can to limited extend
be used by the third type, in the case the recommendations are
"static".
As the second and third types of groups will become more common and
contentious it is important to think about how to clearly allow
these groups to express "guidance" in selecting "options".
Olafur
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf