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

Richard Shockey <richard@shockey.us> Fri, 26 June 2015 17:52 UTC

Return-Path: <richard@shockey.us>
X-Original-To: modern@ietfa.amsl.com
Delivered-To: modern@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A25031A90AD for <modern@ietfa.amsl.com>; Fri, 26 Jun 2015 10:52:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.921
X-Spam-Level:
X-Spam-Status: No, score=-0.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DEAR_SOMETHING=1.973, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_I_LETTER=-2, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, MIME_BASE64_BLANKS=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9o3nWWvvLfGP for <modern@ietfa.amsl.com>; Fri, 26 Jun 2015 10:52:43 -0700 (PDT)
Received: from qproxy2.mail.unifiedlayer.com (qproxy2-pub.mail.unifiedlayer.com [69.89.16.161]) by ietfa.amsl.com (Postfix) with SMTP id 898561A90B6 for <modern@ietf.org>; Fri, 26 Jun 2015 10:52:39 -0700 (PDT)
Received: (qmail 13122 invoked by uid 0); 26 Jun 2015 17:52:31 -0000
Received: from unknown (HELO CMOut01) (10.0.90.82) by qproxy2.mail.unifiedlayer.com with SMTP; 26 Jun 2015 17:52:31 -0000
Received: from box462.bluehost.com ([74.220.219.62]) by CMOut01 with id l5N01q00D1MNPNq015N3Ll; Fri, 26 Jun 2015 11:22:10 -0600
X-Authority-Analysis: v=2.1 cv=ALgDonD0 c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=sNEldo0-0YMA:10 a=IYETQKA4aJkA:10 a=MKtGQD3n3ToA:10 a=1oJP67jkp3AA:10 a=ZZnuYtJkoWoA:10 a=8WrITzYgnNwA:10 a=YQA3agX6zLcA:10 a=XAFQembCKUMA:10 a=PeFO9FbFhS32YxYntvkA:9 a=dci_DRCyiIAA:10 a=CiRkrLRW1GAA:10 a=iycWLhIX580A:10 a=48vgC7mUAAAA:8 a=izV7ms69AAAA:8 a=hGBaWAWWAAAA:8 a=hZG83p_yAAAA:8 a=UqAplN6HAAAA:8 a=yakATiurAAAA:8 a=qb5AeoveEj9_vRKy0AYA:9 a=fXH3lMBJ42S_-c2q:21 a=DZbCQG10rFuXbDkC:21 a=wPNLvfGTeEIA:10 a=DzjOOp_o1eYA:10 a=kkUMZHjH4KkA:10 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=5qHAxTPpvGyLm7KCZycA:9 a=c6PcdC7AMBajFKTI:21 a=KMSyyVF-RjcN2eQv:21 a=2C26eYgu42FFWfOc:21 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=_W_S_7VecoQA:10 a=frz4AuCg-hUA:10 a=egme4pEsFs5cgmtfQNoA:9 a=CB7KgUWFIrtp_Igg:18 a=HXjIzolwW10A:10
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-type:Mime-version:In-Reply-To:References:Message-ID:To:From:Subject:Date; bh=ol2vjKWkTENp/qRRUuq3rw6+cgwTPBH+xkMuqRw7jRU=; b=VfLTSsrdpFMzyezGiXT6H/FlpjH7On/RFp/wnqsbdTFXpzKXLPjT6J/z96GI+PdoyCOixkR4fo/IeGsOMwH2re+aPg3krdH7DV3gqHZ75DQbLJSdDJyNhQ7QUwusurz3;
Received: from [100.36.26.202] (port=58157 helo=[192.168.1.10]) by box462.bluehost.com with esmtpa (Exim 4.84) (envelope-from <richard@shockey.us>) id 1Z8XUC-0005ri-Kx; Fri, 26 Jun 2015 11:32:21 -0600
User-Agent: Microsoft-MacOutlook/14.5.2.150604
Date: Fri, 26 Jun 2015 13:32:14 -0400
From: Richard Shockey <richard@shockey.us>
To: "Gorman, Pierce A [CTO]" <Pierce.Gorman@sprint.com>, "Peterson, Jon" <jon.peterson@neustar.biz>, Richard Hill <rhill@hill-a.ch>, "McGarry, Tom" <Tom.McGarry@neustar.biz>, "modern@ietf.org" <modern@ietf.org>
Message-ID: <D1B30259.28102%richard@shockey.us>
Thread-Topic: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern)
References: <10E9C750-6B20-4258-B538-F64AB40269B2@cooperw.in> <D1B1F5DD.27B63%tom.mcgarry@neustar.biz> <005a01d0b022$169bcbb0$43d36310$@ch> <D1B2C600.15475E%jon.peterson@neustar.biz> <d2460d69736a4afb8eb74b19fc05304d@PLSWE13M08.ad.sprint.com>
In-Reply-To: <d2460d69736a4afb8eb74b19fc05304d@PLSWE13M08.ad.sprint.com>
Mime-version: 1.0
Content-type: multipart/mixed; boundary="B_3518170340_750263"
X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 100.36.26.202 authed with richard+shockey.us}
Archived-At: <http://mailarchive.ietf.org/arch/msg/modern/MH6scZ_EDViK1-AqPpi15oeR0hI>
Subject: Re: [Modern] Fwd: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern)
X-BeenThere: modern@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" <modern.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/modern>, <mailto:modern-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/modern/>
List-Post: <mailto:modern@ietf.org>
List-Help: <mailto:modern-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/modern>, <mailto:modern-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 26 Jun 2015 17:52:55 -0000

