[Enum] ENUM WG Minutes IETF 60 San Diego

[Richard Shockey <[e-mail]>]

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?
From [e-mail] Tue, 07 Sep 2004 13:22:50 -0400
From: The IESG <[e-mail]>
Date: Tue, 07 Sep 2004 13:22:50 -0400
To: IETF-Announce <ietf-announce at ietf.org>
Subject: [Enum] Protocol Action: 'IANA Registration for ENUMservices web and ft' to Proposed Standard
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain
Status: R

The IESG has approved the following document:

- 'IANA Registration for ENUMservices web and ft '
   <draft-ietf-enum-webft-01.txt> as a Proposed Standard

This document is the product of the Telephone Number Mapping Working Group. 

The IESG contact persons are Allison Mankin and Jon Peterson.

Technical Summary
 
   This document registers the Enumservices 'web' and 'ft' using
   the URI schemes 'http:', 'https:' and 'ftp:' following the IANA
   registration process defined in the ENUM specification RFC 3761.
 
Working Group Summary
 
 The working group supported this Enumservice.
 
Protocol Quality
 
 Registrations using these services have been deployed.  Allison Mankin 
 reviewed this document for the IESG.

RFC Editor Notes

1.
Abstract
OLD:
    This document registers the 'ENUMservices' [3] 'web' and 'ft' using
   the URI schemes 'http:', 'https:' and 'ftp:' as per the IANA
   registration process defined in the ENUM specification RFC3761 [3].

NEW:
   This document registers the Enumservices 'web' and 'ft' using
   the URI schemes 'http:', 'https:' and 'ftp:' as per the IANA
   registration process defined in the ENUM specification RFC 3761.
3833
------
2.
In Section 6.2, add to reference [15], an Informative reference [16] to RFC 
3833.
------
3.
Section 4
OLD:
This ENUMservice indicates that the resource identified by the
associated URI scheme is a file service from which a file or file
listing can be retrieved.

NEW:

This Enumservice indicates that the resource identified by the
associated URI scheme is a service usable in the manner specified
for ftp: in RFC 1738, for instance, file retrieval.

[Add a normative reference to RFC 1738].

-------
4.
Replace ENUMservice(s) and "ENUMservice(s)" with Enumservice in the
 title and throughout.  This follows the usage of RFC 3761, which
defines the term.


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