Re: Last Call: draft-ogud-iana-protocol-maintenance-words (Definitions for expressing standards requirements in IANA registries.) to BCP

[Brian E Carpenter <[e-mail]>]

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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ietf
>