In line.

From:  Modern <modern-bounces@ietf.org> on behalf of
"Pierce.Gorman@sprint.com" <Pierce.Gorman@sprint.com>
Date:  Friday, June 26, 2015 at 12:55 PM
To:  "Peterson, Jon" <jon.peterson@neustar.biz>, Richard Hill
<rhill@hill-a.ch>, "McGarry, Tom" <Tom.McGarry@neustar.biz>,
"modern@ietf.org" <modern@ietf.org>
Subject:  Re: [Modern] Fwd: [new-work] WG Review: Managing, Ordering,
Distributing, Exposing, & Registering telephone Numbers (modern)

³Many use cases under consideration would not have a national regulator as
an actor.²  - J. Peterson
 
I¹ve struggled with this point.  What are the ³many² use cases?  For
example, I¹ve not been able to envision the use case that would require a
device to use a MODERN protocol tool to acquire an RFC 3966 telephone
number.  What is this use case?
 
This continues to baffle me.  Why is the IETF proposing to develop protocol
tools to manage telephone numbers?  What is broken about the existing
system(s)?
 
And I really struggle with how this is supposed to work because there are so
many different kinds of telephone numbers such as service numbers (e.g.,
211, 911, etc.), Toll Free numbers, mobile numbers, wireline numbers, TLDNs,
IMRNs, ported numbers, and multiple administrative databases, NPAC, LERG,
SMS800, et cetera.
 
And the administration is distributed (in the US) at national and state
levels.
 
Has anyone from any of the US or international number management
administrative organizations requested that the IETF build tools for them?

RS > Excellent point as you well know there has not been any formal
communication from the NANC ( the US FAC ) to the IETF on this issue.  The
IETF as we all know does actually respond to regulatory requests ..if you
look at nearly all of the PROVREG and WHOIS issues they are in direct
response to ICANN requests or mandates.

I can testify to the fact that some other NRA¹s are interested in new ideas
about number administration and they are desperate to first  find solutions
to the robocall spoofing problems but each jurisdiction is at various points
in the overall PSTN Transition and it is not clear a US centric solution
would be appropriate.

