[Enum] Draft enum webfinger revised

Goix Laurent Walter <laurentwalter.goix@telecomitalia.it> Fri, 30 March 2012 10:46 UTC

Return-Path: <laurentwalter.goix@telecomitalia.it>
X-Original-To: enum@ietfa.amsl.com
Delivered-To: enum@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E6F321F867F for <enum@ietfa.amsl.com>; Fri, 30 Mar 2012 03:46:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.896
X-Spam-Level:
X-Spam-Status: No, score=-0.896 tagged_above=-999 required=5 tests=[AWL=0.223, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V+9uHzWcgXrc for <enum@ietfa.amsl.com>; Fri, 30 Mar 2012 03:46:08 -0700 (PDT)
Received: from GRFEDG702BA020.telecomitalia.it (grfedg702ba020.telecomitalia.it [156.54.233.201]) by ietfa.amsl.com (Postfix) with ESMTP id DADB221F8643 for <enum@ietf.org>; Fri, 30 Mar 2012 03:46:07 -0700 (PDT)
Received: from GRFHUB701BA020.griffon.local (10.188.101.111) by GRFEDG702BA020.telecomitalia.it (10.188.45.101) with Microsoft SMTP Server (TLS) id 8.2.254.0; Fri, 30 Mar 2012 12:46:03 +0200
Received: from GRFMBX704BA020.griffon.local ([10.188.101.16]) by grfhub701ba020.griffon.local ([10.188.101.111]) with mapi; Fri, 30 Mar 2012 12:46:03 +0200
From: Goix Laurent Walter <laurentwalter.goix@telecomitalia.it>
To: Lawrence Conroy <lconroy@insensate.co.uk>
Date: Fri, 30 Mar 2012 12:46:00 +0200
Thread-Topic: Draft enum webfinger revised
Thread-Index: Ac0LXPSbpPO/zzYuTwuH/PGJJ5+tQQDBDa5g
Message-ID: <A09A9E0A4B9C654E8672D1DC003633AE52EDC52C92@GRFMBX704BA020.griffon.local>
References: <01da01ccf8b8$a535d020$efa17060$@us> <35C11485-CA99-49CB-908A-BF74C4CB24E9@insensate.co.uk> <A09A9E0A4B9C654E8672D1DC003633AE52EDAFA343@GRFMBX704BA020.griffon.local> <8F408DE1-00A8-414E-9A41-1E09ED4B0685@insensate.co.uk>
In-Reply-To: <8F408DE1-00A8-414E-9A41-1E09ED4B0685@insensate.co.uk>
Accept-Language: en-US
Content-Language: it-IT
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
x-ti-disclaimer: Disclaimer1
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: IETF ENUM list <enum@ietf.org>, "likepeng@huawei.com" <likepeng@huawei.com>
Subject: [Enum] Draft enum webfinger revised
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/enum>, <mailto:enum-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/enum>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/enum>, <mailto:enum-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 30 Mar 2012 10:46:09 -0000

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@insensate.co.uk] 
Inviato: lunedì 26 marzo 2012 16.30
A: Goix Laurent Walter
Cc: IETF ENUM list; likepeng@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:
> 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:lconroy@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:
>> -----Original Message-----
>> From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org]
>> On Behalf Of internet-drafts@ietf.org
>> Sent: Friday, March 02, 2012 10:49 AM
>> To: i-d-announce@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
> 
> 
> 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.
> 
> _______________________________________________
> enum mailing list
> enum@ietf.org
> https://www.ietf.org/mailman/listinfo/enum