Subject: [Modern] Proposed change to paragraph three of the charter

From: Steve Donovan <[email-masked]>
Date: Thu, 07 May 2015 08:50:49 -0500

All,

Paragraph three currently reads as follows:

"The work of this group will focus on E.164 telephone numbers due to 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."

I propose changing the first sentence to the following:

"The work of this group will focus on TNs -- such as E.164 numbers -- 
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. "

The remainder of the paragraph, starting with "There is an 
expectation..." would remain unchanged.

This adds some clarity on the scope of telephony identifiers covered as 
well as making it clear that blocks of TNs are also covered.

Regards,

Steve

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Mon, 11 May 2015 22:32:13 +0000

I do not agree with the charter being widened to "TN" or presumably "telephone numbers". The reason for this is that telephone numbers has a wide and undefined scope, possibly including alphabetic characters as well (as in the letters on the dialling ring).

Based on the statements made by others in terms of what needs to be covered, I would prefer a more precise definition of: "international E.164 numbers, local special purpose numbers, and network specific numbers" using the explanation of these terms that can be found in ITU-T Recommendation E.164.

Keith

> -----Original Message-----
> From: Modern [mailto:[email-masked]] On Behalf Of 
> Steve Donovan
> Sent: 07 May 2015 14:51
> To: [email-masked]
> Subject: [Modern] Proposed change to paragraph three of the charter
> 
> All,
> 
> "The work of this group will focus on E.164 telephone numbers 
> due to 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 of this group will focus on TNs -- such as E.164 
> numbers -- 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. "
> 
> This adds some clarity on the scope of telephony identifiers 
> covered as well as making it clear that blocks of TNs are 
> also covered.
> 
> Regards,
> 
> Steve
> 
> _______________________________________________
> Modern mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/modern
>

---

From: "Peterson, Jon" <[email-masked]>
Date: Tue, 12 May 2015 15:16:56 +0000

Again, I'd be more sympathetic to this request to invent a new IETF
definition of telephone numbers if we didn't already have standards track
RFCs that have done that, and by reference to the same specifications
you're describing here.

We don't mean anything different by telephone numbers than the abstract of
RFC3966 did when it said that "the 'tel' URI describes resources
identified by telephone numbers."

Jon Peterson
Neustar, Inc.

On 5/11/15, 3:32 PM, "DRAGE, Keith (Keith)"
<[email-masked]> wrote:

>I do not agree with the charter being widened to "TN" or presumably
>"telephone numbers". The reason for this is that telephone numbers has a
>wide and undefined scope, possibly including alphabetic characters as
>well (as in the letters on the dialling ring).
>
>Based on the statements made by others in terms of what needs to be
>covered, I would prefer a more precise definition of: "international
>E.164 numbers, local special purpose numbers, and network specific
>numbers" using the explanation of these terms that can be found in ITU-T
>Recommendation E.164.
>
>Keith
>

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Tue, 12 May 2015 15:31:55 +0000

I am not doing that at all.

I am proposing to remove any attempt by you and others to use the term "telephone number" in a totally undefined manner, and replacing it with terms that have been defined by the body that knows about these things, i.e. SG2 of ITU-T.

You are consisting opposing telling us what you mean by the team.

My proposal is not to include the term "telephone number" at all.

Regards

Keith 

