Re: [Modern] Review of draft-ietf-modern-problem-framework-00.txt

["Gorman, Pierce A [CTO]" <[e-mail]>]

What makes you think the "IP transition of telephony" needs MODERN?  Where in any of the 3GPP tech specs for IMS does it refer to MODERN?  Where do you think the industry is headed with, or without MODERN?

Robo-calling is a problem.  IP transition of telephony is not.


From: Peterson, Jon [mailto:[e-mail]]
Sent: July 07, 2016 4:50 PM
To: Gorman, Pierce A [CTO] <[e-mail]>; Steve Donovan <[e-mail]>; [e-mail]
Subject: Re: [Modern] Review of draft-ietf-modern-problem-framework-00.txt


The question of whether you require multi-factor authentication to access reachability information or not is, actually, a very narrow implementation detail. There will of course be security requirements on accessing and changing the data that our information model captures, and it could be that those requirements will entail that multi-factor authorization is required - though that the term "multi-factor authentication" also has a specific connotation in security design that might be a little different than what you mean here. But again - the bulk of our chartered work in MODERN is just figuring out what that information model is. You're worrying about things that we won't even get to until we've gone through much of that process.

And while your problem statement below does state a specific problem, that problem as stated doesn't happen to be the problem this group is chartered to solve. Again, this group is much more concerned with the broader question of how and why you might populate data associated with telephone numbers for a variety of applications than with meeting any tactical industry goal like reducing unwanted communications. Reducing unwanted communications could certainly be a very desirable side effect of some of the information models we'd consider here, but that problem didn't motivate this working group. I'm sure we don't need another history lesson, but this working group has more to do with an IP transition of telephony in general than with any specific ill we imagine that IP transition might exacerbate.

Jon Peterson
Neustar, Inc.

From: "Gorman, Pierce A [CTO]" <[e-mail]<mailto:[e-mail]>>
Date: Thursday, July 7, 2016 at 2:38 PM
To: Jon Peterson <[e-mail]<mailto:[e-mail]>>, Steve Donovan <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: RE: [Modern] Review of draft-ietf-modern-problem-framework-00.txt

You may be right.  I may be (just as) guilty of solution jumping.

I don't agree though that suggesting the use of standard security architectural approaches (i.e., multi-factor authentication) to inter-system (or inter-personal) communications requirements with respect to managing CRI is a focus "on a narrow way of implementing this".

A problem statement should state a problem.

For example:

Until user-level Communications Reachability Information (CRI) is modeled to include multiple factors of authenticity instead of a single factor (i.e., the "telephone number"), robo-calling and robo-texting will continue to be problems plaguing the global telecommunications infrastucture and it's users.

If we want the telephone network to be better at screening calls for users, we need to provide more information to the network (and/or the user) to improve filtering.  Authenticating calling numbers will be of very limited usefulness as an anti-robo-calling filter. Including a password in a SIP URI is trivial.  Associating and storing credentials with a telephone number is less so, but would be extremely useful as SPAM filters.

MODERN shouldn't manage telephone numbers.  MODERN should manage CRI.  CRI could include telephone numbers, e-mail and social application addresses, credentials for managing access to CRI data, and credentials used in signaling which assist in authenticating and filtering communications attempts.

Pierce

From: Peterson, Jon [mailto:[e-mail]]
Sent: July 07, 2016 3:59 PM
To: Gorman, Pierce A [CTO] <[e-mail]<mailto:[e-mail]>>; Steve Donovan <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: Re: [Modern] Review of draft-ietf-modern-problem-framework-00.txt


I think the only reason your idea here is being "cheerfully discarded," as you put it, is that we're just not on the same page about what is an architecture, versus a framework, versus a solution. What you're describing goes beyond a problem statement, beyond even proposing an architecture or protocol solution - it sketches an actual implementation that someone could offer as a commercial product. We don't make those at the IETF.

