Bernie Hoeneisen | 13 Jan 15:32 2014
Picon

Expert Review draft-goix-appsawg-enum-acct-uri: Approved

Dear ENUM list

Please be informed that after all issues could be resolved with the 
authors, the document draft-goix-appsawg-enum-acct-uri-06 has been expert 
approved.

Please find the expert review document in the attachment.

All the best,
  Bernie, IESG Designated Expert for ENUM

--

http://ucom.ch/
Tech Consulting for Internet Technology
//Start of Expert Review Document//

Expert Review of: IANA Registration for Enumservice 'acct'
Document Name: draft-goix-appsawg-enum-acct-uri-06.txt
Document Location: http://tools.ietf.org/html/draft-goix-appsawg-enum-acct-uri-06


Date Review Started (on revision -06): 13. Jan 2014
Date Review Completed: 13. Jan 2014
Revision: 1.0 [2013-01-13]

Review Conducted By: Bernie Hoeneisen <bernhard.hoeneisen <at> ucom.ch>

--------------------------------------------
Expert's Note: This review was conducted in accordance with RFC 6117. Specific guidance on the Expert
(Continue reading)

Bernie Hoeneisen | 11 May 14:30 2013
Picon

Expert Review of draft-goix-appsawg-enum-acct-uri (ER Last Call)

Dear ENUM community

As the IESG Designated Expert for ENUM I got a request for conducting an 
Expert Review on the following Enumservice to be registered with IANA:

   http://tools.ietf.org/html/draft-goix-appsawg-enum-acct-uri-02

Before I make a final decision on this registration, I'd like to give the 
ENUM community the opportunity for last comments on this Enumservice 
registration document (ER Last Call).

You can send your feedback either to the ENUM mailing list or directly to 
me, and I will take it into account for my Expert Review decision.

Please submit your comments within 2 weeks (i.e. latest by 25 May 2013).

All the best,
  Bernie Hoeneisen, IESG Designated Expert

--

http://ucom.ch/
Tech Consulting for Internet Technology
Goix Laurent Walter | 13 Jul 06:55 2012
Picon

Enum service registration for acct: URI

Hello all,

I've just uploaded a new revision of the draft that proposes to register an enum service for resolving phone
numbers into acct: URIs.
This revision builds on -01 draft that already incorporated feedback received from the enum group, and
mainly updates the references to the new split of webfinger vs acct: uri.

You can find it at http://tools.ietf.org/html/draft-goix-appsawg-enum-sn-service-02

I very much welcome your feedback on this new revision.

Regards
Walter

Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La
diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono
rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente
pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie.

This e-mail and any attachments is confidential and may contain privileged information intended for the
addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are
not the intended recipient, please delete this message and any attachments and advise the sender by
return e-mail, Thanks.
Eric Stone | 3 Apr 06:56 2012

Social ENUM / Patents and Intellectual Property

Dear ENUM Group,

In reference to draft-goix-appsawg-enum-sn-service-00.txt I have to raise my hand and ask to slow down.  My apologies first in case this rubs people the wrong way, I do not want to be a party pooper, but I do feel that this is my party.  Our intellectual property re: Social ENUM date to 2008 and we specifically did not publish to the IETF and have done the traditional patent protection around this tech.  Interestingly the latest draft is spot on --  which really begs the question as from what I understood, you can't protect an open standard and therefore we did not do so.  I don't mind sharing but the specific mechanisms described in the draft are in direct conflict with our IP.   We even built the server and have it in operation and are moving into trial with a major operator.    Specifically the use of any type of "sn" style records in ENUM / E164 and other lookup type db's would be in direct violation of our IP. 

_______________________________________________
enum mailing list
enum <at> ietf.org
https://www.ietf.org/mailman/listinfo/enum
Bernie Hoeneisen | 11 Mar 21:21 2012
Picon

New Version Notification for draft-hoeneisen-rfc5333bis-01.txt (fwd)

FYI

---------- Forwarded message ----------
Date: Sun, 11 Mar 2012 21:18:32
From: internet-drafts <at> ietf.org
To: bernie <at> ietf.hoeneisen.ch
Subject: New Version Notification for draft-hoeneisen-rfc5333bis-01.txt

A new version of I-D, draft-hoeneisen-rfc5333bis-01.txt has been successfully submitted by Bernie
Hoeneisen and posted to the IETF repository.

Filename:	 draft-hoeneisen-rfc5333bis
Revision:	 01
Title:		 IANA Registration of Enumservices for Internet Calendaring
Creation date:	 2012-03-11
WG ID:		 Individual Submission
Number of pages: 20

Abstract:
    This document registers and obsoletes Enumservices for Internet
    calendaring.  Specifically, this document focuses on Enumservices for
    iMIP (iCalendar Message-Based Interoperability Protocol), CalDAV
    (Calendaring Extensions to WebDAV), and iSchedule (Internet Calendar
    Scheduling Protocol).

--

http://ucom.ch/
Tech Consulting for Internet Technology
Richard Shockey | 6 Mar 18:08 2012
Picon

Re: [dispatch] New Proposal for Telephone-Related Queries


I think this a perfectly reasonable proposal.  I'd like to see it move
forward.

It would be useful not to get into any Layer 10 issues of what people have
used 6116 for. The simple fact is that its there, it scales, its fully
deployed in private instantiations in major carrier networks and is baked
into multiple NNI profiles. 

That said we know two things.  6116 has limitations due to its use of
underlying DNS technology. Jon is right that the problem of determinate
response based on source of the query in DNS has forced us to look at some
duct tape and wire solutions that may be sub optimal. Though source-URI does
work. 

Speaking of Layer 9, the other issue is phone numbers are not going away and
any transition from POTS to FOO is going to have to deal with multiple types
of data associated with those identifiers.  

-----Original Message-----
From: dispatch-bounces <at> ietf.org [mailto:dispatch-bounces <at> ietf.org] On Behalf
Of Peterson, Jon
Sent: Monday, March 05, 2012 5:05 PM
To: 'dispatch <at> ietf.org'
Subject: Re: [dispatch] New Proposal for Telephone-Related Queries

Oops, sorry, my mailer did not like the URL I submitted. The correct URL for
the draft is:

https://datatracker.ietf.org/doc/draft-peterson-terq/

Jon Peterson
Neustar, Inc.

 -----Original Message-----
From: 	Peterson, Jon [mailto:jon.peterson <at> neustar.biz]
Sent:	Monday, March 05, 2012 04:51 PM Eastern Standard Time
To:	dispatch <at> ietf.org
Subject:	[dispatch] New Proposal for Telephone-Related Queries

I have a proposal to bounce off the group. Basically, this is a
re-examination of some of the problems we've previously considered in the
telephony-specific cluster of work surrounding ENUM, DRINKS and SPEERMINT.
Through discussions in the past couple years, it's become clear that we
would need to significantly extend ENUM to get it to handle all of the sorts
of sources, subjects, and attributes that people want to factor into queries
about telephone number routing and administration. Most of these discussions
have gotten wrapped around the axle on questions of the underlying syntax
and semantics of the DNS, which were a good match for the original vision of
a public, user-driven ENUM, but don't seem to be such a good match for the
uses people actually want to make of these protocols, in federated,
service-provider-driven environments like those envisioned in SPEERMINT and
provisioned in DRINKS. While the discussion may have died down a bit, the
requirements that motivated th
 e discussion definitely aren't going away.

Rather than continue to debate the applicability of the DNS and the probity
of various extensions to it, we might make more progress if we work towards
agreement on the semantics of queries for telephone-related data
independently of any underlying protocols. In other words, focus on what
kinds of questions about telephone numbers we want to be able to ask, and
what kinds of information needs to go into the answers, and incorporate all
this into an abstract data model. So for example, we know that we want to be
able to express the source of a request in a query. What do we mean by
source? I can think of a bunch of different kinds of source: the logical
originator of the query (the administrative entity asking), the logical
identity of any intermediary or aggregator forwarding the query, or even the
point at the network from which the call originates (the originating trunk
group, SBC or what have you). All three of those concepts of source seem
important when it comes to answe
 ring questions about telephone numbers, so a data model would treat those