That said there was universal consensus that the STIR proposition was needed
and the IETF was the only appropriate body to revise 4474 in order to enable
a PKI infrastructure but beyond 4474bis I think there will need to be some
debate on how NRA¹s actually attempt to implement the protocol and design
the PKI system.



 If they don¹t use them, who will?  And how can they integrate with an
existing system?  Sorry Jon.  Still lost.

 
 
Pierce Gorman
Core Network Planning
O: 913-439-4368
pierce.gorman@sprint.com
 

From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Peterson, Jon
Sent: June 26, 2015 11:35 AM
To: Richard Hill; McGarry, Tom; modern@ietf.org
Subject: Re: [Modern] Fwd: [new-work] WG Review: Managing, Ordering,
Distributing, Exposing, & Registering telephone Numbers (modern)
 

 

Your arguments here could equally well be applied to any important resource
on which the IETF does protocol work - like, say, the DNS. The IETF manages
the DNS protocol and publishes RFCs about it. But since national authorities
are responsible for ccTLDs, surely the IETF is not a suitable body for
managing the DNS! And it isn't. But it is a suitable body for managing the
protocol work on the DNS. Other, effectively unrelated entities handle the
administrative dimensions of operating the DNS, and yes, at those bodies
there are lots of national regulators and they worry about the sorts of
things you are worrying about here. The IETF just produces tools, and that
is all MODERN proposes to do. Trying to characterize this effort otherwise
is simply an error.

 

All work at the IETF is done by a coalition of the willing. If it turns out
that the coalition is not representative of the needs of the community, then
what happens? Well, the work built here doesn't get used. The only people
who wasted any time or effort were the members of that coalition. No
national interests can possibly be harmed by that, even if the failed work
involved ways of talking about telephone numbers. This makes the IETF really
different from places like the ITU, where the products of work have some
binding effect on the world.

 

Virtually all proposed work at the IETF also faces a coalition of the
unwilling. People who aren't interested, or who think the work should be
done elsewhere, or that the work simply shouldn't be done at all. But I
maintain your "formal objection" treats the scope of the proposed work as
being different than it is, and I'd agree that if this proposed work
required regulatory oversight, that the IETF shouldn't do it. But we're just
building some protocol tools. There is also related work here for ATIS to
do, and I'm sure ATIS or some other body could later take some the protocol
tools developed in the IETF and conduct an experiment with various carriers
to see if it works for that interest group or not, and that would be
interesting information. But the IETF doesn't do that part, and doesn't
aspire to do that part.

 

Finally, I'm not really sure how much I would expect "national regulators"
to literally use the tools proposed in this work. They are tools for the use
of a diverse industry of enterprises, carriers, end users, and so on. Many
use cases under consideration would not have a national regulator as an
actor. This work was in part instigated by an FCC workshop, yes, and someone
associated with the FCC spoke at the MODERN BoF. But I don't anticipate that
the FCC would be propping up servers to deploy this work - surely they would
leave that to industry.

 

Jon Peterson

Neustar, Inc.

 

From: Richard Hill <rhill@hill-a.ch>
Date: Friday, June 26, 2015 at 8:09 AM
To: "McGarry, Tom" <Tom.McGarry@neustar.biz>, "modern@ietf.org"
<modern@ietf.org>
Subject: Re: [Modern] Fwd: [new-work] WG Review: Managing, Ordering,
Distributing, Exposing, & Registering telephone Numbers (modern)

 

Thank you for this clarification.
 
Since the intent is to create tools and solutions that would be used by
national regulators, presumably they should be involved in the development
of the tools. 

As far as I know, national regulators from most countries don¹t normally
participate in the IETF, for a number of reasons, including the IETF¹s
decision-making process and the fact that the IETF works in English.
National regulators do participate in ITU-T, for a number of reasons,
including the ITU¹s decision-making process and the fact that documents are
translated into the six UN languages before they are formally approved (and
some discussions takes place with interpretation in six languages).
 
