Subject: [e2md] E2MD rough notes

From: "Elwell, John" <[email-masked]>
Date: Thu, 25 Mar 2010 00:19:28 +0100

05 Admin and Agenda Bash

15 Problem Statement and Use Cases
Dean: We are here to decide if we want to form a WG.
IETF says that we must write spec as if it were for the public Internet.
Cullen: Not exactly - want to know what it is and how it would work.
John Klensin: If not intended for public Internet, should find a different name.

Intro: Bernie Höneisen
"unused" use case
"send-n" use case (Ray Bellis)
"cnam" use case (Richard Shockey)
"Global Service Provider Identifier" use case

Jon: Clarification - URI identifies a resource, not necessarily for establishing a communication session.

Richard Shockey. Pointed out that DRINKS had discussion on provisioning of the Service Provider Identifier.

Jon: What is metadata. These 3 use cases are all rather different - is there really anything in common?
Bernie: ???? Missed his answer
Jon: What's metadata?
Bernie: Information about a phone number.
John Klensin: We have a lot of other information that we do not store in DNS. Fine to link to phone number, but storing in DNS is a big step, and storing with record types that lead to a potential for contradictions, will lead to potential for DNS abuse. So why is it important enough to put in DNS, and why is this unique c.f other types of metadata.
Bernie: DNS is a good way of distributing responsibility.
Ray: Addressing JP's comment. Disagrees that send-n and unused are very different - similar to ENUM.
Dean: I had asked John's question on mailing list, and sense of mailing list was that we already have the phone number keyed structure from ENUM, and we need the same hierarchical and caching characteristics, so 90% functionality of DNS.
Peter Koch?: Agreed that CNAM is rather different. For send-n, doesn't believe ugliness is removed by using E2MD rather than ENUM. No difference what the string in NAPTR is. Killing whole ENUM stuff and doing roll-over not based on NAPTR may be better.
Olaf Kolkman: ENUM tree matches well with hierarchy, but wondered that putting metadata in system, what form of query/search systems do you need. If you need to search for metadata with specific number, might be better to have a service just for that. Might be good idea to look for different tools for this problems.
Dean: Should be a slide addressing this later.
Dean: Debated on list and felt DNS was a good match for use cases, but would need to provide guidance on evaluating future use cases.
John Klensin: When ENUM work, we mapped to DNS for a reason, but assumption that numbers were well matched to DNS would be wrong.
Richard Shockey: Counter argument is that ENUM does work well, and is deployed in a number of trees. Would work for other types of data is that it is a good hammer, so let's try it.
Jon Peterson: Kept running into security properties, and these were found to be even closer.
Richard Shockey: Many successful deployments in private environments.
Andrew Sullivan: Problem is that there a tiny part of DNS that is not a good fit, but if that is an important part, should reconsider.

10 Issues from List: Dean Willis
DNS record size.
Cullen: Even though present use cases are all small, will there be future  bigger ones?
Dean: Guidance will be given on suitability. Is size-constrained.
Richard: Not necessarily size-constrained.
Cullen: What is a good idea for putting in here and what is not? How can we scope this so someone can approve it.
Spencer Dawkins: Are you suggesting ???
Dean: Yes.

Is everything a NAPTR
Jon: Goes beyond just CNAM not being like the others. Why do you need NAPTR, if have to do some kludge.
Patrick Faltstrom: Number of problems with NAPTR record with ENUM, so perhaps shouldn't use it for this, in same we should not have for ENUM. Need to see what record types match and perhaps using correct choice, rather than just following EN@UM
Jon: Would one record type necessarily fit all cases?
Dean: So look at cases separately.
Jon: So why do you need a framework then?
Spencer: What you said then sounded scarier than everything being one NAPTR or one container.
Dean: Yes, that is one approach, or could have different filter criteria. SRV records might give a clue to another possibility.
Jabber: Question concerning size of response.
Dean: With many use cases you might have a very large response.
Dave Crocker: Discussion is on low level implementation choices. Need to do lots of different things, but without very specific use cases as goals, so how can you select. Also mentioned possibility of txt records.
Dean: We do have 4 specific use cases, with I-Ds on 3.
Someone: 10 more have been proposed to list.
Jon: What do they have in common.
Dean: indexed by phone call etc.
Jon: Disagree.
Cullen: What would be the registration procedure. If ENUM were 1st come 1st served, we would not be having this BoF.
Dean: Current draft charter suggests expert review.
Richard Shockey: Tried to follow ENUM as closely as possible.
David Schwarz: Is this something to help me make routing decision? CNAM has nothing to do with routing.

Who thinks there is something worth looking it? A lot of people raised hands.

Who thinks DNS is a suitable basis?
Dave Crocker: Don't understand the sequence of questions. Don't have specific set of problems, so no basis for deciding that DNS is right basis.
Dean: Let's back-up and look at CNAM
Who agrees DNS is suitable for CNAM: 10 for, 3 against.
Who agrees ENUM is suitable for CNAM:  - not taken.
Richard is this a problem, is this a problem that we in IETF can solve, are there people who would like to fix problems. We are debating solutions before we establish a charter.
Christer: Assumes SIP is main usage, so can't we do CNAM with SIP OPTIONS?
Dean: Could do by SIP event package.
Gonzalo: Should ask if ????
Dean: Who thinks problem space has be clarified that we understand scope, some do, some don't.

Dean: Are there people who want to solve problem: a fairly large number.

Gonzalo: We didn't discuss charter, and we should have asked question whether we want to propos WG based on that charter.

John Klensin:  Should ask who thinks proposed charter it not ready to go.
Dean: Asked that question. More thought it was not ready to go than thought it was ready to go.

10 Discussion of Open Issues: Open

10 Charter: Bernie

10 Next Actions and Conclusions (chairs/ADs)