Subject: [Enum] Final Agenda items for IETF 63 Paris

From: Richard Shockey <[email-masked]>
Date: Thu, 14 Jul 2005 13:39:01 -0400

It looks like Friday AM.
IETF 63  Telephone Number Mapping (ENUM) WG Agenda
Chair(s):
Patrik Faltstrom <paf at cisco.com>
Richard Shockey <rich.shockey at neustar.biz>
Transport Area Advisor:
Allison Mankin  <mankin at psg.com>
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 BASHING (5 min)
1. Review of the existing drafts - Ready to go top Last call  ( 5-10 M ? )
Title           : ENUM Implementation Issues and Experiences
        Author(s)       : L. Conroy, K. Fujiwara
        Filename        : draft-ietf-enum-experiences-02.txt
        Pages           : 29
        Date            : 2005-7-1
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-02.txt
2. Final disposition of  IRIS EREG, hopefully to last call. ( 5 Min? )
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-newton-iris-ereg-00.txt
3. New/old  work on enumservice registrations  ( 20 M )
3.1
        Title           : IANA Registration for Enumservice Voice
        Author(s)       : R. Brandner, et al.
        Filename        : draft-brandner-enum-voice-00.txt
        Pages           : 12
        Date            : 2005-7-7
   This document registers the ENUMservice ^voice^ (which has a defined
   sub-type ^tel^), as per the IANA registration process defined in the
   ENUM specification RFC3761.  This service indicates that the contact
   held in the generated URI can be used to initiate an interactive
   voice (audio) call.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-brandner-enum-voice-00.txt
3.2
        Title           : IANA Registration for an Enumservice
                          Containing Number Portability and PSTN
                          Signaling Information
        Author(s)       : J. Livingood, R. Shockey
        Filename        : draft-livingood-shockey-enum-npd-00.txt
        Pages           : 8
        Date            : 2005-7-8
   This document registers the Enumservice "npd" and subtype "tel" using
   the URI scheme 'tel:' as per the IANA registration process defined in
   the ENUM specification, RFC 3761.  This data is used to facilitate
   the routing of telephone calls in those countries where Number
   Portability exists.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-livingood-shockey-enum-npd-00.txt
3.3
        Title           : IANA Registration for ENUMservice Mobile Webpage
        Author(s)       : J. Ra, et al.
        Filename        : draft-ra-shin-enum-mobileweb-00.txt
        Pages           :
        Date            : 2005-7-7
   This document registers the ENUMservice ^mobweb^ using the URI
   schemes 'http:' and 'https:' 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-ra-shin-enum-mobileweb-00.txt

4. ENUM Validation Issues. 3 Drafts 15 -20
 4.1 ENUM Validation Architecture      draft-mayrhofer-enum-validation-arch-00
        Title           : ENUM Validation Architecture
        Author(s)       : A. Mayrhofer, B. Hoeneisen
        Filename        : draft-mayrhofer-enum-validation-arch-00.txt
        Pages           : 16
        Date            : 2005-7-11
   An ENUM domain name is tightly coupled with the underlying E.164
   number.  The process of verifying whether or not the Registrant of an
   ENUM domain name is identical to the Assignee of the corresponding
   E.164 number is commonly called ^validation^.  This document
   describes validation requirements and a high level architecture for
   an ENUM validation infrastructure.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-mayrhofer-enum-validation-arch-00.txt
4.2  "ENUM Validation Token Format Definition" - 
draft-lendl-enum-validation-token-00.txt

        Title           : ENUM Validation Token Format Definition
        Author(s)       : O. Lendl
        Filename        : draft-lendl-enum-validation-token-00.txt
        Pages           : 16
        Date            : 2005-7-11
   An ENUM domain name is tightly coupled with the underlying E.164
   number.  The process of verifying whether the Registrant of an ENUM
   domain name is identical to the Assignee of the corresponding E.164
   number is commonly called ^validation^.  This document describes an
   signed XML data format -- the Validation Token -- with which
   Validation Entities can convey successful completion of a validation
   procedure in a secure fashion.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-lendl-enum-validation-token-00.txt
