Subject: [Modern] MODERN will solve no problems (or will the IETF take over the world?)

From: Steve Donovan <[email-masked]>
Date: Fri, 01 May 2015 16:23:54 -0500

The question of what problem(s) MODERN will address has been asked, 
multiple times.

The short answer is that, in an of itself, MODERN will solve no problems.

This isn't to say there aren't problems with existing mechanisms. It is 
to say that all MODERN can do is to specify protocols that can then be 
part of an overall solution that addresses problems that exist with 
those existing mechanisms.

There is a brief capture of these problems in the latest version of the 
charter:

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

Will MODERN solve these problems? No.

Will MODERN make it possible for these problems to be addressed as part 
of new number management policies to be enacted by the appropriate 
authorities?  That, I believe, is the goal.

Will MODERN force any of these new number management policies to be 
enacted.  No.  The IETF is not a policy setting body.

I'm ok with having a more detailed articulation of the problem statement 
as part of the deliverables of the MODERN working group. I don't see the 
benefit of making that the only deliverable and forcing rechartering 
after that document is finished.  Let's instead agree to shut the 
working group down if there is consensus that it is going nowhere (which 
I'm sure the ADs will do anyway).

Regards,

Steve

---

From: "Gorman, Pierce A [CTO]" <[email-masked]>
Date: Mon, 4 May 2015 16:32:46 +0000

If we can agree we eliminate the charter language that implies creating a framework which supplants the authority of the NANC (at least) and which assumes a replacement of the NPAC and LERG databases, we will have made progress (IMHO).

Beyond striking objectionable language, the reason for David Holmes' posts following mine last week was to try to improve the focus of the work for MODERN.  We do think it is a bad idea to ignore that number administration and routing solutions need to evolve.  And we're not against the MODERN working group identifying problems.  In fact we're in favor of it.  Its what to do past that where we're struggling.

The thing I'm concerned about is a repeat of the e164.arpa fiasco which succeeded in defining a global schema and protocol for managing numbers and resolving them for routing and which failed utterly.

Best regards,

Pierce Gorman
Core Network Planning
O: 913-439-4368  M: 816-210-8623
[email-masked]

-----Original Message-----
From: Modern [mailto:[email-masked]] On Behalf Of Steve Donovan
Sent: May 01, 2015 4:24 PM
To: [email-masked]
Subject: [Modern] MODERN will solve no problems (or will the IETF take over the world?)

The question of what problem(s) MODERN will address has been asked, multiple times.

This isn't to say there aren't problems with existing mechanisms. It is to say that all MODERN can do is to specify protocols that can then be part of an overall solution that addresses problems that exist with those existing mechanisms.

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

Will MODERN make it possible for these problems to be addressed as part of new number management policies to be enacted by the appropriate authorities?  That, I believe, is the goal.

Will MODERN force any of these new number management policies to be enacted.  No.  The IETF is not a policy setting body.

I'm ok with having a more detailed articulation of the problem statement as part of the deliverables of the MODERN working group. I don't see the benefit of making that the only deliverable and forcing rechartering after that document is finished.  Let's instead agree to shut the working group down if there is consensus that it is going nowhere (which I'm sure the ADs will do anyway).

Regards,

Steve

_______________________________________________
Modern mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/modern

________________________________

This e-mail may contain Sprint proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message.

---

From: Richard Shockey <[email-masked]>
Date: Mon, 04 May 2015 13:50:59 -0400

Well said. 

There were two issues here. First is E.164 number allocation, management
and administration vs the second is a query response mechanism for data
retrivial surrounding phone numbers specifically routing and session
establishment data [SED] query & retrieval.

The first issue is the generally the problem. The FCC workshop clearly
identified two options. Given time frames surrounding the PSTN Transition
we had to find mechanisms to use the existing databases and tools to get
the job done. That work, as you correctly point out, was the focus of the
ATIS/SIP Forum JV and NNI TF. We are done with Phase 1 and this week will
start to look at what Phase 2 looks like. The balloting is done. We did
not reach consensus on a single method for session routing but we
documented enough so that service providers can begin to automate a
process that was becoming unmanageable using bi-lateral exchange of
spreadsheets. There are a bunch of decisions that now have to be made on
how to implement those Recommendations.  Those decisions will have to
occur within the NANC and INC very quickly.

http://www.sipforum.org/content/view/427/171/

There was some general agreement at the workshop that the existing number
management system could use a fresh review but there was consensus that
the time frames for accomplishing that were ³indeterminate² at best. As
anyone who knows this space can tell you the numbering
registrant-registrar-registry construct is ultimately national policy but
the real cost structure is in the OSS/BSS systems. Any service provider
will testify that modifying those systems takes a lot of zeros behind lots
of dollars. Dollars that service providers are loathe to spend.   This is
not a North American centric problem.  This is interesting work but as
Brother Burger points out, beyond North America who is going to buy the
product? Believe me the UK DE IT and FR could use it but OFCOM for example
has enough to worry about right now and their industry consultation
process is just as convoluted as the ones in the US and CA.

Second was the larger issue of the query response mechanism.  On that
there has been nearly universal consensus.  ENUM sort of sucks. I should
know. You all know my background here and I can assure you that knowing
what I know now I would have not supported using DNS for what became RFC
6116, but at the time it was the best and most logical choice.  DNS is not
a Œmodern¹ protocol (pun intended) by any stretch of the imagination but
it has proven to be a pretty good TCAP replacement in widespread
deployment.  We all know the problems, lack of authentication, security,
lack of determinate response..the list is rather long.

e164.arpa was a total failure as a number management scheme but rethinking
the query response mechanism along the lines of TERQ could be useful and
deployable. Its also useful to remind ourselves that DRINKS was
essentially a failure.

https://tools.ietf.org/wg/drinks/charters

‹ 
Richard Shockey
Shockey Consulting LLC
Chairman of the Board SIP Forum
www.shockey.us
www.sipforum.org
richard<at>shockey.us
Skype-Linkedin-Facebook rshockey101
PSTN +1 703-593-2683

