Subject: Re: [dispatch] [Modern] draft charter

From: Richard Shockey <[email-masked]>
Date: Tue, 24 Feb 2015 18:35:36 -0500

Excellent points David.

My concern here is charter overreach. I really want to keep CNAM+/CNIT out
of this.  IMHO that is a very separate and highly focused effort to define
both the modification of the SIP headers necessary to support some enhanced
calling party identification and a very limited effort to define the object
and or the STIR validation data.

I¹m violently opposed to ³end world hunger² WG¹s.

If registries can be used fine but I certainly want to see how this can be
accomplished in bi lateral agreements between consenting service providers
and work with CUA vendors on how the data is displayed aka Apple, Samsung,
Microsoft in the context of a formal liaison with 3GPP.  Certainly the
relevance of CNAM+/CNIT in enterprise and residential access markets is
important but we all know ³Money is the answer what is the  question ..²

I¹ve asked for time in Dispatch to look at the CNAM/CNIT issue and report on
the JTF on NNI. As you well know we have made considerable progress.

Last week I gave a talk on this to a panel that included many of our friends
among the national regulators.

http://apps.fcc.gov/ecfs/document/view?id=60001033217

‹ 
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:  "Holmes, David W [CTO]" <[email-masked]>
Date:  Tuesday, February 24, 2015 at 5:06 PM
To:  "Peterson, Jon" <[email-masked]>, "[email-masked]"
<[email-masked]>
Subject:  Re: [Modern] draft charter

Jon, 
 
Thank you for the work in assembling this draft of the charter for MODERN.
 
We would like to suggest some minor clarifications to the bullets describing
the deliverables, to align them with the statement regarding flexibility to
support the needs of different regulatory regimes, & thus to ensure that if
quoted alone they are not taken out of context; i.e. the group product will
be the protocols to support the allocation etc. activities, & it would not
attempt to define the allocation processes.  We also would like the charter
to note the relevant work that has already been performed by both IETF & the
ATIS/SIP Forum JTF, & incorporate that into the output from the MODERN WG as
appropriate.  These changes/additions are have been added to your text
inline below. 
 
We are hoping that the MODERN session at IETF#92 will have remote access, to
allow participation by those of us that cannot attend in person due to other
commitments that week.
 
Regards, 
 
David/Sprint 
____________________________________________________________________________
__
 
From: Modern [mailto:[email-masked]] On Behalf Of Peterson, Jon
Sent: Wednesday, February 11, 2015 9:19 AM
To: [email-masked]
Subject: [Modern] draft charter

At the Dallas IETF meeting in March, we'd like to get together and talk
about what a working group for MODERN might look like. As an initial input
to the discussion, a few of us have put together a proposed charter. While
the TeRQ work was positively evaluated in the DISPATCH process, we feel this
is broader enough in scope to warrant its own BoF.
 
Comments are welcome, this is just a starting point.
 
------
 
Modern charter text:
 
The MODERN working group will define a set of Internet-based mechanisms for
the purposes of managing and resolving telephone numbers (TNs) in an IP
environment.  Existing mechanisms for these purposes face obsolescence as
the voice communications infrastructure evolves to IP technology and new
applications for TNs become possible.  The traditional model of a TN having
an association to a single service provider and a single application is
breaking down.  Its use as a network locator is going away, but its use as
an identifier for an individual or an organization will remain for some
time. Devices, applications, and network tools increasingly need to manage
TNs, including requesting and acquiring TN delegations from authorities.
 
The working group will define a framework for the roles and functions
involved in managing and resolving TNs in an IP environment. This includes a
protocol mechanism for acquiring TNs, which will provide an enrollment
process for the individuals and entities that use and manage TNs. TNs may
either be managed in a hierarchical tree, or in a distributed peer-to-peer
architecture.  Privacy of the enrollment data and security of the resource
will be primary considerations.
 
Additionally, the working group will deliver a protocol mechanism for
resolving TNs which will allow entities such as service providers, devices,
and applications to access data related to TNs, possibly including caller
name data (CNAM).  Maintaining reliability, real time application
performance, security and privacy are primary considerations.  The working
group will take into consideration existing IETF work including ENUM,
SPEERMINT, STIR, and DRINKS.
 