The irony in this misalignment of our understanding of working group's job is that the MODERN charter is probably compatible with what you're proposing, as far as I can tell. A .name namespace allocated for this purpose of exposing reachability information would be an implementation of the "retrieval interface" component of the MODERN framework described in the problem statement. The question of what "factors" you include in a query to the retrieval interface is indeed one of the big ones we're interested in exploring - we hope to eventually produce an information model that will capture what those factors would be. We want to create an information model versatile enough to work with a number of distinct bindings (that is, protocols that might carry the query). But retrieval is only one component of the framework we're developing, as we're also concerned with how identifiers get allocated (maybe how those .name domains get assigned?) and what information gets provisioned against them (maybe what provisioning occurs so that your "factors" help you get the reachability information you need?).

So again, it's not that I'm even necessarily opposed to what you're proposing, you're just not looking at the same parts of the problem that I am, and you're apparently focused on a narrow way of implementing this. Implementing will be the easy part. Getting the information model right is hard, and that's the work we're chartered to do.

Jon Peterson
Neustar, Inc.

From: "Gorman, Pierce A [CTO]" <[e-mail]<mailto:[e-mail]>>
Date: Thursday, July 7, 2016 at 11:38 AM
To: Jon Peterson <[e-mail]<mailto:[e-mail]>>, Steve Donovan <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: RE: [Modern] Review of draft-ietf-modern-problem-framework-00.txt

I haven't read the most current version, but I think it's fair to say I've provided most of the public non-political feedback to MODERN so far.

The last comments I made advocated for the use of .name. domain name space (or a new name space) tied to telephone numbers with the concept of MODERN hosting Communications Reachability Information (CRI) and that index keys into a CRI database could be passwords which could also be telephone numbers.

The idea was cheerfully disregarded but I will bring it up again.  The MODERN "problem statement" is a solution architecture (not a problem statement), and it's inadequate, and centric to NANP telephony considerations.

If you want a globally usable telephone number routing information model for IP-based telecommunications and you want to more usefully solve problems like calling identity authentication (globally) and non-geographic number portability (for NANP), you should seriously be looking at multi-factor authentication for routing information queries.  Factors such as who do you think you're calling? And, what is the number [password] you think is associated with them?

You send a query to the CRI and you only know one factor (e.g., telephone number)?  That provides you an index into the least useful telecommunications information.  Perhaps only a telephone number into a SPAM-only voicemail box or voice-to-text-to-SPAM-text-box or whatever the user has defined that protects them from unauthorized and unauthenticated communications attempts.  Create a multi-factor communications model (which SIP and other communications protocols easily and commonly support) and you can have a meaninful impact on global robo-calling and robo-texting SPAM.

I have 3 main telephone numbers that are unique to me.  Very few people have all 3.  I compartmentalize my communications based on whether they are private, family, or business.  I could easily want or have more.  Many people do.  Very few people purposefully distribute all of their telephone numbers, e-mail addresses, social network personas, et cetera to all of their private, family, and work contacts.

If you want to give users globally, the world over, control over CRI, build a model that addresses their communications reachability needs, not their voice telephony needs.

Regards,

Pierce

From: Modern [mailto:[e-mail]] On Behalf Of Peterson, Jon
Sent: July 07, 2016 12:33 PM
To: Steve Donovan <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: Re: [Modern] Review of draft-ietf-modern-problem-framework-00.txt


Thanks Steve, I cleaned these up.

Jon Peterson
Neustar, Inc.

From: Modern <[e-mail]<mailto:[e-mail]>> on behalf of Steve Donovan <[e-mail]<mailto:[e-mail]>>
Date: Friday, June 24, 2016 at 12:21 PM
To: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: [Modern] Review of draft-ietf-modern-problem-framework-00.txt

I have reviewed draft-ietf-modern-problem-framework-00.txt.  This document is in great shape and I only have editorial comments as follows.

Regards,

Steve

-----

Section 1:

s /familiar from the/familiar to the/
s/ manenr/manner/
s/evolvling/evolving/

Section 2.1
s/assginees/assignees/
s/entitiy/entity/

Section 3
Need references for DRINKS and WEIRDS

Section 4.1.4
s/Aquiring/Acquiring/

Section 4.1.5
s/wtih/with/

Section 4.2.1.2
s/Regisrar/Registrar/

Section 4.1.2.3
s/could could/could/

Section 4.3.2
s/to access to this/to access this/




________________________________

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.