Subject: [Enum] Fwd: You know guys we are really not that far off consensus here.

From: Michael Haberler <[email-masked]>
Date: Wed, 14 Mar 2007 10:35:08 +0100

[I'm taking the growing offline thread to the list now. Let's  
continue here. -mah]

Anfang der weitergeleiteten E-Mail:

> Von: Patrik Fältström <[email-masked]>
> Datum: 12. März 2007 17:50:03 GMT+01:00
> An: Jim Reid <[email-masked]>
> Kopie: <[email-masked]>, <[email-masked]>, "'Jay Daley'"  
> <[email-masked]>, "'Wilhelm Wimmreuter'"  
> <[email-masked]>, "'Stastny Richard'"  
> <[email-masked]>, "'Niall O'Reilly'"  
> <[email-masked]>, "'Conroy Lawrence'"  
> <[email-masked]>, "'Bartosiewicz Andrzej'"  
> <[email-masked]>
> 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.

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