If the intent is to develop tools that would be used only in the USA at
first, then I would suggest that it would be more appropriate to develop
them in a forum such as ATIS or an ad-hoc group created specifically for the
purpose. If the US experience proved successful, then the tools could be
proposed for adoption elsewhere, for example through ITU-T.
 
If the intent is to develop tools for use in many countries right at the
start, then I would suggest that the appropriate forum would be ITU-T, not
IETF, for the reasons outlined above.
 
Thus, I formally object to the creation of this new working group, and this
even if the Charter is modified as suggested below.
 
Please see additional comments inline.
 
Thanks and best,
Richard
 

From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of McGarry, Tom
Sent: vendredi, 26. juin 2015 00:31
To: modern@ietf.org
Subject: Re: [Modern] Fwd: [new-work] WG Review: Managing, Ordering,
Distributing, Exposing, & Registering telephone Numbers (modern)
 

 

This effort is intended to create tools and solutions to enable flexibility
in the process of managing numbers among national administrators, service
and application providers, and consumers.  Entities can choose to use these
tools or not.  These tools are not for the ITU-T's processes or role, nor
for how national administrators interact with the ITU-T.  But of course we
want your input and feedback, so thanks for sending this along.  More
comments in line below.

 

 

From: Alissa Cooper <alissa@cooperw.in>
Date: Thursday, June 25, 2015 7:44 AM
To: Modern List <modern@ietf.org>
Subject: [Modern] Fwd: [new-work] WG Review: Managing, Ordering,
Distributing, Exposing, & Registering telephone Numbers (modern)

 

Would appreciate people¹s thoughts on whether any charter edits may be
warranted in response to these comments, and/or whether a separate response
may be useful for addressing some of the questions below.

 

Alissa

 

Begin forwarded message:



From: "Zhang, Jie" <jie.zhang@itu.int>

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

Date: June 23, 2015 at 1:56:42 PM GMT-3

To: "iesg@ietf.org" <iesg@ietf.org>

Cc: "Jamoussi, Bilel" <bilel.jamoussi@itu.int>

> Dear Sir/Madam,
> 
> Below please find comments from the ITU Telecommunication Standardization
> Bureau on the proposed IETF working group MODERN.
> 
> 1. Potential impacts on Recommendation ITU-T E.164 and E.164.1
> It is stated at the beginning of the Charter that 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. And it is
> mentioned that TNs are defined in RFC 3966 "The tel URI for Telephone
> Numbers". Does that mean the mechanism being referred to here only deals with
> Tel URI? Would there be any impact on Recommendation ITU-E E.164 and E.164.1
> which are core recommendations on Telephone Numbers?

There will be no impacts on E.164 and E.164.1.
 
>RH: Given the scope of the work, I think that it is too early to say whether
there would be an impact. Those Recommendations are regularly updated, in
particular E.164.1, so there is nothing wrong with envisaging changes, with the
recognition of course that the changes would have to be proposed to ITI-T Study
Group 2 and agreed by that group.
> 
> 
> 2. Entities participating in the defined mechanisms
> The Charter states that the protocol mechanism for resolving TNs will allow
> entities such as service providers, devices, and applications to access data
> related to TNs. But it is not clear what kind of entities can participate in
> the mechanisms defined by this MODERN working group. Would it be restricted to
> the entities who have been assigned a TN or a block of TNS?

Who participates in numbering processes within countries is subject to
regulation.  The WG cannot make any decisions with regard to this.  I expect
the WG to define "roles" within the number management processes; e.g.,
administrator, telecom carrier, application provider, consumer, etc.; and
how those roles could interact with each other.  This will be a baseline for
what tools and solutions would be useful to facilitate those interactions.
 
>RH: Even that might be subject to, or affect, national regulations.  That is,
the definition of a ³role² may well depend on national regulations.
> 
> 
> 3. Status of Telephone numbers in the defined mechanisms
> Several operations related to TNs are mentioned in the Charter, including
> requesting, acquiring, resolving and associating. It is also stated that the
> protocol mechanism for acquiring TNs will provide an enrollment process for
> the entities that use and manage TNs. Does that mean Telephone numbers with
> various status, such as assigned, spare and reclaimed numbers will all be
> managed in the mechanisms defined by the MODERN working group?