On 5/4/15, 12:32 PM, "Gorman, Pierce A [CTO]" <[email-masked]>
wrote:

>If we can agree we eliminate the charter language that implies creating a
>framework which supplants the authority of the NANC (at least) and which
>assumes a replacement of the NPAC and LERG databases, we will have made
>progress (IMHO).
>
>Beyond striking objectionable language, the reason for David Holmes'
>posts following mine last week was to try to improve the focus of the
>work for MODERN.  We do think it is a bad idea to ignore that number
>administration and routing solutions need to evolve.  And we're not
>against the MODERN working group identifying problems.  In fact we're in
>favor of it.  Its what to do past that where we're struggling.
>
>The thing I'm concerned about is a repeat of the e164.arpa fiasco which
>succeeded in defining a global schema and protocol for managing numbers
>and resolving them for routing and which failed utterly.
>
>Best regards,
>
>
>Pierce Gorman
>Core Network Planning
>part of an overall solution that addresses problems that exist with those
>existing mechanisms.
>
>after that document is finished.  Let's instead agree to shut the working
>group down if there is consensus that it is going nowhere (which I'm sure
>the ADs will do anyway).
>
>Regards,
>
>Steve
>
>This e-mail may contain Sprint proprietary information intended for the
>sole use of the recipient(s). Any use by others is prohibited. If you are
>not the intended recipient, please contact the sender and delete all
>copies of the message.
>

---

From: Steve Donovan <[email-masked]>
Date: Mon, 04 May 2015 13:29:33 -0500

Pierce,

See my comments inline.

Regards,

Steve

> If we can agree we eliminate the charter language that implies creating a framework which supplants the authority of the NANC (at least) and which assumes a replacement of the NPAC and LERG databas…
SRD> This should be easy to do, as there is no intent and, even if there 
were intent, there is no ability for the MODERN group to take anyone's 
authority or replace anyone's database.

SRD> Is the problem with the word framework in the second paragraph?  
Would calling it an "architectural framework" help?
> Beyond striking objectionable language, the reason for David Holmes' posts following mine last week was to try to improve the focus of the work for MODERN.  We do think it is a bad idea to ignore t…
SRD> I share the desire to focus the work.  I think the revisions of the 
charter have moved in this direction.
> The thing I'm concerned about is a repeat of the e164.arpa fiasco which succeeded in defining a global schema and protocol for managing numbers and resolving them for routing and which failed utter…
SRD> We fail if we don't learn from our mistakes.  I'm confident we will 
have enough involvement in the group to keep us pointed in the right 
direction.

---

From: "Gorman, Pierce A [CTO]" <[email-masked]>
Date: Mon, 4 May 2015 20:53:25 +0000

Thanks Steve.  I don't think wordsmithing "framework" to be "architectural framework" in the 2nd paragraph really addresses the underlying concern.

I understand the temptation to jump right in and have MODERN develop a newer, better, solution to the existing (North American?) framework architecture but it feels like a bridge too far.  I'd suggest striking the 2nd paragraph entirely, but I suspect that is also as unappealing to you as the paragraph is to me.

I liked Eric Burger's suggestions regarding fleshing out problems by describing use cases.

One use case that occurs to me that might lead in the direction I think you're interested in is I've not seen sufficient description of how to associate "services" with telephone numbers.  For example, many people are members of more than one social networking application, and some social network applications offer services which overlap with traditional telecommunications and therefore could benefit from assocation with number_user telephone numbers.

I think it would be useful to explore how those services could be defined syntactically, managed, and discovered.  But maybe that's just me.  Maybe others find that useless and/or objectionable.  It does seem like the direction you were wanting things to go in terms of giving number_users control over service provider associations with their telephone number.  And it seems directionally correct in terms of addressing the interests of users and non-traditional communications service providers for service provider mash-ups associated with a telephone number.

I know I haven't directly answered your question about specific suggested changes to the text in the charter.  I would like to hear more from others.

Best regards,

Pierce Gorman
Core Network Planning
O: 913-439-4368
[email-masked]

-----Original Message-----
From: Modern [mailto:[email-masked]] On Behalf Of Steve Donovan
Sent: May 04, 2015 1:30 PM
To: [email-masked]
Subject: Re: [Modern] MODERN will solve no problems (or will the IETF take over the world?)

Pierce,

See my comments inline.

Regards,

Steve

SRD> This should be easy to do, as there is no intent and, even if there
were intent, there is no ability for the MODERN group to take anyone's authority or replace anyone's database.

SRD> We fail if we don't learn from our mistakes.  I'm confident we will
have enough involvement in the group to keep us pointed in the right direction.
> O: 913-439-4368
> completion problems which aren't helped by small providers struggling
> to keep numbers straight)

---

From: "McGarry, Tom" <[email-masked]>
Date: Tue, 5 May 2015 14:54:07 +0000

"Š define a framework for the roles and functions involved in managing and
resolving TNs Š" is a necessary step to create a common understanding, for
a WG, of the ecosystem for managing TNs.

For example the WG could define a communications service user, a
communications service provider, a numbering authority, a numbering
administrator, etc.; describe the functions of these roles and how they
may interact with each other.  Both presentations at the BoF did a good
job of starting this discussion.

As the charter states, the work done by the WG would be flexible enough to
accommodate different administrative models, therefore the framework,
roles and functions would need to be flexible.  There is no intent to
create a single administrative model, and there is no text in the charter
that would suggest otherwise.  In fact the charter states this explicitly.
 If there are text changes you could suggest that makes this clearer for
you and others, please do.

On 5/4/15 4:53 PM, "Gorman, Pierce A [CTO]" <[email-masked]>
wrote:

