Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern)

From: "Richard Hill" <[email-masked]>
Date: Wed, 1 Jul 2015 11:13:31 +0200

Please see embedded comments below.

Thanks and best,
Richard

> -----Original Message-----
> From: Modern [mailto:[email-masked]] On Behalf Of Gorman,
> Pierce A [CTO]
> Sent: Tuesday, June 30, 2015 22:08
> To: Adam Roach; DOLLY, MARTIN C
> Cc: [email-masked]
> Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering,
> Distributing, Exposing, & Registering telephone Numbers (modern)
> 
> Adam,
> 
> The IP PBX use case that Cullen Jennings documented is sensible, but
> also small scale, and if that was all the MODERN charter proposed to
> do, then there would probably be no lack of consensus (as compared to
> where we are in reality).
> 
> The reality is if that was all MODERN would attempt, then its leading
> proponents would be very dissatisfied.

Is this the case?

> 
> Some are frustrated with the existing multi-database and multi-
> regulatory organizational structure of number and routing information
> management in carrier-based telecommunications and believe they see a
> possibility to bypass this situation through a protocol and data model
> (of a super-database?) work effort in the IETF.  Apparently this is a
> political and commerical matter with the emphasis on the former.

Indeed, and I think that we all agree that the regulatory and economic
aspects of telephone number management are not in the scope of the IETF.

SNIP

> 
> So, while the work of MODERN is aimed to solve certain [relatively
> minor?] specific allocation implementation issues:
>      1.  This may not represent the overwhelming interests of current
> or future operators; &
>      2.  Specifically MODERN must consider application to the current
> architectures used for allocation, management, & use of E.164 resource,
> including LERG, NPAC, Point Code Data, and SMS800 in the US.
>      3.  IETF should formally liaise with those major national &
> international bodies that support the allocation, administration &
> usage of numbering data bases including ITU, NANC, LNPA WG, INC, and
> the FoN; both before the WG is activated, & to help steer its work.

Regarding ITU, in my view they only way to get a sensible response from them
is to send them a formal liaison statement. When they get it, they may not
reply, but then that would mean that they don't have any concerns with what
MODERN is doing.

If you don't send a formal liaison and rely on ITU's looking at IETF mailing
lists, then you probably won't get a reply until the IETF asks for something
that impacts the ITU. And then they might be annoyed because they were not
formally brought into the loop earlier. That's what happened with ENUM and I
don't think that we should risk a repeat of that situation.

> 
> Best regards,
> 
> 
> Pierce Gorman
> Core Network Planning
> O: 913-439-4368
> [email-masked]
> 
> 
> -----Original Message-----
> From: Modern [mailto:[email-masked]] On Behalf Of Adam Roach
> Sent: June 29, 2015 10:27 PM
> To: DOLLY, MARTIN C
> Cc: [email-masked]
> Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering,
> Distributing, Exposing, & Registering telephone Numbers (modern)
> 
> We discussed this exact use case in Dallas. From Jon's presentation:
> 
> https://www.dropbox.com/s/58rjn55ji8i34tg/Screenshot%202015-06-
> 29%2022.12.37.png?dl=0
> 
> It's also described in the charter. In fact, it's really the main
> thrust of the work: the charter repeatedly talks about acquiring,
> managing, and resolving TNs. This is the "acquring" part.
> 
> So now, as I'm reflecting on it, I'm a little confused about what *you*
> think MODERN will be doing. Perhaps whatever you're worried about isn't
> actually happening.
> 
> /a
> 
> 
> On 6/29/15 21:24, DOLLY, MARTIN C wrote:
> > How is that applicable? Scope question?
> >
> > Sent from my iPhone
> >
> >> On Jun 29, 2015, at 10:16 PM, Adam Roach <[email-masked]> wrote:
> >>
> >> In this context, there isn't one.
> >>
> >> MARTINI was predicated on a continuation of having VISPs do
> excruciatingly manual things like emailing -- or in some cases faxing -
> -  spreadsheets to their customers detailing number ranges. I think I
> still have the one I got from our VISP back in the Estacado days when I
> was running our PBX. I can dig it up and forward it to you if you
> really don't know how number assignment works at that level. Basically,
> it's a lot of human reading and human typing. If you're lucky, you
> don't have to get a fax machine involved, so you can at least copy and
> paste.
> >>
> >> But emailing or faxing spreadsheets around is a brutally primitive
> and error-prone way to get this kind of thing done. I'm a little
> surprised it took this long for anyone to make a serious run at some
> standardized form of automation.
> >>
> >> /a
> >>
> >>> On 6/29/15 21:00, DOLLY, MARTIN C wrote:
> >>> Please explain the number assignment process
> >>>
> >>> Sent from my iPhone
> >>>
> >>>>> On Jun 29, 2015, at 9:56 PM, Adam Roach <[email-masked]> wrote:
> >>>>>
> >>>>> On 6/29/15 20:19, Cullen Jennings wrote:
> >>>>> I think private network case is already happening. There are more
> and more PBX that integrate with cloud providers such as Tropo or
> Twillio to get phone numbers using a simple API.
> >>>> And, really, ever since we ruled this out of scope for MARTINI,
> it's been a pretty big gap in SIP PBX deployments.
> >>>>
> >>>> /a
> >>>>
> >>>> _______________________________________________
> >>>> Modern mailing list
> >>>> [email-masked]
> >>>> https://www.ietf.org/mailman/listinfo/modern
> >>> _______________________________________________
> >>> Modern mailing list
> >>> [email-masked]
> >>> https://www.ietf.org/mailman/listinfo/modern
> 
> _______________________________________________
> 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.
> 
> _______________________________________________
> Modern mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/modern

---

From: "Richard Hill" <[email-masked]>
Date: Wed, 1 Jul 2015 11:27:49 +0200

Thank you for this and please see embedded replies below.

Best,
Richard

===================

>From: Modern [mailto:[email-masked]] On Behalf Of Alissa Cooper
>Sent: Tuesday, June 30, 2015 23:01
>To: [email-masked]
Distributing, Exposing, & >Registering telephone Numbers (modern)

SNIP

