Re: Service Identity (Re: Machine Identity)

Jeroen Massar <jeroen@unfix.org> Thu, 28 February 2008 16:41 UTC

Return-Path: <discuss-bounces@ietf.org>
X-Original-To: ietfarch-discuss-archive@core3.amsl.com
Delivered-To: ietfarch-discuss-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 879B43A69A0; Thu, 28 Feb 2008 08:41:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001]
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 RFz05fZRjo4V; Thu, 28 Feb 2008 08:41:01 -0800 (PST)
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5963228C42E; Thu, 28 Feb 2008 08:41:01 -0800 (PST)
X-Original-To: discuss@core3.amsl.com
Delivered-To: discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D89028C4D6 for <discuss@core3.amsl.com>; Thu, 28 Feb 2008 08:41:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
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 hL9spT-i6eSS for <discuss@core3.amsl.com>; Thu, 28 Feb 2008 08:40:49 -0800 (PST)
Received: from abaddon.unfix.org (abaddon.unfix.org [IPv6:2001:41e0:ff00:0:216:3eff:fe00:4]) by core3.amsl.com (Postfix) with ESMTP id 7261F28C73A for <discuss@apps.ietf.org>; Thu, 28 Feb 2008 08:40:49 -0800 (PST)
Received: from [IPv6:2001:41e0:ff42:b00:216:cfff:fe00:e7d0] (spaghetti.ch.unfix.org [IPv6:2001:41e0:ff42:b00:216:cfff:fe00:e7d0]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jeroen) by abaddon.unfix.org (Postfix) with ESMTPSA id 2411E40202E; Thu, 28 Feb 2008 17:40:41 +0100 (CET)
Message-ID: <47C6E40D.8060002@spaghetti.zurich.ibm.com>
Date: Thu, 28 Feb 2008 17:40:45 +0100
From: Jeroen Massar <jeroen@unfix.org>
Organization: Unfix
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.12) Gecko/20080213 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666
MIME-Version: 1.0
To: j.schoenwaelder@jacobs-university.de
Subject: Re: Service Identity (Re: Machine Identity)
References: <20080226130527.GA1404@generic-nic.net> <20080228112318.GA23196@nic.fr> <20080228114656.GD8439@elstar.local> <Pine.SOL.4.64.0802281405360.10117@kekkonen.cs.hut.fi> <47C6BA02.9090000@spaghetti.zurich.ibm.com> <0aea01c87a12$95cc8df0$0600a8c0@china.huawei.com> <47C6CB64.9060704@spaghetti.zurich.ibm.com> <20080228160422.GK8852@elstar.local>
In-Reply-To: <20080228160422.GK8852@elstar.local>
X-Enigmail-Version: 0.95.6
OpenPGP: id=333E7C23
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="------------enig4AFE0B5262F4AD26F9360DD2"
X-Virus-Scanned: ClamAV version 0.92.1, clamav-milter version 0.92.1 on abaddon.unfix.org
X-Virus-Status: Clean
Cc: discuss@apps.ietf.org
X-BeenThere: discuss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: general discussion of application-layer protocols <discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/discuss>, <mailto:discuss-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:discuss@ietf.org>
List-Help: <mailto:discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/discuss>, <mailto:discuss-request@ietf.org?subject=subscribe>
Sender: discuss-bounces@ietf.org
Errors-To: discuss-bounces@ietf.org

Juergen Schoenwaelder wrote:
[..]
> Some 10+ years ago, SNMP decoupled the identity of an SNMP service
> from the transport used to access the service by introducing the
> notion of an engineID. It was architecturally the right thing to
> do. At that time, people hoped that management applications would at
> start using engineIDs since they are architecturally the right thing
> to deal with proxies, NATs and all sort of issues. Ten years later, we
> must simply observe that this did not happen. Perhaps HIP as a more
> general solution to this problem has more luck.

I don't think that programs are going to adopt this, simply because the 
programmers don't know about it and because there is no easy way to have 
it available on the platforms they want to program for. If there was a 
simple API for this which worked on all platforms and had a BSD license 
+ commercial licenses if needed then it would help quite a bit, still 
though changing people, hard thing.

I would love to, but unfortunately I don't see it happening.

Greets,
  Jeroen