>Thanks Steve.  I don't think wordsmithing "framework" to be
>"architectural framework" in the 2nd paragraph really addresses the
>underlying concern.
>
>I understand the temptation to jump right in and have MODERN develop a
>newer, better, solution to the existing (North American?) framework
>architecture but it feels like a bridge too far.  I'd suggest striking
>the 2nd paragraph entirely, but I suspect that is also as unappealing to
>you as the paragraph is to me.
>
>One use case that occurs to me that might lead in the direction I think
>you're interested in is I've not seen sufficient description of how to
>associate "services" with telephone numbers.  For example, many people
>are members of more than one social networking application, and some
>social network applications offer services which overlap with traditional
>telecommunications and therefore could benefit from assocation with
>number_user telephone numbers.
>
>I think it would be useful to explore how those services could be defined
>syntactically, managed, and discovered.  But maybe that's just me.  Maybe
>others find that useless and/or objectionable.  It does seem like the
>direction you were wanting things to go in terms of giving number_users
>control over service provider associations with their telephone number.
>And it seems directionally correct in terms of addressing the interests
>of users and non-traditional communications service providers for service
>provider mash-ups associated with a telephone number.
>
>I know I haven't directly answered your question about specific suggested
>changes to the text in the charter.  I would like to hear more from
>others.
>
>Best regards,
>
>
>Pierce Gorman
>Core Network Planning
>O: 913-439-4368
>[email-masked]
>
>
>> If we can agree we eliminate the charter language that implies creating
>>a framework which supplants the authority of the NANC (at least) and
>>which assumes a replacement of the NPAC and LERG databases, we will have
>>made progress (IMHO).
>> I'm ok with having a more detailed articulation of the problem
>>statement as part of the deliverables of the MODERN working group. I
>>don't see the benefit of making that the only deliverable and forcing
>>rechartering after that document is finished.  Let's instead agree to
>>shut the working group down if there is consensus that it is going
>>nowhere (which I'm sure the ADs will do anyway).
>>
>> Regards,
>>
>> Steve
>>
>>https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman
>>_listinfo_modern&d=AwICAg&c=MOptNlVtIETeDALC_lULrw&r=4Klm32iB7HufveeIDcLe
>>xtZ1ooNcfp01IYIaVqsORjI&m=O7TZ4YM6BoXXyDhVxT8j5VG46X6WlVqvtIBx-xTDf7w&s=h
>>tIM_QeOI3fHOZSEUNnH-3DYxiYMREbp5P8RPhTjGqw&e=
>>
>>sole use of the recipient(s). Any use by others is prohibited. If you
>>are not the intended recipient, please contact the sender and delete all
>>copies of the message.
>>
>>https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman
>>_listinfo_modern&d=AwICAg&c=MOptNlVtIETeDALC_lULrw&r=4Klm32iB7HufveeIDcLe
>>xtZ1ooNcfp01IYIaVqsORjI&m=O7TZ4YM6BoXXyDhVxT8j5VG46X6WlVqvtIBx-xTDf7w&s=h
>>tIM_QeOI3fHOZSEUNnH-3DYxiYMREbp5P8RPhTjGqw&e=
>>
>
>https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_
>listinfo_modern&d=AwICAg&c=MOptNlVtIETeDALC_lULrw&r=4Klm32iB7HufveeIDcLext
>Z1ooNcfp01IYIaVqsORjI&m=O7TZ4YM6BoXXyDhVxT8j5VG46X6WlVqvtIBx-xTDf7w&s=htIM
>_QeOI3fHOZSEUNnH-3DYxiYMREbp5P8RPhTjGqw&e=
>
>https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_
>listinfo_modern&d=AwICAg&c=MOptNlVtIETeDALC_lULrw&r=4Klm32iB7HufveeIDcLext
>Z1ooNcfp01IYIaVqsORjI&m=O7TZ4YM6BoXXyDhVxT8j5VG46X6WlVqvtIBx-xTDf7w&s=htIM
>_QeOI3fHOZSEUNnH-3DYxiYMREbp5P8RPhTjGqw&e=

---

From: "Gorman, Pierce A [CTO]" <[email-masked]>
Date: Tue, 5 May 2015 15:06:42 +0000

Thanks Tom.  As I said, my suggestion would be to strike the paragraph 2 text.

Best regards,

Pierce Gorman
Core Network Planning
O: 913-439-4368
[email-masked]

-----Original Message-----
From: McGarry, Tom [mailto:[email-masked]]
Sent: May 05, 2015 9:54 AM
To: Gorman, Pierce A [CTO]; Steve Donovan; [email-masked]
Subject: Re: [Modern] MODERN will solve no problems (or will the IETF take over the world?)

"Š define a framework for the roles and functions involved in managing and resolving TNs Š" is a necessary step to create a common understanding, for a WG, of the ecosystem for managing TNs.

For example the WG could define a communications service user, a communications service provider, a numbering authority, a numbering administrator, etc.; describe the functions of these roles and how they may interact with each other.  Both presentations at the BoF did a good job of starting this discussion.

As the charter states, the work done by the WG would be flexible enough to accommodate different administrative models, therefore the framework, roles and functions would need to be flexible.  There is no intent to create a single administrative model, and there is no text in the charter that would suggest otherwise.  In fact the charter states this explicitly.
 If there are text changes you could suggest that makes this clearer for you and others, please do.

On 5/4/15 4:53 PM, "Gorman, Pierce A [CTO]" <[email-masked]>
wrote:

>the 2nd paragraph entirely, but I suspect that is also as unappealing
>to you as the paragraph is to me.
>
>social network applications offer services which overlap with
>traditional telecommunications and therefore could benefit from
>assocation with number_user telephone numbers.
>
>I think it would be useful to explore how those services could be
>defined syntactically, managed, and discovered.  But maybe that's just
>me.  Maybe others find that useless and/or objectionable.  It does seem
>like the direction you were wanting things to go in terms of giving
>number_users control over service provider associations with their telephone number.
>of users and non-traditional communications service providers for
>service provider mash-ups associated with a telephone number.
>
>I know I haven't directly answered your question about specific
>suggested changes to the text in the charter.  I would like to hear
>more from others.
>
>Best regards,
>
>
>Pierce Gorman
>Core Network Planning
>O: 913-439-4368
>[email-masked]
>
>
>> If we can agree we eliminate the charter language that implies
>>creating a framework which supplants the authority of the NANC (at
>>least) and which assumes a replacement of the NPAC and LERG databases,
>>we will have made progress (IMHO).
>SRD> This should be easy to do, as there is no intent and, even if
>SRD> there
>>against the MODERN working group identifying problems.  In fact we're
>>in favor of it.  Its what to do past that where we're struggling.
>SRD> I share the desire to focus the work.  I think the revisions of
>SRD> the
>> The thing I'm concerned about is a repeat of the e164.arpa fiasco
>>which succeeded in defining a global schema and protocol for managing
>>numbers and resolving them for routing and which failed utterly.
>SRD> We fail if we don't learn from our mistakes.  I'm confident we
>SRD> will
>> This isn't to say there aren't problems with existing mechanisms. It
>>is to say that all MODERN can do is to specify protocols that can then
>>be part of an overall solution that addresses problems that exist with
>> Will MODERN make it possible for these problems to be addressed as
>>part of new number management policies to be enacted by the
>>appropriate authorities?  That, I believe, is the goal.
>>
>>xtZ1ooNcfp01IYIaVqsORjI&m=O7TZ4YM6BoXXyDhVxT8j5VG46X6WlVqvtIBx-xTDf7w&
>>s=h tIM_QeOI3fHOZSEUNnH-3DYxiYMREbp5P8RPhTjGqw&e=
>>
>> This e-mail may contain Sprint proprietary information intended for
>>the sole use of the recipient(s). Any use by others is prohibited. If
>>you are not the intended recipient, please contact the sender and
>>delete all copies of the message.
>>
>>xtZ1ooNcfp01IYIaVqsORjI&m=O7TZ4YM6BoXXyDhVxT8j5VG46X6WlVqvtIBx-xTDf7w&
>>s=h tIM_QeOI3fHOZSEUNnH-3DYxiYMREbp5P8RPhTjGqw&e=
>>
>
>Z1ooNcfp01IYIaVqsORjI&m=O7TZ4YM6BoXXyDhVxT8j5VG46X6WlVqvtIBx-xTDf7w&s=h
>tIM _QeOI3fHOZSEUNnH-3DYxiYMREbp5P8RPhTjGqw&e=
>
>are not the intended recipient, please contact the sender and delete
>all copies of the message.
>
>Z1ooNcfp01IYIaVqsORjI&m=O7TZ4YM6BoXXyDhVxT8j5VG46X6WlVqvtIBx-xTDf7w&s=h
>tIM _QeOI3fHOZSEUNnH-3DYxiYMREbp5P8RPhTjGqw&e=

---

From: "Gorman, Pierce A [CTO]" <[email-masked]>
Date: Fri, 8 May 2015 17:58:41 +0000

Steve,

Here is a suggested set of changes to the 2nd paragraph.

OLD:

The working group will define a framework for the roles and functions involved in managing and resolving TNs in an IP environment. This includes a protocol mechanism for acquiring TNs, which will provide an enrollment process for the individuals and 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 enrollment data and security of the resource will be primary considerations.

NEW:

The working group will define a an information management framework for the roles and functions involved in managing and resolving TNs associating SERVICE, SERVICE_PROVIDER, and NUMBER_USER information with one or more TNs in an IP environment. This includes a protocol mechanism for acquiring TNs, which will provide an enrollment process for the individuals and 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 enrollment managed data and security of the resource will be primary considerations.

I would prefer if others weighed in here.  I don't like being one of a few with such influence.

Because I wasn't at the BoF and am new at this sort of thing, I personally would be happier if we took more time in e-mail or meetings to discuss the problems the WG should address, not the solutions (at first).

A specific area of concern for me is the data model of information associated with telephone numbers.   I care much more about what is being provisioned then I do about how it is provisioned or shared.

I think trying to identify the what first will be more valuable than the how, and certainly more important than the who.

Best regards,

Pierce Gorman

Core Network Planning

O: 913-439-4368

[email-masked]

-----Original Message-----

To: Gorman, Pierce A [CTO]; Steve Donovan; [email-masked]<mailto:[email-masked]>

On 5/4/15 4:53 PM, "Gorman, Pierce A [CTO]" <[email-masked]<mailto:[email-masked]>>

>I liked Eric Burger's suggestions regarding fleshing out problems by

>describing use cases.

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

>From: Modern [mailto:[email-masked]] On Behalf Of Steve

>Donovan

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

>Subject: Re: [Modern] MODERN will solve no problems (or will the IETF

>take over the world?)

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

>> From: Modern [mailto:[email-masked]] On Behalf Of Steve

>> Donovan

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

>> Subject: [Modern] MODERN will solve no problems (or will the IETF

>> take over the world?)

>> The short answer is that, in an of itself, MODERN will solve no

>>problems.

>> There is a brief capture of these problems in the latest version of

>> the

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

>>https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail

>>man

>>_listinfo_modern&d=AwICAg&c=MOptNlVtIETeDALC_lULrw&r=4Klm32iB7HufveeID

>>cLe

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

>>https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail

>>man

>>_listinfo_modern&d=AwICAg&c=MOptNlVtIETeDALC_lULrw&r=4Klm32iB7HufveeID

>>cLe

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

>https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailm

>an_

>listinfo_modern&d=AwICAg&c=MOptNlVtIETeDALC_lULrw&r=4Klm32iB7HufveeIDcL

>ext

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

>https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailm

>an_

>listinfo_modern&d=AwICAg&c=MOptNlVtIETeDALC_lULrw&r=4Klm32iB7HufveeIDcL

>ext

Modern mailing list

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

---

From: Steve Donovan <[email-masked]>
Date: Tue, 12 May 2015 14:17:51 -0500

Pierce,

See my comments inline.

Steve

On 5/8/15 12:58 PM, Gorman, Pierce A [CTO] wrote:
>
> Steve,
>
> Here is a suggested set of changes to the 2^nd paragraph.
>
> OLD:
>
> The working group will define a framework for the roles and functions 
> involved in managing and resolving TNs in an IP environment. This 
> includes a protocol mechanism for acquiring TNs, which will provide an 
> enrollment process for the individuals and 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 enrollment data 
> and security of the resource will be primary considerations.
>
> NEW:
>
> The working group will define a an information management framework 
> for the roles and functions involved in managing and resolving TNs 
> associating SERVICE, SERVICE_PROVIDER, and NUMBER_USER information 
> with one or more TNs in an IP environment. This includes a protocol 
> mechanism for acquiring TNs, which will provide an enrollment process 
> for the individuals and 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 enrollment managed data and 
> security of the resource will be primary considerations.
>
SRD> I'm mostly okay with your changes other then removing the wording 
on the protocol work.  I believe there is enough support for doing the 
protocol work that this should remain in the charter. I'm not sure we 
need to define the concepts of SERVICE, SERVICE_PROVIDER and 
NUMBER_USER, as the framework might come up with different terms and/or 
roles.
>
> I would prefer if others weighed in here.  I don’t like being one of a 
> few with such influence.
>
SRD> Agreed.
>
> Because I wasn’t at the BoF and am new at this sort of thing, I 
> personally would be happier if we took more time in e-mail or meetings 
> to discuss the problems the WG should address, not the solutions (at 
> first).
>
SRD> Yes we need more discussion.  That is what the working group is 
for.  The charter is to define the scope of the working group effort.  
We don't need to have all of the answers now.
>
> A specific area of concern for me is the data model of information 
> associated with telephone numbers.  I care much more about what is 
> being provisioned then I do about how it is provisioned or shared.
>
SRD> I actually don't think it is the job of the MODERN working group to 
define detailed data models.  We clearly need to have some assumptions 
about what those data models might look like, but I would assume that 
each number management authority would determine what data is associated 
with a number.

SRD> I also think the how is important as the resulting mechanism, be it 
a new one defined by the group or an existing one recommended by the 
group, will need to be flexible and extensible to be able to address the 
problems outlined by Henning.
>
> I think trying to identify the what first will be more valuable than 
> the how, and certainly more important than the who.
>
SRD> Agreed and the proposed deliverables are in the order listed for 
that very reason.
> <mailto:[email-masked]>
> "Š define a framework for the roles and functions involved in managing 
> and resolving TNs Š" is a necessary step to create a common 
> understanding, for a WG, of the ecosystem for managing TNs.
>
> administrator, etc.; describe the functions of these roles and how 
> they may interact with each other.  Both presentations at the BoF did 
> a good job of starting this discussion.
>
> As the charter states, the work done by the WG would be flexible 
> enough to accommodate different administrative models, therefore the 
> framework, roles and functions would need to be flexible.  There is no 
> intent to create a single administrative model, and there is no text 
> in the charter that would suggest otherwise.  In fact the charter 
> states this explicitly.
>
> >[email-masked] <mailto:[email-masked]>
>
> >
>
> >
>
> >To: [email-masked] <mailto:[email-masked]>
>
> >> [email-masked] <mailto:[email-masked]>
>
> >>
>
> >>
>
> >> To: [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]>
>
> [email-masked] <mailto:[email-masked]>
>
> ------------------------------------------------------------------------
>

---

From: "Gorman, Pierce A [CTO]" <[email-masked]>
Date: Tue, 12 May 2015 22:10:45 +0000

Thanks Steve.

“SRD>   …I'm not sure we need to define the concepts of SERVICE, SERVICE_PROVIDER and NUMBER_USER, as the framework might come up with different terms and/or roles.”

I’m not sure how you want to word this and I’m not married to what I suggested.  I was implying information in a data model.  I picked those three fields because I thought they are fundamentally what has been described to associate with one or more telephone numbers (assuming we can agree what a TN is).

How about we remove any reference to what information is being associated with telephone numbers like this…

NEW-ER #0:

“SRD> I'm mostly okay with your changes other then removing the wording on the protocol work.  I believe there is enough support for doing the protocol work that this should remain in the charter.”

Well, if there’s enough support you can ignore me.  ☺  The heartburn I have with leaving the protocol work in there is I’m not convinced new protocol mechanisms are needed.

Even if it was inarguable that new protocol mechanisms are needed, won’t this still point back to your point about, “each number management authority would determine what data is associated with a number”?

Today those number management authorities also determine the protocol mechanisms for enrolling (i.e., assigning) and managing telephone numbers.  What reason is there to believe they will spontaneously adopt what MODERN developed?  This is starting to feel like TRIP2.0.

I think the number management authorities have to respect users and communications service providers want to create associations of new non-traditional kinds of information with one or more telephone numbers.

I don’t think that necessarily implies they also have to respect any suggested protocol mechanisms for managing the information assocations.  And the number management authorities would necessarily be facing that conversation at some point, will they not?

“SRD> We clearly need to have some assumptions about what those data models might look like, but…”

Agreed.  I suggest developing a starter data model based on a set of legacy requirements and requirements not being met by the current data set would be useful.  I think defining an easily extensible data model is critical.

I’m not very interested in discussing YAPP (Yet Another Provisioning Protocol), but very interested to discuss association of new non-traditional services and their identifiers and parameters with telephone numbers.

Best regards,

Pierce Gorman
Core Network Planning
O: 913-439-4368
[email-masked]

From: Steve Donovan [mailto:[email-masked]]
Sent: May 12, 2015 2:18 PM
To: Gorman, Pierce A [CTO]; McGarry, Tom; [email-masked]
Subject: Re: [Modern] MODERN will solve no problems (or will the IETF take over the world?)

Pierce,

See my comments inline.

Steve

OLD:

NEW:

SRD> I'm mostly okay with your changes other then removing the wording on the protocol work.  I believe there is enough support for doing the protocol work that this should remain in the charter.   I'm not sure we need to define the concepts of SERVICE, SERVICE_PROVIDER and NUMBER_USER, as the framework might come up with different terms and/or roles.

I would prefer if others weighed in here.  I don’t like being one of a few with such influence.

SRD> Agreed.

Because I wasn’t at the BoF and am new at this sort of thing, I personally would be happier if we took more time in e-mail or meetings to discuss the problems the WG should address, not the solutions (at first).
SRD> Yes we need more discussion.  That is what the working group is for.  The charter is to define the scope of the working group effort.  We don't need to have all of the answers now.

A specific area of concern for me is the data model of information associated with telephone numbers.   I care much more about what is being provisioned then I do about how it is provisioned or shared.
SRD> I actually don't think it is the job of the MODERN working group to define detailed data models.  We clearly need to have some assumptions about what those data models might look like, but I would assume that each number management authority would determine what data is associated with a number.

SRD> I also think the how is important as the resulting mechanism, be it a new one defined by the group or an existing one recommended by the group, will need to be flexible and extensible to be able to address the problems outlined by Henning.

I think trying to identify the what first will be more valuable than the how, and certainly more important than the who.
SRD> Agreed and the proposed deliverables are in the order listed for that very reason.

Best regards,

Pierce Gorman

Core Network Planning

O: 913-439-4368

-----Original Message-----

Modern mailing list

---

From: Steve Donovan <[email-masked]>
Date: Wed, 13 May 2015 09:11:12 -0500

Pierce,

Protocol work doesn't necessarily mean new protocols will be developed.  
It could also result in a recommendation to use or build on  existing 
protocols.

To your question: "Today those number management authorities also 
determine the protocol mechanisms for enrolling (i.e., assigning) and 
managing telephone numbers.  What reason is there to believe they will 
spontaneously adopt what MODERN developed?"

Nothing happens spontaneously but if we do our work well then we give 
the authorities another option, one that addresses the shortcomings in 
the existing mechanisms.

To your point: "I’m not very interested in discussing YAPP (Yet Another 
Provisioning Protocol), but very interested to discuss association of 
new non-traditional services and their identifiers and parameters with 
telephone numbers."

