[Enum] IETF-64 Vancouver ENUM WG meeting minutes - Preliminary

[Richard Shockey <[e-mail]>]

===============================

Chair(s):
Patrik Faltstrom <[e-mail]>
Richard Shockey <[e-mail]>


WG Secretary:
Alex Mayrhofer <[e-mail]>


Transport Area Director(s):
Allison Mankin <[e-mail]>
Jon Peterson <[e-mail]>

Transport Area Advisor:
Allison Mankin  <[e-mail]>

TUESDAY, November 8, 2005

AGENDA BASHING (5 min)
----------------------


The chairs open the meeting. Agenda as well as the location of 
presentations were posted to list. The proposed agenda is accepted 
without comments by the WG.


RECHARTER DISCUSSION (CURRENT PROPOSAL)  (15 MIN )
==================================================

The ENUM working group has defined a DNS-based architecture and protocol 
[RFC 3761] by which an E.164 number, as defined in ITU Recommendation 
E.164, can be expressed as a Fully Qualified Domain Name in a specific 
Internet Infrastructure domain defined for this purpose (e164.arpa).

Background:

E.164 numbers are globally unique, language independent identifiers for 
resources on Public Telecommunication Networks that can support many 
different services and protocols. There is an emerging desire for 
network operators to utilize aspects of RFC 3761 to discover points of 
interconnection necessary to terminate communications sessions 
identified by a E164 number, in addition to identifying end point 
protocols and services.

Working Group Revised Goals and Scope:

1. The working group will update RFC 3761 and advance to Draft Standard.

2.  The working group will examine and document the use of RFC 3761 to
facilitate network interconnection for services using E.164 addressing.
The working group will coordinate its activities with other IETF working 
groups, existing or to be chartered, that are investigating elements of 
peering and or interconnection for VoIP or other services that typically 
use E.164 addressing.

3. The working group will continue examine and document various aspects 
of ENUM administrative and /or operational procedures irrespective of 
whether e164.arpa domain is used.

4. The working group will also examine the use of RFC 3761 technology 
for storing and delivering other information about services addressed by 
E.164 numbers, for example PSTN call routing and signaling data.

5. The Working Group will continue to maintain appropriate contact and 
liaison with other standards bodies and groups, specifically ITU-T G2,to 
provide technical or educational information and address, as needed, 
issues related to the use of the E.164 numbering plan for services on IP 
networks.  In addition the Working Group will continue to encourage the 
exchange of technical information within the emerging global ENUM 
community as well as documentation on practical experiences with 
implementations, alternate technology uses and the administration and 
provisioning of RFC 3761.

6. As described in RFC 3761, the IETF documents and registers the
ENUMservices.  While extant, it is the ENUM working group that performs
the technical review and development of the ENUMservices for the 
Internet community.  The working group determines whether to advance 
them and how to progress them technically.  Coordination with other WGs 
will be taken into account on these.

Other than ENUMservices, all proposed deliverables of the working group 
will be discussed with and approved by the Area Directors, who may 
require wider review due to the broad impact of the subject.

Goals and Milestones

March 06  ENUMservice Registration for Local Number Portability 
  and Related Data as a Proposed Standard

April 06  Requirements for Carrier Interconnection using ENUM 
as an Informational

June 06   Carrier Interconnection using ENUM as a Proposed Standard

July 06   ENUM Privacy and Security Considerations as an 
Informational Standard

August 06 Advancement of RFC 3761 to Draft Standard

----

DISCUSSION:

Most of the issues of the recharter have been discussed on the list 
already. Includes moving RFC3761 up to draft standard, which needs 
interoperable implementations. Documentation on this will be first step 
towards draft standard.

Scope now includes investigating possible carrier ENUM implementations,
and continues registration of ENUMservices.

Milestones: Draft on number portability to be completed this fall, 
carrier enum requirements in spring. Shockey will probably work on a 
privacy and security draft to be submitted soon, and finally asks for 
comments of objections to the charter.

There are neither questions nor objections.
----

ENUM Implementers Draft: (Final Version) 5 MIN
==============================================

	Title		: ENUM Implementation Issues and Experiences
	Author(s)	: L. Conroy, K. Fujiwara
	Filename	: draft-ietf-enum-experiences-03.txt
	Pages		: 33
	Date		: 2005-10-18
	
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 advisory, 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-03.txt