>The conclusion from the BoF in Dallas was that there was rough consensus in
the room in >support of forming the WG but that the charter and problem
scope needed refinement (feel free >to review the
minutes: http://www.ietf.org/proceedings/92/minutes/minutes-92-modern). That
>process of refinement took place on this list over several months following
the BoF. The
>charter was put out for review on June 12

I presume that the point of that is precisely to solicit comments from
people who were not at the BoF and were not involved up to then.

> with comments requested to be sent to the IESG by June 22. 

I apologize for not having responded sooner.

>The IESG considered the two ITU-T related comments received (both after the
deadline)

I presume that you consider my comment to be "ITU-T related", but actually
it covered broader issues, such as whether the IETF should get into process
reengineering.

> and issued no blocking comments on the charter

Actually in my message to the IESG I formally objected to the creation of
this group, and gave the reasons for my objection.

I fully understand that one objection, or even more than one objection, is
not necessarily sufficient to prevent approval of the creation of the group.
However, I think that it would have been appropriate to explain why the IESG
did not consider my reasons to be sufficient to block approval.

>but asked that edits be considered on the basis of comments received. There
were no other >comments received or indications provided to the IESG about
the readiness of this work for >chartering. 

See above.

>I’m still working on edits (Richard Hill pointed out that I missed his
suggestions)

Indeed, I didn't see any objections to my first set of edits, so I'm looking
forward to seeing them incorporated.

More importantly, it has now become clear that it is not clear (pun
intended) whether the group's charter is intended to be limited to
"management of how to get telephone numbers"  or whether it might be
intended to include the much wider "management of telephone numbers".

>From my point of view, the latter is out of the scope of the IETF, so the
charter should be clarified so that it refers only to the former.

I made a proposal for that, but there was one objection.

After some other E-Mail exchanges, I made a second proposal.  I haven't yet
seen any objections to that second proposal.

So I'm looking forward to a revised charter than makes it clear that the
scope of this group's work is "how to get numbers within the existing
regulatory frameworks".

> and milestones are in the works as well. Thus this WG is being formed
according to the
> usual process.

As several people have pointed out, issues relating to telephone numbers
include regulatory and economic issues that can be very tricky and
politically sensitive.  So maybe a bit more caution needs to be exercised
here than "the usual process".

In particular, I still think that the charter should be sent to ITU-T Study
Group 2 as a formal liaison statement, asking for their comments. [NOTE: I
don't participate in ITU-T Study Group 2]

>Alissa

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Wed, 1 Jul 2015 12:45:12 +0000

My remembrance is somewhat different.

3GPP had a solution, based on existing mechanisms, and already enshrined in their procedures for similar capabilities not based on MARTINI, using reg event which you claimed was broken. 

Rather than prolong the argument, the discussion was left out.

3GPP still specifies the reg event mechanism for this functionality, so as far as 3GPP is concerned, there is no hole in the story.

Regards

Keith

> From: Adam Roach [mailto:[email-masked]] 
> Sent: 30 June 2015 17:31
> To: DRAGE, Keith (Keith); DOLLY, MARTIN C
> Cc: [email-masked]
> Subject: Re: [Modern] [new-work] WG Review: Managing, 
> Ordering, Distributing, Exposing, & Registering telephone 
> Numbers (modern)
> 
> On 6/30/15 09:39, DRAGE, Keith (Keith) wrote:
> > You make this sound like MARTINI was originally meant to 
> solve world hunger, and somehow got scoped down, which is untrue.
> 
> The MARTINI charter was silent on the issue of whether the 
> AORs being registered were explicit or implicit. Making them 
> implicit was a simplification, but not a necessary one. We 
> could have been explicit about the AORs being registered and 
> still been well within the charter.
> 
> My point is that this simplification left a hole in the 
> story, and that MODERN's work is well positioned to fill that hole.
> 
> /a
>

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Wed, 1 Jul 2015 12:45:15 +0000

So my question still remains, given that this is significant data associated with the number, rather than just the number itself.

How do we distinguish this problem from either device configuration, or network management, for which a number of solutions still exist?

If the problem is not distinguished, then why are the existing device configuration and network management solutions not appropriate?

Regards

Keith

> From: Modern [mailto:[email-masked]] On Behalf Of 
> Henning Schulzrinne
> Sent: 30 June 2015 19:50
> To: DRAGE, Keith (Keith)
> Cc: [email-masked]
> I think of the phone number as a key into a logical (not 
> necessarily physical) database with a variety of fields (and 
> a change log), some that are near-universal and others that 
> are highly-specific to countries, use cases or even 
> companies. We do the same for domain names, e.g., technical 
> and administrative contacts or for DHCP, where an IP address 
> is associated with a set of service records (e.g., for a SIP 
> proxy, LIS or LoST server in our technical neighborhood).
> 
> Much of that information exists already and is in the AT&T 
> and Tropos APIs, the LNPA or LERG. Examples include:
> 
> * OCN/carrier code (some kind of assignment identifier is 
> probably unavoidable)
> * number state (available, locked, etc.)
> * reachability (URLs)
> * cryptographic keying materials
> 
> All but the first and maybe second are likely to be optional. 
> As usual, there would be suitable extension points, e.g., to 
> accommodate storing 911 address information that only makes 
> sense in certain relationships (not for the LNPA, but for a 
> carrier-customer relationship). All the usual stuff applies 
> that the veterans in this group do by rote: IANA 
> considerations, privacy considerations, security considerations, ...
> 
> Henning
> 
> ________________________________________
> From: Modern [[email-masked]] on behalf of DRAGE, 
> Keith (Keith) [[email-masked]]
> Sent: Tuesday, June 30, 2015 9:50 AM
> First of all, Jons presentation has no status (it was one of 
> a number of presentations made at the meeting as to a single 
> individuals view of what might be useful); what matters is 
> the charter.
> 
> However what is clear to me is that we have no consensus 
> agreement on what this group is meant to be doing or what the 
> charter actually means. Otherwise this discussion would not 
> be occurring.
> 
> At the simplest it appears to me that people were stating a 
> data model where a telephone number is associated with a 
> specific owner, and nothing more than that.
> 
> However if you dive into various people's proposed use cases, 
> it appears that more than that is envisaged. So for example 
> to run any enterprise system, that telephone number would 
> need to be assocated with various other data either:
> 
> -       in the end device itself, that controls how that 
> telephone number fits with the functions that the end device 
> provides, any security certificates, or relates to other 
> identifiers in the device; and/or
> 
> -       in some server belonging to the enterprise where the 
> end users service policy is policed, and added functionality 
> may also be provided.
> 
> Now the first bullet above is device configuration, and the 
> second bullet above is network management.
> 
> So I believe some people are talking as if the problem MODERN 
> is meant to solve also includes device configuration and 
> network management, as I have described above, and that is 
> certainly considerably more that a simple allocation problem.
> 
> So which is it? In this new protocol, what data model will 
> the end point of the protocol end up with?
> 
> Keith
> 
> > Sent: 30 June 2015 04:27
> > https://www.dropbox.com/s/58rjn55ji8i34tg/Screenshot%202015-06
> > -29%2022.12.37.png?dl=0
> >
> > So now, as I'm reflecting on it, I'm a little confused about what 
> > *you* think MODERN will be doing. Perhaps whatever you're worried 
> > about isn't actually happening.
> >
> > /a
> >
> >
> > >> MARTINI was predicated on a continuation of having VISPs
> > do excruciatingly manual things like emailing -- or in some cases 
> > faxing --  spreadsheets to their customers detailing number 
> ranges. I 
> > think I still have the one I got from our VISP back in the Estacado 
> > days when I was running our PBX. I can dig it up and 
> forward it to you 
> > if you really don't know how number assignment works at that level. 
> > Basically, it's a lot of human reading and human typing. If you're 
> > lucky, you don't have to get a fax machine involved, so you can at 
> > least copy and paste.
> > >>
> > >> But emailing or faxing spreadsheets around is a brutally
> > primitive and error-prone way to get this kind of thing done.
> > I'm a little surprised it took this long for anyone to make 
> a serious 
> > run at some standardized form of automation.
> > >>
> > >> /a
> > >>
> > >>>>> I think private network case is already happening.
> > There are more and more PBX that integrate with cloud 
> providers such 
> > as Tropo or Twillio to get phone numbers using a simple API.
> > >>>> And, really, ever since we ruled this out of scope for
> > MARTINI, it's been a pretty big gap in SIP PBX deployments.
> > >>>>
> > >>>> /a
> > >>>>

---

From: "Ben Campbell" <[email-masked]>
Date: Wed, 01 Jul 2015 08:09:31 -0500

On 1 Jul 2015, at 7:45, DRAGE, Keith (Keith) wrote:

> So my question still remains, given that this is significant data 
> associated with the number, rather than just the number itself.
>
> How do we distinguish this problem from either device configuration, 
> or network management, for which a number of solutions still exist?
>
> If the problem is not distinguished, then why are the existing device 
> configuration and network management solutions not appropriate?

(no hats)

It's not unreasonable that the working group, after considering 
requirements, could decide that an existing solution was appropriate.

>> Adam Roach

---

From: "DOLLY, MARTIN C" <[email-masked]>
Date: Wed, 1 Jul 2015 13:12:18 +0000

But this is the root of the issue here, the requirements for such a solution is based on policy and regulation, that does not exist , yet....

-----Original Message-----
From: Modern [mailto:[email-masked]] On Behalf Of Ben Campbell
Sent: Wednesday, July 01, 2015 9:10 AM
To: DRAGE, Keith (Keith)
Cc: [email-masked]; Henning Schulzrinne
Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern)

(no hats)

It's not unreasonable that the working group, after considering requirements, could decide that an existing solution was appropriate.

>> From: Modern [mailto:[email-masked]] On Behalf Of Henning 
>> Schulzrinne
>> Sent: 30 June 2015 19:50
>> To: DRAGE, Keith (Keith)
>> Cc: [email-masked]
>> I think of the phone number as a key into a logical (not necessarily 
>> physical) database with a variety of fields (and a change log), some 
>> that are near-universal and others that are highly-specific to 
>> countries, use cases or even companies. We do the same for domain 
>> names, e.g., technical and administrative contacts or for DHCP, where 
>> an IP address is associated with a set of service records (e.g., for 
>> a SIP proxy, LIS or LoST server in our technical neighborhood).
>>
>> Much of that information exists already and is in the AT&T and Tropos 
>> APIs, the LNPA or LERG. Examples include:
>>
>> * OCN/carrier code (some kind of assignment identifier is probably 
>> unavoidable)
>> accommodate storing 911 address information that only makes sense in 
>> certain relationships (not for the LNPA, but for a carrier-customer 
>> relationship). All the usual stuff applies that the veterans in this 
>> group do by rote: IANA considerations, privacy considerations, 
>> security considerations, ...
>>
>> Henning
>>
>> From: Modern [[email-masked]] on behalf of DRAGE, Keith 
>> (Keith) [[email-masked]]
>> First of all, Jons presentation has no status (it was one of a number 
>> of presentations made at the meeting as to a single individuals view 
>> of what might be useful); what matters is the charter.
>>
>> However what is clear to me is that we have no consensus agreement on 
>> what this group is meant to be doing or what the charter actually 
>> means. Otherwise this discussion would not be occurring.
>>
>> At the simplest it appears to me that people were stating a data 
>> model where a telephone number is associated with a specific owner, 
>> and nothing more than that.
>>
>> However if you dive into various people's proposed use cases, it 
>> appears that more than that is envisaged. So for example to run any 
>> enterprise system, that telephone number would need to be assocated 
>> with various other data either:
>>
>> provides, any security certificates, or relates to other identifiers 
>> in the device; and/or
>>
>> end users service policy is policed, and added functionality may also 
>> be provided.
>>
>> Now the first bullet above is device configuration, and the second 
>> bullet above is network management.
>>
>> So I believe some people are talking as if the problem MODERN is 
>> meant to solve also includes device configuration and network 
>> management, as I have described above, and that is certainly 
>> considerably more that a simple allocation problem.
>>
>> So which is it? In this new protocol, what data model will the end 
>> point of the protocol end up with?
>>
>> Keith
>>

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 1 Jul 2015 13:29:11 +0000

Indeed, it would be interesting to see whether and how Netconf/YANG fits the requirements. I'm sure somebody will propose using DNS TXT records...

Henning

________________________________________
From: DRAGE, Keith (Keith) [[email-masked]]
Sent: Wednesday, July 01, 2015 8:45 AM
To: Henning Schulzrinne
Cc: [email-masked]
Subject: RE: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern)

Regards

Keith

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 1 Jul 2015 13:34:04 +0000

To move the discussion forward, rather than cycling back to invoking the terms, I'd be interested in hearing which requirements, precisely and concretely, are likely to depend on policy and regulation. 

Everybody has iterated again and again that the "who can get what" part definitely does, but that's outside the protocol mechanism, just like "who can see what web page" or "who can place what SIP call" is beyond the concern of HTTP or SIP, beyond providing an authentication mechanism that allows to associate a policy with a principal.

You must have specific issues in mind that go beyond that.

Henning

________________________________________
From: DOLLY, MARTIN C [[email-masked]]
Sent: Wednesday, July 01, 2015 9:12 AM
To: Ben Campbell; DRAGE, Keith (Keith)
Cc: [email-masked]; Henning Schulzrinne
Subject: RE: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern)

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Wed, 1 Jul 2015 14:08:30 +0000

Yes, but the problem is that it appears that the current charter is so widely scoped that any issue that any network management issue involving a telephone number falls within the scope of the charter, whereas existing network management (or device configuration groups) should cover network management problems.

The charter should be revised to be more precise.

Regards

Keith

> From: Ben Campbell [mailto:[email-masked]] 
> Sent: 01 July 2015 14:10
> To: DRAGE, Keith (Keith)
> Cc: Henning Schulzrinne; [email-masked]
> It's not unreasonable that the working group, after 
> considering requirements, could decide that an existing 
> solution was appropriate.
> 
> >
> > Regards
> >
> > Keith
> >
> necessarily 
> and Tropos 
> agreement on

---

From: "DOLLY, MARTIN C" <[email-masked]>
Date: Wed, 1 Jul 2015 14:12:26 +0000

May be I have been a System Engineer too long:
1. The service/capability requirements would be defined by policy/regulatory needs.
2. Then the "tool" requirements would be derived from the policy/regulatory needs

A builder needs to know what he is building in order to ensure that he has the correct tools in his tool box....

-----Original Message-----
From: Henning Schulzrinne [mailto:[email-masked]] 
Sent: Wednesday, July 01, 2015 9:34 AM
To: DOLLY, MARTIN C; Ben Campbell; DRAGE, Keith (Keith)
Cc: [email-masked]
Subject: RE: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern)

Henning

---

From: "Ben Campbell" <[email-masked]>
Date: Wed, 01 Jul 2015 09:25:55 -0500

(no hats)

On 1 Jul 2015, at 9:08, DRAGE, Keith (Keith) wrote:

> Yes, but the problem is that it appears that the current charter is so 
> widely scoped that any issue that any network management issue 
> involving a telephone number falls within the scope of the charter, 
> whereas existing network management (or device configuration groups) 
> should cover network management problems.
>

I think that's a tortured reading of the charter as a whole.

> The charter should be revised to be more precise.

I disagree. The charter is not a technical specification. It needs to 
balance precision against allowing enough flexibility for the working 
group to make decisions. I think it's time to let the wg start making 
those decisions (and much of the discussion over the last few days may 
be useful for that purpose.)

Ben.

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Wed, 1 Jul 2015 14:37:31 +0000

It is not me that is doing the tortured reading. It is apparent from potential use cases being identified on the list that others have that flexibility of the reading from the current charter.

But the point I am making is that working groups should not be created to cover the work of other groups. It is clear that there is significant overlap of this charter with groups doing network management, and that needs to be resolved. 

It is not about restricting the flexibility of the group, it is dealing with overlap (a matter that gets written into the charter of many working groups). 

Regards

Keith

> Sent: 01 July 2015 15:26
> I disagree. The charter is not a technical specification. It 
> needs to balance precision against allowing enough 
> flexibility for the working group to make decisions. I think 
> it's time to let the wg start making those decisions (and 
> much of the discussion over the last few days may be useful 
> for that purpose.)
> 
> 
> Ben.
> 
> >
> > Regards
> >
> > Keith
> >

---

From: Richard Shockey <[email-masked]>
Date: Wed, 01 Jul 2015 10:21:08 -0400

Please fix one thing first. MARTINI did one thing and did it well. We
opened the WG and closed it down in record time.

Discussions of device configuration frankly will go no where. Been there
done that.  Vendor specific solutions have dominated that area for some
time and will continue to do so. See RFC 6011 for another example of IETF
epic failure.  No ENUM did not fail.  e164.apra failed. Contrary to
popular opinion. The protocol is widely deployed is countless carrier
networks in private carrier specific configurations.

http://www.sipforum.org/content/view/311/253/

