Skip to main content

Quick-Start for TCP and IP
draft-ietf-tsvwg-quickstart-07

Yes

(Lars Eggert)

No Objection

(Bill Fenner)
(Brian Carpenter)
(Cullen Jennings)
(Dan Romascanu)
(David Kessens)
(Lisa Dusseault)
(Magnus Westerlund)
(Ross Callon)
(Russ Housley)

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

Lars Eggert Former IESG member
Yes
Yes () Unknown

                            
Bill Fenner Former IESG member
No Objection
No Objection () Unknown

                            
Brian Carpenter Former IESG member
(was Discuss) No Objection
No Objection () Unknown

                            
Cullen Jennings Former IESG member
No Objection
No Objection () Unknown

                            
Dan Romascanu Former IESG member
No Objection
No Objection () Unknown

                            
David Kessens Former IESG member
No Objection
No Objection () Unknown

                            
Jari Arkko Former IESG member
No Objection
No Objection (2006-10-11) Unknown
This is a very interesting and great spec.
But I still worry about the practical tradeoff
for early deployers implied by the experimental 
results:

    Measurement studies of interactions between transport protocols and
    middleboxes [MAF04] show that for 70% of the web servers
    investigated, no connection is established if the TCP SYN packet
    contains an unknown IP option  ...
    If the TCP sender doesn't receive a response to the SYN or SYN/ACK
    packet containing the Quick-Start Request, then the TCP sender
    SHOULD resend the SYN or SYN/ACK packet without the Quick-Start
    ...

And the cost evaluation in Section 9.2 does not take this
into account at all, as far as I can see.
Lisa Dusseault Former IESG member
No Objection
No Objection () Unknown

                            
Magnus Westerlund Former IESG member
No Objection
No Objection () Unknown

                            
Mark Townsley Former IESG member
(was Discuss, No Objection) No Objection
No Objection (2006-10-11) Unknown
    If the tunnel ingress for the simple tunnel is at a router, the IP
    TTL of the inner header is generally decremented during forwarding
    before tunnel encapsulation takes place.

This is not true for L2TP tunnels, though I understand that the document is not making any specific claim about L2TP at this time. For IPinIP and GRE tunnels, the TTL is decremented on ingress and egress for each tunnel. For L2TP, it is only decremented at an LNS, which is typically the egress of the tunnel.
Ross Callon Former IESG member
No Objection
No Objection () Unknown

                            
Russ Housley Former IESG member
No Objection
No Objection () Unknown