Draft enum webfinger revised

Hello Lawrence, all,

I have just submitted a revision of the enum draft for webfinger based on t=
he 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 protected]] =

Inviato: luned=EC 26 marzo 2012 16.30
A: Goix Laurent Walter
Cc: IETF ENUM list; [email protected]
Oggetto: Re: [Enum] R: FW: I-D Action: draft-goix-appsawg-enum-sn-service-0=
0.txt

Hi Walter, folks,

- Hmm ... to spell this out:
  see RFC6116, section 3, para.2, 2nd sentence, parenthetic phrase; ENUM us=
e is within the e164.arpa apex.
=3D> 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.

=3D> Likewise, the last sentence of section 5, paragraph 2 doesn't appear t=
o help.
   This security mechanism would require changing the position of groups of=
 regulators,
   potentially the esteemed members of ITU study groups, and would take yea=
rs 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.a=
rpa, but with a private root.

  There's nothing stopping a CSP or anyone deploying NAPTRs holding ENUM-sp=
ecified 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 R=
FC5483) 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 i=
t 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 abo=
ut standardising complex behaviour that seems to be outside the ENUM protoc=
ol 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 N=
APTRs with acct Enumservice (as that functional specification would seem to=
 be needed by rfc6117 section 3.1). Otherwise, remove the proposed "recursi=
ve behaviour" by removing section 4 para 2.

all the best,
  Lawrence

On 21 Mar 2012, at 16:44, Goix Laurent Walter wrote:
> Hello lawrence, all,
> =

> I'd like to resume the discussion on the draft in this list, as at this s=
tage 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 rfc611=
6 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 ref=
erence 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 pa=
ragraph 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 in=
tention here would be to clarify that if no "acct" record is found, subsequ=
ent enum queries could apply recursively to any e164 number found in record=
s containing tel URIs independently from the specific service, still aiming=
 at identifying an "acct" uri. I could further imagine that the idea to mit=
igate loops would be based on rfc4759 principles so that when the same numb=
er 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 servi=
ces?
> =

> Thank you
> Walter
> =

> =

> -----Messaggio originale-----
> Da: Lawrence Conroy [mailto:[email protected]]
> 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 dr=
aft.
> =

> 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 sp=
ells out that a separate apex may be used.
> That directly contradicts its example, and in any case the Enumservice te=
mplate is incorrect for such private use (in that case, it would need to be=
 "limited", not "common" -- see RFC6117 section 5.2.7 **).
> =3D> 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 u=
se given in RFC4769 section 3.1, but ...
> =

> The last bullet of section 5.5 of RFC6117 states that the registration do=
c needs to cover loop mitigation.
> It may be unfair, but RFC4769 was not covered by the current rules, so th=
ey dodged the bullet of that requirement.
> This draft can't, so you will have to spell out the rules for loop mitiga=
tion.
> Merely referring to RFC4694 is not enough; see the last sentence of secti=
on 5 of RFC4694.
> =

> Finally, section 5 mentions an "activity wall". I wonder if anyone will k=
now 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 covere=
d by 6117]
> =

> =

> On 2 Mar 2012, at 21:08, Richard Shockey wrote:
>> -----Original Message-----
>> From: [email protected] [mailto:[email protected]=
g]
>> On Behalf Of [email protected]
>> Sent: Friday, March 02, 2012 10:49 AM
>> To: [email protected]
>> 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-0=
0.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
> =

> =

> Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle p=
ersone indicate. La diffusione, copia o qualsiasi altra azione derivante da=
lla conoscenza di queste informazioni sono rigorosamente vietate. Qualora a=
bbiate ricevuto questo documento per errore siete cortesemente pregati di d=
arne immediata comunicazione al mittente e di provvedere alla sua distruzio=
ne, Grazie.
> =

> This e-mail and any attachments is confidential and may contain privilege=
d information intended for the addressee(s) only. Dissemination, copying, p=
rinting or use by anybody else is unauthorised. If you are not the intended=
 recipient, please delete this message and any attachments and advise the s=
ender by return e-mail, Thanks.
> =

> _______________________________________________
> enum mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/enum