[08:23:56] --- spencerdawkins has joined
[08:24:03] --- spencerdawkins has left
[08:27:28] --- agallant has joined
[08:28:40] --- agallant has left
[08:30:43] --- agallant has joined
[08:30:51] --- agallant has left
[08:37:38] --- agallant has joined
[08:37:42] --- agallant has left
[08:43:52] --- agallant has joined
[08:44:03] --- agallant has left
[08:48:34] --- spencerdawkins has joined
[08:48:40] --- spencerdawkins has left
[08:50:31] --- agallant has joined
[08:50:42] --- agallant has left
[08:53:07] --- yone has joined
[08:56:09] --- patrik has joined
[08:57:38] --- agallant has joined
[09:00:28] --- spencerdawkins has joined
[09:01:00] <spencerdawkins> OK, I can jabber scribe (at least we are here)
[09:01:10] <agallant> Yay!
[09:01:19] <spencerdawkins> audio not working :-(
[09:01:50] --- dyork has joined
[09:02:00] --- pk has joined
[09:02:10] --- jad has joined
[09:02:22] --- olaf@jabber.secret-wg.org has joined
[09:02:23] --- fujiwara has joined
[09:02:25] <spencerdawkins> final agenda on working group list last week - any bashing? none noted
[09:02:40] <spencerdawkins> Review of drafts
[09:02:50] <agallant> still no audio
[09:03:43] <spencerdawkins> Alex speaking (when we start speaking)
[09:04:08] --- xiaodong has joined
[09:04:15] <spencerdawkins> Have published several RFCs (nine?) since last IETF, with more in queue
[09:05:34] <spencerdawkins> VOID is revised ID needed (DISCUSS is from Allison)
[09:05:43] --- Jelte has joined
[09:05:52] --- dyork is now known as danyork
[09:06:05] --- ogud has joined
[09:06:06] <spencerdawkins> PSTN has two small DISCUSSes (IANA and Gen-ART)
[09:06:15] <Jelte> The ietf jabber instructions page still says to use rooms.jabber.ietf.org
[09:06:34] <spencerdawkins> ARCH has new version addressing AD comments
[09:06:46] <patrik> Yeah, but that doesn't work. I get some jabber error, and have no time NOW to look at what is (not) happening.
[09:07:05] <spencerdawkins> IAX waitng for IAX2 scheme?
[09:07:26] <danyork> Jelte: yes, that confused me as well. Thank you to the speakers for saying what the address was.
[09:07:33] <spencerdawkins> EDNS0 - DNSOP doesn't care, do it here?
[09:08:06] <spencerdawkins> IPTEL-TEL-ENUMDI in AD followup
[09:08:32] <spencerdawkins> Peter - DNSOP does care, just not doing the work there
[09:08:41] <spencerdawkins> Richard Shockey
[09:09:10] <spencerdawkins> Would like to move EDNS0 forward, other SDOs (Cablelabs) looking at this work for inclusion in their standards
[09:09:38] --- marcos.sanz has joined
[09:09:45] <spencerdawkins> Will take EDNS0 and Experiences documents and move quickly to last call?
[09:09:52] <agallant> audio works
[09:10:00] <patrik> Good!
[09:10:10] <agallant> thanks!
[09:10:15] <spencerdawkins> EDNS0 hum - take document
[09:10:59] <spencerdawkins> EXPERIENCES hum - balance seemed to take, but there are objections
[09:11:59] <spencerdawkins> Peter - EDNS0 in much better shape. EXPERIENCES had editorial changes but still changes the interpretation of the standard (even though it says it doesn't) - this is completely confusing.
[09:12:23] <spencerdawkins> Recommendations don't belong in this draft
[09:12:40] <spencerdawkins> Cleanup work belongs in separate draft.
[09:13:08] <spencerdawkins> Need to know what issues are resolved in 3761bis? Yes
[09:13:08] --- sakuma.macx has joined
[09:13:52] <spencerdawkins> don't want to give people INFO that updates STD-track document
[09:14:34] <spencerdawkins> Richard Stasney - EXPERIENCE was always interim step, think questions are necessary to move forward
[09:14:54] <spencerdawkins> Shockey - people are trying to deploy resolving these problems now.
[09:16:22] <spencerdawkins> Shockey asking for opinions from Livingood (none), Peterson (thought we were doing tactical drafts that update 3761 - was that not the plan?)
[09:16:59] --- bhoeneis has joined
[09:17:58] <spencerdawkins> Jon sees two avenues besides 3761bis
[09:18:39] --- frodek has joined
[09:18:58] <spencerdawkins> some things go into EXPERIMENTs but small incremental updates can be individual documents
[09:19:38] <spencerdawkins> don't think we have consensus to move forward adopting EXPERIENCE (sorry, said EXPERIMENTs in previous line, but was mistake)
[09:19:53] <spencerdawkins> specific issues beyond what's appeared on the list?
[09:20:23] <spencerdawkins> no, just 05 updates didn't address previous issues
[09:21:39] <spencerdawkins> Peter thinks saying what problems have been encountered is different from proposing solutions
[09:22:01] <spencerdawkins> shockey - ready to consider adopting new drafts
[09:22:23] <spencerdawkins> IANA registrations, IM, Calendaring, ???
[09:22:27] --- geoff has joined
[09:22:59] <spencerdawkins> Humm on VCARD - move forward
[09:23:28] <spencerdawkins> Hum on IM - not many opinions
[09:24:44] <spencerdawkins> Peterson - hums are weak, what does this mean?
[09:25:03] <spencerdawkins> registrations are just one more step, not controversial
[09:25:23] <spencerdawkins> have draft on this process forthcoming
[09:27:12] <spencerdawkins> calendaring hum - adopt
[09:27:28] <spencerdawkins> ??? hum - ready
[09:27:46] <spencerdawkins> template presentation -
[09:27:57] <bhoeneis> last hum was for validation-token
[09:28:06] <spencerdawkins> thanks!
[09:28:13] <bhoeneis> in favour of moving it forward to WG last call
[09:28:16] <spencerdawkins> I missed it BOTH times it was mentioned
[09:29:51] <spencerdawkins> discussed at last IETF, recently revved to 01. Will publish 02 for WGLC - need IANA considerations text, have none suggested now
[09:30:09] --- ogud has left
[09:30:13] <spencerdawkins> think consensus is that SUBTYPEs are OPTIONAL, not mandatory
[09:30:43] --- robertml has joined
[09:30:52] --- ogud has joined
[09:31:57] <spencerdawkins> Peter - document could use a "DNS considerations" section, would have helped VOID which proposes "DNS tricks", should not go unnoticed
[09:32:21] --- ogud has left
[09:32:24] <spencerdawkins> Would like this in the template (not necessarily in the defining document)
[09:33:00] <spencerdawkins> Jon for Richard Shockey - alternative registration process?
[09:33:20] <spencerdawkins> Richard Shockey - issue is what is proper IANA approval after ENUM shuts down
[09:33:34] --- ogud has joined
[09:34:48] <spencerdawkins> Jon - not a bad thing to consider, some models already exist (URI list, MIME types list, expert reviewers pool, AVT has existed forever and mostly does registrations)
[09:35:13] <spencerdawkins> Jon - this is question for the group
[09:36:00] <spencerdawkins> Jon - has no objection to ENUM being in existence for next ten years
[09:36:39] <spencerdawkins> Jon - thought there was going to be text on guidance about what registrations are/are not reasonable - still going to happen?
[09:38:54] <spencerdawkins> Jon - not sure we can plan WGLC if we haven't even discussed this yet
[09:39:57] <spencerdawkins> Patrik - many ways forward, including expert review - don't need to decide this now
[09:40:54] <spencerdawkins> Does Jon think we need to decide immediately? No, no problems immediately. Publication of deterministic rules would make your job simpler, though.
[09:41:10] --- dudi has joined
[09:43:46] <spencerdawkins> Richard Stasney - Infrastructure ENUM
[09:44:12] <spencerdawkins> Issue is private ENUMs - major disadvantage is that one never gets access to all numbers
[09:44:18] <agallant> http://www3.ietf.org/proceedings/06jul/slides/enum-1.ppt?
[09:44:30] <spencerdawkins> "provide a hint?"
[09:45:16] <spencerdawkins> would increase hit rate, would find out with one query in ie164.arpa to find if both are in the same group.
[09:45:52] <spencerdawkins> agallent - yes, exactly
[09:46:44] <spencerdawkins> can be done easily with NAPTR record with unique name of private ENUM space.
[09:46:59] <spencerdawkins> draft also proposes using URN instead of HTTP
[09:47:28] <spencerdawkins> optional thing but may help performance/hit rate
[09:48:17] <spencerdawkins> Dave Oran - requirements slide? is there general agreement to these requirements/motivation? Does this represent a requirement to be met?
[09:49:06] <spencerdawkins> David Schwartz - solves real-world problem - don't want to make lots of hits to routing, want to reduce number of queries. What do you do when you get more than one answer?
[09:49:20] <spencerdawkins> Richard Stasney - decision is with originator
[09:49:42] <spencerdawkins> Solves realworld problem, would like to see DNS URI
[09:50:24] <spencerdawkins> Dave Oran - who was around for X.500? This is like NSSAs all over again. Google is going to crawl these anyway.
[09:51:00] <spencerdawkins> Richard Stasny - agree, but operators don't want this to happen. Ridiculous but it is a fact.
[09:51:21] <spencerdawkins> Speermint is working on federations
[09:51:51] <spencerdawkins> Richard Stasny - didn't use federations in document because it's a different way to decide about peering
[09:51:59] <spencerdawkins> trying to keep this separate for now
[09:52:58] <spencerdawkins> Richard Shockey - why use DNS if we don't have to? and not publishing numbers is totally bogus, because these are disclosed to regulators anyway
[09:53:04] <robertml> for the logs, it was Andy Newton who would like to see the DNS URI.
[09:53:10] <spencerdawkins> -- but this is US-only
[09:53:19] <spencerdawkins> robertml - thanks!
[09:53:56] <spencerdawkins> not sure if I agree with requirements on this slide, but this may be because operators don't understand what solutions are possible
[09:54:30] <spencerdawkins> fully agree that ENUM is available through search engines today -
[09:54:45] <spencerdawkins> Richard stasney - problem is that operators are stupid
[09:55:00] <spencerdawkins> we need more education, but it's not stupidity
[09:55:25] <spencerdawkins> we're talking about endpoint privacy...
[09:55:47] <spencerdawkins> patrik - some discussion isn't about this draft, but about INFRAstructure requirements document
[09:56:07] <spencerdawkins> this document is one solution, shouldn't beat up richard on requirements
[09:56:27] --- jft has joined
[09:56:29] <spencerdawkins> richard shockey - we are not obligated to fix "stupid" - in requirements document
[09:56:51] <spencerdawkins> patrik - is requirements document good enough to use in evaluating this draft?
[09:57:22] <spencerdawkins> Richard shockey - are problems in this document that are not in requirements document? no response
[09:57:39] <spencerdawkins> do we need to go back to requirements document and deal with these specific issues?
[09:57:57] <spencerdawkins> requirement about effectiveness of resolution is missing
[09:58:41] --- jft has left
[09:59:36] --- nm has joined
[09:59:37] <spencerdawkins> Patrik - we had consensus at last two IETFs on requirements document, and now we have issues?
[09:59:55] --- nm has left
[10:00:35] <spencerdawkins> jon - have gotten documents at IESG before that had WG concerns later...
[10:01:03] <spencerdawkins> can set document aside if you need me to, can still call attention to work after setting aside
[10:01:24] <spencerdawkins> patrik - people are trying to do stuff now, can't stall on requirements forever
[10:01:39] --- dudi has left
[10:01:55] <spencerdawkins> jason - we are losing time her
[10:01:59] <spencerdawkins> "here"
[10:03:26] <spencerdawkins> make sure we solve the problem, don't worry about stupid
[10:04:01] <spencerdawkins> David Schartz - lots of service providers don't want open communications, scared of SPIT, etc.
[10:04:23] <spencerdawkins> Patrik - are your requirements covered in the requirements document? clearly not
[10:06:18] <spencerdawkins> Dave Oran - I have no problem with requirements, just don't see how this is covered by requirements
[10:06:57] <spencerdawkins> see problems this approach raises (several listed) - but not in requirements
[10:07:20] <spencerdawkins> do people think these missing requirements are part of missing infrastructure requirements?
[10:08:44] --- jad has left
[10:08:52] <spencerdawkins> humm on pulling requirements document is very quiet
[10:09:02] <spencerdawkins> really scares Patrik
[10:09:44] <spencerdawkins> we have like three people who are expressing an opinion?
[10:11:18] <spencerdawkins> patrik - want names of five people who will read requirements document this week (I'm not trying to capture them here, WG chairs got them and scribe)
[10:12:02] --- enrico has joined
[10:14:01] <spencerdawkins> we actually have seven volunteers - will meet with Alex at end of meeting
[10:17:16] <spencerdawkins> Michael Habertler - revised Carrier ENUM ID
[10:17:30] <spencerdawkins> "states interim all over the place"
[10:17:52] <spencerdawkins> requirements moved, branch location, apex moved out
[10:18:19] <spencerdawkins> "sample" implementation now used by 9 service providers in +3 work
[10:18:43] <spencerdawkins> "in +43 work" - austria trial
[10:19:13] <spencerdawkins> adopt carrier-enum-03 humm - adopt
[10:19:35] <spencerdawkins> branch location humm - adopt (but weaker)
[10:20:09] <spencerdawkins> Patrik - but opening requirements document may affect this
[10:22:33] <spencerdawkins> INFRASTRUCTURE ENUM ROOT?
[10:22:52] <spencerdawkins> choosing ie164.arpa - most of the discussion was about this
[10:23:33] <spencerdawkins> will add Richard Stastny's text in Security and Privacy Considerations section.
[10:24:20] <spencerdawkins> jonathan rosenberg - glad to see this, one suggestion - different ENUM service record type needed? would constrain opt-in
[10:25:44] <spencerdawkins> Dave Oran - if anyone exposes their call log, the cat is out of the bag for web crawlers
[10:26:20] <spencerdawkins> david schwartz - people already using SRV records today, think I agree with provider.example domain.
[10:26:55] <spencerdawkins> Richard Shockey - would need new enumservices registration - but we have a cool template, so that's not as big a deal
[10:27:16] <spencerdawkins> Richard Stastny - not sure how this affects variable length number problem
[10:28:12] <spencerdawkins> Infrastructure is mostly for SIP providers but we shouldn't exclude other URI types
[10:32:17] <spencerdawkins> we are way ahead of schedule, now talking about 3761 going to draft standard
[10:32:17] --- danyork has left: Lost connection
[10:32:17] --- sakuma.macx has left: Lost connection
[10:32:17] --- fujiwara has left: Lost connection
[10:32:17] --- bhoeneis has left: Lost connection
[10:32:21] --- ogud has left
[10:32:22] --- spencerdawkins has left
[10:32:51] --- yone has left
[10:34:08] --- yone has joined
[10:34:54] --- nm has joined
[10:36:10] --- miki has joined
[10:37:04] --- olaf@jabber.secret-wg.org has left: Logged out
[10:39:52] <geoff> test [IGNORE]
[10:41:24] --- robertml has left
[10:49:20] --- yone has left
[10:51:22] --- Jelte has left: Logged out
[10:58:23] --- yone has joined
[10:58:50] --- sakuma.macx has joined
[10:59:18] --- spencerdawkins has joined
[10:59:37] <spencerdawkins> sorry, got kicked off and had to reboot
[10:59:45] --- fujiwara has joined
[10:59:58] <spencerdawkins> Now at slide 12 of Patrik's presentation on ENUM Next Generation
[11:00:20] <spencerdawkins> proposal would replace NAPTR with URI records
[11:00:37] --- danyork has joined
[11:00:58] --- marcos.sanz has left
[11:01:02] --- marcos.sanz has joined
[11:01:03] --- bhoeneis has joined
[11:01:09] <spencerdawkins> Richard Shockey - proposal would encourage use of neutral third-party registries (and yes, we know about the conflict of interest here)
[11:03:39] <spencerdawkins> Patrik - to have nameservers hosting .dk zones you must be registered in the registry - may see more of these
[11:06:10] --- patrik has left
[11:06:17] --- marcos.sanz has left
[11:06:24] --- fujiwara has left: Logged out
[11:07:03] --- agallant has left
[11:07:03] --- yone has left
[11:07:11] --- frodek has left
[11:07:14] <spencerdawkins> adjourned early
[11:07:24] --- miki has left
[11:07:35] --- enrico has left
[11:11:35] --- spencerdawkins has left
[11:12:57] --- pk has left: Computer went to sleep
[11:19:35] --- bkhabs@jabber.org has joined
[11:21:37] --- bkhabs@jabber.org has left
[11:22:15] --- spencerdawkins has joined
[11:25:13] --- bhoeneis has left
[11:28:15] --- geoff has left
[11:29:22] --- nm has left: Replaced by new connection
[11:29:22] --- nm has joined
[11:29:22] --- nm has left
[11:29:36] --- sakuma.macx has left
[11:29:57] --- danyork has left
[11:30:24] --- xiaodong has left
[11:30:59] --- spencerdawkins has left
[12:46:09] --- danyork has joined
[12:46:17] --- danyork has left
[12:50:34] --- isudo has joined
[12:51:06] --- isudo has left
[13:16:14] --- spencerdawkins has joined
[13:19:30] --- patrik has joined
[13:19:43] --- patrik has left
[14:02:43] --- spencerdawkins has left
[17:38:54] --- isudo has joined
[17:40:23] --- isudo has left
[19:00:30] --- LOGGING STARTED
[20:06:15] --- isudo has joined
[20:07:13] --- isudo has left