[09:08:39] --- ietf-wg-enum has joined
[09:32:05] --- ietf-wg-enum has left: Disconnected
[09:46:47] --- jjmbcom has joined
[10:08:51] --- jjmbcom has left: Disconnected
[19:15:13] --- herve.prigent@jabber.org has joined
[19:16:11] --- herve.prigent@jabber.org has left
[19:16:15] --- herve.prigent@jabber.org has joined
[19:17:36] --- frodek has joined
[19:28:08] --- levigner has joined
[19:30:42] --- mstjohns has joined
[19:43:59] --- patrik has joined
[19:44:18] <patrik> This is paf that will try to be jabber-scribe
[19:44:27] <patrik> The agenda is approved
[19:45:17] --- bhoeneis has joined
[19:45:45] <patrik> Regarding going to draft standard, Richard and Patrik will go through 3761 together with the experience draft to see whether we can go to draft or wether we have to recycle at proposed first.
[19:45:51] <patrik> A matrix with tests will be created.
[19:46:04] <patrik> The new charter is walked through
[19:46:53] --- Glenn Parsons has joined
[19:47:42] <patrik> ENUM implementers draft
[19:48:07] <patrik> Conroy is not here, but Richard explains the draft. This is a fairly baked draft, and last call in the wg will be called.
[19:48:19] <patrik> Ken: the draft is good
[19:48:23] --- mstjohns has left
[19:49:31] <patrik> This has impact on 3761 and DDDS
[19:49:56] --- ogud has joined
[19:52:15] --- mstjohns has joined
[19:52:35] --- ogud has left: Replaced by new connection
[19:53:37] <patrik> Now the draft draft-conroy-enum-edns0-01.txt
[19:54:39] <patrik> Presentation of the content
[19:59:32] --- ogud has joined
[20:00:01] --- ogud has left: Replaced by new connection
[20:00:59] <patrik> Patrik reported we have two people from dnsop wg that are interested in helping
[20:04:45] <patrik> This is an ENUM wg item
[20:06:12] <patrik> This implies btw one more quick round of comments on the experiences document, and then it goes to wg last call
[20:06:23] <patrik> vcard enumservice
[20:06:25] <patrik> new item
[20:07:01] <patrik> draft-mayrhofer-enum-vcard-00
[20:07:44] <patrik> the idea that the uri one get back is an HTTP or HTTPS URI that when a GET operation on the URI give back a vcard entry
[20:15:51] <bhoeneis> - PAF as individual: - privacy concerns, some more wording needed - http is maybe not completely optimal - maybe IRIS is a choice --> might be too quick solution should be at least subtyped, so that other protocal could be added lateron - AM: - Looked at LDAP for this - Wanted something fast and cheap - PAF: - should this be a subtype of white pages
[20:16:40] <patrik> (thanks)
[20:16:52] <bhoeneis> - Rich: - strong recommendation concerning privacy - LDAP is not a wonderful idea - IRIS would be for a number of reasons
[20:18:00] <patrik> Carsten: Patrik, did you want a granularity so different attributes are given back to different users
[20:18:36] <patrik> patrik: yes, I think I want the full record be given back to friends, but only few things to non-friends
[20:18:53] <patrik> Leif: I don't think granularity is what people think of when thinking of vCards
[20:19:18] <patrik> <unknown>: we need to think a bit more of this. If people don't want things out there, they should not publish things.
[20:22:00] <bhoeneis> - AM - We could say we just publish the pointer and let the other end deal with the privacy issues - PAF - We dould document the possible security impacts - Rich: - no objections to go forward with HTTP - might be granular repsonse mechanism useful
[20:23:33] <bhoeneis> - N.N. - Is is out of scope of ENUM on how that all we work - we don't have to worry how to implement it, just find URL
[20:24:23] <patrik> We should also look at "draft-daboo-carddav-00"
[20:24:31] <patrik> vCard Extensions to WebDAV (CardDAV)
[20:25:07] <bhoeneis> (Speakers should state their names....!)
[20:25:16] <patrik> (yes)
[20:25:39] <patrik> (do you mind continuing to jabber instead of me?)
[20:25:39] <patrik> (sorry...)
[20:27:53] <bhoeneis> (you can do that better than me...;-) )
[20:28:20] <bhoeneis> (was just backing up, while you were busy.)
[20:28:31] <patrik> (ok)
[20:31:03] <patrik> http://www.eguy.org/presentations/2005/draft-guy-iax-00p.txt
[20:32:02] <patrik> This is not an IETF document (yet).
[20:32:25] <patrik> Question from rich: what status do you want on the target?
[20:32:44] <patrik> The document we talk about here is a URI scheme definition, but rely on an underlying protocol.
[20:34:21] <patrik> It was pointed out that H.323 is informational
[20:37:29] <bhoeneis> - paf: you have to look into the IANA registration, not just guess from the name of the service type
[20:37:59] <patrik> A document is under creation that explain how registration of ENUM service types works
[20:38:33] --- ksto033 has joined
[20:38:34] <patrik> Question behind the discussion was "should the subtype be the same as the URI scheme"?
[20:39:14] <bhoeneis> - Rich: H.323 is not an IETF standard as well - Rich: Clarification needed - Hum in favor of applying as WG item
[20:39:17] <patrik> ENUM API library -- out of scope (already decided)
[20:39:51] <patrik> draft-lind-infrastructure-enum-reqs-01
[20:40:01] --- Glenn Parsons has left: Disconnected
[20:40:40] <patrik> Abstract 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.
[20:40:57] <patrik> Infrastructure ENUM is defined as the use of the technology in RFC3761 [2] by the carrier-of-record for a specific E.164 number [3] to map a telephone number into a URI that identifies a specific point of interconnection to that service provider's network that could enable the originating party to establish communication with the associated terminating party. It is separate from any URIs that the end-user, who registers their E.164 number, may wish to associate with that E.164 number.
[20:43:30] <bhoeneis> @Patrik: Could you please before discussion starts remind people to state their names...
[20:43:36] <patrik> yes, I will
[20:43:57] <bhoeneis> Thanks!
[20:44:22] <patrik> Carsten: Would it make sense on having an agreement on one terminology?
[20:44:32] <patrik> Carsten: Infrastructure enum or carrier enum (for example)?
[20:44:56] <ksto033> why not?
[20:44:57] <ksto033> its confusing
[20:45:44] <patrik> Carsten: I suggest carrier enum as that is what I am using :-)
[20:46:34] <patrik> Jim: I think one of the issues about the terminology is the baggage of the term "carrier"
[20:47:04] <patrik> Jim: regardless of what we choose, other people will make assumptions, and we should think about that when we make the decision
[20:47:26] <patrik> Rich: note that the voipeer group have not agreed on what "carrier" is
[20:47:41] <patrik> Jim: What is the reason for discussing the document today?
[20:48:01] <patrik> Rich: We should provide Steve and Penn with guidance on "what are the next steps"
[20:48:18] <patrik> Jim: 2.8 "work with open numbering plans"
[20:48:42] <patrik> Jim: What is "c. Restrict additional functionality to carrier resolvers."
[20:48:56] <patrik> Rich: Jim, please post these comments to the list
[20:50:02] <patrik> <unknown>: One talk about carrier of record:
[20:50:02] <patrik> For purposes of this document, "Carrier of Record" refers to the entity that provides PSTN service for an E.164 number with the understanding that this definition is ultimately a matter for national authorities to determine.
[20:50:17] <patrik> This is too restrictive
[20:51:03] <patrik> Mark: I think the right word is "infrastructure" so one remove the problem with the word carrier
[20:51:36] <patrik> mark: I like parts of this document, I have problems with this as a requirements document. requirements have problem statements that have to be resolved.
[20:51:43] <patrik> Mark: For example, I have problems with 2.5
[20:51:54] <patrik> Implementation of Infrastructure ENUM MUST NOT restrict the ability of an end-user, in a competitive environment, to choose a Registrar and/or Tier 2 name server provider for end-user ENUM registrations.
[20:52:10] <patrik> This postulates a solution to a problem that is not specified
[20:52:21] <patrik> The document must focus on requirements and not talk about solutions
[20:52:33] --- levigner has left: Replaced by new connection
[20:52:43] --- levigner has joined
[20:52:49] <patrik> Robert: There is an ETSI document on infrastructure document. Are we creating connections to that document or not? Are there similarities or differences?
[20:53:15] <patrik> Michael: Why not foobar enum :-)
[20:53:21] <patrik> Michael: Better with infrastructure
[20:53:28] <patrik> About c. Restrict additional functionality to carrier resolvers.
[20:53:57] <patrik> The intention is that it should not break already deployed and implemented solutions.
[20:54:21] <patrik> Richard: Carrier ENUM or Infrastrcture ENUM>
[20:54:59] <patrik> It was a stronger hum for infrastructure ENUM
[20:55:52] <patrik> Michael
[20:56:12] <patrik> draft-haberler-carrier-enum-01
[20:56:23] --- ogud has joined
[20:57:09] --- tom_creighton has joined
[21:12:47] --- ogud has left: Replaced by new connection
[21:13:12] --- ogud has joined
[21:15:21] <bhoeneis> - Jon Peterson: - TXT Record might be appropriate for Branch location record - N.N. - TXT Records are the worst idea - Peter Koch - ask DNS WGs beforehand - MAH: WG item? - Rich: Finalize Requirements document first - Ken: What about conflicts, e.g. if E2U+sip is in both carrier and user ENUM
[21:16:11] --- mstjohns has left
[21:16:43] <bhoeneis> Rich: It is not conflicting date, policy decision which one to use
[21:19:19] <bhoeneis> s/carrier/infrastructure/g :-)
[21:20:14] <patrik> Location for slides and presentations of today:
[21:20:15] <patrik> https://onsite.ietf.org/public/meeting_materials.cgi?meeting_num=64
[21:24:55] --- levigner has left
[21:40:25] --- herve.prigent@jabber.org has left: Logged out
[21:40:44] --- tom_creighton has left
[21:42:31] --- bhoeneis has left: Logged out
[21:43:25] --- ksto033 has left: Lost connection
[21:52:10] --- patrik has left
[21:56:40] --- ksto033 has joined
[22:00:22] --- frodek has left
[22:00:48] --- ogud has left
[22:55:29] --- ksto033 has left
[23:30:52] --- mstjohns has joined
[23:34:42] --- mstjohns has left