Shared Use of Experimental TCP Options
draft-ietf-tcpm-experimental-options-06
Yes
(Martin Stiemerling)
(Ron Bonica)
(Wesley Eddy)
No Objection
(Gonzalo Camarillo)
(Jari Arkko)
(Richard Barnes)
(Robert Sparks)
(Russ Housley)
(Sean Turner)
(Spencer Dawkins)
(Stephen Farrell)
Abstain
Note: This ballot was opened for revision 03 and is now closed.
Martin Stiemerling Former IESG member
Yes
Yes
(for -03)
Unknown
Ron Bonica Former IESG member
Yes
Yes
(for -03)
Unknown
Wesley Eddy Former IESG member
Yes
Yes
(for -03)
Unknown
Barry Leiba Former IESG member
(was Discuss)
No Objection
No Objection
(2013-02-25 for -04)
Unknown
I think the changes in -04 are a fine compromise, providing an FCFS registry for those willing to use it, and giving advice for dealing with situation when the registry isn't used. Thanks very much to the authors and the working group for sorting this out!
Benoît Claise Former IESG member
(was Discuss)
No Objection
No Objection
(2013-03-18 for -05)
Unknown
Hi Joe, Thanks for your effort on this draft. I'll clear my DISCUSS now. The draft improved a lot during our discussion. Discussing with Martin and Wes during the IETF last week, we concluded that it would be appropriate to restart the ballot on this draft. Indeed, IMHO, the draft improved so much that I believe that some IESG members might clear their ABSTAIN ... which is always a preferred outcome if possible. Regards, Benoit
Gonzalo Camarillo Former IESG member
No Objection
No Objection
(for -03)
Unknown
Jari Arkko Former IESG member
No Objection
No Objection
(2013-06-03 for -05)
Unknown
Joel Jaeggli Former IESG member
No Objection
No Objection
(2013-03-18 for -05)
Unknown
In light of the more recent drafts, I'm fine with logging my position as no objection. I'm not sure that I interpret 3692 quite as strongly as Adrian's discuss does. while there is certainly a temptation to squat on experimental code points due to the size of the space, the potential for less pollution of the registered code point range seems like it has fewer consequences then what is otherwise expected to continue to happen.
Richard Barnes Former IESG member
No Objection
No Objection
(for -05)
Unknown
Robert Sparks Former IESG member
No Objection
No Objection
(for -03)
Unknown
Russ Housley Former IESG member
No Objection
No Objection
(for -03)
Unknown
Sean Turner Former IESG member
No Objection
No Objection
(for -03)
Unknown
Spencer Dawkins Former IESG member
No Objection
No Objection
(2013-05-15 for -05)
Unknown
Stephen Farrell Former IESG member
No Objection
No Objection
(2013-05-13 for -05)
Unknown
Ted Lemon Former IESG member
(was Discuss)
No Objection
No Objection
(2013-06-10)
Unknown
Based on the recent update to the document, I'm moving this to a No Objection. I don't really think that the document has fully addressed the points raised here, but given the state of the consensus on this question in the working group, I'm afraid I'm not going to get much more movement, so I'll take what I can get. Former DISCUSS: I don't think it adds value to have the ExID be of variable length. It's highly implausible that there could be 64k TCP experiments in the reasonable lifetime of this policy, particularly now that the code space is being managed by the IANA. Two bytes in the TCP header is a lot, and alignment of 4-byte integers is easy to fix. I think that using a 4-byte ExID runs a real risk of overflowing the available space in the TCP header in real-world circumstances.
Adrian Farrel Former IESG member
Abstain
Abstain
(2012-12-18 for -03)
Unknown
Note that you have 3692 transposed as 3962! I find this symptomatic :-( --- I am Abstaining on this document. I understand it as a pragmatic extension of the experimental codepoint space, but I believe that RFC 3692 (sic) is deliberately precise about the value of limiting the experimental space and gives good reasons. I cannot support this document going against the philosophy of 3692, and I think it would have been far better to encourage the use of non-experimental options and possibly make it easier to register non-experimental options. However, I do not believe I should block the pragmatic solution in this document that clearly has consensus support.
Brian Haberman Former IESG member
(was Discuss)
Abstain
Abstain
(2012-12-20 for -03)
Unknown
Given the discussions during the IESG call, I am moving to Abstain.
Pete Resnick Former IESG member
(was No Objection)
Abstain
Abstain
(2012-12-20 for -03)
Unknown
I am convinced by the IESG discussion that this is not appropriate for a standards track document.
Ralph Droms Former IESG member
(was Discuss)
Abstain
Abstain
(2013-02-18 for -03)
Unknown
Based on the discussion of my objection to this document, I am moving to Abstain before stepping down as Int AD.
Stewart Bryant Former IESG member
(was No Objection)
Abstain
Abstain
(2013-05-14 for -05)
Unknown
This is a significant improvement over the version that I previously reviewed. Although significant steps have been taken to improve the document, the risk of collision due to unregistered use or registration of a collision is still acknowledged. I would find this less objectionable in an Informational or Experimental document, but in a Standards Track document I find it difficult to accept anything other than required registration (which may be confidential to IANA) to ensure the absence of a collision.