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

["Brian Rosen" <br at brianrosen.net>]

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'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.

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