> Peterson, Jon
> Sent: 12 May 2015 16:17
> To: DRAGE, Keith (Keith); Steve Donovan; [email-masked]
> Subject: Re: [Modern] Proposed change to paragraph three of 
> the charter
> 
> 
> Again, I'd be more sympathetic to this request to invent a 
> new IETF definition of telephone numbers if we didn't already 
> have standards track RFCs that have done that, and by 
> reference to the same specifications you're describing here.
> 
> RFC3966 did when it said that "the 'tel' URI describes 
> resources identified by telephone numbers."
> 
> Jon Peterson
> Neustar, Inc.
> 
> >"telephone numbers". The reason for this is that telephone 
> numbers has 
> >a wide and undefined scope, possibly including alphabetic 
> characters as 
> >numbers" using the explanation of these terms that can be found in 
> >ITU-T Recommendation E.164.
> >
> >Keith
> >
> >> From: Modern [mailto:[email-masked]] On Behalf Of Steve 
> >> Donovan
> >> Sent: 07 May 2015 14:51
> >> To: [email-masked]
> >> "The work of this group will focus on E.164 telephone 
> numbers due to 
> >> the changing telecom environment and interest expressed by 
> >> regulatory models than exist today.
> >> 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."
> >> 
> numbers -- 
> >> 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. "
> >> 
> >> This adds some clarity on the scope of telephony 
> identifiers covered 
> >> as well as making it clear that blocks of TNs are also covered.
> >> 
> >> Regards,
> >> 
> >> Steve
> >>

---

From: "Peterson, Jon" <[email-masked]>
Date: Tue, 12 May 2015 16:37:08 +0000

No, what I've said consistently is that what I mean by the term is what
RFC3966 meant by the term. TeRQ deferred to that specification for its
formal definition of telephone number, say. I see no reason to reinvent
that wheel.

If we get to a place where the term "telephone number" is imprecise or
toxic, then I think we've confused ourselves into a rejection of common
sense and common usage. The term is used without warning labels in IETF
standards track specifications already. The bar you are raising is not
consistent with IETF usage.

I do gather that you believe the expertise to do the MODERN work resides
in SG-2 rather than in the IETF. But the proposed working group will not,
say, reassign country code +44 to someone else, or do any of the things
you'd need the expertise and authority of that body to do. We're not
delegating authority for country codes to Internet entities as ENUM did,
which necessitated an IAB liaison with SG-2, even. Those are all policy
issues. We're not trying to build policy, we're trying to build tools that
will work in a variety of policy environments.

Jon Peterson
Neustar, Inc.

On 5/12/15, 8:31 AM, "DRAGE, Keith (Keith)"
<[email-masked]> wrote:

>I am proposing to remove any attempt by you and others to use the term
>"telephone number" in a totally undefined manner, and replacing it with
>terms that have been defined by the body that knows about these things,
>i.e. SG2 of ITU-T.
>

---

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

Would it solve the problem by referring directly to RFC3966 in the charter?

Steve

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Tue, 12 May 2015 17:07:23 +0000

Firstly the charter gives no definition of what you are using for telephone number, e.g. by reference to RFC 3966.

RFC 3966 basically defines it as any sequence of decimal digits. Other usages elsewhere include alphabetic characters, because this name is used both in the context of what the user represents to other users as his number and what actually gets used in a signalling protocol. 

The ITU-T terms actually distinguish between those two usages, by putting them in separate recommendations.

The additionally problem with RFC 3966 as a definition as it does not define a usage where every sequence of digits is unique, and therefore it has to add a phone context to enable that uniqueness to exist, with a default applying to "global" numbers.

So do you intend such digit sequences used within this group to be unique or will it need a phone context as a result of using the RFC 3966 definition? The definitions I provided would not.

In regard to:

> I do gather that you believe the expertise to do the MODERN 
> work resides in SG-2 rather than in the IETF. But the 
> proposed working group will not, say, reassign country code 
> +44 to someone else, or do any of the things you'd need the 
> expertise and authority of that body to do. We're not 
> delegating authority for country codes to Internet entities 
> as ENUM did, which necessitated an IAB liaison with SG-2, 
> even. Those are all policy issues. We're not trying to build 
> policy, we're trying to build tools that will work in a 
> variety of policy environments.

Then I do not believe that. I believe SG2 should define what the numbers are that we use, and maybe they should define the use cases. Once it is reduced to fulfilling a protocol requirement, then I anyone (including IETF) can do the work.

Regards

Keith 