The work of this group is limited to specifying a solution for TNs and
covers any service that can be addressed using a TN.  Expanding the work to
other identifiers is out of scope.  Solutions and mechanisms created by the
working group will be flexible enough to accommodate different policies,
e.g., by different regulatory agencies.
 
The work group will deliver the following:
 
-         An architecture overview document that includes high level
requirements and security/privacy considerationsbuilt on the work of IETF &
the ATIS/SIP Forum JTF, that included:

o  Call routing architecture

o  Inter-carrier NNI

o  Cryptographically-enabled Anti-spoofing (STIR)

o  Enhanced Calling Name (CNIT/CNAM)

-         A document describing the protocols to support enrollment
processes for existing and new TNs including any modifications to metadata
related to those TNs

-         A document describing protocol mechanisms for accessing contact
information associated with enrollments

-         A document describing protocol mechanisms for resolving
information related to TNs

-          

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: "DOLLY, MARTIN C" <[email-masked]>
Date: Wed, 25 Feb 2015 02:02:41 +0000

I support Richard on this

Martin Dolly
Lead Member of Technical Staff
Core & Gov't/Regulatory Standards
AT&T Standards and
Industry Alliances
+1-609-903-3390
Sent from my iPhone

On Feb 24, 2015, at 6:36 PM, Richard Shockey <[email-masked]<mailto:[email-masked]>> wrote:

Excellent points David.

My concern here is charter overreach. I really want to keep CNAM+/CNIT out of this.  IMHO that is a very separate and highly focused effort to define both the modification of the SIP headers necessary to support some enhanced calling party identification and a very limited effort to define the object and or the STIR validation data.

I’m violently opposed to “end world hunger” WG’s.

If registries can be used fine but I certainly want to see how this can be accomplished in bi lateral agreements between consenting service providers and work with CUA vendors on how the data is displayed aka Apple, Samsung, Microsoft in the context of a formal liaison with 3GPP.  Certainly the relevance of CNAM+/CNIT in enterprise and residential access markets is important but we all know “Money is the answer what is the  question ..”

I’ve asked for time in Dispatch to look at the CNAM/CNIT issue and report on the JTF on NNI. As you well know we have made considerable progress.

Last week I gave a talk on this to a panel that included many of our friends among the national regulators.

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

From: "Holmes, David W [CTO]" <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, February 24, 2015 at 5:06 PM
To: "Peterson, Jon" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Modern] draft charter

Jon,

We would like to suggest some minor clarifications to the bullets describing the deliverables, to align them with the statement regarding flexibility to support the needs of different regulatory regimes, & thus to ensure that if quoted alone they are not taken out of context; i.e. the group product will be the protocols to support the allocation etc. activities, & it would not attempt to define the allocation processes.  We also would like the charter to note the relevant work that has already been performed by both IETF & the ATIS/SIP Forum JTF, & incorporate that into the output from the MODERN WG as appropriate.  These changes/additions are have been added to your text inline below.

We are hoping that the MODERN session at IETF#92 will have remote access, to allow participation by those of us that cannot attend in person due to other commitments that week.

Regards,

David/Sprint
______________________________________________________________________________

From: Modern [mailto:[email-masked]] On Behalf Of Peterson, Jon
Sent: Wednesday, February 11, 2015 9:19 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [Modern] draft charter

At the Dallas IETF meeting in March, we'd like to get together and talk about what a working group for MODERN might look like. As an initial input to the discussion, a few of us have put together a proposed charter. While the TeRQ work was positively evaluated in the DISPATCH process, we feel this is broader enough in scope to warrant its own BoF.

------

Modern charter text:

The MODERN working group will define a set of Internet-based mechanisms for the purposes of managing and resolving telephone numbers (TNs) in an IP environment.  Existing mechanisms for these purposes face obsolescence as the voice communications infrastructure evolves to IP technology and new applications for TNs become possible.  The traditional model of a TN having an association to a single service provider and a single application is breaking down.  Its use as a network locator is going away, but its use as an identifier for an individual or an organization will remain for some time. Devices, applications, and network tools increasingly need to manage TNs, including requesting and acquiring TN delegations from authorities.

