Subject: [Enum] ENUM WG Minutes IETF 60 San Diego

From: Richard Shockey <[email-masked]>
Date: Fri, 03 Sep 2004 14:54:24 -0400

Telephone Number Mapping WG (enum)
IETF 60 San Diego
Wed August 2, 2004
1300-1500 Afternoon Sessions
Chair(s):
Patrik Faltstrom <paf at cisco.com>
Richard Shockey <rich.shockey at neustar.biz>
Transport Area Advisor:
Allison Mankin  <mankin at psg.com>
===============================
SCRIBE: Chris Celeberti  - Patrik Faltstrom - Jabber
AGENDA BASHING (5 min)  ( appointment of scribe etc)
130-1300 Break
1300-1500 Afternoon Sessions I
 I
TSV  enum       Telephone and Number Mapping WG
AGENDA BASHING (5 min)
No objections to the Agenda being reordered from that posted.
# 1 Disposition of    [ 10 Min]
Title           : E.164 Number Mapping for the Extensible Provisioning Protocol
        Author(s)       : S. Hollenbeck
        Filename        : draft-ietf-enum-epp-e164-04.txt
        Pages           : 17
        Date            : 2004-6-8
This document describes an Extensible Provisioning Protocol (EPP)
   extension mapping for the provisioning and management of E.164
   numbers representing domain names stored in a shared central
   repository. Specified in XML, this mapping extends the EPP domain
   name mapping to provide additional features required for the
   provisioning of E.164 numbers.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-enum-epp-e164-04.txt
Scott H: The central question is what will the WG do with the document 
since it has been lying around for some time.

Chair. How many people have read the document ( 5-10)
Chair: Does anyone have issues with document ?( 0 )
Chair : Scott what do you think ..Experimental or Proposed?
Scott H. Experimental is generally for documents that have dragons we know 
of else it can be proposed standard. Other EPP extensions have been 
proposed if this needs to be revised in the future.

Chair: So proposed path is to update the document once to reflect current 
drafts etc and then go to last call. Objections ?  None stated.

Stastny: Allison what is the current state of the service registrations?
Allison: There have been some well known problems with ID tracker where the 
documents got lost in cyberspace so those should proceed asap.

2:  Review of the ENUM Operations Document [ 10 Min]
Title           : ENUM Implementation Issues and Experiences
        Author(s)       : L. Conroy, K. Fujiwara
        Filename        : draft-ietf-enum-experiences-00.txt
        Pages           : 0
        Date            : 2004-7-12
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-00.txt
Fujiwara:  Co author of document could not come. General presentation of 
the document. Issues separated into server side and client side issues. 
Discussion of issues involving Non-Terminal NAPTR records. Question as to 
whether there is any need for discussion of non-terminal NAPTR records.

Chair: Is anyone contemplating using non terminal NAPTR records? (no answer)
Conclusion - draft enum experiences is close to being finished and ready 
for submission for last call etc. Further discussion on the list.

#3 ENUM VOID [ 10 Min]
Title           : IANA Registration for enumservice void
        Author(s)       : R. Stastny, L. Conroy
        Filename        : draft-stastny-enum-void-00.txt
        Pages           : 7
        Date            : 2004-7-13
This document registers the 'ENUMservice' 'void' using the URI
   scheme 'mailto:' as per the IANA registration process defined in the
   ENUM specification RFC3761 [2]. This 'ENUMservice' SHALL be used to
   indicate that the E.164 number or E.164 number range connected to
   the domain used in DNS as described in [2] is not assigned to an
   end-user in case of an E.164 number or to a communication service
   provider in case of an E.164 number range.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-stastny-enum-void-00.txt
Stastny:  Overall issue is that for ENUM end user is controlling what is 
registered in the zone ..If no registration is made an NXDOMAIN results 
from a query in DNS. The result of this is a default condition of passing 
to the PSTN. Some NRA's now assigning specific E.164 number ranges for ENUM 
use such as +43780 in Austria. Calls using this range can only be addressed 
using ENUM. User agents don know the special call is for VoIP.

It would be better if the origination caller gets a response from the DNS 
indicating the number is in a "unassigned" state.

ENUM service called "VOID" should say the number is unused and not assigned 
to and end user then can then be used by NRA's and carriers for blocks for 
which they have been allocated but not assigned.

ENUM service is  'void' subtype mail to URI scheme mailto:
Shockey: What happens if a user doesnt want any email address published at all?