Subject: [e2md] Divide and conquer!

From: Bernie Hoeneisen <[email-masked]>
Date: Tue, 30 Mar 2010 10:14:39 +0200 (CEST)

Hi,

Reading through all the emails I believe the best way to address the
problem space is the following approach:

   Divide and conquer!

By that I mean to divide the problem space into a short term and a
long term solution and conquer the both separately.

- Short term solution:

   Approach the easy use cases along the lines of
   http://tools.ietf.org/html/draft-hoeneisen-e164-to-metadata-02
   (What the _easy_ use cases are, is yet to be determined.)

   I guess we'll have to ditch the framework approach (at least for the
   time being) and rather concentrate on the E2M DDDS application and the
   easy use cases.

   I could imagine to re-charter the ENUM WG for this.  At least Dave
   Crocker indicated to me that an approach that simply enhances ENUM
   with additional records is more likely to get the required support,
   as opposed to define a new protocol decoupled from ENUM.

   Exact strategy for short term solution is yet to be worked out.

- Long term solution:

   The long term solution goes through the normal IETF process and
   starts with the collection and documentation of requirements and use
   cases.

   The goal could be a general mapping mechanism to map phone numbers
   to other addresses (forth and back) including source dependent
   queries and other stuff that has been proposed.

   Note: The solution does not necessarily be in DNS.

   Once we have the requirements in written, we'll prioritize them and
   formulate a charter proposal. If we get the requirements ready in
   time for Maastricht, we'll propose a BoF, which needs to happen
   latest by May 2010, according to:
   http://www.ietf.org/meeting/cutoff-dates-2010.html#IETF78

What is your general feeling about this "divide and conquer" approach?

If we go this way, we need a volunteer to make a proper requirements
document for the long term solution.

cheers,
  Bernie

---

From: Bernie Hoeneisen <[email-masked]>
Date: Tue, 30 Mar 2010 10:30:38 +0200 (CEST)

Oh yeah, and let's simply name the long term solution:

  HAMMER --> H... Address Mapping for Multimedia Enabling R...

Any smart(er) ideas for the missing H and R (and other letters)?

:-)

Have fun!

cheers,
  Bernie

On Tue, 30 Mar 2010, Bernie Hoeneisen wrote:

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

---

From: Jay Daley <[email-masked]>
Date: Tue, 30 Mar 2010 21:39:28 +1300

> What is your general feeling about this "divide and conquer" approach?

There are still two important issues that this does not resolve:

1.  It appears this initiative has become a venue for a proxy war against NAPTR and ENUM in general.  If we don't resolve that then we don't get anywhere.

2.  We have no clear way of deciding what is easy and what is not.  I suspect your attempt to separate out "things that require a change to the protocol" into the not easy pile will not work - the discussion over the last day has already gone against that.

> document for the long term solution.

I think that is premature.  We are better off determining what the requirements are for easy and then seeing if the necessary features can be delivered in a compliant way.  For example my alternative to source-uri is an 'easy' way of doing the same thing.

cheers
JAy

-- 
Jay Daley
Chief Executive
.nz Registry Services (New Zealand Domain Name Registry Limited)
desk: +64 4 931 6977
mobile: +64 21 678840

---

From: Dean Willis <[email-masked]>
Date: Tue, 30 Mar 2010 03:59:02 -0500

On Mar 30, 2010, at 3:39 AM, Jay Daley wrote:
>>
>
> I think that is premature.  We are better off determining what the  
> requirements are for easy and then seeing if the necessary features  
> can be delivered in a compliant way.  For example my alternative to  
> source-uri is an 'easy' way of doing the same thing.

I'd like to work through Jay's proposal in a little more depth. It may  
well provide the basis of an "easy" approach that also leads us to  
solving the whole problem space in a way that makes E2MD both  
efficient and palatable to the DNS directorate folks (which would be  
very, very cool). Or it might not, but working through it will at  
least get us a better understanding of the potential solution space.

--
Dean