[Enum] Preliminary minutes ENUM WG IETF 61

Many thanks to Spencer Dawkins for his excellent notes.
Telephone Number Mapping WG (enum)
Monday, November 9 at 1930-2200
===============================
CHAIRS: Patrik Faltstrom <paf at cisco.com>
Richard Shockey <rich.shockey at neustar.biz>
Mailing Lists:
General Discussion:enum at ietf.org
To Subscribe: enum-request at ietf.org
In Body: subscribe
Archive: ftp://ftp.ietf.org/ietf-mail-archive/enum/
AGENDA:
AGENDA BASHING (5 min)
Short Presentation on current status of ENUM in CC 1: Special Guest - Karen
Mulberry MCI
        <>Karen is senior project manager for Numbering at MCI. She
presented a Country Code 1 press release for a not-for-profit LLC (MCI,
Sprint, Verizon are members now). $25K/year membership this year, all
members equal, no limit on membership from interested parties, except cannot
also be a vendor to the LLC. Most of the budget is liability insurance for
the membership.
</>
1.      Problem is that 19 countries share "country code 1". This is the rat
in the snake of ENUM deployment. All countries have to support delegation in
order to make it happen.
2.      Will write an RFC, will select one or more Tier One operators  to
operate a +1 ENUM registry.
3.      Vision is that RFC goes to Tier Ones in June 2005, awarded/signed by
October 2005, registry operational by January 2006.
4.      http://www.enumllc.com is under construction now.
5.      Are discussing a trial as soon as possible (before award, but after
delegation).
6.      Group is not chartered by anyone - US government has encouraged
formation of this LLC, but can't be sure there are no alternatives in the
woodpile.
7.      IAB/ITU agreement is that ENUM delegation matches normal delegation
perfectly. US and Canada can request the delegation, but no opposition is
allowed (opposition will roadblock the delegation).
8.      There is only one Tier One "A" vendors, but under that, there could
be many Tier Two vendors.
1. [ 10 min] Shockey-Stastny The ENUM dip indicator. It is a draft that
discusses the use of a ENUM dip indicator in the TEL URL that indicates that
a ENUM query has been done. This is going to be discussed at IPTEL but we
want to make everyone aware of it.
New parameter for the "tel" URI to support ENUM, defined in
http://www.ietf.org/internet-drafts/draft-stastny-iptel-tel-enumdi-00.txt.
*       Support handling ENUM queries in SIP proxies, H.323 gatekeepers,
other VoIP network elements.
*       Idea is that ENUM operations may result in repeated queries - want
to give subsequent ENUM entities a list of queries that have already been
performed, so they won't be repeated. This improves performance and reduces
load on VoIP network elements.
*       Enumdi parameter isn't mandatory, so a VoIP network element that
doesn't understand it will ignore it and still do the lookup.
*       Patrik - this needs to be a SHOULD NOT, not a MUST NOT.
*       Working group hum agrees...
NEW ITEMS : We need to discuss whether the timing is correct to take on this
as a WG item.
2. [20 M ] Title : An ENUM Registry Type for the Internet Registry
Information Service
Author(s) : A. Newton
Filename : draft-newton-iris-ereg-02.txt
Pages : 45
Date : 2004-9-28
This document describes an IRIS (draft-ietf-crisp-iris-core-02.txt) registry
schema for ENUM administrative information. A URL for this Internet-Draft
is: http://www.ietf.org/internet-drafts/draft-newton-iris-ereg-02.txt
*       IRIS uses multiple layers, XML, NAPTR records.
*       Want to provide ENUM Registry (EREG) . Similar to DREG registry,
with its own identifier namespace.
*       Implementation available at irisverisignlabs.com.
*       Supports both UDP and TCP (using BEEP).
*       Does not require universal adoption
Working group interest? Seems like enough interest to adopt, no opposition
but a lot of "don't cares", too.
Chairs Conclusion : Adopt as a WG item
NEW ITEMS : These drafts relate to issues involving Validation of the Number
Holder as part of the Provisioning process.
3. [20 M ] Title : ENUM Validation Information Mapping for the Extensible
Provisioning Protocol
Author(s) : B. Hoeneisen
Filename : draft-hoeneisen-enum-validation-epp-00.txt
Pages : 17
Date : 2004-9-30
This document describes an EPP extension for mapping information about the
validation process the ENUM Registrar has applied for the E.164 number (or
number range), which the ENUM domain name is based on. Specified in XML,
this mapping extends the EPP domain name mapping to provide an additional
feature required for the provisioning of E.164 numbers.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-hoeneisen-enum-validation-epp-00.t
xt
*       The goal here is to know a lot more about who registered an E.164
domain than we know about who registered a plain, vanilla DNS domain.
*       Austria, Switzerland, - who doesn't need something like this? We
vote Country Code 1, of course, but no conclusions here (except that we know
we have a problem). CC1 has external databases that you may not have in
Europe, so not sure if CC1 would use the same approach or not.
*       This has a lot of interactions with number portability (which is
done differently in CC1 and in Europe - they call-forward instead of doing a
database lookup.
*       If your country code considers ENUM deployment, all these issues pop
up instantly.
4. [ 20 M ] ENUM Validation Architecture and Token Format Definition -
Alexander Mayrhofer
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-mayrhofer-enum-validation-00.txt
*       What's the incentive for legacy carriers to contribute to validation
for ENUM? We think it's close to zero. Most others (users, porting
process/NPAC, etc.) are more likely to participate.
*       We need to accommodate consumer choice, not set up the next
monopoly.
*       Centralized validation agents? Multiple validation agents? Number
range holder = registrar? No single solution works best, so define
Validation Entity as a role, not as an agency.
*       Question - where is the end user in all this? This validation flows
one way (registrars validated registrants, not the other way around). What
about the danger of slamming as we had in US long distance competition?
*       Question - we are getting from the problem statement to the solution
- what are the requirements? Should a validation token be traceable to a
verifier?
*       Question - are validation tokens signed, or encrypted and signed?
Sweden has a distinction between validation entities and registration
entities, and they don't share data, especially about customers.
*       Question - can the ENUM WG clear up the trust model here?
*       Question - what about cancelling tokens? New tokens override old
ones, but there's an explicit cancel as well.
What's still needed here? Definition of terms.
Will this be one document or two (a framework and a specific
implementation)? Will work on one document (framework, roles, requirements,
definitions) during next IETF cycle (confirm this on the mailing list).

