Procedures for Protocol Extensions and Variations
draft-carpenter-protocol-extensions-04
Yes
(Jari Arkko)
(Ross Callon)
(Sam Hartman)
No Objection
(Bill Fenner)
(David Kessens)
(Lisa Dusseault)
Abstain
(Jon Peterson)
Recuse
(Brian Carpenter)
Note: This ballot was opened for revision 04 and is now closed.
Cullen Jennings Former IESG member
Yes
Yes
(2006-09-11)
Unknown
Trivial typo s/prroblems/problems/
Jari Arkko Former IESG member
Yes
Yes
()
Unknown
Lars Eggert Former IESG member
Yes
Yes
(2006-09-12)
Unknown
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/
Ross Callon Former IESG member
Yes
Yes
()
Unknown
Sam Hartman Former IESG member
(was Discuss)
Yes
Yes
()
Unknown
Bill Fenner Former IESG member
No Objection
No Objection
()
Unknown
Dan Romascanu Former IESG member
No Objection
No Objection
(2006-09-08)
Unknown
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.
David Kessens Former IESG member
No Objection
No Objection
()
Unknown
Lisa Dusseault Former IESG member
No Objection
No Objection
()
Unknown
Magnus Westerlund Former IESG member
No Objection
No Objection
(2006-09-13)
Unknown
I am in support of Ted's comment about tone. Especially in the introduction part.
Mark Townsley Former IESG member
No Objection
No Objection
(2006-09-13)
Unknown
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.
Russ Housley Former IESG member
No Objection
No Objection
(2006-09-14)
Unknown
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/
Jon Peterson Former IESG member
Abstain
Abstain
()
Unknown
Ted Hardie Former IESG member
Abstain
Abstain
(2006-09-12)
Unknown
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.
Brian Carpenter Former IESG member
Recuse
Recuse
()
Unknown