Subject: [Ideas] IDEAS Proposed Charter 08/20/2017 Version - Final Round

From: Padma Pillay-Esnault <[email-masked]>
Date: Sun, 20 Aug 2017 23:02:40 -0700

Dear IDEAS,

Thanks to everyone who sent their comments and feedback both on the list
and off the list. The version below has integrated all the comments, inputs
as well as discussions on the alias for the last 2 weeks. For your
reference, a log of comments can be found at the end of this email.

*Please send your comments by **Thursday 08/24/2017 latest for t**his
final round for feedback.*

*IDEAS: “IDentity EnAbled networkS”*

*Version 8/20/2017 - Proposed Charter*

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.

End users require greater privacy for their networking information and
protection from outside threats, and operators demand greater operational
efficiency. Identity-enabled networks enable networking applications and
services that provide a high degree of privacy and control of end points
over their identity address, location address, and data coupled with
greater inherent security than provided by today’s networks.

To this end, the working group shall:

- Specify and deploy a mapping system, and related protocol that provide a
solution for existing 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

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

The problem space is:

- Common infrastructure and primitives: The lack of a common infrastructure
is a barrier for the application of 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
specify a framework that can be used by identifier-based protocols and
provides services to address their requirements. We refer to the 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:

- Specify a mapping system supporting the mapping combinations as needed

- Definition of primitives for identifier-location split protocols to
interact with the framework

- Identifier/locator mapping and resolution (e.g. discovery, pub/sub,
multi-homing, ...)

- 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 e.g. type)

- Management aspects and Data Models where appropriate.

The IDEAS WG will collaborate with LISP WG and HIP WG to extend their
control planes if needed to meet the framework requirements.  The WG will
also collaborate with other WG for any other relevant work. Furthermore,
the WG will try to reuse technologies already developed when appropriate.

WG deliverables include:

Generic Identity Services Framework

Other 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 for identifier/locator mapping and resolution

*- *Requirements for identity authentication and authorization service (for
GRIDS).

- Applications of the architecture for use cases

*- *Threat model document

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

*Modification Log and Comments*

*Comments on the 08/08/2017 Version *

*Sam Sun: *

1) In the first item in "the IDEAS WG is chartered to work on...", what it
means by "... interworking with identifier-location split protocols"?
*CLOSED*
2) In the deliverables, could we include some of chartered tasks here? For
example,
- Requirements for identifier/locator mapping and resolution *CLOSED*

- Requirements for identity authentication and authorization service (for
GRIDS). *CLOSED*

*Alex Clemm*:

This version sounds fine to me.

*Uma Chunduri*:

Looks fine and the term” control plane”   can be dropped from the above
sentence.  #1  *CLOSED*

This list doesn’t capture #1 in the earlier description and IMO that should
be listed too *CLOSED*

*Lan Gao*:

I agree with Sam. Specific chartered tasks or a statement referencing the
chartered tasks should be added to the Deliverables as the current document
only implies that they will be met by the Generic Identity Services
Framework. *CLOSED*

*Bob Moskowitz*:

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

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

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

*Dino Farinacci*:

I would add “… control of end points over their identity address, location
address, and data coupled with …”. *CLOSED*

I don’t know why there the use of the word “common” appears throughout. The
charter really shouldn't intend to interoperate existing locator/ID split
protocols so I would say “define and deploy a mapping system”. *CLOSED*

> - Definition of primitives for interworking with identifier-location
split protocols
This isn’t useful to anyone. Having a HIP host talk to a LISP host solves
nothing. It just creates complexity. And what if the LISP host has an IPv4
EID? *CLOSED*

I think the IDEAS WG should work with these working groups to make sure
their control planes are extended to meet the requirements from IDEAS. But
not to make them interoperate. *CLOSED*

*Shreyasee Mukherjee:*

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

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

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>. *REJECTED –
Email discussion -Too specific but this is implied by the addition above*.

Generic Identity Services Framework – should this be defined further in
terms of API, syntax/semantics, mapping service query/response/update
protocol, etc.? *REJECTED per comments on alias*

*Di Ma:*

I think prospects described in IDEAS charter are promising since people
fancy anonymity in connecting to different network environments, via
identity/identifier separation.

 Yet by doing so, we would introduce new risk into the Internet.  Threat
model is therefore indispensable to provide a basis for the design of
future IDEAS security mechanisms.

 I suggest a threat model document as one of WG deliverables *CLOSED*

*D. Raychaudhuri*:

I reviewed the charter document and feel that it is a good start.  My main
comments are:

(1) I agree with the concept of an identity-identifier split, which is
necessary for an important set of applications requiring dynamic change of
identifier. Realizing this will require something similar to a trusted
“name certification service”  [cf. “MobilityFirst: A Robust and Trustworthy
Mobility-Centric Architecture for the Future Internet, ACM MC2R, July 2012]
in addition to a dynamic name-to-locator mapping/resolution service [cf.
”DMap: A Shared Hosting Scheme for Dynamic Identifier to Locator Mappings
in the Global Internet”, ICDCS 2012]

(2) A key requirement for the mapping service is the ability to support
multiple types of resolution including identifier to identifier (i.e.
recursive), identifier to group of identifiers, identifier to single
locator, identifier to a list of locators, etc.  We have found the
recursive identifier resolution capability to be very useful for scaling
and new service creation.  *CLOSED*

(3) The final output of the WG at the end of the doc should be filled in a
bit further in terms of specific APIs and query/response/update protocol
definitions to be included in the spec.

*REJECTED by email discussion*

*Bob M.*: You really don't want a starting charter this specific.  You can
have wording about working on an API, but APIs have always been a sore item
in the IETF.  Also this is why I2NSF talks about Interfaces and
capablities, not APIs.  Leave the specitivity for the workgroup, not try
and get the post-BOF to complete the work to start the workgroup.

(4) While I realize that the current charter’s scope is intentionally
limited to defining general-purpose control plane support, the spec could
be of greater value by defining or linking one or more specific
identifier-based routing (data plane) protocols compatible with the IDEAS
infrastructure.

*Bob M.*:This comes out in the workgroup, and if necessary then you do a
charter revision.  I need to talk to you separately about TAPS...

*Albert Cabellos: *

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

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

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

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

 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:" *CLOSED*

*Comments on the 08/06/2017 Version *

*Yingzhen Qu:*

About “- Identity and Identifier Metadata (fixed or slow changing)”, I
remember one of the comments we got before was to further limit the scope
of metadata to just a couple of categories, for example type. *CLOSED*

*Michael Menth* :

Clarity has improved.

*Tom Herbert/Diego Lopez*:

