Subject: [e2md] Where do we think we're going with E2MD?

From: Dean Willis <[email-masked]>
Date: Mon, 3 May 2010 22:22:19 -0500

Before we start trying to nail-down a next-gen charter, I'd like to  
ask some questions about where we think we're going with E2MD.

I see a couple of paths:

1) We come up a level and do a problem definition, then a requirements  
analysis, then an analysis of extant protocols to see if anything can  
be hammered into shape, and then a final protocol to meet those  
requirements.

2) We stay with a straightforward ENUM extension as proposed in   
Bernie's draft, and commit to developing the guidance necessary to  
make such a mechanism "Internet safe", including giving guidance on  
when it really needs to be used in a private network as opposed to  
public Internet. This will mean talking about the security sensitivity  
of data, the size of RRsets, etc.

3)  As #2, but we ditch the "framework" model and require standards- 
track work for each new metadata type.

4) We stay with ENUM extension, but define an extension model that  
offers better query selectivity, such as using new RR types for some  
queries where NAPTR might not be optimal. Again, we may need to  
include source-URI work and deal with content sensitivity (although it  
could be as simple as saying "When used on the Internet, one must  
assume that all data is world-readable and therefore not provision any  
data that requires privacy controls.")

5) We make a minimal modification to ENUM to add a metadata URI;  
basically one NAPTR record per E.164, and define how some other  
protocol can be used to retrieve the metadata. Possibly we extend the  
scope to include developing a highly-efficient stateless UDP protocol  
based on DNS Query that meets the needs for high-capacity private  
networks, and possibly a profile for using HTTP (or HTTP/TLS) that  
meets the requirements for public networks and/or authentication- 
sensitive responses. Also optionally, we could define the high- 
efficiency protocol such that it can be accessed directly in private  
networks without the need to dereference a URL from ENUM, assuming  
that the querying node is already configured with where-to-ask (which  
is how we really use DNS now). Open question: Does said high- 
efficiency protocol address Hadriel's source-URI requirements?

Or we could do some combination of these things, or something entirely  
different. The important thing is that we 1) have a strong consensus  
on what we're doing, and 2) anticipate and be prepared to answer the  
questions we know are coming, because we heard them at Anaheim.

--
Dean

---

From: "PFAUTZ, PENN L (ATTCORP)" <[email-masked]>
Date: Tue, 4 May 2010 07:21:57 -0400

Is it legit as a charter to basically state the use cases we've come up
with and say we'll examine the alternatives laid out in (2), (3),(4),
and (5) as potential solutions taking into account the concerns (list
them) brought up at the BOF. 

Penn Pfautz
AT&T Access Management
+1-732-420-4962
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Dean Willis
Sent: Monday, May 03, 2010 11:22 PM
To: E.164 To MetaData BOF discussion list
Subject: [e2md] Where do we think we're going with E2MD?

I see a couple of paths:

--
Dean

_______________________________________________
e2md mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/e2md

---

From: Dean Willis <[email-masked]>
Date: Tue, 04 May 2010 10:57:50 -0500

Yeah, that could work.
-- 
Dean Willis