[Enum] IETF65 ENUM session minutes

minutes are below - thanks to Spencer and Bernie for serving as scribes.

----
IETF65 (Dallas, TX) ENUM meeting minutes

Chair(s):
Patrik Faltstrom <paf@cisco.com>
Richard Shockey <rich.shockey@neustar.biz>

WG Secretary:
Alex Mayrhofer <alexander.mayrhofer@enum.at>

Scribes:
Spencer Dawkins <spencer@mcsr-labs.org>
Alex Mayrhofer <alexander.mayrhofer@enum.at>

Jabber Scribe:
Bernie Hoeneisen <bhoeneis@switch.ch>

Real Time Applications Infrastructure Area Director(s):
Cullen Jennings <fluffy@cisco.com>
Jon Peterson <jon.peterson@neustar.biz>

AGENDA BASHING (5 min)
======================

Slight change to agenda - Patrik talks about 3761bis planned works first:

RFC3761bis
==========

Patrik is not upping for IAB, so has time to update RFC3761 (3761bis),
which is in line with WG milestone.

A RT tracker system is set up for work on this document, issues should
be opened as tickets in the system. One ticket per issue should be
opened, there will be shared username/password for access to the system.

Patrik will work on the individual issues, and resolve corresponding
tickets once an issue is resolve. When all issues are resolved, the
document should be ready. 3761bis does not exist as an draft yet - RT
stuff will provide input for this. Patrik will do the editing.

More info:
http://www1.ietf.org/mail-archive/web/enum/current/msg04849.html

Tickets could also affect other documents (conroy asks for DDDS
issues). Shockey asks if guidance on non-terminals should go in there
as well. Conroy suggests to put hints in 3761bis. patrik: operational
experience stuff could go in seperate section or even document.

ENUM Implementers Draft: (Final Version) 5 MIN
==============================================

Title		: ENUM Implementation Issues and Experiences
	Author(s)	: L. Conroy, K. Fujiwara
	Filename	: draft-ietf-enum-experiences-04.txt
	Pages		: 37
	Date		: 2006-3-9

This document captures experience in implementing systems based on
the ENUM protocol, and experience of ENUM data that have been created
by others.  As such, it is advisory, and produced as a help to others
in reporting what is "out there" and the potential pitfalls in
interpreting the set of documents that specify the protocol.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-enum-experiences-04.txt

slides: http://www3.ietf.org/proceedings/06mar/slides/enum-8.ppt

*  Changes include section 6 (general DNS issues), request publication -
Section 6 is biggest source of changes (others mostly editorial, seeking
clarity, please give feedback for continued improvements).
* Added size recommendations for EDNS0, intermediate system guidance, TTL
and ANY (255) queries (this is a general DNS issue, but has been a problem
in ENUM deployment - NAPTRs appear/disappear, etc.).
* Please read and review - think we are finished, publish and update later
if we need to.
* Tim - "Non-terminal NAPTRs SHOULD NOT be used" - can't go quite this far -
if you're gonna do this, it will take a long time - one third of the code on
mobile clients deals with this. EDNS0 doesn't work with TCP, etc. - lots of
things break. We'll talk offline, and this is a good WGLC comment.
* EDNS0 is recommended here. May be spun off as separate document and just
referenced here (if we can avoid dependencies). Still discussing MUST
capitalization with DNSOPS reviewers.
* Peter Koch: Implementation and OPS side is too much in one document -
advocate separation. Having normative language for firewalls isn't
appropriate in this standards track document. EDNS0 is a precondition for
anything that uses DDDS - make a recommendation for minimum size in general,
TCP, etc.
* Conroy: Firewalls break DNS over TCP all by themselves, without any ENUM
involved.

Enumservices Guide
==================

Title		: Guide and Template for IANA Registrations of Enumervices
											[ 15 M ]
	Author(s)	: J. Livingood, B. Hoeneisen
	Filename	: draft-ietf-enum-enumservices-guide-00.txt
	Pages		: 12
	Date		: 2006-2-27

   This document provides a guide to and template for the creation of
   new IANA registration of ENUM services.  It is also to be used for
   updates of existing IANA registrations.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-enum-enumservices-guide-00.txt