I don¹t think number management will go very far at least for years.  Not
because of regulatory concerns its just that the cost of the OSS/BSS
systems in global carrier networks are so expensive and modifying them
would cost more that the current US LNP database and no one is going there
ever again. I could say some very very uncharitable things about the
certain national numbering advisory committees but ...

Not to mention there is ample public statements that the incumbent
carriers have no intention of spending one penny on anything involving
reconfiguring existing TDM networks that continue to dominate the global
voice market.

There is one thing that would be very useful.  A general purpose query
response mechanism for STIR public keys. RFC 6116 and SIP Redirect have
generally outlived their usefulness for countless reasons. Public key
management and retrieval could deploy very quickly in modern SIP and
mobile access networks (aka VoLTE) and actually solve a global public
policy problem. If the mechanism works then it might possible to fold
other use cases and numbering meta data into the structure as the voice
networks evolve.. Of course it would be nice to see 4474bis finished up
first. < hint Cullen :-) >

It might be useful for some folks around here to consider the actual
reality of how carrier real time networks work not to mention the issues
of CAPEX constraints on what is actually possible to deploy.

On 7/1/15, 9:29 AM, "Modern on behalf of Henning Schulzrinne"
<[email-masked] on behalf of [email-masked]> wrote:

>Indeed, it would be interesting to see whether and how Netconf/YANG fits
>the requirements. I'm sure somebody will propose using DNS TXT records...
>
>Henning
>
>Subject: RE: [Modern] [new-work] WG Review: Managing, Ordering,
>How do we distinguish this problem from either device configuration, or
>network management, for which a number of solutions still exist?
>

---

From: Richard Shockey <[email-masked]>
Date: Wed, 01 Jul 2015 10:23:39 -0400

Thank you Keith. I completely agree. This charter it totally out of
control and the way this WG was formed isn¹t too great either.

On 7/1/15, 10:08 AM, "Modern on behalf of DRAGE, Keith (Keith)"
<[email-masked] on behalf of [email-masked]>
wrote:

>widely scoped that any issue that any network management issue involving
>a telephone number falls within the scope of the charter, whereas
>existing network management (or device configuration groups) should cover
>network management problems.
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 1 Jul 2015 14:54:44 +0000

I don't think anybody is proposing that legacy TDM systems do anything different from what they are doing today. However, almost all of these systems will transition to VoIP, in addition to the non-traditional providers that are emerging (the ones Cullen has mentioned, among others). The transition to VoLTE is on-going, as is the emphasis on end-to-end work flow automation (NFV, SDN, and whatever other keynote buzzword you care to list). A number of people have stated repeatedly that legacy interfaces will likely persist until the last TDM switch is turned into scrap metal and tooth fillings. But in the numbering space, we've always had multiple evolving interfaces (TCAP ROSE, SOAP and probably a number of proprietary web APIs, in addition to "protocols" like ftp'ing spreadsheets).

>From my limited experience, the notion that policy drives technology is too narrow. Often, available technology options drive policy options. Thus, having more technology options enables new policy choices (such as more user-friendly porting, better number utilization, competition, better use authentication [your example] or better NNI). The other way works, but it's usually very incremental tweaking, like the NANC-initiated change order process. There are exceptions, such as number porting, but they are tied to once-in-a-generation events like the 1996 Telecom Act in the US.

On a macro scale, this should be obvious: the availability of VoIP drove policy options; nobody said "we have policy needs, let's invent SIP".

Henning

-----Original Message-----
From: Modern [mailto:[email-masked]] On Behalf Of Richard Shockey
Sent: Wednesday, July 01, 2015 10:21 AM
To: Henning Schulzrinne; DRAGE, Keith (Keith)
Cc: [email-masked]
Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern)

Please fix one thing first. MARTINI did one thing and did it well. We opened the WG and closed it down in record time.

Discussions of device configuration frankly will go no where. Been there done that.  Vendor specific solutions have dominated that area for some time and will continue to do so. See RFC 6011 for another example of IETF epic failure.  No ENUM did not fail.  e164.apra failed. Contrary to popular opinion. The protocol is widely deployed is countless carrier networks in private carrier specific configurations.

I don¹t think number management will go very far at least for years.  Not because of regulatory concerns its just that the cost of the OSS/BSS systems in global carrier networks are so expensive and modifying them would cost more that the current US LNP database and no one is going there ever again. I could say some very very uncharitable things about the certain national numbering advisory committees but ...

Not to mention there is ample public statements that the incumbent carriers have no intention of spending one penny on anything involving reconfiguring existing TDM networks that continue to dominate the global voice market.

There is one thing that would be very useful.  A general purpose query response mechanism for STIR public keys. RFC 6116 and SIP Redirect have generally outlived their usefulness for countless reasons. Public key management and retrieval could deploy very quickly in modern SIP and mobile access networks (aka VoLTE) and actually solve a global public policy problem. If the mechanism works then it might possible to fold other use cases and numbering meta data into the structure as the voice networks evolve.. Of course it would be nice to see 4474bis finished up first. < hint Cullen :-) >

It might be useful for some folks around here to consider the actual reality of how carrier real time networks work not to mention the issues of CAPEX constraints on what is actually possible to deploy.

On 7/1/15, 9:29 AM, "Modern on behalf of Henning Schulzrinne"
<[email-masked] on behalf of [email-masked]> wrote:

>Indeed, it would be interesting to see whether and how Netconf/YANG 
>fits the requirements. I'm sure somebody will propose using DNS TXT records...
>
>Henning
>

---

From: "Gorman, Pierce A [CTO]" <[email-masked]>
Date: Wed, 1 Jul 2015 15:03:33 +0000

Alissa,

I've admitted before, I'm a novice at IETF procedures.  Your repeated use of the phrase "rough consensus" as a conclusion of fact caught my attention.  I wondered, is there any IETF accepted definitiion of "rough consensus" that Alissa and others are adhering to that I'm just not aware of?

A little research turned up an IETF.org document based on RFC 6722 Section 4.2 going into some detail on the topic of "Getting Things Done in a Working Group" at URL: https://www.ietf.org/tao.html#getting.things.done

I've copied-and-pasted the sentences from the beginning of the section that I think are particularly relevant to understanding the IETF "consensus" view on the definition of "rough consensus".

"One fact that confuses many novices is that the face-to-face WG meetings are much less important in the IETF than they are in most other organizations. Any decision made at a face-to-face meeting must also gain consensus on the WG mailing list. There are numerous examples of important decisions made in WG meetings that are later overturned on the mailing list, often because someone who couldn't attend the meeting pointed out a serious flaw in the logic used to come to the decision."

"The general rule on disputed topics is that the Working Group has to come to "rough consensus", meaning that a very large majority of those who care must agree."

"Rough consensus has been defined in many ways; a simple version is that it means that strongly held objections must be debated until most people are satisfied that these objections are wrong."

There is some more verbiage related to the use of a Working Group Last Call (WGLC), but it isn't clear if this is before or after chartering.  If its supposed to be done before, we skipped it I think.

The Tao is not a legalistic document based on rigid parlimentary procedures and there is what I will call a power of fiat within the IESG and the WG chairs, meaning they can basically ignore the definitions given above.

I can fully understand the anxiousness of many participants to end debate and just move on.  Code prototyping has already happened and available for review (based on request only and an undefined approval process).

Regardless, I have to ask, using the definitions of the IETF Tao, on what basis can it be claimed that "rough consensus" has been achieved for the MODERN charter?  From what I can tell it was the power of fiat.

Best regards,

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

From: Modern [mailto:[email-masked]] On Behalf Of Alissa Cooper
Sent: June 30, 2015 4:01 PM
To: [email-masked]
Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern)

I'd like to ask that each person participating in this discussion remember to be respectful of one another's points of view and focus on constructive dialogue. If you feel that you're wasting cycles on the current threads then feel free to change the subject to something more productive; likewise if you feel someone else is wasting your cycles, don't feel compelled to respond.

To review the process that got us to the current point:

The conclusion from the BoF in Dallas was that there was rough consensus in the room in support of forming the WG but that the charter and problem scope needed refinement (feel free to review the minutes: http://www.ietf.org/proceedings/92/minutes/minutes-92-modern). That process of refinement took place on this list over several months following the BoF. The charter was put out for review on June 12 with comments requested to be sent to the IESG by June 22. The IESG considered the two ITU-T related comments received (both after the deadline) and issued no blocking comments on the charter but asked that edits be considered on the basis of comments received. There were no other comments received or indications provided to the IESG about the readiness of this work for chartering. I'm still working on edits (Richard Hill pointed out that I missed his suggestions) and milestones are in the works as well. Thus this WG is being formed according to the usual process.

Alissa

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: "Gorman, Pierce A [CTO]" <[email-masked]>
Date: Wed, 1 Jul 2015 15:49:45 +0000

"On a macro scale, this should be obvious: the availability of VoIP drove policy options; nobody said "we have policy needs, let's invent SIP"."

SIP has certainly enjoyed the spotlight in terms of creating opportunities for policy (and carrier-grade security products).  It could be argued, however, very little policy specifically mentioning VoIP has been codified.

Perhaps the most meaningful telephone number and routing information management changes voluntarily achieved were the addition of four URI fields to NPAC, and a proposal currently under evaluation to do something similar for LERG.  These two simple changes may be sufficient within themselves to rapidly fascilitate an all-IP PSTN (in the US).

Numbering and routing information management policy changes with respect to non-traditional providers of VoIP and multimedia services are in-flight.

I've already said folks will agree that there is useful work to be done if that agreement is limited to how to automatically provision an IP PBX with a range of telephone numbers.  I'm not sure that requires a standard now or will ever.  But, if that is what was proposed, I feel more confident the proposal would reach more than "rough consensus".

I will heartily agree with Richard's suggestion that a non-DNS and non-SIP "general purpose query response mechanism" protocol investigation would be valuable.

Best regards,

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

-----Original Message-----
From: Modern [mailto:[email-masked]] On Behalf Of Henning Schulzrinne
Sent: July 01, 2015 9:55 AM
To: Richard Shockey; DRAGE, Keith (Keith)
Cc: [email-masked]
Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern)

Henning

---

From: Chris Wendt <[email-masked]>
Date: Wed, 1 Jul 2015 12:18:22 -0400

+1

Although i know it has always been part of the proposal for Modern, I’m sensing a shift in conversation or at least more of a segmentation for enterprise requirements vs. number administrator requirements.  Is there any sense that the charter can and does represent both of these use cases, and there is any reasonable outcome that there would be a largely common set of functionality for both?

Or is there two explicit requirements, and in my mind very different solutions, hence my previous question about the analogy to DNS and IP address allocation.

I would agree the enterprise requirements are fairly straight forward.  Entity A has a pool of telephone numbers they can provide some wholesale or transit relationship for and Entity B would like to provision and use those numbers.  This perhaps could benefit from a standardized interface, although i might argue that tropo and twilio and AT&T and others can differentiate their services based on better or worse interfaces (but that is a different discussion and maybe that’s a higher level interface than what would be defined here)

For the number administrator interface to those entities that are “governed” to be responsible for telephone numbers, there is a different set of requirements and a fuzzier path forward based on specific regulatory body rules and what needs to be enabled in that provisioning interface and registry database, specific to applying policy as part of the interface.  Above and beyond the fact that there is things like number portability and other things that may or may not be common to both use case.

To Martin’s point, unless there is clear requirements or a path to clear requirements, it is difficult to engineer a solution or at least one that would/could be adopted for either or both of the use cases.
Particularly if you are trying to address two at once.