If we end up creating a new set of protocols, hopefully it will be ABPP 
(A Better Provisioning Protocol) :-).  I believe the latter part of your 
statement is one of the motivators for the proposed working group.

I propose the following, which keeps the protocol work.

Old (from the "revised revised" email):

The working group will define a framework for the roles and functions 
involved in managing and resolving TNs in an IP environment.  It will 
also define protocol mechanisms for acquiring and resolving TNs.  The 
protocol mechanism for acquiring TNs will provide an enrollment process 
for the individuals and 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 enrollment 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, possibly including 
caller name data (CNAM).  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, and DRINKS.

New:

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 individuals and 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, possibly including caller 
name data (CNAM).  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, and DRINKS.

Regards,

Steve

On 5/12/15 5:10 PM, Gorman, Pierce A [CTO] wrote:
>
> Thanks Steve.
>
> “SRD>   …I'm not sure we need to define the concepts of SERVICE, 
> SERVICE_PROVIDER and NUMBER_USER, as the framework might come up with 
> different terms and/or roles.”
>
> I’m not sure how you want to word this and I’m not married to what I 
> suggested.  I was implying information in a data model.  I picked 
> those three fields because I thought they are fundamentally what has 
> been described to associate with one or more telephone numbers 
> (assuming we can agree what a TN is).
>
> How about we remove any reference to what information is being 
> associated with telephone numbers like this…
>
> NEW-ER #0:
>
> associating SERVICE, SERVICE_PROVIDER, and NUMBER_USERinformation with 
> one or more TNs in an IP environment. This includes a protocol 
> “SRD> I'm mostly okay with your changes other then removing the 
> wording on the protocol work.  I believe there is enough support for 
> doing the protocol work that this should remain in the charter.”
>
> Well, if there’s enough support you can ignore me. J  The heartburn I 
> have with leaving the protocol work in there is I’m not convinced new 
> protocol mechanisms are needed.
>
> Even if it was inarguable that new protocol mechanisms are needed, 
> won’t this still point back to your point about, “each number 
> management authority would determine what data is associated with a 
> number”?
>
> Today those number management authorities also determine the protocol 
> mechanisms for enrolling (i.e., assigning) and managing telephone 
> numbers.  What reason is there to believe they will spontaneously 
> adopt what MODERN developed?  This is starting to feel like TRIP2.0.
>
> I think the number management authorities have to respect users and 
> communications service providers want to create associations of new 
> non-traditional kinds of information with one or more telephone numbers.
>
> I don’t think that necessarily implies they also have to respect any 
> suggested protocol mechanisms for managing the information 
> assocations.  And the number management authorities would necessarily 
> be facing that conversation at some point, will they not?
>
> Agreed. I suggest developing a starter data model based on a set of 
> legacy requirements and requirements not being met by the current data 
> set would be useful.  I think defining an easily extensible data model 
> is critical.
>
> I’m not very interested in discussing YAPP (Yet Another Provisioning 
> Protocol), but very interested to discuss association of new 
> non-traditional services and their identifiers and parameters with 
> telephone numbers.
>
> Best regards,
>
> *Pierce Gorman*
>
> Core Network Planning
>
> O: 913-439-4368
>
> [email-masked]
>
>
> *From:*Steve Donovan [mailto:[email-masked]]
> *Sent:* May 12, 2015 2:18 PM
> *To:* Gorman, Pierce A [CTO]; McGarry, Tom; [email-masked]
> *Subject:* Re: [Modern] MODERN will solve no problems (or will the 
> IETF take over the world?)
>
> Pierce,
>
> See my comments inline.
>
> Steve
>
>     The working group will define a framework for the roles and
>     functions involved in managing and resolving TNs in an IP
>     environment. This includes a protocol mechanism for acquiring TNs,
>     which will provide an enrollment process for the individuals and
>     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 enrollment data and security of the resource will
>     be primary considerations.
>
>     NEW:
>
>     The working group will define a an information management
>     framework for the roles and functions involved in managing and
>     resolving TNs associating SERVICE, SERVICE_PROVIDER, and
>     NUMBER_USER information with one or more TNs in an IP environment.
>     This includes a protocol mechanism for acquiring TNs, which will
>     provide an enrollment process for the individuals and 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 enrollment managed data and security of the
>     resource will be primary considerations.
>
> protocol work that this should remain in the charter.   I'm not sure 
> we need to define the concepts of SERVICE, SERVICE_PROVIDER and 
> NUMBER_USER, as the framework might come up with different terms 
> and/or roles.
>
>     personally would be happier if we took more time in e-mail or
>     meetings to discuss the problems the WG should address, not the
>     solutions (at first).
>
>     associated with telephone numbers.   I care much more about what
>     is being provisioned then I do about how it is provisioned or shared.
>
> SRD> I actually don't think it is the job of the MODERN working group 
> to define detailed data models.  We clearly need to have some 
> assumptions about what those data models might look like, but I would 
> assume that each number management authority would determine what data 
> is associated with a number.
>
> SRD> I also think the how is important as the resulting mechanism, be 
> it a new one defined by the group or an existing one recommended by 
> the group, will need to be flexible and extensible to be able to 
> address the problems outlined by Henning.
>
>     I think trying to identify the what first will be more valuable
>     than the how, and certainly more important than the who.
>
>     "Š define a framework for the roles and functions involved in
>     managing and resolving TNs Š" is a necessary step to create a
>     common understanding, for a WG, of the ecosystem for managing TNs.
>
>     communications service provider, a numbering authority, a
>     numbering administrator, etc.; describe the functions of these
>     roles and how they may interact with each other.  Both
>     presentations at the BoF did a good job of starting this discussion.
>
>     enough to accommodate different administrative models, therefore
>     the framework, roles and functions would need to be flexible. 
>     There is no intent to create a single administrative model, and
>     there is no text in the charter that would suggest otherwise.  In
>     fact the charter states this explicitly.
>
>     On 5/4/15 4:53 PM, "Gorman, Pierce A [CTO]"
>     <[email-masked] <mailto:[email-masked]>>
>
>     wrote:
>
>     This e-mail may contain Sprint proprietary information intended
>     for the sole use of the recipient(s). Any use by others is
>     prohibited. If you are not the intended recipient, please contact
>     the sender and delete all copies of the message.
>
>     This e-mail may contain Sprint proprietary information intended
>     for the sole use of the recipient(s). Any use by others is
>     prohibited. If you are not the intended recipient, please contact
>     the sender and delete all copies of the message.
>
>

