Shared Use of Experimental TCP Options
RFC 6994

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

(Ron Bonica) Yes

(Wesley Eddy) Yes

(Martin Stiemerling) Yes

(Jari Arkko) No Objection

(Richard Barnes) No Objection

(Gonzalo Camarillo) No Objection

(Benoît Claise) (was Discuss) No Objection

Comment (2013-03-18 for -05)
No email
send info
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

(Spencer Dawkins) No Objection

(Stephen Farrell) No Objection

(Russ Housley) No Objection

(Joel Jaeggli) No Objection

Comment (2013-03-18 for -05)
No email
send info
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.

(Barry Leiba) (was Discuss) No Objection

Comment (2013-02-25 for -04)
No email
send info
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!

(Ted Lemon) (was Discuss) No Objection

Comment (2013-06-10)
No email
send info
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.

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.

(Robert Sparks) No Objection

(Sean Turner) No Objection

(Stewart Bryant) (was No Objection) Abstain

Comment (2013-05-14 for -05)
No email
send info
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.

(Ralph Droms) (was Discuss) Abstain

Comment (2013-02-18 for -03)
No email
send info
Based on the discussion of my objection to this document, I am moving to Abstain before stepping down as Int AD.

(Adrian Farrel) Abstain

Comment (2012-12-18 for -03)
No email
send info
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) (was Discuss) Abstain

Comment (2012-12-20 for -03)
No email
send info
Given the discussions during the IESG call, I am moving to Abstain.

(Pete Resnick) (was No Objection) Abstain

Comment (2012-12-20 for -03)
No email
send info
I am convinced by the IESG discussion that this is not appropriate for a standards track document.