Re: [Ideas] Your Input requested: Charter Proposal New Version

Robert Moskowitz <rgm-ietf@htt-consult.com> Thu, 10 August 2017 20:24 UTC

Return-Path: <rgm-ietf@htt-consult.com>
X-Original-To: ideas@ietfa.amsl.com
Delivered-To: ideas@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADB5A128A32 for <ideas@ietfa.amsl.com>; Thu, 10 Aug 2017 13:24:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I-Q_0dIUDjuq for <ideas@ietfa.amsl.com>; Thu, 10 Aug 2017 13:24:43 -0700 (PDT)
Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [50.253.254.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5566132448 for <ideas@ietf.org>; Thu, 10 Aug 2017 13:24:42 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 07BA1622B0; Thu, 10 Aug 2017 16:24:42 -0400 (EDT)
X-Virus-Scanned: amavisd-new at htt-consult.com
Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id kyCwtI+6rLo0; Thu, 10 Aug 2017 16:24:30 -0400 (EDT)
Received: from lx120e.htt-consult.com (unknown [192.168.160.12]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id 87CA7622AE; Thu, 10 Aug 2017 16:24:27 -0400 (EDT)
To: Padma Pillay-Esnault <padma.ietf@gmail.com>, ideas@ietf.org
References: <CAG-CQxpxDXxLXdu0a2GdBRfTFLM_C+jqCz58HoNim52C7Yzr8g@mail.gmail.com>
From: Robert Moskowitz <rgm-ietf@htt-consult.com>
Message-ID: <49cf40d7-9c32-5b22-2955-18ea85405edc@htt-consult.com>
Date: Thu, 10 Aug 2017 16:24:24 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <CAG-CQxpxDXxLXdu0a2GdBRfTFLM_C+jqCz58HoNim52C7Yzr8g@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------8E8C877A632FB97BC923EC37"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/ideas/3-CjEOjKxaalTf2vdnQ04UqwXD0>
Subject: Re: [Ideas] Your Input requested: Charter Proposal New Version
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: Thu, 10 Aug 2017 20:24:48 -0000

About time I weighed in on this.

Basically I am comfortable with the charter content.  It has to be a 
amalgam of different approaches so no one can be completely on board 
with it.  Really that proof will be in the output; we have to start with 
some goals tacked to the wall.

If I would change anything it is in the 2nd para, and that is general 
info which can be wordsmithed til the cows come home (as they say).  But 
to put my fork in it:

"At the same time"  ?? what time?  The 1st para really does not define a 
time.  Just drop it and start with "End users ..."

"and operators demand"  Don't make them competitative requirements. They 
just are.

"Identity-enabled networks aim to enable'  They do?  Just drop the "aim 
to" and I think it is a stronger, yet valid, statement.

For me, the rest can stand to get us off the starting block.

Bob

On 08/07/2017 01:20 AM, Padma Pillay-Esnault wrote:
> Dear IDEAS,
>
> Thanks to everyone who sent their comments and feedback both on the 
> list and off the list.
>
> This new version should address comments from:
> -  Michael Menth. Michael, please let us know if this revision address 
> some of your comments on clarity.
> - Alex Clemm. Alex , please chime on the revision regarding your 
> addition.
> - Tom Herbert. Tom, Some of your suggestions are incorporated in this 
> version.
> -Tom and Alex, this version include specific working that the 
> framework is modular. The set of areas to be covered has been 
> reordered to put the basic identifier protocol common infrastructure 
> first and then the new identity concept and functionalities.
> - Georgios Karagiannis, Uma Chundhuri. Georgios, Uma, there is still 
> an ongoing discussion about the framework. This version is flexible 
> enough to accommodate the work to be done on defining the framework.
> - Uma Chundhuri. Uma, the pub/sub reference should cover the 
> inter-grids aspect if needed.
>
> Please find the new version below:
>
> IDEAS: “IDentity EnAbled networkS”
>
> Proposed Charter
>
> Network solutions based on the concept of Identifier-Locator 
> separation are increasingly considered to support mobility 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.
>
> At the same time, end users require greater privacy for their 
> networking information and protection from outside threats, while 
> operators demand greater operational efficiency. Identity-enabled 
> networks aim to enable networking applications and services that 
> provide a high degree of privacy and control of end points over their 
> networking data, coupled with greater inherent security than provided 
> by today’s networks.
>
> To this end, the working group shall:
>
> - define a framework for the development of an identifier/locator 
> mapping system that provides a common solution for all 
> identifier/locator mapping protocols and network virtualization.
>
> - in addition, introduce the concept of identity-identifier split and 
> new mechanisms that let endpoints dynamically change identifiers. 
> These new functionalities may, for example, facilitate anonymity 
> through obscurity while preventing security issues that might result 
> from abuse, ensuring that information about actual endpoints and their 
> location is revealed only on a need-to-know basis.
>
> Some examples of the problem space are:
>
> - Common infrastructure and primitives: The lack of a common 
> infrastructure is a barrier for the application of common and 
> consistent basic networking policies. Likewise, mapping services and 
> infrastructure that apply to identity-identifier as well as 
> identifier-locator mappings reduces operational and deployment complexity.
>
> - Access control: Unrestricted look up on an identifier may reveal 
> information such as the locator to eavesdroppers. Today, there is no 
> way to prevent the look up of an identifier with some user defined 
> policy or finer grain rules.
>
> - Privacy:  The use of long-lived and public identifiers may be 
> desirable for looking up a peer, however it causes privacy issues as 
> well. Indeed, when identifier-location pairs can be looked up without 
> restriction, flows can be pinned by anybody to specific end systems.  
> The endpoint communications should be able to change their identifier 
> while retaining their identity and associated policies. The use of 
> temporary identifiers and access control on lookups should help 
> discourage undesired traffic and conceal sensitive network information 
> of end devices to eavesdroppers.
>
> The Identity Enabled Networks (IDEAS) working group is chartered to 
> develop a common framework that can be used by identifier-based 
> protocols and provides services to address their requirements. We 
> refer to the common framework providing the set of services as Generic 
> Identity Services (GRIDS).
>
> The working group will identify gaps and make recommendations on 
> changes needed for interactions between the framework and 
> identifier-enabled protocols.
>
> Specifically, the IDEAS WG is chartered to work on these areas for the 
> modular framework:
>
> - Definition of primitives for interworking with identifier-location 
> split protocols
>
> - Identifier/locator mapping and resolution (e.g. discovery, pub/sub, 
> multihoming, ...)
>
> - Registration and lifecycle management of identities and their 
> associated identifiers.
>
> - Identity authentication and authorization (e.g. access to framework, 
> update of information for identifiers..)
>
> - Definition and enforcement of basic networking policies (e.g. 
> ability to look up an identifier-locator pair, permit forwarding 
> traffic for particular endpoints on a per-identity basis…)
>
> - Identity and Identifier Metadata (fixed or slow changing)
>
> - Management aspects and Data Models where appropriate.
>
> The IDEAS WG will collaborate with other Working Groups to ensure 
> interoperability with LISP, HIP, ILA and other relevant work. 
> Furthermore, it will try to reuse technologies already developed when 
> appropriate.
>
> WG deliverables include the definition:
>
> Generic Identity Services Framework
>
> WG sustaining/informational documents may include:
>
> These documents may not necessarily be published, but may be 
> maintained in a draft form or on a collaborative Working Group wiki to 
> support the efforts of the Working Group and help new comers:
>
> - Problem statement
>
> - Use cases
>
> - Requirements
>
> - Applications of the architecture for use cases
>
> Milestones
>
> March 2018 Adopt WG draft for the Generic Identity Services framework
>
> August 2018 WGLC for the Generic Identity Services framework
>
> December 2018 Send Generic Identity Services framework draft to the IESG
>
>
>
> _______________________________________________
> Ideas mailing list
> Ideas@ietf.org
> https://www.ietf.org/mailman/listinfo/ideas