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

Dear Shreyasee

Thanks your for your review and suggested edits.

See below <Padma>

On Fri, Aug 11, 2017 at 8:57 AM, Shreyasee Mukherjee <
shreya@winlab.rutgers.edu> wrote:

>
> Dear Padma,
>
> This version reads well. Professor Ray and we at WINLAB had a few minor
> comments. We agree with Alex's previous comment on including some notion
> that the mapping system should have the flexibility of mapping not just
> identifiers to locators but also allow mapping identifiers to other
> identifiers. This is a powerful tool and we have looked into how such
> recursive mapping of identifiers allows newer network services to be
> enabled such as context-aware multicast. This can also be extended to
> support privacy concerns wherein an identifier could map into a whitelist
> or blacklist of identifiers for lookup queries. In that regard, our
> comments to the charter proposal are provided inline.
>
> Thank you,
> Shreyasee
>
>>
>> ---------- Forwarded message ----------
>> From: Alexander Clemm <alexander.clemm@huawei.com>
>> To: Padma Pillay-Esnault <padma.ietf@gmail.com>, Padmadevi Pillay
>> Esnault <padma@huawei.com>
>> Cc: Tom Herbert <tom@herbertland.com>, "ideas@ietf.org" <ideas@ietf.org>
>> Bcc:
>> Date: Wed, 9 Aug 2017 21:49:29 +0000
>> Subject: Re: [Ideas] Your Input requested: Charter Proposal New Version
>>
>> This version sounds fine to me.
>>
>>
>>
>> Thanks
>>
>> --- Alex
>>
>>
>>
>> *From:* Padma Pillay-Esnault [mailto:padma.ietf@gmail.com]
>> *Sent:* Tuesday, August 08, 2017 9:36 PM
>> *To:* Padmadevi Pillay Esnault <padma@huawei.com>
>> *Cc:* Alexander Clemm <alexander.clemm@huawei.com>; Tom Herbert <
>> tom@herbertland.com>; ideas@ietf.org
>> *Subject:* Re: [Ideas] Your Input requested: Charter Proposal New Version
>>
>>
>>
>> Hello All
>>
>>
>>
>> Here is the latest version as of 08/08/17.
>>
>>
>>
>> Please send your comments and feedback on the list.
>>
>>
>>
>>
>>
>> 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. 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.
>>
>
>
<Padma> ok will add

> A common infrastructure and protocol could be used by identifier/locator
>> protocols as well as for 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 and develop a common mapping system, control plane, and related
>> protocol that provide a common solution for identifier/locator protocols
>> that map identifiers to locators as well other new mapping combinations as
>> needed, as well as network virtualization protocols that map virtual to
>> physical addresses
>>
>>
>>
>> - in addition, introduce the concept of identity-identifier split and new
>> mechanisms that let endpoints dynamically change identifiers. The common
>> mapping system will include identity to identifier mappings. 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.
>>
>
> -  In addition to resolving an identifier to a set of network addresses,
> the mapping system should be able to support a recursive mode in which an
> identifier <IDf> can be mapped to multiple identifiers <IDf1>, <IDf2>,
> …<IDfn>.  This is useful for incorporating hierarchies associated with the
> ontology tree of the information being accessed, as well as for scaling of
> multicast services involving mapping of a single identifier to large
> numbers of network addresses.
>

<Padma> I did not hear of any objections on the list.
Will add this in the latest version and will resent to the list.

>
>
>>
>>
>> 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. The API should be
>> sufficiently general to enable various modes of resolution including
>> identifier to network address <IDf> à <NA>, identifier to multiple
>> network addresses <IDf> à <NA1>, <NA2>, …<NAn>, and identifier to one or
>> more identifiers <IDf> à <IDf1>, <IDf2>, …<IDfn>.
>>
>>
>>
>> - 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 (only fixed or slow changing, e.g.
>> type)
>>
>> - 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:
>>
>> Generic Identity Services Framework – should this be defined further in
>> terms of API, syntax/semantics, mapping service query/response/update
>> protocol, etc.?
>>
>>
<Padma> I woud defer to the list on this. The paragraph above also
describes some of this. We could expand there

Thanks
Padma