> From: Peterson, Jon [mailto:[email-masked]] 
> Sent: 12 May 2015 17:37
> RFC3966 meant by the term. TeRQ deferred to that 
> specification for its formal definition of telephone number, 
> say. I see no reason to reinvent that wheel.
> 
> If we get to a place where the term "telephone number" is 
> imprecise or toxic, then I think we've confused ourselves 
> into a rejection of common sense and common usage. The term 
> is used without warning labels in IETF standards track 
> specifications already. The bar you are raising is not 
> I do gather that you believe the expertise to do the MODERN 
> work resides in SG-2 rather than in the IETF. But the 
> proposed working group will not, say, reassign country code 
> +44 to someone else, or do any of the things you'd need the 
> expertise and authority of that body to do. We're not 
> delegating authority for country codes to Internet entities 
> as ENUM did, which necessitated an IAB liaison with SG-2, 
> even. Those are all policy issues. We're not trying to build 
> policy, we're trying to build tools that will work in a 
> variety of policy environments.
> 
> Jon Peterson
> Neustar, Inc.
> 
> Peterson, 
> >> Jon
> >> Subject: Re: [Modern] Proposed change to paragraph three of the 
> >> charter
> >> 
> >> 
> new IETF 
> >> definition of telephone numbers if we didn't already have 
> standards 
> >> track RFCs that have done that, and by reference to the same 
> >> specifications you're describing here.
> >>

---

From: Steve Donovan <[email-masked]>
Date: Thu, 14 May 2015 08:02:09 -0500

The IETF has already spent time defining telephone numbers and I see 
little value in redefining the concept in the MODERN charter.  As such, 
I propose that we include a reference to RFC3966 as the definition of TN.

As one data point, the SCIM work references RFC3966 for telephone 
numbers.  We might, by the way, want to add SCIM to the list of areas we 
look at in the charter.

See my comments on Kieth's points below.

Regards,

Steve

> The ITU-T terms actually distinguish between those two usages, by putting them in separate recommendations.
SRD> RFC3966 deals with this, indicating that alphabetic characters are 
limited to local (non global) numbers.
> So do you intend such digit sequences used within this group to be unique or will it need a phone context as a result of using the RFC 3966 definition? The definitions I provided would not.
SRD> I suspect we will follow RFC3966, with global numbers being the 
default.  There is no reason to limit what MODERN does to managing 
global numbers.  I would not, however, suggest we take on including 
private number resources as a use case for the initial MODERN charter.

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Fri, 15 May 2015 13:16:11 +0000

The IETF has NOT defined telephone numbers. RFC 3966 defines a syntax that can be used to carry them, and I question whether that syntax is appropriate for use in the scenarios so far identified. To understand what RFC 3966 means one has to go to E.164 (and associated national numbering plans) and hope it touchs with the terminology used in those places.

I am fine as far it goes in terms of a sequence of decimal digits, but when we get to whether a phone context is required, then that is a jump into essentially supporting multiple numbering plans over a single interface. That would seem to be identifying an architecture of coordinating bodies with multiple numbering plans well beyond the scope of what is described so far. 

Within national administration, escape digits are defined within the national numbering plan to clearly identity all allocations within the national area. At least my assumption is that any procedures we are looking at would be within the context of a national numbering plan. If you have ideas that go beyond this, then perhaps you need to expand on them, because that goes way beyond what we have discussed so far.

Keith