Would definitely be interested in any clarification on the intent that i may have misunderstood or whether it is useful to clarify these and/or pick an explicit path towards one or the other.

> On Jul 1, 2015, at 10:12 AM, DOLLY, MARTIN C <[email-masked]> wrote:
>

---

From: "Dwight, Timothy M (Tim)" <[email-masked]>
Date: Wed, 1 Jul 2015 12:56:53 -0400

Chris's mail made me wonder about something.

Traditionally "end users" (individuals, Enterprises) have obtained telephone numbers as a byproduct of subscribing to some form of "telephony" service.  Hence it made sense that the provider of the service be the source of the number.  My reading of the current charter, and my observation of the presentations made by Jon and Henning in the Dallas IETF, lead me to believe MODERN will assume a different paradigm.  The tools the wg develops may be usable to support the above, but would also support a couple of new (to me at least) notions

a) separation of telephone number assignment from subscription to telecommunications services, and
b) relaxation of the "hierarchy" through which numbers are allocated today (e.g., NPA to traditional-SP to non-traditional-SP to Enterprise to desk phone).

Is that understanding correct?  

I have to say it comes more from Henning's "motivational" slides than from the charter itself.  So I'm not sure these are _the_ objectives, _some_possible_ objectives, or a misinterpretation on my part.  Apologies in advance if the latter is the case.

tim

-----Original Message-----
From: Modern [mailto:[email-masked]] On Behalf Of Chris Wendt
Sent: Wednesday, July 01, 2015 11:18 AM
To: DOLLY, MARTIN C
Cc: Ben Campbell; DRAGE, Keith (Keith); [email-masked]; Henning Schulzrinne
Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern)

+1

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 1 Jul 2015 12:26:46 -0700

This topic is complicated and there is not a perfect answer to what rough consensus is. I suspect that in this case it is formed by a combination of the views of people that were at the BOF and what has been expressed on email lists. Keep in mind a lot of people in that room expressed support for this. Some people have expressed issues on the email lists - many of theses being basically issues that were raised on the lists before the BOF or at BOF. 

Many IETF people I work with view rough consensus as a large percentage of the informed and relevant people agree - and the people with relevant objections have had a chance to convince others they are should object too (so they are informed). The position that debate will continue until everyone agrees is definitely not a viable definition for a SDO that is trying to get something done.

I realize that makes the process even less deterministic but I suspect most people at IETF would agree that my answer was at least part of rough consensus.  Part of the reason it is so hard to get a straight answer on this is the IETF keeps telling itself it does not vote though when you start describing how most of our important decisions are made, it starts to sound a bit like a vote. 

> On Jul 1, 2015, at 8:03 AM, Gorman, Pierce A [CTO] <[email-masked]> wrote:
> 
> Alissa,
>  
> I’ve admitted before, I’m a novice at IETF procedures.  Your repeated use of the phrase “rough consensus” as a conclusion of fact caught my attention.  I wondered, is there any IETF accepted definitiion of “rough consensus” that Alissa and others are adhering to that I’m just not aware of?
>  
> A little research turned up an IETF.org document based on RFC 6722 Section 4.2 going into some detail on the topic of “Getting Things Done in a Working Group” at URL: https://www.ietf.org/tao.html#getting.things.done
>  
> I’ve copied-and-pasted the sentences from the beginning of the section that I think are particularly relevant to understanding the IETF “consensus” view on the definition of “rough consensus”.
>  
> “One fact that confuses many novices is that the face-to-face WG meetings are much less important in the IETF than they are in most other organizations. Any decision made at a face-to-face meeting must also gain consensus on the WG mailing list. There are numerous examples of important decisions made in WG meetings that are later overturned on the mailing list, often because someone who couldn't attend the meeting pointed out a serious flaw in the logic used to come to the decision.”
>  
> “The general rule on disputed topics is that the Working Group has to come to "rough consensus", meaning that a very large majority of those who care must agree.”
>  
> “Rough consensus has been defined in many ways; a simple version is that it means that strongly held objections must be debated until most people are satisfied that these objections are wrong.”
>  
> There is some more verbiage related to the use of a Working Group Last Call (WGLC), but it isn’t clear if this is before or after chartering.  If its supposed to be done before, we skipped it I think.
>  
> Regardless, I have to ask, using the definitions of the IETF Tao, on what basis can it be claimed that “rough consensus” has been achieved for the MODERN charter?  From what I can tell it was the power of fiat.
>  
> Best regards,
>  
>  
> Pierce Gorman
> Core Network Planning
> O: 913-439-4368
> [email-masked]
>  
> I’d like to ask that each person participating in this discussion remember to be respectful of one another’s points of view and focus on constructive dialogue. If you feel that you’re wasting cycles on the current threads then feel free to change the subject to something more productive; likewise if you feel someone else is wasting your cycles, don’t feel compelled to respond.
>  
> The conclusion from the BoF in Dallas was that there was rough consensus in the room in support of forming the WG but that the charter and problem scope needed refinement (feel free to review the minutes: http://www.ietf.org/proceedings/92/minutes/minutes-92-modern). That process of refinement took place on this list over several months following the BoF. The charter was put out for review on June 12 with comments requested to be sent to the IESG by June 22. The IESG considered the two ITU-T related comments received (both after the deadline) and issued no blocking comments on the charter but asked that edits be considered on the basis of comments received. There were no other comments received or indications provided to the IESG about the readiness of this work for chartering. I’m still working on edits (Richard Hill pointed out that I missed his suggestions) and milestones are in the works as well. Thus this WG is being formed according to the usual process.
>  
> Alissa
> 
>

---

From: "Gorman, Pierce A [CTO]" <[email-masked]>
Date: Wed, 1 Jul 2015 19:51:57 +0000

In-line.

Pierce Gorman

[email-masked]

-----Original Message-----
From: Cullen Jennings [mailto:[email-masked]]
Sent: July 01, 2015 2:27 PM
To: Gorman, Pierce A [CTO]
Cc: Alissa Cooper; [email-masked]
Subject: Rough consensus - Re: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern)

This topic is complicated and there is not a perfect answer to what rough consensus is. I suspect that in this case it is formed by a combination of the views of people that were at the BOF and what has been expressed on email lists. Keep in mind a lot of people in that room expressed support for this.

PG->  I have no doubt “a lot of people in that room expressed support for this.”  However, the guidelines for defining and achieving rough consensus in RFC 6722 indicates, “face-to-face WG meetings are much less important in the IETF than they are in most other organizations. Any decision made at a face-to-face meeting must also gain consensus on the WG mailing list.”

Some people have expressed issues on the email lists - many of theses being basically issues that were raised on the lists before the BOF or at BOF.

Many IETF people I work with view rough consensus as a large percentage of the informed and relevant people agree - and the people with relevant objections have had a chance to convince others they are should object too (so they are informed).

PG->  Who decides whom is informed?  Who decides the membership of “relevant people”?  Not to be (too) impertinent, but any chance I can get a list of the irrelevant people and their irrelevant objections?  I think I can guess whom are the relevant people and their views.

The position that debate will continue until everyone agrees is definitely not a viable definition for a SDO that is trying to get something done.

PG->  Agree.  The guidelines the IETF adopted and published in RFC 6722 indicate complete agreement is not required.  Instead what is required is a “rough consensus” defined variously as “a very large majority of those who care must agree”, and “strongly held objections must be debated until most people are satisfied that these objections are wrong.”  My point is that from what I can tell these guidelines have been dismissed here.

> On Jul 1, 2015, at 8:03 AM, Gorman, Pierce A [CTO] <[email-masked]<mailto:[email-masked]>> wrote:

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

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

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

---

From: "Holmes, David W [CTO]" <[email-masked]>
Date: Wed, 1 Jul 2015 20:06:11 +0000

Cullen,

I believe the specific issue here is that the area of interest for MODERN, telephone number administration, is regarded generally in the industry as being at the margins of IETF influence, but is very mainstream in other industry organizations.  Therefore the balance of interests between the FtF attendees to the BoF & the participants on this reflector are somewhat skewed; specifically, the FtF will tend to be attended by IETF-centric parties, whereas the reflector population appears to more closely represent the organizations that have a demonstrated interest in TN administration.

I would also note that the highly parallel scheduling of the FtF meetings within the IETF meeting weeks can make it very difficult for organizations with light representation to be present at all those sessions that they would desire.  In this case the BoF was scheduled alongside other sessions that were of high interest to telcos, so Sprint, for one, could not be represented there.

So given these considerations, and thus weighting the FtF & reflector discussions, do we really feel that we have "a large number of informed & relevant people" agreeing to provide "rough consensus"?  (An entirely open question).

BR/David Holmes

---

From: Alissa Cooper <[email-masked]>
Date: Wed, 1 Jul 2015 13:41:45 -0700

Hi Pierce,

As you’ve discovered there is no normative definition of “rough consensus” in the IETF. There are informational descriptions in various places, some of which go on at length and may be interesting reading if you’re looking for different perspectives (e.g., RFC 7282). But there is no normative definition.

I will note that in my message that you quote below, I chose my words carefully. I said there was rough consensus in the room in Dallas in support of forming the WG, pending charter and scope edits. This is what was reported in the minutes, which I linked to. As I’ve noted before, I was not there in Dallas since I was on leave (and the audio recording for that portion is cut off unfortunately), but I trust that the minutes were reported correctly. Ben was shepherding this work until I came back from leave in June.

As Ben pointed out on this mailing list in April, there is no notion of WG consensus until there is a WG. The decision to form a WG certainly must be informed by the level of support demonstrated in the community for the work. But such decisions generally also take other factors into account, as reflected in the RFC 2418 questions and the BoF questions and answers listed in the minutes for this BoF. 

The decision to form a WG ultimately rests with the IESG, as Adam noted. The MODERN charter went before the IESG after several months of iterations and editing resulting from discussions on this list (some of which I see that you were involved in). As I noted in an earlier mail, the IESG asked for comments on the charter and did not receive a single one within the time frame requested. Two came in late and resulting edits are being worked into the charter. 

So to summarize, there was a BoF where rough consensus existed in the room to form the WG pending charter edits and where a sizable group of volunteers demonstrated interest in authoring and editing the documents, there were then many months of discussion on this list (which is open to all) about the viability of the WG and the scope of the charter, there was a standard charter review period conducted by the IESG that elicited comments from two commenters, one of whom objected on grounds that had been previously thoroughly discussed by participants on the list and in person, and the WG has now been approved for formation by the IESG pending further charter edits stemming from these comments. I have a hard time seeing how this equates to WG formation by fiat.  It certainly does not equate to unanimous support for the WG’s formation, but that has never been a requirement.

Lastly, I’m not sure what you mean by an “undefined approval process” for “code prototyping,” but I will note that the IETF has no role whatsoever in determining who decides to implement what, when, or how.

Cheers,
Alissa

On Jul 1, 2015, at 8:03 AM, Gorman, Pierce A [CTO] <[email-masked]> wrote:

> A little research turned up an IETF.org document based on RFC 6722 Section 4.2 going into some detail on the topic of “Getting Things Done in a Working Group” at URL:https://www.ietf.org/tao.html#getting.things.done
>

---

From: Alissa Cooper <[email-masked]>
Date: Wed, 1 Jul 2015 14:07:35 -0700

Further edits have been incorporated into the first and last paragraphs based on Richard Hill’s suggestions and resulting list discussion — <http://datatracker.ietf.org/doc/charter-ietf-modern/>. I think we’re at the point of diminishing returns at this point (especially considering Richard’s overall objection to this work moving forward in the IETF), so I will hit the approval button unless someone spots an error introduced in making the changes.

