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

From: Richard Shockey <[email-masked]>
Date: Fri, 19 Aug 2005 22:08:25 -0400

IETF
63  Telephone Number Mapping (ENUM) WG Meeting
Minutes

Comments from the list incorporated.

Chair(s):

Patrik Faltstrom <[email-masked]>

Richard Shockey <[email-masked]>

Transport Area Advisor:

Allison Mankin  <[email-masked]>

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

Pfautz approach of use of non-terminal
NAPTR’s

Haberler/Stastny approach with
delegation at
RIPE/ITU  aka [CC]. c.e164.arpa

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

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 +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
[email-masked]
https://www1.ietf.org/mailman/listinfo/enum

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