RE: 63rd IETF Agenda - DRAFT

[Eric Burger <[e-mail]>]

Wednesday afternoon would also conflict with LEMONADE.

Not to start a fire, but given that it is a BOF and it probably does need a
lot of time, how about Friday?

Let's face it, there are a lot of "personalities" and "emotions" on this
topic.  Holding it on Friday will self-limit participation to those that
REALLY need to be involved.  They will MAKE the effort to be there.  I don't
buy the "Friday is inconvenient" argument on this one...

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] 
> Sent: Thursday, July 14, 2005 2:55 PM
> To: Tom Taylor; Richard Shockey
> Cc: [e-mail]; IETF Secretariat; Working Group 
> Chairs; [e-mail]
> Subject: Re: 63rd IETF Agenda - DRAFT
> 
> At 02:41 PM 7/14/2005, Tom Taylor wrote:
> 
> >Is that really true given that you identified a major 
> overlap between 
> >this and the ENUM potential agenda?
> 
> oh yes...you cant discuss voipeer without understanding what 
> is happening in the ENUM WG.
> 
> The first order problem is how do you discover a point of 
> interconnection..this debate is raging in the ENUM WG.
> 
> I just posted our WG agenda. It should be self evident what 
> the overlaps are. We are devoting a full 1 1/2 hour to the 
> concept of Infrastructure/Carrier ENUM.
> 
> 
> IETF 63  Telephone Number Mapping (ENUM) WG Agenda
> 
> Chair(s):
> Patrik Faltstrom <[e-mail]>
> Richard Shockey <[e-mail]>
> 
> Transport Area Advisor:
> Allison Mankin  <[e-mail]>
> 
> Mailing Lists:
> General Discussion:[e-mail]
> To Subscribe: [e-mail]
> 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-en
> um-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-mobile
> web-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-valid
> ation-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-validatio
> n-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-ca
> rrier-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-modestp
> roposal-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:[e-mail]
> ENUM [phone]
> PSTN Office +1 571.434.5651 PSTN Mobile: [phone],  
> Fax: [phone]
> <mailto:richard(at)shockey.us> or 
> <mailto:richard.shockey(at)neustar.biz>
> <http://www.neustar.biz> ; <http://www.enum.org>
> <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
> 
>