Alissa

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 1 Jul 2015 21:08:45 +0000

As you know, we already have somewhat varying assignment rules, in the US, for different classes of numbers, such as pANIs, toll free numbers, SMS short codes and "regular" numbers, among others. Some are tied to service, others not. (For example, RespOrgs for toll-free numbers don't have to provide transport/signaling services.)

Whether MODERN is applicable to any of these number spaces is a separate discussion; my point is mainly that there already is a separable authorization process that doesn't seem to influence the mechanics. As an example, a company has to go through a set of qualification steps to become a RespOrg and then gets handed credentials to interact with the SMS800 database.

But I'm not sure how this matters to the product of the working group. Clearly, there has to be a policy mechanism that says "you are authorized to request a number", where the qualifications are likely to be varying and enforced by contract or the national regulator. ("Contract" for the case where a carrier assigns numbers to one of its customers.) Unless you see some need to include the qualifications and their validation in the protocol, I don't see how this affects the protocol mechanics. In the US, for example, you'd need to get an OCN from NECA, and they require paperwork proving your status, but I don't think anybody is proposing that we design an automated applicant-to-NECA protocol that incorporates all the fields in https://www.neca.org/WorkArea/linkit.aspx?LinkIdentifier=id&ItemID=5419&libID=5439)

If OFCOM or the FCC wanted to hand numbers directly to hot dog vendors for some reason, I suspect giving them technical access to the respective existing numbering databases is the least of the problems. 

But I'm probably missing an important facet of the concern.

Henning

-----Original Message-----
From: Dwight, Timothy M (Tim) [mailto:[email-masked]] 
Sent: Wednesday, July 01, 2015 12:57 PM
To: Chris Wendt; DOLLY, MARTIN C
Cc: Ben Campbell; DRAGE, Keith (Keith); [email-masked]; Henning Schulzrinne
Subject: RE: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern)

tim

-----Original Message-----
From: Modern [mailto:[email-masked]] On Behalf Of Chris Wendt
Sent: Wednesday, July 01, 2015 11:18 AM
To: DOLLY, MARTIN C
Cc: Ben Campbell; DRAGE, Keith (Keith); [email-masked]; Henning Schulzrinne
Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern)

+1

---

From: Richard Shockey <[email-masked]>
Date: Wed, 01 Jul 2015 17:26:52 -0400

On 7/1/15, 3:26 PM, "Modern on behalf of Cullen Jennings"
<[email-masked] on behalf of [email-masked]> wrote:

>
>This topic is complicated and there is not a perfect answer to what rough
>consensus is. I suspect that in this case it is formed by a combination
>of the views of people that were at the BOF and what has been expressed
>on email lists. Keep in mind a lot of people in that room expressed
>support for this. Some people have expressed issues on the email lists -
>many of theses being basically issues that were raised on the lists
>before the BOF or at BOF.
>
>Many IETF people I work with view rough consensus as a large percentage
>of the informed and relevant people agree -

RS> And just who, pray tell, are those informed and relevant people? Is
there a club? Is there a secret handshake? :-) Just the people who can
afford to show up for BOF¹s?

IMHO there has been a bit of a rush to judgement (charter) before it was
clear that a full spectrum of informed and relevant people had been
consulted, especially those that would, by definition, have to implement
the, yet to be determined, protocols in question.

That said there is some consensus within the industry at large that, over
time, there is a problem with numbering administration especially as TDM
networks are transitioned but for the time being the problem is uniquely
confined to the North American context. As a purely practical matter a
charter that is this expansive is a recipe for a epic fail and that is NOT
in the best interest of anyone who is informed by the subject matter.

A productive discussion of how to limit the scope of a solution within the
charter without precluding is use by other metadata elements in the future
might produce progress. Pick one ..maybe two use cases.

Speaking from personal experience. 6116 and its predecessors was a epic
fail until some of us figured out it was just perfect for the retrieval of
LNP data that eliminated TCAP dips. I still have the baseball caps BTW! NO
TCAP.  After that it just took off like a rocket. Number allocation
protocols may prove difficult but starting to put in place the
infrastructure for E.164 public keys IMHO is not the use/business/policy
case is highly compelling.

>and the people with relevant objections have had a chance to convince
>others they are should object too (so they are informed). The position
>that debate will continue until everyone agrees is definitely not a
>viable definition for a SDO that is trying to get something done.
>
>I realize that makes the process even less deterministic but I suspect
>most people at IETF would agree that my answer was at least part of rough
>consensus.  Part of the reason it is so hard to get a straight answer on
>this is the IETF keeps telling itself it does not vote though when you
>start describing how most of our important decisions are made, it starts
>to sound a bit like a vote.
>
>
>> I¹ve admitted before, I¹m a novice at IETF procedures.  Your repeated
>>use of the phrase ³rough consensus² as a conclusion of fact caught my
>>attention.  I wondered, is there any IETF accepted definitiion of ³rough
>>consensus² that Alissa and others are adhering to that I¹m just not
>>aware of?
>>  
>> A little research turned up an IETF.org document based on RFC 6722
>>Section 4.2 going into some detail on the topic of ³Getting Things Done
>>in a Working Group² at URL:
>>https://www.ietf.org/tao.html#getting.things.done
>>  
>> I¹ve copied-and-pasted the sentences from the beginning of the section
>>that I think are particularly relevant to understanding the IETF
>>³consensus² view on the definition of ³rough consensus².
>>  
>> ³One fact that confuses many novices is that the face-to-face WG
>>meetings are much less important in the IETF than they are in most other
>>organizations. Any decision made at a face-to-face meeting must also
>>gain consensus on the WG mailing list. There are numerous examples of
>>important decisions made in WG meetings that are later overturned on the
>>mailing list, often because someone who couldn't attend the meeting
>>pointed out a serious flaw in the logic used to come to the decision.²
>>  
>> ³The general rule on disputed topics is that the Working Group has to
>>come to "rough consensus", meaning that a very large majority of those
>>who care must agree.²
>>  
>> ³Rough consensus has been defined in many ways; a simple version is
>>that it means that strongly held objections must be debated until most
>>people are satisfied that these objections are wrong.²
>>  
>> There is some more verbiage related to the use of a Working Group Last
>>Call (WGLC), but it isn¹t clear if this is before or after chartering.
>>If its supposed to be done before, we skipped it I think.
>>  
>> The Tao is not a legalistic document based on rigid parlimentary
>>procedures and there is what I will call a power of fiat within the IESG
>>and the WG chairs, meaning they can basically ignore the definitions
>>given above.
>>  
>> I can fully understand the anxiousness of many participants to end
>>debate and just move on.  Code prototyping has already happened and
>>available for review (based on request only and an undefined approval
>>process).
>>  
>> Regardless, I have to ask, using the definitions of the IETF Tao, on
>>what basis can it be claimed that ³rough consensus² has been achieved
>>for the MODERN charter?  From what I can tell it was the power of fiat.
>>  
>> Best regards,
>>  
>>  
>> Pierce Gorman
>> Core Network Planning
>> O: 913-439-4368
>> [email-masked]
>>  
>> I¹d like to ask that each person participating in this discussion
>>remember to be respectful of one another¹s points of view and focus on
>>constructive dialogue. If you feel that you¹re wasting cycles on the
>>current threads then feel free to change the subject to something more
>>productive; likewise if you feel someone else is wasting your cycles,
>>don¹t feel compelled to respond.
>>  
>> The conclusion from the BoF in Dallas was that there was rough
>>consensus in the room in support of forming the WG but that the charter
>>and problem scope needed refinement (feel free to review the minutes:
>>http://www.ietf.org/proceedings/92/minutes/minutes-92-modern). That
>>process of refinement took place on this list over several months
>>following the BoF. The charter was put out for review on June 12 with
>>comments requested to be sent to the IESG by June 22. The IESG
>>considered the two ITU-T related comments received (both after the
>>deadline) and issued no blocking comments on the charter but asked that
>>edits be considered on the basis of comments received. There were no
>>other comments received or indications provided to the IESG about the
>>readiness of this work for chartering. I¹m still working on edits
>>(Richard Hill pointed out that I missed his suggestions) and milestones
>>are in the works as well. Thus this WG is being formed according to the
>>usual process.
>>  
>> Alissa
>> 
>> 
>>are not the intended recipient, please contact the sender and delete all
>>copies of the message.

---

From: Richard Shockey <[email-masked]>
Date: Wed, 01 Jul 2015 17:48:31 -0400

On 7/1/15, 5:08 PM, "Modern on behalf of Henning Schulzrinne"
<[email-masked] on behalf of [email-masked]> wrote:

>As you know, we already have somewhat varying assignment rules, in the
>US, for different classes of numbers, such as pANIs, toll free numbers,
>SMS short codes and "regular" numbers, among others. Some are tied to
>service, others not. (For example, RespOrgs for toll-free numbers don't
>have to provide transport/signaling services.)

RS> The word that always comes to mind is fustercluck. That said the US is
infinitely better that some nameless jurisdictions re numbering. That
would have been a great WG name. Where is Hadriel Kaplan when we need him.

>
>Whether MODERN is applicable to any of these number spaces is a separate
>discussion; my point is mainly that there already is a separable
>authorization process that doesn't seem to influence the mechanics. As an
>example, a company has to go through a set of qualification steps to
>become a RespOrg and then gets handed credentials to interact with the
>SMS800 database.
>
>But I'm not sure how this matters to the product of the working group.
>Clearly, there has to be a policy mechanism that says "you are authorized
>to request a number", where the qualifications are likely to be varying
>and enforced by contract or the national regulator. ("Contract" for the
>case where a carrier assigns numbers to one of its customers.) Unless you
>see some need to include the qualifications and their validation in the
>protocol, I don't see how this affects the protocol mechanics. In the US,
>for example, you'd need to get an OCN from NECA, and they require
>paperwork proving your status, but I don't think anybody is proposing
>that we design an automated applicant-to-NECA protocol that incorporates
>all the fields in 
>https://www.neca.org/WorkArea/linkit.aspx?LinkIdentifier=id&ItemID=5419&li
>bID=5439)

RS> So Henning pick two use cases. Something that can deploy fast and
something that might take time.

>
>If OFCOM or the FCC wanted to hand numbers directly to hot dog vendors
>for some reason, I suspect giving them technical access to the respective
>existing numbering databases is the least of the problem.
> 
>

RS> Obviously in the case of hot dog vendors you must exclude from the FCC
model any hot dog vendor that serves ketchup. That said having actually
read the relevant R&O hot dog vendors could certainly offer VoIP services
with their mustard and kraut if they can provide the relevant NRUF
reporting, USF contributions, 911 services etc.

