Re: [Enum] IETF65 ENUM session minutes

[Richard Shockey <[e-mail]>]

Mowafy, Hala wrote:
> Thanks for the minutes.  I see there was a request for a list of CNAM
> specs.
> The following should cover it:
> - Telcordia GR-1188-CORE: CLASS Feature: Calling Name Delivery Generic
> Requirements (December 2000)
> - ANSI T1.641-1995: Calling Name Identification Presentation
> - ANSI T1.639-1995: Calling Name Identification Restriction


yes it does .. thanks ..

> 
> Hope this helps.
> Hala
> 
> -----Original Message-----
> From: Alexander Mayrhofer [mailto:[e-mail]] 
> Sent: Friday, March 31, 2006 2:31 AM
> To: '[e-mail]'
> Subject: [Enum] IETF65 ENUM session minutes
> 
> 
> minutes are below - thanks to Spencer and Bernie for serving as scribes.
> 
> ----
> IETF65 (Dallas, TX) ENUM meeting minutes
> 
> Chair(s):
> Patrik Faltstrom <[e-mail]>
> Richard Shockey <[e-mail]>
> 
> 
> WG Secretary:
> Alex Mayrhofer <[e-mail]>
> 
> Scribes:
> Spencer Dawkins <[e-mail]>
> Alex Mayrhofer <[e-mail]>
> 
> Jabber Scribe:
> Bernie Hoeneisen <[e-mail]>
> 
> 
> Real Time Applications Infrastructure Area Director(s):
> Cullen Jennings <[e-mail]>
> Jon Peterson <[e-mail]>
> 
> 
> AGENDA BASHING (5 min)
> ======================
> 
> Slight change to agenda - Patrik talks about 3761bis planned works
> first:
> 
> RFC3761bis
> ==========
> 
> Patrik is not upping for IAB, so has time to update RFC3761 (3761bis),
> which is in line with WG milestone.
> 
> A RT tracker system is set up for work on this document, issues should
> be opened as tickets in the system. One ticket per issue should be
> opened, there will be shared username/password for access to the system.
> 
> Patrik will work on the individual issues, and resolve corresponding
> tickets once an issue is resolve. When all issues are resolved, the
> document should be ready. 3761bis does not exist as an draft yet - RT
> stuff will provide input for this. Patrik will do the editing.
> 
> More info:
> http://www1.ietf.org/mail-archive/web/enum/current/msg04849.html
> 
> Tickets could also affect other documents (conroy asks for DDDS
> issues). Shockey asks if guidance on non-terminals should go in there
> as well. Conroy suggests to put hints in 3761bis. patrik: operational
> experience stuff could go in seperate section or even document.
> 
> ENUM Implementers Draft: (Final Version) 5 MIN
> ==============================================
> 
> Title		: ENUM Implementation Issues and Experiences
> 	Author(s)	: L. Conroy, K. Fujiwara
> 	Filename	: draft-ietf-enum-experiences-04.txt
> 	Pages		: 37
> 	Date		: 2006-3-9
> 	
> 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-04.txt
> 
> slides: http://www3.ietf.org/proceedings/06mar/slides/enum-8.ppt
> 
> *  Changes include section 6 (general DNS issues), request publication -
> Section 6 is biggest source of changes (others mostly editorial, seeking
> clarity, please give feedback for continued improvements).
> * Added size recommendations for EDNS0, intermediate system guidance,
> TTL
> and ANY (255) queries (this is a general DNS issue, but has been a
> problem
> in ENUM deployment - NAPTRs appear/disappear, etc.).
> * Please read and review - think we are finished, publish and update
> later
> if we need to.
> * Tim - "Non-terminal NAPTRs SHOULD NOT be used" - can't go quite this
> far -
> if you're gonna do this, it will take a long time - one third of the
> code on
> mobile clients deals with this. EDNS0 doesn't work with TCP, etc. - lots
> of
> things break. We'll talk offline, and this is a good WGLC comment.
> * EDNS0 is recommended here. May be spun off as separate document and
> just
> referenced here (if we can avoid dependencies). Still discussing MUST
> capitalization with DNSOPS reviewers.
> * Peter Koch: Implementation and OPS side is too much in one document -
> advocate separation. Having normative language for firewalls isn't
> appropriate in this standards track document. EDNS0 is a precondition
> for
> anything that uses DDDS - make a recommendation for minimum size in
> general,
> TCP, etc.
> * Conroy: Firewalls break DNS over TCP all by themselves, without any
> ENUM
> involved.
> 
> Enumservices Guide
> ==================
> 
> Title		: Guide and Template for IANA Registrations of
> Enumervices
> 	
> [ 15 M ]
> 	Author(s)	: J. Livingood, B. Hoeneisen
> 	Filename	: draft-ietf-enum-enumservices-guide-00.txt
> 	Pages		: 12
> 	Date		: 2006-2-27
> 	
>    This document provides a guide to and template for the creation of
>    new IANA registration of ENUM services.  It is also to be used for
>    updates of existing IANA registrations.
> 
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-enum-enumservices-guide-0
> 0.txt
> 
> slides: http://www3.ietf.org/proceedings/06mar/slides/enum-4.ppt
> 
> History: People filling out over and over again same sections with same
> content when doing Enumservice registrations. Standard template desired.
> 
> request input for 3.2 ("Intended usage: COMMON") and 3.6 ("IANA
> Considerations"). Please post text or email privately.
> 
> Section 3.2 - should a subtype always be given? should seperate subtypes
> have seperate registrations? for each URI scheme seperate?
> Statement on non-terminal NAPTRs?
> 
> suggested answer: yes/yes/yes/no (with warning on non-terminals)
> 
> Penn: didn't get a lot of guidance - would like template that includes
> cautions.
> cautions ok, but should actually tell you how to do this.
> Stastny: Usage of non-terminals need to be clarified before usage of
> them is advocated.
> shockey: should the behaviour regarding non terminals be in registration
> document itself?
> conroy: could imaging 2 ways to non-terminals. currently, missing flag
> indicates "non terminal", which is outside DDDS. If no flag is given,
> we can't do registrations, so seperate flag and seperate registration?
> 
> no final conclusion about the four questions.
> 
> CNAM
> ====
> 
> Title        : IANA Registration for an Enumservice and "tel"   [ 15 Min
> ]
>     Parameter for Calling Name  Delivery(CNAM) Information
>     Author(s)    : R. Shockey, J. Livingood
>     Filename    : draft-shockey-enum-cnam-00.txt
>     Pages        : 10
>     Date        : 2006-1-13
> 
>    This document registers the Enumservice "cnam" and subtype "tel"
>    using the URI scheme 'tel:', as per the IANA registration process
>    defined in the ENUM specification, RFC 3761.
> 
>    In addition this document registers the parameter "cnam" in the IANA
>    "tel" Parameter Registry defined in RFCXXX.  This data is used to
>    facilitate the transfer of Calling Name Delivery (CNAM) data for
>    calls that originate on the PSTN that may be displayed on VoIP or
>    other Real-time Client User Agents (CUA).
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-shockey-enum-cnam-00.txt
> 
> slides: http://www3.ietf.org/proceedings/06mar/slides/enum-6.ppt
> 
> is about caller name display. info is requested in the US before
> callees phone rings. service assumes a private tree, with info
> not public.
> 
> discussion about tel uri parameter vs. data uri. draft proposes tel
> parameter, but not sure about this (list discussions).
> 
> What character set being used? No ultimate restriction, but PSTN limits
> to 15 characters in ASCII. How to interpret contents? DDDS says UTF-8,
> but there should be wording about this in there. Need to be aware what
> is about to being parsed (security considerations should point that
> out).
> List of CNAM specs to point people to is requested.
> 
> Group agrees to adopt this as WG item - no "no" hums in room.
> 
> tel or data URI? Paul primary objector, but not in the room. "tel"
> because this is a classic PSTN thing?
> Jon: don't compete with SIP caller name - what happens if both present?
> This needs to be interopable with normal SIP stuff.
> Jason: What if other providers don't have SIP URIs in their network, and
> are trying to limit the number of bits they are paying to store?
> Lawrence: Could have "network provided" and "user provided" numbers as
> well.
> this is for "network provided" - we use TXT in trials now.
> Jon: If network provided, don't we prefer to render that? Display name
> could be present in from tel or sip. data would never show up in SIP,
> but the servers or user agents would fetch it. depends all on call flows
> and use cases. don't couple with tel - would never appear in request.
> Jason/Richard: No preference, will dig deeper into data URI.
> 
> IAX2 Enumservice:
> =================
> 
> Title		: IANA Registration for IAX Enumservice            [ 15
> M ]
> 	Author(s)	: E. Guy
> 	Filename	: draft-ietf-enum-iax-00.txt
> 	Pages		: 13
> 	Date		: 2006-2-22
> 	
> This document registers the IAX2 (Inter-Asterisk eXchange Version 2)
> 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-ietf-enum-iax-00.txt
> 
> slides: http://www3.ietf.org/proceedings/06mar/slides/enum-7.pdf
> 
> Need IAX2 URI registration, and a new template has shown up since
> last time.
> Some minor tech changes.
> Currently requested IESG review of protocol itself, will submit URI
> request using new template.
> Enumservice would need to go after URI registration (because RFC editors
> would need to perform edits otherwise).
> 
> ENUM & Domainkeys
> =================
> 
> Title		: Telephone Number Mapping and Domain Keys  as a
> Distributed
> Identity Infrastructure                                        [ 15 M ]
> 
> 	Author(s)	: A. Mayrhofer
> 	Filename	: draft-mayrhofer-enum-domainkeys-00.txt
> 	Pages		: 10
> 	Date		: 2006-2-23
> 	
>    This document creates a decentralized indentity infrastructure by
>    combining technology from E.164 Number Mapping (ENUM) and DomainKeys
>    Identified Mail (DKIM).  This infrastructure uses E.164 numbers as
>    identities, ENUM DNS for key distribution, and leverages the trust
>    relations from ENUM validation to actual messages signed by the
>    number holder.
> 
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-mayrhofer-enum-domainkeys-00.t
> xt
> 
> slides: http://www3.ietf.org/proceedings/06mar/slides/enum-2.ppt
> 
> # Not a full DDDS app, not a full Domain Keys app, so ...
> # Validation is most expensive part of ENUM provisioning - validation
> takes
> the identity to Internet domain - make use of this expense!
> # ENUM, not full DDDS
> # Domainkeys, but just key/storage
> # Validate that Sender has the same identiry as number holder
> # Available to any ENUM domain holder, no prior knowledge about sender
> required, any node on Internet can do this, domain internationally
> agreed,
> common validity.
> # Applications - signin to P2P networks, CLI signalling to PSTN, SPIT
> prevention.
> # Disconnected nodes could do authentication (with cached public keys)
> # Looking for opinions/feedback
> # Looking for crypto-PKI clue on co-authors
> # Steve Kent - you're going down to individual devices, right? form of
> identifier needs to be appropriate for applications. Going to this
> granularity needs to scale bigger than the DKIM application today, so
> think
> about scaling. (and why not DNSsec?)
> # Koch: How much do you want to trust DNS? You need DNSsec to trust this
> anyway, and if you do have DNSsec, maybe this would be enough. Cool
> ideas
> with deployment problems, probably premature, keep thinking.
> # David Schwartz - concerned about relying on PKI for individual
> certificates with no challenges, etc. E.164 numbers have geographic
> content,
> and this opens us up to some additional issues (beyond e-mail
> addresses).
> May need additional controls, may need to know who is verifying the
> numbers,
> etc.
> # SIP has made different tradeoffs, because of things like lack of huge
> installed base, etc. - have you looked at SIP Identity? There's a gap
> here
> that needs to be filled.
> # Penn Pfautz: Interesting idea, could be investigate further for usage
> even in carrier scenarios.
> 
> Enumservice FOAF
> ================
> 
>  Title        : IANA Registration for Enumservice foaf   [ 15 Min ]
> 
>     Author(s)    : K. Reichinger
>     Filename    : draft-reichinger-enum-foaf-00.txt
>     Pages        : 9
>     Date        : 2006-2-15
> 
> This memo registers the Enumservice "foaf" using the URI schemes
> "http" and "https" according to the IANA Enumservice registration
> process defined in RFC3671.  The Enumservice "foaf" is to be used to
> refer from an ENUM domain name to the location of a FOAF RDF file
> using the corresponding E.164 telephone number.
> 
> Clients may use data retrieved from a FOAF RDF file to provide caller
> or callee with information available within the Friend-Of-A-Friend
> (FOAF) Semantic Web application.  For example, the caller might be
> presented with personal information on the callee (e.g. name, gender
> and various online attributes) as well as information on the callee's
> social context (e.g. relations to friends or colleagues).
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-reichinger-enum-foaf-00.txt
> 
> slides: http://www3.ietf.org/proceedings/06mar/slides/enum-3.ppt
> 
>     *  FOAF is "Friend of a Friend"
>     * Part of Semantic Web Project
>     * Lots of terms defined already (in presentation)
>     * Data is RDF-based and can be published anywhere on the web
>     * Want to link FOAF data to phone number
>     * Allows FOAF/ENUM spidering
>     * Introduces ENUM to Semantic Web
>     * Rohan - how do you find my FOAF data if I don't have a phone
> number
> today? Could be published on website, could appear as FOAF data under a
> related friend.
>     * Richard Shockey - privacy issues seem astounding - how granular is
> privacy? File-by-file, so all-or-nothing. This is vCard-equivalent
> privacy -
> no, it's also other people's data in your profile, so it's more than
> vCard
> privacy issues.
>     * Is this voluntary, like blogging? Yes. What applications read this
> information today? Don't think so, at the moment (but it's RDF-based).
>     * Alex: Privacy question comes up for every service we talk about.
> Jason/Bernie - please point out that securing the underlying data isn't
> part
> of the ENUM service registration template, only the additional security
> issues of linking it to ENUM.
>     * Rohan - there is a vCard security considerations list now - that's
> understood. What are we doing in ENUM if we make E.164 addresses more
> useful
> than other identifiers? Make a service discovery service, instead?
>     * E.164 numbers are simply keys, period.
>     * Patrik is concerned that the E.164 number becomes the FOAF
> identifier
> and should not be tied directly to the URI, which may move, etc. Lots of
> people are looking in this area (IRIS, Rohan, etc.). ENUM gives you
> URIs,
> not URNs.
>     * What should we do with this document? The underlying protocols are
> experimental, so this should be, too. Need to publish something, so
> people
> know about the string - X-dash, for example?
>     * Jon - don't actually know how to distinguish ENUM applications
> that
> use the same protocols (http) - need to figure out how to do this.
>     * Rohan - if you have someone's web page and can't find their FOAF
> information, that's a Semantic Web issue that needs to be solved
> independently. (web page address could come from ENUM, FOAF to be
> discovered from there)
>     * Rohan - need to come up with a generic way to do these
> registrations.
> Don't need to do much here except avoid conflicts.
>     * Richard Shockey - would like to see one more spin of this document
> with updated registration template (draft previously discussed), but
> this is
> very interesting.
> 
> IM Enumservice & Calendering Enumservice
> ========================================
> 
> Title		: A Telephone Number Mapping (ENUM) Service Registration
> for Instant
> Messaging (IM) Services
> 	
> [ 15 M ]
> 	Author(s)	: R. Mahy
> 	Filename	: draft-mahy-enum-im-service-00.txt
> 	Pages		: 5
> 	Date		: 2006-2-22
> 	
> This document registers a Telephone Number Mapping (ENUM) service for
> Instant Messaging (IM).  Specifically, this document focuses on
> provisioning im: URIs in ENUM.
> 
> 
> Title		: A Telephone Number Mapping (ENUM) Service Registration
> for Internet
> Calendaring Services
> [ 15 M ]
> 
> 	Author(s)	: R. Mahy
> 	Filename	: draft-mahy-enum-calendar-service-00.txt
> 	Pages		: 5
> 	Date		: 2006-2-23
> 	
> This document registers a Telephone Number Mapping (ENUM) service for
> Internet Calendaring Services.  Specifically, this document focuses
> on provisioning mailto: (iMIP) and http: (CalDAV) URIs in ENUM.
> 
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-mahy-enum-calendar-service-00.
> txt
> 
> slides: http://www3.ietf.org/proceedings/06mar/slides/enum-5.ppt
> 
> IM:
> ---
> 
>     *  Was surprized that IM enumservice didn't exist, but it didn't
> exist.
>     * Like pres URI, can only return IM URIs, and have a 3861 mechanism
> to
> discover correct/preferred protocol.
>     * Comments?
>     * Lawrence - this is fine. Not sure who will use this, because most
> IM
> users won't have SRV records. But no problem with the draft.
>     * Room hummed to make thsi a WG draft
> 
> Adopted as WG item.
> 
> Calendar:
> ---------
> 
>     *  Used to discover mailto and http(s) URIs for Internet calendaring
> services
>     * Actually several subservices (manipulate calendar, check
> busy/free),
> including subservices that you can support in iCal, but not with IMAP.
>     * Could this be merged with vCard transport? CALDEV doesn't really
> have
> a working group home (Calify has the right people) - but this isn't a
> generic vCard service.
>     * Is this just traditional calendar events? There are a lot of
> possible
> calendars, which may be overlapping. Would this be better for the IETF
> Agenda? Rohan prefers to point to services with well-defined services.
>     * Are we rolling too much stuff into ENUM?
>     * Is this a WG item? Some number of hums in favor, fewer opposed.
> 
> Adopted as WG item.
> 
> Infrastructure Requirements
> ===========================
> 
> Title		: Infrastrucure ENUM Requirements
> 	Author(s)	: S. Lind, P. Pfautz                       [ 20
> M ]
> 	Filename	:
> draft-ietf-enum-infrastructure-enum-reqs-00.txt
> 	Pages		: 7
> 	Date		: 2006-3-6
> 	
> 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-ietf-enum-infrastructure-enum-
> reqs-00.txt
> 
> slides: http://www3.ietf.org/proceedings/06mar/slides/enum-1.ppt
> 
>     *  Lawrence - UK experience is that your "SHALL" should be "SHALL
> NOT" -
> anything that is public must not be able to identify the serving CSP...
> -
> this is the difference between "must have the capability" and "must turn
> the
> capability on". Have used cut-outs in the US for information like
> carrier-of-record.
>     * If we're allowed to return anything, it would be carrier of
> record.
>     * Richard Shockey - if you're going to do something like this, you
> have
> to have a WHOIS.
>     * Next steps with this document? WGLC? Consensus to go for it.
> 
> Combined User and Carrier ENUM
> ==============================
> 
> "Combined User and Carrier ENUM in the e164.arpa tree" -
> draft-haberler-carrier-enum-02.txt .
> 								[20 M]
> Abstract:
> 
> 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.
> 
> until it comes out of the queue, the I-D is available at:
> 
> http://www.ietf.org/internet-drafts/draft-haberler-carrier-enum-02.txt
> 
> slides: http://www3.ietf.org/proceedings/06mar/slides/enum-0.ppt
> 
> # Consensus is to have one tree. In .arpa? IETF, IAB, RIPE, ITU-T
> involvement all needed, and existing policies/procedures can be reused.
> No
> time to come up with a new governing body and get agreement.
> # Above the country code, or below the country code? (or both places in
> parallel? - but would meet the requirements no matter where it is).
> # Above country code is most straight-forward solution (everything
> works),
> but has some constraints on timing for ITU-T concurrence.
> # Below country code is a national matter and can be implemented now.
> # Uses Branch Location Records (BLR).
> # Proposed to pursue both options in parallel, to allow trials using
> below
> country code.
> # Need RFC 3761bis to accomplish this.
> # Is BLR at the country level? No, location is a national matter ("below
> the
> zone cut").
> # Lawrence - don't like TXT records. new RR is strongly recommended. Use
> TXT
> records for trials?
> # Richard Shockey - have never liked BLR (and never will). IAB isn't the
> decision-maker, it's IESG.
> # Patrik - ITU-T will be involved even if it's below the country code.
> # Lars - problem with TXT records. Can't stop you from using them for
> trials, but please make sure there are no collisions.
> # Richard Shockey - ITU-T will be involved, get used to it.
> # Patrik - in all the choices, so ITU-T involvement isn't a reason to
> pick
> one choice.
> # Richard Shockey - we need to expect 3GPP interest in carrier ENUM,
> too.
> # There are only about 300 records - why update millions of clients to
> recognize them?
> # May ITU-T meeting - need to do something about this very soon.
> # Patrik - do we disagree about above/below because we are missing
> requirements from the requirement documents? Should we have had more
> requirements?
> # Jon - remember that the IESG doesn't make decisions in a vacuum - IAB
> is
> part of the community that will be involved in any community decision.
> # Need to describe what's in DNS (label the boxes or your filing system
> will
> break down). Can't assume that all TXT records will "really" be BLRs.
> # There is a Draft Standard on handling unknown RR types (one of our
> few).
> # We all prefer option one, but what do we do in the interim?
> Alternative is
> that carriers will pick something, hopefully in the public parts of DNS,
> and
> then we'll TRY to tie things together.
> # Should this draft be a working group item? Richard Shockey doesn't
> think
> so - are we talking about having a separate domain for infrastructure
> ENUM?
> That's a separate document. Does not see BLR moving forward (unusual use
> of
> DNS).
> # Lawrence - don't like this, I'm worried about this, but the way ENUM
> is
> set up in the world, a global standard isn't going to happen quickly
> without
> something like this.
> # Richard Shockey - are BLRs a viable option? We took a hum, and lots of
> people said "yes".
> # Patrik - Some individuals violently disagree - can they go off to the
> bar
> and report back to the working group? On the Mailing list, this week.
> 
> The outcome of bar discussions was later posted as the "Dallas Treaty":
> http://www1.ietf.org/mail-archive/web/enum/current/msg04848.html
> 
> 
> AOB
> ===
> 
> Koch: worried about potential size of DNS responses, number of ENUM
> services
> rising could lead to lots of TCP queries...
> 
> meeting concluded.
> 
> 
> _______________________________________________
> enum mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/enum
> 
> _______________________________________________
> enum mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/enum
> 


-- 


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