Subject: [Enum] Draft Minutes from IETF 62 MN

From: Richard Shockey <[email-masked]>
Date: Tue, 15 Mar 2005 15:15:39 -0500

Thank You Spencer !!!
Please note any changes or clarifications.
*********
Telephone Number Mapping WG (enum)
IETF 62 Minneapolis, MN
Wednesday, March 9 at 1300-1500
===============================
CHAIRS: Patrik Faltstrom <paf at cisco.com>
             
Richard Shockey <rich.shockey at neustar.biz>
Transport Area Advisor:
Allison Mankin  <mankin at psg.com>
Mailing Lists:
General Discussion:enum at ietf.org
To Subscribe: enum-request at ietf.org
In Body: subscribe
Archive:

ftp://ftp.ietf.org/ietf-mail-archive/enum/

SCRIBE : Spencer Dawkins <spencer at mcsr-labs.org>
AGENDA:
Report from APEET SIP/ENUM trial at Apricot 2005 at Kyoto. 
Informational item - Yoshiro Yoneya 
Goal of APEET is to conduct joint trials and promote ENUM and related
technologies, including SIP 
Trial goal was to provide ENUM/SIP experience for every Apricot
attendee 
Not providing telephony service - no warranties! 
Provided 802.11 handsets and id/passwords for ENUM directory 
Participants communicated with other attendees, overseas, registered
ENUM information/opt-in phone book 
About 100 participants registered in phonebook, about 30 with more
than two URIs 
Registration prototype now available as free software 
Supported three common SIP phone types 
888-205-xxxx calls, overseas calls made with ENUM lookup 
About 7800 200-OKs, 300 other responses 
SIP really can use ENUM for call routing 
Authentication mechanism from SIP server to MGW is different for each
gateway - requires testing 
Handover between access points is still difficult 
RTP within same AP still difficult 
Planning to offer same service at IETF 64 (500-2000 handsets) in
Vancouver 
Was this trial only on ENUM operation or on delegation, etc? Mostly
providing experience for participants 
WG business.
1. Discussion of the ENUM dip indicator on behalf of the IPTEL WG. 
Left out an author in 00 draft - will add in 01 after blackout period 
Enumdi syntax has not changed 
Replaced MUST NOT retrieve with SHOULD NOT retrieve 
Updated examples as example.com domain names 
Recommending IPTEL WGLC on this document 
2. Status from Patrik on what is happening with the IANA and
enumservice registrations. 
Issues resolved on Monday of this week - everything has been sorted
out with IANA 
Are VPIM registrations consistent with what we want? Yes, with no
additional changes identified on the mailing list - they have been
approved by IESG and are good to go now 
Enum+? This will be updated in RFCs 
2b. There seems to be a sense that we need to at least discuss some
of the structure issues in enumservice registrations in general terms
..this seems to be a warm issue recently with various requirements coming
out of 3GPP etc . In particular we do not have a TEL URL enum
registration document as of yet and someone needs to take on that task. 
VOPI registration draft? Make this a working group item, as
informational document? 
Still need a standards-track TEL URL document - we'll clarify all
this on the list 
3. Issues related to  IRIS for ENUM  -- We have had no
in-depth discussion of this draft on the list and we'd like to see
more.

http://www.ietf.org/internet-drafts/draft-ietf-enum-iris-ereg-00.txt 
Who has read it? Not a lot of people in the room 
Opinions or concerns about this document? ENUM administrations are
looking at this document as a potential requirement 
This is a wonderful document ... 
Minimal changes since last revision, fourth version as WG document 
4. New Item Enumservice registrations for Conferencing  Alan
Johnston  20M
   A URL for this Internet-Draft is:

http://www.ietf.org/internet-drafts/draft-johnston-enum-conf-service-00.txt
 