>Traditionally "end users" (individuals, Enterprises) have obtained
>telephone numbers as a byproduct of subscribing to some form of
>"telephony" service.  Hence it made sense that the provider of the
>service be the source of the number.  My reading of the current charter,
>and my observation of the presentations made by Jon and Henning in the
>Dallas IETF, lead me to believe MODERN will assume a different paradigm.
>The tools the wg develops may be usable to support the above, but would
>also support a couple of new (to me at least) notions
>
>b) relaxation of the "hierarchy" through which numbers are allocated
>today (e.g., NPA to traditional-SP to non-traditional-SP to Enterprise to
>desk phone).
>
>I have to say it comes more from Henning's "motivational" slides than
>from the charter itself.  So I'm not sure these are _the_ objectives,
>_some_possible_ objectives, or a misinterpretation on my part.  Apologies
>in advance if the latter is the case.
>
>tim
>
>
>
>Although i know it has always been part of the proposal for Modern, I¹m
>sensing a shift in conversation or at least more of a segmentation for
>enterprise requirements vs. number administrator requirements.  Is there
>any sense that the charter can and does represent both of these use
>cases, and there is any reasonable outcome that there would be a largely
>common set of functionality for both?
>
>Or is there two explicit requirements, and in my mind very different
>solutions, hence my previous question about the analogy to DNS and IP
>address allocation.
>
>I would agree the enterprise requirements are fairly straight forward.
>Entity A has a pool of telephone numbers they can provide some wholesale
>or transit relationship for and Entity B would like to provision and use
>those numbers.  This perhaps could benefit from a standardized interface,
>although i might argue that tropo and twilio and AT&T and others can
>differentiate their services based on better or worse interfaces (but
>that is a different discussion and maybe that¹s a higher level interface
>than what would be defined here)
>
>For the number administrator interface to those entities that are
>³governed² to be responsible for telephone numbers, there is a different
>set of requirements and a fuzzier path forward based on specific
>regulatory body rules and what needs to be enabled in that provisioning
>interface and registry database, specific to applying policy as part of
>the interface.  Above and beyond the fact that there is things like
>number portability and other things that may or may not be common to both
>use case.
>
>To Martin¹s point, unless there is clear requirements or a path to clear
>requirements, it is difficult to engineer a solution or at least one that
>would/could be adopted for either or both of the use cases.
>Would definitely be interested in any clarification on the intent that i
>may have misunderstood or whether it is useful to clarify these and/or
>pick an explicit path towards one or the other.
>
>
>> A builder needs to know what he is building in order to ensure that he
>>has the correct tools in his tool box....
>> 
>> To move the discussion forward, rather than cycling back to invoking
>>the terms, I'd be interested in hearing which requirements, precisely
>>and concretely, are likely to depend on policy and regulation.
>> 
>> Everybody has iterated again and again that the "who can get what" part
>>definitely does, but that's outside the protocol mechanism, just like
>>"who can see what web page" or "who can place what SIP call" is beyond
>>the concern of HTTP or SIP, beyond providing an authentication mechanism
>>that allows to associate a policy with a principal.
>> 
>> But this is the root of the issue here, the requirements for such a
>>solution is based on policy and regulation, that does not exist , yet....
>>

---

From: "McGarry, Tom" <[email-masked]>
Date: Wed, 1 Jul 2015 22:20:26 +0000

Number assignment is done today without a subscription to a communications
service.  Numbers are allocated to carriers and carriers use that
inventory to assign to users as they sign up for subscriptions.  There are
lots of allocated numbers without subscriptions.  I could envision a
scenario where a user gets a number from an administrator before they have
enabled a communications service on that number.  But just like today I
would expect the administration process to expect to see service enabled
at some time and reclaim it if it not.  I could also see processes that
either require a subscription before getting the TN or require a short
timeframe between acquisition and service enablement.  As stated in the
charter, solutions need to be flexible enough to accommodate different
policies.    

As to your other question, I see modern enabling different administration
models than are common today.

Recently in the US the FCC issued an order that said VoIP providers
(companies that are not regulatory recognized telecommunications service
providers) can be assigned numbers directly by the administrator.  The
VoIP providers will still rely on TSPs for PSTN interconnection and
transport.  This is a perfect example of a scenario that modern would
address - a protocol mechanism that would facilitate the interactions of
the administrator, the TSP and the VoIP provider.

On 7/1/15 12:56 PM, "Dwight, Timothy M (Tim)" <[email-masked]>
wrote:

>>https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman
>>_listinfo_modern&d=AwIGaQ&c=MOptNlVtIETeDALC_lULrw&r=4Klm32iB7HufveeIDcLe
>>xtZ1ooNcfp01IYIaVqsORjI&m=FP40Nrq8w87FyQLovMYZxVUOiK32GshZtdzgS2HObuQ&s=C
>>HlbePlLP6JQrESwZaaVhXaqG52HfAUyqaa8ikelPKM&e=
>
>
>
>https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_
>listinfo_modern&d=AwIGaQ&c=MOptNlVtIETeDALC_lULrw&r=4Klm32iB7HufveeIDcLext
>Z1ooNcfp01IYIaVqsORjI&m=FP40Nrq8w87FyQLovMYZxVUOiK32GshZtdzgS2HObuQ&s=CHlb
>ePlLP6JQrESwZaaVhXaqG52HfAUyqaa8ikelPKM&e=
>
>https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_
>listinfo_modern&d=AwIGaQ&c=MOptNlVtIETeDALC_lULrw&r=4Klm32iB7HufveeIDcLext
>Z1ooNcfp01IYIaVqsORjI&m=FP40Nrq8w87FyQLovMYZxVUOiK32GshZtdzgS2HObuQ&s=CHlb
>ePlLP6JQrESwZaaVhXaqG52HfAUyqaa8ikelPKM&e=

---

From: "McGarry, Tom" <[email-masked]>
Date: Wed, 1 Jul 2015 22:55:57 +0000

The charter does cover at least both scenarios you mention - "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 identity protocol mechanisms
to support the interactions between the functions defined by the
framework."

The information related to a TN - subscriber, service, service provider,
service address, etc. - is relatively finite.  I would expect information
exchanged between retail-wholesale to be somewhat different than that
between wholesale-administrator, but they're in the same ballpark.
Solving both should not be too difficult.

And as I stated elsewhere, the solutions are expected to be flexible to
account for different policies.  So information exchanged under one
policy, may not be the same information exchanged under another policy.
But the WG should capture the superset.

On 7/1/15 12:18 PM, "Chris Wendt" <[email-masked]> wrote:

>>xtZ1ooNcfp01IYIaVqsORjI&m=9uORpP0hGzE9S4A7IIpCY9PNWn06UsCjQ10ngvDS1xE&s=n
>>FOf9-sTlWhwYP4Jid7VSqlTJqv0vHfn3TE9ueNAF7o&e=
>
>Z1ooNcfp01IYIaVqsORjI&m=9uORpP0hGzE9S4A7IIpCY9PNWn06UsCjQ10ngvDS1xE&s=nFOf
>9-sTlWhwYP4Jid7VSqlTJqv0vHfn3TE9ueNAF7o&e=

---

From: "Richard Hill" <[email-masked]>
Date: Thu, 2 Jul 2015 01:31:31 +0200

Dear Alissa,

Thank you for this. The new version of the charter accommodates my
suggestions, and those of others, so I'm happy with it.

My objection was mostly because I feared that the charter would allow the
group to stray unwittingly into areas that are politically sensitive because
of regulatory frameworks. But I think that this is unlikely under the new
charter, so I am hereby withdrawing my objection.

I trust that you will communicate the withdrawal of my objection, if
appropriate, to the IESG.

Thank you very much for your careful and thoughtful considerations of all
the comments.

Best,

Richard

From: Modern [mailto:[email-masked]] On Behalf Of Alissa Cooper
Sent: Wednesday, July 1, 2015 23:08
To: McGarry, Tom
Cc: [email-masked]
Subject: Re: [Modern] charter edits

Further edits have been incorporated into the first and last paragraphs
based on Richard Hill's suggestions and resulting list discussion -
<http://datatracker.ietf.org/doc/charter-ietf-modern/>. I think we're at the
point of diminishing returns at this point (especially considering Richard's
overall objection to this work moving forward in the IETF), so I will hit
the approval button unless someone spots an error introduced in making the
changes.

Alissa

---

From: "DOLLY, MARTIN C" <[email-masked]>
Date: Wed, 1 Jul 2015 23:43:09 +0000

Tom

Almost all you stated is policy/regulatory requirements. Did you read the FCC order?
Where are numbers being assigned to individuals?

Martin

Sent from my iPhone

> On Jul 1, 2015, at 6:20 PM, McGarry, Tom <[email-masked]> wrote:
>

---

From: "Richard Hill" <[email-masked]>
Date: Thu, 2 Jul 2015 01:49:17 +0200

Sorry for responding to this late but, as Alissa has already pointed out,
RFC 7282 provides a pretty detailed discussion of consensus in IETF, see:

  http://www.rfc-editor.org/rfc/rfc7282.txt 

Best,

Richard

From: Modern [mailto:[email-masked]] On Behalf Of Gorman, Pierce A
[CTO]
Sent: Wednesday, July 1, 2015 17:04
To: Alissa Cooper; [email-masked]
Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering,
Distributing, Exposing, & Registering telephone Numbers (modern)

Alissa,

I've admitted before, I'm a novice at IETF procedures.  Your repeated use of
the phrase "rough consensus" as a conclusion of fact caught my attention.  I
wondered, is there any IETF accepted definitiion of "rough consensus" that
Alissa and others are adhering to that I'm just not aware of?

A little research turned up an IETF.org document based on RFC 6722 Section
4.2 going into some detail on the topic of "Getting Things Done in a Working
Group" at URL: https://www.ietf.org/tao.html#getting.things.done

I've copied-and-pasted the sentences from the beginning of the section that
I think are particularly relevant to understanding the IETF "consensus" view
on the definition of "rough consensus".

"One fact that confuses many novices is that the face-to-face WG meetings
are much less important in the IETF than they are in most other
organizations. Any decision made at a face-to-face meeting must also gain
consensus on the WG mailing list. There are numerous examples of important
decisions made in WG meetings that are later overturned on the mailing list,
often because someone who couldn't attend the meeting pointed out a serious
flaw in the logic used to come to the decision."

"The general rule on disputed topics is that the Working Group has to come
to "rough consensus", meaning that a very large majority of those who care
must agree."

"Rough consensus has been defined in many ways; a simple version is that it
means that strongly held objections must be debated until most people are
satisfied that these objections are wrong."

There is some more verbiage related to the use of a Working Group Last Call
(WGLC), but it isn't clear if this is before or after chartering.  If its
supposed to be done before, we skipped it I think.

The Tao is not a legalistic document based on rigid parlimentary procedures
and there is what I will call a power of fiat within the IESG and the WG
chairs, meaning they can basically ignore the definitions given above.

I can fully understand the anxiousness of many participants to end debate
and just move on.  Code prototyping has already happened and available for
review (based on request only and an undefined approval process).

Regardless, I have to ask, using the definitions of the IETF Tao, on what
basis can it be claimed that "rough consensus" has been achieved for the
MODERN charter?  From what I can tell it was the power of fiat.

Best regards,

Pierce Gorman

Core Network Planning

O: 913-439-4368

[email-masked]

I'd like to ask that each person participating in this discussion remember
to be respectful of one another's points of view and focus on constructive
dialogue. If you feel that you're wasting cycles on the current threads then
feel free to change the subject to something more productive; likewise if
you feel someone else is wasting your cycles, don't feel compelled to
respond.