4.3  Bernie Hoeneisen
  http://ietf.hoeneisen.ch/draft-ietf-enum-validation-epp-00.txt
  http://ietf.hoeneisen.ch/draft-ietf-enum-validation-epp-00.html
#################
5. PART 2  1/2 hours. 3 Items
The first order of business is to attempt to create some very basic common 
ground on what is the problem Carrier/Infrastructure/Private ENUM is trying 
to solve based on what we generally understand are the orthogonal interests 
of A. the E.164 number holder vs B. the carrier of record for that number. 
In addition try to place this problem statement in the over all context of 
converged carrier networks and the desire for interconnection and peering.

We are NOT going to solve the Carrier ENUM definition and problem statement 
in Paris but there needs to be some baseline before we can generally review 
the drafts at hand.

Steve Lind has attempted to capture some of the ongoing discussion. This 
was not ready before the ID cut off but anyone coming to Paris is 
encouraged to read and comment on this ID on the list.

http://www.sdlind.com/draft-lind-infrastructure-enum-reqs-00.txt
#################
Discussion of Pfautz etal drafts on Carrier ENUM - Requirements ?
 Title           : IANA Carrier/User enumservice Registration
        Author(s)       : P. Pfautz, et al.
        Filename        : draft-pfautz-lind-enum-carrier-user-00.txt
        Pages           : 10
        Date            : 2005-6-6
This document registers, pursuant to the guidelines in RFC 3761,
   tElephone NUmber Mapping (ENUM) services to allow a single registry
   to support end user and carrier services with independent name
   servers holding the terminal NAPTR (Naming Authority Pointer) records
   identifying the communication services for each.  The to-be-
   registered enumservices make use of non-terminal NAPTR records and
   DDDS (Dynamic Delegation Discovery System) replacement to achieve
   this end.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-pfautz-lind-enum-carrier-user-00.txt
"Combined User and Carrier ENUM in the e164.arpa tree"
        Title           : Combined User and Carrier ENUM in the e164.arpa tree
        Author(s)       : M. Haberler, R. Stastny
        Filename        : draft-haberler-carrier-enum-00.txt
        Pages           : 10
        Date            : 2005-7-11
   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.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-haberler-carrier-enum-00.txt

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.

        Title           : Non-Terminal NAPTR Processing: A Modest Proposal
        Author(s)       : L. Conroy
        Filename        : draft-conroy-enum-modestproposal-00.txt
        Pages           : 12
        Date            : 2005-7-6
   Recent Discussions within the IETF and in other fora have highlighted
   differences in interpretation of the set of standards associated with
   ENUM and DDDS, on which it relies.  Specifically, the operation and
   semantics surrounding support for non-terminal NAPTRs has led to some
   confusion.  This document is an attempt to add clarification to non-
   terminal NAPTR processing.  In this, it clarifies RFC3403.  A
   subsequent document will build on this one to extend RFC3761 further,
   permitting registration of non-terminal Enumservices.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-conroy-enum-modestproposal-00.txt

6.  Discussion of ENUM WG recharter ?

Richard Shockey, Director - Member of Technical Staff
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

---

From: lconroy <[email-masked]>
Date: Sat, 23 Jul 2005 08:10:22 -0400

Hi Folks,
  In case no-one noticed, the mobileweb draft has been updated
to "draft-ra-shin-enum-mobileweb-01.txt".
This draft is covered in section 3.3 of the Agenda.
I would suggest that folk look at the new version BEFORE the ENUM  
meeting
- the changes are editorial rather than technical, but given how some
people seem to have interpreted the -00 version so far, perhaps this one
will clarify things and avoid unnecessary flights of fancy.

I would also advise folk to look at the "modest proposal" draft, but  
as it
seems vanishingly unlikely that there will be time to cover that in  
the meeting,
questions/comments to the list would be appreciated.

all the best,
  Lawrence
On 14 Jul 2005, at 18:38, Richard Shockey wrote:
It looks like Friday AM.
Or, from the content to be covered, all day Friday (and most of the  
night)
IETF 63  Telephone Number Mapping (ENUM) WG Agenda
0. AGENDA BASHING (5 min)
1. Review of the existing drafts - Ready to go top Last call   
( 5-10 M ? )
Title           : ENUM Implementation Issues and Experiences