----

DISCUSSION:

Shockey explains the roadmap of the document - this could go to last
call fairly shortly. Only few comments have been posted to the list
so that seems ready to go. When further experiences are to be added,
a new version of the document could be done.

Ken Cartwright: This could probably have an impact on RFC3761 and the
DDDS documents - it's unclear who owns the DDDS documents.
Faltstrom: No one owns the DDDS RFCs - revising them would probably
require to reopen the WG.

Updates to RFC3761 will be baked into the next version experiences document.
----

DNS issues 10-M
===============

B. Title		: ENUM Requirement for EDNS0 Support
	Author(s)	: L. Conroy, J. Reid
	Filename	: draft-conroy-enum-edns0-01.txt
	Pages		: 16
	Date		: 2005-10-25
	
This document mandates support for EDNS0 (Extension Mechanisms for 
DNS) in DNS entities claiming to support ENUM query resolution (as 
defined in RFC3761).  This requirement is needed as DNS responses to 
ENUM-related questions return larger sets of Resource Records than 
typical DNS messages.  Without EDNS0 support in all the involved 
entities, a fallback to TCP transport for ENUM queries and responses 
would typically occur.  That has a severe impact on DNS Server load, 
and on latency of ENUM queries.

    This document updates RFC3761 only in adding this requirement.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-conroy-enum-edns0-01.txt

----

DISCUSSION:


The draft was discussed in the DNSOP WG just before the ENUM wg meeting.

Wimmreuter presents the draft as a proxy:

- ENUM features large responses
- could lead to lots of TCP queries if EDNS0 size option not used
- draft mandates EDNS0 size support on all entities involved in
   ENUM DNS lookups.
- middleboxes could additionally mess up with fragmentation & truncation 
  of responses

The document does mandate EDNS0 size option, but does not recommend a 
certain size (1200 bytes could be a good value, however).

Wimmreuter asks to make this draft a WG item, and let the DNSOP WG have 
a look at it. He points out that a generic document about how DNS should 
be operated could be much bigger, and would probably be too late for 
many implementers.

If this draft is accepted, the corresponding section could be removed 
from the experiences draft discussed before.

Faltstrom: Question was proposed to DNSOP if they could write a Document 
on how to run DNS - they were very interested. However, they were 
nervous about writing a doc about how to run DNS, because that could be 
400 pages. One suggestion was to just have a very brief document with 
normative references (MUSTs SHOULDs etc.) that they are going to review. 
Suggestion is to not decide now about the EDNS0 draft, but instead take 
EDNS0 and the relevant part from experiences together, with brief 
references

WG ACTION : Shockey comments that such a document should be made WG item.

Jean Francois: There are strong reasons to allow corner cases where
EDNS0 support should NOT be a requirement. Is 3761 the right place for
DNS requirements?

Faltstrom: Suggests to discuss the list document once available with
dnsops, and not mess with 3761 for now.

Shockey: Should not stop RFC3671 from progressing

Koch: There's a difference between "protocol" and "operations". 
"Operations" cannot be regulated by RFCs. Depends on who reads
this document: implementers or eg. firewall operators.

Stastny:  asks if experiences draft goes to last call under the light of 
this.

Faltstrom suggests another quick round, and then to publish what we have 
there, because this is a live document.
----

IANA Registration for ENUMservice vCard  10-Min
===============================================

	Author(s)	: A. Mayrhofer, D. Lindner
	Filename	: draft-mayrhofer-enum-vcard-00.txt
	Pages		: 7
	Date		: 2005-10-5
	
  This memo registers the ENUMservice "vCard" using the URI schemes 
http" and "https" according to the IANA ENUMservice registration process 
described in RFC3671.  This ENUMservice is to be used to refer from an 
ENUM domain name to the vCard of the entity using the  corresponding 
E.164 number.

   Clients may use information gathered from those vCards before, during 
or after inbound or outbound communication takes place.  For example, a 
callee might be presented with the name and association of the caller 
before he picks up the call.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-mayrhofer-enum-vcard-00.txt



DISCUSSION:

ENUMservice for refering from phone numbers to URIs containing vCard.
Came from questions from service providers which wanted to publish.
Usage scenario: query for number, receive vCard URI, fetch vCard.

No subtypes defined right now, two URI schemes (http and https) proposed 
now.

