Subject: [Enum] FW: I-D Action: draft-goix-appsawg-enum-sn-service-00.txt

From: "Richard Shockey" <[email-masked]>
Date: Fri, 2 Mar 2012 16:08:39 -0500

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of [email-masked]
Sent: Friday, March 02, 2012 10:49 AM
To: [email-masked]
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
[email-masked]
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

---

From: Lawrence Conroy <[email-masked]>
Date: Sat, 3 Mar 2012 13:00:08 +0000

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]

---

From: "Richard Shockey" <[email-masked]>
Date: Sat, 3 Mar 2012 10:38:34 -0500

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:[email-masked]] 
Sent: Saturday, March 03, 2012 8:00 AM
To: [email-masked]
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]

---

From: Lawrence Conroy <[email-masked]>
Date: Sat, 3 Mar 2012 18:09:53 +0000

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

---

From: "Richard Shockey" <[email-masked]>
Date: Sat, 3 Mar 2012 13:25:28 -0500

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:[email-masked]] 
Sent: Saturday, March 03, 2012 1:10 PM
To: Richard Shockey
Cc: 'IETF ENUM list'
Subject: Re: [Enum] FW: I-D Action:

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.

---

From: Goix Laurent Walter <[email-masked]>
Date: Wed, 21 Mar 2012 17:44:57 +0100

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 experience of similar enum services?

Thank you
Walter

-----Messaggio originale-----
Da: Lawrence Conroy [mailto:[email-masked]]
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

all the best,
  Lawrence

> ftp://ftp.ietf.org/internet-drafts/draft-goix-appsawg-enum-sn-service-00.txt

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.

---

From: Lawrence Conroy <[email-masked]>
Date: Mon, 26 Mar 2012 15:29:54 +0100

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

---

From: Goix Laurent Walter <[email-masked]>
Date: Tue, 27 Mar 2012 18:53:31 +0200

Thank you lawrence for your accurate feedback,

[snip]

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

[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

---

From: Goix Laurent Walter <[email-masked]>
Date: Fri, 30 Mar 2012 12:46:00 +0200

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:[email-masked]] 
Inviato: lunedì 26 marzo 2012 16.30
A: Goix Laurent Walter
Cc: IETF ENUM list; [email-masked]
Oggetto: Re: [Enum] R: FW: I-D Action: draft-goix-appsawg-enum-sn-service-00.txt

Hi Walter, folks,

all the best,
  Lawrence