Managing, Ordering, Distributing, Exposing, and Registering Telephone Numbers (MODERN): Problem Statement, Use Cases, and Framework
RFC 8396

Note: This ballot was opened for revision 03 and is now closed.

(Ben Campbell) Yes

Comment (2018-02-21 for -03)
No email
send info
I am balloting yes, but I do have a few minor comments:

Substantive:

§1: "An enterprise, for example, can deploy an IP PBX that
   receives a block of telephone numbers from a carrier and then in turn
   distribute those numbers to new IP telephones when they associate
   with the PBX. "
That's been true for PBX's since well before the advent of IP PBXs. 

§2.1, Numbering Authority: "A regulatory body within a country"
I suspect "country" should be "region", since the definition goes on to consider non-country domains.

Editorial and Nits:

§2.1, last paragraph (before figure): "and it issues 10,000 blocks of TNs to CSPs"
Should that be "10,000 blocks" or "blocks of 10,000 TNs"?

§4.1.1: 
Please define "freephone".
Last paragraph: "... not inventory.In  ..."
Missing space after period.

§4.2.3.1: "   In a similar model to common practice in some environments today..."
Should that be a "model similar to common practice"?

§4.3, 2nd to last paragraph: The paragraph seems to end mid-sentence.

§4.3.1: s/ Eithert / Either

Alissa Cooper Yes

Alexey Melnikov Yes

Comment (2018-02-20 for -03)
No email
send info
Thank you for a well written document.

I am agreeing with Alvaro about expanding MODERN on first use.

4.2.1.2.  Mangaing Data at a CSP

Typo: Managing

Adam Roach Yes

Deborah Brungard No Objection

Comment (2018-02-21 for -03)
No email
send info
Agree with Alvaro, "modern" in the title is confusing without any further reference
in the abstract/introduction.
Nicely done document.

(Benoît Claise) No Objection

Comment (2018-02-21 for -03)
No email
send info
From Linda Dunbar, as OPS DIR reviewer:

The draft brought up a very interesting aspect of Telephone Numbers (TNs),
especially the mobile phone number which is widely used for getting "secure
code" for secure access to very sensitive content, such as bank account.

However, the draft only describes how today's TNs are acquired and managed
(e.g. the Use cases in Section 4). Two issues with the draft: 1) The draft
didn't have the content to describe what is the problems with the current
practices. (I was expecting to read the "problems" when I started to read the
draft) 2) The draft didn't describe the problems of using mobile phone number
for authenticating the access to sensitive data content.

Suresh Krishnan No Objection

Warren Kumari No Objection

Comment (2018-02-22 for -03)
No email
send info
As Benoit said, please see Linda's OpsDir review.

Mirja Kühlewind No Objection

(Terry Manderson) No Objection

(Kathleen Moriarty) (was Discuss, No Objection) No Objection

Comment (2018-03-14)
No email
send info
Thanks for adding the privacy considerations section in response to my prior discuss.

(Eric Rescorla) No Objection

Comment (2018-02-21 for -03)
No email
send info
   from a Registrar.  Today, a user wishing to acquire a freephone
   number may browse the existing inventory through one or more
   Registrars, comparing their prices and services.  Each such Registrar
what's a "freephone number"



   kept by the Registry, TNs assigned to a User are always considered
   assigned, not inventory.In this use case, after receiving a number
   assignment from the Registrar, a User will then obtain communications
You said this above.



   Eithert administrative or service data may be made publicly available
   by the authority that generates and provisions it.  Under most
Nit: "Eitehr"



   have a means of authenticating the source of the query, and of
   protecting the integrity and confidentiality of its responses.
Also, aren't there privacy type issues in the retrieval of the service data? I.e., I would assume we don't want random people to retrieve the service data associated with a TN.

Alvaro Retana No Objection

Comment (2018-02-16 for -03)
No email
send info
(0) For the benefit of non-modern readers, changing the title or at least making it clear that "modern" refers to an acronym, and later expanding and explaining would be very nice.

(1) 

The document mentions the need for authentication, integrity and confidentiality when retrieving information.  However, I didn't see anything related to verifying that in fact the CSP (for example) is the "proper authority" -- IOW, how can the user requesting information verify that the CSP is in fact the one responsible for the TN?  I'm thinking of the case where the CSP was assigned a TN from the numbering authority (how is that verified?), and also the portability case (4.2.3.1) where the "old CSP" is no longer responsible for the user's service.

Given that this document is a framework, I obviously don't expect a solution.  But I think validation of the assignment chain should be included for consideration by future solutions.