I would expect proposed solutions to be able to address the status of a
telephone number.
 
>RH: Since the terms ³assigned², ³spare² and ³reclaimed² are defined in ITU-T
Recommendations (albeit sometimes implicitly), addressing the status of a
telephone number might well impact E.164 or E.164.1.
> 
> 
> 4. Regulatory issues
> The Charter states that Solutions and mechanisms created by the working group
> will be flexible enough to accommodate different policies for TN assignment
> and management, for example those established by different regulatory
> agencies. We would like to bring your attention to the fact that the E.164
> international public telecommunication numbering plan is a politically
> significant numbering resource with direct implications on national
> sovereignty. ITU Plenipotentiary Conference Resolution 133 (Rev. BUSAN, 2014)
> recognized "the existing role and sovereignty of ITU Member States with
> respect to allocation and management of their country code numbering resources
> as enshrined in Recommendation ITU-T E.164", and further instructed the ITU
> Secretary-General and the Directors of three Bureaux (Telecommunication
> Standardization, Development, and Radiocommunication) to "take any necessary
> action to ensure the sovereignty of ITU Member States with regard to
> Recommendation ITU-T E.164 numbering plans whatever the application in which
> they are used".

We are aware of Resolution 133 and will certainly respect it.  I would
propose adding the following text after the first sentence in the last full
paragraph ­ "The group acknowledges ITU Plenipotentiary Conference
Resolution 133 which recognizes the existing role and sovereignty of ITU
Member States with respect to allocation and management of their country
code numbering resources as enshrined in Recommendation ITU-T E.164."
 
>RH: That certainly would be a helpful addition. In addition to the above, I
would suggest adding ³The group¹s outputs would be consistent with the
provisions of relevant ITU-T Recommendations, in particular E.164, E.164.1,
E.190 and the Recommendations referenced therein.²
 
>RH: For the sake of clarity I reiterate that I oppose the creation of this
group even if the Charter is modified to include the text above.
 
> 
> 
> 5. Relationship with .Tel
> DNS-based use of international numbering resources has been discussed in ITU-T
> Study Group 2 (SG2) since its meeting of 17-26 September 2013. TSB Director
> has also exchanged letters with ICANN on issues related to registering digit
> strings in the .TEL domain. A representative from ICANN participated in the
> ITU-T SG2 meeting (28 May - June 2014) and provided some background on the
> TELNIC application. A correspondence group under ITU-T SG2 was also set up in
> this regard. We would like to know how the work of this new WG would relate to
> issues related to registering digit strings in the .TEL domain and other
> DNS-based use of telephone numbers.

The WG will not create any new namespace that would require regulatory
oversight, e.g., a new TLD, SLD, etc.  I wouldn't rule out the WG leveraging
existing namespaces as part of proposed solutions.  But it's too early to
say anything specific about that.  There is nothing in the charter that
references .tel.  
> 
> 
> 6. Relationship with related existing or concluded WGs
> It is stated in the Charter that the working group will take into
> consideration existing IETF work including STIR, ENUM, SPEERMINT, DRINKS and
> SCIM. Detailed description of the relationship between this new WG and the
> above mentioned other existing or concluded WGs would be appreciated.

I agree.  I would modify that sentence to add the following at the end - "as
well as other relevant industry and standards organizations."
> 
> 
> 7. The name of this new WG
> The name of this new WG is "Managing, Ordering, Distributing, Exposing, &
> Registering telephone Numbers (modern)". But in the Charter, ordering,
> exposing and registering TNs are not mentioned, which seems to be a little bit
> inconsistent.

