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

[Albert Cabellos <[e-mail]>]

Hi all

I agree -in general- with the charter in its current form, below you can
find some comments inline:

On Mon, Aug 7, 2017 at 2:20 PM, Padma Pillay-Esnault <[e-mail]>
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.
>
>
>

I suggest also mentioning overlay networking for virtualization as a
use-case.


> 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.
>

specify instead of define? (same across the charter, specify instead of
develop, etc)
'for *existing* identifier/locator mapping' --> 'all' might be too generic
and not realizable.

>
>
> - 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.
>

why 'in addition'? The itemization already implicitly states: 'in
addition'.

>
>
> Some examples of the problem space are:
>

why 'some examples'? This looks very vague. From my understanding below you
have a solid and complete definition of the problem state. I suggest
rewriting to "The problem space is:"


> - 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ideas
>
>