RE: sockets APIs extensions for Host Identity Protocol

Chris Newman <Chris.Newman@Sun.COM> Fri, 11 May 2007 23:46 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 1Hmeog-0002xD-Ho; Fri, 11 May 2007 19:46:30 -0400
Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1Hmeoe-0002x8-Lc for discuss-confirm+ok@megatron.ietf.org; Fri, 11 May 2007 19:46:28 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hmeoe-0002x0-Bq for discuss@apps.ietf.org; Fri, 11 May 2007 19:46:28 -0400
Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hmeoc-0007kn-Qc for discuss@apps.ietf.org; Fri, 11 May 2007 19:46:28 -0400
Received: from fe-amer-03.sun.com ([192.18.108.177]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l4BNkQai026187 for <discuss@apps.ietf.org>; Fri, 11 May 2007 23:46:26 GMT
Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JHW00201GZNRK00@mail-amer.sun.com> (original mail from Chris.Newman@Sun.COM) for discuss@apps.ietf.org; Fri, 11 May 2007 17:46:26 -0600 (MDT)
Received: from [10.1.110.5] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JHW00308I1AVR00@mail-amer.sun.com>; Fri, 11 May 2007 17:46:25 -0600 (MDT)
Date: Fri, 11 May 2007 16:46:25 -0700
From: Chris Newman <Chris.Newman@Sun.COM>
Subject: RE: sockets APIs extensions for Host Identity Protocol
In-reply-to: <77F357662F8BFA4CA7074B0410171B6D040492F2@XCH-NW-5V1.nw.nos.boeing.com>
To: "Henderson, Thomas R" <thomas.r.henderson@boeing.com>, Miika Komu <miika@iki.fi>, discuss@apps.ietf.org
Message-id: <0DC32C985E2B5065559C802B@[10.1.110.5]>
MIME-version: 1.0
X-Mailer: Mulberry/3.1.6 (Mac OS X)
Content-type: text/plain; format=flowed; charset=us-ascii
Content-transfer-encoding: 7BIT
Content-disposition: inline
References: <77F357662F8BFA4CA7074B0410171B6D040492F2@XCH-NW-5V1.nw.nos.boeing.c om>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17
Cc:
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

Henderson, Thomas R wrote on 5/8/07 9:43 -0700:
> Is the IETF in the business of defining this new API?  Or is the IETF
> scope limited to sockets, and the APIs that you seek are defined by
> library and OS developers?

The IETF's primary focus is to standardize protocols.  But standard protocols 
are of little value if they aren't deployed.  There are various ways to assist 
deployment of protocols and documented APIs are one way.  The IETF has a long 
tradition of publishing APIs, mostly as informational but occasionally on the 
standards track.  There are IETF published APIs of dubious quality that have 
still significantly helped deploy the underlying protocol (I'd point to the 
LDAP API as an example in the applications space).

> As a HIP WG participant, I see that there has been a history of RFCs for
> sockets API extensions (2292, 2960, 4584, etc.).  We could do a similar
> one for HIP, but Miika has proposed that we go for a more future-proof
> API and build in some abstraction.  It seems to me that there is support
> for defining such an API and it has already been done successfully for
> Java.

The primary design goal for an IETF API should be to ease deployment of IETF 
standards-track protocols.  If the APIs designed to ease deployment of HIP also 
ease deployment of IPv6 (which is clearly problematic), that would be a good 
thing.

The key principles from this discussion are:
* Don't bother the busy/lazy/dumb programmers with details they don't need
  or want to know (my point)
* Don't hide any details from programmers who do care (Keith's point)

Data hiding is often good, data losing is always bad.  Be careful to avoid the 
latter when designing those abstractions.

                - Chris