The IETF often has fun with creating WG names.  : )  But the charter is
where to look for the scope of work.  The charter uses the following phrases
"distribution, acquisition and management of TNs", "functions involved in
associating information Š with TNs", "associating, acquiring and resolving
TNs", "access data related to TNs", and "mechanisms for resolving
information related to TNs".  The functions you believe were left out of the
charter will be part of one or more of these processes.
> 
> 
> 
> Best regards,
> 
> Jie Zhang
> Advisor, ITU-T SG2
> International Telecommunication Union
> Place des Nations
> CH-1211 Geneva , Switzerland
> Tel :+41 22 730 5855
> jie.zhang@itu.int
> www.itu.int <http://www.itu.int>
> www.itu150.org <http://www.itu150.org>
> 
> 
> -----Original Message-----
> From: new-work [mailto:new-work-bounces@ietf.org] On Behalf Of The IESG
> Sent: Friday, June 12, 2015 8:47 PM
> To: new-work@ietf.org
> Subject: [new-work] WG Review: Managing, Ordering, Distributing, Exposing, &
> Registering telephone Numbers (modern)
> 
> A new IETF working group has been proposed in the Applications and Real-Time
> Area. The IESG has not made any determination yet. The following draft charter
> was submitted, and is provided for informational purposes only. Please send
> your comments to the IESG mailing list (iesg at ietf.org) by 2015-06-22.
> 
> Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers
> (modern)
> ------------------------------------------------
> Current Status: Proposed WG
> 
> Chairs:
>  Tom McGarry <tom.mcgarry@neustar.biz>
>  Steve Donovan <srdonovan@usdonovans.com>
> 
> Assigned Area Director:
>  Alissa Cooper <alissa@cooperw.in>
> 
> Mailing list
>  Address: modern@ietf.org
>  To Subscribe: https://www.ietf.org/mailman/listinfo/modern
>  Archive: http://www.ietf.org/mail-archive/web/modern/
> 
> Charter:
> 
> 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. Devices, applications, and network tools increasingly need to
> manage TNs, including requesting and acquiring TN delegations from
> authorities. The output of the working group should make distribution,
> acquisition, and management of TNs simpler for all entities involved.
> 
> 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 identify protocol
> mechanisms to support the interactions between the functions defined by the
> framework. This includes either recommending or defining protocol mechanisms
> for acquiring, associating and resolving TNs, with a preference for use of
> existing protocol mechanisms. TNs may either be managed in a hierarchical
> tree, or in a distributed registry. The protocol mechanism for acquiring TNs
> will provide an enrollment process for the entities that use and manage TNs.
> 
> The protocol mechanism for resolving TNs will allow entities such as service
> providers, devices, and applications to access data related to TNs.
> Maintaining reliability, real-time application performance, and security and
> privacy for both the data and the protocol interactions are primary
> considerations. The working group will take into consideration existing IETF
> work including STIR, ENUM, SPEERMINT, DRINKS and SCIM.
> 
> The work of this group will focus on TNs, as defined in RFC3966, and blocks of
> TNs, that are used to initiate communication with another user of a service.
> There is an expectation that aspects of the architecture and protocols defined
> by the working group will be reusable for other user-focused identifiers. Any
> such extensions or reuse of MODERN mechanisms are out of scope for the MODERN
> working group. Solutions and mechanisms created by the working group will be
> flexible enough to accommodate different policies for TN assignment and
> management, for example those established by different regulatory agencies.
> 
> The working group will deliver the following:
> 
> - An architecture overview, including high level requirements and
> security/privacy considerations
> 
> - A description of the enrollment processes for existing and new TNs including
> any modifications to metadata related to those TNs
> 
> - A description of protocol mechanisms for accessing contact information
> associated with enrollments
> 
> - A description of mechanisms for resolving information related to TNs
> 
> Milestones:
> 
> TBD
> 
> _______________________________________________
> new-work mailing list
> new-work@ietf.org
> https://www.ietf.org/mailman/listinfo/new-work

>  
 



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
Modern@ietf.org https://www.ietf.org/mailman/listinfo/modern