slides: http://www3.ietf.org/proceedings/06mar/slides/enum-4.ppt

History: People filling out over and over again same sections with same
content when doing Enumservice registrations. Standard template desired.

request input for 3.2 ("Intended usage: COMMON") and 3.6 ("IANA
Considerations"). Please post text or email privately.

Section 3.2 - should a subtype always be given? should seperate subtypes
have seperate registrations? for each URI scheme seperate?
Statement on non-terminal NAPTRs?

suggested answer: yes/yes/yes/no (with warning on non-terminals)

Penn: didn't get a lot of guidance - would like template that includes
cautions.
cautions ok, but should actually tell you how to do this.
Stastny: Usage of non-terminals need to be clarified before usage of
them is advocated.
shockey: should the behaviour regarding non terminals be in registration
document itself?
conroy: could imaging 2 ways to non-terminals. currently, missing flag
indicates "non terminal", which is outside DDDS. If no flag is given,
we can't do registrations, so seperate flag and seperate registration?

no final conclusion about the four questions.

CNAM
====

Title        : IANA Registration for an Enumservice and "tel"   [ 15 Min ]
    Parameter for Calling Name  Delivery(CNAM) Information
    Author(s)    : R. Shockey, J. Livingood
    Filename    : draft-shockey-enum-cnam-00.txt
    Pages        : 10
    Date        : 2006-1-13

   This document registers the Enumservice "cnam" and subtype "tel"
   using the URI scheme 'tel:', as per the IANA registration process
   defined in the ENUM specification, RFC 3761.

   In addition this document registers the parameter "cnam" in the IANA
   "tel" Parameter Registry defined in RFCXXX.  This data is used to
   facilitate the transfer of Calling Name Delivery (CNAM) data for
   calls that originate on the PSTN that may be displayed on VoIP or
   other Real-time Client User Agents (CUA).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-shockey-enum-cnam-00.txt

slides: http://www3.ietf.org/proceedings/06mar/slides/enum-6.ppt

is about caller name display. info is requested in the US before
callees phone rings. service assumes a private tree, with info
not public.

discussion about tel uri parameter vs. data uri. draft proposes tel
parameter, but not sure about this (list discussions).

What character set being used? No ultimate restriction, but PSTN limits
to 15 characters in ASCII. How to interpret contents? DDDS says UTF-8,
but there should be wording about this in there. Need to be aware what
is about to being parsed (security considerations should point that out).
List of CNAM specs to point people to is requested.

Group agrees to adopt this as WG item - no "no" hums in room.

tel or data URI? Paul primary objector, but not in the room. "tel"
because this is a classic PSTN thing?
Jon: don't compete with SIP caller name - what happens if both present?
This needs to be interopable with normal SIP stuff.
Jason: What if other providers don't have SIP URIs in their network, and
are trying to limit the number of bits they are paying to store?
Lawrence: Could have "network provided" and "user provided" numbers as well.
this is for "network provided" - we use TXT in trials now.
Jon: If network provided, don't we prefer to render that? Display name
could be present in from tel or sip. data would never show up in SIP,
but the servers or user agents would fetch it. depends all on call flows
and use cases. don't couple with tel - would never appear in request.
Jason/Richard: No preference, will dig deeper into data URI.

IAX2 Enumservice:
=================

Title		: IANA Registration for IAX Enumservice            [ 15 M ]
	Author(s)	: E. Guy
	Filename	: draft-ietf-enum-iax-00.txt
	Pages		: 13
	Date		: 2006-2-22

This document registers the IAX2 (Inter-Asterisk eXchange Version 2)
Enumservice using the URI scheme 'iax2:' as per the IANA registration
process defined in the ENUM specification RFC3761.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-enum-iax-00.txt

slides: http://www3.ietf.org/proceedings/06mar/slides/enum-7.pdf

Need IAX2 URI registration, and a new template has shown up since
last time.
Some minor tech changes.
Currently requested IESG review of protocol itself, will submit URI
request using new template.
Enumservice would need to go after URI registration (because RFC editors
would need to perform edits otherwise).

ENUM & Domainkeys
=================

Title		: Telephone Number Mapping and Domain Keys  as a Distributed
Identity Infrastructure                                        [ 15 M ]

	Author(s)	: A. Mayrhofer
	Filename	: draft-mayrhofer-enum-domainkeys-00.txt
	Pages		: 10
	Date		: 2006-2-23

   This document creates a decentralized indentity infrastructure by
   combining technology from E.164 Number Mapping (ENUM) and DomainKeys
   Identified Mail (DKIM).  This infrastructure uses E.164 numbers as
   identities, ENUM DNS for key distribution, and leverages the trust
   relations from ENUM validation to actual messages signed by the
   number holder.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-mayrhofer-enum-domainkeys-00.txt

slides: http://www3.ietf.org/proceedings/06mar/slides/enum-2.ppt

# Not a full DDDS app, not a full Domain Keys app, so ...
# Validation is most expensive part of ENUM provisioning - validation takes
the identity to Internet domain - make use of this expense!
# ENUM, not full DDDS
# Domainkeys, but just key/storage
# Validate that Sender has the same identiry as number holder
# Available to any ENUM domain holder, no prior knowledge about sender
required, any node on Internet can do this, domain internationally agreed,
common validity.
# Applications - signin to P2P networks, CLI signalling to PSTN, SPIT
prevention.
# Disconnected nodes could do authentication (with cached public keys)
# Looking for opinions/feedback
# Looking for crypto-PKI clue on co-authors
# Steve Kent - you're going down to individual devices, right? form of
identifier needs to be appropriate for applications. Going to this
granularity needs to scale bigger than the DKIM application today, so think
about scaling. (and why not DNSsec?)
# Koch: How much do you want to trust DNS? You need DNSsec to trust this
anyway, and if you do have DNSsec, maybe this would be enough. Cool ideas
with deployment problems, probably premature, keep thinking.
# David Schwartz - concerned about relying on PKI for individual
certificates with no challenges, etc. E.164 numbers have geographic content,
and this opens us up to some additional issues (beyond e-mail addresses).
May need additional controls, may need to know who is verifying the numbers,
etc.
# SIP has made different tradeoffs, because of things like lack of huge
installed base, etc. - have you looked at SIP Identity? There's a gap here
that needs to be filled.
# Penn Pfautz: Interesting idea, could be investigate further for usage
even in carrier scenarios.

Enumservice FOAF
================

 Title        : IANA Registration for Enumservice foaf   [ 15 Min ]

    Author(s)    : K. Reichinger
    Filename    : draft-reichinger-enum-foaf-00.txt
    Pages        : 9
    Date        : 2006-2-15

This memo registers the Enumservice "foaf" using the URI schemes
"http" and "https" according to the IANA Enumservice registration
process defined in RFC3671.  The Enumservice "foaf" is to be used to
refer from an ENUM domain name to the location of a FOAF RDF file
using the corresponding E.164 telephone number.

Clients may use data retrieved from a FOAF RDF file to provide caller
or callee with information available within the Friend-Of-A-Friend
(FOAF) Semantic Web application.  For example, the caller might be
presented with personal information on the callee (e.g. name, gender
and various online attributes) as well as information on the callee's
social context (e.g. relations to friends or colleagues).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-reichinger-enum-foaf-00.txt

slides: http://www3.ietf.org/proceedings/06mar/slides/enum-3.ppt

    *  FOAF is "Friend of a Friend"
    * Part of Semantic Web Project
    * Lots of terms defined already (in presentation)
    * Data is RDF-based and can be published anywhere on the web
    * Want to link FOAF data to phone number
    * Allows FOAF/ENUM spidering
    * Introduces ENUM to Semantic Web
    * Rohan - how do you find my FOAF data if I don't have a phone number
today? Could be published on website, could appear as FOAF data under a
related friend.
    * Richard Shockey - privacy issues seem astounding - how granular is
privacy? File-by-file, so all-or-nothing. This is vCard-equivalent privacy -
no, it's also other people's data in your profile, so it's more than vCard
privacy issues.
    * Is this voluntary, like blogging? Yes. What applications read this
information today? Don't think so, at the moment (but it's RDF-based).
    * Alex: Privacy question comes up for every service we talk about.
