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@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf