Subject: Re: [Enum] [e2md] E2MD and Indirection -- a new problem statement

From: "Richard Shockey" <[email-masked]>
Date: Fri, 14 May 2010 13:33:16 -0400

DNS technology Dean !!! ..stop this "It's the DNS" thing.  Its not about the
DNS it never was. You are perpetuating the problem once again. 

If you note the ENUM charter we never ever used the word DNS. That was
deliberate and calculated when I wrote it. 

Delete the word DNS from your text and it closer to the reality here. Now of
course the solution is really the two variants of 3761 in deployment the
public trees and the private closed ones.  The use cases would reflect that
matrix of options. Indirection is NOT needed in closed systems its simply
interjects a redundant look up into the system that causes delay is session
set up. 

Goal of the E2MD Work (see how much better it reads when you don't talk
about the DNS :-) 
---------------------

An easily extensible framework for using the DNS to discover data that 
is related to an E.164 number. The 
framework's organizational model is expected to be based as closely as 
possible on the existing ENUM [RFC 3761 framework] . The framework is
expected to 
provide for a multiplicity of different data types and provide for a 
semantic definition of each data type as well as define its relationship 
with the aforementioned E.164 number. The framework is expected to 
provide for storing some data types directly, and in other 
cases to store a reference to the data, with that 
determination based on the nature of the data type and its use cases.

The framework is NOT expected to provide a selective query mechanism; 
rather, a query for framework data associated with an E.164 number 
is expected to return all such data and data. The framework's query
mechanism will make no considerations 
for authentication, authorization, or selective response based on the 
identity of the querying node. Further, the framework's mechanism 
is expected to make no considerations for network congestion, 
reliability, integrity, privacy, or overly-large response sets.

Where such considerations are significant, the framework is expected to 
provide guidance on the use of other protocols that will be used to 
retrieve the framework data referenced , and such other 
protocols are expected to provide needed considerations for 
authentication, authorization, selective response based on the identity 
of the querying node, network congestion, reliability, integrity, 
privacy, and large responses. The framework is expected to provide for 
standardization and IANA registration of new data types without a 
requirement for IETF consensus on each new data type, using the existing 
ENUM service registration model.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dean
Willis
Sent: Friday, May 14, 2010 12:25 PM
To: E.164 To MetaData BOF discussion list
Subject: [e2md] E2MD and Indirection -- a new problem statement

I've heard Ray and Richard say that indirection might be appropriate in
some cases. If we're willing to factor that into the work, we might have 
an opportunity.

If we amended our problem statement to say that we would analyze the
initial use cases, determine which cases need to be "in the database"
and which need to be indirectly referenced, show how to indirectly
reference where needed, and provide guidance for future users on how to
make this determination and provide future guidance on dereferencing,
then I predict our problem statement would be MUCH more palatable to the 
opposition.

Let's try a re-write of my proxy-shill version and see if it gets
friendlier looking. This one's a bit rough, but it should convey the basics:

Goal of the E2MD Work
---------------------

An easily extensible framework for using the DNS to discover data that 
is related to an E.164 number also resolvable in the DNS. The 
framework's organizational model is expected to be based as closely as 
possible on the existing ENUM framework. The framework is expected to 
provide for a multiplicity of different data types and provide for a 
semantic definition of each data type as well as define its relationship 
with the aforementioned E.164 number. The framework is expected to 
provide for storing some data types directly in the DNS, and in other 
cases to store a reference to the data in the DNS, with that 
determination based on the nature of the data type and its use cases.

The framework is NOT expected to provide a selective query mechanism; 
rather, a DNS query for framework data associated with an E.164 number 
is expected to return all such data and data references known by the DNS 
to the querying node. The framework's expected query mechanism is 
expected to be straight-up DNS, and as such will make no considerations 
for authentication, authorization, or selective response based on the 
identity of the querying node. Further, the framework's query mechanism 
is expected to make no considerations for network congestion, 
reliability, integrity, privacy, or overly-large response sets beyond 
the inherent mechanisms of the DNS.

Where such considerations are significant, the framework is expected to 
provide guidance on the use of other protocols that will be used to 
retrieve the framework data referenced from the DNS, and such other 
protocols are expected to provide needed considerations for 
authentication, authorization, selective response based on the identity 
of the querying node, network congestion, reliability, integrity, 
privacy, and large responses. The framework is expected to provide for 
standardization and IANA registration of new data types without a 
requirement for IETF consensus on each new data type, using the existing 
ENUM service registration model.
_______________________________________________
e2md mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/e2md

---

From: Dean Willis <[email-masked]>
Date: Sat, 15 May 2010 00:29:07 -0500

> DNS it never was. You are perpetuating the problem once again. 

Dude! Slow down and get this through your head: As far as the "rest of
the IETF" is concerned, ENUM is about putting phone numbers in the DNS,
and as long as ENUM relies on the core protocol of the DNS, any
extension to ENUM is an extension to the DNS.

Failure to understand this very fundamental concept is why we don't
understand the objections that Olaf and Peter and John and Jon and other
DNS people keep bringing up. And it's why "just restarting the ENUM
working group" will not solve the E2MD problem: the same people that are
objecting to E2MD as a standalone working group will object to
restarting ENUM. This is also why the CNAM draft that "had consensus in
ENUM" did NOT advance through the IETF and is not currently "a
standard." If the approach was ever going to fly, it would have migrated
south for the winter years ago!

Either solve the problem in a way that is acceptable to "the DNS people"
 by using the DNS consistently with their guidelines, or move the
problem outside the DNS. Trying to shove it down their throats is just
going to perpetuate further non-progress.

--
Dean

---

From: Tony Rutkowski <[email-masked]>
Date: Sat, 15 May 2010 07:31:30 -0400

> going to perpetuate further non-progress.

Well said.  The OID Resolution Sytem (ORS) folks ran into
the same pushback from the "DNS people," even when a
similar instantiation occurred with ONS.

--tony

---

From: [email-masked]
Date: Sat, 15 May 2010 22:56:42 +0000

hum, as a "DNS person"... I spent a fair number of hours ~70% of my time,
working on something almost identical to the VSGN-ONS platform ... with the
AutoID labs folks in Japan.  We never called it anything other than what
it was, DNS with extentions.   Never remember any public pushback from the
"DNS people" on ONS.  Archives?

--bill

On Sat, May 15, 2010 at 07:31:30AM -0400, Tony Rutkowski wrote:
> enum mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/enum