[12:11:07] --- otmar has joined
[13:02:10] --- xiaodong has joined
[13:54:13] --- otmar has left
[14:08:13] --- m_ersue has joined
[14:08:17] --- m_ersue has left
[14:17:45] --- xiaodong has left
[15:48:16] --- bnsmith has joined
[15:52:38] --- lellel has joined
[15:53:23] --- no8 has joined
[15:53:37] <lellel> you're in!
[15:53:44] <no8> cool!
[15:53:47] <no8> thanks
[15:54:05] <lellel> I've sent your ticket on to the jabber folk, but this sould work for now.
[15:54:35] <no8> Ah, an ad-hoc work-around. Great!
[15:55:39] <lellel> enjoy!
[15:56:16] <lellel> ping me if you have trouble again - lellel @ jabber.org
[15:56:23] --- lellel has left
[15:57:32] --- bnsmith has left
[15:57:45] --- bnsmith has joined
[15:57:51] --- agallant has joined
[16:01:17] --- jis has joined
[16:01:56] --- becarpenter has joined
[16:02:05] --- lemmakin has joined
[16:02:26] --- mlepinski has joined
[16:02:52] --- becarpenter has left
[16:05:20] --- agallant has left: Logged out
[16:05:48] --- agallant has joined
[16:07:08] --- hpditt has joined
[16:07:09] --- otmar has joined
[16:08:49] --- hotta has joined
[16:09:03] --- fujiwara has joined
[16:09:12] --- raj has joined
[16:09:39] --- axelm has joined
[16:11:29] --- msj has joined
[16:11:30] --- dmalas has joined
[16:11:56] <msj> sorry - missed what draft we're talking about right now??
[16:12:00] <otmar> void
[16:12:06] <msj> thanks
[16:12:56] --- m_ersue has joined
[16:13:10] --- bhoeneis has joined
[16:14:32] --- dblacka has joined
[16:14:41] --- irino has joined
[16:16:16] --- xiaodong has joined
[16:17:01] --- jun_koshiko has joined
[16:18:07] --- joshlitt has joined
[16:20:04] --- patrik has joined
[16:20:07] --- frank has joined
[16:20:37] --- jakob has joined
[16:22:11] <xiaodong> why I cannot see the jabber scribe things
[16:22:44] --- geoff has joined
[16:23:19] <otmar> Is there a jabber scribe at all?
[16:24:47] <axelm> bernie, could you do a bit of jabber scribing? would be appreciated...
[16:25:35] <xiaodong> Hope to see the jabber scribe things, patrik
[16:26:03] <axelm> ok, i'll change me minute taking to the jabber...
[16:26:19] <axelm> regarding RFC3761bis and ENUM URI.
[16:26:31] <axelm> patrik finally found the email with comments to otmar et al.
[16:26:32] <bhoeneis> Good idea
[16:26:54] <xiaodong> axelm, how about publish your minutes just now to the jabber
[16:27:17] <axelm> agenda being accepted ===================== draft review. mentioning void: ================ rich requests comments on void. jon peterson: doc has been around in stuck state. there are very deep questions regrding the methodology of the doc. q posed to the chairs: is there goindg to be an update peter koch: comment about "inappropriate use" of the DNS. question should be addressed. stasty: two opinions problem: "inappropriate use" vs. "useful information". shockey: what are the alternatives to this? need an ENUM query which returns the status of a certain number... what is the correct methodology ???: this is admin data. do you have that in the DNS? alex: we have that data in the DNS. "locked" peter: we don't have that in there. jon: we'll not gonna solve that here. Has the group the will to do this? strong opinions indicate interest. 2nd point: Enumservices guideline could be the doc to make assumptions. stastny: fed up with that other people say that this is useless... jon: it's up to resolve the "discuss" positions sinnreich: DNS is not a replacement for SS7. see sufficient people raising hand that they will be interested. volunteers will contact stastny. experiences draft ================= shockey asks for comments. no comments - issues resolved? Moving forward to last call... peter koch: EDNS0 issue? shockey: EDNS0 is dealt with different document... peter: even though aiming at informational, it makes clarification of 3761... this was to be a living document, wasn't it? shockey: bring that issues back to the list? paf: problem that we'd like some docs to be drafts forever,
[16:27:22] <axelm> here you are.
[16:27:43] <axelm> first requirements on infrastrucutre enum: carriers to supply infor about endpoints etc.
[16:27:52] <axelm> next question is "how do we do that"
[16:28:15] <axelm> but, User ENUM is run "by the user", so that clashes with Infrastructure ENUM.
[16:28:15] <xiaodong> thanks
[16:28:51] <axelm> if we have delegation for the full number to the user, we cannot "delegate back" the infrastructure enum zone.
[16:29:11] --- m_ersue has left
[16:29:17] <axelm> if we compare the "URI-idea" now with ie164.arpa or combined..
[16:29:35] <axelm> that would be an important discussion this WG should follow.
[16:29:44] <axelm> patrik speaking not as chair, but as author.
[16:30:08] <axelm> patrik concerned about breaking out a tree for a specific service, namely telephone.
[16:30:22] <axelm> could only be the first one, email, sip, etc. could follow.
[16:30:46] <axelm> so technically we should foresee that there are many more than just 2 branches.
[16:31:29] <axelm> penn pfautz: view on "seperate trees": numbers are allocated to service providers, and assigned to users.
[16:32:05] <axelm> penn: user has right to the number as a user.
[16:32:19] <axelm> penn: service provider has "another" right to the number as provider.
[16:32:49] <axelm> penn: so, is there an issue there?
[16:33:14] --- rwatro has joined
[16:33:33] <axelm> patrik: mixing user rights and service provider rights - user cannot influence portability database.
[16:34:48] <axelm> henry: portability makes the user "own" the number.
[16:35:18] <axelm> henry: can do telephony even without an number. service definition by an old addressing mechanism?
[16:35:50] <axelm> patrik: we're here to use E.164 as number... output is whatever URI...
[16:36:32] <axelm> penn: E.164 numbers as allocated are not ONLY for telephone?
[16:37:12] <axelm> penn: nobody talks about making user@provider portable...
[16:37:47] <axelm> penn: structure of phone numbers: they are not allocated based on service. one can use any service with the number...
[16:38:15] <axelm> penn: so, see no contradiction between the user doing whatever he wants, and (2) the telco doing whatever he wants with the same number
[16:38:47] <axelm> sinnreich: phone numbers are for narrowband telephony.
[16:39:12] <axelm> otmar lendl: different delegation points for single numbers and allocated blocks. so mixing those delegation borders makes trouble.
[16:39:36] <axelm> shockey: no need to reargue the infrastructure reqs here...
[16:39:53] <axelm> patrik: case that we have not been talking enough?
[16:40:19] <axelm> patrik: let the questions conclude, then URI draft?
[16:40:40] <axelm> otmar: what about the rfc3761bis doc now since it violates basic reqs?
[16:41:11] <axelm> patrik: would like to do another round of document - one example is flawed.
[16:42:06] <axelm> klaus nieminen: we have single operators in the traditional world for a number.
[16:42:11] --- isudo has joined
[16:42:26] <axelm> klaus: there is user right to have the user domain delegated, but this is fine with user-enum.
[16:42:33] --- alfredprasad has joined
[16:42:45] --- miki has joined
[16:42:54] <axelm> jon: would like to see detailed change log.
[16:43:29] --- pk has joined
[16:43:30] <axelm> otmar: URI draft: URI record does not work with open numbering plan.
[16:43:40] --- ysuzuki345 has joined
[16:43:44] <axelm> because number cannot be "put back" into the URI..
[16:44:21] --- ysuzuki345 has left
[16:44:24] <axelm> patrik: do you dial the full number, or is it two stage?
[16:44:30] --- ysuzuki345 has joined
[16:44:52] --- dcrocker has joined
[16:44:59] <axelm> otmar: two ways: direct dialling, or overlap dialling.
[16:45:33] <axelm> penn: the whole number needs to be sent. a record for any full number would need to be populated
[16:46:11] <axelm> patrik: ok, users can "add digits" to the number...
[16:46:49] <axelm> otmar: routing prefix based, they don't care about the digits "behind" the prefix.
[16:46:50] --- dcrocker has left
[16:46:59] <no8> just like subaddressing was in X.25 ...
[16:47:04] <axelm> otmar: carrier does not even know the length behind a customers number.
[16:47:32] <no8> worse than wildcard: non-terminal 8-(
[16:47:46] <axelm> patrik: URI draft should therefore just specify the URI record itself, and not talk about delegation stuff.
[16:47:54] <axelm> otmar: simple regex would be useful.
[16:48:09] <axelm> shockey: any other q on URI draft?
[16:48:25] <axelm> ???: If only URI RR, why is that in ENUM?
[16:48:46] <axelm> patrik: .... (lying on the floor) ...
[16:49:02] <axelm> softswitch requirements ddraft
[16:49:04] <axelm> ---------------------------------------
[16:49:27] <axelm> NIDA operates +82 ENUM zone.
[16:49:27] --- Antoin has joined
[16:49:46] <axelm> since 2005.
[16:50:06] <axelm> two Korean VoIP SPs are now testing routing using ENUM.
[16:50:26] <axelm> ENUM modules have been embedded on their softswitches
[16:50:53] <axelm> according to RFC3761
[16:50:54] --- geoff has left
[16:51:20] <axelm> enum in +82 currently contains numbers of 2 carriers only.
[16:51:29] <axelm> provisioning is done using EPP.
[16:51:43] <axelm> (shows a classical ENUM call routing slide)
[16:51:51] --- enrico has joined
[16:52:01] <axelm> so, in the beginning, not all numbers are in ENUM.
[16:52:18] <axelm> so, question: what to do when a switch cannot get routing info from ENUM?
[16:52:30] --- richard.barnes has joined
[16:52:53] <axelm> so, to have the softswitch route all calls, not just those for which enum is available.
[16:52:59] --- irino has left
[16:52:59] <axelm> simple method:
[16:53:08] <axelm> softswtich MUST lookup ENUM info.
[16:53:13] <axelm> if info exists - use it.
[16:53:30] <axelm> if no info, uses it's own routing database as fallback.
[16:53:44] <axelm> (falls back to "legacy routing")
[16:53:58] <axelm> (slides with examples).
[16:54:21] <axelm> first example with URI returned from ENUM -> use this.
[16:54:44] <axelm> second example: no ENUM info, use lookup table to find destination.
[16:55:28] <axelm> jason livingood: what is the objective of the ID? Is this an informational, what's the overall goas.
[16:55:41] <axelm> s/goas/goal/
[16:55:59] <axelm> shockey: isn't the scenario obvious?
[16:56:05] --- ajsaf@jabber.org has joined
[16:56:13] --- AdamUzelac has joined
[16:56:23] <axelm> penn: would agree that this looks obvious, but at least one implementation does not confirm to that.
[16:56:51] <axelm> shockey: struggles, because too obvious.
[16:58:08] <axelm> jean francois mule: doc defines what happens when RCODE 3. but: there could be other methods a softswitch does - we might want to keep this open...
[16:58:12] --- mah has joined
[16:58:35] --- ajsaf@jabber.org has left
[16:58:54] --- andrewsullivan has joined
[16:59:19] <axelm> jason: understand where this comes from.
[16:59:40] <axelm> shockey: don't think that this is WG item at this stage - what problem are we trying to solve?
[17:00:00] <axelm> authentication scheme draft
[17:00:02] <axelm> -----------------------------------------
[17:00:19] --- frank has left
[17:01:25] <axelm> notices that they use enum.at clouds and boxes :-)
[17:01:41] <axelm> provides a mechanism to authenticate the user.
[17:01:43] --- irino has joined
[17:02:20] <axelm> client a encrypts, client b receives message
[17:02:34] <axelm> client b contacts authentication center, receives key.
[17:02:49] --- dmalas has left
[17:03:41] --- dcrocker has joined
[17:03:50] <axelm> if encryption is wrong, the call fails.
[17:04:14] <axelm> jon: this is a SIP security thing
[17:04:43] <axelm> shockey: this is DKIM for ENUM.
[17:04:58] <axelm> (BTW, we had a similar draft in Dallas from me, actually).
[17:05:19] <axelm> jon: what is the security property that we're trying to achieve?
[17:06:28] <axelm> jon: this is probably the wrong place to discuss SIP security, it has been studied extensively in SIP.
[17:07:09] <axelm> jonathon rosenberg: ENUM is only for phone numbers. so doesn't work with an SIP URI.
[17:07:53] <axelm> alex : had similar draft in Dallas.
[17:08:25] <axelm> shockey: ENUM is probably not the right place to discuss security authentication related stuff.
[17:08:29] --- mo7sen has joined
[17:08:42] --- ja has joined
[17:08:46] <axelm> jon: pops up in a lot of places, lack of DNSsec is limiting Keys in DNS.
[17:09:11] <axelm> jon: OTOH, DNSsec itself is putting keys in the DNS - could be reused for applications
[17:09:24] --- dcrocker has left
[17:09:30] <axelm> jon: DKIM is controversial, similar issues in SIP.
[17:09:47] <axelm> jon: DNSsec probably the best way to generalize such stuff...
[17:10:10] <axelm> shockey: *looks at charter* seems not to be in.. there exist more appropriated places.
[17:10:40] <axelm> ??: seems that this draft is not soo much tied to SIP, and rather tied to ENUM....
[17:11:07] <axelm> shockey: is a security / authentication issue, not a ENUM issue.
[17:11:23] <axelm> patrik agrees that it does not fit in scope.
[17:12:24] <axelm> ???: again, this is not too much tied to SIP, more to DNS.
[17:12:41] <agallant> who's at the mike?
[17:12:51] <dblacka> dave crocker
[17:12:55] <agallant> tnx
[17:13:05] <axelm> dave: DNS already has security issues that we live with.
[17:13:27] <axelm> dave: the fact that data retrieved is keys is more a nuisance rather than a problem?
[17:13:44] <axelm> Q: if DNSsec would be deployed in ENUM, would this exist?
[17:13:56] <axelm> jon: yes, it would - this is about application keys.
[17:15:09] <axelm> Xingdong: This is not just for a certain application. it is more a framework, based on ENUM.
[17:15:47] --- msj has left
[17:15:52] <axelm> comment: sounds like circular logic.
[17:16:44] <axelm> sorry, "Xiaodong" instead of "Xingdong" - sorry bout that.
[17:17:17] <axelm> shockey: patrik identified scope problems. WG has not expertise to judge this work.
[17:18:12] --- hpditt has left
[17:18:13] <otmar> axelm presets xmpp enumservice
[17:18:19] <bhoeneis> draft-mayrhofer-enum-xmpp-00.txt
[17:18:30] <otmar> (actually, we all here right now use XMPP to talk to this jabber server)
[17:18:50] --- dcrocker has joined
[17:19:00] <otmar> XMPP is standardized: rfc3920f
[17:19:31] <otmar> used for: IM, Presence, VoIP (google-talk).
[17:19:39] <otmar> Lots of clients available
[17:19:43] <AdamUzelac> don't forget dingaling! ;)
[17:20:38] <otmar> RFC4622 defines the xmpp URI scheme
[17:22:06] <otmar> simple service type definition
[17:23:27] <otmar> considerations: No auth component.
[17:23:39] <otmar> i18n allowed for now
[17:26:17] <axelm> ENUM branch locatiion record
[17:26:23] <axelm> ---------------------------------------------------
[17:26:28] --- miki has left
[17:26:51] <axelm> offspring of the "Dallas treaty"
[17:27:07] <axelm> supports the "interim" solution to Infrastructure ENUM.
[17:27:48] <axelm> approach store the position where the Infrastructure ENUM tree branches off.
[17:27:56] <axelm> 4 parameters
[17:28:00] <axelm> "application"
[17:28:03] <axelm> "seperator"
[17:28:08] <axelm> "position"
[17:28:11] <axelm> "apex"
[17:28:57] <axelm> also supports the "final" solution, transition possible.
[17:29:18] <axelm> there are implementations for OpenSER (CVS, patch for 1.1 required)
[17:29:29] <axelm> And there is an implementation for Asterisk.
[17:29:38] <axelm> open issues:
[17:29:43] --- irino has left
[17:29:54] <axelm> application: use a registry? use underscore prefix?
[17:30:12] <axelm> Terminology: Define the "infrastructure" label already?
[17:30:18] <axelm> in the document itself?
[17:30:33] <axelm> Location: where do we store the EBL record?
[17:31:01] <axelm> cc Level? or Other options?
[17:31:04] --- miki has joined
[17:31:58] <axelm> eg. "have it always at position 4"?
[17:32:41] <axelm> Austria (+43) is running an I-Enum-Trial
[17:32:59] <axelm> now branch hardcoded to "i.3.4.e164.arpa"
[17:33:16] <axelm> need the EBL to get other trials up
[17:33:24] <axelm> requesting input from DNS people.
[17:33:57] <axelm> Draft could be stripped down to the basic RR type, and don't define the ENUM application in that draft - would make the RR definition uncontroversial.
[17:34:23] --- klensin has joined
[17:34:39] --- shinta has joined
[17:34:49] <axelm> olaf kolkman: please strip to RR definition. also wait for 2929bis. getting a new RR allocation will then be a matter of filling out a form.
[17:35:02] <axelm> olaf: not sure how fast 2929bis will be out..
[17:35:23] <axelm> shockey moves to floor mike: reiterates that he does not like the draft.
[17:35:26] --- mlepinski has left
[17:36:12] <axelm> stastny: thought that we've sorted that out already.
[17:36:21] --- klensin has left
[17:36:46] <axelm> stastny: linked to "combined" , so should be a WG item.
[17:36:54] <axelm> shockey: it is already
[17:37:01] --- klensin has joined
[17:37:02] --- irino has joined
[17:37:07] --- hpditt has joined
[17:37:15] <axelm> ENUM services guid
[17:37:18] <axelm> ----------------------------------------
[17:37:23] <axelm> bernie presents.
[17:38:08] <mah> Rich - in Dallas you agreed to support the combined ENUM effort in good faith, signed the contract - now please stick to it!
[17:38:18] <axelm> skips editorial draft.
[17:38:19] --- klensin has left
[17:38:46] --- klensin has joined
[17:39:05] <axelm> security considerations: should we have that in each registration, or point to it, other options?
[17:39:51] <axelm> jon: should be one thing that we can reference. stick it in this draft, break it out later.
[17:40:31] <axelm> jon: notices that it would be a downref if it's just a BCP.
[17:40:47] <axelm> jon: could also be in 3761bis.
[17:41:17] <axelm> subtype mandatory? "no" suggested.
[17:41:40] --- msj has joined
[17:42:04] --- dcrocker has left
[17:42:05] <axelm> seperate registrations for each subtype? "yes" suggested.
[17:42:34] <axelm> no comments so far.
[17:42:57] <axelm> URI scheme always matches subtype? "no" suggested.
[17:43:24] <axelm> Seperate registrations for sep. URI schemes? no suggested.
[17:43:25] --- isudo has left
[17:43:45] <axelm> What track are we aiming for?
[17:45:20] <axelm> jon: BCP would match the doc type.
[17:45:27] --- dblacka has left
[17:45:45] <axelm> jon: do we need to normatively reference this doc from Enumservice registrations.
[17:46:06] --- jakob has left
[17:46:37] <axelm> jon: if the doc does not specify how ENUM itself works, it probably does not need to be referenced normatively.
[17:48:08] <axelm> should it update RFC3761bis?
[17:48:15] <axelm> "no" suggested.
[17:48:32] <axelm> peter koch: administrative stuff should be discussed elsewehre.
[17:48:37] --- TomTaylor has joined
[17:49:16] --- healthyao2000 has joined
[17:49:45] <axelm> add text about experimental service? yes suggested.
[17:50:01] <axelm> add text about extending existing ENUM services?
[17:50:33] <axelm> finally: what is the IANA impact?
[17:51:58] --- shinta has left
[17:52:12] --- jmce has joined
[17:52:32] <axelm> jon: there are a lot confusing things about ENUM services.
[17:52:59] <axelm> jon: there would be guidance appreciated about how to define Enumservices.
[17:53:09] --- hpditt has left
[17:53:20] <axelm> shockey: do you want to solve the "void" problem in this doc?
[17:54:02] <axelm> jon: not talking about "void" here, but would like to capture the experience of the last Enumservices (lot of Enumservices proposing http...)
[17:56:18] <axelm> Ed guy talks about IAX Enumservice.
[17:56:43] <axelm> IAX itself is going into expert review in the next few weeks.
[17:57:07] <axelm> meeting concludes.
[17:57:08] --- andrewsullivan has left
[17:57:10] --- lemmakin has left
[17:57:20] --- raj has left
[17:57:35] --- pk has left
[17:57:41] --- hotta has left
[17:57:44] --- no8 has left
[17:57:49] --- patrik has left
[17:57:50] --- TomTaylor has left
[17:57:55] --- agallant has left
[17:58:00] --- klensin has left
[17:58:17] --- healthyao2000 has left
[17:58:22] --- ysuzuki345 has left
[17:58:23] --- rwatro has left
[17:58:44] --- mah has left
[17:58:50] --- msj has left
[17:59:11] --- irino has left
[17:59:17] --- axelm has left
[17:59:40] --- ja has left
[18:00:27] --- bnsmith has left
[18:01:02] --- irino has joined
[18:01:33] --- irino has left
[18:01:56] --- jun_koshiko has left
[18:02:11] --- jmce has left
[18:03:47] --- joshlitt has left
[18:04:01] --- miki has left: Replaced by new connection
[18:04:09] --- jun_koshiko has joined
[18:05:36] --- miki has joined
[18:06:22] --- xiaodong has left
[18:07:00] --- jun_koshiko has left
[18:07:12] --- AdamUzelac has left
[18:07:13] --- AdamUzelac has joined
[18:09:59] --- enrico has left
[18:11:37] --- richard.barnes has left
[18:15:32] --- alfredprasad has left
[18:16:19] --- otmar has left
[18:24:08] --- alfredprasad has joined
[18:24:45] --- Antoin has left
[18:26:06] --- hpditt has joined
[18:26:50] --- miki has left
[18:28:20] --- alfredprasad has left
[18:28:46] --- hpditt has left
[18:29:46] --- irino has joined
[18:31:39] --- irino has left: Replaced by new connection
[18:47:02] --- fujiwara has left
[19:03:05] --- mo7sen has left
[19:27:27] --- jis has left
[19:57:24] --- bhoeneis has left
[20:56:26] --- raj has joined
[20:56:43] --- raj has left
[21:11:44] --- AdamUzelac has left
[21:17:29] --- jpope has joined
[21:18:20] <jpope> test ... 123
[21:19:52] --- jpope has left