IETF-64 Vancouver ENUM WG meeting minutes
===============================
Chair(s):
Patrik Faltstrom
Richard Shockey
WG Secretary:
Alex Mayrhofer
Transport Area Director(s):
Allison Mankin
Jon Peterson
Transport Area Advisor:
Allison Mankin
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
|