Hi Patrik,
I do not really see a problem here
I do not see A, B and C as different camps (I do not understand D),
all of these 3 are valid ENUM applications
As Penn is saying, C is of no concern in IETF,
A is already solved
leaves B open:
This is also solved in the WG, the drafts are there
what is missing is a statement from IETF/IESG/IAB to the ITU-T
My proposal is that IESG/IAB is to offer the ITU-T to use also an apex
in .arpa and also to use RIPE NCC to operate the Tier-0,
it is the ITU-T decision to take this offer or chose another apex
(and somebody else to operate it).
In SG2 Q.1 already a correspondance group has been created
at the last plenary in February (the rapporteur is Karen Mulberry from Neustar)
to deal with this issue (and awaiting a liaison from IESG).
In addition, to my understanding nobody in ITU-T considers that
this will have any influence on e164.arpa and the Interim Procedures.
So what we need to do is advancing the 4 I-Ds to RFCs and send them with a
letter to ITU-T
Richard
________________________________
Von: Patrik Fältström [mailto:paf at cisco.com]
Gesendet: So 18.03.2007 15:23
An: enum at ietf.org
Cc: iab at ietf.org; The IESG
Betreff: [Enum] My view of where we are in ENUM
Note: My co-chair have seen this, think the wording is correct, but
these are my words
I identify regarding ENUM 4 different camps:
[A] User ENUM
The Public ENUM where the end user, holder of the E.164, is
controlling the DNS and URIs.
[B] Public Infrastructure ENUM
ENUM that is in the public DNS, where lame delegation is not allowed,
but the "carrier" responsible for the number (one and only one
organisation, not the end user) is controlling the data in a way
similar to A.
[C] Private Infrastructure ENUM
ENUM that is NOT in the public DNS, where groups of organisations on
bilateral agreements can make information about the number public.
Only parties signing up to the agreements can access the data in the
DNS.
[D] Non-telephony users of ENUM
B (and possibly C - dependent on the agreements) treat "providers of
telephony" special, using the regulative/legal definition of carrier
as the special entity that part from the end user (as covered in
solution A) can add data to the DNS. Category D include other
providers of services, not the end user, that argue for them to get
the same treatment as the carrier in solutions like B and/or C.
---- o -----
Out of these four, B is very vocal in the IETF. A participates, but
is relatively silent (their problem is solved already). C is not
participating in IETF but have their own conferences. D does not
really exist, but I am nervous about the day when D get members, and
what impact D might have on the solutions.
The solutions advocated for in the IETF related to B require a branch
in the DNS tree, so that solutions for A and B are stored under
different domain names, or apexes.
How that branch is created, where it is created, and whether it is to
be created, is based on arguments that I personally feel we in the
IETF are not capable of discussing. Especially as alternative C
people are present in the discussions. Those discussions are such
that I think (for example) ITU-T in SG2 should discuss.
What you should read of the note (that I stand behind that many of
you objected to) is that I as co-chair tell IAB and IESG that I do
not feel capable recommending the IETF to create a branch, or where
some apex should be, of a specific kind without support from a
combination of IAB and IESG. Plus a recommendation that many
discussions that have been held in ENUM should be held outside of the
IETF.
_______________________________________________
enum mailing list
enum at ietf.org
https://www1.ietf.org/mailman/listinfo/enum
<<winmail.dat>>
_______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum