Re: [nbs] First draft agenda

Rémi Després <remi.despres@free.fr> Wed, 27 October 2010 13:31 UTC

Return-Path: <remi.despres@free.fr>
X-Original-To: nbs@core3.amsl.com
Delivered-To: nbs@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F3473A67FB for <nbs@core3.amsl.com>; Wed, 27 Oct 2010 06:31:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.541
X-Spam-Level:
X-Spam-Status: No, score=-1.541 tagged_above=-999 required=5 tests=[AWL=0.408, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q2oVDuCi3wzY for <nbs@core3.amsl.com>; Wed, 27 Oct 2010 06:31:37 -0700 (PDT)
Received: from smtp22.services.sfr.fr (smtp22.services.sfr.fr [93.17.128.10]) by core3.amsl.com (Postfix) with ESMTP id E9EAF3A6A1A for <nbs@ietf.org>; Wed, 27 Oct 2010 06:31:22 -0700 (PDT)
Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2218.sfr.fr (SMTP Server) with ESMTP id E97127000091; Wed, 27 Oct 2010 15:33:11 +0200 (CEST)
Received: from [192.168.0.23] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2218.sfr.fr (SMTP Server) with ESMTP id 7AC0A7000097; Wed, 27 Oct 2010 15:33:11 +0200 (CEST)
X-SFR-UUID: 20101027133311502.7AC0A7000097@msfrf2218.sfr.fr
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: text/plain; charset=iso-8859-1
From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= <remi.despres@free.fr>
In-Reply-To: <116CC7E2-56EF-4FC9-8B8B-295C20E3563F@nokia.com>
Date: Wed, 27 Oct 2010 15:33:10 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <FEC5F585-C483-41A6-B026-55F9EEB0F5F0@free.fr>
References: <E84E7B8FF3F2314DA16E48EC89AB49F0752719@PALLENE.office.hd> <722633D9-BA33-498E-A2A3-3194B6020806@nokia.com> <EBA3CA08-905F-4CAE-86E4-E05FD398FB20@free.fr> <116CC7E2-56EF-4FC9-8B8B-295C20E3563F@nokia.com>
To: Lars Eggert <lars.eggert@nokia.com>
X-Mailer: Apple Mail (2.1081)
Cc: "nbs@ietf.org" <nbs@ietf.org>, Martin Stiemerling <Martin.Stiemerling@neclab.eu>
Subject: Re: [nbs] First draft agenda
X-BeenThere: nbs@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Name based sockets discussion list <nbs.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/nbs>, <mailto:nbs-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/nbs>
List-Post: <mailto:nbs@ietf.org>
List-Help: <mailto:nbs-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nbs>, <mailto:nbs-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 27 Oct 2010 13:31:38 -0000

Le 27 oct. 2010 à 14:59, Lars Eggert a écrit :

> 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*.

Eggs or chicken problem!
You obviously know IETF rules much better than I do.
A WG may very well be premature at this stage.
What I hope though, if it is so, is that IETF can continue to be a place where solutions to identified problems can be discussed among specialists.
The lack of referrals that applications can use, and that don't depend on address changes is AFAIK an one of these identified problems. 

Regards,
RD

> 
> Lars