Jason/Bernie - please point out that securing the underlying data isn't part
of the ENUM service registration template, only the additional security
issues of linking it to ENUM.
    * Rohan - there is a vCard security considerations list now - that's
understood. What are we doing in ENUM if we make E.164 addresses more useful
than other identifiers? Make a service discovery service, instead?
    * E.164 numbers are simply keys, period.
    * Patrik is concerned that the E.164 number becomes the FOAF identifier
and should not be tied directly to the URI, which may move, etc. Lots of
people are looking in this area (IRIS, Rohan, etc.). ENUM gives you URIs,
not URNs.
    * What should we do with this document? The underlying protocols are
experimental, so this should be, too. Need to publish something, so people
know about the string - X-dash, for example?
    * Jon - don't actually know how to distinguish ENUM applications that
use the same protocols (http) - need to figure out how to do this.
    * Rohan - if you have someone's web page and can't find their FOAF
information, that's a Semantic Web issue that needs to be solved
independently. (web page address could come from ENUM, FOAF to be
discovered from there)
    * Rohan - need to come up with a generic way to do these registrations.
Don't need to do much here except avoid conflicts.
    * Richard Shockey - would like to see one more spin of this document
with updated registration template (draft previously discussed), but this is
very interesting.

IM Enumservice & Calendering Enumservice
========================================

Title		: A Telephone Number Mapping (ENUM) Service Registration for Instant
Messaging (IM) Services
											[ 15 M ]
	Author(s)	: R. Mahy
	Filename	: draft-mahy-enum-im-service-00.txt
	Pages		: 5
	Date		: 2006-2-22

This document registers a Telephone Number Mapping (ENUM) service for
Instant Messaging (IM).  Specifically, this document focuses on
provisioning im: URIs in ENUM.

Title		: A Telephone Number Mapping (ENUM) Service Registration for Internet
Calendaring Services    						 [ 15 M ]

	Author(s)	: R. Mahy
	Filename	: draft-mahy-enum-calendar-service-00.txt
	Pages		: 5
	Date		: 2006-2-23

This document registers a Telephone Number Mapping (ENUM) service for
Internet Calendaring Services.  Specifically, this document focuses
on provisioning mailto: (iMIP) and http: (CalDAV) URIs in ENUM.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-mahy-enum-calendar-service-00.txt

slides: http://www3.ietf.org/proceedings/06mar/slides/enum-5.ppt

IM:
---

    *  Was surprized that IM enumservice didn't exist, but it didn't exist.
    * Like pres URI, can only return IM URIs, and have a 3861 mechanism to
discover correct/preferred protocol.
    * Comments?
    * Lawrence - this is fine. Not sure who will use this, because most IM
users won't have SRV records. But no problem with the draft.
    * Room hummed to make thsi a WG draft

Adopted as WG item.

Calendar:
---------

    *  Used to discover mailto and http(s) URIs for Internet calendaring
services
    * Actually several subservices (manipulate calendar, check busy/free),
including subservices that you can support in iCal, but not with IMAP.
    * Could this be merged with vCard transport? CALDEV doesn't really have
a working group home (Calify has the right people) - but this isn't a
generic vCard service.
    * Is this just traditional calendar events? There are a lot of possible
calendars, which may be overlapping. Would this be better for the IETF
Agenda? Rohan prefers to point to services with well-defined services.
    * Are we rolling too much stuff into ENUM?
    * Is this a WG item? Some number of hums in favor, fewer opposed.

Adopted as WG item.

Infrastructure Requirements
===========================

Title		: Infrastrucure ENUM Requirements
	Author(s)	: S. Lind, P. Pfautz                       [ 20 M ]
	Filename	: draft-ietf-enum-infrastructure-enum-reqs-00.txt
	Pages		: 7
	Date		: 2006-3-6

This document provides requirements for "infrastructure" or "carrier"
ENUM, defined as the use of RFC 3761 technology to facilitate
interconnection of networks for E.164 number addressed services, in
particular but not restricted to VoIP.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-enum-infrastructure-enum-reqs-00.txt

slides: http://www3.ietf.org/proceedings/06mar/slides/enum-1.ppt

    *  Lawrence - UK experience is that your "SHALL" should be "SHALL NOT" -
