Subject: RE: [Enum] Benefits of "Carrier" / "User" enumservices

From: "Lind, Steven D, ALABS" <[email-masked]>
Date: Wed, 15 Jun 2005 16:09:04 -0400

It seems to that if this is the case, the template does not cover all the cases described in RFC 3761. Do we need a second template for non-terminal NAPTRs or change the existing template (and associated instructions) to incorporate both types of NAPTRs.

Steve Lind

--------------------------------------------------------------------------------
Steven D. Lind                                Tel: 973-236-6787
180 Park Avenue                             Fax: 360-343-2875
Room A201                                    sdlind at att.com
Florham Park, NJ 07932
--------------------------------------------------------------------------------

> -----Original Message-----
> From: enum-bounces at ietf.org [mailto:enum-bounces at ietf.org]On Behalf Of
> Stastny Richard
> Sent: Wednesday, June 15, 2005 3:32 PM
> To: Pfautz, Penn L, NEO; Fullbrook Kim (UK); enum at ietf.org
> Subject: Re: [Enum] Benefits of "Carrier" / "User" enumservices
> 
> 
> Penn,
>  
> I am not the one to answer you THIS question ;-)
> but IMHO we have here a catch 22
> because in the replacement field there cannot be 
> an URI at all, the enumservice template is 
> only valid for flag 'u' and not for non-terminal NAPTRs
>  
> regards
> Richard
> 
> ________________________________
> 
> Von: Pfautz, Penn L, NEO [mailto:ppfautz at att.com]
> Gesendet: Mi 15.06.2005 21:12
> An: Stastny Richard; Fullbrook Kim (UK); enum at ietf.org
> Betreff: RE: [Enum] Benefits of "Carrier" / "User" enumservices
> 
> 
> 
> Richard.
> Fair enough. I confess to some uncertainty re how to populate the URI
> part of the template for non-terminals. I toyed with 
> something like "all
> URI schemes registered under any other enumservice." Would that have
> been better?
> 
> Penn
> 
> -----Original Message-----
> From: Stastny Richard [mailto:Richard.Stastny at oefeg.at]
> Sent: Wednesday, June 15, 2005 3:08 PM
> To: Pfautz, Penn L, NEO; Fullbrook Kim (UK); enum at ietf.org
> Subject: Re: [Enum] Benefits of "Carrier" / "User" enumservices
> 
> Penn,
> 
> a minor correction:
> you are correct that according to RFC 3761 a client should be able
> to process non-terminal NAPTRs as defined, which means NAPTRs
> having only "E2U" in the enumservice field, without any additional
> enumservices defined. The original intention was that you query
> the domain given for NAPTRs and THEN decide which enumservice
> to use.
> 
> The definitions of the enumservices "user" and "carrier" you draft
> is NOT according to the template in RFC 3761, because you MUST define
> the URIs valid for this enumservice (and not N/A), as Lawrence already
> pointed out.
> 
> In addition, even if clients have implemented the capability to use
> non-terminal NAPTRs, up to now they need not to be able to understand
> and interpret any enumservice defined (only they ones they can handle)
> 
> With your proposal any ENUM-client not understanding the enumservices
> "user" and "carrier" will not be able to retreive any enumservice at
> all.
> 
> This is of course also true for the proposal I made using for this
> purpose
> terminal NAPTRs with enumservice "enum:tel" and carrier:tel",
> using the phone-context in tel: as apex for the new tree.
> but this proposal has other advantages.
> 
> But one should be careful in saying any client in the MUST 
> support this
> because this is already defined in RFC 3761.
> 
> regards
> Richard
> 
> 
> 
> ________________________________
> 
> Von: enum-bounces at ietf.org im Auftrag von Pfautz, Penn L, NEO
> Gesendet: Mi 15.06.2005 19:05
> An: Fullbrook Kim (UK); enum at ietf.org
> Betreff: RE: [Enum] Benefits of "Carrier" / "User" enumservices
> 
> 
> 
> Kim:
> 
> I'm not sure I agree with your assessment of what gets 
> broken. My belief
> is that clients compliant with RFC 3761 should process non-terminal
> NAPTRs. The matching on a service within E2U such as SIP 
> should occur on
> terminal NAPTRs. There will be a need to support the new enum services
> of "user" and "carrier".
> 
> As to the benefits to carriers, our motivator is NOT 
> primarily privacy,
> it's effective interconnection. User ENUM in many countries 
> requires end
> user opt-in and may give the end user the right to select the Tier 2
> that hosts the terminal NAPTR records. These constraints are 
> problematic
> for interconnection which requires registration for all served numbers
> and carrier control of Tier 2 to ensure reliability.
> 
> Although the I-D did not go into it, there are techniques for
> controlling access to actual routing data or offering up different IP
> points of interface (e.g. different Session Border Controller 
> point) to
> different carriers. How open interconnection will be to non-carrier
> parties is a business decision for individual carriers but we believe
> the proposed implementation can support whatever is decided.
> 
> Some kind of ENUM will be used for interconnection as voice moves to
> being an application on IP networks. Our preference is that this
> implementation be synergistic with end user ENUM.
> 
> Penn Pfautz
> 
> -----Original Message-----
> From: enum-bounces at ietf.org [mailto:enum-bounces at ietf.org] On 
> Behalf Of
> Fullbrook Kim (UK)
> Sent: Wednesday, June 15, 2005 12:44 PM
> To: enum at ietf.org
> Subject: [Enum] Benefits of "Carrier" / "User" enumservices
> 
> Having read the draft-pfautz-lind-enum-carrier-user-00.txt 
> and discussed
> it with colleagues, I have some concerns about its drawbacks and am
> struggling to see what benefits it offers.
> 
> It may be that I've missed a key point or mis-understood 
> something so I
> would be grateful if someone can assist with explanation and
> clarification.
> 
> The first concern is that if this registration and 
> accompanying data is
> introduced, its implications about how DNS data is structured breaks
> existing enum resolvers. For example, when a resolver queries the
> e164.arpa DNS tree for an E164 number +1-234-5678901 it retrieves all
> the NAPTR records matching this number and then looks for a 
> match on the
> enumservices "E2U" and "SIP". This matching will fail as only NAPTR
> records with "Carrier" or "User" are present and the call fails. To
> introduce these enumservices successfully requires all existing enum
> resolvers to be re-implemented. The resolver has to first look for a
> match on "Carrier" or "User" enumservice, retrieve more 
> NAPTRs and then
> look for a match on "E2U" and "SIP".
> 
> The second concern is how the "Carrier" enumservice meets the needs of
> telcos. As I understand it, the major driver for introduction 
> of Carrier
> enum is to address privacy concerns. Telcos don't want their enum data
> available for inspection and attack by everyone on the 
> Internet and the
> carrier enum concept addresses this by making the data inaccessible
> except to authorised queries. However, the use of the Carrier
> enumservice only shifts the DNS query to a different DNS domain on the
> Internet and makes no difference to the privacy or access privileges.
> It's not clear to me what the benefit of "Carrier" enumservice is for
> data privacy compared to the case of not having it.
> 
> Kim Fullbrook
> 
> =====================================================
> This electronic message contains information from O2 which may be
> privileged or confidential. The information is intended to be for the
> use of the individual(s) or entity named above. If you are not the
> intended recipient be aware that any disclosure, copying 
> distribution or
> use of the contents of this information is prohibited. If you have
> received this electronic message in error, please notify us 
> by telephone
> or email (to the numbers or address above) immediately.
> =====================================================
> 
> 
> _______________________________________________
> enum mailing list
> enum at ietf.org
> https://www1.ietf.org/mailman/listinfo/enum
> 
> _______________________________________________
> enum mailing list
> enum at ietf.org
> https://www1.ietf.org/mailman/listinfo/enum
> 
> 
> 
> 
> 
> _______________________________________________
> enum mailing list
> enum at ietf.org
> https://www1.ietf.org/mailman/listinfo/enum
> 

