ietf
[Top] [All Lists]

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

2010-03-19 14:06:18
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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf

_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf

<Prev in Thread] Current Thread [Next in Thread>