Re: [nbs] First draft agenda

"David Harrington" <> Tue, 02 November 2010 01:26 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 38CA43A681D for <>; Mon, 1 Nov 2010 18:26:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.412
X-Spam-Status: No, score=-102.412 tagged_above=-999 required=5 tests=[AWL=-0.113, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id q1LhxOPoFT48 for <>; Mon, 1 Nov 2010 18:26:38 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 1ADBD3A6804 for <>; Mon, 1 Nov 2010 18:26:38 -0700 (PDT)
Received: from ([]) by with comcast id RoCK1f00117dt5G5E1ShFH; Tue, 02 Nov 2010 01:26:41 +0000
Received: from 23FX1C1 ([]) by with comcast id S1Sg1f00J2JQnJT3Z1SggZ; Tue, 02 Nov 2010 01:26:41 +0000
From: "David Harrington" <>
To: "'Lars Eggert'" <>, =?iso-8859-1?Q?'R=E9mi_Despr=E9s'?= <>
References: <><><> <>
Date: Tue, 2 Nov 2010 09:26:45 +0800
Message-ID: <E6D8CA28C4E448FAA7279F89336D2515@23FX1C1>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Office Outlook 11
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5994
Thread-Index: Act11s6cMp3s6RMRR9u4ls/CZRzopAEVN5wA
In-Reply-To: <>
Cc:, 'Martin Stiemerling' <>
Subject: Re: [nbs] First draft agenda
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: Tue, 02 Nov 2010 01:26:39 -0000


I agree with Lars that we need to see whether vendors and customers
are interested, not just protocol designers.

I think it is important to remember that the IETF is about engineering
standards for inetroperability. 
and typically, multiple deployed solutions are brought together to
consider what common features can be standardized.
I strongly encourage people who are interested in this work to
convince their companies to produce products that their customers can
use to solve the problem. If a number of companies find common
solutions, then we can help standardize the common parts so they will
be interoperabile across vendors.

Specifying a theoretical approach to separating identifiers and
addresses, that nobody is actually implementing or using, strikes me
as still being conjecture, or, if being done in limited projects,
Maybe these ideas and this work should be documented in the IRTF or
peer-reviewed academic journals. 
Maybe it's not ready for IETF standards engineering.

But I'm willing to listen to the ideas and to see whether there is
interest in multi-vendor interoperability.


> -----Original Message-----
> From: [] On 
> Behalf Of Lars Eggert
> Sent: Wednesday, October 27, 2010 8:59 PM
> To: Rémi Després
> Cc:; Martin Stiemerling
> Subject: Re: [nbs] First draft agenda
> HI,
> On 2010-10-27, at 15:33, Rémi Després wrote:
> > Yes, knowing whether some OS or application implementers 
> already are, at this early stage, interested in Name Based 
> Sockets  can be a useful third issue.
> > 
> > But even if there is none today, this IMHO doesn't mean 
> that those that are ready to spend energy to make a sound 
> proposal should be discouraged: 
> > - We know we need referrals that don't depend on addresses 
> (addresses may be dynamic or subject to renumbering).
> > - Using names for this is an alternative to other 
> locator/identifier separation approaches.
> > - It has the distinct advantage leveraging existing 
> Internet specifications such as the DNS and IPv6 address 
> formats, rather than departing from them.
> I'm with you until here.
> > For OS and Application vendors to make their an opinion, 
> clearly explaining first what is meant by named based sockets 
> seems a quite reasonable approach.
> Here I have to disagree. We don't (normally) charter WGs in 
> the IETF to explain technologies. We charter WGs to produce 
> specifications so that interoperable implementations can be 
> built. A specification is not a good way to explain a 
> technology or motivate its adoption, that needs to come *first*.
> Lars