Re: sockets APIs extensions for Host Identity Protocol

der Mouse <mouse@Rodents.Montreal.QC.CA> Mon, 07 May 2007 22:16 UTC

Return-path: <discuss-bounces@apps.ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlBVH-0001xe-16; Mon, 07 May 2007 18:16:23 -0400
Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HlBVG-0001xZ-GK for discuss-confirm+ok@megatron.ietf.org; Mon, 07 May 2007 18:16:22 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlBVG-0001xR-6u for discuss@apps.ietf.org; Mon, 07 May 2007 18:16:22 -0400
Received: from sparkle.rodents.montreal.qc.ca ([216.46.5.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HlBVE-0003Sp-5G for discuss@apps.ietf.org; Mon, 07 May 2007 18:16:22 -0400
Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id SAA06179; Mon, 7 May 2007 18:16:16 -0400 (EDT)
From: der Mouse <mouse@Rodents.Montreal.QC.CA>
Message-Id: <200705072216.SAA06179@Sparkle.Rodents.Montreal.QC.CA>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway.
X-Message-Flag: Microsoft: the company who gave us the botnet zombies.
Date: Mon, 7 May 2007 18:07:14 -0400 (EDT)
To: discuss@apps.ietf.org
Subject: Re: sockets APIs extensions for Host Identity Protocol
In-Reply-To: <31BC7A8C1A51004A84E08DEF@[10.1.110.5]>
References: <Pine.SOL.4.64.0705041801060.14418@kekkonen.cs.hut.fi> <31BC7A8C1A51004A84E08DEF@[10.1.110.5]>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 52e1467c2184c31006318542db5614d5
X-BeenThere: discuss@apps.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: general discussion of application-layer protocols <discuss.apps.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/discuss>, <mailto:discuss-request@apps.ietf.org?subject=unsubscribe>
List-Post: <mailto:discuss@apps.ietf.org>
List-Help: <mailto:discuss-request@apps.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/discuss>, <mailto:discuss-request@apps.ietf.org?subject=subscribe>
Errors-To: discuss-bounces@apps.ietf.org

> Application software wants to work with strings.  [...]

> If I change my "connectbyname" code again, I will change it once more
> to use a new OS API that hides all the v4 vs. v6 vs. HIP vs. whatever
> junk, preferably to something much simpler than the code today.

Something wrong with getaddrinfo()?  It certainly could use something
HIPish under the hood, if some implementor decided to.

>> A potential benefit of the handles is that it would make the API
>> future-proof againts changes to the HIT size.

getaddrinfo() already is...or at least, it is when used correctly, and
in this respect it's easier to use it correctly than incorrecetly
(which is about all you can expect).  It's a slightly broken API, true,
but the problems with it are not in areas that any putative HIP/HIT
stuff would fix.

>> Similarly, one might argue that the IPv6 transition would have been
>> a lot easier for applications if the concept of endpoint descriptor
>> were already available for the past twenty years;

That concept *has* been available for the past twenty years; it's
called a "socket".  What hasn't been available is a socket
implementation that doesn't expose the underlying addressing details to
the application.  This could be - and arguably should be - fixed
entirely under the socket-layer hood, not by inventing new protocols
and exposing *them* to the application.  I speculate that the major
reason this hasn't been done is tradition - sockets have traditionally
been a fairly direct interface into the kernel, and preserving that
while presenting this kind of socket interface is relatively hard.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B