> Sent: 14 May 2015 14:02
> Subject: [Modern] Definition of TN (was Re: Proposed change 
> to paragraph three of the charter)
> 
> The IETF has already spent time defining telephone numbers 
> and I see little value in redefining the concept in the 
> MODERN charter.  As such, I propose that we include a 
> reference to RFC3966 as the definition of TN.
> 
> As one data point, the SCIM work references RFC3966 for 
> telephone numbers.  We might, by the way, want to add SCIM to 
> the list of areas we look at in the charter.
> 
> > Firstly the charter gives no definition of what you are 
> using for telephone number, e.g. by reference to RFC 3966.
> >
> > RFC 3966 basically defines it as any sequence of decimal 
> digits. Other usages elsewhere include alphabetic characters, 
> because this name is used both in the context of what the 
> user represents to other users as his number and what 
> actually gets used in a signalling protocol.
> >
> > The ITU-T terms actually distinguish between those two 
> usages, by putting them in separate recommendations.
> > The additionally problem with RFC 3966 as a definition as 
> it does not define a usage where every sequence of digits is 
> unique, and therefore it has to add a phone context to enable 
> that uniqueness to exist, with a default applying to "global" numbers.
> >
> > So do you intend such digit sequences used within this 
> group to be unique or will it need a phone context as a 
> result of using the RFC 3966 definition? The definitions I 
> provided would not.
> default.  There is no reason to limit what MODERN does to 
> managing global numbers.  I would not, however, suggest we 
> take on including private number resources as a use case for 
> the initial MODERN charter.
> >
> > In regard to:
> >
> >> I do gather that you believe the expertise to do the MODERN work 
> >> resides in SG-2 rather than in the IETF. But the proposed working 
> >> group will not, say, reassign country code
> >> expertise and authority of that body to do. We're not delegating 
> >> authority for country codes to Internet entities as ENUM 
> did, which 
> >> necessitated an IAB liaison with SG-2, even. Those are all policy 
> >> issues. We're not trying to build policy, we're trying to 
> build tools 
> >> that will work in a variety of policy environments.
> > Then I do not believe that. I believe SG2 should define 
> what the numbers are that we use, and maybe they should 
> define the use cases. Once it is reduced to fulfilling a 
> protocol requirement, then I anyone (including IETF) can do the work.
> >
> > Regards
> >
> > Keith
> >
> >> RFC3966 meant by the term. TeRQ deferred to that specification for 
> >> its formal definition of telephone number, say. I see no reason to 
> >> reinvent that wheel.
> >>
> imprecise 
> >> or toxic, then I think we've confused ourselves into a 
> rejection of 
> >> common sense and common usage. The term is used without warning 
> >> labels in IETF standards track specifications already. The bar you 
> >> are raising is not consistent with IETF usage.
> >>
> >> I do gather that you believe the expertise to do the MODERN work 
> >> resides in SG-2 rather than in the IETF. But the proposed working 
> >> group will not, say, reassign country code
> >> expertise and authority of that body to do. We're not delegating 
> >> authority for country codes to Internet entities as ENUM 
> did, which 
> >> necessitated an IAB liaison with SG-2, even. Those are all policy 
> >> issues. We're not trying to build policy, we're trying to 
> build tools 
> >> that will work in a variety of policy environments.
> >>
> >> Jon Peterson
> >> Neustar, Inc.
> >>

---

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

Would it be inappropriate to add into the charter a work item to specify appropriate definitions of telephone numbers as needed per use case?

Best regards,

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

-----Original Message-----
From: Modern [mailto:[email-masked]] On Behalf Of DRAGE, Keith (Keith)
Sent: May 15, 2015 8:16 AM
To: Steve Donovan; [email-masked]
Subject: Re: [Modern] Definition of TN (was Re: Proposed change to paragraph three of the charter)

Keith

> Subject: [Modern] Definition of TN (was Re: Proposed change to
> paragraph three of the charter)
>
> little value in redefining the concept in the MODERN charter.  As
> such, I propose that we include a reference to RFC3966 as the
> definition of TN.
>
> numbers.  We might, by the way, want to add SCIM to the list of areas
> we look at in the charter.
>
> digits. Other usages elsewhere include alphabetic characters, because
> this name is used both in the context of what the user represents to
> other users as his number and what actually gets used in a signalling
> protocol.
> >
> it does not define a usage where every sequence of digits is unique,
> and therefore it has to add a phone context to enable that uniqueness
> to exist, with a default applying to "global" numbers.
> >
> group to be unique or will it need a phone context as a result of
> using the RFC 3966 definition? The definitions I provided would not.
> what the numbers are that we use, and maybe they should define the use
> cases. Once it is reduced to fulfilling a protocol requirement, then I
> anyone (including IETF) can do the work.
> >
> > Regards
> >
> > Keith
> >

