Subject: [Enum] WG: I-D submission draft-haberler-carrier-enum-01

From: "Stastny Richard" <[email-masked]>
Date: Fri, 21 Oct 2005 16:03:38 +0200

Dear all,
 
since I-D submission turn around is very slow currently, here a peek preview
of our Carrier ENUM draft
 
Richard

________________________________

Von: Michael Haberler [mailto:[email-masked]]
Gesendet: Fr 21.10.2005 15:14
An: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; Pfautz, Penn L, NEO; [email-masked]; Stastny Richard; [email-masked]; [email-masked]
Betreff: I-D submission draft-haberler-carrier-enum-01

Dear IETF I-D team,

please find attached an updated Internet-Draft submission titled
"Combined User and Carrier ENUM in the e164.arpa tree" -
draft-haberler-carrier-enum-01.txt .

Abstract:

ENUM as defined now in RFC3761 is not well suited for the purpose of
interconnection by carriers, as can be seen by the use of various
private tree arrangements based on ENUM mechanisms. A combined
end-user and carrier ENUM tree solution would leverage the ENUM
infrastructure in e164.arpa, increase resolution rates, and decrease
the cost per registered telephone number. This document describes a
minimally invasive scheme to provide both end-user and carrier data in ENUM.

This draft is intended for the ENUM working group.

The draft is also available on my web page at:

http://mah.priv.at/i-d/draft-haberler-carrier-enum-01.txt
http://mah.priv.at/i-d/draft-haberler-carrier-enum-01.html

best regards

Michael Haberler
Internet Foundation Austria
+43 664 4213465 

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

---

From: "Peter Williams" <[email-masked]>
Date: Fri, 21 Oct 2005 08:05:55 -0700

So I REALLY did NOT like this ID, as it continues the traditional debate 
over the legitimacy of the Carrier ENUM, continuing a debate that is now 
passe. We must move ON from wheter we want to address the CarrierENUM 
question in the WG per se, to characterizing it in a wider architecture so 
that various IETF activities (in various WGs) can co-exist and cooperate.

I suggest the document needs a good reorganization, focussing on harmonizing 
its content with the current I-D set that are fashioning a set of 
terminology set , and a common reference point for requirements. If 
modernised, the draft will fit into the improving architecture discussion 
that is clearly going on in and around the rechartering of the WGs mission 
to now make Carrier ENUM into a creditable standards track effort.

But it was useful to read, in the RFC tradition: it identified to me certain 
issues that need resolving, structurally within the set of standards under 
consideration, now that we HAVE (finally) the Carrier ENUM question before 
us:

(1) The I-D identified that current standard track document concerning ENUM 
means "User ENUM" today - based on a history of dogma and politics. We need 
to define ENUM  as something that is NOT tied to the User ENUM model of 
provisioning entries, and/or exercising control over zone content. ENUM 
needs to be a generic telematic service, and associated DNS-level 
protocols/procedures: User ENUM vs Carrier ENUM are two models for an EMO 
(ENUM Management Organization) to manage and adminster the generic telematic 
service (ENUM) at certain access points. Two further models will emerge, if 
history repeats: so we should prepare architecturally.

(2) The interconnects between ENUM providers must be distinguished from the 
notion of interconnect being used in VOIP Peering. VIOP Peering has a VERY 
restricted notion of interconnect (the weird and wonderful "layer 5" term), 
that does not take into account non-SIP usage environments for ENUM, and 
does not take into account interworking arrangements between ENUM providers 
cooperating to delivery of a shared ENUM telematic service by those parties, 
in a particular "Carrier ENUM adminsitrative region" of a public or private 
tree.

(3)  All discussion of Carrier ENUM model of deploying an ENUM telematic 
service should not involve any DNS layer protocol/procedure discussion. 
Whether an EMO coalition of providers opts to deploy a Carrier ENUM service 
in the e164.arpa tree (IANA/DARPA controlled) or under another DNS tree 
(ICANN but not IANA controlled directly), or a walled-garden name service 
using non Internet domain names, should not influence how Carrier ENUM model 
is distinguished from User ENUM or the underlying ENUM telematic service.

How does one use the above three comments: they are suggestions that address 
how the content will be appreciated by readers of the future standard, not 
detailed debating points about text or the underlying politics of the 
issues. If the authors agree, use the material. If the authors do not agree 
with the style of the comments, they should ignore them!

Peter.

>From: "Stastny Richard" <[email-masked]>
>To: <[email-masked]>
>CC: [email-masked]
>Subject: [Enum] WG: I-D submission draft-haberler-carrier-enum-01
>Date: Fri, 21 Oct 2005 16:03:38 +0200
>
>Dear all,
>
>Cc: [email-masked]; [email-masked]; 
>[email-masked]; [email-masked]; Pfautz, 
>Penn L, NEO; [email-masked]; Stastny Richard; [email-masked]; [email-masked]

><< draft-haberler-carrier-enum-01.txt >>