Subject: [Ideas] Prep for BOF in July - Your input Needed on a Charter Proposal

From: Padma Pillay-Esnault <[email-masked]>
Date: Sat, 13 May 2017 17:08:15 -0700

Hello IDEAS

The deadline for a request for a BOF for IETF99 in July is 6/02/2017 and
just a few weeks away.

Please see below a tentative charter proposal. We would like to have input
from the list regarding the charter. We would like to hear from you
regarding the scope of work and your interests.

Proposed Charter

The Identity Enabled Networks (IDEAS) working group focuses on the
framework  to implement a common control plane for identifier–location
separation protocols.

The identifier-enabled solutions and applications are increasingly being
considered to support mobility solutions across heterogeneous access
networks, Internet of Things, Machine to Machine (M2M), context aware
applications and security.  Due to the diverse nature of devices and
applications, it may not be possible to deploy a single protocol end to
end. A common control plane will address siloes in discovery and
communications.  Moreover, a common control plane will address the
technical and operational hurdle to deployment and interoperability of
solutions.

The working group will specify an overall architecture for  a common
control plane and services for identity-enabled technology.  More
specifically these services will include:

·      registration and lifecycle management of identities and associated
identifiers

·      identifier binding to location(s),

·      support for grouping,

·      definition and enforcement of policies

·      support for metadata.

Additionally, the control plane interface and protocol extensions that
allow clients to communicate with that infrastructure will be covered.

The abstraction provided by a secured identity will give a new level of
control for confidentiality, accountability, security and access-control.
The working group will cover these aspects and balance them with the
minimized storage of data and privacy considerations.

Specifically, the IDEAS WG is chartered to work on these areas:

Overall architecture: This work covers the control plane, management,
policy control, and security aspects.

Manageability of the architecture: The working group will cover the
management aspects of IDEAS architectural components and the services that
they provide.

Interface to the architecture: This work will cover interface interactions
between the framework and identifier-enabled protocol.

Where appropriate, the IDEAS WG will collaborate with other Working Groups
to ensure interoperability with LISP, HIP, ILA and other relevant work.

WG deliverables include:

Overall architecture

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

.....

Milestones

TBD

---

From: "Liubingyang (Bryan)" <[email-masked]>
Date: Tue, 16 May 2017 06:27:51 +0000

Thanks for the proposal.

I suggest a minor modification in the scope, i.e., changing “a common control plane for identifier–location separation protocols” into “a common control plane for identifiers and identifier-location separation protocols”.
The main reason is that ID by itself has a lot of work to do in the control plane, including life cycle management, security and metadata as in your list. So the scope should be the control plane for identifiers as well as ID/Loc protocols.

Bingyang (Bryan)

From: Ideas [mailto:[email-masked]] On Behalf Of Padma Pillay-Esnault
Sent: Sunday, May 14, 2017 8:08 AM
To: [email-masked]
Subject: [Ideas] Prep for BOF in July - Your input Needed on a Charter Proposal

Hello IDEAS

The deadline for a request for a BOF for IETF99 in July is 6/02/2017 and just a few weeks away.

Please see below a tentative charter proposal. We would like to have input from the list regarding the charter. We would like to hear from you regarding the scope of work and your interests.

Proposed Charter

The Identity Enabled Networks (IDEAS) working group focuses on the framework  to implement a common control plane for identifier–location separation protocols.

The identifier-enabled solutions and applications are increasingly being considered to support mobility solutions across heterogeneous access networks, Internet of Things, Machine to Machine (M2M), context aware applications and security.  Due to the diverse nature of devices and applications, it may not be possible to deploy a single protocol end to end. A common control plane will address siloes in discovery and communications.  Moreover, a common control plane will address the technical and operational hurdle to deployment and interoperability of solutions.

The working group will specify an overall architecture for  a common control plane and services for identity-enabled technology.  More specifically these services will include:
•      registration and lifecycle management of identities and associated identifiers
•      identifier binding to location(s),
•      support for grouping,
•      definition and enforcement of policies
•      support for metadata.
Additionally, the control plane interface and protocol extensions that allow clients to communicate with that infrastructure will be covered.

The abstraction provided by a secured identity will give a new level of control for confidentiality, accountability, security and access-control. The working group will cover these aspects and balance them with the minimized storage of data and privacy considerations.

Overall architecture: This work covers the control plane, management, policy control, and security aspects.

Manageability of the architecture: The working group will cover the management aspects of IDEAS architectural components and the services that they provide.

Interface to the architecture: This work will cover interface interactions between the framework and identifier-enabled protocol.

Where appropriate, the IDEAS WG will collaborate with other Working Groups to ensure interoperability with LISP, HIP, ILA and other relevant work.

WG deliverables include:
Overall architecture

Milestones
TBD

---

From: Alexander Clemm <[email-masked]>
Date: Tue, 16 May 2017 19:50:58 +0000

Overall this looks fine to me.  However, the deliverables section should probably be a bit more specific, in particular given the scope of the charter.  In addition to “overall architecture”, there will need to be deliverables for the other points as well, specifically interfaces for each of the distinct services that are taken into the charter and the data exchanged across these interfaces.

--- Alex

From: Ideas [mailto:[email-masked]] On Behalf Of Padma Pillay-Esnault
Sent: Saturday, May 13, 2017 5:08 PM
To: [email-masked]
Subject: [Ideas] Prep for BOF in July - Your input Needed on a Charter Proposal

Hello IDEAS

Proposed Charter

WG deliverables include:
Overall architecture

Milestones
TBD

---

From: Tom Herbert <[email-masked]>
Date: Tue, 16 May 2017 17:17:03 -0700

Hi Padma,

Thanks for leading this effort.

A few comments on the charter...

On Sat, May 13, 2017 at 5:08 PM, Padma Pillay-Esnault
<[email-masked]> wrote:
> The Identity Enabled Networks (IDEAS) working group focuses on the framework
> to implement a common control plane for identifier–location separation
> protocols.
>
Identifier-location separation protocols probably should be defined. I
think this actually could easily be used as a control network
virtualization where identifiers are virtual addresses and locators
are physical addresses. I guess it depends on how much scope we're
shooting for.

> networks, Internet of Things, Machine to Machine (M2M), context aware

Mobility is also a bit of a loaded term. Mobility of devices like UEs
from cell to cell, or mobility of task between machines in a
datacenter are physically very different but logically could end up
using prety much the same mechanisms (for instance ILA is being used
in DC as a direct alternative to encapsulation). Again, seems to be a
matter of how much scope this entails.

> applications, it may not be possible to deploy a single protocol end to end.
Isn't that kind of a given?

> A common control plane will address siloes in discovery and communications.

Not sure what these "siloes" are.

> Moreover, a common control plane will address the technical and operational
> hurdle to deployment and interoperability of solutions.
>
That's good.

>
>
> The working group will specify an overall architecture for  a common control
> plane and services for identity-enabled technology.  More specifically these
> services will include:
>
Maybe something about dynamic updates and minimizing convergence time,

> Additionally, the control plane interface and protocol extensions that allow
> clients to communicate with that infrastructure will be covered.
>
>
>

"new level of control" sounds like marketing. Maybe just take this out.

> to ensure interoperability with LISP, HIP, ILA and other relevant work.
Should the use case or relevance to 5G/3GPP be mentioned?

Tom

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

---

From: "Liubingyang (Bryan)" <[email-masked]>
Date: Wed, 17 May 2017 01:06:02 +0000

Agree on Tom's opinion on ID/Loc protocols. Basically it is mapping from one name space to another, and perhaps the first one is topology-independent while the second one is not. For end host mobility or virtual machine migration, they are basically changing topological locations. 

-----Original Message-----
From: Ideas [mailto:[email-masked]] On Behalf Of Tom Herbert
Sent: Wednesday, May 17, 2017 8:17 AM
To: Padma Pillay-Esnault <[email-masked]>
Cc: [email-masked]
Subject: Re: [Ideas] Prep for BOF in July - Your input Needed on a Charter Proposal

Hi Padma,

On Sat, May 13, 2017 at 5:08 PM, Padma Pillay-Esnault <[email-masked]> wrote:
> Please see below a tentative charter proposal. We would like to have 
> input from the list regarding the charter. We would like to hear from 
> you regarding the scope of work and your interests.
>
> Proposed Charter
>
>
>
Identifier-location separation protocols probably should be defined. I think this actually could easily be used as a control network virtualization where identifiers are virtual addresses and locators are physical addresses. I guess it depends on how much scope we're shooting for.

>
>
> The identifier-enabled solutions and applications are increasingly 
> being considered to support mobility solutions across heterogeneous 
> access networks, Internet of Things, Machine to Machine (M2M), context 
> aware

Mobility is also a bit of a loaded term. Mobility of devices like UEs from cell to cell, or mobility of task between machines in a datacenter are physically very different but logically could end up using prety much the same mechanisms (for instance ILA is being used in DC as a direct alternative to encapsulation). Again, seems to be a matter of how much scope this entails.

> Moreover, a common control plane will address the technical and 
> operational hurdle to deployment and interoperability of solutions.
>
That's good.

> The abstraction provided by a secured identity will give a new level 
> of control for confidentiality, accountability, security and access-control.

> management aspects of IDEAS architectural components and the services 
> that they provide.
>
>
>
> Interface to the architecture: This work will cover interface 
> interactions between the framework and identifier-enabled protocol.
>
>
>
> Where appropriate, the IDEAS WG will collaborate with other Working 
> Groups to ensure interoperability with LISP, HIP, ILA and other relevant work.
>

Tom

---

From: Padma Pillay-Esnault <[email-masked]>
Date: Tue, 16 May 2017 22:43:33 -0700

Hi Alex

Thanks for your feedback.

Do you want to write some text to cover this?

Thanks
Padma

On Tue, May 16, 2017 at 12:50 PM, Alexander Clemm <
[email-masked]> wrote:

> Overall this looks fine to me.  However, the deliverables section should
> probably be a bit more specific, in particular given the scope of the
> charter.  In addition to “overall architecture”, there will need to be
> deliverables for the other points as well, specifically interfaces for each
> of the distinct services that are taken into the charter and the data
> exchanged across these interfaces.
>
>
>
> --- Alex
>
>
>
> *From:* Ideas [mailto:[email-masked]] *On Behalf Of *Padma
> Pillay-Esnault
> *Sent:* Saturday, May 13, 2017 5:08 PM
> *To:* [email-masked]
> *Subject:* [Ideas] Prep for BOF in July - Your input Needed on a Charter
> Proposal
>
>
>
> Hello IDEAS
>
>
>

---

From: Padma Pillay-Esnault <[email-masked]>
Date: Tue, 16 May 2017 22:45:34 -0700

Hello Bingyang

Looks like a good suggestion.
Will add it. If anyone has concerns please let us know

Thanks
Padma

On Mon, May 15, 2017 at 11:27 PM, Liubingyang (Bryan) <
[email-masked]> wrote:

> Thanks for the proposal.
>
>
>
> I suggest a minor modification in the scope, i.e., changing “a common
> control plane for identifier–location separation protocols” into “a common
> control plane for* identifiers and* identifier-location separation
> protocols”.
>
> The main reason is that ID by itself has a lot of work to do in the
> control plane, including life cycle management, security and metadata as in
> your list. So the scope should be the control plane for identifiers as well
> as ID/Loc protocols.
>
>
>
> Bingyang (Bryan)
>
>
>
> *Sent:* Sunday, May 14, 2017 8:08 AM
> *To:* [email-masked]

---

From: Padma Pillay-Esnault <[email-masked]>
Date: Tue, 16 May 2017 23:24:02 -0700

Hi Tom, Bingyang

See below <PPE> for comments

On Tue, May 16, 2017 at 6:06 PM, Liubingyang (Bryan) <[email-masked]
> wrote:

> Agree on Tom's opinion on ID/Loc protocols. Basically it is mapping from
> one name space to another, and perhaps the first one is
> topology-independent while the second one is not. For end host mobility or
> virtual machine migration, they are basically changing topological
> locations.
>

<PPE>

Agree as well. We should add this for clarity.

Bingyang I really like the ideas of putting mapping one name space to
another.
Regarding whether a namespace is topology independent completely may
actually depend on how we decide to do the allocation.

This is an important discussion and I would suggest we use two names spaces
independent of each other. Thoughts?

> virtualization where identifiers are virtual addresses and locators are
> physical addresses. I guess it depends on how much scope we're shooting for.
>
> <PPE>
If we say they are independent of each other that should cover the scope
issue.

> Mobility is also a bit of a loaded term. Mobility of devices like UEs from
> cell to cell, or mobility of task between machines in a datacenter are
> physically very different but logically could end up using prety much the
> same mechanisms (for instance ILA is being used in DC as a direct
> alternative to encapsulation). Again, seems to be a matter of how much
> scope this entails.
>

<PPE>
Yes I see what you mean, by mobility the text is really talking about the
case of  changing your locator. If you keep the same locator that would be
transparent to the network and still be seen as fixed.

The interesting application is really the hetnet cases which will most
probably cause changes of locator and also have multihoming.

We should actually add some text on multihoming handling.

> end.
> <PPE>
After discussion it would seem this is not clear to all.  The sentence does
no harm here. Thoughts?

> Not sure what these "siloes" are.

<PPE> fragmented communication or discovery because of different systems.
Will rephrase.

> Maybe something about dynamic updates and minimizing convergence time,

<PPE> Ok will add

> "new level of control" sounds like marketing. Maybe just take this out.

<PPE>
ok will rephrase this

> Should the use case or relevance to 5G/3GPP be mentioned?

<PPE> Yes we can add something about this.

Thanks for your comments
Will respin this and resend

Padma

---

From: Tom Herbert <[email-masked]>
Date: Wed, 17 May 2017 08:25:20 -0700

> control, and security aspects.
Like other mapping systems (routing, DNS) there will probably be a
natural two level protocol hierarchy in the system. 1) The
authoritative servers that synchronize the full mapping table for a
domain and possibly shard it 2) A means for hosts to cache a subset of
mappings without consulting the master for every use. Between the
servers a protocol is needed with goal of synchronizing the
distributed table. For the host cache protocol the goal is to manage
the cache and keep it up to date as much a possible. Cache management
will break down to whether it's a pull or a push model. Pull
techniques would be like address resolution (like ARP as a model),
push would be re-directs, cache invalidation, etc. There are some
significant differences in security between pull and push, pull being
the easier one to make secure since requests can be validated using a
nonce.

Another thing that might be mentioned in charter is what intended
scope is. Is the goal to have one public mapping table system (like
DNS) for the Internet with hierarchy that would allow sites to create
their own mapping tables? Or would each site create there own tables
and if they want to share mapping information with their partners they
can do so by a private agreement? (personally I'd favor the second
approach).

Tom

---

From: Declan Ma <[email-masked]>
Date: Thu, 18 May 2017 00:04:54 +0800

Padma,

This is really a good start. 

See my comments in lines.

> 在 2017年5月14日，08:08，Padma Pillay-Esnault <[email-masked]> 写道：
> 
> Hello IDEAS
> 
> ·      registration and lifecycle management of identities and associated identifiers
> 

I suggest identity certification, as one of security aspects be specific.

The way to certify the holding or custodianship of an identifier in a naming space bears significance, which could vary among different design, self-certified or third-party certified. 

I believe this issue has something to do with top level design of this common control plane. 

Declan (Di) Ma

ZDNS

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 17 May 2017 09:26:05 -0700

> This is really a good start. 

I agree as well. But have one question on the opening sentence.

>> The Identity Enabled Networks (IDEAS) working group focuses on the framework  to implement a common control plane for identifier–location separation protocols.

So is IDEAs:

(1) Creating the framework?

(2) Defining protocols to implement?

(3) Does implement mean “deploy” or “create mechanisms”.

Shouldn’t you state that the working group will use solutions from other working groups?

Thanks,
Dino

---

From: Tom Herbert <[email-masked]>
Date: Wed, 17 May 2017 09:39:13 -0700

> The deadline for a request for a BOF for IETF99 in July is 6/02/2017 and
What area would IDEAS WG be in?

Tom

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 17 May 2017 09:54:53 -0700

> What area would IDEAS WG be in?

I believe it is needed in the OPs area but that doesn’t mean it should go there.

Dino

---

From: Alexander Clemm <[email-masked]>
Date: Wed, 17 May 2017 21:50:11 +0000

I also think it makes sense in ops.
--- Alex

-----Original Message-----
From: Ideas [mailto:[email-masked]] On Behalf Of Dino Farinacci
Sent: Wednesday, May 17, 2017 9:55 AM
To: Tom Herbert <[email-masked]>
Cc: Padma Pillay-Esnault <[email-masked]>; [email-masked]
Subject: Re: [Ideas] Prep for BOF in July - Your input Needed on a Charter Proposal

Dino

>> access networks, Internet of Things, Machine to Machine (M2M), 
>> context aware applications and security.  Due to the diverse nature 
>> of devices and applications, it may not be possible to deploy a single protocol end to end.
>> Additionally, the control plane interface and protocol extensions 
>> that allow clients to communicate with that infrastructure will be covered.
>> 
>> 
>>

---

From: Alexander Clemm <[email-masked]>
Date: Wed, 17 May 2017 22:08:19 +0000

FWIW, two comments on various aspects raised in this thread, one by Bingyang, the other by Tom:

- On mapping name spaces between each other:  At one level this is true, we could phrase it that way.  However, this implies there is no distinction between locators, identifiers, etc.  There would be merely "name spaces" (of possibly different type), and locators would be treated like "names".  If we go this route, we need to be aware of ramifications, e.g. concerning uniqueness requirement.  Depending on the coordinate system used for the locators, uniqueness may not always be a given.  Another difference concerns how names come into being - different for a name (that is assigned, or that is registered) from a "coordinate" - the life cycle of IDs and locators may have to be managed differently, and I would not expect this differentiation to be made at the level of the namespace.   In other words, while this path will give us a very general mapping system (a good thing) that can be used as part of a control plane, I don't think this would constitute a control plane in itself itself, so this part of the charter would need to be adjusted.  

- On the issue of hierarchies: I'm not a big fan of that and subscribe more to Tom's point of view.  However, we will need to be able distinguish the sharing of mapping information and the sharing of naming information (i.e., while a name might be shared, its associated mapping might not be).  

--- Alex

-----Original Message-----
From: Ideas [mailto:[email-masked]] On Behalf Of Tom Herbert
Sent: Wednesday, May 17, 2017 8:25 AM
To: Padma Pillay-Esnault <[email-masked]>
Cc: [email-masked]
Subject: Re: [Ideas] Prep for BOF in July - Your input Needed on a Charter Proposal

On Sat, May 13, 2017 at 5:08 PM, Padma Pillay-Esnault <[email-masked]> wrote:
> aware applications and security.  Due to the diverse nature of devices 
> and applications, it may not be possible to deploy a single protocol end to end.
Like other mapping systems (routing, DNS) there will probably be a natural two level protocol hierarchy in the system. 1) The authoritative servers that synchronize the full mapping table for a domain and possibly shard it 2) A means for hosts to cache a subset of mappings without consulting the master for every use. Between the servers a protocol is needed with goal of synchronizing the distributed table. For the host cache protocol the goal is to manage the cache and keep it up to date as much a possible. Cache management will break down to whether it's a pull or a push model. Pull techniques would be like address resolution (like ARP as a model), push would be re-directs, cache invalidation, etc. There are some significant differences in security between pull and push, pull being the easier one to make secure since requests can be validated using a nonce.

Another thing that might be mentioned in charter is what intended scope is. Is the goal to have one public mapping table system (like
DNS) for the Internet with hierarchy that would allow sites to create their own mapping tables? Or would each site create there own tables and if they want to share mapping information with their partners they can do so by a private agreement? (personally I'd favor the second approach).

Tom

---

From: Hesham ElBakoury <[email-masked]>
Date: Wed, 17 May 2017 22:42:31 +0000

Why OPS not Rtg area like LISP ?

Hesham

-----Original Message-----
From: Ideas [mailto:[email-masked]] On Behalf Of Dino Farinacci
Sent: Wednesday, May 17, 2017 9:55 AM
To: Tom Herbert
Cc: Padma Pillay-Esnault; [email-masked]
Subject: Re: [Ideas] Prep for BOF in July - Your input Needed on a Charter Proposal

Dino

---

From: Tom Herbert <[email-masked]>
Date: Wed, 17 May 2017 15:55:20 -0700

> Why OPS not Rtg area like LISP ?
I was thinking this should be routing as well.

---

From: Padma Pillay-Esnault <[email-masked]>
Date: Wed, 17 May 2017 22:47:24 -0700

On Wed, May 17, 2017 at 8:25 AM, Tom Herbert <[email-masked]> wrote:

> <snip>

Agree with most of your points.
I am not sure that we really want to synchronize the full mapping table but
I agree on 2 where ou really want to have efficient cache management.

> can do so by a private agreement? (personally I'd favor the second
I am in favor of second as well and think this is more realistic for the
use cases.

Padma

> that
> interactions
> Groups

---

From: Padma Pillay-Esnault <[email-masked]>
Date: Wed, 17 May 2017 22:48:45 -0700

Hi Declan

Thank you for your feedback and suggestions.
See my comments below <PPE>

> I suggest identity certification, as one of security aspects be specific.
<PPE> Ok will add that somewhere

> The way to certify the holding or custodianship of an identifier in a
> naming space bears significance, which could vary among different design,
> self-certified or third-party certified.
>
> <PPE> Correct.

Thanks
Padma

---

From: Padma Pillay-Esnault <[email-masked]>
Date: Wed, 17 May 2017 23:08:32 -0700

Hi Alex

Comments see <PPE>

On Wed, May 17, 2017 at 3:08 PM, Alexander Clemm <[email-masked]

> - On mapping name spaces between each other:  At one level this is true,
> we could phrase it that way.  However, this implies there is no distinction
> between locators, identifiers, etc.  There would be merely "name spaces"
> (of possibly different type), and locators would be treated like "names".
> If we go this route, we need to be aware of ramifications, e.g. concerning
> uniqueness requirement.  Depending on the coordinate system used for the
> locators, uniqueness may not always be a given.  Another difference
> concerns how names come into being - different for a name (that is
> assigned, or that is registered) from a "coordinate" - the life cycle of
> IDs and locators may have to be managed differently, and I would not expect
> this differentiation to be made at the level of the namespace.   In other
> words, while this path will give us a very general mapping system (a good
> thing) that can be used as part of a control plane, I don't think this
> would constitute a control plane in itself itself, so this part of the
> charter would need to be adjusted.
>

<PPE> I tend to agree that making it general is a good thing.

@ Alex If I understand you correctly ... Your concern is that today the
located is based on IP and that guarantees some kind of uniqueness which we
will rely on. However this may not be the case if we use another namespace.
However, if there is no uniqueness in the locator then I would assume this
is broken as forwarding would not be deterministic.

@ Bingyang My understanding is that you wanted to generalize this for
forwarding on L3 and L2.
Is this what you had in mind?

> - On the issue of hierarchies: I'm not a big fan of that and subscribe
> more to Tom's point of view.  However, we will need to be able distinguish
> the sharing of mapping information and the sharing of naming information
> (i.e., while a name might be shared, its associated mapping might not be).
>
> <PPE> Agree with Alex and Tom here. I do not think that all mappings need
to be shared. I would even say that this should be a feature.

> Like other mapping systems (routing, DNS) there will probably be a natural
> two level protocol hierarchy in the system. 1) The authoritative servers
> that synchronize the full mapping table for a domain and possibly shard it
> 2) A means for hosts to cache a subset of mappings without consulting the
> master for every use. Between the servers a protocol is needed with goal of
> synchronizing the distributed table. For the host cache protocol the goal
> is to manage the cache and keep it up to date as much a possible. Cache
> management will break down to whether it's a pull or a push model. Pull
> techniques would be like address resolution (like ARP as a model), push
> would be re-directs, cache invalidation, etc. There are some significant
> differences in security between pull and push, pull being the easier one to
> make secure since requests can be validated using a nonce.
>
> Another thing that might be mentioned in charter is what intended scope
> is. Is the goal to have one public mapping table system (like
> their own mapping tables? Or would each site create there own tables and if
> they want to share mapping information with their partners they can do so
> by a private agreement? (personally I'd favor the second approach).
>
> Tom
>
> >
> >

---

From: Padma Pillay-Esnault <[email-masked]>
Date: Wed, 17 May 2017 23:30:35 -0700

Hi Dino

Thank you for the review and feedback.

On Wed, May 17, 2017 at 9:26 AM, Dino Farinacci <[email-masked]> wrote:

> input from the list regarding the charter. We would like to hear from you

<PPE> Ideas should define an architecture which is then the basis for a
framework. Does that make sense?

> (2) Defining protocols to implement?

<PPE> The control plane itself may be two parts, one interaction between
the infrastructure and a data plane protocol. The other between components
of the grids itself for example depending on how we do the leaking between
the different local grids as discussed in Tom's email.

> (3) Does implement mean “deploy” or “create mechanisms”.

<PPE> Actually, the intent was rather to say that the framework with
provide open interface for an id-loc to interact with it. These interfaces
should be defined and implemented.

> Shouldn’t you state that the working group will use solutions from other

<PPE> IMHO we should reuse what we can but at this point we need to refine
the requirements to find out how to use these existing solutions or whether
they should be tweaked.
This is covered here
<

*Where appropriate, the IDEAS WG will collaborate with other Working Groups
to ensure interoperability with LISP, HIP, ILA and other relevant work.*>

Thanks
Padma

---

From: "Liubingyang (Bryan)" <[email-masked]>
Date: Thu, 18 May 2017 07:52:50 +0000

I think that mapping from overlay to underlay is a good use case in virtualization environment. It can be l2 to l3, l3 to l3, or anything that is valuable in practice.

Btw, topology is a little vague, since it can be physical topology as well as virtual network topology.

Best
Bingyang (Bryan)
发件人： Padma Pillay-Esnault
收件人： Alexander Clemm<[email-masked]<mailto:[email-masked]>>
抄送： Tom Herbert<[email-masked]<mailto:[email-masked]>>;[email-masked]<mailto:[email-masked]>
主题： Re: [Ideas] Prep for BOF in July - Your input Needed on a Charter Proposal
时间： 2017-05-18 14:14:29

Hi Alex

Comments see <PPE>

On Wed, May 17, 2017 at 3:08 PM, Alexander Clemm <[email-masked]<mailto:[email-masked]>> wrote:
FWIW, two comments on various aspects raised in this thread, one by Bingyang, the other by Tom:

@ Alex If I understand you correctly ... Your concern is that today the located is based on IP and that guarantees some kind of uniqueness which we will rely on. However this may not be the case if we use another namespace.
However, if there is no uniqueness in the locator then I would assume this is broken as forwarding would not be deterministic.

@ Bingyang My understanding is that you wanted to generalize this for forwarding on L3 and L2.
Is this what you had in mind?

<PPE> Agree with Alex and Tom here. I do not think that all mappings need to be shared. I would even say that this should be a feature.

--- Alex

-----Original Message-----
From: Ideas [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Tom Herbert
Sent: Wednesday, May 17, 2017 8:25 AM
To: Padma Pillay-Esnault <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [Ideas] Prep for BOF in July - Your input Needed on a Charter Proposal

Tom

> [email-masked]<mailto:[email-masked]>

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

---

From: Alexander Clemm <[email-masked]>
Date: Thu, 18 May 2017 22:11:32 +0000

Reply on the first item regarding how much to generalize the mapping problem. I am not sure we should make it that general.  We can keep generality in mind without committing to it.  I would rather have us be specific about the fact that we address mappings between IDs (or “names”) and locators, and their lifecycles.  This scope is more focused than a system that allows to manage mappings between anything and anything.  If it turns out later that I can adopt the same mapping system also to map, say, customers, service orders, and delivery trucks, then all the better, but I would not want to have to consider such scenarios here.
--- Alex

From: Padma Pillay-Esnault [mailto:[email-masked]]
Sent: Wednesday, May 17, 2017 11:09 PM
To: Alexander Clemm <[email-masked]>
Cc: Tom Herbert <[email-masked]>; [email-masked]
Subject: Re: [Ideas] Prep for BOF in July - Your input Needed on a Charter Proposal

Hi Alex

Comments see <PPE>

--- Alex

-----Original Message-----
From: Ideas [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Tom Herbert
Sent: Wednesday, May 17, 2017 8:25 AM
To: Padma Pillay-Esnault <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [Ideas] Prep for BOF in July - Your input Needed on a Charter Proposal

Tom

---

From: <[email-masked]>
Date: Fri, 19 May 2017 07:09:21 +0000

Dear all,

Thanks to Padma for this proposal. A few comments inline from my side.

[snip]
Proposed Charter

The identifier-enabled solutions and applications are increasingly being considered to support mobility [CJ] scenarios across heterogeneous access networks. Likewise, Internet of Things and Machine to Machine (M2M)[CJ]  services, [CJ] as well as context aware applications[CJ]  can take advantage of identifier-enabled solutions. The enforcement of security[CJ]  policies (regardless of the nature of the service) can also benefit from IE features.  Due to the diverse nature of devices and applications, it may not be possible to deploy a single protocol end to end.
[CJ] Not sure I get the last part of the above sentence – did you mean a single identifier/location separation protocol? If so, I would elaborate and also briefly indicate this is because of likely different naming and addressing schemes, such as typical, often technology-specific, IoT services.
A common control plane will address siloes in discovery and communications.
[CJ] I don’t understand the above sentence. Did you mean: “A common control plane is required to facilitate the dynamic discovery of the various naming/addressing schemes and the communication between these heterogeneous environments”? If so, I guess I would rephrase.
Also, I think I would add a few words about negotiation capabilities that may take place between mapping systems operated by different entities.
  Moreover, a common control plane will [CJ] smooth the technical and operational hurdles to deployment and interoperability of [CJ] heterogeneous solutions.
[CJ] Not sure a common control plane is sufficient to address all the technical and operational hurdles hence the proposed rewording.

The working group will specify an overall architecture for  a common control plane and services for identity-enabled technology.  More specifically these services will include:
•      registration and lifecycle management of identities and associated identifiers
•      identifier binding to location(s),
•      support for grouping,
[CJ] Does grouping relate to the ability of facilitating communications within communities (of users/devices, whether they are in motion or not, and which use different naming schemes)? If so, I would elaborate and I also think this implies some negotiation capabilities (clearance to join a community, exchanging mapping information between different Mapping Systems).
•      definition and enforcement of policies
[CJ] I think we should be specific about what such policies look like – forwarding/routing, traffic engineering, security, QoS? A combination thereof?
•      support for metadata.
[CJ] You may want to elaborate on the usage of such metadata.
Additionally, the control plane interface and protocol extensions that allow clients to communicate[CJ] /negotiate with that infrastructure will be covered.

The abstraction provided by a secured identity will give a new level of control for confidentiality, accountability, security and access-control. The working group will cover these aspects and balance them with the minimized storage of data and privacy considerations.
[CJ] Not sure I understand the above two sentences. Did you mean: “The common control plane is meant to provide hard guarantees about identity information, among other features. Such guarantees will facilitate the design and the operation of secured, trustworthy, and robust communication services regardless of the underlying networked technologies and the various addressing/naming schemes they rely upon. The WG will take into account the need for such hard guarantees for the specification of the common control plane, while making sure an appropriate balance can be found between the amount of information that need to be maintained by the common control plane and the scalability/performance of the proposed approach.”?

Where appropriate, the IDEAS WG will collaborate with other Working Groups to ensure interoperability with LISP, HIP, ILA and other relevant work.
[CJ] I think the WG should also capitalize the effort conducted by the above WGs, besides interop considerations.

WG deliverables include:
Overall architecture

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 the record, I won’t be able to attend the next Prague IETF, but I’m willing to contribute. Also, I fully agree with Alex’s latest comment about the generalization of the mapping problem. The scope needs to be focused.
[CJ] Cheers,
Christian.

Milestones
TBD

_________________________________________________________________________________________________________________________

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: Damien Saucez <[email-masked]>
Date: Fri, 19 May 2017 10:22:50 +0200

> On 18 May 2017, at 09:52, Liubingyang (Bryan) <[email-masked]> wrote:
> 
> 收件人： Alexander Clemm<[email-masked]>
> 抄送： Tom Herbert<[email-masked]>;[email-masked]
>> On Wed, May 17, 2017 at 3:08 PM, Alexander Clemm <[email-masked]> wrote:
Hello,

I don't think we should aim at finding only a global mapping table but instead propose a method that allows to be either local (private) or global (public).  Also we should consider the case of migration from a local only to a global mapping. For example one start it's mapping in a DC then because of new usage of the DC then has to become public and global. The change of scope should be such that it does not require any change from the one changing. Maybe we will have to explicitly indicate the scope of the mappings such that it allows to provide policy based filtering of them (something as powerful as  BGP extended communities would be great). 

Also as it is likely that we will not have one solution fits all, therefore we have to consider the seamless merging of mapping systems. For example one may use a push approach while another may use a pull one. For that I guess that it will be useful to format the mapping information such that it can be carried as-is by all the flavors of the solutions we will propose or at least propose an automatic translation of the information. 

Thanks 

Damien Saucez

---

From: Albert Cabellos <[email-masked]>
Date: Fri, 19 May 2017 12:30:26 +0200

Hi

Please see my comments inline:

> regarding the scope of work and your interests.

Thanks for putting this together

> to implement a common control plane for identifier–location separation

I see some inconsistencies, here it is clear that the WG will work on
a 'control plane', while below it states 'the overall architecture'.
There are very little mentions to the database storing the information
(e.g, Mapping System).

>From the text I understand that mobility is central to IDEAS, I think
that mobility is a relevant function but ID-enabled solutions have
additional functions which are of interest for other use-cases.
> plane and services for identity-enabled technology.  More specifically these

control-plane is part of the overall architecture, we need to specify this.

> clients to communicate with that infrastructure will be covered.

Another interesting item is how to deal with the distribution of the ID-state:

- Assuming you are (logically) centralizing the ID state you may
want/need to push/pull the relevant state to the data-plane elements
to improve performance. On top of that and in some cases the state may
have relevance regionally (to a few clustered data-plane elements), in
this case you may want/need to push/pull this state to a regional
server for performance. This results in state consistency issues and a
solution needs to be standardized.

- The most common case is where the state is 'read' by the data-plane
elements from the Mapping System (either push or pull), but we have
found that 'writing' state from the data-plane elements to the Mapping
System (or whatever you may call it) is a key aspect of ID
architectures. A relevant example is the Map-Register message in LISP,
which does precisely this: write state. When the data-plane elements
are allowed to write state then you have to deal with state
consistency, race conditions, etc. A standard solution for this must
be produced.

> minimized storage of data and privacy considerations.

Security is a very broad word that pretty much includes
confidentiality, accountability, access-control, etc. We need to
narrow this or leave it wide open to then analyze which properties we
want.

In my view privacy is a very relevant one, particularly when you are
targeting mobility end-to-end, confidentiality seems harder to achieve
as a whole.

Albert

---

From: Padma Pillay-Esnault <[email-masked]>
Date: Fri, 19 May 2017 13:59:25 -0700

Hi  Albert and all

Thanks for your feedback and comments 

I will respin a new version with all the comments and feedback

Thanks
Padma 

Sent from my iPhone

> On May 19, 2017, at 03:30, Albert Cabellos <[email-masked]> wrote:
> 
> Hi
> 

Ok
> additional functions which are of interest for other use-cases.
Agree 
> control-plane is part of the overall architecture, we need to specify this.
Ok
> consistency, race conditions, etc. A standard solution for this must
Will come back on this agree mostly 
> targeting mobility end-to-end, confidentiality seems harder to achieve
Agree

---

From: Padma Pillay-Esnault <[email-masked]>
Date: Fri, 19 May 2017 14:12:13 -0700

Hi Christian 

Thanks for your review and feedback Will integrate some of this when I respin the new version and will clarify,

Thanks
Padma 

Sent from my iPhone

> On May 19, 2017, at 00:09, <[email-masked]> <[email-masked]> wrote:
> 
> Dear all,
>  
Will clarify 

Ok
> [CJ] Not sure I understand the above two sentences. Did you mean: “The common control plane is meant to provide hard guarantees about identity information, among other features. Such guarantees wil…
 will clarify 
> [CJ] I think the WG should also capitalize the effort conducted by the above WGs, besides interop considerations.
Sure
Ok

---

From: Padma Pillay-Esnault <[email-masked]>
Date: Fri, 19 May 2017 14:15:46 -0700

Hi Damien 

Thanks for your comments and feedback.  Will integrate some and clarify.

Thanks 
Padma 

Sent from my iPhone

> On May 19, 2017, at 01:22, Damien Saucez <[email-masked]> wrote:
> 
> 
> 
> I don't think we should aim at finding only a global mapping table but instead propose a method that allows to be either local (private) or global (public).

Yes we do have the local /private.. in mind
>  Also we should consider the case of migration from a local only to a global mapping. For example one start it's mapping in a DC then because of new usage of the DC then has to become public and global. The change of scope should be such that it does not require any change from the one changing. Maybe we will have to explicitly indicate the scope of the mappings such that it allows to provide policy based filtering of them (something as powerful as  BGP extended communities would be great). 
> 
Ok will try to integrate this

> Also as it is likely that we will not have one solution fits all, therefore we have to consider the seamless merging of mapping systems.

Agree
> For example one may use a push approach while another may use a pull one. For that I guess that it will be useful to format the mapping information such that it can be carried as-is by all the flavors of the solutions we will propose or at least propose an automatic translation of the information. 
> 
> Thanks 
> 
> Damien Saucez
> 
> 
>>> Tom
>>> 
>>> >
>>> >

---

From: Alexander Clemm <[email-masked]>
Date: Fri, 19 May 2017 22:25:33 +0000

Hi Damien

<snip>

@ Alex If I understand you correctly ... Your concern is that today the located is based on IP and that guarantees some kind of uniqueness which we will rely on. However this may not be the case if we use another namespace.
However, if there is no uniqueness in the locator then I would assume this is broken as forwarding would not be deterministic.
<https://www.ietf.org/mailman/listinfo/ideas>

I was concerned with the lifecycle of identifiers (where  we need to ensure identifiers identify an endpoint uniquely), not locators.  You are correct that in many coordinate systems locators need to be unique, but I am not sure if this is always going to be the case.  I am wondering, is there a requirement to ensure that the same locator cannot be “shared” / mapped to from two identifiers?

--- Alex

---

From: Uma Chunduri <[email-masked]>
Date: Tue, 23 May 2017 18:14:38 +0000

>Should the use case or relevance to 5G/3GPP be mentioned?

5G spec by 3G does need a common mapping system  where  part of the data (other than mapping info)  controlled by operator and mapping information in global database. 
This will not only provide mobility beyond 4G, but can potentially remove anchor based solutions and help ease deployment for non-3GPP/Hetnet access.
As there are no official liaison for all the requirements (do we have any??), else - IMO we should not put any specific language beyond generic use cases or specified more generally.

--
Uma C.

---

From: Uma Chunduri <[email-masked]>
Date: Tue, 23 May 2017 18:17:37 +0000

In-line [Uma]:

--
Uma C.

-----Original Message-----
From: Ideas [mailto:[email-masked]] On Behalf Of Tom Herbert
Sent: Wednesday, May 17, 2017 8:25 AM
To: Padma Pillay-Esnault <[email-masked]>
Cc: [email-masked]
Subject: Re: [Ideas] Prep for BOF in July - Your input Needed on a Charter Proposal

> policy control, and security aspects.
Like other mapping systems (routing, DNS) there will probably be a natural two level protocol hierarchy in the system. 1) The authoritative servers that synchronize the full mapping table for a domain and possibly shard it 2) A means for hosts to cache a subset of mappings without consulting the master for every use. Between the servers a protocol is needed with goal of synchronizing the distributed table. For the host cache protocol the goal is to manage the cache and keep it up to date as much a possible. 

[Uma]: Agree.

Cache management will break down to whether it's a pull or a push model. Pull techniques would be like address resolution (like ARP as a model), push would be re-directs, cache invalidation, etc. There are some significant differences in security between pull and push, pull being the easier one to make secure since requests can be validated using a nonce. Another thing that might be mentioned in charter is what intended scope is. Is the goal to have one public mapping table system (likeDNS) for the Internet with hierarchy that would allow sites to create their own mapping tables? Or would each site create there own tables and if they want to share mapping information with their partners they can do so by a private agreement? (personally I'd favor the second approach).

[Uma]: +1 

Tom

---

From: Uma Chunduri <[email-masked]>
Date: Tue, 23 May 2017 18:27:30 +0000

In-line [Uma]:
--
Uma C.

-----Original Message-----
From: Ideas [mailto:[email-masked]] On Behalf Of Declan Ma
Sent: Wednesday, May 17, 2017 9:05 AM
To: Padma Pillay-Esnault <[email-masked]>
Cc: [email-masked]
Subject: Re: [Ideas] Prep for BOF in July - Your input Needed on a Charter Proposal

Padma,

[Uma]: Mostly agree. 
              This is really an important aspect.  The fact of having any identity can bring in lot of value and much easier manageability.   This is essential,  if there is a possibility of having  multiple/different identifiers for the same entity.
               I don't quite see, we need to get entangled in Self-Certification or PKI (possibly this  stuff is needed).  But, what is critical is a notion of Identity authentication and subsequently secure access to the
                mapping system for not only updating mapping information but policy and other data.

Declan (Di) Ma

ZDNS

---

From: Padma Pillay-Esnault <[email-masked]>
Date: Tue, 23 May 2017 22:26:56 +0200

Hi Christian

I have some comments see below <PPE> while respiring the newer version

Thanks
Padma

On Fri, May 19, 2017 at 11:12 PM, Padma Pillay-Esnault <[email-masked]

> separation protocols. The identifier-enabled solutions and applications
> are increasingly being considered to support mobility *[CJ] *scenarios across
> heterogeneous access networks.
>
> Likewise, Internet of Things and Machine to Machine (M2M)*[CJ] * services,
> *[CJ] *as well as context aware applications*[CJ] * can take advantage of
> identifier-enabled solutions. The enforcement of security*[CJ] * policies
> (regardless of the nature of the service) can also benefit from IE features.
>
>
> <PPE> I do not think that we should be discussing enforcement of security
policies here.
The definition and enforcement of policies is actually mention in the
bulleted list below.

> Due to the diverse nature of devices and applications, it may not be
> possible to deploy a single protocol end to end.
>
> [CJ] Not sure I get the last part of the above sentence – did you mean a
> single identifier/location separation protocol? If so, I would elaborate
> and also briefly indicate this is because of likely different naming and
> addressing schemes, such as typical, often technology-specific, IoT
> services.
>
> <PPE> Ok I make some clarifications on this in the newer version

> [CJ] I don’t understand the above sentence. Did you mean: “A common
> control plane is required to facilitate the dynamic discovery of the
> various naming/addressing schemes and the communication between these
> heterogeneous environments”? If so, I guess I would rephrase.
>
> Also, I think I would add a few words about negotiation capabilities that
> may take place between mapping systems operated by different entities.
>
> <PPE> I do not think we should add about negotiation capabilities
specifically , this is covered as part of the control plane

>   Moreover, a common control plane will *[CJ] *smooth the technical and
> operational hurdles to deployment and interoperability of *[CJ] *heterogeneous
> solutions.
>
> [CJ] Not sure a common control plane is sufficient to address all the
> technical and operational hurdles hence the proposed rewording.
>
>
>
> <PPE> Agree. The original text intent was not to say that it was
addressing "all".

> [CJ] Does grouping relate to the ability of facilitating communications
> within communities (of users/devices, whether they are in motion or not,
> and which use different naming schemes)? If so, I would elaborate and I
> also think this implies some negotiation capabilities (clearance to join a
> community, exchanging mapping information between different Mapping
> Systems).
>
> <PPE> This was already discussed in the requirements document section
5.8.1
Would like to keep the charter as bulleted list here.

> [CJ] I think we should be specific about what such policies look like –
> forwarding/routing, traffic engineering, security, QoS? A combination
> thereof?
>
> ·      support for metadata.
>
> <PPE> Both of these are discussed in the requirement draft section 5.8.2,
5.8.3
If we have to add details would be best to do it there

> allow clients to communicate*[CJ] */negotiate with that infrastructure
> will be covered.
>
> <PPE> Why negotiate specifically? I think communicate covers negotiation
 and exchange of information

> [CJ] Not sure I understand the above two sentences. Did you mean: “The
> common control plane is meant to provide hard guarantees about identity
> information, among other features. Such guarantees will facilitate the
> design and the operation of secured, trustworthy, and robust communication
> services regardless of the underlying networked technologies and the
> various addressing/naming schemes they rely upon. The WG will take into
> account the need for such hard guarantees for the specification of the
> common control plane, while making sure an appropriate balance can be found
> between the amount of information that need to be maintained by the common
> control plane and the scalability/performance of the proposed approach.”?
>
>
>
>
> <PPE> What do you mean by hard guarantees? Here is the newer version which
also takes into account Tom's Comment

"The implementation of secured identities can address some concerns
regarding privacy, confidentiality, accountability, security and
access-control. The working group will cover these aspects and balance them
with the minimized storage of data and privacy considerations."

> [CJ] I think the WG should also capitalize the effort conducted by the
> above WGs, besides interop considerations.
>
> <PPE> Is that a given? The "relevant work" covers this aspect.

> For the record, I won’t be able to attend the next Prague IETF, but I’m
> willing to contribute. Also, I fully agree with Alex’s latest comment about
> the generalization of the mapping problem. The scope needs to be focused.
>
> [CJ] Cheers,
>
> Christian.
>
>
>
> Ok
>
>
>
> Milestones
>
> TBD
>

---

From: Padma Pillay-Esnault <[email-masked]>
Date: Tue, 23 May 2017 22:37:23 +0200

Hi Albert

See below <PPE> for some of my comments in the process of spinning the
newer version

Thanks
Padma

On Fri, May 19, 2017 at 10:59 PM, Padma Pillay-Esnault <[email-masked]

> input
> framework
> operational
> control
> allow

<PPE> We have proposed in the requirements document a Pub/Sub model.
Agree with you that the race conditions and propagation delay depends on
the model.

Propose to add a bullet after " identifier binding to location"
 ID leaking and distribution. BTW, this is  covered in the section 5.4 of
the req document.

---

From: Uma Chunduri <[email-masked]>
Date: Tue, 23 May 2017 22:07:37 +0000

<PPE> What do you mean by hard guarantees? Here is the newer version which also takes into account Tom's Comment

"The implementation of secured identities can address some concerns regarding privacy, confidentiality, accountability, security and access-control. The working group will cover these aspects and balance them with the minimized storage of data and privacy considerations."

[Uma]: I agree and I am not sure we can specify hard guarantees for the system  for  updates, resolutions or secure propagations  etc.
But I can sense from the comments from Christian, there could be  some hard requirements (5G mobility, M2M, vehicular transport, URLLC)  for some of the use cases, still IMO we should not specify hard guarantees.
This is because, things can vary based on the deployment model, implementation and scale.
Perhaps, architecture should allow a  deployment model where some the use case requirements can be met and some MIN-MAX ranges should be specified for some of the operations to allow implementation differentiation.

--
Uma C.

---

From: <[email-masked]>
Date: Wed, 24 May 2017 09:56:05 +0000

Hello Padma, all,

Thanks for your feedback – more inline.
[snip].
Likewise, Internet of Things and Machine to Machine (M2M)[CJ]  services, [CJ] as well as context aware applications[CJ]  can take advantage of identifier-enabled solutions. The enforcement of security[CJ]  policies (regardless of the nature of the service) can also benefit from IE features.
<PPE> I do not think that we should be discussing enforcement of security policies here.
The definition and enforcement of policies is actually mention in the bulleted list below.
[CJ] Maybe I was confused by the initial wording, but the original sentence mixes very different notions: IoT/M2M/context-aware (applications) on one side and then the word security pops up. And the bullet list only mentions policies with no further elaboration (enforcement is not mentioned for one). So, I would either suggest an elaboration or a rewording of the initial sentence, or the deletion of security, or the introduction of the set of policies that may be supported by the ideas architecture and which may serve the requirements of the aforementioned services/applications.

[CJ] [snip]
A common control plane will address siloes in discovery and communications.
[CJ] I don’t understand the above sentence. Did you mean: “A common control plane is required to facilitate the dynamic discovery of the various naming/addressing schemes and the communication between these heterogeneous environments”? If so, I guess I would rephrase.
Also, I think I would add a few words about negotiation capabilities that may take place between mapping systems operated by different entities.
<PPE> I do not think we should add about negotiation capabilities specifically , this is covered as part of the control plane
[CJ] Well, the word “negotiation” is not mentioned anywhere so far and I’m not convinced tat mentioning a control plane necessarily implies negotiation capabilities. As I’m not convinced there will be a single, global, pan-service, mapping system either, then the question of inter-MS negotiation capabilities (besides MS service discovery) comes naturally to mind. And I think this should be explicitly stated in the charter.
  Moreover, a common control plane will [CJ] smooth the technical and operational hurdles to deployment and interoperability of [CJ] heterogeneous solutions.
[CJ] Not sure a common control plane is sufficient to address all the technical and operational hurdles hence the proposed rewording.

<PPE> Agree. The original text intent was not to say that it was addressing "all".
[CJ] Right, but then again, the initial wording may suggest such claimed comprehensiveness.

•      support for grouping,
[CJ] Does grouping relate to the ability of facilitating communications within communities (of users/devices, whether they are in motion or not, and which use different naming schemes)? If so, I would elaborate and I also think this implies some negotiation capabilities (clearance to join a community, exchanging mapping information between different Mapping Systems).
<PPE> This was already discussed in the requirements document section 5.8.1
Would like to keep the charter as bulleted list here.
[CJ] I don’t understand the argument that seems to suggest the reading of the requirements document is a must to understand the charter.
•      definition and enforcement of policies
[CJ] I think we should be specific about what such policies look like – forwarding/routing, traffic engineering, security, QoS? A combination thereof?
•      support for metadata.
[CJ] You may want to elaborate on the usage of such metadata.
<PPE> Both of these are discussed in the requirement draft section 5.8.2, 5.8.3
If we have to add details would be best to do it there
[CJ] I understand a WG charter has to be concise, but I don’t think this should be at the cost of jeopardizing the understanding of what the WG is trying to address/achieve.

Ok

Additionally, the control plane interface and protocol extensions that allow clients to communicate[CJ] /negotiate with that infrastructure will be covered.
<PPE> Why negotiate specifically? I think communicate covers negotiation  and exchange of information
[CJ] I don’t think communication implies negotiation – see also one of my previous comments. Exchanging information is certainly not negotiation.

<PPE> What do you mean by hard guarantees?
[CJ] By hard guarantees, I meant trustworthy identity information.
Here is the newer version which also takes into account Tom's Comment

"The implementation of secured identities can address some concerns regarding privacy, confidentiality, accountability, security and access-control. The working group will cover these aspects and balance them with the minimized storage of data and privacy considerations."
[CJ] What aspects? The concerns mentioned in the first sentence? If so, mentioning “some concerns” reads a bit fuzzy to me. Again, I think the charter needs to be specific and in particular indicate clearly what will be covered and what will not.
Specifically, the IDEAS WG is chartered to work on these areas:

Where appropriate, the IDEAS WG will collaborate with other Working Groups to ensure interoperability with LISP, HIP, ILA and other relevant work.
[CJ] I think the WG should also capitalize the effort conducted by the above WGs, besides interop considerations.
<PPE> Is that a given? The "relevant work" covers this aspect.
[CJ] The sentence says collaborate, which does not imply capitalize afaic. What I meant is that ideas should not reinvent the wheel wherever there are already mechanisms/protocols/tools that can serve its purpose.

[CJ] Cheers,
Christian.

---

From: Padma Pillay-Esnault <[email-masked]>
Date: Fri, 26 May 2017 07:59:29 +0200

Hi Christian

Thanks for your response.
See <PPE1> for my responses.

In order to converge faster, I suggest that you send some proposals to the
text marked with *** and we discuss it on the list.

On Wed, May 24, 2017 at 11:56 AM,  <[email-masked]> wrote:

> Likewise, Internet of Things and Machine to Machine (M2M)*[CJ] * services
> , *[CJ] *as well as context aware applications*[CJ] * can take advantage
> of identifier-enabled solutions. The enforcement of security*[CJ]* policies
> [CJ] Maybe I was confused by the initial wording, but the original
> sentence mixes very different notions: IoT/M2M/context-aware (applications)
> on one side and then the word security pops up. And the bullet list only
> mentions policies with no further elaboration (enforcement is not mentioned
> for one). So, I would either suggest an elaboration or a rewording of the
> initial sentence, or the deletion of security, or the introduction of the
> set of policies that may be supported by the ideas architecture and which
> may serve the requirements of the aforementioned services/applications.
>

<PPE1> Clarified some of these aspects in newer version of charter which
incorporates the comments and feedback. Let's defer to then.

> *[CJ] *[snip]
> [CJ] Well, the word “negotiation” is not mentioned anywhere so far and I’m
> not convinced tat mentioning a control plane necessarily implies
> negotiation capabilities.
>

<PPE1> May be I should ask the question differently ... FWIW, I am not
convinced that the specific word negotiate need to be added in the charter.
To participate in a control plane you may or may not need to negotiate. See
more below

As I’m not convinced there will be a single, global, pan-service, mapping
> system either, then the question of inter-MS negotiation capabilities
> (besides MS service discovery) comes naturally to mind. And I think this
> should be explicitly stated in the charter.
>

<PPE1> Yes but as Tom had alluded this can also be done by agreement not
necessarily in the control plane either. I am not opposed to having
negotiation however  it should not be mandatory. Can you propose some text
here so that we can discuss it on the alias ?***

> operational hurdles to deployment and interoperability of *[CJ] *
> heterogeneous solutions.
>

<PPE1> ok sure.

> [CJ] I don’t understand the argument that seems to suggest the reading of
> the requirements document is a must to understand the charter.
>

<PPE1>  My argument is rather that the charter should not go into such
detail that it ends up excluding what is not written. The bulleted list is
just listing the work on a high level and is not excluding these aspects.
Understand your POV.

> [CJ] I understand a WG charter has to be concise, but I don’t think this
> should be at the cost of jeopardizing the understanding of what the WG is
> trying to address/achieve.
>
>
>

<PPE1> Yes this is where we are at odds. :-)

If we define here what the metadata will cover -  won't that be an issue of
putting everything else out of scope? Specifically,if we define opaque data
then this should not necessarily defined in the charter. Same for the
policies, are you advocating to put restrictions on the metadata and policy
usage and scope?

May be you should propose some wording here and then everyone can converge
on the list. ***

Ok
> [CJ] I don’t think communication implies negotiation – see also one of my
> previous comments. Exchanging information is certainly not negotiation.
>

<PPE1> Do you intend to introduce the notion of rejection of a
communication by negotiation? To be able to negotiate that implies you have
communication exchange and it is a processing of that communication
exchange. For backward interoperability, it would be best to not narrow
this. Will defer to opinion of the community.

> [CJ] By hard guarantees, I meant trustworthy identity information.

<PPE1>  "secured" identity implies that correct? IMHO, hard guarantees is
too vague a term.

> [CJ] What aspects? The concerns mentioned in the first sentence? If so,
> mentioning “some concerns” reads a bit fuzzy to me. Again, I think the
> charter needs to be specific and in particular indicate clearly what will
> be covered and what will not.
>

<PPE1> IMHO, we cannot imply that by having secured identities all concerns
are covered hence the "some". Perhaps best you make a proposal for this as
well so everyone can converge.****

Specifically, the IDEAS WG is chartered to work on these areas:
> [CJ] The sentence says collaborate, which does not imply capitalize afaic.
> What I meant is that ideas should not reinvent the wheel wherever there are
> already mechanisms/protocols/tools that can serve its purpose.
>
<PPE1> I see what you mean and this is not the intent. Would this work
better?

Where appropriate, the IDEAS WG will collaborate with other Working Groups
to ensure interoperability with LISP, HIP, ILA and other relevant work. The
WG will try to reuse technologies already developed when appropriate.

---

From: <[email-masked]>
Date: Mon, 29 May 2017 14:33:33 +0000

Hello Padma,

Thanks for the clarification. Please see inline wherever you suggest me to propose some wording (tentative, in red).

[snip]
As I’m not convinced there will be a single, global, pan-service, mapping system either, then the question of inter-MS negotiation capabilities (besides MS service discovery) comes naturally to mind. And I think this should be explicitly stated in the charter.

<PPE1> Yes but as Tom had alluded this can also be done by agreement not necessarily in the control plane either. I am not opposed to having negotiation however  it should not be mandatory. Can you propose some text here so that we can discuss it on the alias ?***
[CJ] A common control plane is required to facilitate the dynamic discovery of the various naming/addressing schemes and the communication between these heterogeneous environments. Such communication may also imply some negotiation capabilities, e.g., when several Mapping Systems are managed by different entities. A common control plane could thus facilitate such negotiation.

[CJ] [snip]

If we define here what the metadata will cover -  won't that be an issue of putting everything else out of scope?
[CJ] I think the wording can be flexible enough to leave room to (almost) everything else…Examples of such metadata in the charter text would certainly not hurt my feelings ☺
Specifically,if we define opaque data then this should not necessarily defined in the charter. Same for the policies, are you advocating to put restrictions on the metadata and policy usage and scope?
[CJ] No I’m not. But I encourage examples if not concise definitions.

May be you should propose some wording here and then everyone can converge on the list. ***
[CJ] Examples of such metadata include (but are not necessarily limited to) the description of the definition, the structure and the management of identity information. An example of such policies is (but is not necessarily limited to) the security policy enforced for the sake of the robustness of a Mapping System against DDoS attacks.

[CJ] [snip]

<PPE1> Do you intend to introduce the notion of rejection of a communication by negotiation?
[CJ] I indeed think this is a possible outcome of a negotiation: the inability to accommodate a request for retrieving a set of specific identity information maintained by a peering Mapping System, for example.
To be able to negotiate that implies you have communication exchange
[CJ] Of course.
and it is a processing of that communication exchange.
[CJ] Not sure what you mean by processing precisely, but the initialization of a negotiation (cycle) indeed assumes the establishment of a communication between the negotiating parties. And it seems to me this is a likely context at least in some IDN environments (those that support a variety of IoT services whose scope may span several regions of the network, for example).
For backward interoperability, it would be best to not narrow this. Will defer to opinion of the community.
[CJ] Fair enough, but I really don’t think this narrows the scope of the WG, on the contrary.

[snip]

<PPE1>  "secured" identity implies that correct? IMHO, hard guarantees is too vague a term.
[CJ] OK.

<PPE1> IMHO, we cannot imply that by having secured identities all concerns are covered hence the "some". Perhaps best you make a proposal for this as well so everyone can converge.****
[CJ] The implementation of secured identities can address concerns related to the preservation of privacy information, the protection of confidential information, as well as a basis to mitigate security threats that include (but are not limited to) DDoS and spoofing attacks as well as theft of identity credentials, for example.

<PPE1> I see what you mean and this is not the intent. Would this work better?

Where appropriate, the IDEAS WG will collaborate with other Working Groups to ensure interoperability with LISP, HIP, ILA and other relevant work. The WG will try to reuse technologies already developed when appropriate.
[CJ] Yes – thanks.

Cheers,

Christian.