The working group will define a framework for the roles and functions involved in managing and resolving TNs in an IP environment. This includes a protocol mechanism for acquiring TNs, which will provide an enrollment process for the individuals and entities that use and manage TNs. TNs may either be managed in a hierarchical tree, or in a distributed peer-to-peer architecture.  Privacy of the enrollment data and security of the resource will be primary considerations.

Additionally, the working group will deliver a protocol mechanism for resolving TNs which will allow entities such as service providers, devices, and applications to access data related to TNs, possibly including caller name data (CNAM).  Maintaining reliability, real time application performance, security and privacy are primary considerations.  The working group will take into consideration existing IETF work including ENUM, SPEERMINT, STIR, and DRINKS.

The work of this group is limited to specifying a solution for TNs and covers any service that can be addressed using a TN.  Expanding the work to other identifiers is out of scope.  Solutions and mechanisms created by the working group will be flexible enough to accommodate different policies, e.g., by different regulatory agencies.

-          An architecture overview document that includes high level requirements and security/privacy considerationsbuilt on the work of IETF & the ATIS/SIP Forum JTF, that included:

o   Inter-carrier NNI

-          A document describing the protocols to support enrollment processes for existing and new TNs including any modifications to metadata related to those TNs

-          A document describing protocol mechanisms for accessing contact information associated with enrollments

-          A document describing protocol mechanisms for resolving information related to TNs

-

________________________________

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]<mailto:[email-masked]> https://www.ietf.org/mailman/listinfo/modern
_______________________________________________
dispatch mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/dispatch

---

From: "Peterson, Jon" <[email-masked]>
Date: Wed, 25 Feb 2015 18:14:25 +0000

I think the potential for a CNAM-like function enters into MODERN from the WHOIS/WEIRDS sorts of requirements we imagine are associated with moving the number registration process to the Internet. As you enroll in the system to get numbers, obviously some information about assignees is going to change hands, and somewhere there will have to be control and accountability for who owns what numbers, and a secure (privacy-protecting) way to query for that data. But more broadly, since MODERN follows on TeRQ, any TeRQ-like protocol is going to be able to ask about arbitrary data associated with numbers including names - but crucially, TeRQ queries can and will be launched at a time no call from that number is in progress.

So I'm not sure MODERN would conflict or even overlap, necessarily, with efforts to define a header or other place to carry that naming information in SIP as in the proposed CNIT charter. MODERN isn't going to define a SIP header to carry CNAM data, and CNIT isn't going to define a way to query for CNAM-like data outside of a SIP session in progress, from my reading of the draft charter. If that sounds reasonable, we could build language into both proposed charters that makes the distinction clear.

Jon Peterson
Neustar, Inc.

From: <DOLLY>, MARTIN C <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, February 24, 2015 at 6:02 PM
To: Richard Shockey <[email-masked]<mailto:[email-masked]>>
Cc: "Holmes, David W [CTO]" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Jon Peterson <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Modern] [dispatch] draft charter

Martin Dolly

Excellent points David.

—
Richard Shockey
Shockey Consulting LLC

Jon,

Regards,

David/Sprint

------

Modern charter text:

o   Inter-carrier NNI

-

---

From: Richard Shockey <[email-masked]>
Date: Wed, 25 Feb 2015 13:52:02 -0500

Excellent points.  I agree.

I don¹t see a conflict here in the various Goals and Requirements between
MODERN and CNIT.

My concern was to make sure we could make some immediate progress by
properly separating the work into digestible functions.  I¹m not concerned
at this point on how CNIT / STIR validation data is acquired, much less
authenticated during session establishment or by which SIP/IMS functional
element, only what is the structure of that data and where in the SIP
headers it resides.

There is ample evidence this is getting attention in other SDO¹s so the
first order of business is making sure RAI defines what goes where properly.

‹ 
Richard Shockey
Shockey Consulting LLC

From:  "Peterson, Jon" <[email-masked]>
Date:  Wednesday, February 25, 2015 at 1:14 PM
To:  "DOLLY, MARTIN C" <[email-masked]>, Richard Shockey
<[email-masked]>
Cc:  "Holmes, David W [CTO]" <[email-masked]>, "[email-masked]"
<[email-masked]>, "[email-masked]" <[email-masked]>
Subject:  Re: [Modern] [dispatch]  draft charter

