In followup to our TAE bar-BOF on Tuesday, here is an initial draft  
for a negotiation BOF charter - please bash on it...

---

A major challenge the Internet faces in the evolution to and  
deployment of new protocols is enabling upgraded hosts to detect  
efficiently whether a would-be communication partner supports the new  
protocols, and automatically fall back on older protocols if not.  If  
the upgraded host first attempts to use the new protocol and falls  
back to the old protocol only after the former attempt fails, the host  
risks incurring long timeout delays on connection that are highly  
visible and annoying to users, greatly decreasing the likeliness that  
users, operating system vendors, or application vendors will adopt the  
new protocols.  If the upgraded host attempts connections using the  
new and old protocols simultaneously, the host wastes resources both  
in the network (redundant initialization packets) and on the end hosts  
(redundant transport control blocks when multiple connection attempts  
succeed but only one is needed).

Some inefficiency due to concurrent connection attempts is probably  
tolerable and perhaps unavoidable in the interest of enabling  
negotiation without risking long startup delays, but this approach  
alone will not scale in the long term, for two reasons.  First, the  
number of alternative protocols among which to negotiate may increase  
over time.  If an application can run atop TCP, SCTP, or DCCP, then  
negotiating among them may incur the network and end host costs of  
three redundant connections, not just two.

Second, negotiation is often needed at multiple layers  
simultaneously.  At the network layer, to enable deployment of IPv6  
without risking poor user experiences, a host needs to be able to try  
connecting via IPv6 but fall back to IPv4 if necessary without  
incurring long delays.  At the application layer, applications often  
need to decide whether to operate with or without TLS, which can be  
problematic if the original application protocol was not designed to  
support TLS negotiation and was not assigned a separate port number  
for its TLS variant, or an application may wish to negotiate  
efficiently between multiple similar or equivalent application  
protocols without the user's involvement: e.g., POP3 versus IMAP, SIP  
versus IAX2.  If a host tries to make negotiation decisions for each  
layer serially (i.e., first choose IPv4 or IPv6, then TCP versus SCTP  
versus DCCP, then SIP versus IAX2), then it risks even longer  
connection delays.  If a host tries to make all such negotiation  
decisions in parallel via simultaneous connection attempts, then the  
combinations multiply across layers: e.g., with two alternatives at  
the network layer, two at the transport layer, and two at the  
application layer, a host will be attempting eight simultaneous  
connection attempts, an explosion that will quickly become infeasible.

The task of the proposed Negotiation (NEGO) BOF will explore the  
development and specification of both short-term and longer-term  
solutions to this negotiation problem.  Short-term work would address  
specific common cases that are of some immediate urgence, such as  
negotiating efficiently between the IPv4 and IPv6 versions of a single  
TCP-based application protocol such as HTTP - a problem that is urgent  
because of the imminent exhaustion of the IPv4 address space.  Longer- 
term work would be to develop a negotiation mechanism addressing the  
scalability problems discussed above.  Technical details such as  
whether this negotiation mechanism would operate out-of-band (e.g.,  
via DNS) or in-band (directly between the hosts wishing to  
communicate) will have to be decided within the group.

Tentative work items, vaguely in order from short-term to long-term:
	- Best current practice(?) on negotiating between the IPv4 and IPv6  
versions of a single transport and application protocol.
	- Specification of generic, extensible negotiation protocol or  
framework ("Nego")
	- Spec for using Nego to migrate to new transports with fallback to TCP
	- Spec for using Nego to migrate to new transports with fallback to UDP
	- Spec for using Nego to negotiate use of transport with vs without  
TLS/DTLS
	- Spec for using Nego to negotiate among application-layer protocols

Reference materials:
	- "Happy Eyeballs: Successful Introduction of New Technology to HTTP"
		http://tools.ietf.org/html/draft-wing-http-new-tech-00
	- "An Efficient Cross-Layer Negotiation Protocol"
		http://bford.info/pub/net/nego.pdf

---

Comments?
Bryan