Re: [Ideas] WG Review: IDentity Enabled Networks (ideas)

John C Klensin <> Wed, 04 October 2017 16:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4C84F1342FC; Wed, 4 Oct 2017 09:58:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id EFVchTOteAvV; Wed, 4 Oct 2017 09:58:02 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5BB4F13422B; Wed, 4 Oct 2017 09:58:02 -0700 (PDT)
Received: from [] (helo=PSB) by with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <>) id 1dzmzh-0002rj-EF; Wed, 04 Oct 2017 12:58:01 -0400
Date: Wed, 04 Oct 2017 12:57:55 -0400
From: John C Klensin <>
Message-ID: <94E38EAAADE89B4B40A79530@PSB>
In-Reply-To: <>
References: <> <>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Scanned: No (on; SAEximRunCond expanded to false
Archived-At: <>
Subject: Re: [Ideas] WG Review: IDentity Enabled Networks (ideas)
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 04 Oct 2017 16:58:04 -0000


A comment somewhat orthogonal to whether this WG should be
chartered (I see the need, or at least the desire, but suspect
the current charter is badly structured to accomplish it).   It
may be that, with LISP (another IMO unfortunate name) and HIP
already out there, we are already obligated to do something like

However, I strongly urge that, if the charter is accepted in
principle,  you move away from from acronyms that are likely to
create far more confusion than the desire for demonstrating
cleverness or cuteness can possibly be worth.  "ideas" itself is
an example.  It may be an an acronym that was cleverly matched
to the WG name (or vice versa) but it is also a word that
implies an entirely different meaning, one that is fairly
misleading relative to the intended WG's topic and more suited,
if it is suitable at all for a WG name, for something exploring
or brainstorming a much broader range of topics.  An
"" mailing list is particularly obnoxious in that

<sarcasm>If people really are trying to show off how clever they
can be with acronyms, how about taking the LISP precedent and
figuring out words that would match some other programming
language names?  For example, those who oppose this might like
COBOL or, more neutrally, SLIP (although that, of course,
describes another piece of networking protocol (see RFC 1055)). 
Or someone who dislikes this might advocate calling it The
Ultimate Routing Key Evolutionary Ysmmer group.
You get the idea -- if we want the IETF to be seen as a mature
and responsible body, we really don't need to go there.

"GRIDS" is as bad or worse, because "Grid" refers to a
well-known networking technology about which the IETF Stream has
published RFCs (See, e.g., RFC 6272).

Our job is supposed to be trying to make the Internet better.
It seems to me that creating confusion by side-effect of the
terminology we use does not advance that goal.


On 29/09/17 17:13, The IESG wrote:

> A new IETF WG has been proposed in the Routing Area. The IESG
> has not made any determination yet. The following draft
> charter was submitted, and is provided for informational
> purposes only. Please send your comments to the IESG mailing
> list ( by 2017-10-09.
> IDentity Enabled Networks (ideas)
> Network solutions based on the concept of Identifier-Locator
> separation are increasingly considered to support mobility,
> overlay networking for virtualization and multi-homing across
> heterogeneous access networks. Identifier-locator separation
> protocols require infrastructure that allows nodes to
> discover the network topological location(s) of its peer(s)
> for packet delivery. A common infrastructure and protocol
> could be used by identifier/locator protocols as well as
> network virtualization. However, additional infrastructure
> and new protocol extensions are needed to address new
> requirements that go well beyond the traditional discovery
> service and mapping of identifier-to-location for packet
> delivery. Identifier-locator protocols are also useful for
> additional services involving dynamic association of a name
> to a set of network addresses - these include dynamic
> multicast, cloud service anycast and context-aware IoT
> queries.
> The IDEAS WG is chartered to produce a framework document
> that defines the expected behavior of a mapping system across
> the multiple existing use cases. The framework will aim at a
>  homogeneous behavior across use cases, and it will call out
> specific trade-offs that may be considered in the development
> of solutions.  We refer to the framework providing the set of
> services as Generic Identity Services (GRIDS).