Olafur, > 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". I'm all in favour of making things easier for people trying to use our standards. I don't believe that adding duplicative terminology to the IANA registries is the right way to do it; I believe that will only *increase* confusion and the risk of ambiguity. Something like draft-ietf-newtrk-repurposing-isd seems much more hopeful but never reached IETF consensus. Meanwhile, to repeat myself, why don't WG's write Applicability Statements as defined in 1996 by BCP 9 (RFC 2026) section 3.2? We've had this mechanism for 14 years, maybe it's time to test it. Regards Brian Carpenter On 2010-03-20 06:58, Olafur Gudmundsson wrote: > 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@xxxxxxxx > https://www.ietf.org/mailman/listinfo/ietf > _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf