[11:52:29] --- bharat.josh has joined
[11:58:20] --- raj has joined
[11:59:59] --- bharat.josh has left
[12:03:43] --- Seung Yi has joined
[12:04:15] --- dudi has joined
[12:04:28] --- mstenber has joined
[12:04:45] --- marka has joined
[12:04:56] --- woj has joined
[12:05:18] <Seung Yi> Is the audiocast working now? I'm having problems connecting to the streaming server.
[12:05:52] --- arifumi has joined
[12:06:14] --- sarikaya has joined
[12:06:20] --- bharat.josh has joined
[12:06:21] <marka> adjenda bashing
[12:06:37] <raj> chairs don't seem to know if the audiocast is working or not.
[12:06:41] <mstenber> and wondering if the audio works or not ;)
[12:06:47] <raj> apparently there were problems in some earlier meetingsw
[12:06:58] --- venaas has joined
[12:08:12] --- oatwillie has joined
[12:08:13] <mstenber> anyone here not physically present?
[12:08:28] <oatwillie> yes
[12:08:32] <bharat.josh> Me...
[12:08:42] <bharat.josh> Yes
[12:08:50] <Seung Yi> here.
[12:09:17] <venaas> now at ready for last calls draft
[12:09:41] <venaas> seems to be consensus for taking raan and srsn to wglc, will verify on list
[12:09:42] <mstenber> we're going through the WG last call stuff. the relay agent notification option / SRSN apparently were hummed good enough, re-check on ml though.
[12:09:50] <Seung Yi> audiocast is working now.
[12:09:54] <mstenber> ah, excellent.
[12:10:29] <venaas> happy if you do jabber scribing Markus :)
[12:10:43] <mstenber> chuckle
[12:10:48] <mstenber> reconfigure-rebind was hummed last call as well.
[12:11:44] <mstenber> Durand: no last call votes on stuff with presentations (LQ)
[12:11:56] <mstenber> Ralph: so we hold last calls until presentations done.
[12:12:35] --- paulwouters@jabber.org has joined
[12:12:50] <mstenber> IPR statement concern about subnet allocation option(?).
[12:12:57] <mstenber> (XXX, from Boeing)
[12:13:18] <sarikaya> fred templin from boeing
[12:13:58] <mstenber> .. does IPv6 PD have the IPR too? apparently, no definite idea ..
[12:14:12] <mstenber> (Arkko, Droms comments in that vein)
[12:14:31] <mstenber> "Using it will be difficult for us." (-Templin)
[12:15:24] <mstenber> .. leave it to mailing list, apparently, during the last call ..
[12:15:41] <mstenber> Interesting if DHCPv6 PD is affected though.
[12:16:13] <mstenber> hummed subnet option to last call.
[12:17:12] <mstenber> relay agent echo request option also hummed to last call (Albeit very weakly)
[12:18:03] <mstenber> .. now discussing new WG work items ..
[12:18:56] <mstenber> .. Droms discussing failover next ..
[12:19:03] <mstenber> (bickering about lack of slides)
[12:19:10] --- Jyrki.Soini has joined
[12:20:15] <mstenber> apparently, interest on failover draft (Cisco authors, Nominum, Arkko<>Droms<>Venaas conference call)
[12:21:01] <mstenber> .. few minutes unofficial chat after today's meeting on the failover draft ..
[12:21:02] --- bharat.josh has left
[12:22:18] <mstenber> "is there a need to publish failover draft as std track document? yes, apparently interest in vendor-interoperable solutions."
[12:22:38] --- bharat.josh has joined
[12:23:47] <mstenber> "std track RFC apparently good idea. no concrete evidence of market for such an implementation." (I wonder why)
[12:24:02] <mstenber> "Nominum willing to assess demand for interoperable version of failover protocol"
[12:24:57] <mstenber> Arkko: significant work ahead.
[12:25:34] <mstenber> .. Arkko promoted informational/experimental as a valid alternative ..
[12:25:58] <mstenber> David (ISC) points out that interoperability is currently impossible.
[12:27:11] <mstenber> Thomas XXX: tremendous amount of work needed - previous versions 133 pages, complex protocol, hard to understand.
[12:27:23] <mstenber> his recommendation was along the lines of "walk away from it and work on other things."
[12:28:16] <mstenber> venaas: server-override passed last call but then later IESG demanded changes.
[12:28:44] <sarikaya> thomas narten
[12:28:46] <mstenber> apparently, new version - but chair doesn't think LC is needed.
[12:29:01] <mstenber> .. moving on to rechartering ..
[12:31:17] <mstenber> DHC WG will act primarily as clearinghouse for options; second alternative is to have the DHC WG work on oiptions based on requirements from other WGs.
[12:31:27] <mstenber> (apparently Droms prefers the latter ;-)
[12:32:28] <mstenber> .. dhc WG objectives-slide ..
[12:33:03] <mstenber> Need to address security - not quite clear what it is yet.
[12:33:40] <venaas> I think we will see both things happening. Sometimes other groups do a dhc option where we review it. Other times a wg might tell us that we need an option to do a certain thing with such and such use and content, and we can design the option for them
[12:34:15] <mstenber> Arkko: Charter update reasons (3); current (remove things already done)
[12:34:25] <mstenber> - opportunity for reconsidering where things should be worked on (failover, new things?)
[12:34:45] <mstenber> - write the charter so that it supports our reasoning on the decisions we make on whether drafts are accepted as WG items or not
[12:34:58] <mstenber> Alain Durand:
[12:35:28] <mstenber> "what about work that will be about DHCP? f.ex MIB, XML"
[12:35:43] <mstenber> (xxx) "do you have something specific in mind?"
[12:35:47] <mstenber> Durand: "maybe"
[12:35:54] <mstenber> Droms: "present ideas on the list."
[12:36:13] <mstenber> Arkko: "not union of the things people want to work on. intersection!"
[12:37:02] <mstenber> .. DHCP option for discoverin IEEE 802.21 info-show ..
[12:37:19] <mstenber> outlook slide.
[12:38:29] <raj> http://www.ietf.org/internet-drafts/draft-daniel-dhc-mihis-opt-02.txt
[12:39:47] <mstenber> (I'm happily assuming people have voice feed, and just noting down impressions / important comments by my subjective information ;-)
[12:40:45] <mstenber> .. issues from 802.21 spec slide
[12:42:05] <mstenber> .. discocvery info slide
[12:42:07] <mstenber> (Arkko on the mike)
[12:42:22] <mstenber> "chosen as a candidate mechanism"
[12:42:39] <mstenber> "typically, the orgs work by fighting about solutions - is this official decision or really just a candidate?"
[12:43:08] <mstenber> (?) "Nothing defined yet. L2 defined, but nothing for L3 and above."
[12:43:22] <mstenber> .. "if it is defined by the IETF, it will maybe considered as default approach for it."
[12:43:53] <mstenber> Ralph: from the last time, he had AP on it. tried to contact IEEE, but no luck, who's driving which?
[12:44:21] <mstenber> (?)=Subir Das: "there is a liason to the IETF."
[12:44:49] <mstenber> (?2): in current text there is a DHCP reference.
[12:45:14] <mstenber> (grumble, wish people announced their names more clearly, they usually face wrong way for me to read names too :p)
[12:45:31] <sarikaya> ?2=Yoshi Ohba
[12:46:11] <mstenber> Arkko: We should operate based on other SDO's request. Remaining question are the technical details and where to work on this. There is also a support WG in IETF.
[12:47:03] <mstenber> Ohba: mipshop(?) attempts to determine just location information
[12:47:24] <mstenber> Das/Arkko discussion on the mipshop charter.
[12:47:39] <mstenber> Arkko's preference for option to be worked on in mipshop and reviewed here.
[12:48:40] <mstenber> .. skipping apparently the details of the show, just going for the discussion on whose job it is? ..
[12:49:09] <mstenber> .. Leasequery show (Volz) ..
[12:50:00] <raj> http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcvp6-leasequery-00.txt
[12:50:24] <mstenber> .. two messages-slide
[12:50:39] <mstenber> .. messages
[12:51:19] <mstenber> .. OPTION_LQ_QUERY
[12:52:28] <mstenber> .. OPTION_CLIENT_DATA
[12:54:00] <mstenber> .. OPTION_CLT_TIME
[12:54:38] <mstenber> .. Other parameters
[12:55:07] --- BillC has joined
[12:55:31] <mstenber> .. sample LQ
[12:56:03] <mstenber> .. sample LQ reply
[12:56:28] <mstenber> .. next steps
[12:56:46] <mstenber> "fundamentally duplicates what v4 LQ offers."
[12:57:25] <mstenber> mr. ISC again: Modifications have over-answered the comments.
[12:57:36] <mstenber> "nothing left here anyone could complain about."
[12:57:40] <mstenber> (reasonably)
[12:57:41] --- sarikaya has left
[12:57:44] <mstenber> (lots of laughter here ;-)
[12:58:17] <mstenber> XXX, Comcast: the extensions on LQ are interesting for us (as separate ID)
[12:58:24] <mstenber> "I believe there is interest in that."
[12:59:09] <mstenber> Volz: "with 10k clients, doing them one-by-one is expensive. is there more efficient way to do this? UDP isn't bulk transfer protocol."
[12:59:54] <mstenber> Alain: doesn't aggree with LC comments to a degree; bulk transport might need to use other transport. talk about it in next show?
[13:00:58] <raj> http://www.ietf.org/internet-drafts/draft-stenberg-pd-route-maintenance-00.txt
[13:05:56] --- sarikaya has joined
[13:08:21] <paulwouters@jabber.org> closer to microphopne please
[13:14:01] --- bharat.josh has left
[13:14:10] --- bharat.josh has joined
[13:14:17] --- BillC has left
[13:16:11] <mstenber> .. Volz's SRSN
[13:16:23] <mstenber> .. problem-slide
[13:16:25] <raj> http://www.ietf.org/internet-drafts/draft-volz-dhc-dhcpv6-srsn-option-00.txt
[13:17:10] <mstenber> .. example
[13:17:22] <mstenber> .. proposed solution
[13:18:24] <mstenber> .. relay impact
[13:19:07] <mstenber> .. server impact
[13:20:00] <mstenber> .. security issues
[13:20:14] <mstenber> Kinnear (Cisco): fine thing to do, but the upgrade/replacement of server issues
[13:20:22] <mstenber> "how do you replace a DHCP server?"
[13:20:35] <mstenber> "how can you ever talk to a client?"
[13:22:54] <mstenber> (me): .. long diatribe on using time instead of reboot counts .. Droms: just a suggestion in draft anyway. Volz: change draft if needed.
[13:23:18] <venaas> Not sure if timestamp works. or depends what your idea was
[13:23:20] <raj> http://www.ietf.org/internet-drafts/draft-templin-autoconf-netlmm-dhcp-04.txt
[13:23:25] <mstenber> Templin's NETLMM
[13:24:08] <venaas> if you on average sends multiple replies per second, wouldn't the timestamp when rebooting be past what was previously used?
[13:24:13] <mstenber> venaas: the timestamp works, the flawed iidea is just the default of using reboot counter 32 bits for the upper bits instead of time. (I think I've discussed this with Volz/et al before)
[13:24:18] <mstenber> it being ahead isn't a problem
[13:24:21] <mstenber> it being a behind is
[13:24:21] <venaas> or maybe it works if reboot takes longer than the lifetime of packet
[13:24:27] <mstenber> .. NETLMM on DHCP
[13:24:36] <venaas> right
[13:24:37] <mstenber> .. route/tunnel config after MN config's address/prefix via AR1
[13:24:58] <mstenber> .. after MN moves to AR2
[13:25:12] <mstenber> .. new since -02
[13:25:48] <mstenber> .. AR client/relay configuration
[13:26:20] <mstenber> .. deleting state in old AR
[13:27:09] <mstenber> .. network-initiated handovers
[13:27:59] <mstenber> .. support for SLAAC-only MNs (aka "proxy-DHCP")
[13:28:12] --- florent.parent@gmail.com has joined
[13:28:34] <mstenber> .. notes
[13:28:52] <mstenber> .. technical questions
[13:29:46] --- florent.parent@gmail.com has left
[13:29:57] <mstenber> .. big-picture questions
[13:30:51] <mstenber> Arkko: providing background ..
[13:31:04] <mstenber> "lots of discussion on what sort of solution to pick up going forward."
[13:31:17] <mstenber> "had dozen people contacting (me) this week"
[13:31:40] <mstenber> "I also encourage everyone to come to NETLMM to provide feedback"
[13:32:09] <mstenber> "in the end of the day, one or more need to be chosen."
[13:32:55] <mstenber> Templin: customer-driven solution before IETF solution
[13:33:09] <mstenber> Arkko: question in wg is - do we take something from somewhere, or start from scratch
[13:33:30] <mstenber> Mark Stapp: is it already used in this env?
[13:33:33] <mstenber> Templin: yes.
[13:34:26] <mstenber> Arkko: nodes use DHCP internally, but. I haven't heard of this sort of proposals being deployed somewhere, and non-IETF solutions elsewhere.
[13:34:43] <mstenber> Templin: there are 2 DHCPv4 implementations that are actually implemented.
[13:35:08] <mstenber> Droms: RAAN->CSR rename has to be discussed later.
[13:35:28] <mstenber> Volz: we do more than prefixes in RAAN anyway
[13:36:19] <mstenber> Das questions the validity of the use of DHCP for this.
[13:36:30] <mstenber> ".. only for this particular arch it will work."
[13:36:56] <mstenber> Droms: "big picture depends on NETLMM - we need to see what comes from NETLMM"
[13:37:33] <mstenber> (?3) questions NETLMM<>DHCP relation.
[13:37:43] <mstenber> Droms: details of DHCP and NETLMM interop offline later.
[13:38:06] <mstenber> (or hm, Templin commented the last, Droms just said we were late - my bad.)
[13:38:10] <mstenber> .. PXELINUX options show
[13:38:13] <raj> http://www.ietf.org/internet-drafts/draft-ietf-dhc-pxelinux-00.txt
[13:38:50] <mstenber> .. what this draft does
[13:38:57] <mstenber> .. questions?
[13:39:42] <mstenber> (jabber scribe visiting WC; back in a bit)
[13:41:19] <paulwouters@jabber.org> people: please speak in the microphone. i cannot hear anything now :(
[13:41:43] <raj> Hankin's is talking now. Can you hear him?
[13:41:44] <mstenber> .. back.
[13:41:53] <paulwouters@jabber.org> hardly
[13:42:05] <mstenber> better?
[13:42:11] <paulwouters@jabber.org> no change
[13:42:41] <mstenber> .. option processing show; we hear the presenter's voice ok, so maybe the problem's elsewhere
[13:42:53] <mstenber> .. option processing req's
[13:42:55] <raj> Looks like maybe there's something with the audio stream. he's talking as loudly as other people were.
[13:42:57] <mstenber> .. one approach
[13:42:57] <Seung Yi> audicast is working fine for me.
[13:42:58] <raj> http://www.ietf.org/internet-drafts/draft-dhankins-atomic-dhcp-00.txt
[13:43:12] <bharat.josh> For me also its working fine
[13:43:36] <paulwouters@jabber.org> odd. it was louder for me 10 minutes ago
[13:43:47] <paulwouters@jabber.org> now it's a whisper. and all my volume controls are full open
[13:43:47] <mstenber> .. enter "atomic" DHCP
[13:44:23] <mstenber> .. a day in the life of Ivan
[13:44:40] --- sarikaya has left
[13:44:48] <mstenber> .. configuring format
[13:45:43] <mstenber> .. configuring content
[13:46:05] <mstenber> .. transmitting
[13:46:23] <mstenber> .. receiving Ivan
[13:46:47] <mstenber> .. cont'd
[13:47:21] <mstenber> .. DNs are problem children
[13:48:03] <mstenber> .. todo
[13:48:50] --- oatwillie has left
[13:49:01] <mstenber> Kinnear (Cisco): .. liked the conclusions.
[13:49:12] <mstenber> "look first at this, look secondly at this, .."
[13:49:28] <mstenber> "this part felt useful to me, as we've spent lots of time on this over the years"
[13:49:51] <mstenber> .. but he didn't like part about server internals.
[13:50:14] --- sarikaya has joined
[13:50:22] <mstenber> "we don't need to tell them why to do it like this"
[13:51:20] <mstenber> (I don't agree, but guess I won't waste the time with mic time ;-)
[13:51:38] <mstenber> (I dislike solutions that do not describe why, because then there's bit of second-guessing)
[13:52:32] --- ShoichiSakane has joined
[13:52:46] <mstenber> .. discussion on is this ..
[13:53:10] <mstenber> Droms summarizes: there is a call for document that summarizes how to defines how to do DHCP options.
[13:53:18] <mstenber> John ?: intent of this to be informational?
[13:53:28] <mstenber> Droms: yes, as informational document.
[13:53:42] <mstenber> -> WG item, it seems. (no opposition hums)
[13:54:13] <mstenber> .. extension of DHCP LQ in bridging/switching networks ..
[13:54:33] <raj> http://www.ietf.org/internet-drafts/draft-joshi-dhcp-lease-query-ext-02.txt
[13:54:50] <mstenber> .. RFC4388 for L3 AN
[13:56:42] <mstenber> .. extension of RFC4388 to L2
[13:58:14] <mstenber> .. changes from 00 to 02
[14:02:30] <mstenber> Richard P (Cisco): question o premise of the architecture - with BFD keepalive, client will start re-discovering anyway?
[14:03:05] <mstenber> presenter: with that scheme clients need to be restarted; however, with this it isn't needed.
[14:03:54] <mstenber> Droms: DSL forum working on this solution? -> not
[14:04:11] <mstenber> .. he wants to find out who's actually driving for solution to the rebooting problem.
[14:04:20] <mstenber> presenter: our solution, not DSL solution as such.
[14:04:48] <mstenber> (XXX, Cisco): forum doesn't cover this solution as such - but wants to know more
[14:05:35] <mstenber> .. discussion on deployment variants ..
[14:05:52] <mstenber> "your solution only affects solutions when RG is briding and DSLAM restarts and loses state."
[14:06:04] <mstenber> Droms: what is status of BFD solution?
[14:06:21] <mstenber> XXX: upcoming working text (what's that? forum document?)
[14:07:07] <mstenber> Droms: L2 part is not material; L3 fact that the state has been lost is being inferred.
[14:08:12] <mstenber> .. more discussion on the L2 reset ..
[14:08:37] <mstenber> Droms: DSL-related solutions should be in DSL forum? we can work on optinons if needed. however, L2 solution general or not?
[14:09:03] <mstenber> Volz: in v6 we allow relay chaining; is this a general relay chaining problem in v4? (L2 relays that is)
[14:09:41] <mstenber> Kinnear: not disagreeing as such, LQs aren't relayed right now.
[14:10:09] <mstenber> "generally, realistic problem"
[14:10:34] <mstenber> .. apparently we're overtime and discussions are being cut short
[14:10:43] <mstenber> Volz: are these devices L2 only?
[14:10:55] <mstenber> presenter: only mgmt IP address, fully L2 devices.
[14:11:38] <mstenber> ?: another keepalive there anyway, good to keep in mind
[14:11:46] <mstenber> .. unicast-address sub-option show
[14:12:01] <raj> http://www.ietf.org/internet-drafts/draft-decnodder-dhc-rai-unicast-01.txt
[14:13:44] <mstenber> .. new sub-option in option-82
[14:13:50] <mstenber> .. processing of new sub-option
[14:14:46] <mstenber> .. next step
[14:15:39] <mstenber> Droms; we will discuss this on the list before considering this as WG item.
[14:16:04] <mstenber> question is, where is the requirement for this option coming from, or is this already being dealt with in DSL forum, or is this useful elsewhere?
[14:16:41] <mstenber> Kinnear: if we proceed with this, I could imagine a hardware address option/suboption combo
[14:17:24] <mstenber> "if we decide to do both of these things, describing it as 'this is the hw addr, put it wherever'"
[14:17:36] <mstenber> .. DHCPv4/v6 proxy
[14:17:40] <raj> http://www.ietf.org/internet-drafts/draft-sarikaya-dhc-proxyagent-00.txt
[14:17:53] <mstenber> .. overview-slide
[14:18:41] <mstenber> (I don't see the point - is there some reason why this 'proxy' is non-implementation matter?)
[14:19:27] <mstenber> (looks like matter of backend abstraction to me, which is implementation matter..)
[14:19:39] <mstenber> .. usecase-1
[14:20:27] <venaas> agree, I don't see the point either
[14:21:13] <mstenber> .. use case-2
[14:21:27] --- bharat.josh has left
[14:22:02] <mstenber> .. mobility issue
[14:23:13] <mstenber> (huh, this doesn't look like DHCP as I understand it)
[14:23:45] <mstenber> (strange mobility approach? glued on top of normal? DHCP server as I see it)
[14:23:52] <mstenber> .. mobility issues (2)
[14:24:29] <mstenber> .. DHCP extensions
[14:24:46] <mstenber> .. list discussions
[14:25:27] <mstenber> .. feedback needed
[14:25:37] <mstenber> (ahh, wimax, brr)
[14:26:05] <mstenber> Volz: what is the purpose of this?
[14:26:24] <mstenber> nothing in the standards says where the server has (or hasn't) pool of addresses
[14:26:44] <mstenber> are you after fixing addresses of servers or something?
[14:27:51] <mstenber> .. clueless discussion on where the address is from doesn't matter (funnily enough, I agree) ..
[14:28:50] <mstenber> Ralph: if server was written not as an entity, but instead as behaviors in the backend, this whole proxy thing would be irrelevant - how the things happen doesn't matter.
[14:28:58] <mstenber> how the responses are processed is immaterial.
[14:29:08] --- paulwouters@jabber.org has left
[14:30:58] <mstenber> .. got off my comment ..
[14:31:30] <mstenber> Arkko points out that NETLMM's view of the world vrt proxying is creating this problem; perhaps we should choose another approach?
[14:32:18] <mstenber> Ralph: I've heard this DHCP proxy concept few times. Different contexts/meanings. Some technical definition place could define this, but not WG's work.
[14:32:37] --- sarikaya has left
[14:32:45] <mstenber> .. Distributing address selection policy using DHCPv6
[14:32:50] <raj> http://www.ietf.org/internet-drafts/draft-fujisaki-dhc-addr-select-opt-02.txt
[14:33:32] <mstenber> .. bg slide
[14:33:38] --- venaas has left
[14:35:08] <mstenber> .. our proposal
[14:36:00] <mstenber> .. why neccessary?
[14:36:08] <mstenber> (oh, when this is neccessary?)
[14:38:01] <mstenber> .. std status
[14:39:06] <mstenber> .. discussion
[14:40:18] <raj> Didn't think come up before a few years ago? I thought the WG decided it wasn't in scope/necessary.
[14:41:13] <raj> think -> this
[14:41:41] <mstenber> (I think it's more relevant now though - due to some ISPs dreams of offering bunch of IPv6 address ans SAS problems deriving from that)
[14:41:57] <mstenber> Kinnear: Defining a conflict resolution strategy shouldn't be done here - default strategy.
[14:42:45] <mstenber> (in Japan for example, the IPv6 provider (Docomo) will have bunch of ISPs providing their own addresses to clients - at same time. SAS is critical problem in stuff like that, and currently solutions are ugly tunneling ones.)
[14:43:28] <mstenber> Kinnear advocates explicitly setting prefix sizes etc in the draft text.
[14:44:11] <mstenber> Alain: Problem is not just about prefix table. It is also about policy notes (CoA, stateless/stateful, ..)
[14:44:35] <mstenber> .. some of the items will need different treatment - first determine policy, and then work on pushing it to the hosts.
[14:45:04] <mstenber> Droms: v6ops will do specs, and we will do the work on getting it to clients.
[14:45:48] <mstenber> Volz: handling source address selection is doable, but destination - with multiple providers, complex!
[14:45:53] <mstenber> .. mature enough?
[14:46:00] <mstenber> Droms: moot question. need more from v6ops first.
[14:46:09] --- Jyrki.Soini has left
[14:46:32] <mstenber> Kinnear: clearly WG item?
[14:46:43] <mstenber> ?chair: depends on v6ops result.
[14:46:59] <mstenber> ( so, wait for v6ops results, basically )
[14:47:19] --- raj has left
[14:48:48] --- Seung Yi has left
[14:49:11] --- dudi has left
[14:49:15] --- ShoichiSakane has left
[14:52:52] --- frank has joined
[14:53:12] --- frank has left
[14:54:50] --- arifumi has left
[14:57:12] --- mstenber has left: Disconnected.
[15:10:55] --- marka has left
[15:22:48] --- woj has left
[15:52:20] --- arifumi has joined
[15:52:39] --- arifumi has left
[16:04:50] --- marka has joined
[16:30:18] --- adekok has joined
[18:59:49] --- adekok has left
[21:11:38] --- marka has left