Subject: Re: [Enum] ENUM interworking

From: "Jim Fleming" <[email-masked]>
Date: Wed, 31 Oct 2001 23:16:01 -0600

----- Original Message -----
From: "Bill Manning" <[email-masked]>
To: "Tony Rutkowski" <[email-masked]>
Cc: "Bill Manning" <[email-masked]>; "Patrik Fältström " <[email-masked]>;
"David R. Conrad" <[email-masked]>; "Kevin McCandless"
<[email-masked]>; <[email-masked]>; <[email-masked]>; "Bob
Wienski" <[email-masked]>
Sent: Wednesday, October 31, 2001 3:07 PM
Subject: Re: [Enum] ENUM interworking

> % >         ideal than things which are not. I get the impression that
> % >         you might feel that an ideal construct would allow for
> % >         arbitrary fragmentation into administrative boundaries while
> % >         retaining the "external" appearance of a single construct.
> % >         Is this correct?
> %
> % Hi Bill,
> %
> % Rather than assuming the worse case situation of
> % arbitrary fragmentation, why not consider coordinated,
> % non-conflicting namespaces to allow for competition
> % and provide for recovery in case of outages.
>
> Hum... again, chasing the ideal,
> It would seem to me to be desirable to get the
> coordination and non-conflicting agreements done
> at the outset and then allow the relevent parties
> to freely operate within the constructs that define
> the namespace.  Reducing the need to constantly revisit
> coordination and to ensure that non-conflicting events
> are the norm would lead to faster customer response, which state,
> IMHO, is a characteristic of an ideal.
>

"freely operate within the constructs that define the namespace"

It all boils down to fairness.
Which list do you think is more fair ?

The "toy" IPv4 Internet Early Experimentation Allocations ?
http://www.iana.org/assignments/ipv4-address-space
or
The Proof-of-Concept IPv8 Allocations ?
http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt

Why would people pay for Address Space, when it is FREE ?

Jim Fleming
http://www.DOT-BIZ.com
http://www.in-addr.info
3:219 INFO

_______________________________________________
enum mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/enum

---

From: "David R. Conrad" <[email-masked]>
Date: Wed, 31 Oct 2001 19:59:37 -0800

At 11:41 AM 10/31/2001 -0500, Tony Rutkowski wrote:
>What is your view about the use of DNAME?

Give me some context.  DNAME is interesting because it allows aliasing of 
trees, not just leaves like CNAME.  However, I'm not sure I understand how 
this addresses any particularly pressing issue.

>Aren't robustness and diminished vulnerability (especially
>post 9-11) at least as important attributes as call completion
>delay?

I'd agree.

>What ENUM architectures and attributes
>increase or diminish "signalling" vulnerabilities?

I figure multiple namespace would introduce a higher likelihood of data 
consistency failures without necessarily improving reliability or robustness.

Regardless of architecture, the DNS (without DNSSEC) is fundamentally 
insecure.  It is trivial (publicly available tools exist) to spoof 
name-to-(whatever) translations when you are on the path between the 
requestor and the server.  It is significantly more difficult, albeit 
theoretically possible, if you are not on the path between the requestor 
and the server.  This is probably not a feature.

Rgds,
-drc

---

From: Dave Crocker <[email-masked]>
Date: Thu, 01 Nov 2001 13:03:35 -0800

At 04:10 PM 11/1/2001 -0500, Mark Harris wrote:
> >It requires that they collaborate.
>
>I'm not sure...

I'll rephrase:

         Assignment of the PSTN number and assignment of the same number 
within ENUM must be coordinated.

         If they are not coordinated, they will diverge.  And THAT will 
mean that the number is used by different entities.  And THAT will be very 
bad, indeed.

d/

----------
Dave Crocker  <mailto:[email-masked]>
Brandenburg InternetWorking  <http://www.brandenburg.com>
tel +1.408.246.8253;  fax +1.408.273.6464

---

From: "Mark Harris" <[email-masked]>
Date: Thu, 1 Nov 2001 16:49:18 -0500

>mean that the number is used by different entities.  And THAT will be very

Agreed.  ...The ENUM subscriber must be the assignee of the telephone
number.

Regards,
Mark

www.EnumNIC.net
www.EnumForums.org

-----Original Message-----
From: Dave Crocker [mailto:[email-masked]]
Sent: Thursday, November 01, 2001 3:59 PM
To: [email-masked]
Cc: [email-masked]; Bill Manning; [email-masked];
Jordyn A. Buchanan; David R. Conrad; Pfautz Penn L NNAD; Kevin
McCandless; [email-masked]; [email-masked]; Bob Wienski
Subject: RE: [Enum] ENUM interworking

I'll rephrase:

d/

----------

---

From: "Christian Huitema" <[email-masked]>
Date: Thu, 1 Nov 2001 13:55:56 -0800

> this addresses any particularly pressing issue.

When I proposed using DNAME about 2 years ago, I was concerned with the
handling of internal directories inside organization domains, in which
my extension "1234" would map to something like 
	4.3.2.1.local-numbers.example.com
There are many possible uses of such trees in internal telephony
gateways inside a corporation. DNAME could be use to establish "tree
mapping" between the "golden tree" and these subtrees.

There have been two arguments against this proposal. First, if you are
doing a product designed for used within an organization, you will
probably use another solution for mapping numbers, e.g. an internal LDAP
directory; even if you used ENUM, the primary storage of the information
would still usually be some form of directory, so the benefits or
avoiding replication are limited. Second, you could just as well use NS
records pointing from a main tree to the local organization server, with
possibly better caching characteristics. I am kind of swayed by these
arguments.

-- Christian Huitema

---

From: Dave Crocker <[email-masked]>
Date: Thu, 01 Nov 2001 17:36:45 -0800

At 04:51 PM 11/1/2001 -0500, Pfautz, Penn L, NNAD wrote:
>the issue in interworking was
>how a registry that choose to store NAPTR records in a domain other than
>e164.arpa, for its own business reasons, could still have a pointer to its
>DNS in the e164.arpa Tier 1.
>This approach was being explored in the spirit of trying to be see what can
>be done to interwork with other trees without changing the fundamental
>approach in RFC2916 which is the focus of the Forum

1.      The fundamental approach in 2916 is a single hierarchy, not a 
single hierarchy with lots of parallel hierarchies.

2.      People working outside a standard are free to do anything they 
want.  They only problem is when they claim to be part of the standard.

3.      People building one standard that incorporates another standard 
need to document and validate that standard, in whatever way they find 
useful.  They need to realize that they are creating a new and different 
standard.

         In earlier days, it was always amusing to see products that 
claimed to be "based on" Internet standards. The phrase "based on" was code 
language for "this product is proprietary and does not interwork".

4.      The key point got onr standard that uses another -- and makes any 
effort to elaborate on the first standard -- is the question of 
coherence.  Does the second work have any possibility of diverging from the 
first?

         In the world of TLD Domain Names, incorporating the ICANN 
namespace but then creating additional TLDs guarantees a problem when ICANN 
later assign a new TLD.  It is certain that eventually they will create one 
that the second effort had already been using.  The problem here is with 
the independent action by the second group, not the "encroachment" by ICANN.

         The same issue is true for any similar effort.  Such an effort 
needs to senure that it does not seed its work with trojan horses.

d/

----------