Re: [nbs] [Int-area] New draft related to name-based sockets

Joe Touch <> Thu, 09 December 2010 19:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B313028C14A; Thu, 9 Dec 2010 11:10:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id pvcElT1YXFlC; Thu, 9 Dec 2010 11:10:30 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id CDBB228C144; Thu, 9 Dec 2010 11:10:30 -0800 (PST)
Received: from [] ( []) (authenticated bits=0) by (8.13.8/8.13.8) with ESMTP id oB9JAjE5002812 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Thu, 9 Dec 2010 11:10:54 -0800 (PST)
Message-ID: <>
Date: Thu, 09 Dec 2010 11:10:43 -0800
From: Joe Touch <>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv: Gecko/20101027 Thunderbird/3.1.6
MIME-Version: 1.0
To: Pete McCann <>
References: <> <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
Cc: "" <>, "" <>
Subject: Re: [nbs] [Int-area] New draft related to name-based sockets
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Name based sockets discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 09 Dec 2010 19:10:31 -0000

On 12/9/2010 11:06 AM, Pete McCann wrote:
> Hi, Joe,
> Thanks for the issue list and the pointers to drafts.
> I agree that backwards compatibility is an issue, if we are blindly
> opening connections to previously unknown peers.  However, in
> the pickle packet framework, opening a connection would always
> be preceded by a DNS lookup for the TXT record at
> which, if present, would be an indication
> that the peer supports the new extensions.  So, I think there is
> little danger of running into the issues you cite.
> You might say that this is equivalent to defining a new transport,
> but I think it's important to keep the protocol number 6 because
> that is what today's middleboxes will pass.

But they won't. The read more than you think, including options. ;-(

Protocol 6 is an entire protocol, not just the default. If you want 
something inside that, you need to include framing.

However, this option is useful only in the SYN, IMO - as portnames 
pointed out. And that's the place where NATs are most problematic 
(stripping data, etc.).

On a separate point, presumes that _pickle is a 
transport, which it really isn't. Take a look at the SRV record specs, 
and the pending docs on that issue; I don't know what others feel about 
that, but that might a sticking point as well.