Feedback received about subtypes: Should subtypes reflect protocol?

Faltstrom (as WG member): Privacy constriants, and granularity
limits of HTTP. vCards could be synthesized based on authentication.
HTTP not optimal for detailed access constraints. A bit nervous that 
usage of http is too quick. Recommend at least subtyping because good WP 
systems should not use http, but could be started
with http now. Suggestion is to check HTTP, LDAP, IRIS

Shockey: Want to see granularity on access control as well.

Schiefner: Would like to see this a WG item, looking at moving that forward.

Levi ??: vCards heavily used in XMPP. Should look at this. Not sure if
granularity is what people expect from publishing a vCard.

Jimmy ??: Suggestions to granularity on access controls could be out of
scope of the ENUM WG?

Mayrhofer: Could simply say "we make the reference, what behind this is
out of scope for ENUM".

Faltstrom: Clarification on privacy needed.

Baskin: Privacy needs to be highlighted each time. However, "ENUM" does
not the vCard, ENUM just returns a reference. It's done after the lookup.

Faltstrom: Agreed, need to be subtyped to differentiated.

??: There is a draft about vCard over WebDAV in the calendaring for
WebDAV. draft-debut-carddav?

Schwartz: Issues on identifying when using HTTP.

WG ACTION: Based on a hum of the WG, consensus for adopting this as WG item.
----

IANA Registration for IAX ENUMservice ( 10-Min )
================================================

     Author(s)    : E. Guy
     Filename    : draft-guy-enumiax-00.txt
     Pages        : 11
     Date        : 2005-10-20

    This document registers the IAX2 ENUMservice using the URI scheme 
  'iax2:' 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-guy-enumiax-00.txt

----
Ed Guy presents the document: registers IAX ENUMservice with iax2 URI.
The URI definition itself is in the protocol spec itself (aims at 
Informational). Some feedback on formatting was received.

Rosenberg: Passwords in URI are bad.

Guy: addressed in doc as "bad thing".
Peterson: There is a list on reviewing URI, comments expected from there

Faltstrom: Peer review between W3C and IETF exists
.
Cartwright: empty subtype causes headache for implementors, URI scheme
Recommended

Shockey: Underlying protocol informational, going for proposed standard?

Stastny: same with h323. Was that an informational?

Cartwright: Uncertainty about subtype - what is it supposed to contain?
Clarification desired.

Faltstrom: Subtypes were actually requested. Anyway, Subtype is not 
equal to URI scheme, must look up IANA registration for relation between 
subtype and protocol URI.

WG ACTION : The WG hums in favor of accepting this draft as a WG item.


An ENUM Library API    ( 5 Min WG Chairs will lead discussion )
===============================================================

	Author(s)	: T. Sajitha
	Filename	: draft-sajitha-enum-api-00.txt
	Pages		: 7
	Date		: 2005-10-21
	
This draft defines a library API for ENUM. The API takes telephone
number as input and returns the URI associated with that telephone number.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-sajitha-enum-api-00.txt

----
WG Chairs have made the decision that API is out of scope, and will not 
be discussed here.
----

Carrier ENUM Requirements?   ( 15 - M )
=======================================

Title	: Carrier/Infrastructure ENUM Requirements
	Author(s)	: S. Lind, et al.
	Filename	: draft-lind-infrastructure-enum-reqs-01.txt
	Pages		: 7
	Date		: 2005-10-21
	
This document provides requirements for "infrastructure" or "carrier" 
ENUM, defined as the use of RFC 3761 technology to facilitate 
interconnection of networks for E.164 number addressed services, in 
particular but not restricted to VoIP

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-lind-infrastructure-enum-reqs-01.txt

----

DISCUSSION: ( Shockey for Pfautz, Lind)

This document will be core requirements document for of carrier enum 
moving forward.

"Carrier enum is usage of ENUM technology by carrier of record, carrier 
of record is the carrier providing PSTN service to a number, definition 
ultimately national matter". DNS must return a result, and can identify 
a point of interconnection. User ENUM and carrier ENUM must coexist.

Document a WG item since Paris, because requirements are first step.

Schiefner: Common terminology? "Infrastructure" vs "carrier"

Baskin: no preference on terminology, but political burden on the word
"carrier" to be considered.

Shockey: voipeer was unable to define what a "carrier" is.

