Procedures for Protocol Extensions and Variations
RFC 4775

Received changes through RFC Editor sync (changed abstract to 'This document discusses procedural issues related to the extensibility of IETF protocols, including when it is reasonable to extend IETF protocols with little or no review, and when extensions or variations need to be reviewed by the IETF community. Experience has shown that extension of protocols without early IETF review can carry risk. The document also recommends that major extensions to or variations of IETF protocols only take place through normal IETF processes or in coordination with the IETF.

This document is directed principally at other Standards Development Organizations (SDOs) and vendors considering requirements for extensions to IETF protocols. It does not modify formal IETF processes. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.')

[Ballot comment]
Section 1 says:
  >
  > ... experience has shown that they may not be done with the full
  > understanding of why the existing protocol was designed the way
  > that it is ...
  >
  I find this awkward.  I suggest:
  >
  > ... experience has shown that extensions are designed without full
  > understanding of the rationale behind the original protocol design ...

  Section 3 says:
  >
  > Note that Independent Submissions cannot be placed on the IETF
  > Standards Track; they would need to enter full IETF processing.
  >
  I think that "they" is ambiguous.  I suggest:
  >
  > Note that Independent Submissions cannot be placed on the IETF
  > Standards Track, since Standards Track documents require full
  > IETF processing.

  Section 6: s/counter-measure/countermeasure/

[Ballot discuss]
I realize that a lot of thought has gone into this draft.  I want to
thank those who have contributed time and to appologize for not
contributing my own time and then for being unhappy with the result.


This is a disconsolate discuss to some extent and I can be convinced
to move to an abstain but I would like to see how commonly my views
are shared within the IESG because I believe publishing this document
in its current form is harmful to the IETF's credibility.

First, this is an example of a mood of writing I'll call "ietf
passive" which is characterized by excessive use of passive voice and
by not clearly identifying who has responsibility for what.  We've had
lots of trouble with this mood and I strongly recommend the authors
make a pass to make the document active voice.  I think you'll find
you end up having to answer some hard questions about responsibility
in the process.    The following is an excellent example of the IETF
passive mood: "It is implicitly presumed that this process will apply
not
  only to the initial definition of a protocol, but also to any
  subsequent updates, such that continued interoperability can be
  guaranteed.  However, it is not always clear whether extensions to
a
  protocol fall within this presumption, especially when they
originate
  outside the IETF community."  Who has the presumption?  Is the
presumption good?

Second, I agree with last call comments that the document as it stands
today really sounds like "IETF good, other SDOs bad."

Finally, I don't find the advice credible.  Section 3 admits that
there are minor extensions and major extensions, but seems to say that
I should go ask the IETF about everything so I can be told if it is
minor or major.  There are a lot of cases where I don't think we want
to spend a lot of time on review.  Someone has a new application they
want to run over TCP.  Do we really want them to submit an
internet-draft?  Is it credible for us to expect them to do so?  What
about other FCFS registrations?  I realize that deciding when we want
significant review and when we do not is a hard question, but I think
that to be taken seriously we'd need to actually come up with a more
complete answer to that question.

Finally, I think the document suffers from a lack of a definition of
interoperability.  I brought up that issue as what I hoped was a way
to solve Robert's appeal.  However as I read the document, I think it
is a really serious issue.  There are many SDOs who produce
technologies that are interoperable within environments where the
technology is profiled to work.  These SDOs design their standards to
work within well-defined environments and may not expect environments
to mix or may expect gateways and conversions to be needed when there
is such mixing.  Explaining why that's not true for the IETF and
providing some justification seems critical to this document coming
across as credible.

[Ballot comment]
It's almost laughable to use RADIUS as an example here as for many years, much to the dismay of many folks and SDOs, RADIUS did *not* have a WG to come to within the IETF. Further, the radext wg that finally exists today is rather limited in what kinds of extensions it may take on.

>    For example, RADIUS [RFC2865] is designed to carry attributes and
>    allow definition of new attributes.  But it is important that
>    discussion of new attributes involve the IETF community of experts
>    knowledgeable about the protocol's architecture and existing usage in
>    order to fully understand the implications of a proposed extension.
>    Adding new attributes without such discussion creates a high risk of
>    interoperability or functionality failure.  For this reason among
>    others, the IETF has an active RADIUS Extensions working group at the
>    time of writing.

[Ballot comment]
I continue to think that this is needlessly pejorative:

  When extensions to IETF protocols are made outside the IETF and
  without consulting the IETF, experience has shown that they may not
  be done with the full understanding of why the existing protocol was
  designed the way that it is - e.g., what ideas were brought up during
  the original development and rejected because of some problem with
  them.  Also such extensions could, because of a lack of
  understanding, negate some key function of the existing protocol
  (such as security or congestion control).  Short-sighted design
  choices are sometimes made, and basic underlying architectural
  principles of the protocol are sometimes violated.  Of course, the
  IETF itself is not immune to such mistakes, suggesting a need for
  working groups to document their design decisions (including paths
  rejected) and some rationale for those decisions, for the benefit of
  both those within IETF and those outside of IETF.

and the procedure documented is needlessly paternalistic.  Saying that
the first step in definining an extension should be picking how to bring
it to the IETF is presumptious--specifically, it presumes that the IETF
has engineering talent and energy to spare for this review, which has
turned out to be a bad mistake in previous working relations.  It is also
often the case that subject matter experts are spread through the industry,
and the IETF may not have an active set of them any more.  This is true,
for example, of both HTTP and FTP.

I also think this document is not really clear about how design decisions
at the protocol development phase make it easy or hard to get extension
done.

All that said, I am holding my nose.  This has been around for a long time,
and put something into print for further work makes sense.

[Ballot comment]
Section 1., paragraph 9:
>    All that can be said about extensions applies with equal or greater
>    force to variations - in fact, by definition, protocol variations
>    damage interoperability.  They must therefore be intensely
>    scrutinized.  Throughout this document, what is said about extensions
>    also applies to variations.

  A sentence on the differences between an extension and a variation
  would not hurt. Also, sometimes other SDOs propose interrelated
  extensions to multiple protocols, i.e., an extension of the
  architecture, which I'm not sure falls under "variation."


Section 2.3., paragraph 3:
>    The proper forum for such review is the IETF,
>    either in the relevant Working Group, or by individual IETF experts
>    if no such WG exists.

  Nit: maybe s/relevant Working Group/relevant Working Group or Area/


Section 3., paragraph 6:
>      This should be done at an early
>      stage, before a large investment of effort has taken place, in
>      case basic problems are revealed.

  Nit: maybe s/basic/fundamental/

[Ballot comment]
Was this document reviewed by external Standards Development Organizations? I know that it was in IETF Last Call, but was the last call pro-actively announced to other SDOs, and were any comments received? I believe that because of the implications of the relations between the IETF and other SDOs and in order to ensure that the process of extending IETF protocols is well understood externally such feedback is important.

This document discusses procedural issues related to the extensibility of IETF protocols, including when it is reasonable to extend IETF protocols with little or no review, and when extensions or variations need to be reviewed by the larger IETF community.  Experience with IETF protocols has shown that extensibility of The document recommends that major extensions to or variations of IETF protocols only take place through normal IETF processes or in coordination with the IETF.