Subject: [Enum] Re: User ENUM vs Operator ENUM

From: [email-masked]
Date: Wed, 16 Jun 2004 18:36:52 -0400

On Tue, 15 Jun 2004 at 16:33:09 -0400, Richard Stastny wrote:
>
>Since (at least in User ENUM aka e164.arpa) the should
>be the domain name holder of the domain corresponding to
>the E.164 number and therefor should be able to modify the
>contents of his domain, he may change the URIs pointing
>to his service providers, what could be understood as number
>portability (changing his SP). He may also transfer the domain
>from one ENUM provider to another
>
RFC 3761 states:
<!--StartFragment-->
Holders of E.164 numbers which want to be listed in DNS
should contact the appropriate zone administrator according to the
policy which is attached to the zone.  One should start looking for
this information by examining the SOA resource record associated with
the zone, just like in normal DNS operations.
Of course, as with other domains, policies for such listings will be
controlled on a subdomain basis and may differ in different parts of
the world.
<!--EndFragment-->

Nothing in RFC3761 distinguishes categories such as end user or carrier.
I believe it is incorrect to equate e164.arpa with "user ENUM."
What Richard describes, above, might be a description of the policy for
a particular domain, but the policy could be very different in other
domains.
A policy could be developed that provides for both user-controlled and
carrier-controlled (infrastructure) NAPTRs in the same domain.

There has been talk about user/public ENUM and Infrastructure ENUM
(iENUM) being orthogonal, with the conclusion that they must be handled
in separate domains.  I don't see the logic in such a conclusion.  If,
for example, a different Enumservice were registered for iENUM, then
an iENUM NAPTR could easily coexist with user-specified NAPTRs for
other registered Enumservices in a single ENUM tree -- no split DNS,
no other undesirable DNS options needed.

(Question: Would it be possible for one NAPTR to exist in a particular
level
of the ENUM tree along with NS records pointing to a lower level that
contains additional NAPTRs for different Enumservices?  (E.g., to allow
a user to control the domain where those additional NAPTRs reside.))

Please forgive me if I have used incorrect terminology or if the suggestion
violates some rule of DNS operation.  Flame me, but also tell me where
I have gone wrong.

>This only works if the delegations are done (sorry Patrik, this
>was the main reason for the Tiers) directly from Tier 1 (the
>national level to the Tier 2 (the level containing the NAPTRs)
>
NAPTRs are not restricted to a particular level, are they?.

>Since NP is not an issue between countries ;-), this grouping
>is possible (also for national policies). There could be a Tier1a
>and 1b for various reasons (e.g +1) or a grouping according
>to differnt number types e.g. 800 numbers will always be
>800 numbers.
>
Number portability can be an issue for every number regardless of
the origin of the "call."  A receiving service provider may need
to determine where to deliver the call based on porting information.
But if the NAPTRs associated with a number in ENUM always relate
to the current end-user assignee, then as far as ENUM is concerned,
porting is not a technical issue.  It is taken care of in the
registration process.

