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

["Richard Shockey" <[e-mail]>]

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: [e-mail] [mailto:[e-mail]] 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
[e-mail]
https://www.ietf.org/mailman/listinfo/e2md