ONGOING WORK:
Title : IANA Registration for Enumservice VOID
Author(s) : R. Stastny, L. Conroy
Filename : draft-ietf-enum-void-00.txt
Pages : 0
Date : 2004-10-12
This document registers the Enumservice 'void' using the URI schemes
'mailto:' and 'http:' as per the IANA registration process defined in the
ENUM specification, RFC3761. This Enumservice may be used to indicate that
the E.164 number (or E.164 number range) tied to the domain in which the
enclosing NAPTR is published is not assigned for communications service.
When such an indication is provided, an ENUM client can detect calls that
will fail "early".
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-enum-void-00.txt
***
Older business:
Title : ENUM Implementation Issues and Experiences
Author(s) : L. Conroy, K. Fujiwara
Filename : draft-ietf-enum-experiences-01.txt
Pages : 26
Date : 2004-10-25
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 informational only, 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-01.txt
*       Want to get implementers' experience in next 30 days for WGLC by
yearend.
Title : IANA Registration for ENUMservices email, fax, mms, ems
and sms
Author(s) : R. Brandner, et al.
Filename : draft-ietf-enum-msg-03.txt
Pages : 20
Date : 2004-10-21
This document registers the 'ENUMservices' "email", "fax", "sms", "ems" and
"mms" using the URI schemes 'tel:' and 'mailto:' 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-msg-03.txt

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Richard Shockey, Senior Manager, Strategic Technology Initiatives
NeuStar Inc.
46000 Center Oak Plaza  -   Sterling, VA  20166
sip:rshockey(at)iptel.org   sip:57141 at fwd.pulver.com
ENUM +87810-13313-31331
PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683,  Fax: +1 815.333.1237
<mailto:richard(at)shockey.us> or <mailto:richard.shockey(at)neustar.biz>
<http://www.neustar.biz> ; <http://www.enum.org>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
_______________________________________________
enum mailing list
enum at ietf.org
https://www1.ietf.org/mailman/listinfo/enum