The conclusion from the BoF in Dallas was that there was rough consensus in
the room in support of forming the WG but that the charter and problem scope
needed refinement (feel free to review the minutes:
http://www.ietf.org/proceedings/92/minutes/minutes-92-modern). That process
of refinement took place on this list over several months following the BoF.
The charter was put out for review on June 12 with comments requested to be
sent to the IESG by June 22. The IESG considered the two ITU-T related
comments received (both after the deadline) and issued no blocking comments
on the charter but asked that edits be considered on the basis of comments
received. There were no other comments received or indications provided to
the IESG about the readiness of this work for chartering. I'm still working
on edits (Richard Hill pointed out that I missed his suggestions) and
milestones are in the works as well. Thus this WG is being formed according
to the usual process.

Alissa

  _____  

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: Chris Wendt <[email-masked]>
Date: Thu, 2 Jul 2015 10:00:03 -0400

If the push is toward a single extensible protocol/interface, because there is so many different owner/consumer scenarios and use-cases and different regulatory environments we will end up spending years defining 10’s or 100’s of “modern” profiles to extend the base spec.

Hmm… sounds familiar.

> On Jul 1, 2015, at 6:55 PM, McGarry, Tom <[email-masked]> wrote:
>

---

From: "Dwight, Timothy M (Tim)" <[email-masked]>
Date: Thu, 2 Jul 2015 10:11:48 -0400

Tom,

My first statement was specifically about how "end users" obtain telephone numbers.  Your response addresses how service providers obtain telephone numbers.  The two are orthogonal.

The scenario you envision ("a user gets a number from an administrator before they have enabled a communications service on that number") is more what I was asking about.  It's useful to hear concrete ideas, even if they're just examples of the types of capability we intend to enable.  To make progress we need to get beyond vague statements about supporting "a wide range of policies" and generate actual use cases.

I will also note that this scenario raises regulatory / policy concerns.  But still I thank you for describing it.  In my opinion any non-trivial use case will raise such concerns.  In the end we need requirements in order to judge proposed solutions, and we need use cases to drive those requirements.  The fact that a use case has policy implications should not IMHO eliminate it from consideration, but it's a factor.

Final point... to discuss use cases intelligently we need the "numbering SMEs" to actively participate.  To get that we have to bring this discussion down out of the clouds... as long as we're talking in generalities ("wide range of policies..."), you won't hear from them.  The ones in my company, at any rate, are baffled.

Tim

-----Original Message-----
From: Modern [mailto:[email-masked]] On Behalf Of McGarry, Tom
Sent: Wednesday, July 01, 2015 5:20 PM
To: [email-masked]
Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern)

Number assignment is done today without a subscription to a communications service.  Numbers are allocated to carriers and carriers use that inventory to assign to users as they sign up for subscriptions.  There are lots of allocated numbers without subscriptions.  I could envision a scenario where a user gets a number from an administrator before they have enabled a communications service on that number.  But just like today I would expect the administration process to expect to see service enabled at some time and reclaim it if it not.  I could also see processes that either require a subscription before getting the TN or require a short timeframe between acquisition and service enablement.  As stated in the charter, solutions need to be flexible enough to accommodate different
policies.    

As to your other question, I see modern enabling different administration models than are common today.

Recently in the US the FCC issued an order that said VoIP providers (companies that are not regulatory recognized telecommunications service
providers) can be assigned numbers directly by the administrator.  The VoIP providers will still rely on TSPs for PSTN interconnection and transport.  This is a perfect example of a scenario that modern would address - a protocol mechanism that would facilitate the interactions of the administrator, the TSP and the VoIP provider.

On 7/1/15 12:56 PM, "Dwight, Timothy M (Tim)" <[email-masked]>
wrote:

>service be the source of the number.  My reading of the current 
>charter, and my observation of the presentations made by Jon and 
>Henning in the Dallas IETF, lead me to believe MODERN will assume a different paradigm.
>today (e.g., NPA to traditional-SP to non-traditional-SP to Enterprise 
>to desk phone).
>
>
>
>_some_possible_ objectives, or a misinterpretation on my part.  
>Apologies in advance if the latter is the case.
>
>
>
>tim
>
>
>
>
>
>
>
>enterprise requirements vs. number administrator requirements.  Is 
>there any sense that the charter can and does represent both of these 
>use cases, and there is any reasonable outcome that there would be a 
>largely common set of functionality for both?
>
>
>
>Entity A has a pool of telephone numbers they can provide some 
>wholesale or transit relationship for and Entity B would like to 
>provision and use those numbers.  This perhaps could benefit from a 
>standardized interface, although i might argue that tropo and twilio 
>and AT&T and others can differentiate their services based on better or 
>worse interfaces (but that is a different discussion and maybe that¹s a 
>higher level interface than what would be defined here)
>
>
>
>³governed² to be responsible for telephone numbers, there is a 
>different set of requirements and a fuzzier path forward based on 
>specific regulatory body rules and what needs to be enabled in that 
>provisioning interface and registry database, specific to applying 
>policy as part of the interface.  Above and beyond the fact that there 
>is things like number portability and other things that may or may not 
>be common to both use case.
>
>
>
>To Martin¹s point, unless there is clear requirements or a path to 
>clear requirements, it is difficult to engineer a solution or at least 
>one that would/could be adopted for either or both of the use cases.
>
>Would definitely be interested in any clarification on the intent that 
>i may have misunderstood or whether it is useful to clarify these 
>and/or pick an explicit path towards one or the other.
>
>
>
>
>
>> A builder needs to know what he is building in order to ensure that 
>>he has the correct tools in his tool box....
>
>> 
>
>> Everybody has iterated again and again that the "who can get what" 
>>part definitely does, but that's outside the protocol mechanism, just 
>>like "who can see what web page" or "who can place what SIP call" is 
>>beyond the concern of HTTP or SIP, beyond providing an authentication 
>>mechanism that allows to associate a policy with a principal.
>
>> 
>
>>xtZ1ooNcfp01IYIaVqsORjI&m=FP40Nrq8w87FyQLovMYZxVUOiK32GshZtdzgS2HObuQ&
>>s=C HlbePlLP6JQrESwZaaVhXaqG52HfAUyqaa8ikelPKM&e=
>
>
>
>Z1ooNcfp01IYIaVqsORjI&m=FP40Nrq8w87FyQLovMYZxVUOiK32GshZtdzgS2HObuQ&s=C
>Hlb ePlLP6JQrESwZaaVhXaqG52HfAUyqaa8ikelPKM&e=
>
>Z1ooNcfp01IYIaVqsORjI&m=FP40Nrq8w87FyQLovMYZxVUOiK32GshZtdzgS2HObuQ&s=C
>Hlb ePlLP6JQrESwZaaVhXaqG52HfAUyqaa8ikelPKM&e=

---

From: Richard Shockey <[email-masked]>
Date: Thu, 02 Jul 2015 10:34:53 -0400

IMHO that would not be a good idea.

‹ 
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

From:  Modern <[email-masked]> on behalf of Alissa Cooper
<[email-masked]>
Date:  Wednesday, July 1, 2015 at 5:07 PM
To:  "McGarry, Tom" <[email-masked]>
Cc:  "[email-masked]" <[email-masked]>
Subject:  Re: [Modern] charter edits

Further edits have been incorporated into the first and last paragraphs
based on Richard Hill¹s suggestions and resulting list discussion ‹
<http://datatracker.ietf.org/doc/charter-ietf-modern/>. I think we¹re at the
point of diminishing returns at this point (especially considering Richard¹s
overall objection to this work moving forward in the IETF), so I will hit
the approval button unless someone spots an error introduced in making the
changes.

Alissa  

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 2 Jul 2015 15:02:29 +0000

Can you enumerate, roughly, the spectrum you have in mind? In our implementation, we (my two grad students and I) looked at a range of options and existing databases (including the LERG) and found this all pretty manageable.

Generally, we divided the elements "attached" to each number (or block, although we decided for simplicity to avoid dealing with blocks since you then have to worry about block-common and number-specific properties) into a set of broad categories:

* who (the entity being assigned, identified by a carrier code or some other opaque identifier that leads to a record identifying an entity), with two levels (equivalent to OCN and altSPID).

* reachability (URL)

* security (certificates, porting PIN)

* properties (media, service type, ...)

Fortunately, we have decades of precedent we can draw on, given the well-established databases.

As you said, I think we can make more progress if everybody enumerates specific issues or examples, rather than raising general concerns.

>From my experience in the SIP space, adding informational content to a protocol is easy (mainly syntax and registration); things that change the protocol flow are harder.

Henning

________________________________________
From: Modern [[email-masked]] on behalf of Chris Wendt [[email-masked]]
Sent: Thursday, July 02, 2015 10:00 AM
To: McGarry, Tom
Cc: Modern List
Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern)

Hmm… sounds familiar.

---

From: "Gorman, Pierce A [CTO]" <[email-masked]>
Date: Thu, 2 Jul 2015 15:08:07 +0000

Based on the different use case suggestions and comments of "legacy databases" being "interfaces" into whatever MODERN creates, it seems the idea is to create a super-database data model(s) and protocol(s) to enable "options that bypass" the problems an NRA encounters employing conventional policy approaches to updating regulated telecommunications infrastructure.

Why don't we speak plainly?  In the US, there is a perception that LERG and NPAC, etc., are not the best data model and protocols for managing telephone numbers and routing information for those numbers.  (Who doesn't love TP4 and CMIS/CMIP?)

OK.  No heartburn with that view.   One of the things that the SIP Forum/ATIS Joint Task Force has worked on is different models for managing routing information including a proposal for a monolithic per-TN URI database ostensibly achieving what LERG and NPAC having URI fields will do.

What this illustrated was that whether the databases are centralized or distributed doesn't inhibit policy and that numbering and routing folks embrace thinking outside the "legacy" box.

Another output of the JTF work was a focus on a "Tiered ENUM" proposal which presents interesting operational challenges and highlighted the value (again) of developing something better than DNS for telecommunications routing query and response which is why I enthusiastically embraced Richard Shockey's comments on this yesterday.

Routing multimedia services could be greatly optimized if there were more and better information available in both the query and the response.  E.g., if terminating number has media attributes which the origination does not support, route through transcoding media anchor, otherwise use optimized TrFO fast path.

If the basic thrust of MODERN is to get to a new and better number administration and routing information data model, can we not plainly say that, and add a charter item to develop a non-SIP and non-DNS query response protocol in support of that model?  (It will still encounter all sorts of policy questions, but at least it will be easier to talk about what we're trying to accomplish.)

Best regards,

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

-----Original Message-----
From: Modern [mailto:[email-masked]] On Behalf Of Dwight, Timothy M (Tim)
Sent: July 02, 2015 9:12 AM
To: McGarry, Tom; [email-masked]
Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern)

Tom,

Tim

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 2 Jul 2015 15:43:52 +0000

Thank you for moving towards more specificity. Reachability and properties do indeed seem like important facets of this problem (see my other note on our experimental sandbox). One of the questions is whether a generic (HTTP?) query protocol should be specialized to just retrieve the URL or if this a sufficiently important and different case to warrant a completely different mechanism.

Henning

________________________________________
From: Modern [[email-masked]] on behalf of Gorman, Pierce A [CTO] [[email-masked]]
Sent: Thursday, July 02, 2015 11:08 AM
To: Dwight, Timothy M (Tim); McGarry, Tom; [email-masked]
Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern)

Best regards,

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

---

From: "Gorman, Pierce A [CTO]" <[email-masked]>
Date: Thu, 2 Jul 2015 16:25:27 +0000

Agreed wrt HTTP.

Media/Service attributes, and services associated with a number (URIs only?) seem like the most pertinent categories of interest.

And wrt Joe's Hot Dog Stand as a use case, should count on Joe wanting multiple numbers to more easily differentiate service configuration for multiple personal communications services identities; business, personal, social, etc., which begs the policy question of NRUF-like enforcement.

Best regards,

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

-----Original Message-----
From: Henning Schulzrinne [mailto:[email-masked]]
Sent: July 02, 2015 10:44 AM
To: Gorman, Pierce A [CTO]; [email-masked]
Subject: RE: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern)

Henning

Best regards,

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

---

From: Chris Wendt <[email-masked]>
Date: Thu, 2 Jul 2015 12:30:15 -0400

I agree and we are going through a similar exercise in the context of the ATIS testbed.

As you said, the technology is easy.