conf-web and conf-uri registrations 
conf-web is discovery mechanism for web conferences - URI is a source
of information about the conference 
either HTTP or HTTPS 
Value over RFC 4002 web? Don't know a web URI is about a conference 
Will a single phone number route to a single person or to a
conference? Why would a UA ever do this lookup? 
My phone number might have a web page associated with it, but most
callers won't bring up the web page unless they know it's part of the
conference 
Madness lies this way - there's no end to what we might treat as a
special case 
If both web and conf-web are present, they probably point to the same
URI 
Problem we're solving is telling a caller "this is a
conference" - even if it doesn't exist on the IP network at all? Is
this even an ENUM problem? 
Do see difference between web and conf-web - should they refer to
different phone numbers? 
Not finding a resource, but providing information about the resource
- this isn't how we want to use ENUM service tags 
If the service provider needs to provide multiple URIs, multiple ENUM
tags make sense 
Is this a phone number that identifies a conference, or a conference
server? If it's a conference server, that's ludicrous, if it's a
conference, it makes more sense 
Would a user go to a single web server to enter a PIN number? What
about different PINs for different components of the conference? 
We're moving along discovering how much information we want to
publish for ENUM services, and there are lots of potential kinds of
things to publish - "the client might want to know" doesn't let
us draw the line anywhere 
SIP has a negotiation capability so we don't need this in SIP - this
is more about the kind of thing you'll find if you call the resource -
picture of a dog on the web page? conversations about communism? What
does a client do differently when they see this tag? 
Is interpretation based on human intelligence, or does it accommodate
automatons? Automatons would require a lot more structure than we're
talking about here. 
Isn't this the same as isfocus in SIP? If we needed that, we need
this 
We should be keying off a specific kind of XML document, not off an
enumservice tag 
Conf-uri is actually the controversial part of the proposal... 
Says that the resource is a focus 
How many telephone numbers are true conference URIs with no passcode
or PIN needed? 
Is it OK to have both a sip and a conf-uri URI? 
Not hearing clear consensus on what to do with this document, or what
to do with conferences in enumservice registrations (is it needed or is
this part of normal SIP negotiation?) 
Concern is that devices who don't understand this tag won't be able
to connect to a conference - need to include sip if you include conf or
conf-uri 
What's wrong with just saying "isfocus" in the SIP URI
returned from the lookup? 
Is it necessary to know that it's a conference before you start
negotiationg? 
Is there anything you'd differently before you contact the URI?
That's the critical question 
We're trying to create boundaries on what a service is, on an ad hoc
basis, and that's not working well 
Alan to respin this document with more use cases to see if we can
move forward 
We need to be a lot better at deciding what is a service than we are
now... it can't be this painful every time someone proposes an
enumservice! 
We also need to worry about URI schemes defined by people who didn't
think about any of this 
5. In private discussions with folks there seems to me a
demonstrable need 
   to create a SOAP binding for EPP-164. I believe this is an
extremely 
   important project and I'd like to see if there is A.
sufficient interest 
   in the project and if there is sufficient interest B. find
some folks 
   who would be willing to work on the draft.

http://www.ietf.org/internet-drafts/draft-ietf-enum-epp-e164-08.txt 
Mostly enterprise-level interest, and their toolkits are based on
SOAP. Anything that helps with provisioning is good. 
6. ENUM Validation update w/Bernie Hoeneisen 
Ensure that ENUM owner == E.164 owner at registration time 
Version 01 is adding requirements section, split into transport and
content, handling renewal and transfer, adding acknowledgements and
corrections/updates 
Should this be a working group item? as Informational item? Room hum
is "yes" 
7. Status of ENUM Operational Experiences draft? 
No new items in document - can we WGLC a new revision before Paris?
Yes 
8. WG next steps? 
Enumdi loops when we're trying to prevent loops? discussion on
mailing list - if you get the same tel URI back, this is just loop
detection with one bounce - can we just cover the general loop case with
hop count > 1? What do you do when you get a loop back with or without
enumdi? Use first one, last one ... 
GSMA or 3GPP may be requesting ENUM for GRX network - two NAPTR, one
with SIP and one with e-mail for SMS messages. If there is an IMS enum
service, should the enumservice be ims: or sip+ims:? This is another
slippery slope - is this IMS release 5, IMS release 6, ... but it sounds
really wrong. Do we need to take on a liaison on this? Slippery slope is
about 80-percent incline. Doesn't matter if we have an official liaison
or not - we need to know what to tell them, either way. ETSI has asked
and we can give them our opinions. Why do you need to know that a user is
within the IMS system? We have no idea. This is using the DNS as a
replacement for negotiation. There's an IAB draft on DNS assumptions
that's in last call - please look at this and comment! ENUM idea is that
you look up one number and get back one URI - if you voice and IM from
the same SIP URI, this has to come from one provider, right? Where do we
multiplex- ENUM or SIP? How much SIP call routing do we put in DNS
(suggested answer = none). If we don't want to do this, we need to make
sure people can't try, or they'll try for sure. 

Richard Shockey, Senior Manager, Strategic Technology Initiatives
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
enum at ietf.org
https://www1.ietf.org/mailman/listinfo/enum