________________________________

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: "McGarry, Tom" <[email-masked]>
Date: Fri, 15 May 2015 13:59:18 +0000

RFC3966 didn't require coordination with international or national
numbering authorities.  The work at MODERN won't either.  The charter says
- "Solutions and mechanisms created by the working group will be flexible
enough to accommodate different policies, e.g., by different regulatory
agencies."  It's up to the WG to build that flexibility in.

On 5/15/15 9:16 AM, "DRAGE, Keith (Keith)"
<[email-masked]> wrote:

>The IETF has NOT defined telephone numbers. RFC 3966 defines a syntax
>that can be used to carry them, and I question whether that syntax is
>appropriate for use in the scenarios so far identified. To understand
>what RFC 3966 means one has to go to E.164 (and associated national
>numbering plans) and hope it touchs with the terminology used in those
>places.
>
>I am fine as far it goes in terms of a sequence of decimal digits, but
>when we get to whether a phone context is required, then that is a jump
>into essentially supporting multiple numbering plans over a single
>interface. That would seem to be identifying an architecture of
>coordinating bodies with multiple numbering plans well beyond the scope
>of what is described so far.
>
>Within national administration, escape digits are defined within the
>national numbering plan to clearly identity all allocations within the
>national area. At least my assumption is that any procedures we are
>looking at would be within the context of a national numbering plan. If
>you have ideas that go beyond this, then perhaps you need to expand on
>them, because that goes way beyond what we have discussed so far.
>
>Keith
>
>>https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman
>>_listinfo_modern&d=AwICAg&c=MOptNlVtIETeDALC_lULrw&r=4Klm32iB7HufveeIDcLe
>>xtZ1ooNcfp01IYIaVqsORjI&m=FrBWPwqBvWGzEfXBPELFlleLV9bTVkkeypURT6kU1B8&s=v
>>UUR-S68_HexdvOSjFlbbESMXS9wj8O0g1-oCX0r07U&e=
>> >>>>>>
>>https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman
>>_listinfo_modern&d=AwICAg&c=MOptNlVtIETeDALC_lULrw&r=4Klm32iB7HufveeIDcLe
>>xtZ1ooNcfp01IYIaVqsORjI&m=FrBWPwqBvWGzEfXBPELFlleLV9bTVkkeypURT6kU1B8&s=v
>>UUR-S68_HexdvOSjFlbbESMXS9wj8O0g1-oCX0r07U&e=
>>https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman
>>_listinfo_modern&d=AwICAg&c=MOptNlVtIETeDALC_lULrw&r=4Klm32iB7HufveeIDcLe
>>xtZ1ooNcfp01IYIaVqsORjI&m=FrBWPwqBvWGzEfXBPELFlleLV9bTVkkeypURT6kU1B8&s=v
>>UUR-S68_HexdvOSjFlbbESMXS9wj8O0g1-oCX0r07U&e=
>> >>>>
>> >>
>>https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman
>>_listinfo_modern&d=AwICAg&c=MOptNlVtIETeDALC_lULrw&r=4Klm32iB7HufveeIDcLe
>>xtZ1ooNcfp01IYIaVqsORjI&m=FrBWPwqBvWGzEfXBPELFlleLV9bTVkkeypURT6kU1B8&s=v
>>UUR-S68_HexdvOSjFlbbESMXS9wj8O0g1-oCX0r07U&e=
>> >
>> 
>>https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman
>>_listinfo_modern&d=AwICAg&c=MOptNlVtIETeDALC_lULrw&r=4Klm32iB7HufveeIDcLe
>>xtZ1ooNcfp01IYIaVqsORjI&m=FrBWPwqBvWGzEfXBPELFlleLV9bTVkkeypURT6kU1B8&s=v
>>UUR-S68_HexdvOSjFlbbESMXS9wj8O0g1-oCX0r07U&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=FrBWPwqBvWGzEfXBPELFlleLV9bTVkkeypURT6kU1B8&s=vUUR
>-S68_HexdvOSjFlbbESMXS9wj8O0g1-oCX0r07U&e=

