[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Enum] I-D Action: New draft - draft-bellis-enum-send-n-00


Brian Rosen wrote:
> I think we're tending to agree that the data is useful, and disagree on how
> you get it.
> 
> I think we're tending to agree that even if you use private ENUM, you need
> the data.
> 
> The question is then where to put it.
> 
> I would point out that the SOURCE of the data is the number plan
> administrator in a country, which is distinctly different from the operator
> of the public enum tree, if there is one.

I will admit that I don't fully understand this stuff, so the following 
might be nonsense...

IIUC this may be the responsibility of the number plan administrator of 
a country in those cases where that isn't delegated. But in some places 
it is indeed delegated, perhaps all the way down to an end customer. 
Certainly is sounds like it is that way in Germany.

> I'd rather see a mechanism that the number plan administrator could use
> directly, and I'd like to avoid the delegation issues of public enum.

In those cases where number length can be delegated it is *just* like 
the delegation issues of public enum. That is why it seems interesting 
to use the same or an analogous mechanism.

If the only variability was at the country level then I would agree with 
you that this is overkill and the data ought to simply be provisioned. 
Is would be quite feasible for individual UAs to be provisioned with 
data for all countries. But not every business in Germany.

	Paul

> It's really just a file.  Couldn't we just define an XML data structure for
> that file and figure out a way to publish it? 
> 
> Brian
> 
> -----Original Message-----
> From: enum-bounces at ietf.org [mailto:enum-bounces at ietf.org] On Behalf Of
> Hadriel Kaplan
> Sent: Saturday, April 05, 2008 1:49 AM
> To: Ray.Bellis at nominet.org.uk
> Cc: enum at ietf.org
> Subject: Re: [Enum] I-D Action: New draft - draft-bellis-enum-send-n-00
> 
> Howdy,
> I don't disagree with the points you guys are making, but I wonder if you're
> coming at this from the wrong angle given the relative sensitivities to
> ENUM-specific uses of DNS.
> 
> If one of your use-cases or goals is to enable this for public ENUM, I think
> one way to look at this is simply as a DNS problem.  Alice has asked a DNS
> NAPTR query, for foo.bar.com, and its server would like to tell her that
> NAPTR record types don't exist for foo.bar.com but may exist for
> *.*.foo.bar.com and *.*.*.foo.bar.com.  In other words the server wants to
> answer differently than not-found, or with additional detail, and could
> answer this way for any RR type asked of it for any name.  I have absolutely
> zero clue if that's going to help or make it worse in the IETF's view, but
> it's different. :) (it could easily be worse, fwiw, because it has a
> potential to raise a LOT of issues)
> 
> I hesitated saying this, because I fear what this would mean for UNUSED's
> chances of getting approved, but another way to look at it is as a specific
> type of UNUSED scenario, obviously.  Alice has asked a DNS NAPTR query for
> 1.4.4.e164.arpa, and there truly is no such E.164 globally (pstn and all),
> so all you're missing is something in the resulting data URN to tell the
> client why. (the latest draft is an http URL, but I'm going to try to revert
> to a data one that is well-defined, a la pstndata)  But at least you could
> then simply define an extension ABNF and semantics for the unused-data URN
> in a separate draft.  It would not break UNUSED, because the unknown
> extension abnf in the URN would simply be ignored.
> 
> If your goal is only private ENUM, but you want it publicly documented to
> foster interop with vendors for private use (a goal which I can certainly
> understand), then nothing stops you from defining it for UNUSED or your
> current way as an informational RFC, with clear language regarding
> applicability.  But I still think it would be good to hash out the best way
> for it to be done, so that it's not specific to private use in the UK.
> 
> -hadriel
> _______________________________________________
> enum mailing list
> enum at ietf.org
> https://www.ietf.org/mailman/listinfo/enum
> 
> _______________________________________________
> enum mailing list
> enum at ietf.org
> https://www.ietf.org/mailman/listinfo/enum
> 
_______________________________________________
enum mailing list
enum at ietf.org
https://www.ietf.org/mailman/listinfo/enum