Re: Send-N draft: draft-bellis-enum-send-n-02 published

I think we're in the "agree to disagree state".

I do not support Send-N.

I think there is a problem, I think IETF can solve it.  I've provided one
alternative, I'm happy to discuss others.  

Your proposal, in my opinion, is too limiting, and doesn't solve the entire
problem.

Brian


> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On Behalf Of
> [email protected]
> Sent: Friday, June 27, 2008 12:11 PM
> To: [email protected]
> Subject: Re: [Enum] Send-N draft: draft-bellis-enum-send-n-02 published
> 
> > 1000 entries in a database is laughably small.
> 
> Probably, but maintaining it apparently is not.
> 
> > Downloading it to a phone as
> > the country code is dialed is even easy (although I suspect you wouldn't
> do
> > that to a wireless phone with current data rates, you might with 4G data
> > rates).
> 
> Again, this is for dumb DTMF phones, not smart phones.
> 
> > Here is a more or less concrete proposal:
> > The regulator publishes, in the existing ITU document, a URI of its
> current
> > dial plan.  The URI yields an XML data structure that looks like:
> > <dial-plan globalprefix="+1">
> > ...
> > <assignment operator="ATT" use="wireless" prefix="202555" min=4 max=4/>
> > ...
> > </dial-plan>
> 
> Yes, but that's ITU-T territory.
> 
> Automatically generating Send-N records based on the local ENUM tree
> structure allows (I-)ENUM operators to publish real-time number plan
> pseudo-data without their ever needing to be reference to a "master"
> ITU-T/Regulator number plan.
> 
> The master number plan information only needs to be consulted locally to
> figure out whether any given E.164 number is allowed to be put in the ENUM
> database in the first place.
> 
> Ray
> 
> _______________________________________________
> enum mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/enum