[e2md] Revised draft minutes of E2MD BOF at IETF 77

[Dean Willis <[e-mail]>]

Bernie and I have made some further cleanup on the draft minutes of  
the recent E2MD BOF. If you have any further feedback, please get it  
back to us ASAP.

Draft minutes follow:

Draft Minutes for E2MD at IETF 77
based on notes by John Elwell
Jabber session scribed by Patrik Fältström
edited by Bernie Höneisen, Dean Willis


Meeting started approximately 10 minute late due to delay in room exit
by prior group and equipment problems. Both chair's personal computers
kernel-panicked on connecting to the projector, and an attendees'  
machine
was pressed into service. Subsequently, the cord fell out of the main
microphone.

Chairs verbally reviewed "Note Well" and agenda, but did not present
related slides due to equipment delay.

Chair declared that the question for today's meeting was whether we
should form a working group to solve the problems that will be
discussed today using the general approach of a new DDDS based on
ENUM. Chair noted prior guidance from the IESG is that such a
specification would need to be written as if it were to be used on the
public Internet, even though use in private networks is more
common. AD Cullen Jennings declared that this was not necessarily the
case, and the group should first decide what it wants to do. John
Klensin suggested that if the work result is not intended for the
public Internet then it should be renamed, because a name like E2MD
implies a parallel to ENUM, which really was intended for the public
Internet during its conceptualization phase.

The chairs stated that the basic idea is similar to ENUM, but instead of
mapping the E.164 number to a URI that identifies the resource labeled
by the E.164 number, we are mapping the E.164 number to information
about that phone number.



Topic: Problem Statement and Use Cases
led by Bernie Hoeneisen

Slides presented reviewed several use cases under discussion:

* "unused" use case introduced by Bernie
* "send-n" use case introduced by Ray Bellis
* "cnam" use case introduced by Richard Shockey
* "Global Service Provider Identifier" use case introduced by Bernie

Noted that the ENUM working group agreed a draft on the CNAM use case,
and that the DRINKS working group earlier this week had discussed
mechanisms for provisioning a global service provider identifier.


Jon Peterson asked: What is metadata? These 3 use cases are all rather
different - is there really anything in common? Debate ensued, with
the one commonality noted that all the data in question has in common
that it is keyed by the E.164 number and might be needed either when
starting or accepting a session using that E.164 number as its target
or source. Bernie noted that ENUM had different kinds and classes of
ENUM services, and had provided a classification mechanism as part of
the IANA registration document.

Ray Bellis responded, discussing the relationships between the send-n
and unused cases with ENUM. Both send-n and unused are helpful in
resolving ENUM lookups and need to be done in conjunction with the
ENUM lookup, literally at the same time.

John Klensin challenged the assumption that the DNS is a good place to
keep this data, noting that we have a lot of other information that
might be keyed by the phone number but that we do not store in the
DNS. Further, storing data in the DNS with record types that lead to a
potential for contradictions or unclear semantics gives a potential
for abuse of the DNS. We will need to be able to say why each piece of
metadata is important enough to put it into the DNS,

Bernie noted that the DNS is a good way of distributing the
responsibility, and that the delegation structures and relationships
of the metadata in question are identical to those of ENUM.

Dean reported that John's question had already been discussed on the
mailing list, and the 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 any new protocol would
need 90% functionality of DNS making it not worth inventing something
new.

Peter Koch noted that CNAM is rather different from the other use
cases. For send-n, he doesn't believe that the problems with the
proposal are removed by using E2MD rather than ENUM -- that it makes
no difference what the string in NAPTR is. He suggested that killing
the whole dependency on ENUM stuff and doing a roll-over not based on
NAPTR may be a better approach.

Olaf Kolkman agreed that the ENUM tree matches well with hierarchy,
but wondered what form of query/search systems might be needed. For
example, if we need to search for metadata with a specific number, it
might be better to have a service just for that. He suggested that it
might be good idea to look for different tools for this problems.

Dean noted that this had come up in on-list discussion, and that the
later discussion would touch on using E2MD to find a URI for a
metadata service.

Dean noted that the existing use cases had been debated on the list
and that the list felt that DNS was a good match for these use cases,
but that we would need to provide guidance on evaluating future use
cases as.

John Klensin noted that when we did the ENUM work, we mapped phone
numbers to DNS for a a specific reason, but assumption that numbers
were well matched to DNS would be wrong. The inverse ordering model
creates a vast number of DNS hierarchy levels and is not particularly
optimal.

Richard Shockey responded that ENUM does work well, and is deployed in
a number of trees. Practical experience shows that it would work
equally well for other types of data.

Jon Peterson noted that ENUM  kept running into security properties, and
the constraints in E2MD may prove to be even more restrictive.

Richard Shockey noted that there are many successful ENUM deployments
in private environments, and that this resolves most of the security
issues.

Andrew Sullivan suggested that the problem is that there a tiny part
of DNS that is not a good fit, but if that is an important part, then we
should reconsider using DNS as the basis for E2MD.



Topic: Issues from List
led by Dean Willis


Issue: DNS record size.

List discussion agrees that the E2MD space in DNS is size constrained,
and that each use case will have to be analyzed for suitability and
unsuitable use cases rejected. further, the group agrees that they
will have to produce guidance documents for future reviewers of use
cases.

Cullen challenged the group to scope this so it would be approvable,
apparently asking for the review guidelines to be finalized before the
work is done. He proposed a use case of putting a ring-tone into the
DNS, and asked how we would evaluate it. Discussion ensued, with some
participants maintaining that this is a valid use case, others
suggesting that this was a bad idea and that it would perhaps be
reasonable to insert a URI that indicates a ring tone. Lawrence Conroy
noted (via remote) that an upper bound on size is probably 250 bytes.



Issue: Is everything a NAPTR?


Jon Peterson observed that this goes beyond just CNAM not being like
the others. Why should we use NAPTR, if we have to do some kludge on
the data just to make it fit into a NAPTR record

Patrik Fältström noted that there had been a number of problems with
NAPTR record with ENUM, so perhaps we shouldn't use it for this, in the
same way we should not have for ENUM. Need to see what record types
match and perhaps use a better choice, rather than just following
ENUM.

Jon noted that it is improbable that one RR type would fit all use
cases, and that we would therefore have to look at each use case
separately. This suggests that we do not need an overall framework for
metadata, but should charter work for individual metadata use cases.


Discussion moved onto response filtering and aggregation.


Spencer suggested that having a profusion of reseource record types
might be even scarier than everything being one NAPTR or one
container.

Dean noted that multiple RR types might be one approach, and that
various other filtering techniques might be applied. For example, the
underscore prefixing used with SRV records might give a clue to
another possibility.


Question: How large are the responses. Dean responded that with many
use cases feeding into a NAPTR RR-set we might have very large
responses.

Dave Crocker observed that our current discussion is about low level
implementation choices.  We need to or might do lots of different
things, but without very specific use cases as goals, we have no way
to select an approach. He also berated the group for not having
considered underscore prefixes as used in SRV records.


Dean noted that we do have 4 specific use cases under discussion, with
I-Ds on 3. Bernie stated that about 10 more have been proposed to the
list.


Jon asked what these use cases have in common? Dean responded that the
information is indexed by the phone number and used when either
setting up or answering a call, to which Jon disagreed without further
explanation being recorded.


David Schwartz noted that the common factor is not "has to do with
call routing", since the CNAM proposal clearly doesn't.

Issue: Registration Procedure

Current document suggests Specification Required (with Expert Review
procedures TBD) Cullen supposed that if ENUM were 1st come 1st served,
we would not be having this BoF (we would have just done it in ENUM,
with the implication that this would have been a Bad Thing).

Richard Shockey noted that the proposed process follows ENUM as
closely as possible, as the ENUM process has been shown to work.



Conclusion: Polls of the Room

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

Poll: Who thinks DNS is a suitable basis?

Dave Crocker declared that since we don't have specific set of
problems there is no rationale for deciding whether DNS is the right
basis. Chair responded by moving to discussion of specifc use cases.

Poll: Who agrees DNS is suitable for CNAM: 10 for, 3 against.



Poll: (asked by Richard) We are debating solutions before we establish
a charter.Is this a problem that we in IETF can solve, are there
people who would like to fix problems?  Response was mixed.

Christer asked that if we assumes SIP is the main usage, can we solve
CNAM with SIP OPTIONS? Dean responded that it is doable with a SIP
event package, and that this approach had been previously suggested.


Gonzalo suggested following up with questions from the "How to have a
successful BOF" list such as "should a WG with the following charter
be formed?"


Poll: Who thinks the problem space has been clarified by the current
drafts and proposed charter such that we understand the proposed
scope? Mixed response.

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

Poll: Who has read the proposed charter? A large percentage responded.

Poll: Who thinks the proposed charter is close to being usable?
Response generally favored the negative.

Poll: Who thinks the proposed charter is too vague or proposes an
untenable approach? Response generally disagreed that the charter was
adequate.

Gonzalo observed that we didn't really discuss the charter in this
room, and we should have asked the question whether we want to propose a
WG based on that charter. The chairs, who thought they had just asked
that question, merely nodded in response.

John Klensin suggested that we should ask who thinks proposed charter
it not ready to go. The chair responded that the question had already
been asked, and that more people thought it was not ready to go
than thought it was ready to go.


Chair's conclusion:


The problem scope appears to be clearly defined, but the general
solution model of defining an open-ended framework is problematic due
to concerns about review and approval, and concerns about the general
applicability of the ENUM process to encompass the larger metadata
problem. Consequently, the proposed charter defines too large a
scope. An approach that scales back to solving specific metadata
issues one at a time may be more sustainable. Alternately, a solution
that strongly revises (or replaces) ENUM  might be better tolerated by
the community.