Skip to main content

Procedures for Protocol Extensions and Variations
draft-carpenter-protocol-extensions-04

Revision differences

Document history

Date Rev. By Action
2012-08-22
04 (System) post-migration administrative database adjustment to the Yes position for Sam Hartman
2006-11-08
04 (System) Request for Early review by SECDIR Completed. Reviewer: Juergen Quittek.
2006-10-23
04 Amy Vezza State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza
2006-10-16
04 Amy Vezza IESG state changed to Approved-announcement sent
2006-10-16
04 Amy Vezza IESG has approved the document
2006-10-16
04 Amy Vezza Closed "Approve" ballot
2006-10-13
04 (System) Removed from agenda for telechat - 2006-10-12
2006-10-12
04 Amy Vezza State Changes to Approved-announcement to be sent from IESG Evaluation::AD Followup by Amy Vezza
2006-10-10
04 Ross Callon Placed on agenda for telechat - 2006-10-12 by Ross Callon
2006-10-06
04 (System) New version available: draft-carpenter-protocol-extensions-04.txt
2006-09-27
04 Sam Hartman [Ballot Position Update] Position for Sam Hartman has been changed to Yes from Discuss by Sam Hartman
2006-09-25
04 (System) Sub state has been changed to AD Follow up from New Id Needed
2006-09-25
03 (System) New version available: draft-carpenter-protocol-extensions-03.txt
2006-09-14
04 Amy Vezza State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation by Amy Vezza
2006-09-14
04 Jon Peterson [Ballot Position Update] New position, Abstain, has been recorded by Jon Peterson
2006-09-14
04 Lisa Dusseault [Ballot Position Update] New position, No Objection, has been recorded by Lisa Dusseault
2006-09-14
04 Russ Housley
[Ballot comment]
Section 1 says:
  >
  > ... experience has shown that they may not be done with the full
  > understanding …
[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/
2006-09-14
04 Russ Housley [Ballot Position Update] New position, No Objection, has been recorded by Russ Housley
2006-09-14
04 Jari Arkko [Ballot Position Update] New position, Yes, has been recorded by Jari Arkko
2006-09-13
04 Bill Fenner [Ballot Position Update] New position, No Objection, has been recorded by Bill Fenner
2006-09-13
04 David Kessens [Ballot Position Update] New position, No Objection, has been recorded by David Kessens
2006-09-13
04 Sam Hartman
[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 …
[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.
2006-09-13
04 Sam Hartman [Ballot Position Update] New position, Discuss, has been recorded by Sam Hartman
2006-09-13
04 Mark Townsley
[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, …
[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.
2006-09-13
04 Mark Townsley [Ballot Position Update] New position, No Objection, has been recorded by Mark Townsley
2006-09-13
04 Magnus Westerlund [Ballot comment]
I am in support of Ted's comment about tone. Especially in the introduction part.
2006-09-13
04 Magnus Westerlund [Ballot Position Update] New position, No Objection, has been recorded by Magnus Westerlund
2006-09-12
04 Ted Hardie
[Ballot comment]
I continue to think that this is needlessly pejorative:

  When extensions to IETF protocols are made outside the IETF and
  without …
[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.
2006-09-12
04 Ted Hardie [Ballot Position Update] New position, Abstain, has been recorded by Ted Hardie
2006-09-12
04 Dan Romascanu [Ballot Position Update] New position, No Objection, has been recorded by Dan Romascanu
2006-09-12
04 Lars Eggert
[Ballot comment]
Section 1., paragraph 9:
>    All that can be said about extensions applies with equal or greater
>    force to variations …
[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/
2006-09-12
04 Lars Eggert [Ballot Position Update] New position, Yes, has been recorded by Lars Eggert
2006-09-11
04 Cullen Jennings [Ballot Position Update] New position, Yes, has been recorded by Cullen Jennings
2006-09-11
04 Cullen Jennings [Ballot comment]
Trivial typo s/prroblems/problems/
2006-09-10
02 (System) New version available: draft-carpenter-protocol-extensions-02.txt
2006-09-08
04 Yoshiko Fong IANA Last Call Comment:

As described in the IANA Considerations section, we understand this document
to have NO IANA Actions.
2006-09-08
04 Brian Carpenter [Ballot Position Update] New position, Recuse, has been recorded by Brian Carpenter
2006-09-08
04 Dan Romascanu
[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 …
[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.
2006-09-07
04 Ross Callon State Changes to IESG Evaluation from Waiting for Writeup by Ross Callon
2006-09-07
04 Ross Callon Ballot has been issued by Ross Callon
2006-09-07
04 Ross Callon [Ballot Position Update] New position, Yes, has been recorded for Ross Callon
2006-09-07
04 Ross Callon Ballot has been issued by Ross Callon
2006-09-07
04 Ross Callon Created "Approve" ballot
2006-09-07
04 Ross Callon Placed on agenda for telechat - 2006-09-14 by Ross Callon
2006-09-05
04 (System) State has been changed to Waiting for Writeup from In Last Call by system
2006-08-08
04 Amy Vezza Last call sent
2006-08-08
04 Amy Vezza State Changes to In Last Call from Last Call Requested by Amy Vezza
2006-08-08
04 Ross Callon State Changes to Last Call Requested from Publication Requested by Ross Callon
2006-08-08
04 Ross Callon Last Call was requested by Ross Callon
2006-08-08
04 (System) Ballot writeup text was added
2006-08-08
04 (System) Last call text was added
2006-08-08
04 (System) Ballot approval text was added
2006-08-08
04 Ross Callon
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 …
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.
2006-08-08
04 Ross Callon Draft Added by Ross Callon in state Publication Requested
2006-08-04
01 (System) New version available: draft-carpenter-protocol-extensions-01.txt
2006-06-19
00 (System) New version available: draft-carpenter-protocol-extensions-00.txt