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.
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.
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?
--Paul Hoffman, Director
--VPN Consortium
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf