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 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.

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.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 easier than arguing. The real world
intruded we have ugly NAPTRs in .tel; sigh]

BTW, speaking of different ways of doing this, see the ENUM FOAF stuff from
2006 for example.

SN records can be taken much further, but the privacy concerns are
ridiculous, so it only works (with sane privacy) with proper encryption.
That's hard in DNS (unless one uses something like
<http://tools.ietf.org/html/draft-timms-encrypt-naptr-01>, and publishes
data for one's friends only, of course).
----

all the best,
  Lawrence

On 3 Apr 2012, at 06:39, Duane wrote:
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.
least as far back as December 2006, I'd have to check the mailing list
archive for specific dates.
incremental and/or novel change over what we are doing.

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

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 easier than arguing. The real world intruded we have ugly NAPTRs in .tel; sigh]

BTW, speaking of different ways of doing this, see the ENUM FOAF stuff from 2006 for example.

SN records can be taken much further, but the privacy concerns are ridiculous, so it only works (with sane privacy) with proper encryption.
That's hard in DNS (unless one uses something like <http://tools.ietf.org/html/draft-timms-encrypt-naptr-01>, and publishes data for one's friends only, of course).
----

all the best,
Lawrence

On 3 Apr 2012, at 06:39, Duane wrote:
fically 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.

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 list
enum< at >ietf.org
https://www.ietf.org/mailman/listinfo/enum

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 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 5526.

- Re. loop control -- 6116 section 5.2.1, paragraphs 6&7&8 (and before it RFC5483) already gives one way to do loop mitigation for non-terminal NAPTRs
  (basically, count to 5 and give up).
  However, now you have explained your section 4, para 2, this looks like it will need quite a bit of work to be a detailed and clear specification;
  (so clients can behave the same way).
  Right now, I'm not sure if and how this would work whilst keeping within the processing rules of the ENUM specification (i.e. 6116 plus 340x).
  Is it really useful to include this recursive behaviour?
  Personally I would discard section 4, paragraph 2 as well, and forget about standardising complex behaviour that seems to be outside the ENUM protocol spec.

In summary, lose section 4, para.1 and the last sentence of section 5, para.2.

Then, if you really, really, really want to go there, work out what clients that understand this Enumservice are supposed to do if there are no ENUM NAPTRs with acct Enumservice (as that functional specification would seem to be needed by rfc6117 section 3.1). Otherwise, remove the proposed "recursive behaviour" by removing section 4 para 2.

all the best,
  Lawrence

On 21 Mar 2012, at 16:44, Goix Laurent Walter wrote:

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 example) the *Informational* RFC 5526.

[walter] ok I got your point and will update removing the references you pointed you

- Re. loop control -- 6116 section 5.2.1, paragraphs 6&7&8 (and before it RFC5483) already gives one way to do loop mitigation for non-terminal NAPTRs
(basically, count to 5 and give up).
However, now you have explained your section 4, para 2, this looks like it will need quite a bit of work to be a detailed and clear specification;
(so clients can behave the same way).
Right now, I'm not sure if and how this would work whilst keeping within the processing rules of the ENUM specification (i.e. 6116 plus 340x).
Is it really useful to include this recursive behaviour?
Personally I would discard section 4, paragraph 2 as well, and forget about standardising complex behaviour that seems to be outside the ENUM protocol spec.

[walter] i tried to better capture the loop mitigation process in the following text for section 4:

" If no "E2U+sn" NAPTR record exist for the requested number, the resolution process over issuing ENUM queries may be recursively performed over E.164 numbers identified by other NAPTR records for the requested number pointing to "tel" URIs [RFC3966]. Whilst this process is useful to support, amongst others, number portability as per [RFC4769], Section 4., this may also create potential loops in this resolution process. As such ENUM clients performing such ENUM queries over "tel" URIs to identify "acct" URIs SHOULD understand the "enumdi" indicator defined in [RFC4759]. In particular, if the result of the query does not include "E2U+sn" NAPTR records, and includes a NAPTR resource record containing a "tel" URI that has the same E.164 number, or a "tel" URI with the "enumdi" parameter set,
that client SHOULD NOT perform subsequent ENUM queries over such numbers and SHOULD consider that the original requested number cannot be mapped.

