Subject: [e2md] Why do we have a framework instead of discrete services?

From: Dean Willis <[email-masked]>
Date: Tue, 23 Mar 2010 15:22:50 -0500

I was asked this question today and did not havea good answer handy.

E2MD is currently proposed as a framework. That is, we essentially have
a single database table that holds records for each data type. One
record might be a CNAM, the next might be an "unused" etc. The record
type is a subkey and we can query on it, like E2M+cnam or E2M+gspid

Why do we do this as opposed to having a separate table for each data
type, perhaps E2CNAM and E2GSPID?

It was put to me that some people see this as an end-run for getting
stuff into the DNS that wouldn't be allowed if it were being reviewed at
the top level, and that it would be much easier to get a working group
for something like E2CNAM than it will be for our open-ended model.

--
Dean

---

From: [email-masked]
Date: Tue, 23 Mar 2010 12:40:30 -0800

> type, perhaps E2CNAM and E2GSPID?

I have no great answer either, except that any argument made in favour of 
E2CNAM, E2SPID, etc, could equally apply to ENUM proper.

In any event, using E2CNAM etc would require a new full DDDS application 
for each potential record type.  By comparison setting up a framework 
which is 98% the same as ENUM's and then following the E2U service 
registration process should actually be much simpler in the long run. 

> for something like E2CNAM than it will be for our open-ended model.

The correct view (IMHO) on "getting stuff into the DNS" is that there is 
no problem using the DNS for anything - DNSEXT for example is concerned 
with protocol issues (RRs, etc) and _not_ with whether it's actually good 
policy to store any particular stuff in the DNS.

In effect, there is no "end-run" because it's simply not the job of any 
part of the IETF to decide what is or is not "allowed" in the DNS.

Ray

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 23 Mar 2010 16:42:45 -0400

Amen to that.

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Tuesday, March 23, 2010 4:41 PM
To: Dean Willis

The correct view (IMHO) on "getting stuff into the DNS" is that there is no problem using the DNS for anything - DNSEXT for example is concerned with protocol issues (RRs, etc) and _not_ with whether it's actually good policy to store any particular stuff in the DNS.

In effect, there is no "end-run" because it's simply not the job of any part of the IETF to decide what is or is not "allowed" in the DNS.

Ray

---

From: Bernie Hoeneisen <[email-masked]>
Date: Tue, 23 Mar 2010 22:03:43 +0100 (CET)

Hi Dean

In the following a non-exhausive list of arguments in favour of the 
framework approach for E2MD:

- we have over 10 potential Use Cases on the table
   (see archives of this mailing list)

- the framework model scales better

   - To call a BoF for every single E2MD services is too much overhead

   - Having a permanent WG to deal with new E2MD service proposals
     is not sensible either

   - E2MD services as AD sponsored has the potential to end up in
     a mess at least in the long run

- Expert Review will catch the dangerous stuff, the expert will have
   clear guidelines

- Prevent the IESG from unnecessairy load (as there will guidelines,
   a process and experts in place to support the IESG)

- we can re-use 95 % of the work we did in ENUM (no big effort anymore)

- IANA will be the central place to lookup what E2MD services exist
   (as opposed to the Table 2/3 issues we discussed in SIPCORE today)

- more to come...?

cheers,
  Bernie

On Tue, 23 Mar 2010, Dean Willis wrote:

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

---

From: Dean Willis <[email-masked]>
Date: Tue, 23 Mar 2010 16:15:46 -0500

>   (as opposed to the Table 2/3 issues we discussed in SIPCORE today)

I'm afraid that almost all of those are seen as arguments by the AD who
asked me the question for OPPOSING a framework approach, not creating
one. Some people really don't want it to be so easy to create new
metadata types, and see "having to BOF and form a working group" as a
very reasonable threshold for initiating the work. And inheriting the
badness of ENUM (along with its goodness) might not be a desirable goal.

Arguments FOR a framework would seem to be more related to the
structural similarity of the data, the commonality of access control
across different data types, the probability that you would really want
to do just ONE query and get back all the different metadata types, and
things like that. In other words, structural reasons for a framework,
not process/political ones.