2. Final disposition of  IRIS EREG, hopefully to last call. ( 5 Min? )
3. New/old  work on enumservice registrations  ( 20 M )
3.1        Title           : IANA Registration for Enumservice Voice
3.2        Title           : IANA Registration for an Enumservice
                             Containing Number Portability and PSTN
                             Signaling Information
3.3       Title           : IANA Registration for ENUMservice  
Mobile Webpage

4. ENUM Validation Issues. 3 Drafts 15-20
4.1 ENUM Validation Architecture      draft-mayrhofer-enum- 
validation-arch-00
4.2  "ENUM Validation Token Format Definition" - draft-lendl-enum- 
validation-token-00.txt
4.3  EPP Validation Extension
      <http://ietf.hoeneisen.ch/draft-ietf-enum-validation-epp-00.txt>

#################
30 minutes - Ha Ha Ha!

http://www.sdlind.com/draft-lind-infrastructure-enum-reqs-00.txt
http://www.ietf.org/internet-drafts/draft-pfautz-lind-enum- 
carrier-user-00.txt
http://www.ietf.org/internet-drafts/draft-haberler-carrier- 
enum-00.txt
...and finally, my modest proposal to clarify RFC3403
http://www.ietf.org/internet-drafts/draft-conroy-enum- 
modestproposal-00.txt

6.  Discussion of ENUM WG recharter ?
One assumes that this is for Friday night between 23:00 and 00:00.
_______________________________________________
enum mailing list
enum at ietf.org
https://www1.ietf.org/mailman/listinfo/enum

---

From: Ray Anderson <[email-masked]>
Date: Mon, 25 Jul 2005 08:26:08 -0400

Here are my top level comments:
The idea here seems to be to provide "clues" about the services available 
at an ENUM addressible site
so that a device or user that could make use of those clues could provide a 
better service to the end user.

The aims are good, but acfetr careful consideration I believe that this 
proposal is wrong in its approach,
and also wrong as an ENUMservice.  I recommend the authors get involved in 
the Mobile Web Initiative.
http://www.w3.org/2005/MWI/

(1) Wrong Approach
The W3C is currently engaged on a Mobile Web Initiative which is working 
hard to ensure that web sites
can give an improved experience to mobile users.  Currently most web sites 
are optimized to big screen users
with a "PC environment (keyboard, distraction level etc.).   There are many 
parts to this, not least of which
is that the web site can use information presented by the end user device 
(HTTP_ACCEPT among others)
to determine how best to deliver a good experience to users. In addition, 
the site can redirect to alternative
services that might help, if teh device has certain characteristics.

Therefore, the idea of tagging a site with different URL's that are 
selected between by the client device or
the user should not be necessary, and in fact is more limited because the 
hosting site should be able to
evolve and adapt its capabilities much faster than the client device.

There are many reasons why one URL for content promotion / bookmarking / 
passing on is a good
thing.  Thats probably why the .MOBI TLD met with so much derision, and was 
rejected by W3C, 3GPP,
and content providers.

(2) Wrong as an ENUM service
If the ENUM service approach (not withstanding the above)  was to be 
useful, then surely it should be available
across all domains, not just those in e164.arpa, for example in 
www.neustar.biz so that devices accessing
those domains can also provide more appropriate URL's depending on the 
support for WAP, ME, iMode, xHTML,
VoiceXML, Flash, etc.  In that case, the extra "clues" should become a 
general DNS facility, otherwise only
sites accessed by enum URL's could provide the ease of use.

In that case I assume there is some other working group that should look at 
the proposal.

At 13:09 23/07/2005, lconroy wrote:
Hi Folks,
  In case no-one noticed, the mobileweb draft has been updated
to "draft-ra-shin-enum-mobileweb-01.txt".
This draft is covered in section 3.3 of the Agenda.
I would suggest that folk look at the new version BEFORE the ENUM
meeting - the changes are editorial rather than technical, but given how some
people seem to have interpreted the -00 version so far, perhaps this one
will clarify things and avoid unnecessary flights of fancy.
I would also advise folk to look at the "modest proposal" draft, but
as it seems vanishingly unlikely that there will be time to cover that in
the meeting, questions/comments to the list would be appreciated.
all the best,
  Lawrence