Subject: Re: [dispatch] I-D Action:draft-jennings-dispatch-npa-00.txt

From: "Elwell, John" <[email-masked]>
Date: Fri, 9 Jul 2010 11:09:12 +0200

Thanks, Cullen, for producing this draft. I would certainly be interested in trying to find a solution that avoids establishing a new registry. Some initial thoughts:

1.1 Simple Single TLD. This would presumably involve reserving PANxxx (where xxx is a digit string of a certain length or range of lengths), and would be a problem if any such value has already been taken.

2.2 Multiple TLD. This again would be problematic if domain name is already taken. Also the first digit would be able to identify a maximum of 10 TLDs, and would not cover all possibly country TLDs, for example.

2.3 Encoded URI. This is attractive, as it could be resolved locally, without any DNS query. However, it would result in very long digit strings for domain names above about 8-10 characters.

2.4 Compressed encoded URI. I would need to see an example - I am not convinced it could reduce the problem with 2.3 significantly.

John

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of 
> [email-masked]
> Sent: 05 July 2010 17:00
> To: [email-masked]
> Subject: I-D Action:draft-jennings-dispatch-npa-00.txt 
> 
> A New Internet-Draft is available from the on-line 
> Internet-Drafts directories.
> 
> 	Title           : Numeric Provider Alias (NPA)
> 	Author(s)       : C. Jennings
> 	Filename        : draft-jennings-dispatch-npa-00.txt
> 	Pages           : 3
> 	Date            : 2010-07-05
> 
> This draft proposes a modification to
> draft-lawrence-dispatch-sipforum-provider-alias (PAN).  The PAN draft
> proposes a mechanism for a phone to take a short numeric identifier
> that identifies a phone service provider and look it up in DNS to
> find the address of the configuration server for that service
> provider.
> 
> The problem with PAN is that it requires a specific organization,
> sipforum.org, to become a registrar for the PAN.  This will add
> signifiant cost to obtaining them as the expected quantity of PAN is
> low.  This draft proposes a minor modification to the PAN draft.
> Instead of using the sipforum as a new registrar, why not just use
> the registrars that already exist for DNS names.  This ensure a long
> term stable unique allocation of PAN with the advantages of not
> having the IETF allocating a monopoly to one particular organization.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-jennings-dispatch-npa-00.txt
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
>

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 9 Jul 2010 16:00:21 -0600

> 1.1 Simple Single TLD. This would presumably involve reserving PANxxx (where xxx is a digit string of a certain length or range of lengths), and would be a problem if any such value has already bee…

can you say a bit more about what you see as the problem - my thinking is roughly the following. If 123 is already taken by someone else, then it is taken - it does not matter if we use sipforum or .net as the registry. Now if you are concerned that pan123.net might be taken for some other use than the purpose of the PAN draft, then we could make the string you prepend be pan-z9hG4bK and that problem more or less goes away. You could argue that .net domains are so cheap that someone might just go get all of them. This seems like a pretty unlikely attack but that is why the xxx has  a minimum length so the number they needed to get was large. Also it may have a minimum length but it's not fixed length so people can go to a domain with a longer string. 

I'm just not really seeing how this is all that much different if we have the domain that looks like 123.sipforum.net or a string that looks like 123sipforum.net - the size of the address space is about the same either way. 

And I pretty much agree with your comments on the other the other ones - we could probably find ways to solve some of theses but 2,3,4 are at some level just optimization of 1 so if there is some fundamental problem with 1, it probably impacts all of them.

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 12 Jul 2010 08:18:44 +0200

Cullen,

My concern with the first option was simply that a small number of PANxxx values might already be taken for other purposes. But I agree this could be mitigated by using a more obscure fixed string than simply "PAN" and by having a reasonable minimal length for xxx. So probably the first option is the best.

John

> From: Cullen Jennings [mailto:[email-masked]] 
> Sent: 09 July 2010 23:00
> To: Elwell, John
> Cc: [email-masked]
> Subject: Re: [dispatch] I-D Action:draft-jennings-dispatch-npa-00.txt
> 
> 
> > 1.1 Simple Single TLD. This would presumably involve 
> reserving PANxxx (where xxx is a digit string of a certain 
> length or range of lengths), and would be a problem if any 
> such value has already been taken.
> 
> 
> can you say a bit more about what you see as the problem - my 
> thinking is roughly the following. If 123 is already taken by 
> someone else, then it is taken - it does not matter if we use 
> sipforum or .net as the registry. Now if you are concerned 
> that pan123.net might be taken for some other use than the 
> purpose of the PAN draft, then we could make the string you 
> prepend be pan-z9hG4bK and that problem more or less goes 
> away. You could argue that .net domains are so cheap that 
> someone might just go get all of them. This seems like a 
> pretty unlikely attack but that is why the xxx has  a minimum 
> length so the number they needed to get was large. Also it 
> may have a minimum length but it's not fixed length so people 
> can go to a domain with a longer string. 
> 
> I'm just not really seeing how this is all that much 
> different if we have the domain that looks like 
> 123.sipforum.net or a string that looks like 123sipforum.net 
> - the size of the address space is about the same either way. 
> 
> And I pretty much agree with your comments on the other the 
> other ones - we could probably find ways to solve some of 
> theses but 2,3,4 are at some level just optimization of 1 so 
> if there is some fundamental problem with 1, it probably 
> impacts all of them.  
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>

---

From: Cullen Jennings <[email-masked]>
Date: Sun, 18 Jul 2010 09:24:29 -0700

Thought on number of digits and what uniqueness string? I was thinking the min number of digits should be about 5. I did not have any particularly good reason for that number other than it was low enough to be easy to enter even on a single button device and large enough that registering all of them seemed very unlikely. Obviously more than 5 digits is allowed, that would just be the min. 

On the uniqueness string, I imagine we could just run some tests of any strings people propose and see how many are registered in DNS already. 

>> if there is some fundamental problem with 1, it probably 

Cullen Jennings
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 19 Jul 2010 08:20:45 +0200

Sounds reasonable.

John 

> Sent: 18 July 2010 17:24
> Thought on number of digits and what uniqueness string? I was 
> thinking the min number of digits should be about 5. I did 
> not have any particularly good reason for that number other 
> than it was low enough to be easy to enter even on a single 
> button device and large enough that registering all of them 
> seemed very unlikely. Obviously more than 5 digits is 
> allowed, that would just be the min. 
> 
> On the uniqueness string, I imagine we could just run some 
> tests of any strings people propose and see how many are 
> registered in DNS already. 
> 
> 
> > My concern with the first option was simply that a small 
> number of PANxxx values might already be taken for other 
> purposes. But I agree this could be mitigated by using a more 
> obscure fixed string than simply "PAN" and by having a 
> reasonable minimal length for xxx. So probably the first 
> option is the best.
> > 
> > John
> > 
> > 
> >> Subject: Re: [dispatch] I-D 
> Action:draft-jennings-dispatch-npa-00.txt
> >> 
> >>