as separate elements which can vary independently - then we can then try to
figure out what's mandatory or optional, etc. We follow this same method for
all the elements of queries and responses. Figure out what the attributes
are of telephone numbers that we care about, sort them into buckets of
routing data and administrative data, and so on.

Once we have an agreement on the data model, then people can map the model
to whatever underlying protocol they'd like - or just build it into a web
API, or what have you. Those proposals could advance as separate documents.
Having that flexibility would make it a lot easier to figure out what we
really want the questions and answers to be, rather than thinking about what
they realistically can be within the constraints of some existing underlying
protocol.

That's the idea. I'm not going to present a proposed charter for work or
anything like that in Paris, but I am interested in hearing if people think
this is a promising approach, and if so, perhaps we'd put a charter on the
agenda for Vancouver. I have however submitted a -00 draft for this time
which gives a high-level proposal for a data model and at least enumerates
what some of the elements might be that would be populated in queries and
responses. This is a pretty broad sketch, but it should convey the basic
idea. You can check it out here:
https://exchcas.va.neustar.com/owa/thoughts about the direction or the
specifics of the data model are welcome. Thanks!

Jon Peterson
NeuStar, Inc.
_______________________________________________
dispatch mailing list
dispatch <at> ietf.org
https://www.ietf.org/mailman/listinfo/dispatch
_______________________________________________
dispatch mailing list
dispatch <at> ietf.org
https://www.ietf.org/mailman/listinfo/dispatch
Peterson, Jon | 6 Mar 00:34 2012

Fwd: [dispatch] New Proposal for Telephone-Related Queries


This proposal may be of interest to the remnants of this working group.

Jon Peterson
NeuStar, Inc.

Begin forwarded message:

From: "Peterson, Jon" <jon.peterson <at> neustar.biz>
Date: March 5, 2012 1:51:00 PM PST
Subject: [dispatch] New Proposal for Telephone-Related Queries


I have a proposal to bounce off the group. Basically, this is a re-examination of some of the problems we've previously considered in the telephony-specific cluster of work surrounding ENUM, DRINKS and SPEERMINT. Through discussions in the past couple years, it's become clear that we would need to significantly extend ENUM to get it to handle all of the sorts of sources, subjects, and attributes that people want to factor into queries about telephone number routing and administration. Most of these discussions have gotten wrapped around the axle on questions of the underlying syntax and semantics of the DNS, which were a good match for the original vision of a public, user-driven ENUM, but don't seem to be such a good match for the uses people actually want to make of these protocols, in federated, service-provider-driven environments like those envisioned in SPEERMINT and provisioned in DRINKS. While the discussion may have died down a bit, the requirements that motivated th
e discussion definitely aren't going away.

Rather than continue to debate the applicability of the DNS and the probity of various extensions to it, we might make more progress if we work towards agreement on the semantics of queries for telephone-related data independently of any underlying protocols. In other words, focus on what kinds of questions about telephone numbers we want to be able to ask, and what kinds of information needs to go into the answers, and incorporate all this into an abstract data model. So for example, we know that we want to be able to express the source of a request in a query. What do we mean by source? I can think of a bunch of different kinds of source: the logical originator of the query (the administrative entity asking), the logical identity of any intermediary or aggregator forwarding the query, or even the point at the network from which the call originates (the originating trunk group, SBC or what have you). All three of those concepts of source seem important when it comes to answe
ring questions about telephone numbers, so a data model would treat those as separate elements which can vary independently - then we can then try to figure out what's mandatory or optional, etc. We follow this same method for all the elements of queries and responses. Figure out what the attributes are of telephone numbers that we care about, sort them into buckets of routing data and administrative data, and so on.

Once we have an agreement on the data model, then people can map the model to whatever underlying protocol they'd like - or just build it into a web API, or what have you. Those proposals could advance as separate documents. Having that flexibility would make it a lot easier to figure out what we really want the questions and answers to be, rather than thinking about what they realistically can be within the constraints of some existing underlying protocol.