Baskin: Requirements as they are?

Shockey: No, continue to work on this, guidance on next steps.
??: "provides PSTN service" too restrictive - excludes IMS users.
??: Requirements doc without statements on problems to be solved?

Schaefer: ETSI doc on "infrastructure ENUM". choice of "infrastructure"
could be interpreted as association to this doc.

WG ACTION: Humm taken on "carrier" vs "infrastructure" usage in future 
discussion and documents. Chairs consensus that “infrastructure” is 
preferred to “carrier”

Peterson: Stronger hum on "infrastructure", should be taken to list.

Shockey: Next revision of document should refer to "infrastructure".
----

Combined User and Carrier ENUM in the e164.arpa tree  ( 15 - M )
================================================================

	Author(s)	: M. Haberler, R. Stastny
	Filename	: draft-haberler-carrier-enum-01.txt
	Pages		: 15
	Date		: 2005-10-21
	
ENUM as defined now in RFC3761 [1] 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-01.txt

----



Haberler presents the draft:

Use of a single tree for infrastructure purposes has economic 
advantages, draft introduces resolution on texts, tried to generalize 
that to possible other trees. Draft does not imply that actual data is 
in e164.arpa (can be decided at country level).

Indication where branch goes off is indicated by "branch location 
record”, which is put into the DNS itself at the cc level. Assumption 
left is knowledge about country codes (back-off algorithm described in 
draft). This is a change from -00 (dropped the table about branch location).

Not documented in the current draft: Make label configurable, or insert
a zero length label. Could also refer other apexes (generalization).
open issue: Feedback required on branch location record, currently using 
TXT record in prototypes. Assumption is that a NAPTR service would be 
the most flexeble.

Peterson: Might an appropriate case for TXT record. Is just additional
information that has no programmatic function for limited audience, so
that might be OK. However, should be discussed in the WG.

??: TXT bad idea because of overloading, and multiple records with
multiple semantics.

Koch: Make a problem statement, and take it to appropriate DNS WG. 
Asking early might save you problems.

There are already prototypes for Asterisk and SER,they are using TXT
records for now. Roadmap: integrate suggestions received here, add
detailed resolver behavior by copying and modifying from RFC3761. Will
make a problem statement about branch location record.

Shockey: need finish requirements draft before this is promoted to WG
item status - but expects work to continued on this doc, and reconsider
it once requirements are stable.

Cartwright: Doc has overlapping with Lind doc - requirements should be 
copied over. Would like to see guidance on conflicts between 
infrastructure and user contexts (SIP records in both)

Haberler: Precedence will be given to one tree depending on contexts 
(carriers only looking at carrier part, user only in users), but 
probably resorting to other tree will happen. However, might be local 
policy.

Cartwright: concerns about conflicting data

Shockey: Important: There is no _conflicting_ data. It's up to policy
to define precedence, if one uses both. Various national policies and
best current practices will probably exist.

Stastny: Carriers will probably look up carrier enum, but user might
ask carrier to use look up user enum first for his calls.
----

IANA Registration for an ENUMservice Containing PSTN Signaling Information

draft-ietf-enum-pstn-01    ( 10 Min )
=====================================

----
Livingood presents draft: History: Was submitted as non-wg item in
Paris, where it was formally adopted - renaming etc. IPTEL WG is
doing registration for tel-URI parameters, might need updating this
doc. Service type was changed from "npd" to "pstn".

Suggestions on CNAM received. Document added SIP URI as well as 
examples. We added section about distribution of data (data to be 
distributed privately) and section about record conflict resolution. 
Section 7 talks now about implementation suggestions (from feedback 
about implementation questions), additional section talks about call 
flows would work in practice. Update references to reflect tel-URI 
registration and SIP adoption. Will work with various vendors to test 
this out with practical data.

DISCUSSION:

Shockey: Draft currently focused on number portability, will look into
other things (CNAM, probably global title translation). Feedback from
WG desired on other forms of PSTN SS7 data to be incorporated.

Schiefner: Why data private?

Shockey: Restrictions on npd in various jurisdictions, so service cannot 
happen in a public visible domain (IPsec or caching DNS structures)

McCandless: Why registration if it happens in private space? People 
might starting use that in public space.

Faltstrom: Private stuff always leaks into public space – registration 
prevents clashes, and should be performed in any case.
----

