[Ideas] Needless playing with semantics [Was : WG Review: IDentity Enabled Networks (ideas)]

"Adrian Farrel" <adrian@olddog.co.uk> Wed, 11 October 2017 12:21 UTC

Return-Path: <adrian@olddog.co.uk>
X-Original-To: ideas@ietfa.amsl.com
Delivered-To: ideas@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 48A061320C9; Wed, 11 Oct 2017 05:21:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.62
X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id us8hnekgWih0; Wed, 11 Oct 2017 05:21:07 -0700 (PDT)
Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 972C11342D2; Wed, 11 Oct 2017 05:21:06 -0700 (PDT)
Received: from asmtp5.iomartmail.com (localhost.localdomain []) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id v9BCL41a007719; Wed, 11 Oct 2017 13:21:04 +0100
Received: from 950129200 ( []) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id v9BCL1PP007703 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Oct 2017 13:21:03 +0100
Reply-To: <adrian@olddog.co.uk>
From: "Adrian Farrel" <adrian@olddog.co.uk>
To: <ietf@ietf.org>
Cc: <ideas@ietf.org>
Date: Wed, 11 Oct 2017 13:21:03 +0100
Message-ID: <05aa01d3428b$69222890$3b6679b0$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AdNCi2XDwA3qavwwR0S6VNhqD+IZRA==
Content-Language: en-gb
X-TM-AS-MML: disable
X-TM-AS-Product-Ver: IMSS-
X-TM-AS-Result: No--9.754-10.0-31-10
X-imss-scan-details: No--9.754-10.0-31-10
X-TMASE-MatchedRID: cTwTy1nILiLMHUInqqZ02hWCVBr+Ay980nXvwjW2mSWmKn0WszswH8Lm p4jPUF8t2BgAhpJqDmmPgvujI3XDfrE8iKjgaIfGlVHM/F6YkvQGwd8wUY9uM16h6sWm+pWd4qS OTf7raZF7tgTPLzrW2i5SWE9/6EYOVCFefQRV3M5IRA38P/dwbkEfDC/+cVmmFJfW7wEu1kD0T3 Risbtv4/QAGnwdE7nfU9ppuNDleoZPB4rXagQZ+xi14cCd2FejJPNIV6GF8mtk2J2ef3Nd3wOHl es/nBwnTMDcUZMOT5eWNrS+2ymUOHZ41k2pZTcfcFEiuPxHjsVy2CK2WfrdRS3FY27PpHmsXAxU NdULeEYpJoYHgmIwOr59kd3tU9KQemzGG4qDPaloe+401GwOsn0tCKdnhB581B0Hk1Q1KyLUZxE AlFPo846HM5rqDwqtk1KUrXGvNw0o9jlMQyIWK6JMup4ItiKnyU1OQKPdrwGMZWweiRdBFUMMpr cbiest
Archived-At: <https://mailarchive.ietf.org/arch/msg/ideas/R6JlagRtm6WCKtUJXvLUgM8eAu0>
Subject: [Ideas] Needless playing with semantics [Was : WG Review: IDentity Enabled Networks (ideas)]
X-BeenThere: ideas@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Discussions relating to the development, clarification, and implementation of control-plane infrastructures and functionalities in ID enabled networks." <ideas.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ideas>, <mailto:ideas-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ideas/>
List-Post: <mailto:ideas@ietf.org>
List-Help: <mailto:ideas-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ideas>, <mailto:ideas-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Oct 2017 12:21:10 -0000

It is fruitless to debate what "identity" means. Much better to qualify it when you use it. When you mean "identity of a device" say so and don't use a shorthand. When you mean "identity of an individual" be explicit. Sure, you have to use a few more pixels, but you will be better understood.

It would also be helpful IMHO if the proponents were far clearer and blunt in their statements of intention. When saying "it is not our intention to do foo," you are not saying "doing foo is proscribed" and you are not saying "achieving foo as a by-product is unacceptable." Clarity is always helpful.


> -----Original Message-----
> From: ietf [mailto:ietf-bounces@ietf.org] On Behalf Of Uma Chunduri
> Sent: 11 October 2017 11:56
> To: Stephen Farrell; Robert Moskowitz; ietf@ietf.org
> Cc: ideas@ietf.org
> Subject: RE: [Ideas] WG Review: IDentity Enabled Networks (ideas)
> Hi Stephen -
> I would let Bob to respond the questions you asked - but If I may for the below
> question
> 		>>
> 		>> This is about machines, and processes, have ID/Loc through
> some
> 		>> underlying technology (e.g. HIP, ILA, LISP) to have a common
> ID
> 		>> discovery and Loc back to ID (for things like HTTP redirects).
> 	>If that's the case, then there appears to be serious confusion in the use-
> cases draft at least. And "identity" seems a fairly mad term to pick if one means
> processes or devices, as it pretty much guarantees raised hackles and confusion.
> [Uma]:
> 1. IDEAS only intended deal with aspects for control/mapping plane of ID/LOC
> protocols.
>       How  and what kind of Identifier's used in the data packets are governed by
> the  respective ID/LOC protocol in use.  Just give some examples -
>       It could be HIT in case of HIP with security properties, EID/Anonymous EID's in
> case of LISP with encapsulation.
>      This has been explicitly updated in the use-case draft and can be further
> updated in the charter. But, I would note  this is the intention for the  following in
> the current charter text -
>       "The IDEAS WG will closely coordinate with the LISP and HIP WGs (and with
> 	others as needed) in order to keep them well-informed of the progress."
> 2.  And regarding the usage of the term "identity" - not sure what's the confusion
> and why this has been associated with humans to start with. This has been
> further clarified in the discussions past few days and also been updated in the
> document.
>       Now the term,  we felt appropriate as the intent is in the context  of AUTH
> (examples of identifies thought through IPV4_ADDR, FQDN, RFC822_ADDR,
>        which is consistent with any of the authentication mechanism we use today*
> as defined by IETF.
> --
> Uma C.
> * https://tools.ietf.org/html/draft-ietf-tls-tls13-21
>    https://tools.ietf.org/html/rfc5996
>    Or one of the 20/30+ EAP AUTH methods with mutual authentication properties
> (depending the low power/high power mobile/industrial/vehicular IoT device in
> question)