---

From: Richard Shockey <[email-masked]>
Date: Wed, 13 May 2015 11:15:04 -0400

From:  Steve Donovan <[email-masked]>
Date:  Wednesday, May 13, 2015 at 10:11 AM
To:  <[email-masked]>
Subject:  Re: [Modern] MODERN will solve no problems (or will the IETF take
over the world?)

  Pierce,
 
 Protocol work doesn't necessarily mean new protocols will be developed.  It
could also result in a recommendation to use or build on  existing
protocols. [Been there done that]

RS> That is a profile. The IETF doesn't do profiles or at least it doesn't
do profiles very well.

 To your question: "Today those number management authorities also determine
the protocol mechanisms for enrolling (i.e., assigning) and managing
telephone numbers.  What reason is there to believe they will spontaneously
adopt what MODERN developed?"
 
 Nothing happens spontaneously but if we do our work well then we give the
authorities another option, one that addresses the shortcomings in the
existing mechanisms.
 
 To your point: "I'm not very interested in discussing YAPP (Yet Another
Provisioning Protocol), but very interested to discuss association of new
non-traditional services and their identifiers and parameters with telephone
numbers."
 
 If we end up creating a new set of protocols, hopefully it will be ABPP (A
Better Provisioning Protocol) :-).  I believe the latter part of your
statement is one of the motivators for the proposed working group.