ENUM validation drafts
======================

draft-ietf-enum-validation-arch-00.txt,
draft-ietf-enum-validation-token-00.txt
draft-ietf-enum-validation-epp-01.txt)

----
Bernie Hoeneisen & Alex Mayrhofer present updates to the three document.

ENUM validation is checking that only the one who owns the number gets
the ENUM registration. Three drafts: Architecture, transport of 
validation data via EPP, and validation data format.

Changes to architecture: Name change to reflect WG acceptance, minor
cleanups. Changes to EPP draft: Aligned with other two drafts, input
on ID attribute baked in document. Changes to validation token:
added number range option (input from Sweden), synchronize tag names
with IRIS EREG and other drafts, cleanup. Will probably look at SAML,
which was not considered yet. Requesting input from GEOPRIV because
of civic address format.

No comments.
Next steps?

Meeting is concluded.
----

Issues posted to the list after the meeting
===========================================

IANA Registration for an ENUMservice Containing PSTN Signaling Information

Livingood noted: that during my presentation on 
"draft-ietf-enum-pstn-00" the following issues were discussed and 
decided upon:

1.  Minor nits with the draft will be resolved and I will re-submit to
up-rev to -01.

2.  Must revisit the section on Distribution of Data to note that it may 
or may not be done on a private basis.  This will be primarily 
determined based on regulatory requirements in a particular country.  I
have not determined the exact wording of this yet.

3.  After fixing the nits and word-smithing #2 above (resulting in 
-01),we will work on -02 with new suggested data types.  These include 
CNAM and 800 number data, per feedback from Kevin McCandless.  (This 
would not include Global Title Translation - which was a question raised 
by the co-chair.)  The co-authors are open to any other suggestions.

Separately, the need was again confirmed for a guide to creating an
ENUMservice I-D.  This work will be undertaken by members of the WG in
the near future.

Regards
Jason Livingood
----

One issue raised during the discussion on Ed Guys IAX was to finally
clarify the rules for subtyping of ENUMservices.

1. should there be subtypes or not
2. what should be used at subtypes (e.g. the URI)

This discussion is not new, some years? ago it was discussed
if you need subtypes indication the URI on the right side at all,
because you just have to look at the right side of the NAPTR to see it

So basically the registration template is indicating which URI are
valid to be used with this ENUMservice type

This was rejected because then a client is required to evaluate
ALL NAPTRs for this ENUMservice type (including regexp) to find
out the URI and then decide which object to take

As stated by Patrik this must not be the case, it must
be possible by the client to select the NAPTR only by the information
in the ENUMservice field, taking stupid clients into account.

Therefore the praxis was established to use subtypes indication the
URI on the right side, and also to use the URI name itself, to avoid 
confusion, although this is not necessary. If only one URI is possible, 
no subtype is used (e.g. ENUMservice sip or H323).

The only problem here exists when an ENUMservice is defined which
contains at the moment only one URI, but MAY be expanded later
with an additional URI.

We (e.g. Lawrence, Rudi and I) prefer in this also to use a subtype
(the URI), even if it seems not necessary, just to be on the save side
for future extensions.

My proposal is that in future all new ENUMservice registration SHOULD
contain the URI as subtype

regards
Richard Stastny
----

This was not brought up by me, but concerns our draft:

The definitions and terminology used in
draft-haberler-carrier-enum-01

should be moved over and aligned with the definitions and terminology in

draft-lind-infrastructure-enum-reqs-01

Richard Stastny
----

I think it's a vital point that Patrik and Richard schooled me on:  The 
fact that the IETF will make *no* judgments or statements about the 
appropriateness, precedence, or "conflict" resolution of NAPTRs in the 
User ENUM tree and the Carrier ENUM tree for the same TN.  The Carrier 
ENUM tree may very well have NAPTRs for any ENUM service type for a 
given TN, while NAPTRs for the same TN and the same ENUM service types, 
but with perhaps different URIs, may also reside in the User ENUM tree 
at the same time.  The decision on which tree to query, and perhaps in 
what order to query them, and perhaps how to resolve "conflicts" (I 
don't use the term "conflict" in a negative sense) is entirely up to the 
ENUM client application.   I had not heard this said before or seen it 
written, but it certainly simplifies the problem of having two trees.

Kenneth Cartwright

-- 


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