I think the potential for a CNAM-like function enters into MODERN from the
WHOIS/WEIRDS sorts of requirements we imagine are associated with moving the
number registration process to the Internet. As you enroll in the system to
get numbers, obviously some information about assignees is going to change
hands, and somewhere there will have to be control and accountability for
who owns what numbers, and a secure (privacy-protecting) way to query for
that data. But more broadly, since MODERN follows on TeRQ, any TeRQ-like
protocol is going to be able to ask about arbitrary data associated with
numbers including names - but crucially, TeRQ queries can and will be
launched at a time no call from that number is in progress.

So I'm not sure MODERN would conflict or even overlap, necessarily, with
efforts to define a header or other place to carry that naming information
in SIP as in the proposed CNIT charter. MODERN isn't going to define a SIP
header to carry CNAM data, and CNIT isn't going to define a way to query for
CNAM-like data outside of a SIP session in progress, from my reading of the
draft charter. If that sounds reasonable, we could build language into both
proposed charters that makes the distinction clear.

Jon Peterson
Neustar, Inc.

From: <DOLLY>, MARTIN C <[email-masked]>
Date: Tuesday, February 24, 2015 at 6:02 PM
To: Richard Shockey <[email-masked]>
Cc: "Holmes, David W [CTO]" <[email-masked]>, "[email-masked]"
<[email-masked]>, "[email-masked]" <[email-masked]>, Jon Peterson
<[email-masked]>
Subject: Re: [Modern] [dispatch] draft charter

Martin Dolly 

On Feb 24, 2015, at 6:36 PM, Richard Shockey <[email-masked]> wrote:

> 
> Excellent points David.
> 
> My concern here is charter overreach. I really want to keep CNAM+/CNIT out of
> this.  IMHO that is a very separate and highly focused effort to define both
> the modification of the SIP headers necessary to support some enhanced calling
> party identification and a very limited effort to define the object and or the
> STIR validation data.
> 
> accomplished in bi lateral agreements between consenting service providers and
> work with CUA vendors on how the data is displayed aka Apple, Samsung,
> www.shockey.us <http://www.shockey.us>
> www.sipforum.org <http://www.sipforum.org>
> richard<at>shockey.us <http://shockey.us>
> quoted alone they are not taken out of context; i.e. the group product will be
> the protocols to support the allocation etc. activities, & it would not
> attempt to define the allocation processes.  We also would like the charter to
> note the relevant work that has already been performed by both IETF & the
> appropriate.  These changes/additions are have been added to your text inline
> below. 
>  
> At the Dallas IETF meeting in March, we'd like to get together and talk about
> what a working group for MODERN might look like. As an initial input to the
> discussion, a few of us have put together a proposed charter. While the TeRQ
> work was positively evaluated in the DISPATCH process, we feel this is broader
> enough in scope to warrant its own BoF.
>  
> environment.  Existing mechanisms for these purposes face obsolescence as the
> voice communications infrastructure evolves to IP technology and new
> applications for TNs become possible.  The traditional model of a TN having an
> association to a single service provider and a single application is breaking
> down.  Its use as a network locator is going away, but its use as an
> identifier for an individual or an organization will remain for some time.
> Devices, applications, and network tools increasingly need to manage TNs,
> including requesting and acquiring TN delegations from authorities.
>  
> The working group will define a framework for the roles and functions involved
> in managing and resolving TNs in an IP environment. This includes a protocol
> mechanism for acquiring TNs, which will provide an enrollment process for the
> individuals and entities that use and manage TNs. TNs may either be managed in
> a hierarchical tree, or in a distributed peer-to-peer architecture.  Privacy
> of the enrollment data and security of the resource will be primary
> considerations. 
>  
> and applications to access data related to TNs, possibly including caller name
> data (CNAM).  Maintaining reliability, real time application performance,
> security and privacy are primary considerations.  The working group will take
> into consideration existing IETF work including ENUM, SPEERMINT, STIR, and
> DRINKS. 
>  
> The work of this group is limited to specifying a solution for TNs and covers
> any service that can be addressed using a TN.  Expanding the work to other
> identifiers is out of scope.  Solutions and mechanisms created by the working
> group will be flexible enough to accommodate different policies, e.g., by
> different regulatory agencies.
>  
> -         A document describing the protocols to support enrollment processes
> for existing and new TNs including any modifications to metadata related to
> those TNs
> 
> [email-masked]