RS>  Rat hole alert.  The IETF does not have a good record here as well. You
can make the case that the entire IETF PROVREG construct for the domain name
industry was a failure since it ended up being finely tailored to the
requirements of ICANN and not a general purpose provisioning protocol.

 
 The working group will define a framework for the roles and functions
involved in managing and resolving TNs in an IP environment.  It will also
define protocol mechanisms for acquiring and resolving TNs.  The protocol
mechanism for acquiring TNs will provide an enrollment process for the
individuals and 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 enrollment 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, possibly including caller name data (CNAM).

RS> Please take this out the CNAM issue. This is different on multiple
levels. Don't mention CNAM at all.

  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, and DRINKS.
 
 New:
 
 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
individuals and entities that use and manage TNs.

RS> Please on't say anyhting about individuals that is a policy issue.
Entities ..what ever they are.

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, possibly including caller name
data (CNAM).  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, and
DRINKS. 
 
 Regards,
 
 Steve

On 5/12/15 5:10 PM, Gorman, Pierce A [CTO] wrote:

>      
>  
> 
> Thanks Steve.
>  
>  
>  
> "SRD>   ...I'm not sure we need to define the concepts of SERVICE,
> different terms and/or roles."
>  
>  
>  
> I'm not sure how you want to word this and I'm not married to what I
> suggested.  I was implying information in a data model.  I picked those three
> fields because I thought they are fundamentally what has been described to
> associate with one or more telephone numbers (assuming we can agree what a TN
> is).
>  
>  
>  
> How about we remove any reference to what information is being associated with
> telephone numbers like this...
>  
>  
>  
> NEW-ER #0:
>  
>  
>  
> The working group will define a an information management framework for the
> roles and functions involved in managing and resolving TNs  associating
> SERVICE, SERVICE_PROVIDER, and NUMBER_USER information with one or more TNs in
> an IP environment. This includes a protocol mechanism for acquiring TNs, which
> will provide an enrollment process for the individuals and 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 enrollment managed data
> "SRD> I'm mostly okay with your changes other then removing the wording on the
> protocol work.  I believe there is enough support for doing the protocol work
> that this should remain in the charter."
>  
>  
>  
> Well, if there's enough support you can ignore me.  J  The heartburn I have
> with leaving the protocol work in there is I'm not convinced new protocol
> mechanisms are needed.
>  
>  
>  
> Even if it was inarguable that new protocol mechanisms are needed, won't this
> still point back to your point about, "each number management authority would
> determine what data is associated with a number"?
>  
>  
>  
> mechanisms for enrolling (i.e., assigning) and managing telephone numbers.
> What reason is there to believe they will spontaneously adopt what MODERN
> developed?  This is starting to feel like TRIP2.0.
>  
>  
>  
> I don't think that necessarily implies they also have to respect any suggested
> protocol mechanisms for managing the information assocations.  And the number
> management authorities would necessarily be facing that conversation at some
> point, will they not?
>  
>  
>  
> "SRD> We clearly need to have some assumptions about what those data models
> might look like, but..."
>  
>  
>  
> Agreed.  I suggest developing a starter data model based on a set of legacy
> requirements and requirements not being met by the current data set would be
> useful.  I think defining an easily extensible data model is critical.
>  
>  
>  
> I'm not very interested in discussing YAPP (Yet Another Provisioning
> Protocol), but very interested to discuss association of new non-traditional
> services and their identifiers and parameters with telephone numbers.
>  
>  
>  
>  
> 
> Best regards,
>  
>  
>  
>  
>  
> Pierce Gorman
>  
> Core Network Planning
>  
> O: 913-439-4368
>  
> [email-masked]
>  
>  
>  
>  
>  
>  
>  
> 
>> involved in managing and resolving TNs in an IP environment. This includes a
>> protocol mechanism for acquiring TNs, which will provide an enrollment
>> process for the individuals and 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 enrollment data and security of the resource
>> will be primary considerations.
>>  
>>  
>>  
>> NEW:
>>  
>>  
>>  
>> The working group will define a an information management framework for the
>> roles and functions involved in managing and resolving TNs  associating
>> SERVICE, SERVICE_PROVIDER, and NUMBER_USER information with one or more TNs
>> in an IP environment. This includes a protocol mechanism for acquiring TNs,
>> which will provide an enrollment process for the individuals and 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 enrollment
>> managed data and security of the resource will be primary considerations.
>>  
>>  
>>  
>  
> SRD> I'm mostly okay with your changes other then removing the wording on the
> protocol work.  I believe there is enough support for doing the protocol work
> that this should remain in the charter.   I'm not sure we need to define the
> concepts of SERVICE, SERVICE_PROVIDER and NUMBER_USER, as the framework might
> come up with different terms and/or roles.
>  
>  
>  
>>  
>> Because I wasn't at the BoF and am new at this sort of thing, I personally
>> would be happier if we took more time in e-mail or meetings to discuss the
>> problems the WG should address, not the solutions (at first).
>>  
>  
> SRD> Yes we need more discussion.  That is what the working group is for.  The
> charter is to define the scope of the working group effort.  We don't need to
> have all of the answers now.
>  
>  
>  
>>  
>>  
>>  
>> A specific area of concern for me is the data model of information associated
>> with telephone numbers.   I care much more about what is being provisioned
>> then I do about how it is provisioned or shared.
>>  
>  
> define detailed data models.  We clearly need to have some assumptions about
> what those data models might look like, but I would assume that each number
> management authority would determine what data is associated with a number.
>  
>  SRD> I also think the how is important as the resulting mechanism, be it a
> new one defined by the group or an existing one recommended by the group, will
> need to be flexible and extensible to be able to address the problems outlined
> by Henning. 
>  
>>  
>> I think trying to identify the what first will be more valuable than the how,
>> and certainly more important than the who.
>>  
>  
>> From: McGarry, Tom [mailto:[email-masked]
>> <mailto:[email-masked]> ]
>>  
>> resolving TNs Š" is a necessary step to create a common understanding, for a
>> WG, of the ecosystem for managing TNs.
>>  
>>  
>>  
>> administrator, etc.; describe the functions of these roles and how they may
>> interact with each other.  Both presentations at the BoF did a good job of
>> starting this discussion.
>>  
>>  
>>  
>> accommodate different administrative models, therefore the framework, roles
>> and functions would need to be flexible.  There is no intent to create a
>> single administrative model, and there is no text in the charter that would
>> suggest otherwise.  In fact the charter states this explicitly.
>>  
>> On 5/4/15 4:53 PM, "Gorman, Pierce A [CTO]" <[email-masked]
>> <mailto:[email-masked]> >
>>  
>> wrote:
>>  
>>  
>>  
>>> >From: Modern [mailto:[email-masked]
>>> <mailto:[email-masked]> ] On Behalf Of Steve
>>  
>>> >Donovan
>>  
>>>> >> From: Modern [mailto:[email-masked]
>>>> <mailto:[email-masked]> ] On Behalf Of Steve
>>  
>>>> >> Donovan
>>  
>>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail>
>>  
>>>> >>man
>>  
>>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail>
>>  
>>>> >>man
>>  
>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailm>
>>  
>>> >an_
>>  
>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailm>
>>  
>>> >an_
>>  
>> This e-mail may contain Sprint proprietary information intended for the sole
>> use of the recipient(s). Any use by others is prohibited. If you are not the
>> intended recipient, please contact the sender and delete all copies of the
>> message.
>>  
>>  
>>  
>> <https://www.ietf.org/mailman/listinfo/modern>
>>  
>>  
>>  
>>  
>> 
>>  
>>  
>> 
>> 
>>  This e-mail may contain Sprint proprietary information intended for the sole
>> use of the recipient(s). Any use by others is prohibited. If you are not the
>> intended recipient, please contact the sender and delete all copies of the
>> message.
>>  
>  
>  
>  
>  
>  
> 
>  
>  This e-mail may contain Sprint proprietary information intended for the sole
> use of the recipient(s). Any use by others is prohibited. If you are not the
> intended recipient, please contact the sender and delete all copies of the
> message.
>   
>   
>  
> [email-masked]://www.ietf.org/mailman/listinfo/modern
>  

_______________________________________________ Modern mailing list
[email-masked] https://www.ietf.org/mailman/listinfo/modern