[00:19:49] --- Ralph has left: Replaced by new connection
[04:20:47] --- Andre has joined
[04:21:06] --- dhc@ietf has joined
[04:21:41] --- dhc@ietf has left
[04:21:49] --- Touchwood has joined
[05:20:38] --- Andre has left
[05:32:19] --- Touchwood has left
[12:18:18] --- rwoundy has joined
[13:33:26] --- ignas has joined
[13:56:53] --- ignas has left: Replaced by new connection
[14:21:09] --- ignas has joined
[15:21:18] --- LOGGING STARTED
[17:18:22] --- Ralph has joined
[17:43:55] --- dhc has joined
[17:44:17] <dhc> hello to anyone listening in Seoul
[17:45:25] <Ralph> The chair is here.
[17:45:34] <dhc> hi, Ralph---glad to see you
[17:45:40] <Ralph> I haven't been able to volunteer anyone as jabber scribe.
[17:45:40] <dhc> this is Barr....
[17:45:53] <Ralph> Ah, thanks for IDing yourself.
[17:45:59] <dhc> sure....
[17:46:16] <dhc> haven't quite figured out how to always display my name, though
[17:49:26] <dhc> hope that someone will scribe for Jabber....
[17:53:56] --- mellon has joined
[17:54:58] --- rwoundy has joined
[17:55:08] <mellon> Ralph has started talking
[17:55:20] <dhc> hi, Ted... this is Barr
[17:55:33] <dhc> thanks for scribing...
[17:55:34] <mellon> Hi Barr. I'm scribing...
[17:55:36] <mellon> No problem.
[17:55:58] <mellon> We're on agenda bashing.
[17:56:24] <mellon> First page is documents we've accepted as wg work items.
[17:56:41] --- islandia has joined
[17:56:56] <mellon> If we've had enough people reading the draft and no significant objections, we can move the draft to last call.
[17:56:59] <dhc> okay... any late additions that you can tell? as in just since the I-D cutoff
[17:57:03] <mellon> Second screen is new drafts.
[17:57:15] <mellon> I think it's the agenda ralph sent out.
[17:57:22] <dhc> right
[17:57:25] <mellon> Page three, three major issues we have to talk about.
[17:57:51] <mellon> First item is that now that we have dual-stack clients, how do we coordinate?
[17:58:18] <mellon> The last three items on screen 2 fit together, we've had requirements for controlling lifetime/duration of information passed through stateless DHCPv6.
[17:58:26] <mellon> One summary, two proposals for how to do it.
[17:58:32] <dhc> right
[17:58:35] <mellon> Update to DHCwg charter. Then update on IPR issues.
[17:58:42] <mellon> I'm just taking notes - no need to chat. :')
[17:58:54] <dhc> :)
[17:58:58] <mellon> Also, discussion on IPR issues.
[17:59:18] <mellon> First item, dhcp option for proxy server configuration. Vijay?
[17:59:50] <mellon> Presentations are very brief.
[17:59:52] --- islandia has left: Disconnected
[17:59:58] --- rwoundy has left
[18:00:06] <mellon> Vijay: new option called proxy server configuration for dhcpv4.
[18:00:22] <mellon> (explaining the draft, which you have of course read)
[18:00:23] --- islandia has joined
[18:00:40] <dhc> hehehe... I actually did read it...
[18:01:00] <mellon> Ralph asks for comments.
[18:01:15] <mellon> A couple of the proxy servers that are listed in the draft already have DHCP options for carrying list of servers for that protocol.
[18:01:21] <mellon> E.g., www, nntp.
[18:01:31] <mellon> Do we need a second option for these proxy servers?
[18:01:36] --- Ted Faber has joined
[18:02:14] --- Ted Faber has left
[18:02:17] <mellon> Ralph: in the abstract I can see that these are just address and proxy inside organization. From dhcp client's point of view, difference between contacting proxy server and real server?
[18:02:19] <dhc> probably not... I dislike duplicated data as a general rule
[18:02:20] <mellon> Vijay: port number.
[18:02:32] <mellon> Question about list of servers?
[18:03:00] <dhc> yes... I don't think we need both a proxy option and an existing option
[18:03:18] --- Ted Faber has joined
[18:03:41] <mellon> (I said it needed some editorial work)
[18:03:48] <dhc> agreed
[18:04:02] <mellon> ralph: we'll do a wglc, then, you can do editorial at the same time.
[18:04:10] <dhc> sounds good
[18:04:20] <mellon> vijay: describes draft.
[18:05:35] --- Ted Faber has left
[18:05:39] <mellon> Ralph: how many have read? (6)
[18:06:04] <dhc> typical
[18:10:19] <mellon> ralph:suppose dhcp client chooses a server, succeeds in downloading the first file, fails to download the second file?
[18:10:34] <mellon> (a lot of other stuff went by, but it was me talking, so no notes - sorry)
[18:10:51] <mellon> vendor-identifying vendor options.
[18:11:00] <dhc> okay
[18:11:18] --- Margaret has joined
[18:11:27] <mellon> This is the option written by Josh Littlefield, based on vendor-specific option in dhcpv6 where option is self-identifying. v4 option takes vendor id from the vendor class option.
[18:11:38] <mellon> This option identifies the vendor in the form of an organization number.
[18:12:05] <dhc> who administers? IANA? or some neutral party, like the SIC codes?
[18:12:06] <mellon> The last time we talked about this, question about how to describe semantics of multiple options in a DHCP message; josh has recast it so that individual options are encapsulated inside of single option.
[18:12:21] <mellon> 6 readers.
[18:12:24] <dhc> probably a good idea
[18:13:14] <mellon> Ralph says that the organization id is same as in the DHCPv6 version of the option.
[18:13:21] --- raj@cisco has joined
[18:13:24] <mellon> Ralph: I think this is ready for WGLC.
[18:13:30] <dhc> good--consistency
[18:13:40] <mellon> Next one I thought Barr had published new draft, but not online anywhere, so sorry for jumping the gun.
[18:13:48] <mellon> Next, node-specific client ids.
[18:13:56] <dhc> *shrug*
[18:13:58] <mellon> Margaret: enterprise number is number registered with IANA.
[18:14:22] <dhc> thanks
[18:16:33] --- sob has joined
[18:17:10] <mellon> (did a spiel on 3315id draft - please read it if you haven't, send comments)
[18:17:21] <mellon> Ralph asked if WGLC was okay, the room didn't object.
[18:17:29] <dhc> have read it
[18:17:32] <mellon> Rapid commit option for v4.
[18:17:52] <mellon> thansk. :')
[18:18:47] <mellon> The main changes are a detailed flow diagram and some nice text improvements, including administrative considerations.
[18:18:55] <mellon> Question is whether to go to WGLC at this point.
[18:19:36] <mellon> (I said it looks good, maybe a few editorial nits)
[18:19:44] <mellon> Ralph: objections to going to WGLC?
[18:19:47] <mellon> (no objections)
[18:19:48] <dhc> none
[18:19:54] <mellon> Vijay again.
[18:20:04] <mellon> Remote boot support in dhcpv6.
[18:20:29] <mellon> Basically the same as for DHCPv4.
[18:20:41] <dhc> no issues with that
[18:21:33] <mellon> Margaret: quesiton on this option. I'm not sure what happens if I'm a dual-stack node and I get both dhcpv4 and dhcpv6.
[18:21:50] <mellon> Ralph: talk about during dual-stack discussion.
[18:22:07] <mellon> Ralph:not yet ready for last call.
[18:22:25] <mellon> Vijay: tunnel endpoint option.
[18:23:19] <dhc> kk
[18:24:24] <mellon> This is intended for routers, there's some concern about whether this works for the transport people.
[18:24:46] <mellon> Dave Thaler: since this is not for configuring clients, is for configuring routers, not indistinguishable from a host.
[18:24:46] <dhc> ..
[18:24:58] <mellon> I think it's a slippery slope to go down. There's been lots of work in other wgs about this.
[18:25:07] <mellon> Maybe this is the wrong place.
[18:25:20] <mellon> Margaret: this isn't like configuring a client either in regards to things like security considerations.
[18:25:22] <dhc> maybe kick to ADs to find a proper home for it?
[18:25:33] <mellon> Dave: right.
[18:26:06] <mellon> Dave: there's a bunch of different ways that people configure routers. All kinds of other protocols. Specific router vendors looking at doing complete router configs off of DHCP, if not they will use the same mechanism they're using for other things.
[18:26:27] <mellon> Joe Touch ISI: any way to throw prefix stuff up front, padding it, making it aligned?
[18:26:45] <mellon> me; beginning of packet isn't aligned anyway.
[18:27:01] <mellon> ralph: not ready for wglc. seems to me that it's not a DHC working group item.
[18:27:17] <dhc> isn't there a caveat in 2131 that DHCP is NOT meant for configuring routers?
[18:27:27] <mellon> Margaret: the draft itself seems to be published as a work item, maybe should reconsider whether this should be a work item at all.
[18:27:50] <mellon> ralph: my internal thinking when we took it on was it was aimed at hosts. Now we know it's for routers it's a different issue.
[18:28:53] <mellon> ted: suggest finding the wg that's the right one to take this on as a work item.
[18:29:03] <mellon> so it looks like it's being dropped as a DHC work item.
[18:29:07] --- dhc has left
[18:29:16] --- dhc has joined
[18:29:17] <mellon> reclassifying dhcpv4 options.
[18:29:37] <mellon> author redrafted this by taking the all but the last 32 site-specific options and turning them into available options for use in DHCP.
[18:29:51] <mellon> author has also added a fairly detailed specification for how to turn these options into options that can be allocated.
[18:30:19] <mellon> We will go through a process where the ietf is well-informed that we are doing this, so that we can get people who have snarfed options illegally can confess.
[18:30:59] <dhc> yeah, like that will work....
[18:31:20] <mellon> We're going to move it to last call, any edits can be done then.
[18:31:25] <dhc> right
[18:31:40] <mellon> soohong park - configuring ipv6inipv4 tunnels.
[18:32:13] <mellon> Allows a dual stack host to bootstrap itself into a disconnected IPv6 network.
[18:33:07] --- raj@cisco has left: Disconnected
[18:33:07] --- islandia has left: Disconnected
[18:35:24] --- raj@cisco has joined
[18:35:45] --- ignas has joined
[18:35:51] <mellon> Margaret:I don't think we should block about accepting, but have we asked v6ops about reviewing this?
[18:36:14] <mellon> Thaler: I was going to suggest that it be blocked until v6ops reviews.
[18:36:31] <dhc> ...
[18:37:18] <mellon> Thaler: this is in the enterprise scenario, right?
[18:37:36] <mellon> Ralph: I thought service provider scenario where you've got a customer site that uses configured tunnel to get out of v4space.
[18:37:54] <mellon> Let me ask a process question - what is the state of v6ops wg with respect to taking on new work items?
[18:38:04] <mellon> Like, can we make them take this item?
[18:38:17] --- islandia has joined
[18:38:48] <mellon> Margaret: not a-d for v6ops. My take on this is it's a useful DHCP configuration mechanism for something that's already at ps, details ought to be reviewed by v6ops. Whether block accepting it based on that may not be important - is this already a charter item?
[18:39:06] <mellon> Ralph:trying to figure out how to squeeze it in under existing charter.
[18:39:24] <mellon> Ralph: grey area is, it is yet another piece of configuration information, which we have a charter item to accomplish.
[18:39:45] <mellon> OTOH, it's somewhat different in the sense that it has to do with v4-v6 transition, not just "here's a server address that you can use."
[18:40:19] <mellon> Margaret: agree it's a little greyer. I think we ought to talk about it. Consider charter issue raised for the next bunch of items.
[18:40:50] <mellon> Margaret: that sounds good. I want to reiterate that this is a useful thing to do, not trying to say we shouldn't do it.
[18:41:25] <mellon> micro-block.
[18:41:30] <dhc> kk
[18:42:42] --- raj@cisco has left
[18:43:09] <mellon> So the problem that this tries to solve is that if we do static IP pools on routers, it's not efficient - you wind up wasting a lot of addresses.
[18:43:45] <Ralph> Any clue about how this compares to DHCPv6 prefix delegation?
[18:43:48] <mellon> Most efficient way is to do random address allocation.
[18:43:50] <mellon> Not the same.
[18:43:57] --- raj has joined
[18:43:58] <Ralph> And, there's the (now expired) ODAP stuff.
[18:44:21] <mellon> The problem with random allocation is that you have a nightmare of host address routes.
[18:44:23] <Ralph> We'll probably need a specific explanation about how it's different.
[18:44:42] <mellon> For this to work you've got to have point-to-point connection to client - no gateway you can assign to customer.
[18:45:09] <mellon> So here we do micro-blocking address allocation. Very simple DHCP extension using option 82.
[18:45:33] <mellon> DHCP proxy server (usually edge router) go to server ask for block of addresses instead of just one.
[18:45:43] <mellon> Before server gave out one address at a time, now it gives out a block of addresses.
[18:46:06] <mellon> For completeness, we say the server can give out block and single address, but server needs to remember who ask for this block. Always give same block to same server.
[18:47:02] <mellon> Now obviously block size can be customized. Block size is determined by network applications - how scalable do you want routing be. /32 is like random allocation. If you go to other extreme, waste of address space, defeats purpose of this scheme.
[18:47:30] <mellon> Works for both ptop and ptomultipoint clients.
[18:47:35] <dhc> do we need a generalized model for allocation? so that server can essentially treat clients and proxies in the same way?
[18:48:03] <mellon> I'm not sure what you're asking.
[18:48:22] <dhc> that is, client could request multiple addresses (there have been some requests for this in the past)
[18:48:34] <mellon> Ah. No, that's not what's being talked about here. This is a relay agent option.
[18:48:40] <dhc> which is almost a proxy function
[18:49:40] <dhc> I will have to re-read the draft... my impression was it was more general than just a relay agent
[18:50:34] <mellon> It allows the server to be the thing that maintains the micro-blocks.
[18:50:40] <raj> In case it matters, I'm the author of the subnet allocation option (ODAP, as Ralph mentioned) and I plan to update and reissue the draft in the next few months.
[18:50:49] <mellon> That is, the server can allocate addresses out of the block rather than the edge router doing it.
[18:50:55] <dhc> kk--will look forward to it
[18:52:00] <mellon> raj - yes, these two things seem to solve the same problem differently.
[18:52:55] <raj> subnet allocation allows for either the edge router to do the allocation of addresses from the block (what we called "delegation"), or the central router to retain that control with the edge system being a relay.
[18:52:57] --- Margaret has left
[18:53:14] <mellon> (there's a lot of discussion going on here - it's hard to capture)
[18:53:44] <mellon> Ralph is pointing out that if the edge router is the DHCP server, then you have the problem that the edge router doesn't have the configuration information that the server has.
[18:54:12] <mellon> It sounds like there's no lifetime for these block allocations.
[18:54:21] <mellon> Thaler: where does prefix length come from?
[18:54:31] <mellon> Author: prefix is statically configured by service provider.
[18:54:33] <raj> Some of that configuration would be passed in options the the edge router.
[18:54:39] <mellon> Thaler: microblock size, who determines it?
[18:54:44] <mellon> Author: service provider.
[18:54:49] <mellon> raj - right, that's really hard.
[18:54:57] <raj> Subnets which are allocated are done so including a lease time.
[18:55:03] <Ralph> Yes, no lifetime as far as I can tell. I don't see how the block is released back to the server.
[18:55:28] <mellon> Thaler: for comparison, madcap protocol provides an equivalent thing, and so the question is, maybe compare the packet formats and see if they should be common.
[18:55:57] <mellon> author:may send email.
[18:55:58] <Ralph> Isn't it similar to prefix delegation?
[18:56:00] <mellon> thaler: rfc2730.
[18:56:17] <mellon> ???: if proxy server exhausted pool, will it ask extension to the pool?
[18:56:28] <mellon> author: if you exhaust addresses, request another block.
[18:56:33] <mellon> ???: that block may be entirely different?
[18:56:36] <Ralph> Last Q from Subir Das
[18:56:43] <mellon> author: may be completely unrelated you were assigned before.
[18:56:49] --- sra has joined
[18:56:53] <mellon> author: so how your routing information is constructed is based on this block.
[18:57:01] <raj> Sounds as if this author and I should get together. Sounds as if we're doing the same thing.
[18:57:06] <mellon> author: if you are using /32 case, this is like asking for another address, can be from anywehre.
[18:57:11] <mellon> raj - I agree.
[18:57:33] <mellon> author: as long as you've given the block, up to proxy server to allocate.
[18:57:44] <Ralph> raj - I'm about to make exactly that point about similarity to ODAP.
[18:57:54] <mellon> author: don't want to say "I have half block unused" we are not trying to get into that.
[18:58:06] <mellon> ???: when proxy server asks the block, has been configured by the same server?
[18:58:11] <mellon> author:that's the local decision.
[18:59:00] <mellon> ralph: process. I think this is another draft in which we have to come up with a charter item.
[18:59:31] <mellon> second, we have at least two bits of sort of prior art to consider. First is DHCPv6 prefix delegation. Mostly different, but you'd better look at it because folks will ask.
[18:59:45] <raj> Subnet allocation was already accepted as a WG item so should already be on the charter.
[18:59:46] <mellon> Second, we've had a draft published that does roughly the same thing - on-demand address pools.
[19:00:06] <mellon> raj - is that your name or an acronym? :'}
[19:00:20] <mellon> Oh, richard johnson?
[19:00:34] <raj> ODAP is the marketing name and internal name in Cisco. "Subnet Allocation" was the name of the option.
[19:00:39] <mellon> author:old draft doesn't talk about routing.
[19:00:41] <raj> Yes, raj is Richard Johnson
[19:01:01] <raj> I will include the routing part of in the draft update.
[19:01:26] --- knollPOI has joined
[19:01:31] --- hta has joined
[19:02:28] <mellon> vendor-specific option for relay agent information option.
[19:02:37] <dhc> kk
[19:02:54] <mellon> mark stapp wrote up draft that describes how to use vendor-specific suboption. Works just like vendor-self-identifying option for which josh littlefield submitted a draft earlier.
[19:03:01] <mellon> Useful to be able to define relay agent suboptions.
[19:03:15] <dhc> agreed
[19:03:52] <Ralph> Ted: concerned that we will have non-standardized sub-options
[19:04:16] <Ralph> Ted: more of a problem with relay agent options.
[19:05:10] <mellon> Ralph respectfully disagrees with my concern. :')
[19:05:27] <mellon> stig venaas - renumbering requirements.
[19:05:51] <dhc> :)
[19:06:43] <mellon> main issue is that you might use stateless addrconf but use DHCP for getting stateless info - e.g., ntp server, etc. THe problem with this is that if a site renumbers or configuration changes, no way to tell client to reconfigure.
[19:06:54] <mellon> Normally would have lease time for address, client would reconfigure both address and other things.
[19:07:17] <mellon> If you only get stateless, no reason for client to contact server. Some implementations might never contact server. OThers might do it daily or hourly.
[19:07:43] <mellon> Client will notice renumbering, but will not notice changes that don't have to do with renumbering.
[19:07:54] <mellon> We would like to handle both planned and unplanned changes.
[19:08:27] <mellon> - Must support planned and unplanned renumbering
[19:08:40] <mellon> - Security - avoid DOS attacks through reconfigure messages.
[19:08:47] <mellon> -0 must update options even if network is not renunbered.
[19:08:51] <mellon> ...?
[19:09:00] <mellon> This is really a problem statement, but we listed some candidate solutions.
[19:09:35] <mellon> First, when client gets new address where it notices new prefix, contacts DHCP server. Only works when renumbered.
[19:09:45] <mellon> Second, toggle 'O' flag in RA.
[19:09:54] <mellon> Third, add new flag in RA that tells clients to send information-request.
[19:10:05] <mellon> Fourth, add a reconfigure message.
[19:10:17] <mellon> Fifth, convey a configuration lifetime to clients, client sends new request when lifetime expires.
[19:10:43] <mellon> Ralph: so this is an issue that we need to solve.
[19:11:18] <mellon> More readers.
[19:11:33] <Ralph> Ted: Thanks for writing the doc...very nice.
[19:11:42] <Ralph> Ted: there's only one solution - the lifetime.
[19:12:15] <mellon> Ralph: want to just decide whether to make this a wg item, not talk about solutions.
[19:12:26] <mellon> jinmei: description abotu security concerns should be clearer, please see comment on list.
[19:12:27] <Ralph> Jinmei: minor comment - description of security concerns should be clearer (minor comment)
[19:12:37] <mellon> Any objection to taking on as wg item?
[19:12:37] <dhc> I think it is an appropriate work item
[19:13:00] <mellon> Ralph: one potential solution, stig will talk about lifetime option.
[19:14:27] <Ralph> Lifetime option good for planned updates; must use short lifetime for unplanned changes.
[19:16:04] <mellon> Thaler: minor comment, you said after it expires wait a random time, then query. Why not before expiry?
[19:16:13] <mellon> stig: have to think about that.
[19:16:39] <dhc> Ted, thanks for scribing... I've had an unexpected interruption that demands my attention... will leave the session open, but am leaving the session
[19:17:36] <Ralph> Ralph: What about other times for DHCP-light exchanges? E.g., DNA
[19:17:50] <Ralph> Ted: Yes, should be done when prefix changes.
[19:18:19] <Ralph> Ted: MUST be implemented for clients that do DHCPv6-light.
[19:18:36] <mellon> Jinmae: just skimmed draft, not sure. Not sure what behavior is expected when the client fails to update existing information.
[19:18:46] <mellon> I probably need to reread this draft. Maybe will comment later.
[19:19:10] <mellon> stig: not sure either. I would say just give up or wait until you have other reasons to reconfigure. Maybe if it's an hour, retry every hour.
[19:19:37] <mellon> ANother proposal for multicast reconfiguration, from vijay.
[19:25:05] <mellon> ralph: one comment, strikes me there are two separate pieces to this - how to trigger clients, and how to get the message across to indicate that clients should be triggered.
[19:25:30] <mellon> jinmei: I think this is a useful idea, I just sent comment on this to ml last night
[19:25:49] <mellon> main concern on this, I guess you are trying to make this proposal compatible with existing implementation, specification as much as possible.
[19:26:06] <mellon> I see inconsistencies due to this. So probably I am wrong, please check comments on mailing list, would like to see response.
[19:26:41] <mellon> Margaret: more a question than a comment. It seems dependent on idea that there is going to be one default router on every network segment, which will be the relay agent, or can talk to relay agent. Is it constrained to being useful in taht type of configuration or not?
[19:26:47] <mellon> ralph: can you explain more?
[19:27:20] <mellon> margaret: it's the part about getting the router to send the option that I'm trying to understand, if there are multiple routers, relay agents could be on any of them.
[19:27:40] <mellon> margaret: default routers might be different for differnet hosts, relay agent might not even be on router.
[19:27:59] <mellon> vijay: when default router is not running, relay can put off the developer flag.
[19:28:07] <mellon> margaret: maybe I should take this to ml.
[19:28:32] <mellon> thaler: if you have multiple routers, the stateless addrconf spec says host behavior is controlled by other stateful config bit in last RA received.
[19:28:45] <mellon> So the question is if you have multiple ones, are they all consistent?
[19:28:52] <mellon> If they are inconsistent, what is host behavior?
[19:29:10] <mellon> vijay: there is a transaction mechanism for dealing with consecutive reconfigure messages.
[19:29:55] --- knollPOI has left: Replaced by new connection
[19:30:01] <mellon> ralph: objection to taking on draft as work item?
[19:30:04] <mellon> margaret: not sure.
[19:30:12] <mellon> not sure if it would work.
[19:30:21] <mellon> margaret: are we implying it's a correct mechanism?
[19:30:30] <mellon> ralph: no, we say it's correct when we pass it out of the wg.
[19:30:49] <mellon> thomas: my preference is I don't see the need to rush adopting solutions as wg docs.
[19:31:04] <mellon> thomas: my experience in wgs is it's harder to choose among competing proposals that are already wg docs.
[19:31:44] <mellon> margaret: your call to make. if we have two solutions and don't know which to pursue, doesn't make sense to bring both on unless answer might be that there should be two.
[19:32:00] <mellon> ralph: that sort of wasn't the question I was asking. I was asking if there was a reason to handle them differently.
[19:32:15] <mellon> ??: first proposed solution is more than a proposed solution for this particular problem.
[19:32:27] <mellon> ??: it makes no sense to have configuration information without a lifetime.
[19:33:37] <mellon> me: would like to see wg adopt lifetime draft, not adopt reconfigure draft.
[19:34:54] <mellon> ralph: experience with reconfigure dhcpv4, we put it into protocol very late. seocndly, has security issues.
[19:35:25] <mellon> ralph: piggybacking on RA mechnaism in IPv6 to secure RAs independent of flags in RAs, we can potentially address those two problems. Could get this into protocol early enough.
[19:35:37] <mellon> jinmei: I guess I tend to agree with Ted.
[19:36:15] <mellon> jinmei: I think this is useful idea, but seems like more powerful mechanism that may have good and bad significant effect in entire system. May be some overlapping points, but I do not necessarily think these proposals are competing each other completely.
[19:36:30] <mellon> If we need to decide soemthing in this meeting I'd like to have lifetime option as wg item, not this one.
[19:37:57] <mellon> stig: I htink lifetime could be useful in cases wher eyou don't use stateless autoconfig - e.g., static ip address configuration.
[19:38:19] <mellon> Bob Hinden: since stateless DHCP options are fairly new, wonder if we should go back and add lifetimes.
[19:38:39] <mellon> ralph: the lifetimne option would not apply just to stateless dhcpv6, I don't think.
[19:39:06] <mellon> Bob: let me rephrase. for v6-style options we should just say they should always need lifetimes. May want them to have different lifetimes, maybe should just fix it.
[19:39:47] <mellon> kre: was thinking how do you have different lifetimes? If you go to ask for new config information, might as well ask for all of it. One lifetime is enough, without re-adding lifetimes to other options.
[19:40:37] <mellon> pekka: preferble not to have any kind of lifetimes, want to run client and quit it, don't want to have some kind of process that sticks around and keeps count of the lifetimes and checks every now and then.
[19:41:06] <mellon> ralph: I'm going to assume it's okay to keep rpoblem statement draft as wg item.
[19:41:26] <mellon> objection to looking at other two drafts individually?
[19:41:43] <mellon> objection to taking on lifetime draft as wg item?
[19:41:50] <mellon> what about reconfigure option?
[19:42:12] <mellon> reconfigure we leave as individual submission.
[19:42:35] <mellon> we'll start amiling list discussion about how to address the concerns that were addressed here. THose of you who expressed concerns about that draft, please discuss them on mailing list.
[19:43:21] <mellon> So discussion on dual-stack.
[19:43:41] <mellon> Should we enhance DHCPv6 to support v4 options, or not?
[19:43:53] <mellon> Dual stack draft from stig venaas.
[19:44:40] <mellon> Today you can use DHCPv4 to get v4 information, use DHCPv6 to get v6 information.
[19:45:00] <mellon> If you want both kinds, right now you have to use v4 and v6. What if you get competing information?
[19:45:13] <mellon> What about conflicts with configuration files?
[19:45:30] <mellon> Today I often have IPv6 information in config files, have v4 info in v4 files, don't want to lose Ipv6 settings.
[19:45:37] <mellon> In some cases might be running v4 and v6 on different interfaces.
[19:45:47] <mellon> Some settings are interface-specific, some aren't.
[19:46:11] <mellon> Also, might try to only use settings for v6 server for v6-related things, but what about things like NTP server, DNS search path which aren't address-family-specific?
[19:46:55] <mellon> There are some cases where IPv4 and IPv6 might be managed by different organizations, might be difficult to co-ordinate.
[19:47:07] <mellon> When merging, options might not have exactly the same behavior.
[19:47:39] <mellon> Potential solutions - two separate DHCP servers, come up with guidelines for client, administrator, etc.
[19:48:03] <mellon> Another solution - just use DHCPv6 server, get IPv4 information from it. IPv4 addresses?
[19:49:09] <mellon> kre: it's certainly a tough problem, but the title's all wrong. The problem has nothing to do with dual-stack; it's just that you're getting configuration info from multiple places. This can happen when you have two interfaces. This is a general problem with DHCP.
[19:49:09] --- hta has left: Disconnected
[19:49:40] <mellon> stig: agree,but new thing now is this will be a very common problem.
[19:49:41] <mellon> Margaret: I don't agree. I think there are some important differences.
[19:50:03] --- hta has joined
[19:50:21] <mellon> If you've got two interfaces, two sets of DHCP information ebcause you put out request on both interfaces, what your eally want is one set of DHCP information, and you've got two. In the dual stack world, I've got to put out two requests to get all the information I want. In order to even potentially get full set configuration information.
[19:51:13] <mellon> margaret: was vitally important to find solution last several times.
[19:51:22] <mellon> I don't know for sure that we know how to solve this problem. Not unsolvable.
[19:52:07] <mellon> Margaret: if we solve that problem we may as a side effect solve the problem kre was mentioning.
[19:53:53] <mellon> patrik faltstrom: this looks a little bit messy. the first thing I see is when you are on a machine might have one or multiple interfaces, might be sending DHCP query on one or more, get back different results. Already when that happens you might get back multiple result sets that might have to be merged.
[19:54:06] <mellon> So now with two different address families we have an orthogonal vector from that.
[19:54:22] <mellon> Important thing to talk about is whether info you get back should only be bound to that address family.
[19:54:44] <mellon> The only right way of trying to move forward is to say that yes we have these two protocols, but data should be as much as possible address-family-independent.
[19:55:45] <mellon> If you have data that is AF-dependent, that should be clearly specified. E.g., search path in DNS, if you get different response for v4 vs v6, is implication that you should use different search path for v4 than for v6? Instead, we have the same kind of merging the data problem as if you used DHCPv4 query over two different interfaces.
[19:55:59] <mellon> Trying to look at the data youg et back over DHCP as family-independent is a good thing.
[19:56:15] <mellon> Ralph: we have two things to discuss. Should we take this on as wg item. Second is what's the right solution.
[19:56:36] <mellon> Thaler: agree with margaret is that there are two separate problems.
[19:56:39] <mellon> Very little overlap.
[19:56:59] <mellon> In the one case, two interfaces, no way that DHCP servers can know about each other.
[19:57:25] <mellon> The other scenario is the dual-stack scenario where typically DHCP servers are controlled by same administration. The problem is that there's no way for the admin who wants to force some ordering to do that.
[19:58:07] <mellon> Would like to concentrate on that problem.
[19:58:59] <mellon> Harald: I had a problem with some of your specs because I think that they are incomplete.
[19:59:16] <mellon> The reason why you chose to ship them while incomplete is that you didn't know how to solve the problem.
[19:59:23] <mellon> What my admin hat has a problem with is the incompleteness.
[19:59:58] <mellon> Now, I am an engineer who is used to looking at internet as a tool for getting things done. In this particular case, DHCP is a mechanism that I want to be able to solve 90% of problem, shouldn't fail fatally in the edge cases.
[20:00:18] <mellon> The difference between multihoming and DHCPv6 is multihoming is uncommon, dual-stack is common. Critical that you solve it.
[20:00:23] <mellon> You know better than me how to solve it.
[20:00:33] <mellon> Changed from being nice to solve to being critical to solve.
[20:00:45] <mellon> Margaret: I thought the draft was pretty good, would support adopting it.
[20:01:01] <mellon> I do think it could clarify that multihoming problem and this problem are not the same problem.
[20:01:20] <mellon> Would be nice if application folks could help us to know more what the proiblem is for application level stuff that doesn't know what IP version it's running over.
[20:01:59] <mellon> Patrik: In general as margaret said between the lines it's always better for applications the more it doesn't have to know about multiple address families.
[20:02:11] <mellon> That said, in some cases maybe applications people are lazy and think they don't have to know about that.
[20:02:38] <mellon> Regarding what Harald said, it's not only the case when moving from v4 to v6, but also number of ipsec tunnels, laptops get multiple interfaces where one is physical, not logical.
[20:02:38] --- ignas has left: Disconnected
[20:02:54] <mellon> Especially with things like search path.
[20:03:14] <mellon> looks like this is really important.
[20:03:26] <mellon> kre: agree with patrik, mostly. Disagree with what margaret said.
[20:03:32] <mellon> I don't think these are definitely different problems.
[20:03:39] <mellon> Dual-stack case is subproblem of big problem.
[20:03:53] <mellon> I'm yet to be convinced that there is a problem in the dual-stack case.
[20:04:03] <mellon> Where servers are managed by the same administration.
[20:04:46] --- swb has joined
[20:04:49] <mellon> Practically speaking it doesn't matter how you get to your NTP server as long as it works.
[20:05:16] <mellon> Margaret: that's an argument for why we don't need v6.
[20:05:53] --- swb has left
[20:07:40] --- narten has joined
[20:08:07] <mellon> Bob Hinden: the IETF as a whole really needs to think about this.
[20:08:12] <Ralph> Ted: dual-stacking is a hard problem.. We need to avoid tubing on simple answers that aren't comprehensive.
[20:08:15] <mellon> Margaret: my experience with DHCP is all on the client side.
[20:08:35] <mellon> but I think we really have to solve this.
[20:09:20] <mellon> We're going to skip the cadar-dhc-dhcpv6 draft.
[20:09:48] <mellon> We need to update wg charter, three rfcs were just published about ipr situation, I haven't had time to digest them.
[20:10:17] <mellon> RFC3667, 3668, 3669
[20:11:00] <mellon> Rob austein: former cochair of ipr wg. I do not believe that anything in there is a substantive change.
[20:11:18] <mellon> Really the issue, disclosure of IPR, whether to go ahead. Rules haven't changed, just documenting existing procedure.
[20:11:32] <mellon> Pekka: I just walk in here, not sure what kind of issue, could you just mention briefly what this IPR pertains to?
[20:11:42] <mellon> Ralph: suggest you look at WG mailing list archive.
[20:14:08] <mellon> Charter issues. We need to review charter for progress on existing items, update for new work.
[20:15:46] <mellon> We have started to address security issues, but that's slowed down.
[20:15:56] <mellon> We do have an initiative in place to review RFC3118.
[20:16:07] <mellon> Any changes?
[20:16:43] <mellon> Next, write an analysus of the DHCP specifciation, including 2131 and 2132. We had two conference calls last week in which we took published draft with list of RFC2131 issues and got some high-bandwidth interaction about those issues.
[20:17:01] <mellon> That draft will be updated based on results of two phone calls last week, will continue to move it forward. Not doing 2132 yet, first doing 2131.
[20:17:42] <mellon> Current charter has a long list of drafts that represent work in progress. List is out of date. We need to do somethign with that part of the charter. My suggestion is to drop the list - I don't think we need it in the charter.
[20:18:31] <mellon> Thomas: In principle, removing list of drafts is probably right. Identifying wg documents and what wg is working on is needed. There is a long list of wg documents that the wg isn't really working on anymore. Need to clean up list.
[20:18:36] <mellon> Ralph: Six-month expiration?
[20:18:54] <mellon> Thomas: it's happened that people have resubmitted. Documents don't necessarily expire, author can say please restore.
[20:19:05] <mellon> Ralph: don't think it's been a problem in this wg.
[20:19:18] <mellon> Thomas: one question, if a documetn expires, does it disappear from list of documents on wg page?
[20:19:29] <mellon> ralph: I don't know, seems like an IETF process issue.
[20:19:36] <mellon> thomas: (somebody said it does go away)
[20:19:52] <mellon> ralph: will generate a list of drafts, post it to the mailing list, we'll decide which to explicitly expire.
[20:20:09] <mellon> Thomas: just to clarify, technically secretary has database of all wg docs, need to tell them that a doc is no longer a wg doc.
[20:20:34] <mellon> New charter items. Stateless DHCPv6 reconfiguration.
[20:21:23] <mellon> The problem outlined by the chown renumbering draft. Take it on as a separate charter item?
[20:21:53] <mellon> dual-stack issues. take them up?
[20:22:01] <mellon> Will draft some text, post on list.
[20:22:21] <mellon> What were the other items we had that we need to think of as charter items?
[20:23:17] <mellon> Thomas: comment on microblock. One of the meta-issues that this group ought to be considering is the whole question of the DHCP proxy architecture. This is another example of an option about proxying. It would be nice if some people could step back and look at what the architecture should be like with regards to proxy.
[20:23:45] <mellon> Dave: note taker hat, other drafts? The other one was vendor-specific suboptions of RAIO thing.
[20:24:18] <mellon> Ralph: proxy architecture issue.
[20:24:32] <mellon> I'm not sure quite what/where the problem is that we need to be considering.
[20:24:46] <mellon> Thomas: let's take it offline, on list or in hallway.
[20:26:00] --- Ole has joined
[20:26:45] --- sra has left: Disconnected
[20:27:00] --- Ole has left
[20:27:05] --- mellon has left: Disconnected
[20:28:20] --- sob has left
[20:28:32] --- raj has left
[20:28:35] --- islandia has left
[20:28:47] --- hta has left: Disconnected
[20:28:59] --- narten has left: Disconnected
[20:35:23] --- Ralph has left: Replaced by new connection
[20:37:59] --- hta has joined
[20:57:49] --- hta has left: Disconnected
[20:58:03] --- hta has joined
[21:14:51] --- hta has left: Disconnected
[22:37:28] --- dhc has left
[23:12:42] --- Ralph has joined