gmane.ietf.enum

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

Bernie Hoeneisen — 2013-05-11T12:30:45

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

Enum service registration for acct: URI

Goix Laurent Walter — 2012-07-13T04:55:04

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

Re: Social ENUM / Patents and Intellectual Property

Worley, Dale R (Dale — 2012-04-03T15:00:16

Care to tell us the patent or patent application numbers?

It would also be seen as a sign of good faith if you filed IPR
disclosures (https://datatracker.ietf.org/ipr/new-specific/)
referencing your patents and draft-goix-appsawg-enum-sn-service-00.

Dale

Re: Social ENUM / Patents and Intellectual Property

Richard Shockey — 2012-04-03T13:51:57

The original ENUM usage btw was in 1993 in RFC 1530. 

If someone has a intellectual property claim then it has to be posted in the
usual manner outlined in RFC 3979.



-----Original Message-----
From: enum-bounces< at >ietf.org [mailto:enum-bounces< at >ietf.org] On Behalf Of
Lawrence Conroy
Sent: Tuesday, April 03, 2012 4:01 AM
To: Duane
Cc: enum< at >ietf.org; eric< at >telesocial.com
Subject: Re: [Enum] Social ENUM / Patents and Intellectual Property

Hi Duane, Eric, folks,

 Hi Duane ... You too :).

----
All I'll say on this (apart from the exclusively personal "good luck") is --
There are many ways of doing this, and in many places in DNS.

Do you think Telnic might have thought of the kinds of info that people
could want to publish **before** we went for the .tel CCTLD in 2004?
(and yes, there was an attempt in the earlier 2000 round, but that time the
ITU stamped on all things vaguely related to telephony).
LJ was the coming star at that point -- how times change.

For some more RW examples ..
See <http://social.henri

Re: Social ENUM / Patents and Intellectual Property

Lawrence Conroy — 2012-04-03T08:00:47

Hi Duane, Eric, folks,

 Hi Duane ... You too :).

----
All I'll say on this (apart from the exclusively personal "good luck") is -- There are many ways of doing this, and in many places in DNS.

Do you think Telnic might have thought of the kinds of info that people could want to publish **before** we went for the .tel CCTLD in 2004?
(and yes, there was an attempt in the earlier 2000 round, but that time the ITU stamped on all things vaguely related to telephony).
LJ was the coming star at that point -- how times change.

For some more RW examples ..
See <http://social.henri.tel> or dig social.henri.tel for NAPTR
(henri.tel is not a web site, it points at a proxy that digs and presents the content in a web response)

or dig instant-messaging.henri.tel for NAPTR, or ...

[Re. avoiding the standard process -- I feel your pain.
When we finally got around to registering IM, the blatantly obvious way to do this was overtaken by the cultish pres and im Enumservices, which sure convinced me that just doing it was

Re: Social ENUM / Patents and Intellectual Property

Duane — 2012-04-03T05:39:27

e164.org was publishing IM and other social network information via DNS 
at least as far back as December 2006, I'd have to check the mailing 
list archive for specific dates.

And before it gets pointed out, no we didn't use SN, but that seems an 
incremental and/or novel change over what we are doing.
_______________________________________________
enum mailing list
enum< at >ietf.org
https://www.ietf.org/mailman/listinfo/enum

Social ENUM / Patents and Intellectual Property

Eric Stone — 2012-04-03T04:56:19

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 l

Draft enum webfinger revised

Goix Laurent Walter — 2012-03-30T10:46:00

Hello Lawrence, all,

I have just submitted a revision of the enum draft for webfinger based on the various feedback received so far. You can find it at [1].

Comments are welcome.

Walter

[1] http://tools.ietf.org/html/draft-goix-appsawg-enum-sn-service-01 


-----Messaggio originale-----
Da: Lawrence Conroy [mailto:lconroy< at >insensate.co.uk] 
Inviato: lunedì 26 marzo 2012 16.30
A: Goix Laurent Walter
Cc: IETF ENUM list; likepeng< at >huawei.com
Oggetto: Re: [Enum] R: FW: I-D Action: draft-goix-appsawg-enum-sn-service-00.txt

Hi Walter, folks,

- Hmm ... to spell this out:
  see RFC6116, section 3, para.2, 2nd sentence, parenthetic phrase; ENUM use is within the e164.arpa apex.
=> please don't cover different apexes in an ENUM spec;
   remove section 4 para 1 of your draft entirely as it does't help, and it DOES hinder.

=> Likewise, the last sentence of section 5, paragraph 2 doesn't appear to help.
   This security mechanism would require changing the position of groups of regulators,
   potentially the esteem

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

Goix Laurent Walter — 2012-03-27T16:53:31

Thank you lawrence for your accurate feedback,

[snip]

- Hmm ... to spell this out:
  see RFC6116, section 3, para.2, 2nd sentence, parenthetic phrase; ENUM use is within the e164.arpa apex.
=> please don't cover different apexes in an ENUM spec;
   remove section 4 para 1 of your draft entirely as it does't help, and it DOES hinder.

=> Likewise, the last sentence of section 5, paragraph 2 doesn't appear to help.
   This security mechanism would require changing the position of groups of regulators,
   potentially the esteemed members of ITU study groups, and would take years to arrange;
   boiling the ocean would be easier.

Re. the implied question on RFC 6116;
  6116, section 3.6 talks about ENUM use in networks that are not directly connected to the Internet;
  the assumption is that these closed networks would/could still use e164.arpa, but with a private root.

  There's nothing stopping a CSP or anyone deploying NAPTRs holding ENUM-specified Enumservices inside any apex;
  this is spelt out in (for

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

Lawrence Conroy — 2012-03-26T14:29:54

Hi Walter, folks,

- Hmm ... to spell this out:
  see RFC6116, section 3, para.2, 2nd sentence, parenthetic phrase; ENUM use is within the e164.arpa apex.
=> please don't cover different apexes in an ENUM spec;
   remove section 4 para 1 of your draft entirely as it does't help, and it DOES hinder.

=> Likewise, the last sentence of section 5, paragraph 2 doesn't appear to help.
   This security mechanism would require changing the position of groups of regulators,
   potentially the esteemed members of ITU study groups, and would take years to arrange;
   boiling the ocean would be easier.

Re. the implied question on RFC 6116; 
  6116, section 3.6 talks about ENUM use in networks that are not directly connected to the Internet;
  the assumption is that these closed networks would/could still use e164.arpa, but with a private root.

  There's nothing stopping a CSP or anyone deploying NAPTRs holding ENUM-specified Enumservices inside any apex;
  this is spelt out in (for example) the *Informational* RFC 552

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

Goix Laurent Walter — 2012-03-21T16:44:57

Hello lawrence, all,

I'd like to resume the discussion on the draft in this list, as at this stage it seems more appropriate.

I could see that a couple of points (mostly in section 4) have triggered some concerns that I'd like to clarify and seek for your guidance:

-       the first paragraph of section 4, despite its poor wording, wants to point out that this service may be *also* used in enum "infrastructures" other than "e164.arpa", for example in cases where such infrastructure is restricted to CSPs (e.g. "e164.gprs" or others). My feeling is that rfc6116 does mentions this possibility somehow (e.g. see section 3.6) but I can't find a clear section where to refer to more formally (I agree that the reference to section 2 was a bad choice for it). Is there any other reference that could be used for this?

-       regarding loop mitigation it was my intention to address it in paragraph 2 of section 4, but the wording was not appropriate neither (and I realized there is no clear mention on when the proces

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

Richard Shockey — 2012-03-06T17:08:13

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

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

Peterson, Jon — 2012-03-05T23:34:28

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<mailto:jon.peterson< at >neustar.biz>>
Date: March 5, 2012 1:51:00 PM PST
To: "dispatch< at >ietf.org<mailto:dispatch< at >ietf.org>" <dispatch< at >ietf.org<mailto: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, w

Re: Enumservice registrations

Lawrence Conroy — 2012-03-05T14:07:22

On 5 Mar 2012, at 12:51, Peter Koch wrote:

To which I reply:
Hi Peter, Richard, folks,
 Fair enough.
This was *not* a dig at these specific authors -- lord knows I've made enough mistakes and had drafts not marked for the WG in which they were being considered, let alone this case where there are two separate groups that have an interest.

I do recall some confusion in the past that was caused by lack of communication between groups when NAPTRs were being [re-]defined.
The URN folk went their way, the ENUM-URI folk went their way with the SIP folk roughly in allignment, and as for (u)SNAPTRs folk, they were somewhere else again.
I contend that coordination between those groups would have made life easier for all, and certainly would have led to fewer bugs in ENUM code from people looking at examples in entirely unrelated drafts (and so made my life easier).

Given that even the best of us (i.e., me :), make mistakes, how that coordination is arranged at an early enough state to make life easy for the autho

Re: Enumservice registrations

Peter Koch — 2012-03-05T12:51:42


i'd suggest not to install any magic or automated action here.  Maybe the process
wasn't followed, but then we do probably not know what the current status
of the draft is.  Ideally, it would benefit from review on this list even as a -00,
but in that regard there's nothing wrong with further discussion.  Automated action
would lead to undesired effects and also educate authors in the wrong direction.

-Peter

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

Richard Shockey — 2012-03-03T18:25:28

Don't get me wrong.  I thought your comments were excellent and completely
in line with the intent and letter of 6117. If the authors make these
changes than its good to go IMHO. 

As for MetaData

Note mandate for Carrier ENUM. Paragraph 70

http://www.crtc.gc.ca/eng/archive/2012/2012-24.htm

-----Original Message-----
From: Lawrence Conroy [mailto:lconroy< at >insensate.co.uk] 
Sent: Saturday, March 03, 2012 1:10 PM
To: Richard Shockey
Cc: 'IETF ENUM list'
Subject: Re: [Enum] FW: I-D Action:
draft-goix-appsawg-enum-sn-service-00.txt

Hi Richard, folks,
 Um -- yeah?
Just in case there was some misunderstanding, neither do I. If someone wants
to use this stuff, bring it on.
(considering the welter of stuff I've put into ENUM, I'm hardly in a
position to complain :).

I don't think the comments I put in were unreasonable -- these will need to
be fixed, so rather than slow things down later I put in comments on the
ENUM-y bits now.

The registration process of 6117 is designed to (i) make the registration
process e

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

Lawrence Conroy — 2012-03-03T18:09:53

Hi Richard, folks,
 Um -- yeah?
Just in case there was some misunderstanding, neither do I. If someone wants to use this stuff, bring it on.
(considering the welter of stuff I've put into ENUM, I'm hardly in a position to complain :).

I don't think the comments I put in were unreasonable -- these will need to be fixed, so rather than slow things down later I put in comments on the ENUM-y bits now.

The registration process of 6117 is designed to (i) make the registration process easier and (ii) cover the bases that need to be covered so folk can build/use this stuff (not just put it in a document and forget it).

This is one of the first ones through that new process, and its from apps area/W3C/OMA-led work. Helping folk to ensure it does actually tick the 6117 boxes is hardly meant to be awkward.

all the best from a bemused
  Lawrence



On 3 Mar 2012, at 15:38, Richard Shockey wrote:

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

Richard Shockey — 2012-03-03T15:38:34

What's the big deal here.  Sure they can clean up some text, but the intent
of the process was to make these things simple.  This is another Carrier
ENUM concept probably in association with RCS or some other scheme.  And
there are lot more coming.

I certainly have no objection to this registration moving forward.

FYI I have it on good authority that the meta data issue is coming back.

-----Original Message-----
From: Lawrence Conroy [mailto:lconroy< at >insensate.co.uk] 
Sent: Saturday, March 03, 2012 8:00 AM
To: laurentwalter.goix< at >telecomitalia.it
Cc: Richard Shockey; IETF ENUM list
Subject: Re: [Enum] FW: I-D Action:
draft-goix-appsawg-enum-sn-service-00.txt

Hi Laurent-Walter, Richard, folks,
 As one of the authors of RFC6116, I'm intrigued with section 4 of this
draft.

AFAICT, section 4 of this draft specifically states that E2U+acct can be
used in an entirely different namespace from ENUM. That's an interpretation
of 6116 section 2 that I don't recognise.

The second paragraph of Section 5 is ambivalent

Re: Enumservice registrations

Bernie Hoeneisen — 2012-03-03T13:06:41

Hi Lawrence

Thanks for sharing your view on the Enumservice registration process wrt. 
draft-goix-appsawg-enum-sn-service-00.txt. And thanks Rich for spotting 
this I/D and forwarding it to the ENUM list.

It appears to me that the authors simply have not read RFC 6117 too 
thoroughly, and therefore don't follow the RFC-6117-process.

However, I am not worried at this point in time, as the I/D is a -00 
individual submission. Furthermore, before any Enumservice advances, it 
has to go through my hands, and I will ensure each proposal gets 
sufficient community review (in particular ENUM community), before any 
decision is made. Thus, not-follow-the-process simply results in delay, 
which the authors otherwise could avoid.

Should I happen to meet the authors in Paris, I'll talk to them about 
this.

I hope this addresses your concerns.

cheers,
  Bernie, IESG Designated Expert for ENUM


PS: And no, we are not intending to update RFC 6117 any time soon... ;-)

--

http://ucom.ch/
Tech Consulting for Interne

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

Lawrence Conroy — 2012-03-03T13:00:08

Hi Laurent-Walter, Richard, folks,
 As one of the authors of RFC6116, I'm intrigued with section 4 of this draft.

AFAICT, section 4 of this draft specifically states that E2U+acct can be used in an entirely different namespace from ENUM. That's an interpretation of 6116 section 2 that I don't recognise.

The second paragraph of Section 5 is ambivalent on this, but section 4 spells out that a separate apex may be used.
That directly contradicts its example, and in any case the Enumservice template is incorrect for such private use (in that case, it would need to be "limited", not "common" -- see RFC6117 section 5.2.7 **).
=> Was that intended -- does that first paragraph of section 4 of this draft help?

As I understand the second paragraph of section 4, the intention is that an implementation will chase pstn:tel records looking for a domain with an appropriate E2U+acct record. That looks like it's stretching the pstn:tel use given in RFC4769 section 3.1, but ...

The last bullet of section 5.5 of RFC6117 st

Enumservice registrations

Lawrence Conroy — 2012-03-03T12:06:33

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