>So NP is not an issue in User ENUM. It is an issue
>in Infrastructure ENUM  because operators again
>want to have block delegations for simple routing
>to gateways and hiding of information.
>
>Although in some countries NP is only necessary
>for "public available telephony services" (PATS) and
>most VoIP services are non-PATS (this terminology is
>EU centric) = ECS (electronic communications services),
>we should provide for NP from the beginning to avoid
>later hazzles.
>
A VoIP service may be considered non-PATS in some places,
but aren't most of those using proprietary (non-E.164) naming
schemes?  I would be surprised if many countries would allow
assignment of E.164 numbers for VoIP in a non-portable manner
in the long term.  I guess this is what Richard is implying.
(I would also guess that most countries will insist that VoIP
services using E.164 numbers should be dialable from the PSTN,
without the originating or intermediate carriers needing to do
an ENUM query, but that isn't a discussion for this list.)

>We should also not forget the block allocation was the
>number 1 reason for number exhaust. If new number ranges
>used for VoIP are handed out with block size 1 there will
>be more numbers available then now in use.
>
We are in agreement here.

Jim

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

---

From: Jim Reid <[email-masked]>
Date: Thu, 17 Jun 2004 06:01:45 -0400

>>>>> "james" == james f baskin <james.f.baskin at verizon.com> writes:

    james> Nothing in RFC3761 distinguishes categories such as end
    james> user or carrier.  I believe it is incorrect to equate
    james> e164.arpa with "user ENUM."  What Richard describes, above,
    james> might be a description of the policy for a particular
    james> domain, but the policy could be very different in other
    james> domains.  A policy could be developed that provides for
    james> both user-controlled and carrier-controlled
    james> (infrastructure) NAPTRs in the same domain.

How could that be implemented in the DNS? It's a only lookup service
and doesn't have any hooks for implementing policy.

    james> There has been talk about user/public ENUM and
    james> Infrastructure ENUM (iENUM) being orthogonal, with the
    james> conclusion that they must be handled in separate domains.
    james> I don't see the logic in such a conclusion.  If, for
    james> example, a different Enumservice were registered for iENUM,
    james> then an iENUM NAPTR could easily coexist with
    james> user-specified NAPTRs for other registered Enumservices in
    james> a single ENUM tree -- no split DNS, no other undesirable
    james> DNS options needed.

You are mistaken. Different NAPTRs (or whatever) could exist in a zone
and be controlled/manipulated by different entities. But it would be a
nightmare to set up and administer. [Try making something like BIND9's
update-policy{} work for 100M+ numbers each with tens of NAPTR records
all of which require fine-grained control.] And there would be massive
privacy implications for both the providers and the end user. For
instance if my mobile telco has introduced a NAPTR for my GSM which
says "no inbound calls while Jim's overseas", this will be visible to
everyone in the DNS. So any ENUM-aware burglar's been told "come on
round Jim's house because there's nobody home". Similarly, a telco
might not be allowed by law or regulation to publish the fact they
provide service for a given number. And even if they were, no telco
would want to advertise that information to their competitors.

Another concern is user ENUM is going to have to be opt-in. The number
doesn't go in the tree unless the "owner" consents. Operator or
infrastructure ENUM has to work for every active number, including
those people with unlisted numbers, test codes, preminum rate and free
numbers, etc, etc. That means there can be no opt-in principle at work
there. I fail to see how these mutually exclusive principles can be
satisfied by having a single, public tree for both.

---

From: James Seng <[email-masked]>
Date: Thu, 17 Jun 2004 19:46:15 -0400

> and doesn't have any hooks for implementing policy.

then shouldnt we consider how it can be done? there are specific requests for 
ACL in ENUM. So either we meet the user requirements or the users look for 
something else.

> satisfied by having a single, public tree for both.

I think we should not consider protecting the "privacy" of an SIP/H.323 
identifiers, and thats what we put into ENUM. What we do need to protect are 
the user identity-information that is associated to the ENUM or SIP/H.323 
identifiers.

This is analogous to the 'private number' concept, where you dont get 
published in a yellowpage but calling your number (by pure luck or 
wardialing) will still reach you nevertheless.

-James Seng

---

From: Jim Reid <[email-masked]>
Date: Fri, 18 Jun 2004 04:52:21 -0400

>>>>> "James" == James Seng <jseng at pobox.org.sg> writes:

    >> How could that be implemented in the DNS? It's a only lookup
    >> service and doesn't have any hooks for implementing policy.

    James> then shouldnt we consider how it can be done? there are
    James> specific requests for ACL in ENUM. So either we meet the
    James> user requirements or the users look for something else. 

Yes, this is something the WG should consider IMO. Though it may be
better if the WG looked at policy recommendations rather than how the
policy gets implemented.

    James> I think we should not consider protecting the "privacy" of
    James> an SIP/H.323 identifiers, and thats what we put into
    James> ENUM. What we do need to protect are the user
    James> identity-information that is associated to the ENUM or
    James> SIP/H.323 identifiers.

Hmmm. I think it would be wise to try and find out what could and
should be protected before deciding what will be protected. Different
countries have different approaches to privacy and data protection
issues. A couple of ccTLDs have recently started a jihad in the dnsext
WG about the privacy issues surrounding NSEC records for Secure
DNS. [These allow the zone to be walked.] They are concerned about
compilation copyright on the zone data and I suspect this issue might
raise its ugly head in the context of ENUM. Even though zone
enumeration is trivial with or without NSEC records.

---

From: James Seng <[email-masked]>
Date: Fri, 18 Jun 2004 04:59:16 -0400

preciesly. dumping of zone files is a concerns generic to all DNS, so 
not just for ENUM.

we in the ENUM WG, must be absolutely clear what can be done, what 
cannot be done, and how to explain why some thing just cannot be done 
(and actually it doesn't really matters)

-James Seng
Jim Reid wrote:

---

From: Jeff Williams <[email-masked]>
Date: Fri, 18 Jun 2004 05:54:54 -0400

Jim and all,

  The IETF should be developing technical methods not just RFC's
to meet current demand and future expected demand that will allow
for different policies for DNS and this includes ENUM.  Yes I have
been spouting this idea for many years, and have been rebuffed many
times as a result for who knows what real reasons...

> enumeration is trivial with or without NSEC records.

Regards,

--
Jeffrey A. Williams
Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!)
"Be precise in the use of words and expect precision from others" -
    Pierre Abelard

"If the probability be called P; the injury, L; and the burden, B;
liability depends upon whether B is less than L multiplied by
P: i.e., whether B is less than PL."
United States v. Carroll Towing  (159 F.2d 169 [2d Cir. 1947]
===============================================================
Updated 1/26/04
CSO/DIR. Internet Network Eng. SR. Eng. Network data security
IDNS. div. of Information Network Eng.  INEG. INC.
E-Mail jwkckid1 at ix.netcom.com
 Registered Email addr with the USPS
Contact Number: 214-244-4827

---

From: Jeff Williams <[email-masked]>
Date: Fri, 18 Jun 2004 05:59:13 -0400

James and all,

  "Can't be done" is not in my technical vocabulary.  If there is a will
it can be done...

Regards,