anything that is public must not be able to identify the serving CSP... -
this is the difference between "must have the capability" and "must turn the
capability on". Have used cut-outs in the US for information like
carrier-of-record.
    * If we're allowed to return anything, it would be carrier of record.
    * Richard Shockey - if you're going to do something like this, you have
to have a WHOIS.
    * Next steps with this document? WGLC? Consensus to go for it.

Combined User and Carrier ENUM
==============================

"Combined User and Carrier ENUM in the e164.arpa tree" -
draft-haberler-carrier-enum-02.txt .
								[20 M]
Abstract:

ENUM as defined now in RFC3761 is not well suited for the purpose of
interconnection by carriers, as can be seen by the use of various
private tree arrangements based on ENUM mechanisms. A combined
end-user and carrier ENUM tree solution would leverage the ENUM
infrastructure in e164.arpa, increase resolution rates, and decrease
the cost per registered telephone number. This document describes a
minimally invasive scheme to provide both end-user and carrier data in ENUM.

until it comes out of the queue, the I-D is available at:

http://www.ietf.org/internet-drafts/draft-haberler-carrier-enum-02.txt

slides: http://www3.ietf.org/proceedings/06mar/slides/enum-0.ppt

# Consensus is to have one tree. In .arpa? IETF, IAB, RIPE, ITU-T
involvement all needed, and existing policies/procedures can be reused. No
time to come up with a new governing body and get agreement.
# Above the country code, or below the country code? (or both places in
parallel? - but would meet the requirements no matter where it is).
# Above country code is most straight-forward solution (everything works),
but has some constraints on timing for ITU-T concurrence.
# Below country code is a national matter and can be implemented now.
# Uses Branch Location Records (BLR).
# Proposed to pursue both options in parallel, to allow trials using below
country code.
# Need RFC 3761bis to accomplish this.
# Is BLR at the country level? No, location is a national matter ("below the
zone cut").
# Lawrence - don't like TXT records. new RR is strongly recommended. Use TXT
records for trials?
# Richard Shockey - have never liked BLR (and never will). IAB isn't the
decision-maker, it's IESG.
# Patrik - ITU-T will be involved even if it's below the country code.
# Lars - problem with TXT records. Can't stop you from using them for
trials, but please make sure there are no collisions.
# Richard Shockey - ITU-T will be involved, get used to it.
# Patrik - in all the choices, so ITU-T involvement isn't a reason to pick
one choice.
# Richard Shockey - we need to expect 3GPP interest in carrier ENUM, too.
# There are only about 300 records - why update millions of clients to
recognize them?
# May ITU-T meeting - need to do something about this very soon.
# Patrik - do we disagree about above/below because we are missing
requirements from the requirement documents? Should we have had more
requirements?
# Jon - remember that the IESG doesn't make decisions in a vacuum - IAB is
part of the community that will be involved in any community decision.
# Need to describe what's in DNS (label the boxes or your filing system will
break down). Can't assume that all TXT records will "really" be BLRs.
# There is a Draft Standard on handling unknown RR types (one of our few).
# We all prefer option one, but what do we do in the interim? Alternative is
that carriers will pick something, hopefully in the public parts of DNS, and
then we'll TRY to tie things together.
# Should this draft be a working group item? Richard Shockey doesn't think
so - are we talking about having a separate domain for infrastructure ENUM?
That's a separate document. Does not see BLR moving forward (unusual use of
DNS).
# Lawrence - don't like this, I'm worried about this, but the way ENUM is
set up in the world, a global standard isn't going to happen quickly without
something like this.
# Richard Shockey - are BLRs a viable option? We took a hum, and lots of
people said "yes".
# Patrik - Some individuals violently disagree - can they go off to the bar
and report back to the working group? On the Mailing list, this week.

The outcome of bar discussions was later posted as the "Dallas Treaty":
http://www1.ietf.org/mail-archive/web/enum/current/msg04848.html

AOB
===

Koch: worried about potential size of DNS responses, number of ENUM services
rising could lead to lots of TCP queries...

meeting concluded.

_______________________________________________
enum mailing list
enum@ietf.org
https://www1.ietf.org/mailman/listinfo/enum