Furthermore the client MAY stop performing subsequent ENUM queries after the fifth recursive query as suggested in [RFC6116] section 5.2.1."

I would appreciate any further feedback on this proposal or other aspects of the draft.

Thank you
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.

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

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

Hi Walter, folks,

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 5526.

In summary, lose section 4, para.1 and the last sentence of section 5, para.2.

Then, if you really, really, really want to go there, work out what clients that understand this Enumservice are supposed to do if there are no ENUM NAPTRs with acct Enumservice (as that functional specification would seem to be needed by rfc6117 section 3.1). Otherwise, remove the proposed "recursive behaviour" by removing section 4 para 2.

all the best,
Lawrence

On 21 Mar 2012, at 16:44, Goix Laurent Walter wrote:
nce of similar enum services?

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 process should stop). The intention here would be to clarify that if no "acct" record is found, subsequent enum queries could apply recursively to any e164 number found in records containing tel URIs independently from the specific service, still aiming at identifying an "acct" uri. I could further imagine that the idea to mitigate loops would be based on rfc4759 principles so that when the same number is found, or another one containing a dip indicator the recursion should be stopped and the process considered completed with no acct uri found. Do you have any recommendation based on your experienc
 e of similar enum services?

Thank you
Walter


-----Messaggio originale-----
Da: Lawrence Conroy [mailto:lconroy< at >insensate.co.uk]
Inviato: sabato 3 marzo 2012 14.00
A: Goix Laurent Walter
Cc: Richard Shockey; IETF ENUM list
Oggetto: 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 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 states that the registration doc needs to cover loop mitigation.
It may be unfair, but RFC4769 was not covered by the current rules, so they dodged the bullet of that requirement.
This draft can't, so you will have to spell out the rules for loop mitigation.
Merely referring to RFC4694 is not enough; see the last sentence of section 5 of RFC4694.

Finally, section 5 mentions an "activity wall". I wonder if anyone will know what that means in 10 years time.
It is not mentioned directly in the webfinger draft, so if it's spelt out in the referenced OMA service document, from where can one get that spec?

all the best,
  Lawrence
** [E2U+pstn:tel was registered under the "old" rules; this one is covered by 6117]


On 2 Mar 2012, at 21:08, Richard Shockey wrote:


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.

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: 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

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, 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<mailto: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

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 authors is the trick.
Taking your point, automation is the wrong kind of education; conversely, so are cattle prods.
Let's see if this is a common issue (especially with Richard's dark threats of tilting at the E2MD windmill again).

all the best,
  Lawrence

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 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:
intent

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 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 states that the registration doc
needs to cover loop mitigation.
It may be unfair, but RFC4769 was not covered by the current rules, so they
dodged the bullet of that requirement.
This draft can't, so you will have to spell out the rules for loop
mitigation.
Merely referring to RFC4694 is not enough; see the last sentence of section
5 of RFC4694.

Finally, section 5 mentions an "activity wall". I wonder if anyone will know
what that means in 10 years time.
It is not mentioned directly in the webfinger draft, so if it's spelt out in
the referenced OMA service document, from where can one get that spec?

all the best,
  Lawrence
** [E2U+pstn:tel was registered under the "old" rules; this one is covered
by 6117]


On 2 Mar 2012, at 21:08, Richard Shockey wrote:
http://www.ietf.org/internet-drafts/draft-goix-appsawg-enum-sn-service-00.tx
ftp://ftp.ietf.org/internet-drafts/draft-goix-appsawg-enum-sn-service-00.txt

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 Internet Technology


On Sat, 3 Mar 2012, Lawrence Conroy wrote:

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 states that the registration doc needs to cover loop mitigation.
It may be unfair, but RFC4769 was not covered by the current rules, so they dodged the bullet of that requirement.
This draft can't, so you will have to spell out the rules for loop mitigation.
Merely referring to RFC4694 is not enough; see the last sentence of section 5 of RFC4694.

Finally, section 5 mentions an "activity wall". I wonder if anyone will know what that means in 10 years time.
It is not mentioned directly in the webfinger draft, so if it's spelt out in the referenced OMA service document, from where can one get that spec?

all the best,
  Lawrence
** [E2U+pstn:tel was registered under the "old" rules; this one is covered by 6117]


On 2 Mar 2012, at 21:08, Richard Shockey wrote:

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