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

Goix Laurent Walter <laurentwalter.goix@telecomitalia.it> Tue, 27 March 2012 16:54 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 37E9A21E80CF for <enum@ietfa.amsl.com>; Tue, 27 Mar 2012 09:54:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.232
X-Spam-Level:
X-Spam-Status: No, score=-0.232 tagged_above=-999 required=5 tests=[AWL=-0.372, BAYES_20=-0.74, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, 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 w2GVAE3piitA for <enum@ietfa.amsl.com>; Tue, 27 Mar 2012 09:54:05 -0700 (PDT)
Received: from GRFEDG702BA020.telecomitalia.it (grfedg702ba020.telecomitalia.it [156.54.233.201]) by ietfa.amsl.com (Postfix) with ESMTP id A54E921E80A4 for <enum@ietf.org>; Tue, 27 Mar 2012 09:53:43 -0700 (PDT)
Received: from GRFHUB703BA020.griffon.local (10.188.101.113) by GRFEDG702BA020.telecomitalia.it (10.188.45.101) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 27 Mar 2012 18:53:33 +0200
Received: from GRFMBX704BA020.griffon.local ([10.188.101.16]) by GRFHUB703BA020.griffon.local ([10.188.101.113]) with mapi; Tue, 27 Mar 2012 18:53:33 +0200
From: Goix Laurent Walter <laurentwalter.goix@telecomitalia.it>
To: Lawrence Conroy <lconroy@insensate.co.uk>
Date: Tue, 27 Mar 2012 18:53:31 +0200
Thread-Topic: [Enum] R: FW: I-D Action: draft-goix-appsawg-enum-sn-service-00.txt
Thread-Index: Ac0LXPSbpPO/zzYuTwuH/PGJJ5+tQQA2p+Ow
Message-ID: <A09A9E0A4B9C654E8672D1DC003633AE52EDC520CA@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, it-IT
Content-Language: it-IT
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US, it-IT
x-ti-disclaimer: Disclaimer1
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: IETF ENUM list <enum@ietf.org>, "likepeng@huawei.com" <likepeng@huawei.com>
Subject: [Enum] R: R: FW: I-D Action: draft-goix-appsawg-enum-sn-service-00.txt
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: Tue, 27 Mar 2012 16:54:06 -0000

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.