When it comes to these concerns I’d strongly recommend to have a look at
how identity attributes were exchanged and trust established within the
ABFAB framework (https://tools.ietf.org/wg/abfab/)

*CLOSED* - The charter now mentions to collaborate with other group for
relevant work.

*Tom Herbert*:

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" *CLOSED
with modifications from Albert, Dino, Uma*

*Alex Clemm*:

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

*Comments on the 08/02/201 Version *

-  *Michael Menth:* Michael, please let us know if this revision address
some of your comments on clarity. *CLOSED*

- *Alex Clemm*. Alex , please chime on the revision regarding your
addition. *CLOSED*

- *Tom Herbert*. Tom, Some of your suggestions are incorporated in this
version. *CLOSED*

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

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

---

From: <[email-masked]>
Date: Mon, 21 Aug 2017 08:43:35 +0000

Dear all,

Thanks to Padma for the editing effort. The updated charter looks good to me and I hope this will lead to the chartering of the WG. A few (minor) proposals and questions for clarification inline.

[snip]

IDEAS: “IDentity EnAbled networkS”
Version 8/20/2017 - Proposed Charter

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.
[CJ] I would add “in particular” at the end of the above sentence.
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.

End users require greater privacy for their networking information and protection from outside threats, and operators demand greater operational efficiency. Identity-enabled networks enable networking applications and services that provide a high degree of privacy and control of end points over their identity address, location address, and data coupled with greater inherent security than provided by today’s networks.

To this end, the working group shall:
- Specify and deploy a mapping system, and related protocol that provide a solution for existing 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
[CJ] I’m not sure I would keep the last part of the sentence about network virtualization protocols, as I don’t see why network virtualization would suggest a specific protocol.
- 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.

The problem space is:

- Common infrastructure and primitives: The lack of a common infrastructure is a barrier for the application of consistent basic networking policies.
[CJ] Not sure about what lies beneath a basic networking policy, nor the scope of enforcing such policy – single/multi-domain? Thus, I would suggest some elaboration about the actual scope covered by the said common infrastructure, since a multi-domain/multi-party GRIDS-based architecture is very likely to raise additional management complexity (possibly as a function of business models that would infer brokering services or P2P relationships with the deployment of several mapping systems operated by different entities) that may not be covered by the WG, at least not until the proposed framework effort is completed and WG rechartering considerations appear accordingly. Maybe add “at the scale of a domain” at the end of the above sentence?
Cheers,
Christian.

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 21 Aug 2017 10:07:44 -0700

> Thanks to Padma for the editing effort. The updated charter looks good to me and I hope this will lead to the chartering of the WG. A few (minor) proposals and questions for clarification inline.

Same here. Thanks for the big effort Padma.

Dino

> _______________________________________________
> Ideas mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ideas

---

From: Richard Li <[email-masked]>
Date: Mon, 21 Aug 2017 18:22:34 +0000

The same here, too. 

I have read it. Now it looks very good and I hope it will lead to a successful WG charter. 

Regards,

Richard

-----Original Message-----
From: Ideas [mailto:[email-masked]] On Behalf Of Dino Farinacci
Sent: Monday, August 21, 2017 10:08 AM
To: JACQUENET Christian IMT/OLN
Cc: Padma Pillay-Esnault; [email-masked]
Subject: Re: [Ideas] IDEAS Proposed Charter 08/20/2017 Version - Final Round

Dino

---

From: Sam Sun <[email-masked]>
Date: Mon, 21 Aug 2017 16:09:32 -0400

Padma,

Thanks for putting everything together and the leadership to make this 
happen. The updated charter looks good!

I suggest we put a closure on this after Thursday so that we can start 
moving forward with the WG.

All the best,
Sam

On 8/21/17 2:02 AM, Padma Pillay-Esnault wrote:
>
> Dear IDEAS,
>
> Thanks to everyone who sent their comments and feedback both on the 
> list and off the list. The version below has integrated all the 
> comments, inputs as well as discussions on the alias for the last 2 
> weeks. For your reference, a log of comments can be found at the end 
> of this email.
>
>
> 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.
>
> protection from outside threats, and operators demand greater 
> operational efficiency. Identity-enabled networks enable networking 
> applications and services that provide a high degree of privacy and 
> control of end points over their identity address, location address, 
> and data coupled with greater inherent security than provided by 
> today’s networks.
>
> - Specify and deploy a mapping system, and related protocol that 
> provide a solution for existing 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
>
> - 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.
>
> The problem space is:
>
> - Common infrastructure and primitives: The lack of a common 
> infrastructure is a barrier for the application of 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.
>
> 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.
>
> provides services to address their requirements. We refer to the 
> 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.
>
> - Definition of primitives for identifier-location split 
> protocols*//*to interact with the framework
>
> - Registration and lifecycle management of identities and their 
> associated 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…)
>
> The IDEAS WG will collaborate with LISP*//*WG and HIP WG to extend 
> their control planes if needed to meet the framework 
> requirements.  The WG will also collaborate with other WG for any 
> other relevant work. Furthermore, the WG will try to reuse 
> technologies already developed when appropriate.
>
> WG deliverables 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 for identity authentication and authorization 
> service (for GRIDS).
>
> */- /*Threat model document
>
> Milestones
>
> 1) In the first item in "the IDEAS WG is chartered to work on...", 
> what it means by "... interworking with identifier-location split 
> protocols"? *CLOSED*
> 2) In the deliverables, could we include some of chartered tasks here? 
> For example,
> - Requirements for identity authentication and authorization service 
> (for GRIDS). *CLOSED*
>
> *Alex Clemm*:
>
> **
> Looks fine and the term” control plane”   can be dropped from the 
> above sentence.  #1 *CLOSED*
>
> This list doesn’t capture #1 in the earlier description and IMO that 
> should be listed too *CLOSED*
>
> *Lan Gao*:
>
> I agree with Sam. Specific chartered tasks or a statement referencing 
> the chartered tasks should be added to the Deliverables as the current 
> document only implies that they will be met by the Generic Identity 
> Services Framework. *CLOSED*
>
> *Bob Moskowitz*:
>
> 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. 
> *CLOSED*
>
> "Identity-enabled networks aim to enable'  They do? Just drop the "aim 
> to" and I think it is a stronger, yet valid, statement. *CLOSED*
>
> I would add “… control of end points over their identity address, 
> location address, and data coupled with …”. *CLOSED*
>
> I don’t know why there the use of the word “common” appears 
> throughout. The charter really shouldn't intend to interoperate 
> existing locator/ID split protocols so I would say “define and deploy 
> a mapping system”. *CLOSED*
>
> > - Definition of primitives for interworking with identifier-location split protocols
> This isn’t useful to anyone. Having a HIP host talk to a LISP host 
> solves nothing. It just creates complexity. And what if the LISP host 
> has an IPv4 EID? *CLOSED*
>
> I think the IDEAS WG should work with these working groups to make 
> sure their control planes are extended to meet the requirements from 
> IDEAS. But not to make them interoperate. *CLOSED*
>
> *Shreyasee Mukherjee:*
>
> involving dynamic association of a name to a set of network addresses 
> - these include dynamic multicast, cloud service anycast and 
> context-aware IoT queries. *CLOSED*
>
> - 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. 
> *CLOSED*
>
> 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>. *REJECTED – Email discussion -Too specific but this is 
> implied by the addition above*.
>
> Generic Identity Services Framework – should this be defined further 
> in terms of API, syntax/semantics, mapping service 
> query/response/update protocol, etc.? *REJECTED per comments on alias*
>
> *Di Ma:*
>
> I think prospects described in IDEAS charter are promising since 
> people fancy anonymity in connecting to different network 
> environments, via identity/identifier separation.
>
>  Yet by doing so, we would introduce new risk into the Internet.  
> Threat model is therefore indispensable to provide a basis for the 
> design of future IDEAS security mechanisms.
>
> I reviewed the charter document and feel that it is a good start.  My 
> main comments are:
>
> necessary for an important set of applications requiring dynamic 
> change of identifier. Realizing this will require something similar to 
> a trusted “name certification service”  [cf. “MobilityFirst: A Robust 
> and Trustworthy Mobility-Centric Architecture for the Future Internet, 
> ACM MC2R, July 2012] in addition to a dynamic name-to-locator 
> mapping/resolution service [cf. ”DMap: A Shared Hosting Scheme for 
> Dynamic Identifier to Locator Mappings in the Global Internet”, ICDCS 
> 2012]
>
> (2) A key requirement for the mapping service is the ability to 
> support multiple types of resolution including identifier to 
> identifier (i.e. recursive), identifier to group of identifiers, 
> identifier to single locator, identifier to a list of locators, etc.  
> We have found the recursive identifier resolution capability to be 
> very useful for scaling and new service creation. *CLOSED*
>
> (3) The final output of the WG at the end of the doc should be filled 
> in a bit further in terms of specific APIs and query/response/update 
> protocol definitions to be included in the spec.
>
> *Bob M.*: You really don't want a starting charter this specific.  You 
> can have wording about working on an API, but APIs have always been a 
> sore item in the IETF. Also this is why I2NSF talks about Interfaces 
> and capablities, not APIs. Leave the specitivity for the workgroup, 
> not try and get the post-BOF to complete the work to start the workgroup.
>
>
> limited to defining general-purpose control plane support, the spec 
> could be of greater value by defining or linking one or more specific 
> identifier-based routing (data plane) protocols compatible with the 
> IDEAS infrastructure.
>
> *Bob M.*:This comes out in the workgroup, and if necessary then you do 
> a charter revision.  I need to talk to you separately about TAPS...
>
> *Albert Cabellos: *
>
> I agree -in general- with the charter in its current form, below you 
> can find some comments inline:
>
>  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. *CLOSED*
>
>  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:" *CLOSED*
>
> **
> remember one of the comments we got before was to further limit the 
> scope of metadata to just a couple of categories, for example type. 
> *CLOSED*
>
> *Michael Menth* :
>
> Clarity has improved.
>
> When it comes to these concerns I’d strongly recommend to have a look 
> at how identity attributes were exchanged and trust established within 
> the ABFAB framework (https://tools.ietf.org/wg/abfab/)
>
> *CLOSED* - The charter now mentions to collaborate with other group 
> for relevant work.
>
> *Tom Herbert*:
>
> 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" *CLOSED with modifications from Albert, Dino, Uma*
>
> *Alex Clemm*:
>
> 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. *CLOSED*
>
> - *Michael Menth:* Michael, please let us know if this revision 
> address some of your comments on clarity. *CLOSED*
>
> - *Tom Herbert*. Tom, Some of your suggestions are incorporated in 
> this version. *CLOSED*
>
> -*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. *CLOSED*
>
> - *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.*CLOSED*
>
>
>
>

---

From: Lan Gao <[email-masked]>
Date: Tue, 22 Aug 2017 08:38:24 +0800

Thanks Padma for hard work co-coordinating the revisions of the charter.
This version of the Charter looks good. Everyone did a great job
contributing revisions.

Regards,

Lan Gao

On Tue, Aug 22, 2017 at 4:09 AM, Sam Sun <[email-masked]> wrote:

> Network solutions based on the concept of Identifier-Locator separation
> are increasingly considered to support mobility, overlay networking for
> networking policies. Likewise, mapping services and infrastructure that
> apply to identity-identifier as well as identifier-locator mappings reduces
> *- *Requirements for identity authentication and authorization service
> (for GRIDS).
>
> I don’t know why there the use of the word “common” appears throughout.
> The charter really shouldn't intend to interoperate existing locator/ID
> split protocols so I would say “define and deploy a mapping system”.
> *CLOSED*
>
>
>
> can have wording about working on an API, but APIs have always been a sore
> item in the IETF.  Also this is why I2NSF talks about Interfaces and
> Ideas mailing [email-masked]://www.ietf.org/mailman/listinfo/ideas
>
>
>

---

From: "[email-masked]" <[email-masked]>
Date: Tue, 22 Aug 2017 09:37:31 +0800

Padma,

Thanks for putting everything together. The updated charter looks good to me.

Regards，
Jiagui Xie

From: Padma Pillay-Esnault
Date: 2017-08-21 14:02
To: ideas
CC: Padma Pillay-Esnault
Subject: [Ideas] IDEAS Proposed Charter 08/20/2017 Version - Final Round
Dear IDEAS,
 
Thanks to everyone who sent their comments and feedback both on the list and off the list. The version below has integrated all the comments, inputs as well as discussions on the alias for the last 2 weeks. For your reference, a log of comments can be found at the end of this email.

Please send your comments by Thursday 08/24/2017 latest for this final round for feedback.

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 problem space is:
 
- Common infrastructure and primitives: The lack of a common infrastructure is a barrier for the application of 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 specify a framework that can be used by identifier-based protocols and provides services to address their requirements. We refer to the 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:
                 
- Specify a mapping system supporting the mapping combinations as needed
- Definition of primitives for identifier-location split protocols to interact with the framework
- Identifier/locator mapping and resolution (e.g. discovery, pub/sub, multi-homing, ...)
- 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 e.g. type)
- Management aspects and Data Models where appropriate.
 
The IDEAS WG will collaborate with LISP WG and HIP WG to extend their control planes if needed to meet the framework requirements.  The WG will also collaborate with other WG for any other relevant work. Furthermore, the WG will try to reuse technologies already developed when appropriate.
                 
WG deliverables include:
Generic Identity Services Framework
Other 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 for identifier/locator mapping and resolution
- Requirements for identity authentication and authorization service (for GRIDS).
- Applications of the architecture for use cases
- Threat model document 
 
Milestones

Modification Log and Comments
 
Comments on the 08/08/2017 Version 
Sam Sun: 
1) In the first item in "the IDEAS WG is chartered to work on...", what it means by "... interworking with identifier-location split protocols"? CLOSED
2) In the deliverables, could we include some of chartered tasks here? For example,
- Requirements for identifier/locator mapping and resolution CLOSED
- Requirements for identity authentication and authorization service (for GRIDS). CLOSED
 
Alex Clemm: 
 
Uma Chunduri: 
Looks fine and the term” control plane”   can be dropped from the above sentence.  #1  CLOSED
This list doesn’t capture #1 in the earlier description and IMO that should be listed too CLOSED
 
Lan Gao: 
I agree with Sam. Specific chartered tasks or a statement referencing the chartered tasks should be added to the Deliverables as the current document only implies that they will be met by the Generic Identity Services Framework. CLOSED
 
Bob Moskowitz: 
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. CLOSED

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

Dino Farinacci:
I would add “… control of end points over their identity address, location address, and data coupled with …”. CLOSED
 
I don’t know why there the use of the word “common” appears throughout. The charter really shouldn't intend to interoperate existing locator/ID split protocols so I would say “define and deploy a mapping system”. CLOSED
 
> - Definition of primitives for interworking with identifier-location split protocols
This isn’t useful to anyone. Having a HIP host talk to a LISP host solves nothing. It just creates complexity. And what if the LISP host has an IPv4 EID? CLOSED
I think the IDEAS WG should work with these working groups to make sure their control planes are extended to meet the requirements from IDEAS. But not to make them interoperate. CLOSED
Shreyasee Mukherjee: 
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.   CLOSED
 
-  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. CLOSED
 
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>. REJECTED – Email discussion -Too specific but this is implied by the addition above.
 
Generic Identity Services Framework – should this be defined further in terms of API, syntax/semantics, mapping service query/response/update protocol, etc.? REJECTED per comments on alias
 
Di Ma:
I think prospects described in IDEAS charter are promising since people fancy anonymity in connecting to different network environments, via identity/identifier separation.
 Yet by doing so, we would introduce new risk into the Internet.  Threat model is therefore indispensable to provide a basis for the design of future IDEAS security mechanisms.
 I suggest a threat model document as one of WG deliverables CLOSED
 
D. Raychaudhuri: 
I reviewed the charter document and feel that it is a good start.  My main comments are:
(1) I agree with the concept of an identity-identifier split, which is necessary for an important set of applications requiring dynamic change of identifier. Realizing this will require something similar to a trusted “name certification service”  [cf. “MobilityFirst: A Robust and Trustworthy Mobility-Centric Architecture for the Future Internet, ACM MC2R, July 2012] in addition to a dynamic name-to-locator mapping/resolution service [cf. ”DMap: A Shared Hosting Scheme for Dynamic Identifier to Locator Mappings in the Global Internet”, ICDCS 2012]
(2) A key requirement for the mapping service is the ability to support multiple types of resolution including identifier to identifier (i.e. recursive), identifier to group of identifiers, identifier to single locator, identifier to a list of locators, etc.  We have found the recursive identifier resolution capability to be very useful for scaling and new service creation.  CLOSED
(3) The final output of the WG at the end of the doc should be filled in a bit further in terms of specific APIs and query/response/update protocol definitions to be included in the spec. 
REJECTED by email discussion
Bob M.: You really don't want a starting charter this specific.  You can have wording about working on an API, but APIs have always been a sore item in the IETF.  Also this is why I2NSF talks about Interfaces and capablities, not APIs.  Leave the specitivity for the workgroup, not try and get the post-BOF to complete the work to start the workgroup.

(4) While I realize that the current charter’s scope is intentionally limited to defining general-purpose control plane support, the spec could be of greater value by defining or linking one or more specific identifier-based routing (data plane) protocols compatible with the IDEAS infrastructure. 
Bob M.:This comes out in the workgroup, and if necessary then you do a charter revision.  I need to talk to you separately about TAPS...

Albert Cabellos: 
I agree -in general- with the charter in its current form, below you can find some comments inline:
I suggest also mentioning overlay networking for virtualization as a use-case. CLOSED
 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. CLOSED
 why 'in addition'? The itemization already implicitly states: 'in addition'. CLOSED
 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:" CLOSED

Comments on the 08/06/2017 Version 
 
Yingzhen Qu: 
About “- Identity and Identifier Metadata (fixed or slow changing)”, I remember one of the comments we got before was to further limit the scope of metadata to just a couple of categories, for example type. CLOSED
 
Michael Menth : 
Clarity has improved.
 
Tom Herbert/Diego Lopez:
When it comes to these concerns I’d strongly recommend to have a look at how identity attributes were exchanged and trust established within the ABFAB framework (https://tools.ietf.org/wg/abfab/)
CLOSED - The charter now mentions to collaborate with other group for relevant work.

Tom Herbert: 
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" CLOSED with modifications from Albert, Dino, Uma
 
Alex Clemm: 
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.  CLOSED

Comments on the 08/02/201 Version 
 
-  Michael Menth: Michael, please let us know if this revision address some of your comments on clarity. CLOSED
- Alex Clemm. Alex , please chime on the revision regarding your addition. CLOSED
- Tom Herbert. Tom, Some of your suggestions are incorporated in this version. CLOSED
-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. CLOSED
- 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.CLOSED

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Tue, 22 Aug 2017 02:08:34 +0000

Hi!

Thanks to everyone who has contributed to building a Charter.

As I mentioned after the BoF [1]: “I am willing to sponsor a focused WG proposal to define a framework that reflects consensus on what is expected from the mapping system, the questions around identity persistence, privacy, etc.” – I think the text is still very wide as it attempts to go beyond defining a framework.  For example, it says that the WG will “Specify and deploy a mapping system, and related protocols…”

I haven’t seen discussion on the list that indicates to me that there is a common understanding on what is needed for us to take the additional step of defining solutions.  To be clear, I hope that we get to the point where a solution is defined, but the BoF failed to provide a cohesive direction, which is why I want to insist on focusing on a framework first – the faster we get done with that, the faster we can move to more work.  From a process point of view, and to facilitate discussion and approval, I would like to see the charter focus on that first step – re-chartering to include more work is an easy task.

Based on the current text, I’m including suggested text below.

The only other comment is related to the milestones: there is a long time between WGLC and sending the document to the IESG.  Ideally the work would be completed within a year – IOW, I would like the goal to be to re-charter by IETF 103 (in November of 2018).

Thanks!

Alvaro.

[1] https://mailarchive.ietf.org/arch/msg/ideas/VIBmuWm2lTpoA767qJR2elii_vA

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

Some of the areas that should be considered when developing the framework include:

- A flexible and extensible mapping system

- The concept of identity-identifier split and dynamic identifier changes, including anonymity and privacy.

The IDEAS WG will closely collaborate with LISP and HIP WGs. The WG will also collaborate with other WG as needed.

WG deliverables include:

  1.  Generic Identity Services Framework

(2) Other WG sustaining/informational documents may include:

- Problem statement

- Use cases

- Threat model document

Milestones

On 8/20/17, 11:02 PM, "Ideas on behalf of Padma Pillay-Esnault" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:

Dear IDEAS,

The problem space is:

WG deliverables include:

Milestones

Alex Clemm:

Uma Chunduri:

Lan Gao:

Bob Moskowitz:

Dino Farinacci:

Di Ma:

D. Raychaudhuri:

Albert Cabellos:

Yingzhen Qu:

Michael Menth :
Clarity has improved.

Tom Herbert/Diego Lopez:

Tom Herbert:

Alex Clemm:

---

From: Di Ma <[email-masked]>
Date: Tue, 22 Aug 2017 11:08:54 +0800

I think this version is in good shape and ready to move forwards.

Di  Ma
RPSTIR
https://bgpsecurity.net

> 在 2017年8月21日，14:02，Padma Pillay-Esnault <[email-masked]> 写道：
> 
> Dear IDEAS,
> 
>  
>

---

From: "Victor Moreno (vimoreno)" <[email-masked]>
Date: Tue, 22 Aug 2017 05:33:39 +0000

Team,

I agree that it makes sense to have an initial push focused on a framework. I think the exercise would naturally help the WG arrive at a prioritized expansion of the scope for a sub-sequent re-charter.

If others agree with this goal of focusing our initial activities, the text proposed by Alvaro improves the focus IMO. One concern: We should further discuss if the creation of mapping system primitives is to remain in scope (or if it is too close to a protocol in itself for this framework phase).

Victor

On Aug 21, 2017, at 7:08 PM, Alvaro Retana (aretana) <[email-masked]<mailto:[email-masked]>> wrote:

Definition of primitives for identifier-location split protocols to interact with the framework

---

From: Georgios Karagiannis <[email-masked]>
Date: Tue, 22 Aug 2017 08:21:44 +0000

Hi Alvaro,

Thanks for the clarification.
Your proposal on (1) having the Framework draft ready to be sent to IESG before November 2018 and (2) re-chartering of IDEAS WG after that, it makes very much  sense to me;

Best regards,
Georgios

From: Ideas [mailto:[email-masked]] On Behalf Of Alvaro Retana (aretana)
Sent: Tuesday, August 22, 2017 4:09 AM
To: Padma Pillay-Esnault; [email-masked]
Subject: Re: [Ideas] IDEAS Proposed Charter 08/20/2017 Version - Final Round

Hi!

Thanks!

Alvaro.

WG deliverables include:

- Problem statement

- Use cases

- Threat model document

Milestones

Dear IDEAS,

The problem space is:

WG deliverables include:

Milestones

Alex Clemm:

Uma Chunduri:

Lan Gao:

Bob Moskowitz:

Dino Farinacci:

Di Ma:

D. Raychaudhuri:

Albert Cabellos:

Yingzhen Qu:

Michael Menth :
Clarity has improved.

Tom Herbert/Diego Lopez:

Tom Herbert:

Alex Clemm:

---

From: <[email-masked]>
Date: Tue, 22 Aug 2017 08:25:32 +0000

Dear all,

I too support the suggestion and additional text made by Alvaro, let alone the revised milestones.

Cheers,

Christian.

De : Ideas [mailto:[email-masked]] De la part de Georgios Karagiannis
Envoyé : mardi 22 août 2017 10:22
À : Alvaro Retana (aretana); Padma Pillay-Esnault; [email-masked]
Objet : Re: [Ideas] IDEAS Proposed Charter 08/20/2017 Version - Final Round

Hi Alvaro,

Best regards,
Georgios

From: Ideas [mailto:[email-masked]] On Behalf Of Alvaro Retana (aretana)
Sent: Tuesday, August 22, 2017 4:09 AM
To: Padma Pillay-Esnault; [email-masked]<mailto:[email-masked]>
Subject: Re: [Ideas] IDEAS Proposed Charter 08/20/2017 Version - Final Round

Hi!

Thanks!

Alvaro.

WG deliverables include:

- Problem statement

- Use cases

- Threat model document

Milestones

Dear IDEAS,

The problem space is:

WG deliverables include:

Milestones

Alex Clemm:

Uma Chunduri:

Lan Gao:

Bob Moskowitz:

Dino Farinacci:

Di Ma:

D. Raychaudhuri:

Albert Cabellos:

Yingzhen Qu:

Michael Menth :
Clarity has improved.

Tom Herbert/Diego Lopez:

Tom Herbert:

Alex Clemm:

---

From: "[email-masked]" <[email-masked]>
Date: Tue, 22 Aug 2017 04:53:09 -0400

Ditto.

Sam

-------- Original Message --------
Subject: Re: [Ideas] IDEAS Proposed Charter 08/20/2017 Version - Final Round
From: [email-masked]
To: Georgios Karagiannis ,"Alvaro Retana (aretana)" ,Padma Pillay-Esnault ,[email-masked]
CC:

Dear all,

Cheers,

Christian.

De : Ideas [mailto:[email-masked]]
De la part de Georgios Karagiannis

Hi Alvaro,

Best regards,

Georgios

From: Ideas [mailto:[email-masked]]
On Behalf Of Alvaro Retana (aretana)

Hi!

As I mentioned after the BoF [1]: “I am willing to sponsor a focused WG proposal to define a framework that reflects consensus on what is expected from the mapping system, the questions around identity persistence, privacy, etc.” – I think
the text is still very wide as it attempts to go beyond defining a framework.  For example, it says that the WG will “Specify and deploy a mapping system, and related protocols…”

I haven’t seen discussion on the list that indicates to me that there is a common understanding on what is needed for us to take the additional step of defining solutions.  To be clear, I hope that we get to the point where a solution is
defined, but the BoF failed to provide a cohesive direction, which is why I want to insist on focusing on a framework first – the faster we get done with that, the faster we can move to more work.  From a process point of view, and to facilitate discussion
and approval, I would like to see the charter focus on that first step – re-chartering to include more work is an easy task.

The only other comment is related to the milestones: there is a long time between WGLC and sending the document to the IESG.  Ideally the work would be completed within a year – IOW, I would like the goal to be to re-charter by IETF 103
(in November of 2018).

Thanks!

Alvaro.

[1]
https://mailarchive.ietf.org/arch/msg/ideas/VIBmuWm2lTpoA767qJR2elii_vA

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

WG deliverables include:

1.

- Problem statement

- Use cases

- Threat model document

Milestones

On 8/20/17, 11:02 PM, "Ideas on behalf of Padma Pillay-Esnault" <[email-masked] on behalf of
[email-masked]> wrote:

Dear IDEAS,

Thanks to everyone who sent their comments and feedback both on the list and off the list. The version below has
integrated all the comments, inputs as well as discussions on the alias for the last 2 weeks. For your reference, a log of comments can be found at the end of this email.

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.

End users require greater privacy for their networking information and protection from outside threats, and operators demand
greater operational efficiency. Identity-enabled networks enable networking applications and services that provide a high degree of privacy and control of end points over their identity address, location address, and data coupled with greater inherent security
than provided by today’s networks.

- Specify and deploy a mapping system, and related protocol that provide a solution for existing 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

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

The problem space is:

- Common infrastructure and primitives: The lack of a common infrastructure is a barrier for the application of 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 specify a framework that can be used by identifier-based
protocols and provides services to address their requirements. We refer to the 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.

- 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…)

The IDEAS WG will collaborate with LISP WG and HIP WG to extend their control planes if needed to meet the framework
requirements.  The WG will also collaborate with other WG for any other relevant work. Furthermore, the WG will try to reuse technologies already developed when appropriate.

WG deliverables 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 for identity authentication and authorization
service (for GRIDS).

- Threat model document

Milestones

Sam Sun:

1) In the first item in "the IDEAS WG is chartered to work on...", what it means by "... interworking with identifier-location
split protocols"? CLOSED

Alex Clemm:

Uma Chunduri:

This list doesn’t capture #1 in the earlier description and IMO that should be listed too
CLOSED

Lan Gao:

I agree with Sam. Specific chartered tasks or a statement referencing the chartered tasks should be added to the Deliverables
as the current document only implies that they will be met by the Generic Identity Services Framework. CLOSED

Bob Moskowitz:

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.

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

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

Dino Farinacci:

I would add “… control of end points over their identity address, location address, and data coupled with …”.
CLOSED

I don’t know why there the use of the word “common” appears throughout. The charter really shouldn't intend to interoperate existing
locator/ID split protocols so I would say “define and deploy a mapping system”.
CLOSED

> - Definition of primitives for interworking with identifier-location split protocols

This isn’t useful to anyone. Having a HIP host talk to a LISP host solves nothing. It just creates complexity. And what if the LISP host has an IPv4 EID?
CLOSED

I think the IDEAS WG should work with these working groups to make sure their control planes are extended to meet the requirements
from IDEAS. But not to make them interoperate. CLOSED

Shreyasee Mukherjee:

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

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

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>.
REJECTED – Email discussion -Too specific but this is implied by the addition above.

Generic Identity Services Framework – should this be defined further in terms of API, syntax/semantics, mapping service query/response/update
protocol, etc.? REJECTED per comments on alias

Di Ma:

I think prospects described in IDEAS charter are promising since people fancy anonymity in connecting to different network environments,
via identity/identifier separation.

Yet by doing so, we would introduce new risk into the Internet.  Threat model is therefore indispensable to provide a basis
for the design of future IDEAS security mechanisms.

I suggest a threat model document as one of WG deliverables
CLOSED

D. Raychaudhuri:

(1) I agree with the concept of an identity-identifier split, which is necessary for an important set of applications requiring
dynamic change of identifier. Realizing this will require something similar to a trusted “name certification service”  [cf. “MobilityFirst: A Robust and Trustworthy Mobility-Centric Architecture for the Future Internet, ACM MC2R, July 2012] in addition to
a dynamic name-to-locator mapping/resolution service [cf. ”DMap: A Shared Hosting Scheme for Dynamic Identifier to Locator Mappings in the Global Internet”, ICDCS 2012]

(2) A key requirement for the mapping service is the ability to support multiple types of resolution including identifier to
identifier (i.e. recursive), identifier to group of identifiers, identifier to single locator, identifier to a list of locators, etc.  We have found the recursive identifier resolution capability to be very useful for scaling and new service creation.
CLOSED

(3) The final output of the WG at the end of the doc should be filled in a bit further in terms of specific APIs and query/response/update
protocol definitions to be included in the spec.

Bob M.: You really don't want a starting charter this specific.
You can have wording about working on an API, but APIs have always been a sore item in the IETF.  Also this is why I2NSF talks about Interfaces and capablities, not APIs.  Leave the specitivity for the workgroup, not try and get the post-BOF to complete the
work to start the workgroup.

(4) While I realize that the current charter’s scope is intentionally limited to defining general-purpose control plane support, the spec could be of greater value by defining or linking one or more specific identifier-based routing (data plane) protocols compatible
with the IDEAS infrastructure.

Bob M.:This comes out in the workgroup, and if necessary then
you do a charter revision.  I need to talk to you separately about TAPS...

Albert Cabellos:

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

'for *existing* identifier/locator mapping' --> 'all' might be too generic and not realizable.
CLOSED

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:" CLOSED

Yingzhen Qu:

About “- Identity and Identifier Metadata (fixed or slow changing)”, I remember one of the comments we got before was to further
limit the scope of metadata to just a couple of categories, for example type.
CLOSED

Michael Menth :

Clarity has improved.

Tom Herbert/Diego Lopez:

When it comes to these concerns I’d strongly recommend to have a look at how identity attributes were exchanged and trust established
within the ABFAB framework (https://tools.ietf.org/wg/abfab/)

CLOSED - The charter now mentions to collaborate with other
group for relevant work.

Tom Herbert:

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" CLOSED with modifications from Albert, Dino, Uma

Alex Clemm:

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

-  Michael Menth: Michael, please let us know if this revision address some of your comments on clarity.
CLOSED

-
Alex Clemm. Alex , please chime on the revision regarding your addition. CLOSED

-
Tom Herbert. Tom, Some of your suggestions are incorporated in this version.
CLOSED

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

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

---

From: Padma Pillay-Esnault <[email-masked]>
Date: Tue, 22 Aug 2017 09:39:05 -0700

Dear All

I support the changes in text and focusing on the framework as a first
delivery and then rechartering as proposed by Alvaro.

Regarding the milestones, I propose the following modification to reflect
Alvaro's comment.

*Milestones*

*Jan 2018 Adopt WG draft for the Generic Identity Services framework*

*July 2018 WGLC for the Generic Identity Services framework*

*September 2018 Send Generic Identity Services framework draft to the IESG*

*November 2018 Recharter *

Thanks
Padma

On Tue, Aug 22, 2017 at 1:53 AM, [email-masked] <
[email-masked]> wrote:

> *De :* Ideas [mailto:[email-masked]] *De la part de* Georgios
> Karagiannis
> *Envoyé :* mardi 22 août 2017 10:22
> *À :* Alvaro Retana (aretana); Padma Pillay-Esnault; [email-masked]
> *Objet :* Re: [Ideas] IDEAS Proposed Charter 08/20/2017 Version - Final
> Round
>
>
>
> Hi Alvaro,
>
>
>
> Your proposal on (1) having the Framework draft ready to be sent to IESG
> before November 2018 and (2) re-chartering of IDEAS WG after that, it makes
> very much  sense to me;
>
>
>
> Best regards,
>
> Georgios
>
>
>
>
>
> *From:* Ideas [mailto:[email-masked] <[email-masked]>] *On
> Behalf Of *Alvaro Retana (aretana)
> *Sent:* Tuesday, August 22, 2017 4:09 AM
> *To:* Padma Pillay-Esnault; [email-masked]
> *Subject:* Re: [Ideas] IDEAS Proposed Charter 08/20/2017 Version - Final
> Round
>
>
>
> Hi!
>
>
>
> As I mentioned after the BoF [1]: “I am willing to sponsor a focused WG
> proposal to define a framework that reflects consensus on what is expected
> from the mapping system, the questions around identity persistence,
> privacy, etc.” – I think the text is still very wide as it attempts to go
> beyond defining a framework.  For example, it says that the WG will
> “Specify and deploy a mapping system, and related protocols…”
>
>
>
> I haven’t seen discussion on the list that indicates to me that there is a
> common understanding on what is needed for us to take the additional step
> of defining solutions.  To be clear, I hope that we get to the point where
> a solution is defined, but the BoF failed to provide a cohesive direction,
> which is why I want to insist on focusing on a framework first – the faster
> we get done with that, the faster we can move to more work.  From a process
> point of view, and to facilitate discussion and approval, I would like to
> see the charter focus on that first step – re-chartering to include more
> work is an easy task.
>
>
>
> The only other comment is related to the milestones: there is a long time
> between WGLC and sending the document to the IESG.  Ideally the work would
> be completed within a year – IOW, I would like the goal to be to re-charter
> by IETF 103 (in November of 2018).
>
>
>
>
>
> Thanks!
>
>
>
> Alvaro.
>
>
>
> 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).
>
>
>
> The IDEAS WG will closely collaborate with LISP and HIP WGs. The WG will
> also collaborate with other WG as needed.
>
>
>
>
>
> WG deliverables include:
>
>
>
> On 8/20/17, 11:02 PM, "Ideas on behalf of Padma Pillay-Esnault" <
> [email-masked] on behalf of [email-masked]> wrote:
>
>
>
> Dear IDEAS,
>
>
>
> *Please send your comments by Thursday 08/24/2017 latest for this
> split protocols so I would say “define and deploy a mapping system”. *
> CLOSED*
>
>
>
> numbers of network addresses. * CLOSED*
>
>
>
> of metadata to just a couple of categories, for example type. * CLOSED*
>
>
>
> *Michael Menth* :
>
> Clarity has improved.
>
>
>

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Wed, 23 Aug 2017 21:05:20 +0000

Hi Padma,

So the outcome of the framework will determine what "Specify and deploy a mapping system, and related protocols…” actually entails?

Regards,
Reshad.

From: Ideas <[email-masked]<mailto:[email-masked]>> on behalf of Padma Pillay-Esnault <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, August 22, 2017 at 12:39 PM
To: "Alvaro Retana (aretana)" <[email-masked]<mailto:[email-masked]>>
Cc: Georgios Karagiannis <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Padma Pillay-Esnault <[email-masked]<mailto:[email-masked]>>, JACQUENET Christian IMT/OLN <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Ideas] IDEAS Proposed Charter 08/20/2017 Version - Final Round

Dear All

I support the changes in text and focusing on the framework as a first delivery and then rechartering as proposed by Alvaro.

Regarding the milestones, I propose the following modification to reflect Alvaro's comment.

Milestones

Jan 2018 Adopt WG draft for the Generic Identity Services framework

July 2018 WGLC for the Generic Identity Services framework

September 2018 Send Generic Identity Services framework draft to the IESG

November 2018 Recharter

Thanks
Padma

On Tue, Aug 22, 2017 at 1:53 AM, [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>> wrote:
Ditto.

Sam

-------- Original Message --------
Subject: Re: [Ideas] IDEAS Proposed Charter 08/20/2017 Version - Final Round
From: [email-masked]<mailto:[email-masked]>
To: Georgios Karagiannis ,"Alvaro Retana (aretana)" ,Padma Pillay-Esnault ,[email-masked]<mailto:[email-masked]>
CC:

Dear all,

Cheers,

Christian.

De : Ideas [mailto:[email-masked]<mailto:[email-masked]>] De la part de Georgios Karagiannis
Envoyé : mardi 22 août 2017 10:22
À : Alvaro Retana (aretana); Padma Pillay-Esnault; [email-masked]<mailto:[email-masked]>
Objet : Re: [Ideas] IDEAS Proposed Charter 08/20/2017 Version - Final Round

Hi Alvaro,

Best regards,
Georgios

Hi!

Thanks!

Alvaro.

WG deliverables include:

- Problem statement

- Use cases

- Threat model document

Milestones

Dear IDEAS,

The problem space is:

WG deliverables include:

Milestones

Alex Clemm:

Uma Chunduri:

Lan Gao:

Bob Moskowitz:

Dino Farinacci:

Di Ma:

D. Raychaudhuri:

Albert Cabellos:

Yingzhen Qu:

Michael Menth :
Clarity has improved.

Tom Herbert/Diego Lopez:

Tom Herbert:

Alex Clemm:

---

From: Alexander Clemm <[email-masked]>
Date: Thu, 24 Aug 2017 03:43:09 +0000

Seconding the comments from many others: Padma, great work; looks really good.

That said, I do have one small editorial comment, inline, <ALEX>

--- Alex

From: Ideas [mailto:[email-masked]] On Behalf Of Padma Pillay-Esnault
Sent: Sunday, August 20, 2017 11:03 PM
To: [email-masked]
Cc: Padma Pillay-Esnault <[email-masked]>
Subject: [Ideas] IDEAS Proposed Charter 08/20/2017 Version - Final Round

Dear IDEAS,

To this end, the working group shall:
- Specify and deploy a mapping system, and related protocol that provide a solution for existing 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
<ALEX> I think this needs to be rephrased a little.  For one, I am not sure we should say “deploy”.  How would the WG deploy a Mapping System?  Second, there are some singular/plural issues – the sentence is a bit hard to parse.
How about something along the following lines:
Specify a mapping system and related protocols to provide a mapping solution for existing identifier/locator protocols. The solution shall map identifiers to locators and support other new mapping combinations as needed.  It shall also support for network virtualization protocols that map virtual to physical addresses.
---  Alex
</ALEX>
- 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.

The problem space is:

WG deliverables include:

Milestones

Alex Clemm:

Uma Chunduri:

Lan Gao:

Bob Moskowitz:

Dino Farinacci:

Di Ma:

D. Raychaudhuri:

Albert Cabellos:

Yingzhen Qu:

Michael Menth :
Clarity has improved.

Tom Herbert/Diego Lopez:

Tom Herbert:

Alex Clemm:

---

From: Alberto Rodriguez-Natal <[email-masked]>
Date: Wed, 23 Aug 2017 21:27:48 -0700

Hi all,

I share the view that the WG main goal should be to deliver a framework. To
that end, I think that we can further polish the charter to clarify the
scope in order to help the WG to focus on that task. As Alvaro said, the WG
can re-charter to increase the scope as needed.

With the framework goal in mind, find below some extra edits on the
charter, based on the text suggested by Alvaro.

On Mon, Aug 21, 2017 at 7:08 PM, Alvaro Retana (aretana) <[email-masked]>
wrote:

[...]

> - A flexible and extensible mapping system

Flexibility and extensibility considerations

> interact with the framework

Description of interfaces for different protocols to interact with the
framework (e.g. id-loc split protocols, management protocols, etc)

> - Identifier/locator mapping and resolution (e.g. discovery, pub/sub,

Requirements for identifier/locator mapping resolution and mapping update
(e.g. discovery, pub/sub, multi-homing, ...)

> particular endpoints on a per-identity basis…)

Description of required basic network policies and policy enforcement needs
(e.g. ability to look up an identifier-locator pair, permit forwarding
traffic for particular endpoints on a per-identity basis…)

> including anonymity and privacy.
Analysis of the concepts of identity-identifier split and dynamic
identifier changes, including their implications on anonymity and privacy.

[...]

---

From: "Victor Moreno (vimoreno)" <[email-masked]>
Date: Thu, 24 Aug 2017 05:27:14 +0000

Dear All,

I second these edits as they help tighten up the initial focus on a Framework and associated requirements.

-v

On Aug 23, 2017, at 9:27 PM, Alberto Rodriguez-Natal <[email-masked]<mailto:[email-masked]>> wrote:

Hi all,

I share the view that the WG main goal should be to deliver a framework. To that end, I think that we can further polish the charter to clarify the scope in order to help the WG to focus on that task. As Alvaro said, the WG can re-charter to increase the scope as needed.

With the framework goal in mind, find below some extra edits on the charter, based on the text suggested by Alvaro.

On Mon, Aug 21, 2017 at 7:08 PM, Alvaro Retana (aretana) <[email-masked]<mailto:[email-masked]>> wrote:

[...]

Description of interfaces for different protocols to interact with the framework (e.g. id-loc split protocols, management protocols, etc)

Requirements for identifier/locator mapping resolution and mapping update (e.g. discovery, pub/sub, multi-homing, ...)

Description of required basic network policies and policy enforcement needs (e.g. ability to look up an identifier-locator pair, permit forwarding traffic for particular endpoints on a per-identity basis…)

Analysis of the concepts of identity-identifier split and dynamic identifier changes, including their implications on anonymity and privacy.

[...]

_______________________________________________
Ideas mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ideas

---

From: Robert Moskowitz <[email-masked]>
Date: Fri, 25 Aug 2017 17:03:49 -0400

I am ok with this charter.  It is a good start point and should carry us 
through most if not all of the work (what charter has survived first 
encounter with the enemy?  :) ).

Bob

PS.  Been a bit busy.

---

From: "Victor Moreno (vimoreno)" <[email-masked]>
Date: Tue, 29 Aug 2017 21:21:33 +0000

Thanks Padma, Team,

I am supportive of these new milestones.

There were some suggestions from Alberto (attached) to tighten down the language to focus on the goal of producing a Framework.

Subject: Re: [Ideas] IDEAS Proposed Charter 08/20/2017 Version - Final Round
From: Alberto Rodriguez-Natal <[email-masked]>
To: "[email-masked]" <[email-masked]>
Cc: "Alvaro Retana (aretana)" <[email-masked]>, Padma Pillay-Esnault <[email-masked]>
Date: Wed, 23 Aug 2017 21:27:48 -0700
List-Id: "Discussions relating to the development, clarification, and implementation of control-plane infrastructures and functionalities in ID enabled networks." <ideas.ietf.org>

Hi all,

On Mon, Aug 21, 2017 at 7:08 PM, Alvaro Retana (aretana) <[email-masked]>
wrote:

[...]

[...]

---

From: Padma Pillay-Esnault <[email-masked]>
Date: Tue, 29 Aug 2017 15:43:39 -0700

Thanks Victor.
Back after a few days off, will take a look

Thanks
Padma

Sent from my iPhone

> On Aug 29, 2017, at 14:21, Victor Moreno (vimoreno) <[email-masked]> wrote:
> 
> Thanks Padma, Team,
> 
> <mime-attachment>
> If there are no concerns with those edits, the charter including the edits from both Alvaro and Alberto and the revised milestones would look as follows:
> 
> - Flexibility and extensibility considerations
>  
> - Description of interfaces for different protocols to interact with the framework (e.g. id-loc split protocols, management protocols, etc)
>  
> - Requirements for identifier/locator mapping resolution and mapping update (e.g. discovery, pub/sub, multi-homing, ...) 
>  
> - Description of required basic network policies and policy enforcement needs (e.g. ability to look up an identifier-locator pair, permit forwarding traffic for particular endpoints on a per-identity basis…)
>  
> - Analysis of the concepts of identity-identifier split and dynamic identifier changes, including their implications on anonymity and privacy.
>  
>  
> January 2018 Adopt WG draft for the Generic Identity Services framework
>  
>> On Aug 22, 2017, at 9:39 AM, Padma Pillay-Esnault <[email-masked]> wrote:
>> 
>> Dear All
>> 
>>> On Tue, Aug 22, 2017 at 1:53 AM, [email-masked] <[email-masked]> wrote:
>>> Ditto.
>>> 
>>> 
>>> Sam
>>> 
>>> 
>>> On 8/20/17, 11:02 PM, "Ideas on behalf of Padma Pillay-Esnault" <[email-masked] on behalf of [email-masked]> wrote:
>>> 
>>>  
>>> 
>>> Dear IDEAS,
>>> 
>>>  
>>>

---

From: Padma Pillay-Esnault <[email-masked]>
Date: Tue, 29 Aug 2017 22:56:10 -0700

Hi Reshad

On Wed, Aug 23, 2017 at 2:05 PM, Reshad Rahman (rrahman) <[email-masked]>
wrote:

> Hi Padma,
>
> So the outcome of the framework will determine what "Specify and deploy a
> mapping system, and related protocols…” actually entails?
>
>
There are some rewording in that area proposed to tighten the charter.
Will get back to your question if it is still not clear.

Thanks
Padma

> Regards,
> Reshad.
>
> From: Ideas <[email-masked]> on behalf of Padma Pillay-Esnault <
> [email-masked]>
> To: "Alvaro Retana (aretana)" <[email-masked]>
> Cc: Georgios Karagiannis <[email-masked]>, "
> [email-masked]" <[email-masked]>, "[email-masked]" <
> [email-masked]>, Padma Pillay-Esnault <[email-masked]>, JACQUENET
> Christian IMT/OLN <[email-masked]>
>
>> I haven’t seen discussion on the list that indicates to me that there is
>> a common understanding on what is needed for us to take the additional step
>> The IDEAS WG is chartered to produce a framework document that defines
>> the expected behavior of a mapping system across the multiple existing use
>> - Definition and enforcement of basic networking policies (e.g. ability
>> to look up an identifier-locator pair, permit forwarding traffic for
>> - The concept of identity-identifier split and dynamic identifier
>> changes, including anonymity and privacy.
>>
>>
>>
>>
>>
>> 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
>> - Specify and deploy a mapping system, and related protocol that provide
>> a solution for existing identifier/locator protocols that map identifiers
>> to locators as well other new mapping combinations as needed, as well as
>> - Definition and enforcement of basic networking policies (e.g. ability
>> to look up an identifier-locator pair, permit forwarding traffic for
>> 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
>> 1) In the first item in "the IDEAS WG is chartered to work on...", what
>> it means by "... interworking with identifier-location split protocols"?
>> *CLOSED*
>> info which can be wordsmithed til the cows come home (as they say).  But to
>> put my fork in it:
>> (3) The final output of the WG at the end of the doc should be filled in
>> a bit further in terms of specific APIs and query/response/update protocol
>> 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. *CLOSED*
>>
>> an ongoing discussion about the framework. This version is flexible enough
>> to accommodate the work to be done on defining the framework.
>>

---

From: Padma Pillay-Esnault <[email-masked]>
Date: Tue, 29 Aug 2017 23:12:40 -0700

Hi Alberto

Thanks for your review and comments.

Agree with all your changes - will integrate them

Thanks
Padma

On Wed, Aug 23, 2017 at 9:27 PM, Alberto Rodriguez-Natal <
[email-masked]> wrote:

> Hi all,
>
> I share the view that the WG main goal should be to deliver a framework.
> To that end, I think that we can further polish the charter to clarify the
> On Mon, Aug 21, 2017 at 7:08 PM, Alvaro Retana (aretana) <
> [email-masked]> wrote:
>
>>
>>
> [...]
>
>
> Description of required basic network policies and policy enforcement
> needs (e.g. ability to look up an identifier-locator pair, permit
> forwarding traffic for particular endpoints on a per-identity basis…)
>
>

---

From: Alberto Rodriguez-Natal <[email-masked]>
Date: Wed, 30 Aug 2017 17:41:12 -0700

Sounds good, thank you Padma.

Best,
Alberto

On Tue, Aug 29, 2017 at 11:12 PM, Padma Pillay-Esnault <[email-masked]

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Thu, 31 Aug 2017 02:04:21 +0000

Hi Padma,

I am fine with proposed charter with latest edits.

Regards,
Reshad.

From: Padma Pillay-Esnault <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, August 30, 2017 at 1:56 AM
To: Reshad <[email-masked]<mailto:[email-masked]>>
Cc: "Alvaro Retana (aretana)" <[email-masked]<mailto:[email-masked]>>, Georgios Karagiannis <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, JACQUENET Christian IMT/OLN <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Ideas] IDEAS Proposed Charter 08/20/2017 Version - Final Round

Hi Reshad

On Wed, Aug 23, 2017 at 2:05 PM, Reshad Rahman (rrahman) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Padma,

Thanks
Padma
Regards,
Reshad.

Dear All

Milestones

November 2018 Recharter

Thanks
Padma

Sam

-------- Original Message --------
Subject: Re: [Ideas] IDEAS Proposed Charter 08/20/2017 Version - Final Round
From: [email-masked]<mailto:[email-masked]>
To: Georgios Karagiannis ,"Alvaro Retana (aretana)" ,Padma Pillay-Esnault ,[email-masked]<mailto:[email-masked]>
CC:

Dear all,

Cheers,

Christian.

Hi Alvaro,

Best regards,
Georgios

Hi!

Thanks!

Alvaro.

WG deliverables include:

- Problem statement

- Use cases

- Threat model document

Milestones

Dear IDEAS,

The problem space is:

WG deliverables include:

Milestones

Alex Clemm:

Uma Chunduri:

Lan Gao:

Bob Moskowitz:

Dino Farinacci:

Di Ma:

D. Raychaudhuri:

Albert Cabellos:

Yingzhen Qu:

Michael Menth :
Clarity has improved.

Tom Herbert/Diego Lopez:

Tom Herbert:

Alex Clemm: