[14:05:05] --- yone has joined
[14:38:48] --- mocmobile has joined
[14:43:50] --- hkruse has joined
[14:44:48] --- paf has joined
[14:49:37] <paf> Meeting starts
[14:49:52] <paf> wg chair walks through the agenda
[14:50:13] <paf> scribe is assigned (Paul)
[14:50:53] <paf> scott about e164 number mapping extensions for epp
[14:51:06] --- kjd has joined
[14:51:07] <paf> scott: what will the wg do with the document?
[14:52:39] <paf> chair: how many have read the document? (5-10)
[14:52:57] <paf> chair: has anyone of these any issues with the document? (0)
[14:53:12] <paf> chair: Scott, what do you think, experimental or proposed or...?
[14:53:35] <paf> Scott: Experimental is for documents which have dragons we know of, else it can be proposed standard. Other epp extensions are proposed, but I don't care.
[14:53:36] --- stastny56 has joined
[14:55:06] <paf> Scott: I want people to read and look at the NAPTR spec now.
[14:55:42] <paf> chair: proposed path forward is to update the document once, and then have a wg last call, and if no issues are found go to the AD's
[14:56:07] <paf> allison: what about service registrations?
[14:57:13] <paf> Next item on the agenda: ENUM operations
[14:57:34] <paf> Kazunori Fujiwara from JPRS
[14:57:55] <paf> co-author of document with Lawrence which could not come
[14:58:10] <paf> this presentation is about draft-ietf-enum-experiences-00.txt
[14:58:36] <paf> issues separated into server-side and client-side issues
[14:58:49] <paf> server-side: enum population side
[14:58:57] <paf> client: enum data lookup side
[14:59:07] --- andreas-b has joined
[15:06:01] <yone> discussion about Non-Final NAPTRs
[15:07:56] <paf> One document exist which talk about non-final NAPTR's, but there is no "real" need today.
[15:08:39] <paf> Conclusion is that the document draft-ietf-enum-experiences is very very close to be finished.
[15:09:05] <paf> Rest of the discussion to the list.
[15:09:13] <paf> Next agenda item.
[15:09:32] <paf> Stasny/Conroy - draft-enum-void-00.txt
[15:09:51] --- jjmbcom has joined
[15:09:55] <paf> [Scribe typed an error] draft-stasny-enum-void-00.txt
[15:11:16] <paf> Overall issue is that for ENUM, enduser is controlling what is registered in the zone. If no registration is made give NXDOMAIN result in DNS, no further information exists, and call is passed to PSTN.
[15:11:36] <paf> Some NRA's today assign E.164 number ranges for ENUM use (such as +43780 in Austria)
[15:11:49] <paf> Calls to E.164 numbers in this range can only be reached using ENUM.
[15:12:21] <paf> A user agent doesn't know the special call is for VoIP (ENUM) only, get NXDOMAIN from DNS, pass call to PSTN and call will fail.
[15:12:41] <paf> It would be better if the originating caller do get a response from DNS which indicate "unassigned" state.
[15:13:23] <paf> ENUM-service called "VOID" should say the number is unused, and not assigned to an end-user. This can be used by NRA's for blocks which have been allocated but not assigned etc.
[15:14:02] <paf> The mailto URI is chosen as the URI scheme attached to the VOID service type to indicate who to contact for more information
[15:14:14] <paf> Enumservice: void
[15:14:22] <paf> Subtype: mailto
[15:14:26] <paf> URI Scheme: mailto
[15:16:50] <paf> Richard: What happens if a user don't want to have any email address published at all?
[15:17:07] <paf> Room think you have to have some data there.
[15:19:06] <paf> Jim: In some parts of the world, it is not the case only the end-user can decide the delegation of the ENUM data.
[15:19:39] <paf> Richard: jim, do you think there is a need for this?
[15:19:49] <paf> Jim: Yes, I just have issues with some of the background.
[15:21:10] <paf> Richard: Allison, we have work in iptel which look into a dip-indicator for the tel:-URI, just so you know.
[15:21:33] <paf> Jim: Let's go to the slide about "numbers only for E.164"
[15:21:56] <paf> jim: What happens if a call originates where the user doesn't have ENUM?
[15:22:32] <paf> Stasny: If you dial such a number in the US, the call will be routed to austria, and in austria the number will be routed to a gw, which do the enum lookup etc.
[15:23:31] <paf> jim: what about the last bullet then, when the call originates as VoIP?
[15:24:14] <paf> Stasny: The problem is the risk for a loop. A call on VoIP in the US will drop the call to PSTN, route the call to austria, where it will hit the gw which get NXDOMAIN in the gw.
[15:24:53] <paf> Jim: ok, if the call originates on IP, then it makes sense.
[15:27:00] <paf> Steve: what if number portability make no numbers be "enum only"?
[15:27:07] <paf> Stasny: you don't have to use this.
[15:28:09] <paf> Steve: Just don't think this will be used all over the place. It might be interesting in those countries that allocate specific blocks to VoIP. I'll go back and read the document again.
[15:28:48] <paf> Shockey: Should this be a wg document (hum)? (yes)
[15:29:14] <paf> Stasny: I expect getting more comments.
[15:30:36] <paf> Allison: Warning because this is a tool which turn ENUM into a routing tool for carriers. It is opening the door...
[15:31:13] <paf> Carsten: What about other URI schemes than mailto?
[15:31:37] --- mocmobile has left: Disconnected
[15:34:20] <paf> Geoff: This is weird, you take a non-assigned number and assign an endpoint (in some URI scheme) to it. Should really non-existing things be assigned to existing things? Especially as not all non-existing numbers exists as non-exiting ones according to this scheme.
[15:37:03] --- stastny56 has left: Disconnected
[15:37:30] <paf> Next agenda item.
[15:37:39] --- stastny56 has joined
[15:37:49] <paf> Cost optimization based on ENUM.
[15:37:59] <paf> Normal users are not aware of ENUM.
[15:38:36] <paf> draft-bartosiewicz-enterprise-enum-00.txt
[15:40:07] <paf> Core (from an ENUM perspective):
[15:40:40] <paf> [Order] Preference of the calling party (not the preference of the called party stored in user-ENUM)
[15:40:46] <paf> It's based on the analyses of data stored in the connectiosn database and tariffs database
[15:40:56] <paf> [Preference] propability of the connection
[15:41:03] <paf> Additional flag: quality
[15:44:14] --- stastny56 has left: Replaced by new connection
[15:44:15] --- stastny56 has joined
[15:44:15] --- stastny56 has left
[15:47:28] <paf> James Seng: what is the status of this document
[15:47:47] <paf> [Jabber scribe is needed, because my laptop will be used for the presentation]
[15:47:59] <paf> New over to new agenda, operator ENUM.
[15:48:58] <paf> Chair: public enum is the 3761, with use of DNS and e164.arpa as mapping from E.164 to URI's. It assumes all data is available to all users on the Internet without any authentication etc.
[15:49:48] <paf> Stop using the name carrier *ENUM*. What is happening is that carriers have the need of getting information of getting E.164 to URI mapping. They can use DNS, LDAP and whatever. How they do it is not what we should talk about here.
[15:50:23] <paf> The other issue I think is important is whether if authentication/authorization is needed for access to the data, and that seems to be one important thing.
[15:50:52] <paf> We will not under any circumstances talk about solutions. What are the requirements for a solution?
[15:50:57] <paf> (That was Richard)
[15:51:31] --- kjd has left: Disconnected
[15:52:20] --- jakob has joined
[15:52:20] <paf> Jim: I am concerned that you say this is not ENUM.
[15:52:35] <paf> Patrik: I think Richard said we have to talk about requirements.
[15:53:11] <paf> Jim: But, carrier ENUM is about e164.arpa, and carrier ENUM is how carriers put data in e164.arpa.
[15:54:54] <paf> Allison: different people mean different things, so we have to start with requirements.
[15:55:36] --- yone has left: Disconnected
[15:57:55] --- yone has joined
[16:04:54] --- jakob has left
[16:13:05] --- kjd has joined
[16:29:40] --- stastny56 has joined
[16:40:24] --- naotaka has joined
[16:43:31] --- hkruse has left
[16:48:07] --- jjmbcom has left: Disconnected
[16:53:24] --- yone has left: Disconnected
[16:53:35] --- naotaka has left
[16:57:39] --- paf has left
[17:05:06] --- kjd has left: Replaced by new connection
[17:16:46] --- stastny56 has left: Disconnected
[17:27:05] --- andreas-b has left