--
Dean

---

From: Bernie Hoeneisen <[email-masked]>
Date: Tue, 23 Mar 2010 22:24:27 +0100 (CET)

> badness of ENUM (along with its goodness) might not be a desirable goal.

Question for clarification:
Are we here in a Layer 7- or Layer 9+ discussion???

cheers,
  Bernie

---

From: Dean Willis <[email-masked]>
Date: Tue, 23 Mar 2010 16:30:06 -0500

> Are we here in a Layer 7- or Layer 9+ discussion???

Certainly when one is talking about IETF policy and IESG preference,
especially in the context of such a subjective topic as "The DNS", one
is operating above ISO Layer 7.

Framing one's arguments in favor of doing something in terms that align
with those higher layers and are also supported at 7- is more likely to
succeed than arguments that are conflicted at either end of the stack.

--
dean

--
Dean

---

From: [email-masked]
Date: Tue, 23 Mar 2010 13:38:43 -0800

> is operating above ISO Layer 7.

Could perhaps these IESG and higher people who have these concerns come 
here and talk to us about them directly, ideally before the BOF?

Ray

---

From: Dean Willis <[email-masked]>
Date: Tue, 23 Mar 2010 16:47:15 -0500

> here and talk to us about them directly, ideally before the BOF?

Yes, that would be nice. I've taken to stalking them in their favorite
habitats,: backs of rooms, hallways, wine bars, and dark alleys.

--
dean

---

From: Lawrence Conroy <[email-masked]>
Date: Wed, 24 Mar 2010 09:40:01 +0000

Hi folks,
 for what it's worth, I had thought that the goals were pretty straightforward, the tools to use were pretty straightforward/obvious. I had also thought that access to the current repositories for sensitive data is very tightly access controlled (qua certain IAB members' experience).

The wide-ranging discussion on AAA seems to be entirely unrelated to the ground.
How does one expect IMS to work? In practice, it's a constrained access approach.
With the wide range of different extra data stuck to SIP messages, it has to be.

As Jim said, there *ARE* potential ways of dealing with sensitive data
at scale without Web 2.0, as it doesn't change often and the number of
unique accessors for this information is tightly limited. There is also
tight network/server access control that is really likely to be in place 
-- I sure don't see Hadriel's systems plugged into the Interweb directly.

However ... Inheriting ENUM's badness??? C'mon.
Do we really have stalking horses discussing artistic opinion. Coooool.
If some one has a point to make, then please can THEY make it, directly.
I cannot see what is wrong with the framework Bernie has been working
on for ages now, and have not heard of any direct statement on it.
I'm still waiting.

+1 for reuse of ENUM as far as possible.
+1 for the framework approach, so everyone knows how to develop a new case,
+1 for a narrow approach to current use cases.
+1 for flagging security concerns (or not, in some countries)
[+1 for continuing the current flags for security we already have in ENUM.
    these are clearly spelt out in Bernie's current work, so let's keep them]

-10 for having separate DDDS applications for each application. That
sure isn't what S/NAPTR does either, and that just sailed through the
IESG.

all the best,
  Lawrence

For the rest, we have

---

From: "Richard Shockey" <[email-masked]>
Date: Wed, 24 Mar 2010 12:35:40 -0400

Exactly ... these ancillary issues have only confused people making
chartering more difficult.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Lawrence Conroy
Sent: Wednesday, March 24, 2010 5:40 AM
To: Bernie Hoeneisen
Cc: E.164 To MetaData BOF discussion list
Subject: Re: [e2md] Why do we have a framework instead of discrete services?

Hi folks,
 for what it's worth, I had thought that the goals were pretty
straightforward, the tools to use were pretty straightforward/obvious. I had
also thought that access to the current repositories for sensitive data is
very tightly access controlled (qua certain IAB members' experience).

The wide-ranging discussion on AAA seems to be entirely unrelated to the
ground.
How does one expect IMS to work? In practice, it's a constrained access
approach.
With the wide range of different extra data stuck to SIP messages, it has to
be.

    these are clearly spelt out in Bernie's current work, so let's keep
them]

all the best,
  Lawrence

For the rest, we have