Procedures for Protocol Extensions and Variations
RFC 4775

Note: This ballot was opened for revision 04 and is now closed.

(Jari Arkko) Yes

(Ross Callon) Yes

(Lars Eggert) Yes

Comment (2006-09-12 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
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/

(Sam Hartman) (was Discuss) Yes

(Cullen Jennings) Yes

Comment (2006-09-11 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
Trivial typo s/prroblems/problems/

(Lisa Dusseault) No Objection

(Bill Fenner) No Objection

(Russ Housley) No Objection

Comment (2006-09-14 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
  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/

(David Kessens) No Objection

(Dan Romascanu) No Objection

Comment (2006-09-08 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
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.

(Mark Townsley) No Objection

Comment (2006-09-13 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
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.

Magnus Westerlund No Objection

Comment (2006-09-13 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
I am in support of Ted's comment about tone. Especially in the introduction part.

(Ted Hardie) Abstain

Comment (2006-09-12 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
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.

(Jon Peterson) Abstain

(Brian Carpenter) Recuse