_______________________________________________
enum mailing list
enum at ietf.org
https://www1.ietf.org/mailman/listinfo/enum

---

From: lconroy <[email-masked]>
Date: Thu, 16 Jun 2005 05:36:16 -0400

Hi Steve, folks,
  updating an RFC is a non-trivial matter where there is some question 
over a addition in functionality. Even RFC3966 (which, in practice, 
reduced options) took a loooonnnng time to complete.

Do you mean that RFC3761 is inconsistent - i.e. is this what makes you 
think is a need for a second template for non-terminals?
What cases in RFC3761 do you believe REQUIRE such a template, and in 
what section of that RFC do you believe this is implied?
The initial section of the RFC does reflect a messy discussion with a 
definite AD position (as is reported in the meeting minutes). It is one 
of those "strong cup of tea and a quiet room" texts that occur in many 
RFCs.
However... I have looked back through the ML archive (we were both 
involved in the discussions at the time) and even with this prompting 
do not recall a meeting discussion or posting that suggested this.

all the best,
  Lawrence
On 15 Jun 2005, at 21:08, Lind, Steven D, ALABS wrote:
It seems to that if this is the case, the template does not cover all 
the cases described in RFC 3761. Do we need a second template for 
non-terminal NAPTRs or change the existing template (and associated 
instructions) to incorporate both types of NAPTRs.

Steve Lind
-----Original Message-----

Richard.
-----Original Message-----
From: Stastny Richard [mailto:Richard.Stastny at oefeg.at]
Sent: Wednesday, June 15, 2005 3:08 PM
To: Pfautz, Penn L, NEO; Fullbrook Kim (UK); enum at ietf.org
Subject: Re: [Enum] Benefits of "Carrier" / "User" enumservices
Penn,
a minor correction:

Kim:
-----Original Message-----
---------------------------------------
lawrence conroy    |tel:+44-1794-833666