>
>>
>> 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
>>
>>
>>
>> On Tue, Aug 8, 2017 at 1:16 PM, Padmadevi Pillay Esnault <
>> padma@huawei.com> wrote:
>>
>> Sure
>>
>>
>>
>> However, been wondering if it is best not to be so specific in the
>> charter.
>>
>> Thoughts?
>>
>>
>>
>> Padma
>>
>>
>>
>> *From:* Alexander Clemm
>> *Sent:* Tuesday, August 08, 2017 10:42 AM
>> *To:* Padmadevi Pillay Esnault; Tom Herbert
>> *Cc:* ideas@ietf.org; Padma Pillay-Esnault
>>
>>
>> *Subject:* RE: [Ideas] Your Input requested: Charter Proposal New Version
>>
>>
>>
>> OK.
>>
>>
>>
>> If we want to have a more specific list of supported mappings, it may be
>> useful to mention some of those other mappings as well – by means of
>> example, mappings between identifiers.
>>
>>
>>
>> Thanks
>>
>> --- Alex
>>
>>
>>
>> *From:* Padmadevi Pillay Esnault
>> *Sent:* Monday, August 07, 2017 2:52 PM
>> *To:* Alexander Clemm <alexander.clemm@huawei.com>; Tom Herbert <
>> tom@herbertland.com>
>> *Cc:* ideas@ietf.org; Padma Pillay-Esnault <padma.ietf@gmail.com>
>> *Subject:* RE: [Ideas] Your Input requested: Charter Proposal New Version
>>
>>
>>
>> Alex
>>
>>
>>
>> My understanding is that Tom did NOT ask for removing of identity
>> concept.
>>
>> He asked to make the section on common infrastructure clearer with this
>> sentence.
>>
>>
>>
>> I agree with you that the mappings should not be restricted to 1->n
>>
>>
>>
>> Thanks
>>
>> Padma
>>
>>
>>
>> *From:* Ideas [mailto:ideas-bounces@ietf.org <ideas-bounces@ietf.org>] *On
>> Behalf Of *Alexander Clemm
>> *Sent:* Monday, August 07, 2017 2:34 PM
>> *To:* Padma Pillay-Esnault; Tom Herbert
>> *Cc:* ideas@ietf.org
>> *Subject:* Re: [Ideas] Your Input requested: Charter Proposal New Version
>>
>>
>>
>> I am not sure we should restrict ourselves to mapping between identifiers
>> and locators.
>>
>>
>>
>> I would at a minimum want to include mappings between identifiers, and
>> between identifiers and (for lack of a better term) groupings of
>> identifiers.
>>
>>
>>
>> If we take out the identity concept, we should also rename the WG.
>>
>>
>>
>> --- Alex
>>
>>
>>
>> *From:* Ideas [mailto:ideas-bounces@ietf.org <ideas-bounces@ietf.org>] *On
>> Behalf Of *Padma Pillay-Esnault
>> *Sent:* Monday, August 07, 2017 1:28 PM
>> *To:* Tom Herbert <tom@herbertland.com>
>> *Cc:* ideas@ietf.org
>> *Subject:* Re: [Ideas] Your Input requested: Charter Proposal New Version
>>
>>
>>
>> Hi Tom
>>
>>
>>
>>
>>
>> >
>> > 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.
>> >
>>
>> Padma,
>>
>> I think this statement could be stronger and express that the common
>> mapping system and protocols are expected output from WG. How about
>> something like: "Define and develop a common mapping system, control
>> plane, and related protocol that provide a common solution for
>> identifier/locator protocols that map identifiers to locators, as well
>> as network virtualization protocols that map virtual to physical
>> addresses"
>>
>>
>>
>> Fine with me.
>>
>>
>>
>> Let's poll the list for consensus on this.
>>
>>
>>
>> Thanks
>>
>> Padma
>>
>>
>>
>> Tom
>>
>>
>>
>>
>>
>> _______________________________________________
>> Ideas mailing list
>> Ideas@ietf.org
>> https://www.ietf.org/mailman/listinfo/ideas
>>
>>
>
> _______________________________________________
> Ideas mailing list
> Ideas@ietf.org
> https://www.ietf.org/mailman/listinfo/ideas
>
>