Re: [Enum] ENUM WG Meeting Minutes IETF 63 Paris - PRELIMINARY Version 2

[Richard Shockey <[e-mail]>]

Stastny Richard wrote:

>Sorry to be picky, but it is wrong again:
>  
>
OK no problem ...

> 
>It should read:
> 
>The Chair also asked for a non binding "straw poll" based on the three approaches on which is preferred "at this time".  
>
>
>
>3 Options 
>
>A.	Pfautz approach of use of non-terminal NAPTR's 
>B.	Haberler/Stastny approach with delegation at RIPE/ITU  aka [CC]. c.e164.arpa or
>	with delegation after RIPE/ITU c. [CC].e164.arpa 
>C.	Using a different (non-e164.arpa) domain
>
>Hum indicates strong preference for B with further discussion the WG necessary.
>
>-richard
>
>
>________________________________
>
>Von: [e-mail] im Auftrag von Richard Shockey
>Gesendet: Sa 20.08.2005 04:08
>An: [e-mail]
>Betreff: [Enum] ENUM WG Meeting Minutes IETF 63 Paris - PRELIMINARY Version 2
>
>
>IETF 63  Telephone Number Mapping (ENUM) WG Meeting Minutes 
>
>Comments from the list incorporated.
>
>
>Chair(s): 
>Patrik Faltstrom <[e-mail]> <mailto:[e-mail]>  
>Richard Shockey <[e-mail]> <mailto:[e-mail]>  
>
>Transport Area Advisor: 
>Allison Mankin  <[e-mail]> <mailto:[e-mail]>  
>
>
>
>
>Friday, August 6 2005  9:AM to 12:30 PM 
>
>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 
>
> 
>
>WG ACTION :  After some minor discussion agreement that the document should go through one more iteratina and then take directly to WGLC.
>
>
>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 
>
>
>
>WG ACTION : Put this document into WGLC after one more revision by author.
>
>
>
>DISCUSSION Some concerns whether this document is mature enough for even WG last call,  response is that the document will see another revision and pushing towards    last call is only meant to spur document forward.
>
>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 
>
>WG ACTION :  WG humm agrees to draft as ENUM WG work item. Given the straightforward nature of this draft it is probable that it can go to WGLC after one iteration.
>
>DISCUSSION: Document is a simplification of a larger ENUM service registration document on voice services. The document only specifies the concept of voice:tel.
>
>
>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 
>
> 
>
>WG ACTION :  WG humm agrees to draft as ENUM WG work item. 
>
> 
>
>DISCUSSION : 
>
> 
>
>Comments include: 
>    - Doc needs to clarify "which" ENUM this is Public, vs Private vs Carrier
>    - Global Spin Std. 
>    - Are there size problems? Referring to SS7 size of databases can the DNS actually handle this class of queries even if privately cached.
>    - TEL URI scope problem : examples should include both TEL and SIP URI examples
>    - For IMS, limited usefulness 
>    - RFC 3671 db?  1 or collection? (Latter) 
>
>    - Document should discuss sage of portability data as it relates national policy
>    - 
>
>
>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 
>
> 
>
>WG ACTION: Considerable disagreement on the nature and scope that this document ultimately has. WG decision NOT to make WG item at this time.
>
> 
>
>DISCUSSION: 
>Discussion dove into issue of DNS vs. Application layer indication of  protocol stack capabilities. 
>
>    - Meta question, what are the criteria for an ENUMSERVICE registration? There was a general discussion of what those possible criterion are.
>    - In the classic registration cases, want to know if there's common protocol before setting up a transport arrangement (connection) 
>    - HTTP negotiation accomplishes the same once connection is in place 
>    - This draft introduces "Complexity" in placing possible application negotiation in two places (DNS and HTTP) 
>    - RFC 3824, guidelines on SIP and ENUM as reference 
>
>   - Consensus in discussion that ENUMSERVICE registrations should NOT be used to negotiate capabilities that could be handled within the underlying protocol. Registrations are useful to discover hints as to the underlying service or protocol if no other method is available.
>
>
>
>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 
>
> 
>
>
>WG ACTION :  WG humm agrees to draft as ENUM WG work item. 
>
>
>
>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 
>
>WG ACTION :  WG humm agrees to draft as ENUM WG work item. 
>
>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 
>
>WG ACTION :  WG humm agrees to draft as ENUM WG work item. 
>
>DISCUSSION: Very little technical discussion of the above 3 documents.
>
>
>
>################# 
>
>5. PART 2  1/2 hours. 3 Items 
>
>WG AGENDA: Terms and Conditions of discussion.
>
>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. 
>  
>
>
>################# 
>
>5.1 Discussion of drafts on Carrier ENUM - Requirements ? 
>
>  Title           : Infrastructure ENUM Requirements 
>        Author(s)       : S. Lind 
>        Filename        : draft-lind-infrastructure-enum-reqs-00.txt 
>        Pages           : 8 
>        Date            : 2005-7-15 
>
> There has been much discussion in various industries about the  concept of infrastructure (or carrier) ENUM. Some of this discussion   has been has been reflected within the ENUM WG mailing list and some within other organizations, including ETSI, the US ENUM Forum and the  Country Code 1 ENUM LLC. While there has been consensus within some pockets of individual efforts, there has been little consensus    industry-wide on even what infrastructure ENUM is, why it seems to be  important, or what the requirements for implementing it are. 
>
> At the request of the WG co-chairs, this document attempts to gather   together the bits and pieces from those discussions (i.e., I stole   the words shamelessly from the various sources) and, with an absolute minimum of editing, present them in some sort of cohesive manner that   will enable enlightened discussion and hopefully achieve consensus.   Some items listed below may be duplicative and suggest alternative    wordings for similar and other contradictory issues. As such, this  list is very raw and should not be viewed as complete, cohesive or  correct. 
>
>A URL for this Internet-Draft is: 
>http://www.ietf.org/internet-drafts/draft-lind-infrastructure-enum-reqs-00.txt
>
>  
>
>WG ACTION:  This document is now a WG item and is a requirement for any other protocol drafts concerning carrier/infrastructure ENUM. Steve Lind thanked for putting such a document together on such short notice.
>
>Penn Pfautz agrees to collaborate with Steve Lind on future drafts.
>
>
>
>5.2  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 
>
>
>5.3       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 
>
>
>
>
>DISCUSSION: Pfautz and Haberler Carrier ENUM drafts were discussed together.
>
>
>  As opposed to end user, opt-in ENUM, this is registration of information in DNS for carriers. Service provider of record as opposed to the number holder is considered the effective registrant.  Three approaches were mentioned but only two seem "obvious". 
>
>   Non-terminal NAPTR records 
>
> Records are placed in e164.arpa domain, at the tel number. One record for end user other for carrier.  Differentiation is inside NAPTR record with the use of the NAPTR substititution field to indicate different re-write rules to generate the next lookup. 
>
>   Separated branches of the DNS tree 
>
> A. For e164.arpa, there would be a [CC]. c.e164.arpa shadowing the main tree where [CC ] is the relevant Country code or
>
>B. For e164.arpa, there would be a c. [CC].e164.arpa shadowing the main tree where [CC ] is the relevant Country code. Difference being authority delegated pre or post RIPE/ITU.
>
> End users ( number holders) remain in <telnumber>.e164.arpa. carriers in <telnumber>.c.e164.arpa. 
>
>   Requirements/Desired results 
>   1) Minimize number of lookups 
>   2) Retain flexibility 
>   3) Consistency from CC to CC for predictability 
>
>   Discussion 
>
>   -  Data in DNS does not guarantee reachability ("deny's" allowed) 
>
>   -  DNS MUST answer.
>   - Uniformity in "c" label, name and where, is important 
>   - Non-terminal NAPTRs are untried 
>   - Questions on whether DNS wildcards are pertinent to the issue 
>   - Three questions - what's better for 1) DNS, 2) Application, and 3) "life" 
>   - Should not preclude private carrier-carrier traffic control 
>
>WG ACTION : Chair asks for a show of hands whether the WG should accept the general concept of Carrier ENUM as a WG item. There was a large show of hands that Carrier ENUM is of interest as a work topic no dissentions.
>
>
>
>Further Discussion on Next Steps
>
>   - Needs requirements and especially use cases to indicate what it is about 
>
>WG ACTION: Requirements document added as WG item. 
>   - RFC 3761 should remain untouched 
>   - Scope needs definition (stop at re-write rules?) 
>   - Use cases, use cases, use cases 
>   - Terminology and definitions needed 
>
> The Chair also asked for a non binding "straw poll" based on the three approaches on which is preferred "at this time".  
>
>
>
>3 Options 
>
>A.	Pfautz approach of use of non-terminal NAPTR's 
>B.	Haberler/Stastny approach with delegation at RIPE/ITU  aka [CC]. c.e164.arpa 
>C.	Haberler/Stastny approach with delegation after RIPE/ITU c. [CC].e164.arpa 
>
>Hum indicates strong preference for B/C with further discussion the WG necessary.
>
>
>Further Discussion:
>
>Division of labor with VOIPEER BoF effort required 
>
>
>
>6.0 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 n attempt to add clarification to non-   terminal NAPTR processing.  In this, it clarifies RFC3403.  A    subsequent document will build on this one to extend FC3761 further,    permitting registration of non-terminal Enumservices. 
>
>A URL for this Internet-Draft is: 
>http://www.ietf.org/internet-drafts/draft-conroy-enum-modestproposal-0.txt <http://www.ietf.org/internet-drafts/draft-conroy-enum-modestproposal-00.txt>  
>
>WG ACTION : No action taken. Document may be incorporated into revision of RFC 3761 since it is clear there are a number of changes that have to be made before it could become Draft Standard.
>
> 
>
>Meeting Concludes.
>
>
>  
>


-- 


>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
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 [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>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<


_______________________________________________
enum mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/enum