Von: Patrik Fältström <paf at cisco.com>
Datum: 12. März 2007 17:50:03 GMT+01:00
An: Jim Reid <jim at rfc1035.com>
Kopie: <richard at shockey.us>, <mah at inode.at>, "'Jay Daley'"
<jay at nominet.org.uk>, "'Wilhelm Wimmreuter'"
<wilhelm at wimmreuter.de>, "'Stastny Richard'"
<Richard.Stastny at oefeg.at>, "'Niall O'Reilly'"
<Niall.oReilly at ucd.ie>, "'Conroy Lawrence'"
<lconroy at insensate.co.uk>, "'Bartosiewicz Andrzej'"
<andrzej.bartosiewicz at nask.pl>
Betreff: Re: You know guys we are really not that far off consensus
here.
On 12 mar 2007, at 17.32, Jim Reid wrote:
These are very good questions Patrik. And I believe they are for
the WG to consider and work on. Because there's nowhere else where
these discussions could take place in a constructive, neutral manner.
This is why I have asked a few times for what the requirements
REALLY are for things like infrastructure ENUM is (in the IETF).
The document that the wg have consensus on is, I think personally,
not enough. I told the authors that, but I saw myself being in the
minority, and as a wg chair I of course should accept that (as
everyone else).
Here is a note I have kept for myself so far, but I share it with
you all. So you can understand that I do not see the requirements
and answers are on the table... I do not see I can pick which
solution is the best given the requirements document. Once again
from a personal perspective...
1.
Problem:
A zone in DNS is in reality a monopoly, so only one party can run
the DNS for the zone of a specific E.164 number.
Who is affected:
This is not good enough for people that run a service the NAPTR
refer to a service they run themselves. They want to both run
service and DNS for the NAPTRs.
Suggested solution(s):
A. Create a new domain i164.arpa under which certain
(infrastructure) services can be found.
B. Create a new domain below the CC in the e164.arpa tree under
which certain (infrastructure) services can be found.
C. Use the URI resource record type so that it is possible to
delegate from the zone of the number to the provider of the service.
D. Use non-terminal NAPTR and refer to a different owner in DNS
where the NAPTR RR are stored.
Note:
Solution A and B only allow for one (1) service beside the User
ENUM that already exists today. If there are two service providers
that want to run their own DNS for the zone, it can not be done
without creating a new domain for each kind of service.
Solution C require the party running the zone for the E.164 be
neutral. See 2 below.
Solution D require support for non-terminal NAPTR, and there is
hesitation to require that. This further make it possible for the
service provider to have all his numbers in one zone, and not
multiple zones.
Solution C and D both make it easier to implement a system without
opt-in (see 3 below) if the zone of the E.164 is run by a neutral
party. Addition of delegations can be done without impacting
existing delegations.
2. Problem:
A provider of a service (and potentially DNS for that service, see
1 above), do not accept delegation from a party that is not under
regulative control.
Who is affected:
Anyone that for example believe their service is under regulative
control with requirements on for example uptime. In principle
everyone that also is affected of 1 above. Parties that want to
run both service and DNS for the E.164 that refer to the service.
Suggested solution(s):
Have the party running DNS for the CC (that is believed to be
under regulative control and because of that neutral and accepted)
run DNS for also the full E.164, and not only for (for example)
some blocks of E.164.
Note:
In the case of 1.A and 1.B the delegations could be made on
blocks, but number portability might create problems. Question of
course is how number portability is implemented in reality.
3. Problem:
ENUM of today require opt-in by the holder of the E.164 number.
Who is affected:
Anyone that want to run ENUM (or use ENUM) for services or E.164
numbers they control.
Solution(s):
A. Make it clear in RFC3761bis that whether opt-in or not is used
is a policy issue defined by the local CC (regulation).
B. Use solution 1.A or 1.B where opt-in can be said is not needed
while it is still needed in e164.arpa.
Note: Regardless of whether 3.A or 3.B is in use, the end result
will be a combination of local and global policy.
4. Problem:
Make it possible to have "private" ENUM that is only usable for
parties that one have contractual agreements with.
Solution(s):
A. Have the DNS for the numbers visible only to the parties that
one have agreements with.
B. Have separate VPNs where the IP addresses of the DNS servers
are visible, and use "normal" route announcements to announce the
IP addresses over separate networks for parties one have
agreements with.