---

From: "Ben Campbell" <[email-masked]>
Date: Fri, 15 May 2015 09:03:46 -0500

<ADHat>

(I'm not picking on Keith in particular. This just seemed a good place 
to jump in.)

I'd like to remind people that this is a charter, not a technical 
specification. We need guidance to the working group. It doesn't have to 
be perfect, and there's room for some flexibility

</ADHat>

<NoHats>

It seems to me that the syntax is mainly what we care about, _not_ the 
architecture of coordinating bodies. My understanding is the whole point 
of this exercise is to avoid building assumptions about that 
architecture and related policies into the technology itself.

If a national administration defines escape digits, we need to be able 
to handle escape digits. But that doesn't mean we have to import the 
whole administrative architecture.

</NoHats>

On 15 May 2015, at 8:16, DRAGE, Keith (Keith) wrote:

> when we get to whether a phone context is required, then that is a 
> jump into essentially supporting multiple numbering plans over a 
> single interface. That would seem to be identifying an architecture of 
> coordinating bodies with multiple numbering plans well beyond the 
> scope of what is described so far.
>
> looking at would be within the context of a national numbering plan. 
> If you have ideas that go beyond this, then perhaps you need to expand 
> on them, because that goes way beyond what we have discussed so far.
>
> Keith
>

---

From: "Ben Campbell" <[email-masked]>
Date: Fri, 15 May 2015 09:05:26 -0500

On 15 May 2015, at 8:41, Gorman, Pierce A [CTO] wrote:

> Would it be inappropriate to add into the charter a work item to 
> specify appropriate definitions of telephone numbers as needed per use 
> case?

It would be nice to understand that going in, but if that can't happen, 
I don't think it would be a problem to ask the working group to define 
it.

> 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: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Fri, 15 May 2015 14:36:32 +0000

You have at least missed the point I have been making.

By using RFC 3966 as a syntax definition, you automatically include a requirement to support phone context.

The point I am making is that in my understanding from the use cases so far discussed, phone context is unnecessary, as we are dealing with protocol with a single administration supporting a single national numbering space. The context is one only and implicit in the administration one is presumably securely communicating with.

Keith 

> From: Ben Campbell [mailto:[email-masked]] 
> Sent: 15 May 2015 15:04
> To: DRAGE, Keith (Keith)
> Cc: Steve Donovan; [email-masked]
> Subject: Re: [Modern] Definition of TN (was Re: Proposed 
> change to paragraph three of the charter)
> 
> <ADHat>
> 
> (I'm not picking on Keith in particular. This just seemed a 
> good place to jump in.)
> 
> I'd like to remind people that this is a charter, not a 
> technical specification. We need guidance to the working 
> group. It doesn't have to be perfect, and there's room for 
> some flexibility
> 
> </ADHat>
> 
> <NoHats>
> 
> It seems to me that the syntax is mainly what we care about, 
> _not_ the architecture of coordinating bodies. My 
> understanding is the whole point of this exercise is to avoid 
> building assumptions about that architecture and related 
> policies into the technology itself.
> 
> If a national administration defines escape digits, we need 
> to be able to handle escape digits. But that doesn't mean we 
> have to import the whole administrative architecture.
> 
> </NoHats>
> 
> 
> and I see 
> >> what the numbers are that we use, and maybe they should define the 
> >> use cases. Once it is reduced to fulfilling a protocol 
> requirement, 
> >> then I anyone (including IETF) can do the work.
> >>>
> >>> Regards
> >>>
> >>> Keith
> >>>
> >>>> No, what I've said consistently is that what I mean by 
> the term is 
> >>>> what
> specification for

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 15 May 2015 11:42:36 -0400

> The point I am making is that in my understanding from the use cases so far discussed, phone context is unnecessary, as we are dealing with protocol with a single administration supporting a single…

Isn't it an expectation that the numbers being discussed *can* be 
represented in SIP? If so, then 3966 is relevant.

	Thanks,
	Paul

---

From: "Peterson, Jon" <[email-masked]>
Date: Fri, 15 May 2015 16:42:08 +0000

The fundamental point here is that the MODERN working group proposes to
treat telephone numbers as an existing identifier defined elsewhere, not
to define them itself. If it were defining telephone numbers, then I think
it would actually be infringing on the turf of SG-2. The "definition" of
telephone numbers in RFC3966 is indeed just an attempt to capture the
syntax of an existing identifier out there in the world in IETFese. That
is clearly within the IETF's purview, and MODERN would not be breaking any
new ground to simply follow that definition.

TeRQ is slightly more specific about which parts of the ABNF of RFC3966
are useful to this effort, but per Ben's point, we aren't going to specify
the protocol in our charter language.

Jon Peterson
Neustar, Inc.

On 5/15/15, 8:42 AM, "Paul Kyzivat" <[email-masked]> wrote:

>> The point I am making is that in my understanding from the use cases so
>>far discussed, phone context is unnecessary, as we are dealing with
>>protocol with a single administration supporting a single national
>>numbering space. The context is one only and implicit in the
>>administration one is presumably securely communicating with.
>

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Fri, 15 May 2015 18:02:07 +0000

You tell me, but my expectation, that it will not happen on a per session basis, and any entity receiving this information will be capable of, and need to be capable of, switching between the different number formats.

Keith

> Paul Kyzivat
> Sent: 15 May 2015 16:43
> > By using RFC 3966 as a syntax definition, you automatically 
> include a requirement to support phone context.
> >
> > The point I am making is that in my understanding from the 
> use cases so far discussed, phone context is unnecessary, as 
> we are dealing with protocol with a single administration 
> supporting a single national numbering space. The context is 
> one only and implicit in the administration one is presumably 
> securely communicating with.
> 
> Isn't it an expectation that the numbers being discussed 
> *can* be represented in SIP? If so, then 3966 is relevant.
> 
> 	Thanks,
> 	Paul
> 
> > Keith
> >
> >> (I'm not picking on Keith in particular. This just seemed a good 
> >> place to jump in.)
> >>
> >> specification. We need guidance to the working group. It 
> doesn't have 
> >> to be perfect, and there's room for some flexibility
> >>
> >> </ADHat>
> >>
> >> <NoHats>
> >>
> >> It seems to me that the syntax is mainly what we care about, _not_ 
> >> the architecture of coordinating bodies. My understanding is the 
> >> whole point of this exercise is to avoid building 
> assumptions about 
> >> that architecture and related policies into the technology itself.
> >>
> >> If a national administration defines escape digits, we need to be 
> >> able to handle escape digits. But that doesn't mean we 
> have to import 
> telephone 
> result of 
> delegating 
> define the 
> delegating 
> >>>>>>>> We don't mean anything different by telephone 
> numbers than the 
> >>>>>>>> abstract of
> >>>>>>>>>> Subject: [Modern] Proposed change to paragraph 
> three of the 
> >>>>>>>>>> charter
> >>>>>>>>>>
> >>>>>>>>>> All,
> >>>>>>>>>>

---

From: Steve Donovan <[email-masked]>
Date: Mon, 18 May 2015 10:50:28 -0500

Keith,

I think this is something that can be discussed by the working group 
and, to my mind, doesn't require addressing in the charter.

I can "cook up" a use case where public and private number formats could 
be used in a single session, but I don't feel that is relevant to the 
charter discussion.

Can we live with the charter as currently worded and address this as 
part of the working group effort?

Steve

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Mon, 18 May 2015 23:05:49 +0000

I provided wording messages back which I think provided better definition of what we mean by telephone numbers that the current reference to RFC 3966, which to me is providing a coding solution with too many options.

And being able to "cook" up a use case does not mean that we need that as a use case.

Keith

> Sent: 18 May 2015 16:50
> I think this is something that can be discussed by the 
> working group and, to my mind, doesn't require addressing in 
> the charter.
> 
> I can "cook up" a use case where public and private number 
> formats could be used in a single session, but I don't feel 
> that is relevant to the charter discussion.
> 
> Can we live with the charter as currently worded and address 
> this as part of the working group effort?
> 
> Steve
> 
> > You tell me, but my expectation, that it will not happen on 
> a per session basis, and any entity receiving this 
> information will be capable of, and need to be capable of, 
> switching between the different number formats.
> >
> > Keith
> >
> >> From: Modern [mailto:[email-masked]] On Behalf Of Paul 
> >> Kyzivat
> >> Sent: 15 May 2015 16:43
> >> To: [email-masked]
> >> use cases so far discussed, phone context is unnecessary, 
> as we are 
> >> dealing with protocol with a single administration supporting a 
> >> single national numbering space. The context is one only 
> and implicit 
> >> in the administration one is presumably securely 
> communicating with.
> >>
> technical

---

From: Steve Donovan <[email-masked]>
Date: Wed, 20 May 2015 09:33:38 -0500

> I provided wording messages back which I think provided better definition of what we mean by telephone numbers that the current reference to RFC 3966, which to me is providing a coding solution wit…

Then we can pair away the options that don't apply as part of the 
working group effort.
> And being able to "cook" up a use case does not mean that we need that as a use case.
I do think that private numbering plans should be in scope, or at least 
not ruled out of scope by the charter.

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Sun, 24 May 2015 05:29:17 +0000

I assume you mean "pare".

I was not aware that IETF defined charters of the form "Lets solve everything including world hunger" and decided what it might work on after the charter was approved.

Regards

Keith 

> Sent: 20 May 2015 15:34
> > I provided wording messages back which I think provided 
> better definition of what we mean by telephone numbers that 
> the current reference to RFC 3966, which to me is providing a 
> coding solution with too many options.
> 
> Then we can pair away the options that don't apply as part of 
> the working group effort.
> >
> I do think that private numbering plans should be in scope, 
> or at least not ruled out of scope by the charter.
> >
> > Keith
> >
> working group 
> >> I can "cook up" a use case where public and private number formats 
> >> could be used in a single session, but I don't feel that 
> is relevant 
> >> to the charter discussion.
> >>
> information will 
> >> be capable of, and need to be capable of, switching between the 
> >> different number formats.
> >>> Keith
> >>>
> >>>>>>>> private number resources as a use case for the 
> initial MODERN 
> >>>>>>>> charter.
> >>>>>>>>> In regard to:
> >>>>>>>>>
> >>>>>>>>>>>>> E.164 numbers, local special purpose numbers, 
> and network
> >>>>>>>>>> specific
> >>>>>>>>>>>>> numbers" using the explanation of these terms 
> that can be
> >>>>>>>>>> found in

---

From: Steve Donovan <[email-masked]>
Date: Mon, 25 May 2015 21:14:19 -0500

> I assume you mean "pare".
SRD> Yes.
> I was not aware that IETF defined charters of the form "Lets solve everything including world hunger" and decided what it might work on after the charter was approved.
SRD> What in the charter, RFC3966 or my email talks about solving world 
hunger?  My email was in reference to RFC3966, which, to my 
understanding, solves a much simpler problem than world hunger.