[10:33:22] --- ltn22@jabber.org has joined
[11:31:01] --- ltn22@jabber.org has left: Logged out
[12:29:02] --- miaofy has joined
[12:29:07] --- miaofy has left
[12:44:06] --- sam xia has joined
[12:46:26] --- sam xia has left
[14:16:07] --- xiazhongqi has joined
[14:59:26] --- xiazhongqi has left
[15:05:35] --- mjo has joined
[15:14:57] --- jeffa has joined
[15:18:40] --- xiazhongqi has joined
[15:20:35] --- xiazhongqi has left
[15:20:51] --- sam xia has joined
[15:21:11] --- nm has joined
[15:21:57] <sam xia> 111
[15:22:01] <sam xia> test
[15:22:35] --- iljitsch has joined
[15:25:24] --- jft has joined
[15:26:53] --- narten has joined
[15:26:55] --- Bob has joined
[15:27:35] --- dudi has joined
[15:28:40] --- ggm has joined
[15:28:54] <ggm> thats "testing 1 one one one one one one"
[15:28:58] <ggm> ONE
[15:29:24] <iljitsch> Chairs are both here, scribes are found... I'll be doing the jabbering for about half the session, if you have questions that you want relayed please say so
[15:29:45] <iljitsch> hopefully someone else can then go up to the microphone because it's hard to type and walk at the same time...
[15:29:52] --- jeffa has left: Replaced by new connection
[15:29:58] <iljitsch> Anyone participating remotely?
[15:30:00] --- loughney has joined
[15:30:12] --- jeffa has joined
[15:30:14] <iljitsch> Kurtis: agenda bashing, see agenda on the mailinglist
[15:31:22] <iljitsch> Geoff: first agenda item: status of base protocol spec
[15:31:34] <iljitsch> no slides etc, have gone over this in previous meetings
[15:32:09] <iljitsch> ADs requested that 3 documents would be pushed to IESG as a set of connected documents
[15:32:44] <iljitsch> see https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=66 at "shim6" for agenda and some of the protocol slides
[15:33:12] <iljitsch> geoff: do last call for the three documents after this ietf barring any comments now
[15:33:16] <iljitsch> so no presentations on these
[15:33:54] --- miyahiro@jabber.org has joined
[15:34:00] --- rloomans has joined
[15:34:01] <iljitsch> jim bound: I object to HBA-CGA relationship for IPR headers, something about IPsec that I didn't get
[15:34:16] <iljitsch> will go to the IESG, no point in discussing it here
[15:35:13] --- narten has left
[15:35:14] <iljitsch> Jim: Ericsson says: we have patent on CGA you can use it but if you give us patent trouble we can go after you, unacceptable
[15:35:53] --- FDupont has joined
[15:36:16] <iljitsch> Geoff: not disputing this, consulted with ADs, which will follow wg advice, so it's back to the wg, anyone else have comments re the use of crypto material in the identifier part in HBA
[15:38:26] --- rloomans has left
[15:38:54] <jeffa> Iljitsch is at the mic -- HBA vs CGA IPR?
[15:40:36] --- bkhabs@jabber.org has joined
[15:41:41] --- rloomans has joined
[15:41:45] <iljitsch> Earlier: Jim wants the wg to go ahead so he can appeal and change the way things work
[15:42:10] <loughney> sorry got disconnected.
[15:42:46] --- shep has joined
[15:42:47] <loughney> Iljitsch wanted to know if the CGA IPR declaration covered HBAs or just the CGA portion of HBAs.
[15:42:56] <loughney> There was no response.
[15:42:59] <loughney> on that issue.
[15:43:00] --- bonninjm@jabber.org has joined
[15:43:08] <iljitsch> my comment: is ericsson claiming ipr on hba as well as cga? in that case we can make hba incompatible with cga and be done with it
[15:43:21] <iljitsch> general: if only life were this simple
[15:43:43] <iljitsch> didn't catch last comments
[15:44:13] <iljitsch> jim also objects against cga and says ipsec should be used there, and asserts that this isn't a problem
[15:44:35] <iljitsch> anonymous: asking wg to solve legal issues doesn't work
[15:45:07] <iljitsch> geoff: that's not the question, ADs want to see a level of comfort in the wg with proceeding with this document
[15:46:02] <iljitsch> Pekka: more general issue, experienced the same thing with Cisco, alternative to "ipr for free" is "ok, pay us something then you still get to sue"
[15:46:05] --- momose has joined
[15:46:19] <iljitsch> John Loughney: would be more comfortable if this weren't a key part of the spec
[15:46:41] <iljitsch> for success we need open source implementations, this is a disincentive
[15:47:02] <iljitsch> would rather make it deployable without this
[15:47:16] <iljitsch> geoff: is part of the base specification, can't rip it out
[15:47:52] <iljitsch> anonymous: (from ericsson I think) you have two options, free license or pay and reserve the right to sue
[15:47:56] <iljitsch> sorry, no name again:
[15:48:04] <iljitsch> we need to decide what is ok for us
[15:49:03] <iljitsch> I've seen it in many working groups: RAND reasonable and non-discriminatory is good enough, other wgs: ask for royalty-free for open source, maybe ask for this from ericsson
[15:49:16] <iljitsch> jari: this is already on the table, can use it for free
[15:49:21] <iljitsch> or RAND
[15:50:12] <iljitsch> jim: as a wg member , forget about cga , I've made my contribution, I'm going to object to any vendor that presents work that has patents
[15:50:25] --- fparent@jabber.org has joined
[15:50:34] <iljitsch> (fyi: HBA didn't come from ericsson)
[15:52:19] --- niklegrec@jabber.com has joined
[15:52:25] <iljitsch> marcelo: I came up with HBA, no patents, don't work for ericsson
[15:52:38] <iljitsch> jim: jeez, didn't say that
[15:52:53] --- xiaodong has joined
[15:53:01] --- xiaodong has left
[15:53:23] <iljitsch> me: maybe have an alternative security mechanism
[15:54:08] <iljitsch> geoff: question for the wg: comfortable with proceeding to last call as is with your understanding of IPR issues?
[15:54:15] <iljitsch> yes (many people)
[15:54:23] <iljitsch> no (fewer people but also a lot)
[15:54:33] <iljitsch> geoff: no consensus, need to resolve this later
[15:55:26] <iljitsch> jim wants different order for ipsec and shim
[15:55:49] <iljitsch> specified in shim is contrary to how all of this works today
[15:56:30] <iljitsch> fear that people will start to include ULIDs in options or such, that would be bad
[15:56:54] <iljitsch> end-to-end argument says you only see the headers and IPsec, so how does the decrypt work, you need to get in there
[15:57:19] <iljitsch> no name: I understand that all that appears is the context id
[15:58:07] <iljitsch> jim: we're now reversing an earlier architectural decision re in-band or out-of-band carrying of the ULID
[15:59:41] <loughney> Iljitsch - can't you decide which you do first - IPsec first or shim6 first?
[15:59:59] <iljitsch> jim will write something
[16:00:03] <loughney> Geoff suggests that this issue is written up
[16:00:06] <loughney> Jim agrees.
[16:00:43] <iljitsch> pekka: <don't follow this>
[16:01:05] <loughney> Pekka Savola suggests that the SecDir didn't have a clear view if HBAs were sufficient or not.
[16:01:13] <iljitsch> jari: feedback from security directorate thinks HBA will work but worried about coming up with a new mechanism
[16:01:30] <loughney> Jari Arkko said SecDir thought it could work, but were worried about the invention of new things.
[16:01:37] <iljitsch> ok you go
[16:02:03] <loughney> Jari - there was a conclusion that the SecDir was worried but not sure what to do.
[16:02:16] --- bkhabs@jabber.org has left
[16:02:20] <loughney> Summary: no wg consensus on moving forward with HBAs
[16:02:42] <loughney> write-up on the IPsec issues and then see what the next steps are
[16:03:16] <iljitsch> geoff: haven't received all the presentations, email them I'll put them online
[16:03:27] <iljitsch> joe abley will talk about the applicability document
[16:05:37] <iljitsch> this talks about relationships shim6 with other protocols
[16:05:44] <iljitsch> written by marcelo edited by joe
[16:07:25] <iljitsch> sorry this is too complex / fast to type something reasonable...
[16:09:21] <iljitsch> missing content: interaction with other protocols, state machine hints (like tcp timeout approaching), timer manipulation, hook to disable shim6 for individual sessions
[16:10:15] <iljitsch> more missing: site policy enforcement rather than leave it up to hosts, clearer presentation of traffic engineering scenarios
[16:11:39] <iljitsch> vijay (?): last ietf we had a lunch about shim <-> mip
[16:11:53] <iljitsch> can do site multihoming for home address
[16:12:13] <iljitsch> <something> not for care of address, surprising that this is in there now
[16:12:33] <iljitsch> marcelo: I rephrased this as a possibility, but can be removed
[16:13:09] <iljitsch> shinta (?): I'll talk about API stuff later
[16:13:19] <iljitsch> that could solve some of this.
[16:13:35] <iljitsch> joe: but I was talking about other interactions under the hood
[16:14:33] <iljitsch> chris (something): what I don't understand: why is this better done at the host rather than at the network level? looks like NAT, which isn't done at the host either
[16:15:14] <iljitsch> geoff: objection as chair: there were 35 proposals over 18 months in multi6, terminated with proposal to work on shim6, so that's our charter
[16:15:46] <iljitsch> geoff: so there will be another revision of this draft
[16:16:03] <iljitsch> now implementation report overview from marcelo
[16:16:34] <iljitsch> Bagnulo - Implementation Summary
[16:16:50] <iljitsch> (sorry if the link doesn't work, scroll up if necessary)
[16:17:08] <iljitsch> Marcelo: I've talked to some people doing implementation work for shim6, not doing this myself
[16:17:20] <iljitsch> heard about ericsson, ucl, openhip (?)
[16:17:34] <iljitsch> (see sheets for details)
[16:17:59] <iljitsch> ucl = catholic university leuven in belgium
[16:18:15] <iljitsch> leuven === louvain
[16:18:27] --- jft has left: Replaced by new connection
[16:18:27] --- jft has joined
[16:18:52] <iljitsch> see http://www.oopenhip.org
[16:18:59] <iljitsch> more details from: ?
[16:19:35] <iljitsch> Teawan You from ETRI
[16:19:44] <iljitsch> Taewan, sorry
[16:19:54] <iljitsch> Progress report on shim6 implementation
[16:20:27] --- brabson has joined
[16:20:40] <iljitsch> under linux, phase 1 may 2006 - nov 2006, basic stuff
[16:20:49] <iljitsch> second phase starts jan 2007
[16:23:08] <iljitsch> first use Netfilter and IPtable in interim solution, do it with kernel patch later
[16:26:04] <iljitsch> aim is to havee a demonstration at IETF67 in november
[16:28:06] <iljitsch> geoff: if anyone else is implementing, we'd like to know
[16:28:07] <iljitsch> geoff: talk about additions to base shim
[16:28:24] <iljitsch> marcelo: draft about locator pair selection after there is an outage
[16:28:31] <iljitsch> why not RFC 3484?
[16:29:04] <iljitsch> need to consider additional information such as known reachability information and preferences exchanged by the shim protocol
[16:29:14] <iljitsch> this adds/modifies RFC 3484
[16:30:11] <iljitsch> start with set of available addresses
[16:30:21] <iljitsch> create locator set that are communicated to other side
[16:30:39] <iljitsch> some addresses are working according to local information
[16:30:56] <iljitsch> then create pairs, which can have different states
[16:31:45] <iljitsch> shim6 protocol communicates preferences, assume that this info is also available for local addresses
[16:32:47] <iljitsch> discuss all rules including my comments on them
[16:33:00] <iljitsch> there are about 16 rules so we should get rid of some
[16:37:21] <iljitsch> jari: what is the plan with these rules? failure detection leaves this open to implementations on purpose
[16:37:32] <iljitsch> marcelo: I don't have a plan
[16:38:00] <iljitsch> jari: prefer to do this later because it could take some time to hammer this out
[16:38:35] <iljitsch> tim (?) shepard: wow, complex. do you have something in there about site administrator preferences?
[16:39:36] <iljitsch> other issue: when you make this choice 10 kbps, other choice is much faster, should it try both and pick the fastest?
[16:40:01] <iljitsch> is hanlding this in scope for the wg?
[16:40:03] <iljitsch> geoff: yes
[16:40:48] <iljitsch> marcelo: management of locators: local priority/weight how this is distributed needs more thought
[16:41:09] <iljitsch> apart from that locator pair preference table, can assign preference to prefix pairs
[16:41:39] <iljitsch> second question: this more dynamic information would be hard, need to measure
[16:42:35] --- jft has left
[16:42:38] <loughney> Iljitsch - when he was writing a failure detection draft, he added timestamp info for this reason.
[16:42:51] <loughney> It can be used to determinte which pairs are faster.
[16:43:19] <loughney> and avoid doing a full m x n probling of all pairs
[16:43:34] --- miyahiro@jabber.org has left: Logged out
[16:43:52] <loughney> Tim S - if the task is to download a multigigabyte file, I might care which path gives more bw.
[16:44:36] <loughney> Geoff - chair hat off - design is to make a basic spec, and allow for additional experimentation.
[16:46:32] <iljitsch> missed geoff last comments
[16:47:01] <iljitsch> john loughney: potential for unbounded solution space
[16:47:17] <iljitsch> wait for well-thought out use cases to avoid explosion
[16:48:51] <iljitsch> dave ?: there is already an API for selecting ULIDs, what's the relationship to selecting locators for use after a failure? does it make sense to integrate these?
[16:49:12] --- rloomans has left
[16:49:26] <iljitsch> marcelo: more information available here than in non-shim communication
[16:49:52] <iljitsch> dave: true but that's already the case with MIP-applicable stuff in RFC 3484
[16:50:16] <iljitsch> marcelo: choices could be incompatible with MIP
[16:51:12] <iljitsch> marcelo: but interesting to go back to original ULID selection
[16:51:58] <iljitsch> geoff: but one document or two
[16:52:01] --- evanjc has joined
[16:52:02] <iljitsch> marcelo: not sure...
[16:52:32] <iljitsch> geoff: rfc 3484 refinement in int area, not this wg.
[16:55:09] --- Bob has left
[16:58:07] <iljitsch> <discussion>
[16:58:22] <iljitsch> geoff: other work on RFC 3484 so we should probably keep them separate
[16:59:16] <iljitsch> marcelo on ingress filtering
[17:02:57] <iljitsch> will become a wg document
[17:04:15] <iljitsch> sinta shugimoto about socket api for shim
[17:04:21] <iljitsch> shinta
[17:04:35] <iljitsch> targeting both shim and hip
[17:05:54] --- Bob has joined
[17:07:56] <iljitsch> the existing socket api should continue to handle the identifier (ULID)
[17:08:35] --- mjo has left
[17:09:16] --- brabson has left
[17:09:16] --- brabson has joined
[17:09:16] <iljitsch> defined shim6-specific options and ancillary data for get/setsockopt and get/sendmsg
[17:09:56] <iljitsch> there is a fairly big list of them, have a look at the draft or the presentation
[17:09:57] --- evanjc has left
[17:10:42] <iljitsch> comments about suitability of some options for get/setsockopt
[17:11:00] --- rloomans has joined
[17:13:32] --- jft has joined
[17:19:07] --- iljitsch has left
[17:19:12] --- fparent@jabber.org has left
[17:19:48] --- jft has left
[17:20:05] --- FDupont has left
[17:20:29] <loughney> I need to leave soon, may not last all of Iljitsch's presentation
[17:21:31] <loughney> Shim6 is doing is keep connections on-going.
[17:21:40] <loughney> not doing traffic engineering & centralized control
[17:22:32] <loughney> shim6 should work well to start
[17:22:47] --- oran@jabber.org has joined
[17:22:52] <loughney> Shim6 has a bias against it & some objectsions.
[17:23:03] <loughney> Adding new options later that doing it from start is more work.
[17:23:14] <loughney> The WG isn't fast anyway.
[17:23:18] <loughney> IPv6 deployment is low.
[17:24:06] <loughney> Need to look at Proxy Shim / router rewriting.
[17:24:10] --- momose has left
[17:24:19] --- shep has left: Logged out
[17:24:23] <loughney> might require another security mechanism - tls or dnssec?
[17:25:03] <loughney> suggestions - don't push for standards track.
[17:25:12] <loughney> do experiements & implementations
[17:25:14] <loughney> work on more features, regine.
[17:25:23] <loughney> Put on standards track when we're happy.
[17:26:22] <loughney> Kurtis - as wg participant - doesn't think there is a reason to go to experimental, standards track can be updated
[17:26:38] <loughney> got a workiing group to chair now, sorry! bye
[17:27:24] <jeffa> Jari Arrko: threats on the ML, bugs to fix, but he's not sure about adding new features at this stage.
[17:27:29] --- oran@jabber.org has left
[17:28:08] --- loughney has left: Replaced by new connection
[17:28:12] <jeffa> He doesn't think the WG participants want to be working for years and years; some of your suggestions may be nice extensions; not about getting a big spec with all the features, but getting some implementation experience
[17:28:26] <jeffa> Marcelo: main concern w/additional stuff is complexity
[17:28:54] <jeffa> already have hundreds of pages, doesn't want to add more packets, would prefer to remove stuff from the spec
[17:29:21] <jeffa> Iljitsch: if I take stuff out, can I put new stuff in?
[17:29:45] <jeffa> Bob Hinden: WG should full speed ahead, get some impl. experiments
[17:30:09] <jeffa> Il: not talking about adding several years, or making the spec really big...
[17:30:20] <jeffa> Bob: getting this out there would be really useful
[17:30:42] <jeffa> Jari: impl. seem most useful, the path forward to me
[17:30:55] --- Bob has left
[17:30:56] <jeffa> Pekka Savola: one feature I would like to see in the base, extension header suppression
[17:31:13] <jeffa> ... should be happy about applicability statement
[17:31:44] <jeffa> chair: times up
[17:32:01] <jeffa> instructions are clear regarding the 3 documents.
[17:32:12] <jeffa> need to somehow resolve IPR issues... not sure how
[17:32:41] <jeffa> ...etc etc.
[17:32:53] --- jeffa has left
[17:32:56] --- ggm has left
[17:33:06] --- niklegrec@jabber.com has left: Logged out
[17:33:23] --- rloomans has left
[17:33:46] --- bonninjm@jabber.org has left: Logged out
[17:34:16] --- sam xia has left
[17:39:39] --- dudi has left: Replaced by new connection
[17:40:50] --- dudi has joined
[17:40:58] --- dudi has left
[17:47:50] --- nm has left: Replaced by new connection
[17:47:51] --- nm has joined
[17:54:00] --- nm has left
[17:57:46] --- iljitsch has joined
[17:59:52] --- iljitsch has left
[18:10:13] --- rloomans has joined
[18:10:32] --- rloomans has left
[19:00:30] --- LOGGING STARTED
[19:02:53] --- brabson has joined