The premise of my concern was assuming that number administration in various countries, wholesale, transit, centrex, PBXs, security industry, cars, IoT in general, etc. would all have their own twist on requirements and “registry” data models.  

A point I have stated before that typically in the HTTP/REST world, the usual solution is for the provider to simply provide a customized proprietary interface.  That model often is preferred because it’s infinitely extensible and competitors are free to implement cool features and functionality that attract continued usage and business.  There is no consensus needed, because if you provide a crappy interface, you are out of business.  Innovation happens much more quickly because it’s a competitive environment and nobody is beholden to a limited interface that takes years to evolve.  I see very few cases that a standardized REST interface has made any traction, because typically it represents the least common denominator of functionality, and changing the hooks from one API provider to another is typically an exercise measured in days and worst case weeks, so it’s not much of an issue.

I think, if I am interpreting your point, is that the telephone number scope is fairly limited, there is only so much you can do with a telephone number and data that needs to be associated with it.  Perhaps, in the end, the argument is, there is so little value or extensitbility someone can associate with an interface for allocation of numbers, so let’s just provide a standard interface and call it a day.

On the telephone administration part, when you get to regulatory requirements of securing, managing, protecting the telephone number allocation process.  Incorporating a distributed database functionality to allow for multiple participants in the distribution of telephone number data and ability to change entries and allocate numbers and port them from provider to provider.  I think we are on a whole new plane of requirements and functionality, which bears very little resemblance to the core functionality of allocating a telephone number to a database.

And the potential for those rules and procedures to be different for either different regulatory bodies and certainly would be true of new private or public numbering administrators, etc.

Maybe I’m wrong, and these things from policy point of view can be separated, and only the core tools remain, but i think it would be a big stretch personally.  And i think the more efficient path is just to design the interface with the policies and procedures as first class requirements in the interface directly.  

The technology, building the interface and database is easy, applying policy around the interface is the hard part.  And not that Modern isn’t up for the challenge, but agreement on how the policy part is incorporated or even referenced in the charter seems to be getting in the way.

In either case, i don’t disagree with the fact that i am spouting general concerns and not providing specific examples, and maybe that point is moot for now, so i’ll shut up for a while.

> On Jul 2, 2015, at 11:02 AM, Henning Schulzrinne <[email-masked]> wrote:
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 2 Jul 2015 17:58:57 +0000

At least based on my implementation, the distributed model isn't THAT hard and has use cases, as discussed.

Standardization works when you have a reasonably large of users on both "sides"; the dominant API model works if there are relatively few users (with long-term stable relationships) where writing custom code is not a big deal. Particularly given recent movements towards protecting "APIs" as copyrightable, there's value in open interfaces. We won't know if people will use them, but we'll never find out if we don't try.

________________________________________
From: Chris Wendt [[email-masked]]
Sent: Thursday, July 02, 2015 12:30 PM
To: Henning Schulzrinne
Cc: McGarry, Tom; Modern List
Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern)

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 2 Jul 2015 18:01:50 +0000

There are two known ways to deal with scarcity (and avoid waste): administrative (make rules that ensure "use it or lose it") and economical ("pay for it"). I don't think we need to solve this here, but you wouldn't be surprised that relevant folks are well aware of the trade-offs, given a rich history across identifiers, radio spectrum and non-network resources.

________________________________________
From: Gorman, Pierce A [CTO] [[email-masked]]
Sent: Thursday, July 02, 2015 12:25 PM
To: Henning Schulzrinne; [email-masked]
Subject: RE: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern)

Agreed wrt HTTP.

Best regards,

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

-----Original Message-----
From: Henning Schulzrinne [mailto:[email-masked]]
Sent: July 02, 2015 10:44 AM
To: Gorman, Pierce A [CTO]; [email-masked]
Subject: RE: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern)

Henning

Best regards,

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

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 2 Jul 2015 11:41:46 -0700

> On Jul 1, 2015, at 1:06 PM, Holmes, David W [CTO] <[email-masked]> wrote:
> 
> Cullen,
> 

That makes sense and this situation comes up fairly often at IETF where some of the stakeholders are not at the meetings for wide range or reasons. I think that is why it's critical to consider the input from mailing lists - and I assume that is happening - but input provided at the meeting is also relevant and needs to be considered. 

> So given these considerations, and thus weighting the FtF & reflector discussions, do we really feel that we have "a large number of informed & relevant people" agreeing to provide "rough consensus…

Ignoring rough consensus here ... my personal observation would be it seems there are a bunch of people from relevant communities interested in spending some time discussing problems and solutions in this general space. There are proof points that at least some of the simpler version of the problem can be solved - this does not mean we should use them, they are just an existence proof that at least some of the problems can be solved. There seem to be a fair number of people that might use the solutions if the IETF standardized them. Do we agree on the exact solution - no. Do we even agree on what parts of the problem we have to solve in the first part and what can be left to later - no. But I think that largely we agree that there are some problems in this general space where some useful solutions could be developed. In my mind we have some people that want to do some work, figuring out the exact requirements and solutions if what the WG will do.

---

From: Alissa Cooper <[email-masked]>
Date: Thu, 2 Jul 2015 14:40:12 -0700

Thanks Richard, consider your objection ack’ed.

On Jul 2, 2015, at 7:34 AM, Richard Shockey <[email-masked]> wrote:

> — 
> From: Modern <[email-masked]> on behalf of Alissa Cooper <[email-masked]>
> _______________________________________________ Modern mailing list [email-masked] https://www.ietf.org/mailman/listinfo/modern

---

From: "Holmes, David W [CTO]" <[email-masked]>
Date: Fri, 3 Jul 2015 21:02:56 +0000

But the relevant issue to MODERN is that, at very least, any allocation/administration protocol MUST support mandatory (& preferably verifiable) usage reporting to minimize wastage of any such scarce resource?

David Holmes
Standards
+1 425 256 7082
[email-masked]

-----Original Message-----
From: Modern [mailto:[email-masked]] On Behalf Of Henning Schulzrinne
Sent: Thursday, July 02, 2015 11:02 AM
To: Gorman, Pierce A [CTO]; [email-masked]
Subject: Re: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern)

Agreed wrt HTTP.

Best regards,

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

-----Original Message-----
From: Henning Schulzrinne [mailto:[email-masked]]
Sent: July 02, 2015 10:44 AM
To: Gorman, Pierce A [CTO]; [email-masked]
Subject: RE: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern)

Henning

Best regards,

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 4 Jul 2015 02:41:59 +0000

I have a modest proposal that leverages our STIR expertise: We enlist robocallers to check whether a number is in service or not. They seem to be able to cover the whole numbering space and may be looking for additional income. Or you could check whether a number is on the Do-Not-Call list.

More seriously, the toll free number utilization issues in the US show how difficult this is if you have entities that want to hide their hoarding: it has been rumored that a large fraction of 800 numbers terminate on the same adult entertainment services, kind of like domain parking.

Henning

________________________________________
From: Holmes, David W [CTO] [[email-masked]]
Sent: Friday, July 03, 2015 5:02 PM
To: Henning Schulzrinne; Gorman, Pierce A [CTO]; [email-masked]
Subject: RE: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern)

David Holmes
Standards
+1 425 256 7082
[email-masked]

---

From: "Gorman, Pierce A [CTO]" <[email-masked]>
Date: Sat, 4 Jul 2015 18:14:45 +0000

Ranges of Toll Free numbers being used (and paid for and driving service offerings and innovation) is one thing.  Pseudo-identities wrapping up TN address space, potentially for "free" and for nefarious purposes is another.

Regardless, I assume you're not suggesting there be no RFUS policy requirements whatsoever for individual registrations, but just that it may be technically challenging to police and enforce policy on individual registrations.  Do I assume correctly?

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

-----Original Message-----
From: Henning Schulzrinne [mailto:[email-masked]]
Sent: July 03, 2015 9:42 PM
To: Holmes, David W [CTO]; Gorman, Pierce A [CTO]; [email-masked]
Subject: RE: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern)

Henning

David Holmes
Standards
+1 425 256 7082
[email-masked]

---

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 5 Jul 2015 00:11:22 +0000

This is straying a bit far outside the MODERN scope since the decision who gets numbers how and under what conditions is largely a policy one. (I suspect you could have the existing LNPA system hand out numbers to non-carrier or iVoIP entities without changing much beyond the NECA process of filing for OCNs.)

>From what I can tell, people who have proposed treating numbers more like domain names have recognized that this would likely, given the scale, require sufficient economic incentives to encourage frugal use of numbers, in other words, some kind of charge that makes hoarding economically unattractive.

Henning

________________________________________
From: Gorman, Pierce A [CTO] [[email-masked]]
Sent: Saturday, July 04, 2015 2:14 PM
To: Henning Schulzrinne; Holmes, David W [CTO]; [email-masked]
Subject: RE: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern)

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

-----Original Message-----
From: Henning Schulzrinne [mailto:[email-masked]]
Sent: July 03, 2015 9:42 PM
To: Holmes, David W [CTO]; Gorman, Pierce A [CTO]; [email-masked]
Subject: RE: [Modern] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern)

Henning

David Holmes
Standards
+1 425 256 7082
[email-masked]

---

From: Eric Burger <[email-masked]>
Date: Sun, 5 Jul 2015 03:17:51 -0400

Would it not be easier to call it what it is?

A bunch of “relevant people” are interested in doing this work. “This work” is claimed to not have impacts on numbering policy, national regulatory bodies, international treaties, etc. As such, it may be OK to ignore the vehement objections to the IESG chartering the work group, as those folks are not the target audience.

In fact, most of the “relevant people” to the real, current, in the physical world numbering ecosystem have stated flatly and unconditionally they do not care for this work. So, they don’t need to work on it, use the results, write scathing letters to their national regulators, etc.

Can we note that this work group is not targeted to working on a solution to replace anything that exists today? It is just a mechanism for handing out short (numeric?) identifiers that have some opaque policy tokens passed around. That way, the people who really want to work on this (IMHO, academically interesting) problem can work on it, and those that do not, don’t? The fact that today there is a market of five that could use what has been described as being worked on becomes less of an issue. There were at least five hands that went up in the room saying they were willing to work on the problem. The 95 people who said this was brain dead can leave it to its death spiral. Or, if it turns out to be interesting, I’m sure 60 of the 95 will say “I was at the BOF."

> On Jul 2, 2015, at 2:41 PM, Cullen Jennings <[email-masked]> wrote:
>

---

From: Eric Burger <[email-masked]>
Date: Sun, 5 Jul 2015 03:18:57 -0400

What strikes me from this conversation is the IETF created the DNS, so that ICANN could have a field day. In this context I am thinking of all of those useful contributors to society such as domainers, squatters, phishers, blackmail gTLD’s, etc.

Who will take the result of MODERN and build squatting empires?

> On Jul 2, 2015, at 2:01 PM, Henning Schulzrinne <[email-masked]> wrote:
>

---

From: "Gorman, Pierce A [CTO]" <[email-masked]>
Date: Mon, 6 Jul 2015 18:07:48 +0000

You make it sound like there wasn't "rough consensus".

MODERN may be successful though.  DNS has to be considered a success even with all of its operational and political warts (as long as nobody cares about portablity anyway).

And, presumably the ENUM LLC fiasco provided a poignant lesson in how not to create a public database of telephone numbers.

IMHO, for MODERN to be successful, the results need to work for future AND existing needs.  Those needs are many and complex so time should be taken to get it right.  Taking the time to get it right hasn't been the hallmark of this WG, but past performance isn't always an indicator of future results.