[07:49:00] --- mrose has become available
[07:49:00] --- randy has left: Lost connection
[07:50:04] --- warlord has become available
[07:54:07] --- fenton has become available
[07:55:38] --- warlord has left: Disconnected
[07:55:55] --- Jim Galvin has become available
[07:56:13] --- Glenn Parsons has become available
[07:56:24] --- tonyhansen has become available
[07:57:10] --- yone has become available
[07:58:16] --- ggm has become available
[07:58:32] --- leifj has become available
[07:59:22] <ggm> ggm is insane enough to jabberscribe
[07:59:43] --- ludomp has become available
[08:00:02] --- becarpenter has become available
[08:00:14] <ggm> agenda: WG/BOF status (10m) New WG/BOFs (40m) Charter updates (20m) Cross Area Tech Topix (20m) Open Mike (1h or to close)
[08:00:31] <ggm> more stuff to come in open mike.
[08:00:37] <ggm> WG/BOF status.
[08:01:06] <ggm> closed: CALSH, IMPP, IPP, MARID, MSGTRK, XMPP. mostly closed for charter completion. some with malice [laughter]
[08:01:37] <ggm> new: SIEVE, BoF this week,being run as active WG already. IESG telechat for approval coming up.
[08:01:38] --- warlord has become available
[08:01:48] --- hartmans has become available
[08:01:50] <ggm> Charter updates: OPES. (will be on agenda)
[08:02:10] <ggm> interesting things this week. Kitten (GSSAPI update). security focus
[08:02:57] <ggm> Almost BOFs: PERM, MASS, RFID. PERM/MASS met in S.D. scheduled to meet this week, pulled out when not ready enough. try again,
[08:03:11] <ggm> CALSIFY is also on list.
[08:03:49] <ggm> RFID, about reader protocol. no drafts, vague ideas, some conflicts with other standards bodies. pushed back. maybe meet as bof next time.
[08:04:22] <ggm> Crocker: list CLEAR. combo of CSV from MARID, stuff not a good fit in MASS.
[08:04:40] <ggm> [speaker is Scott Hollenbeek btw]
[08:04:44] <ggm> New WGs.
[08:05:01] <ggm> Sieve, Mail filtering . proposed chairs are cyrus, alexey.
[08:05:15] <ggm> IDN with EPP, IDNPROV. Edmon, Howard to chair
[08:05:27] <ggm> Charter Updates.
[08:06:45] <ggm> OPES. Tony (new co-chair) to talk.
[08:08:30] <ggm> chartered originally in 2002, framework for callout services via standard mechanism. focus on HTTP (eg web cache calling out to virus scanner)
[08:08:49] --- resnick has become available
[08:09:37] <ggm> 7 RFCs published. based on OCP core, agnostic on protocols, app profiles specify how to deal with (HTTP, FTP, RTP, SMTP...)
[08:10:18] <ggm> Dave Crocker asks tricky question about layering/profiles.
[08:10:23] <ggm> Experience with HTTP?
[08:10:30] <ggm> Tony: webcasters using it. can't answer in detail
[08:10:37] <ggm> Proposed re-charter:
[08:11:27] <ggm> stable after discussions, focussed, narrow. similar work to HTTP protocols, servers, but for SMTP.
[08:12:04] <ggm> doing scenarios, use-cases. discussing 'rules language', relationship with SIEVE
[08:12:39] <ggm> example use case is to make virus scanner from web cache now also available as callout service to mail via SMTP
[08:12:53] --- brabson has become available
[08:14:40] <ggm> Pete Resnick: pragmatic question. Do folks in eg sendmail camp want to use this?
[08:14:46] <ggm> [yes]
[08:15:04] <ggm> Pete so at least some folks want to write to this as an API/Protocol.
[08:15:07] --- mrose has left
[08:15:18] --- yushunwa has become available
[08:16:30] <ggm> Yes. people have investments offsite, want to shove different things to it eg centralized virus scanning. firewalls do this.
[08:16:31] --- randy has become available
[08:17:08] --- ray_atarashi has become available
[08:17:56] <ggm> reference to 3238. big discussion in chartering, could be used for nasty things like censorware. is using virus scanning just polite window-dressing?
[08:17:59] --- brabson has left: Disconnected
[08:18:09] <ggm> discussion says yes, and then again no.
[08:18:34] <ggm> [nobody is saying who they are, so a bunch of stuff is unattributed. sorry. -ggm]
[08:18:59] --- ray_atarashi has left
[08:19:47] <ggm> Done.
[08:20:07] --- ray_atarashi has become available
[08:20:43] --- resnick has left
[08:20:48] <ggm> Cyrus on SIEVE (co chair)
[08:20:50] --- resnick has become available
[08:21:08] <ggm> ad-hoc, non WG mode, but produced several RFCs. extensions, 8-10 drafts 'out there' need to progress.
[08:21:24] <ggm> main goal, take SIEVE to DS. look at revising base spec in light of bugs, no major changes
[08:21:58] <ggm> [end]
[08:22:34] --- brabson has become available
[08:22:53] <ggm> Edmond on IDN/EPP. now IDNs starting to be deployed, need domain registration support.
[08:23:51] <ggm> so this addresses client to registry processes
[08:26:14] --- brabson has left: Disconnected
[08:26:38] <ggm> Hoffman: you need to consider stds track doc to cover changes to EPP. normative pointing to non-stds .. problem
[08:27:48] <ggm> Edmon need to specify way to pass IDN critical data.
[08:28:20] <ggm> Ted: eg particular registry may just not do this, but may ignore tags passed in. Hope we're aiming for different XML objects, extension objects
[08:29:02] --- kivinen has become available
[08:29:02] --- warlord has left: Lost connection
[08:29:06] <ggm> Klensin: good to do this properly
[08:29:06] --- hartmans has left: Lost connection
[08:29:09] --- leifj has left
[08:29:33] --- amelnikov has become available
[08:30:16] <ggm> Erik Nordmark on Multi6 app referral. draft is findable on the -nordmark- string I guess (he took the URL off before I got there)
[08:30:55] <resnick> draft-nordmark-multi6dt-refer-00.txt
[08:32:02] <ggm> talks about background, scaleable V6 site multihoming goals -keep the socket API stable. looking at L3 shim. app issues are not approach specific
[08:32:14] --- warlord has become available
[08:33:45] --- resnick has left: Disconnected
[08:34:33] <ggm> solution space may include 'do nothing' -worrying at connection establishment, (transp proto, apps figure out set of addresses) -multiple locators, sublayer in stack to make transp. survivable, introducing new id namespace with distributed mapping system to locators
[08:35:14] --- resnick has become available
[08:35:15] <ggm> implications.
[08:36:04] <ggm> apps have to see a 128 bit value. trying to distinguish from locators, can be multiple locators. can be one of them, or something not reachable. not central to discussion.
[08:36:28] <ggm> key issue is how to deal with this thing, not its routing behaviour.
[08:36:46] <ggm> sockets API, need something 'new' in the stack to map to locators
[08:36:58] <ggm> likely outcomes
[08:37:39] <ggm> defining namespaces, deploy takes time. can use DNS, AAAA/PTR recs. imply hierarchical allocation. thats what DNS admin deals with.
[08:37:54] <ggm> hard to get consensus this is THE way to do multihoming.
[08:38:25] <ggm> short to medium term, multiple locators without new ID namespace is likely. -people want a free lunch
[08:38:54] <ggm> good news: no changes to apps which use IP addr as 'short term' handle.
[08:39:08] <ggm> take getaddrinfo() and pass to connect() or sendto()
[08:39:42] <ggm> other apps usages. -retaining handles for longterm use, callback features, referral via 3rd parties, ID comparison
[08:40:55] <ggm> issues already, not secure, already using 'higher level' identifiers
[08:41:19] <ggm> approaches:
[08:41:40] <ggm> use FQDN wherever possible. at least get lookup abstraction. not always appropriate.
[08:41:45] --- cnewman has become available
[08:42:39] <ggm> can use single IP address. still works but has no redundency benefits
[08:42:58] <ggm> apps may have to hold/store sets of locators, ULID/identifiers, deal directly
[08:43:06] <ggm> Issues (seeking feedback)
[08:43:24] <ggm> 'just use FQDNs' ?
[08:43:36] <ggm> URI form?
[08:45:08] <ggm> hard to get accurate FQDN. PTR lookups often wrong.
[08:45:58] <ggm> Ted: from app perspective, what are the advantages of multihoming? money benefits to org (use cheapest link, failover) real benefits to org, but from app perspective, if no difference between identifiers, both reachable, speed/quality the same, shouldn't care which one I use
[08:46:36] <ggm> looking for here, how is the app going to know not just there are multiple locaters, but how to exploit them
[08:48:24] <ggm> Brian C. cochair Multi6. analogy to problems already have. if have 4 and 6 address for FQDN, which to use? already have this problem.
[08:48:52] <ggm> whatever you do is wrong. send FQDN to other people, may not resolve correctly. send one of the locaters, may not be best at the other end.
[08:49:49] <ggm> current apps do bad job of dealing with this.
[08:50:14] <ggm> Erik. if app going to deal with this, need API.
[08:51:02] <ggm> Dave Crocker. spent energy on this both for multi-homing, mobility.
[08:51:26] <ggm> not at all clear, what problem being solved for applications. applications are consumer of this. not sure folks working on this have basis for making decisions
[08:52:36] <ggm> Erik: yes, its a problem.
[08:52:45] <ggm> Dave want to highlight problem
[08:52:59] --- amarine has become available
[08:53:31] --- jaltman has become available
[08:54:12] <ggm> [unnamed person] solve at connect setup time, higher level API needed. 'connect by name' abstraction needed all the time, to get away from transport choices.
[08:55:03] <ggm> Erik middleware has this kind of thing already
[08:55:25] <ggm> [unnamed person] SCTP has one approach. session can persist
[08:55:54] --- kivinen has left
[08:58:42] <ggm> Ted. wondering if fundamental presumtion, if reachable to eg randy via qualcomm VPN, then cannot ever refer to this to outside, since not workable in global net. knowing reachability, hard. apps need to know. not all equivalent. have to iterate, not select (may pick wrong one)
[08:59:38] <cnewman> [unnamed person] = me (Chris Newman)
[08:59:39] <ggm> Erik eg globally unique v6 addrs, but not globally reachable. host can look at upper bits.
[09:01:10] <ggm> [another unnamed person] who does the iteration to determine locator to use.
[09:02:28] <ggm> at least 3 different solutions being considered, considering contradictory requirements. going to need to make tradeoffs/decisions.
[09:03:02] <ggm> William Liebzon. highlight diff multi6/HIP people work. differences layerwise, for apps.
[09:03:03] <fenton> Last unnamed person was Eliot Lear
[09:04:03] <ggm> Erik. using 128 non-reachable 'upper layer identifiers' statistically unique, make them up on the fly if you like. thats one aspect of HIP.
[09:04:14] --- Glenn Parsons has left: Disconnected
[09:04:22] <ggm> lookup service to submit one, ask 'tell me about its locators'
[09:04:39] <ggm> HIP has protocols to do exchanges, security, lookup service on flat space of hashes of public keys is challenging.
[09:04:54] <ggm> William. both trying to create 128bit locater, 'virtual IP address' to pass to app
[09:05:57] <ggm> Erik yes, HIP+lookup service if/when do this, don't have to worrry about set of locaters. promotes transparency, done by underneath layers. even if try doing this, will take long time to get there, scaling issues. even if HIP gets deployed on large scale need to deal with passing lists of locaters, in addition to HIP id.
[09:06:10] <ggm> William. app keeps address, is that how you want it?
[09:06:17] <ggm> Erik take offline
[09:06:51] <ggm> [yet another unnamed person] brian c said something striking. already multihomed, if 4 and 6. scope has to include case of single i/f but with 2 bindings
[09:07:13] <ggm> Erik in abstract yes, thats the case
[09:07:17] <tonyhansen> [unnamed => larry masinter]
[09:09:19] <ggm> [pekka nickander] workshop saturday on HIP, related architectures. came to conclusion, value to add layer to IP stack, lowest layer with location independent id's. HIP doing that, but also doing more. since HIP doing more, value to have two protocols, analogous to TCP and UDP split. one can be HIP providing eg also security, but also maybe something else, multi6? works without external infrastructure, security. these were wkshop conclusions
[09:09:32] <ggm> Christian Huitema. amazed when new proposal 'makes things simpler'
[09:09:52] <ggm> really, when make something new, have to handle new AND old. doesn't make simpler
[09:09:56] <ggm> Erik agree. doesn't make simpler
[09:10:49] <ggm> Christian been looking at this a lot in Microsoft. some things use higher level APIs. don't care. some which do care, already handle eg IM, Mail apps don't see value in this, making things too complex.
[09:10:56] --- hartmans has become available
[09:11:01] <ggm> Erik don't see value in multi6? thats a discussion for multi6.
[09:11:17] <ggm> Christian, but applications people write their own shim layers.
[09:11:29] <ggm> Erik but is it valuable to apps not to have things break?
[09:11:50] <ggm> Christian have to be backwards compat, have to support breakage anyway.
[09:11:57] <ggm> Eliot in short term, transition issue
[09:12:03] <ggm> Chrisitian short term not short.
[09:12:23] <ggm> John Klensin. wish to avoid 'death of internet' but this is one of them.
[09:12:45] <ggm> hourglass model got us to where we are. magic happens 'down in other side of narrow waist of hourglass'
[09:13:50] <ggm> following on christian, move into world, tell app 'need to understand topology, different modes, ways to get out' then we will kill the important thing. in process, will do something else. suggest multi6, including successor AD directors need to think about carefully. way moving, selling V6, multihoming
[09:14:39] <ggm> if end up giving away multihoming, nets, smaller than PI space from registries will kill v6. few real motivations other than running out of address spaces, believe have already run out in some sense. telling apps to know topology of net, kills the goal.
[09:14:50] <ggm> Erik just want to carry variable length sets of things, not fixed things
[09:15:13] <ggm> John fine, HIP does that, but having to get into business of what they mean, how to manipulate, subtext of number of proposals, deadly.
[09:16:04] <ggm> Pete Resnick. to disagree with Christian, yes, lots of apps work around persistent connects with own shim. lots fail and expect user to start over. continue to be lots of those app layer protocols. this makes life easier for upper layer so long as johns warnings heeded. 'thing to pass to get to endpoint, don't worry about dots"
[09:16:10] <ggm> Ted thanks to Erik [applause]
[09:16:12] --- brabson has become available
[09:16:39] <ggm> tomorrow, 9am, this room, second session wednesday
[09:17:12] <ggm> Scott does blue sheet fascism
[09:17:15] <ggm> please send presentation materials to Scott H to get into proceedings
[09:17:21] <ggm> Open Mike.
[09:18:15] <ggm> Chris Newman draft on 'comparator' in i8n. do once, not every app doing different approaches. came out of IMAP-EXT, sort/thread. want to generalize
[09:18:40] <ggm> eg use in SIEVE, WEBDAV, w3c protocols
[09:19:00] <ggm> seeking review from community, naming conventions. looking for volunteer from SIEVE/WEBDAV communities to do detailed reviews, make sure useful
[09:19:22] <ggm> Juta? puts hand up from SIEVE.
[09:19:46] <ggm> could be useful offline, cache information, label collation, implementation in client matching label, can use offline.
[09:20:06] <ggm> [yet another unnamed person] I'll read it.
[09:20:35] <ggm> Scott. doing i8n comparisons, not addressing topic, going to point to this.
[09:20:47] <ggm> [q] chines/taiwanese comparators?
[09:21:03] <ggm> John K remind me, I will get into this can of worms
[09:21:24] <ggm> idea is to keep abstraction, refer to UNICODE/ISO stuff
[09:21:27] <resnick> (I think he offered to find people to get into this can of worms. ;)
[09:22:36] <ggm> John K. have problem with email addresses. want names LHS to be IDN. (in LHS@RHS) efforts to do this got lost in the weeds.
[09:24:15] <ggm> from standpoint of more extreme ends of i8n community, the differering chinese stuff, wg process was too chaotic, s/n noise bad, deterministic pronouncements from people with opinions but no knowledge too high. to avoid that problem, do something more focussed, with people with expertiese., Paul Hoffman started ML process to get proposal to IETF. seemed to work for while, but also collapsed due to differences on how to do this. same people couldn't partiicpate for similar problems which killed IDN.
[09:25:14] <ggm> in process of thrashing, looking for quick/good fix to exit. not finding any. but community is going to move to non-interop proposals of their own. either inside or outside of IETF
[09:26:21] <ggm> r[?Larry Masinter? ] report on URI revision issues. v6 link local addresses, going to spin off separate draft
[09:28:13] <ggm> drafts being proposed, Paul H simpler, radically different. want discussion. schemes from 1738, URI schemes seeking to obsolete the document, 6-7 drafts on schemes, in different states of discussion. would benefit from review. discussion on updating mailto: for i8n
[09:28:34] <ggm> all drafts individual submissions. draft hoffman, draft hansen. need webpage to point to them.
[09:28:40] <ggm> [?] implementation survey?
[09:29:26] <ggm> larry discussion on URI list generally from people with experience. eg found ftp: URI not following draft
[09:30:21] <ggm> Paul Hoffman. apps area list active enough to use?
[09:30:35] <ggm> is there apps area web page? better holder of gang of URIs for a while?
[09:31:56] <ggm> Scott. me? apps ML for discussion. need to promote. Ted and I are in some discussions about website
[09:32:33] <ggm> Larry; take individ. submissions being watched by AD, or think are subject to IETF review but not in WG, list them there.
[09:32:43] <ggm> Paull H I will send mail about URI schemes.
[09:32:50] <ggm> Scott its moderated list.
[09:33:00] --- brabson has left
[09:33:02] --- resnick has left: Disconnected
[09:33:05] <ggm> Scott no more to talk about? Blue sheets
[09:33:12] <ggm> done.
[09:33:27] --- ray_atarashi has left
[09:35:05] --- fenton has left
[09:35:06] --- randy has left: Disconnected
[09:35:44] --- amelnikov has left
[09:35:58] --- ludomp has left
[09:36:16] --- amarine has left
[09:36:32] --- randy has become available
[09:38:10] --- jaltman has left
[09:41:48] --- Jim Galvin has left
[09:52:05] --- cnewman has left: Disconnected
[09:55:06] --- yone has left: Disconnected
[09:55:38] --- warlord has left
[09:56:20] --- ggm has left: Disconnected
[09:56:54] --- yone has become available
[09:57:55] --- yone has left
[09:58:07] --- yone has become available
[09:58:34] --- yone has left
[10:00:46] --- yushunwa has left
[10:07:09] --- randy has left: Logged out
[10:31:20] --- hartmans has left
[10:50:23] --- becarpenter has left: Disconnected
[11:02:13] --- tonyhansen has left
[11:13:37] --- resnick has become available
[11:13:45] --- resnick has left
[11:36:32] --- jaltman has become available
[11:40:38] --- becarpenter has become available
[11:44:46] --- mrose has become available
[11:46:25] --- mrose has left
[11:53:09] --- randy has become available
[12:22:10] --- becarpenter has left
[12:35:18] --- jaltman has left: Disconnected
[15:44:39] --- randy has left
[18:44:40] --- frodek has become available
[18:44:53] --- frodek has left