That's the idea. I'm not going to present a proposed charter for work or anything like that in Paris, but I am interested in hearing if people think this is a promising approach, and if so, perhaps we'd put a charter on the agenda for Vancouver. I have however submitted a -00 draft for this time which gives a high-level proposal for a data model and at least enumerates what some of the elements might be that would be populated in queries and responses. This is a pretty broad sketch, but it should convey the basic idea. You can check it out here:

https://datatracker.ietf.org/doc/draft-peterson-terq/

Any thoughts about the direction or the specifics of the data model are welcome. Thanks!

Jon Peterson
NeuStar, Inc.
_______________________________________________
dispatch mailing list
dispatch <at> ietf.org
https://www.ietf.org/mailman/listinfo/dispatch

_______________________________________________
enum mailing list
enum <at> ietf.org
https://www.ietf.org/mailman/listinfo/enum
Lawrence Conroy | 3 Mar 13:06 2012
Picon

Enumservice registrations

Hi esteemed AD, ENUMers,
 As a process issue:
-  Section 4.1 of RFC6117 suggests that authors of Enumservices should look for existing work in the Enum
mailing list.
-  Section 6.3 of RFC6117 states that authors MUST send a mail to the enum list with a link to the registration doc.

In the current case, Richard forwarded the id-announce mail for
draft-goix-appsawg-enum-sn-service-00.txt to the list; the authors have not.

So ...
 Can someone ensure at least that I-Ds for Enumservices are ALWAYS/Automatically sent to the enum mailing list?
