Subject: [Modern] Third revision of MODERN charter

From: Steve Donovan <[email-masked]>
Date: Thu, 14 May 2015 13:35:24 -0500

All,

In an attempt to capture a snapshot of the discussion so far, I've 
included a proposed third revision of the MODERN charter.

This includes reference to RFC3966 for the definition of TNs (telephone 
numbers).  It also removes the reference to CNAM.  I have also added 
SCIM to the set of existing IETF work to be considered by the working group.

Regards,

Steve

-----

CHARTER TEXT:

The MODERN working group will define a set of Internet-based mechanisms 
for the purposes of managing and resolving telephone numbers (TNs) in an 
IP environment.  Existing mechanisms for these purposes face 
obsolescence as the voice communications infrastructure evolves to IP 
technology and new applications for TNs become possible.  The 
traditional model of a TN having an association to a single service 
provider and a single application is breaking down.  Its use as a 
network locator is going away, but its use as an identifier for an 
individual or an organization will remain for some time. Devices, 
applications, and network tools increasingly need to manage TNs, 
including requesting and acquiring TN delegations from authorities.  A 
sample of problems with existing mechanisms include:

- lack of flexibility (for example, it can be difficult to add fields 
without a very elaborate and lengthy process typically spanning years)
- lack of distribution (for example, it is hard or impossible to have 
more than one administrator for each database)
- complexity (leading, for example, to a fair amount of rural call 
completion problems which aren't helped by small providers struggling to 
keep numbers straight)
- difficulty of adopting more modern allocation (e.g., "blocks" of 1) 
and porting mechanisms

The working group will define an information management framework for 
the roles and functions involved in associating information with one or 
more TNs in an IP environment.  The working group will also define 
protocol mechanisms to support the interactions between the functions 
defined by the framework.  This includes either recommending or defining 
protocol mechanisms for acquiring, associating and resolving TNs.  The 
protocol mechanism for acquiring TNs will provide an enrollment process 
for the entities that use and manage TNs. TNs may either be managed in a 
hierarchical tree, or in a distributed peer-to-peer architecture. 
Privacy of the managed data and security of the resource will be primary 
considerations.  The protocol mechanism for resolving TNs will allow 
entities such as service providers, devices, and applications to access 
data related to TNs.  Maintaining reliability, real time application 
performance, security and privacy are primary considerations.  The 
working group will take into consideration existing IETF work including 
ENUM, SPEERMINT, DRINKS and SCIM.

The work of this group will focus on TNs, as defined in RFC3966, and 
blocks of TNs, that are used to initiate communication with another user 
of a service.  The work is motivated by the changing telecom environment 
and interest expressed by telecommunications industry regulators to 
support more flexible regulatory models than exist today.   There is an 
expectation that aspects of the architecture and protocols defined by 
the working group will be reusable for other user-focused identifiers.  
Any such extensions or reuse of MODERN mechanisms are out of scope for 
the MODERN working group. Solutions and mechanisms created by the 
working group will be flexible enough to accommodate different policies, 
e.g., by different regulatory agencies.

The work group will deliver the following:

-       An architecture overview, including high level requirements and 
security/privacy considerations

-       A description of the enrollment processes for existing and new 
TNs including any modifications to metadata related to those TNs

-       A description of protocol mechanisms for accessing contact 
information associated with enrollments

-       A description of mechanisms for resolving information related to 
TNs

---

From: Steve Donovan <[email-masked]>
Date: Thu, 14 May 2015 15:07:30 -0500

The newest revision to the charter can also be found here:

https://datatracker.ietf.org/doc/charter-ietf-modern/

Steve

On 5/14/15 1:35 PM, Steve Donovan wrote:
> This includes reference to RFC3966 for the definition of TNs 
> (telephone numbers).  It also removes the reference to CNAM.  I have 
> also added SCIM to the set of existing IETF work to be considered by 
> the working group.
>
> Regards,
>
> Steve
>
> -----
>
> CHARTER TEXT:
>
> The MODERN working group will define a set of Internet-based 
> mechanisms for the purposes of managing and resolving telephone 
> numbers (TNs) in an IP environment.  Existing mechanisms for these 
> purposes face obsolescence as the voice communications infrastructure 
> evolves to IP technology and new applications for TNs become 
> possible.  The traditional model of a TN having an association to a 
> single service provider and a single application is breaking down.  
> Its use as a network locator is going away, but its use as an 
> identifier for an individual or an organization will remain for some 
> time. Devices, applications, and network tools increasingly need to 
> manage TNs, including requesting and acquiring TN delegations from 
> authorities.  A sample of problems with existing mechanisms include:
>
> completion problems which aren't helped by small providers struggling 
> to keep numbers straight)
> the roles and functions involved in associating information with one 
> or more TNs in an IP environment.  The working group will also define 
> defined by the framework.  This includes either recommending or 
> defining protocol mechanisms for acquiring, associating and resolving 
> TNs.  The protocol mechanism for acquiring TNs will provide an 
> enrollment process for the entities that use and manage TNs. TNs may 
> either be managed in a hierarchical tree, or in a distributed 
> peer-to-peer architecture. Privacy of the managed data and security of 
> the resource will be primary considerations.  The protocol mechanism 
> for resolving TNs will allow entities such as service providers, 
> devices, and applications to access data related to TNs.  Maintaining 
> reliability, real time application performance, security and privacy 
> are primary considerations.  The working group will take into 
> consideration existing IETF work including ENUM, SPEERMINT, DRINKS and 
> SCIM.
>
> blocks of TNs, that are used to initiate communication with another 
> user of a service.  The work is motivated by the changing telecom 
> environment and interest expressed by telecommunications industry 
> regulators to support more flexible regulatory models than exist 
> today.   There is an expectation that aspects of the architecture and 
> protocols defined by the working group will be reusable for other 
> user-focused identifiers.  Any such extensions or reuse of MODERN 
> mechanisms are out of scope for the MODERN working group. Solutions 
> and mechanisms created by the working group will be flexible enough to 
> accommodate different policies, e.g., by different regulatory agencies.
>
> -       An architecture overview, including high level requirements 
> and security/privacy considerations
>
> -       A description of mechanisms for resolving information related 
> to TNs
>
> _______________________________________________
> Modern mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/modern
>

---

From: Eric Burger <[email-masked]>
Date: Mon, 18 May 2015 18:14:37 -0400

All of Henning’s slides were about number assignments in a hierarchy. My recollection is all of the use cases were about number assignments in a hierarchy. I am not against working on peer-to-peer assignment technology. However, I wanted to make sure this is something that people want to work on.

What is the use case? Sorry if I missed it. When I greped the archive, the term ‘peer’ does not hit, other than in the charter drafts.

> On May 14, 2015, at 2:35 PM, Steve Donovan <[email-masked]> wrote:
> 
>  TNs may either be managed in a hierarchical tree, or in a distributed peer-to-peer architecture.

---

From: Chris Wendt <[email-masked]>
Date: Mon, 18 May 2015 21:29:41 -0700

I think something like simply "Distributed Registry" might be a more straight forward term to stick to.  "Peer-to-peer" isn’t necessarily an inappropriate way to describe the gossip based distributed protocols Henning referred to in his presentation, but has some historical meaning that could potentially confuse or imply something other than what is being proposed or discussed. 

> On May 18, 2015, at 3:14 PM, Eric Burger <[email-masked]> wrote:
>

---

From: "McGarry, Tom" <[email-masked]>
Date: Tue, 19 May 2015 16:41:52 +0000

Good suggestion, much better.

On 5/19/15 12:29 AM, "Chris Wendt" <[email-masked]> wrote:

>I think something like simply "Distributed Registry" might be a more
>straight forward term to stick to.  "Peer-to-peer" isn¹t necessarily an
>inappropriate way to describe the gossip based distributed protocols
>Henning referred to in his presentation, but has some historical meaning
>that could potentially confuse or imply something other than what is
>being proposed or discussed.
>
>
>> All of Henning¹s slides were about number assignments in a hierarchy.
>>My recollection is all of the use cases were about number assignments in
>>a hierarchy. I am not against working on peer-to-peer assignment
>>technology. However, I wanted to make sure this is something that people
>>want to work on.
>> 
>> What is the use case? Sorry if I missed it. When I greped the archive,
>>the term Œpeer¹ does not hit, other than in the charter drafts.
>> 
>>https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman
>>_listinfo_modern&d=AwIGaQ&c=MOptNlVtIETeDALC_lULrw&r=4Klm32iB7HufveeIDcLe
>>xtZ1ooNcfp01IYIaVqsORjI&m=TrkvRaCRvLUvdy0uDgAMBmRFqQWTzHDG4MsbYRzcpZM&s=X
>>phhxgfqwBpQYESLydOdSGK4298XoheNyQ_oAfoskn4&e=
>
>https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_
>listinfo_modern&d=AwIGaQ&c=MOptNlVtIETeDALC_lULrw&r=4Klm32iB7HufveeIDcLext
>Z1ooNcfp01IYIaVqsORjI&m=TrkvRaCRvLUvdy0uDgAMBmRFqQWTzHDG4MsbYRzcpZM&s=Xphh
>xgfqwBpQYESLydOdSGK4298XoheNyQ_oAfoskn4&e=

---

From: Eric Burger <[email-masked]>
Date: Tue, 19 May 2015 14:26:03 -0400

I like it too. A distributed yet authoritative directory can be (but not necessarily) something distinguishable from a peer-to-peer DHT.

> On May 19, 2015, at 12:41 PM, McGarry, Tom <[email-masked]> wrote:
> 
>> straight forward term to stick to.  "Peer-to-peer" isnąt necessarily an
>>> All of Henningąs slides were about number assignments in a hierarchy.
>>> the term Śpeerą does not hit, other than in the charter drafts.
>>>

---

From: Steve Donovan <[email-masked]>
Date: Thu, 21 May 2015 13:13:17 -0500

Chris,

Was your suggestion to make the following change?

From:

" TNs may either be managed in a hierarchical tree, or in a distributed 
peer-to-peer architecture. "

To:

"TNs may either be managed in a hierarchical tree, or in a distributed 
registry."

Steve

---

From: Chris Wendt <[email-masked]>
Date: Tue, 26 May 2015 10:26:47 -0400

Yes, would be interested in other perspectives, but Eric in his response said “peer-to-peer assignment technology”.  Maybe it’s a subtle difference and a minor point, but the general term "peer-to-peer" has some implied techniques that i don’t think are being proposed here.

Distributed i think captures things a bit better in the context of a multi-node distributed datastore, as is fairly commonly implemented in many popular open solutions.

> On May 21, 2015, at 2:13 PM, Steve Donovan <[email-masked]> wrote:
> 
> Chris,
> 
> " TNs may either be managed in a hierarchical tree, or in a distributed peer-to-peer architecture. "
> 
> To:
> 
> "TNs may either be managed in a hierarchical tree, or in a distributed registry."
> 
> Steve
> 
>> On 5/19/15 12:29 AM, "Chris Wendt" <[email-masked]> <mailto:[email-masked]> wrote:
>> 
>>>> On May 18, 2015, at 3:14 PM, Eric Burger <[email-masked]> <mailto:[email-masked]>
>>>> wrote:
>>>> 
>>>>> On May 14, 2015, at 2:35 PM, Steve Donovan <[email-masked]> <mailto:[email-masked]>
>>>>> wrote:
>>>>> 
>>>> [email-masked] <mailto:[email-masked]>
>>>> 
>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman>
>>> [email-masked] <mailto:[email-masked]>
>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_ <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_>
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/modern <https://www.ietf.org/mailman/listinfo/modern>
>> 
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/modern <https://www.ietf.org/mailman/listinfo/modern>