[09:03:11] --- ietf-wg-dhc has joined
[09:23:53] <ietf-wg-dhc> test
[09:27:24] --- jjmbcom has joined
[09:27:32] --- jjmbcom has left
[09:32:05] --- ietf-wg-dhc has left: Disconnected
[09:43:21] --- jjmbcom has joined
[09:45:00] <jjmbcom> test
[10:08:50] --- jjmbcom has left: Disconnected
[10:54:02] --- jjmbcom has joined
[15:18:57] <jjmbcom> test
[15:28:04] --- jjmbcom has left
[15:31:38] --- jjmbcom has joined
[15:31:50] --- jjmbcom has left
[18:35:41] --- venaas has joined
[18:36:09] --- venaas has left
[18:40:40] --- jjmbcom has joined
[19:15:11] --- raj has joined
[19:23:33] --- suz has joined
[19:23:41] --- suz has left
[19:27:48] --- Ralph Droms has joined
[19:28:03] <Ralph Droms> Hello from Vancouver...
[19:28:48] --- marka-isc has joined
[19:29:25] --- Ralph Droms has left
[19:37:44] --- venaas has joined
[19:41:15] --- dudi has joined
[19:41:34] --- Eliot Lear has joined
[19:41:51] <Eliot Lear> agenda bashing
[19:42:12] <Eliot Lear> most presentations are available on ietf web site https://onsite.ietf.org/public/meeting_materials.cgi?meeting_num=64
[19:42:46] <Eliot Lear> last minute agenda change: update to dhcpv6 reconfigure
[19:43:11] --- Hankins has joined
[19:43:27] <Eliot Lear> in the docsys 3.0 effort, the text in rfc 3315 says to send a renew, but it doesn't which server
[19:43:48] <Eliot Lear> proposal- extend reconfigure so it can send a rebind request as well as renew
[19:43:49] --- miya has joined
[19:44:07] <Eliot Lear> that proposal has been discussed and there seems to be consensus...
[19:44:18] <Eliot Lear> how do we incorporate that solution into rfc 3315
[19:44:40] <Eliot Lear> perhaps reissue an update?
[19:44:45] <Eliot Lear> as part of heading towards ds
[19:45:12] <Eliot Lear> or do it separately
[19:45:30] <Eliot Lear> ralph's non-wg chair preference is a one page draft
[19:45:32] <Eliot Lear> discussion?
[19:45:46] --- mo7sen has joined
[19:45:49] <Eliot Lear> bar hibbs(?)
[19:46:26] <Eliot Lear> <bar> i prefer a single document source, so i'd prefer a 3315bis
[19:47:25] <Eliot Lear> <ted lemon> a revision is a fine idea. i've been in the wg long enough how quickly those go [to laughs]. bar doesn't get a lot of help with revisions. while bar is right that we should do an update, we should also do a one pager
[19:47:28] <Eliot Lear> <bar> we agree
[19:48:05] <Eliot Lear> <ralph> i read this as a consensus as a one pager, and that it's time to bring 3315 to draft. volunteers to be sheparded?
[19:48:16] <Eliot Lear> <ted lemon> how many implementations are in common use?
[19:48:39] <Eliot Lear> <ralph> doesn't matter. only two independent implementations and we demonstrated that before 3315 was published
[19:48:49] <Eliot Lear> <ted> i feel funny at this early date
[19:49:07] <Eliot Lear> <ralph> for draft i think we're okay. we've had interoperable implementations for 2 years
[19:49:17] --- ogud has joined
[19:49:25] <Eliot Lear> <ted> the reason i question it is that we haven't seen people using it. that's why i feel uncomfortable
[19:49:45] <Eliot Lear> <bern volts> there are probably a dozen implementations, and as far as i can tell they interoperate
[19:49:56] <Eliot Lear> <ted> we just don't know whether it is serving a need yet
[19:50:13] <Eliot Lear> <ted> there isn't any dhcpv6 running on the ietf network, for example. if it
[19:50:26] <Eliot Lear> <ted> if it's not running here....
[19:50:43] <Eliot Lear> <ted> Q: is anyone actually using it in production?
[19:51:04] <Eliot Lear> <ralph> i can't answer that question for cisco, but i believe so
[19:51:25] <Eliot Lear> <ted> i know there are implementations out there but people are apparently not that excited by them
[19:51:36] <Eliot Lear> <ralph> that's the end of the administrivia.
[19:52:19] <marka-isc> Report on TAHI DHCPv6 conformance testing tool
[19:52:35] --- ogud has left: Replaced by new connection
[19:52:43] <Eliot Lear> <Hideshi Enokihara now presenting>
[19:52:52] --- frodek has joined
[19:53:30] <Eliot Lear> i am going to talk about progress of dhcpv6 in tahi project
[19:53:50] <Eliot Lear> I'm going to skip TAHI project description
[19:53:54] <Eliot Lear> Event Report
[19:54:19] <Eliot Lear> Test results wit only DUIC-LLT as DUID
[19:54:41] <Eliot Lear> Only one issue came up and it is already resolved.
[19:54:41] --- Ralph Droms has joined
[19:54:51] <Eliot Lear> Thanks Ted and Bernie!
[19:54:56] <Eliot Lear> Tester Status
[19:55:14] <Eliot Lear> TAHI project relased test tool 0.1.1 on nov 2nd
[19:55:31] <Eliot Lear> covers 3315, 3633, 3646, and 3736
[19:56:04] <Eliot Lear> test spec is available at http://www.tahi.org/dhcpv6/spec
[19:56:20] <Eliot Lear> tool is available as well
[19:56:27] <marka-isc> dhcptest@tahi.org
[19:56:34] <Eliot Lear> next tahi event will be in january in chiba, japan
[19:57:02] <Eliot Lear> all info is at http://www.tahi.org/dhcpv6
[19:57:10] <Eliot Lear> end of presentation. questions?
[19:57:35] <marka-isc> Domain Suffix Option for DHCPv6
[19:57:59] <Eliot Lear> <Yan Renxiang presenting>
[19:57:59] <marka-isc> Yang Renxiang
[19:58:32] <Eliot Lear> <oops. Ralph Droms is presenting>
[19:59:08] <Eliot Lear> changes- no longer restricted to a particular deployment scenario.
[19:59:15] <Eliot Lear> author added an iana considerations section
[19:59:22] <Eliot Lear> reformatted boiler plate
[19:59:29] <Eliot Lear> is the document ready for wg last call?
[19:59:40] <Eliot Lear> how many people read the draft? [small number of hands]
[19:59:46] <Eliot Lear> objections to going to last call?
[19:59:48] <Eliot Lear> none
[19:59:53] <Eliot Lear> we'll follow up on mailing list
[20:00:35] <marka-isc> skipping DHCP URI Option later
[20:00:46] <marka-isc> Home Agent Configuration Option for DHCPv6
[20:00:48] <Eliot Lear> <Yuzhi Ma now presenting>
[20:01:49] <Eliot Lear> [difficulty hearing the speaker]
[20:02:15] <marka-isc> discribing IPv6 home agent
[20:02:30] <Eliot Lear> home agent option which can be used to provide a list of one or more home addresses
[20:02:58] <Eliot Lear> option-len set to 0 while the mobile node is on its home link
[20:03:26] <Eliot Lear> if client's option len is 0 the link prefix is used as the key for searching home agent lists
[20:03:42] <Eliot Lear> comments?
[20:04:02] --- joshlitt has joined
[20:04:32] <Eliot Lear> <bernie volz> i don't understand how the client can detect how it's home or not... would it want to do that if it didn't have some sort of trust relationship with the dhcp server
[20:04:50] <Eliot Lear> <bernie> need to deal with security considerations
[20:05:26] <Eliot Lear> <mark stamp> we don't like to see options of 0 length... [discussion of whether 0 is a multiple of 16]
[20:05:53] <Eliot Lear> <mark stampf> there is an older draft that was a bit more flexible... draft is expired
[20:06:24] <Eliot Lear> <mark> there may be other things you need, there was some motivation in the draft that you might find useful to revisit
[20:06:52] <Eliot Lear> <ted lemon> it seems like you're asking the server to make decisions about which MIP agent to send
[20:07:38] <Eliot Lear> <bar> when the server is supplying info to the client, it sends one or more addresses. when the client sends a message, it APPARENTLY sends one address. so you need to make it clear that the client is returning one address.
[20:07:54] <Eliot Lear> <bar> how in the world does the client balance which of the addresses is the right one
[20:08:40] <Eliot Lear> <stig> there needs to be a secure BU, and the client needs to have some keys. how does it get those keys? can it get the HA the same way?
[20:09:18] --- william.gilliam has joined
[20:09:19] <Eliot Lear> <michel ?> you also need to look at nemo and add a flag <?>
[20:10:03] <Eliot Lear> <hui> i recall in washington there was a proposal...
[20:10:05] <Eliot Lear> <?>
[20:10:17] <Eliot Lear> <ralph droms> has this been discussed in MIP wg?
[20:10:32] <Eliot Lear> <presenter> i sent an email to them...<..>
[20:10:59] <Eliot Lear> <ralph> we should coordinate with MIP to understand where this fits
[20:11:06] <Eliot Lear> end of presentation
[20:11:19] <Eliot Lear> <james polk presenting>
[20:11:23] <marka-isc> DHCP URI Option
[20:12:38] <Eliot Lear> this will be equally uncontroversial to location
[20:12:44] <Eliot Lear> [laughs]
[20:12:59] <Eliot Lear> 2 iterations already. changes as fast as i get changes.
[20:13:26] <Eliot Lear> creates an option to request and respond with one or more URIs
[20:13:32] <Eliot Lear> can be solicited or unsoclitied
[20:13:41] <Eliot Lear> complies with rfc3396
[20:14:05] <Eliot Lear> what is the purpose is the intended meaning of a uri
[20:15:02] <Eliot Lear> could be location (?) could be sip uri for 911 call ctr
[20:15:28] <Eliot Lear> open issues
[20:15:53] <Eliot Lear> remaining issues are in regards to values "purposes"
[20:16:06] <Eliot Lear> is it sufficiently mature to advance?
[20:16:12] <Eliot Lear> [a long line has formed at the mike]
[20:16:44] <Eliot Lear> <mark linsner> ecrit has an interest in 1,2, 4, and 5
[20:17:21] <Eliot Lear> <mark> you've provided pre-call routing. in an unofficial poll in ecrit it seemed like a reasonable thing to do.
[20:17:43] <Eliot Lear> <mark> what has not been discussed in ecrit is the appropriate place to do pre-call routing in the archicture.
[20:17:51] --- joshlitt has left
[20:18:23] <Eliot Lear> <mark> it seems your motivation is emergency call services. if ecrit were to decide that dhc is not the right place for this would you still be motivated to do this?
[20:18:23] <Eliot Lear> <james> yes
[20:18:43] <Eliot Lear> <mark> dhc operators must realize that they would be providing emergency call routing
[20:19:35] <Eliot Lear> <james> i've been advised to offer a better applicability statement. i've tried to leave as much architecture out of this, except for purpose codes. i didn't want to burden this working group with having to showing where this fits
[20:20:02] <Eliot Lear> <james> in the ietf the end point doesn't know where it is.. option 123 is the only way to know where one is. but one can't then route a call...
[20:20:21] <Eliot Lear> <james> there is no 911@{...}.ca
[20:20:41] <Eliot Lear> <james> so where in the layer do i explain this? so i took too much out and i'll put a little of it back in
[20:21:45] <Eliot Lear> <bernie volz> the way concatenation works is that you end up with one long option that gets broken up arbitrarily. and the way you constructed the option is correct but the example is iffy
[20:22:23] <Eliot Lear> <bernie> and you need to clean up more text. text is confused around option messages and whether they're subdivided. so clean that up as well, and applciability
[20:22:57] <Eliot Lear> <mark stampf> didn't like the stale uri, that there will be an out of band mechanism to keep the information fresh
[20:23:56] <Eliot Lear> <mark> linsner's comments were really correct. there's an issue in practical terms for the other standards groups. they don't have firm requirements... concerned that we are putting cart before the horse...
[20:24:23] <Eliot Lear> <mark> is it correct that it will always be the dhcp administration that will provide this information throughout the entire system?
[20:24:43] <Eliot Lear> <mark> perhaps deliver a single uri where this information where will be delivered?
[20:25:02] <Eliot Lear> <mark> like dns. we don't tell you how to resolve a domain, but we tell you where the servers are
[20:25:15] --- william.gilliam has left
[20:25:23] <Eliot Lear> <ralph droms> line closed
[20:25:41] <Eliot Lear> <ted lemon> you've addressed both of my main objections
[20:26:38] <Eliot Lear> <ted> this is a working group about dhc and not about emergency services. i think it's good to say a little bit about that, but the more language you add the more it's not likely to make it through. i understand the objections... but the objectors should work with you to get more information where it belongs, but [not in this draft]
[20:26:43] <Eliot Lear> <?>
[20:26:56] <marka-isc> ? koster
[20:27:10] <Eliot Lear> <missed the comment>
[20:27:57] <Eliot Lear> <james> i'm not a dhcp guru... i could foresee providers being regulated to not rely on the end point for a request, and that's why the text that is there..
[20:28:16] <Eliot Lear> [jabber scribe must disappear shortly]
[20:28:48] <Eliot Lear> <stig> my problem with the draft is that it covers any type of uri for any purpose.
[20:29:49] <Eliot Lear> <james> i came up with 11 different purposes. and i was sensitive to ralph trying to take back option #s. this gives you 256 URIs...
[20:30:12] <Eliot Lear> Is this sufficiently mature?
[20:30:20] <Eliot Lear> Should the work be continued?
[20:31:02] <Eliot Lear> hmm.. not ready for a wg item
[20:31:04] --- Hankins has left: Lost connection
[20:31:15] <marka-isc> hum not yeat ready for wg itrem
[20:31:16] <Eliot Lear> [sorry guys, i have to go]
[20:31:31] --- Eliot Lear has left
[20:31:31] <marka-isc> Time Options for DHCPv6
[20:31:42] <marka-isc> ralph presenting
[20:32:37] <marka-isc> two new options required for docsis 3.0
[20:33:06] <marka-isc> rfc 868 time servers still needed
[20:33:19] <marka-isc> timoe offset still needed
[20:34:13] <marka-isc> option formats displayes
[20:34:36] --- miya has left
[20:34:58] --- miya has joined
[20:35:03] <marka-isc> <elliot lear> IPv4 problems : DST bit
[20:35:11] <marka-isc> text requested
[20:36:23] <marka-isc> <ted> why does a cable modem need this?
[20:36:58] <marka-isc> answer time-of-day restrictions
[20:38:05] <marka-isc> <ted> would cable labs like to solve this?
[20:38:36] <marka-isc> <ralph> wants this offset
[20:38:56] <marka-isc> <ralph> would cable labs like posix info
[20:39:07] --- Hankins has joined
[20:39:27] <marka-isc> ralph to discuss later
[20:40:09] <marka-isc> hum assign to elliot :-)
[20:40:35] <marka-isc> hum for adopting
[20:40:52] --- william.gilliam@2entwine.net has joined
[20:40:53] <Hankins> i think ralph's mic was off.
[20:41:04] <marka-isc> DHCP Relay agent Request from Multi Address Pool
[20:41:18] <marka-isc> Zi Kang
[20:42:29] <Hankins> i think the mic is still off, isn't it?
[20:46:10] <marka-isc> <ted> in practice the dhcp server use a table
[20:48:04] <marka-isc> <ted> believes existing servers already handing this problem
[20:50:38] --- miya has left: Disconnected
[20:51:05] --- william.gilliam@2entwine.net has left
[20:52:07] <marka-isc> try to find whiteboard time here to determine if there is a problem
[20:53:52] <Hankins> :q
[20:54:03] <marka-isc> DHCP OPtion for Acess Netowork Information
[20:54:17] <marka-isc> sepnser
[20:54:38] <marka-isc> for Jun
[20:54:39] <marka-isc> Li
[20:56:42] --- ogud has joined
[20:57:10] <marka-isc> Ipv6 support not needed
[20:59:38] <marka-isc> <bernie> more work still required. Information flow needs to be clearer
[20:59:56] --- william.gilliam@2entwine.net has joined
[21:02:14] <marka-isc> why not a vendor specific options?
[21:02:42] <marka-isc> needs research to answer
[21:08:05] <marka-isc> <hankins> worry about mobile node
[21:09:20] <marka-isc> hum needs more work before wg item
[21:09:35] <marka-isc> Passive Duplicate Address Detection for DHCP
[21:10:02] <marka-isc> Henning Schulzrinne
[21:10:59] <marka-isc> probems w/ dad
[21:11:04] <marka-isc> packet loss
[21:11:07] <marka-isc> firewalls
[21:11:09] <marka-isc> bugs
[21:12:47] --- ogud has left: Replaced by new connection
[21:12:54] <marka-isc> relay agent sends mac/address pairs to server
[21:12:58] --- ogud has joined
[21:15:02] --- william.gilliam@2entwine.net has left: Logged out
[21:15:34] <marka-isc> <greg dad> text focus on illegal uses but may be misconfiguration
[21:15:59] <marka-isc> detection is important even if no action is taken
[21:17:27] <marka-isc> <greg> may overlap w/ existing ipv6 work
[21:18:15] <marka-isc> <hankins> address to mac binding may give lots of false positives. client identifier vi mac
[21:20:04] <marka-isc> <kim> worried about info volume
[21:20:09] --- levigner has joined
[21:21:04] <marka-isc> <ted> good potential
[21:21:10] --- levigner has left
[21:23:25] <marka-isc> <ted> strong disavantages to remembering mac
[21:24:23] <marka-isc> presenter got desired feedback
[21:24:31] <marka-isc> will come back later
[21:24:51] <marka-isc> Client merging of data from DHCPv[46]
[21:25:39] <marka-isc> focusing on single home problem
[21:26:06] <marka-isc> perhpaps more real life experience needed
[21:26:20] <marka-isc> any comments?
[21:26:51] <marka-isc> <ted> do we expect to acomplish something in the next year? hope?
[21:27:25] <marka-isc> answer: real life exp will help
[21:28:11] <marka-isc> <ted> worried that other solutions will arrive if not published
[21:28:25] <marka-isc> <ted> may do one itself
[21:28:37] <marka-isc> himself
[21:30:00] <marka-isc> real problems being expienced
[21:30:22] <marka-isc> <bernie> simplifying is a good first start
[21:30:29] <marka-isc> <ted> also agrees
[21:32:33] <marka-isc> not ready for wglc
[21:32:34] <marka-isc> DHCP Assignment Notification Option
[21:32:42] <marka-isc> bernie
[21:33:28] <marka-isc> how does the route get into the system
[21:35:27] <marka-isc> assumption DHCP message snooping is bad
[21:38:29] <marka-isc> <hankins> if a client were attached to two relay agents? assume server will send same prefix to both
[21:38:41] <marka-isc> what happens with links fails
[21:39:47] <marka-isc> there is state issues in relkay agent
[21:40:55] <marka-isc> hum for adopting
[21:41:14] <marka-isc> DHCP Cluster
[21:41:33] <marka-isc> Francois Bourdais
[21:42:50] <marka-isc> for TVoDSL, VoIPoDSL
[21:43:42] <marka-isc> multiple pairs of servers to managed
[21:44:03] <marka-isc> database access by servers
[21:46:51] <marka-isc> diagram 4x ( 2x dhcp + ldap) + 1 master ldap -> centralised servers
[21:47:36] <marka-isc> aim for 1M+ clients
[21:49:57] <marka-isc> lost of node talking to central repository for binding state. no failover
[21:50:08] --- venaas has left: Logged out
[21:52:24] <marka-isc> what is trying to be standardised?
[21:56:54] <marka-isc> <ted> are you hoping for this to be implemented?
[21:59:18] <marka-isc> done!!!!
[21:59:24] --- marka-isc has left
[21:59:26] --- Hankins has left: Logged out
[21:59:33] --- dudi has left
[21:59:49] --- raj has left
[21:59:52] --- Ralph Droms has left
[22:00:21] --- frodek has left
[22:00:48] --- ogud has left
[22:01:37] --- jjmbcom has left
[22:17:28] --- mo7sen has left: Disconnected