(i.e., if it's an Enumservice, the enum mailing list is an interested party)

The application detail for Enumservices may well be covered in other WGs, but there must be a link the ENUM
mailing list.
Otherwise 6117 needs an update -- please, no!

all the best,
  Lawrence
Richard Shockey | 2 Mar 22:08 2012
Picon

FW: I-D Action: draft-goix-appsawg-enum-sn-service-00.txt


-----Original Message-----
From: i-d-announce-bounces <at> ietf.org [mailto:i-d-announce-bounces <at> ietf.org]
On Behalf Of internet-drafts <at> ietf.org
Sent: Friday, March 02, 2012 10:49 AM
To: i-d-announce <at> ietf.org
Subject: I-D Action: draft-goix-appsawg-enum-sn-service-00.txt

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

	Title           : ENUM Service Registration for Social Networking
(SN) Services
	Author(s)       : Laurent-Walter Goix
                          Kepeng Li
	Filename        : draft-goix-appsawg-enum-sn-service-00.txt
	Pages           : 7
	Date            : 2012-03-02

   This document registers a Telephone Number Mapping (ENUM) service for
   Social Networking (SN).  Specifically, this document focuses on
   provisioning 'acct:' URIs (Uniform Resource Identifiers) in ENUM.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-goix-appsawg-enum-sn-service-00.tx
t

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-goix-appsawg-enum-sn-service-00.txt

_______________________________________________
I-D-Announce mailing list
I-D-Announce <at> ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
Custodio e Mila Mestre | 29 Oct 17:40 2011
Picon

Can you Help me PLEASE with ENUM

 

 

Hello

I am a Customer of Voxalot, and i registered my numbers on e164.org to transform them into Enum: +351281 370 037, +351 962 843 398, +351281 961 366, +351 963 095 556 putting as SIP / / voxalot.com. I received a pin and actived them, should receive calls free from voip client, but they continue to pay for the calls. do i need to configure anything else in Voxalot or e164.org?

I created an Enum: +882 9999 708126 but that does not work.  instead of using SIP i used TEL 00 351 281 370 037, my home phone, do i must also configure in Voxalot and were in voxalot? Where am I going wrong? Help me please.

Thanks in advance.

Mila

 

_______________________________________________
enum mailing list
enum <at> ietf.org
https://www.ietf.org/mailman/listinfo/enum
Richard Shockey | 29 Sep 23:27 2011
Picon

Who said ENUM was dead?

 

 

Kari Hiatt-Moran | Communications Coordinator

CableLabs | 858 Coal Creek Circle, Louisville, CO 80027

303.661.3789 (office) | 303.664.8137 (fax) | k.hiatt <at> cablelabs.com

                                                                                          Contact:

 

                                                                        info <at> cablelabs.com

303-661-9100

FOR IMMEDIATE RELEASE

CableLabs® Launches Cable’s PeerConnect™ Registry for IP Communications

Louisville, Colorado, September 29, 2011 – CableLabs® today unveiled the PeerConnect™ registry, a cable operator service to facilitate end-to-end IP communications. 

The PeerConnect registry connects cable operators and their partners so they can exchange the data necessary to establish voice and video calls, SMS messages and other forms of IP communications between their respective networks.

“The PeerConnect registry allows Comcast to move telephone number translation services inside the IP domain,” said Phil Miller, Vice President, Strategic Partnership Development, Comcast Communications and Data services. “It provides a scalable solution for us to dynamically distribute numbers and other IP voice session routing data to select partners.”

“Cablevision has been using the PeerConnect registration services for some time with great success to disseminate IP session routing information to peers. It is a scalable solution for managing peering relationships and it is built on open standards to advertise session routing data to various valued-added service companies,” said Wayne Thompson, Vice President, Telecom and Internet Management at Cablevision Systems Corp.

“This initiative provides each operator an independent and secure way of managing its data distribution to enable dynamic peering relationships with cable and non-cable operator companies. In Canada, Shaw is leveraging the registry resolution service as a number translation service,” said Peter Bissonnette, President of Shaw Communications Inc.

The registry service also allows CableLabs member companies deploying mobile wireless services to distribute the wireless numbers they serve to a variety of SMS-MMS service providers.

“The PeerConnect registry is part of the SMS-MMS service platform Cox Wireless TMI has been leveraging with great success for its mobile rollout” said R.K. Gopinath, Director, Wireless Product Development & Management at Cox Communications.

Secure and Distributed Service Platform
CableLabs has built the PeerConnect registry service working with its member companies and a vendor ecosystem to simply enable a secure, distributed service platform for the provisioning and distribution of session related data for SMS-MMS and Voice over IP communications. Endorsed by several large and small cable operators in the United States and Canada, the PeerConnect registry has been in production since 2009.

“We have designed this service to accelerate the adoption of end-to-end IP communications and open up the possibilities for new real-time communication services” said Jean-François Mulé, CableLabs’ SVP of Technology Development and the PeerConnect program director since its inception. “We solved many parts of the dynamic and distributed provisioning issues by implementing Web Services and adopting an open protocol framework for data provisioning, resolution and replication working with numerous actors in the Internet Engineering Task Force (IETF) to agree on common standards,” he said.

The PeerConnect registry includes three main service elements:

·       A registration service allowing cable operators to dynamically provision various service data elements

·       A resolution service element for cable operators and their peering partners to perform number translation and routing queries to the registry using the IETF SIP and ENUM protocols

·       A replication element to dynamically distribute session routing data for SMS-MMS and VoIP to select partner companies

More information about the PeerConnect registry and how to participate is available at http://www.cablelabs.com/peerconnect or http://www.peerconnect.com.

About CableLabs: Founded in 1988 by members of the cable television industry, Cable Television Laboratories is a non-profit research and development consortium that is dedicated to pursuing new cable telecommunications technologies and to helping its cable operator members integrate those advancements into their business objectives. Cable operators from around the world are members. CableLabs maintains additional web sites at www.cablenet.org, www.ebif.tv and www.tru2way.com.

Advanced Digital Cable™, CableCARD™, CableHome®, CableLabs®, CableNET®, CablePC™, DCAS™, DPoE™, DOCSIS®, EBIF™, Go2BroadbandSM, M-Card™, OpenCable™, PacketCable™, PeerConnect™, and tru2way® are marks of Cable Television Laboratories, Inc.

 

 

 

 

Richard Shockey
Shockey Consulting
Chairman of the Board of Directors SIP Forum
PSTN Mobile: +1 703.593.2683
<mailto:richard(at)shockey.us>
skype-linkedin-facebook: rshockey101
http//www.sipforum.org

 

_______________________________________________
enum mailing list
enum <at> ietf.org
https://www.ietf.org/mailman/listinfo/enum

Gmane