[08:53:42] --- droms has joined
[09:08:26] --- droms has left: Replaced by new connection
[09:10:53] --- droms has joined
[09:20:13] --- droms has left: Disconnected
[10:08:25] --- mike893 has joined
[10:25:07] --- dhc has joined
[10:25:25] --- dhc has left
[10:27:38] --- droms has joined
[10:35:04] --- peterd has joined
[10:40:01] --- hkruse has joined
[10:44:14] --- droms has left: Replaced by new connection
[10:46:37] --- touchwood has joined
[10:51:00] --- dhc has joined
[10:51:40] --- yushun has joined
[10:52:51] --- timchown has joined
[10:53:13] <timchown> hi, i'll type in any major comments from the room, but not every word :)
[10:53:47] <timchown> rapid commit IPR claim issue with Samsung has been resolved
[10:53:59] <timchown> no objections to now moving rapid commit forward
[10:54:22] <timchown> also IPR by PackFront on subscriber ID draft
[10:54:48] <timchown> have contacted them to request zero cost licensing, rather than "reasonable non discriminatory terms"
[10:54:58] --- Barr has joined
[10:55:01] <timchown> no response from PacketFront yet to Ralph
[10:55:25] <timchown> WG currently has draft on hold until this is resolved
[10:55:46] <Barr> the IPR issue is still with us, I don't think we should advance the draft until it's resolved
[10:56:11] <timchown> that is current WG consensus
[10:56:29] <timchown> problem is no contact path to PacketFront
[10:56:58] <timchown> Does anyone in channel have info?
[10:57:04] --- dthaler has joined
[10:57:08] <Barr> let me quickly search
[10:57:11] <timchown> ok
[10:57:53] --- Tina has joined
[10:58:00] <timchown> question is what can authors do while WG has draft in stasis
[10:58:05] <Barr> no mention of IPR claims on their website
[10:58:30] <timchown> Ralph: could progress it with IPR pointer, or leave it in stasis
[10:58:38] <Barr> we've been round and around on this issue for a while, already
[10:59:05] --- tuy has joined
[10:59:20] <Barr> if we leave the draft in stasis, either PacketFront will take an active role to advance the draft (assuming they want to resolve it) or will just go away
[10:59:28] <timchown> Margaret: WG can forge ahead if it wants to
[11:00:02] <timchown> will make that comment in room
[11:00:47] <Barr> thanks... I think the only reason PacketFront raised the IPR issue is that it must be important to them in some way -- the draft in stasis may force them to be more clear about it
[11:01:03] <timchown> Ralph: concern is by incorporating tech into dhcp standards based on ipr encumbered tech we are putting implementors and users into positin of having to pay rotyalties
[11:01:20] <timchown> ok, not had chance to say that yet :)
[11:01:55] <Barr> absolutely -- any individual or organization without deep pockets will simply ignore the draft rather than risk crippling payments and /or legal action
[11:02:07] <Barr> that would damage the credibility of the standards process
[11:02:13] <timchown> Margaret: sometimes more than one proposal to solve something, so wg may pick non-encumbered path
[11:02:49] <timchown> Ralph: wg chair off: this is not a key component of dhcp standard
[11:03:13] <Barr> or can withdraw or deprecate documents when an IPR claim is made after publication
[11:03:49] <timchown> room response to barr: it's been months!
[11:03:58] --- droms has joined
[11:04:18] <timchown> Margaret: it may not be important to them; ietf rules just require them to lodge the ipr statement
[11:04:23] <Barr> so, they're not playing fair
[11:04:58] <timchown> Ralph: we need to go to mail list for consensus
[11:05:03] <Barr> agreed
[11:05:14] <timchown> Ralph: or does room have opinion?
[11:05:31] <timchown> Ralph: hum: 3 part question (ouch!!)
[11:06:04] <timchown> Ralph: ok, 2 parts... do we pick it up, or should we leave it in stasis for now waiting for "further developments"?
[11:06:17] <timchown> Ralph hum: progress. loud hum
[11:06:22] <Barr> leave in statis
[11:06:24] <timchown> hum: statis - silence
[11:06:38] <Barr> well, I always WAS the odd one
[11:06:42] <timchown> Ralph: hum acknowledged
[11:06:50] <timchown> :)
[11:07:28] <timchown> Next up: Client FQDN Options
[11:07:45] <timchown> draft-volz-dhc-dhcpv6-fqn-00
[11:07:59] <timchown> based on dhcpv4 option
[11:08:12] <timchown> has 3 of 4 bits of dhcpv4 option
[11:08:19] --- vm has joined
[11:08:48] <timchown> alloow non-terminal partial names, server can fill in fqdn
[11:09:11] <timchown> client uses solicit/request, server sends advertise/reply
[11:09:48] <Barr> I've read the draft... you don't need to reprise the presentation, just the questions/answers
[11:11:57] --- tskj has joined
[11:12:06] <timchown> ok
[11:12:25] --- narten has joined
[11:13:05] <timchown> Pekka: what is security model for updating the fqdn in the dns?
[11:13:18] <timchown> What prevent user saying I want to be www.foo.com?
[11:13:25] --- yushun has left: Disconnected
[11:13:26] <timchown> Volz: outside scope
[11:13:50] <timchown> server policy issue
[11:13:56] <timchown> server should police
[11:13:57] <Barr> actually, DNS update rules should apply here... see Namedroppers list or DNS-EXTS working group
[11:14:17] <timchown> volz making that point now
[11:14:39] <timchown> policy could be duid based for example
[11:15:22] --- yushun has joined
[11:15:29] <timchown> Savola: operators have easier way to secure dhcp server - dns server session, but this makes problem worse because might make one believe somehow more easy to achieve in a trusted manner
[11:15:42] <timchown> a: this is not a general process dns updates method
[11:15:58] <timchown> a: again, policy issue, or use keys, etc
[11:16:20] <dhc> a=mark stapp
[11:16:32] <timchown> dns update mechanisms need to include dhcp servers
[11:17:22] <timchown> client can do update directly if has key, server can do ptr record as it probably has key for that address.
[11:17:35] <timchown> server more static, has policy, won' leave network
[11:17:47] <timchown> a: read v4 equivalent drafts!
[11:18:02] <Barr> duh!
[11:18:37] --- dthaler has left: Replaced by new connection
[11:18:38] --- dthaler has joined
[11:18:42] <timchown> Ralph: package of drafts all holding up on each other
[11:19:03] <timchown> Ralph: includes drafts in other WGs including dnsext
[11:19:12] <timchown> package being obe with ipv6
[11:19:23] <timchown> need to get all docs through various wgs
[11:19:32] <timchown> dhcidrr is dnsext doc
[11:21:00] <timchown> volz possible clashes when same name requested in multihomed scenario
[11:21:09] <timchown> Ralph: is this a wg item?
[11:21:20] <timchown> there are tech issues to finish before we move it out?
[11:21:25] <timchown> is it baked enough now?
[11:21:59] <timchown> margaret: beware it becomes part of the embroiled set of drafts
[11:22:06] <timchown> ralph: any objections?
[11:22:19] <Barr> none
[11:22:20] <timchown> ted: good idea. feel funny about some issues
[11:23:20] --- dhc has left
[11:23:46] <timchown> Now on to dhc-fqdn-option-07
[11:23:49] --- raj has joined
[11:24:05] <Barr> ok
[11:24:06] <timchown> no substantional changes to -06
[11:24:18] <timchown> Ralph: ready for wglc?
[11:24:59] <timchown> Ralph: previous draft will be taken to list for decision on WG adoption
[11:25:39] <timchown> (ie draft-volz-dhc-dhcpv6-fqn-00)
[11:25:51] <timchown> Ralph: so is this doc ready for wglc?
[11:26:01] <timchown> we can mark it now and wait for others to be ready
[11:26:07] <timchown> no objections - so we'll do that
[11:26:20] <timchown> Next is Daniel
[11:26:53] <Barr> tunneling drafts, right?
[11:27:15] <timchown> projector problems :)
[11:27:15] <droms> right. All - here is the updated agenda:
[11:27:31] <droms> DHC WG agenda - IETF 60 0900 Tue 2004-08-03 (tentative) (Last revised 08/03/2004 08:51 AM) ---------------------------------- Administrivia Ralph Droms 10 minutes Agenda bashing, blue sheets, scribe, Jabber scribe Status of IPR claim by Samsung on draft-ietf-dhc-rapid-commit-opt-05.txt Status of IPR claim by PacketFront on draft-ietf-dhc-subscriber-id-06.txt Request for milestones for dhc WG drafts The DHCPv6 Client FQDN Option Bernie Volz 05 minutes <draft-volz-dhc-dhcpv6-fqdn> Accept as dhc WG work item? The DHCP Client FQDN Option Bernie Volz 10 minutes <draft-ietf-dhc-fqdn-option> Technical discussion DHCP Option for Configuring IPv6-over-IPv4 Tunnels S. Daniel Park 05 minutes <draft-daniel-dhc-ipv6in4-opt> Accept as dhc WG work item? Configured Tunnel End-Point Config. using DHCPv4 S. Daniel Park 05 minutes <draft-daniel-dhc-dhcpv4-tep-conf> Accept as dhc WG work item? DHCP Option for Home Agent Discovery in MIPv6 Heejin Jang 05 minutes <draft-jang-dhc-haopt> Accept as dhc WG work item? Vendor-Specific Information Suboption for RAIO Mark Stapp 05 minutes <draft-stapp-dhc-vendor-suboption> Accept as dhc WG work item? Renumbering Requirements for Stateless DHCPv6 Tim Chown 15 minutes <draft-ietf-dhc-stateless-dhcpv6-renumbering> Ready for WG last call? Lifetime Option for DHCPv6 Stig Venaas 15 minutes <draft-ietf-dhc-lifetime> Ready for WG last call (depending on status of 'Renumbering Requirements')? IPv4 and IPv6 Dual-Stack Issues for DHCPv6 Tim Chown 30 minutes <draft-ietf-dhc-dual-stack> Ready for WG last call? Issues in DHCPv6 authentication Jinmei Tatuya 15 minutes <draft-jinmei-dhc-dhcpv6-clarify-auth> Technical discussion IPv6 multicast address assignment with DHCPv6 Jerome Durand 20 minutes <draft-jdurand-assign-addr-ipv6-multicast-dhcpv6> Technical discussion DHCPv4 Opts. for B-cast and M-cast Control Servers Kuntal Chowdhury 05 minutes <draft-chowdhury-dhc-bcmcv4-option> Accept as dhc WG work item? DHCPv6 Opts. for B-cast and M-cast Control Servers Kuntal Chowdhury 05 minutes <draft-chowdhury-dhc-bcmcv6-option> Accept as dhc WG work item? ----------- 150 minutes
[11:27:36] <timchown> dhc-ipv6in4-opt-04
[11:27:38] <Barr> thanks
[11:27:52] <timchown> 1st presented in ietf 59
[11:28:03] <timchown> have requested reviewed by v6ops wg
[11:28:35] <droms> We're now on <draft-daniel-dhc-ipv6in4-opt>
[11:28:38] <timchown> revised based on comments
[11:29:20] <timchown> mechanism allows dhcpv4 servers to provide info about tunnel end points for v6 in v4 within ipv4 networks
[11:29:42] <timchown> claimed useful where isp using tunnels not native (of course)
[11:31:06] <Barr> yes
[11:32:58] <timchown> Ted: i sent comments to list
[11:33:21] <timchown> Ted: client sends option to server, implies server should reply back with option?
[11:33:43] <timchown> Daniel: server can provide this option (?)
[11:34:32] <timchown> Ted: server required to note it must sebd back fqdn option, but client may not request that, i suggest you add wording to say client has to request this option, and server can't send data without option present
[11:34:46] <timchown> let's take to list
[11:34:53] <Barr> I agree with Ted on this
[11:35:10] <timchown> we're behind here today, let's take to list
[11:35:25] <timchown> ted: reason for rfc mandate is to avoid interop problem
[11:35:40] <timchown> ralph: ted, please formulate more clearly
[11:36:26] <timchown> ralph: please capture issue to mail list and we'll resolve
[11:36:50] <timchown> savola: part of more generic problem of discovering tunnel end point, process still underway in v6ops, so premature to lock in this solution now
[11:37:10] <timchown> droms: dhc wg is only part of review process for options like this
[11:37:31] <timchown> droms: v6ops is good place for this
[11:38:08] <timchown> droms: i'm not following tep discovery in v6ops closely
[11:39:07] <timchown> savola: issue ongoing in v6ops, problem if NAT box in middle if doesnt relate dhcp option - i mean if isp provides option and router in middle provides private Ips, then host can't do this?
[11:39:45] <timchown> droms: my linksys box does this - it relays downstream
[11:40:45] <timchown> palet: if you don;t upgrade dhcp boxes, pcs inside nat network won't get this information, so it's good work, BUT requires nat box upgrade in many cases, so it's a possible solution, but may be better, or some combination may be better
[11:41:36] <timchown> scribe: egads we're 25 mins into agenda, and 1hr into meeting
[11:43:15] <timchown> room degenerating.....
[11:43:49] <timchown> droms: question is which wg should this be in? v6ops? dhc?
[11:44:40] <timchown> droms: dont want to waste an option code on something that may not get used
[11:44:57] <timchown> a: not convinced that resource is an issue
[11:45:42] <timchown> ted: are you ready to implement?
[11:45:48] <timchown> anon: yes
[11:46:12] <raj> anon=Mark Stapp
[11:46:21] <timchown> ah, ta :)
[11:47:05] <timchown> savola: don't want client to jhave to implement multiple methods to meet multiple usage scenarios, want to streamline it.
[11:47:16] <timchown> savola: need dhc stamp of approval of course
[11:47:40] <timchown> savola: relaying option is very important - is it possible to achieve?
[11:48:28] <timchown> droms: hat off: less concerned about that detail, not significant problem. other more general solutions - if they exist - and are functionally as good, then lets use those
[11:48:48] <timchown> templin: i had a method like this 2 years ago but got no support
[11:49:09] <timchown> lemon: similar issue with dns discovery, lots of choices!
[11:49:32] --- hkruse has left: Disconnected
[11:49:40] <timchown> lemon: adopt this, get it ready to go, THEN hold until we reelase or get v6ops consensus
[11:49:50] <timchown> lemon: let's not stall now
[11:50:01] <timchown> lemon: no option allocated until it's an RFC
[11:50:48] <timchown> [This is now a very squashed agenda...!]
[11:51:58] <Barr> back to the mailing list
[11:52:06] <timchown> savola: needs to be more work on the proposals, to understand tradeoffs, like whethe relaying will work, could be a factor, so useful to dhc people to specify it so that we can say it will work if we want it
[11:52:16] <timchown> [indeed!]
[11:52:44] <timchown> Stapp: home gateway can't forward option if no option number exists
[11:52:56] <timchown> Savola: gw needs to know option?
[11:53:17] <timchown> Stapp: agent process has to know what data to send to client, must notice it by option number
[11:53:38] <timchown> Savola: will it work through unmodified dhcp implementation?
[11:53:49] <timchown> savola: it is a nice goal
[11:54:01] <timchown> droms: existence proof is there
[11:54:49] --- dfedyk has joined
[11:54:51] <timchown> margaret checking charter
[11:56:35] <timchown> [Discussion of which wg, whether individual or wg item]
[11:57:20] --- dfedyk has left
[11:57:27] <timchown> Wasserman: let's ask v6ops, then make wg item if v6ops likes it
[11:58:06] <timchown> [More discussion of wg eligibility]
[11:58:45] <timchown> Droms: OK, pekka, table it. Next!
[11:59:26] --- dudi has joined
[12:00:41] <droms> Vendor-identifying sub-options; leveraging Littlelfield's vendor-identifying options
[12:00:48] <droms> (Mark Stapp)
[12:01:54] <raj> draft name: draft-stapp-dhc-vendor-suboption-01.txt
[12:02:09] <timchown> now on draft-stapp-dhc-vendor-suboption
[12:02:37] <timchown> droms: is this a wg item? objections?
[12:03:42] <droms> Tim - DHCPv6 renumbering requirements
[12:04:06] <droms> draft-ietf-dhc-stateless-dhcpv6-renumbering
[12:04:59] <droms> Update of draft discussed at Seoul. When a host uses stateless DHCPv6, how does it get updated configuration?
[12:05:18] <droms> For example, how do parameters get updated during renumbeirng?
[12:06:18] <droms> <Tim presents summary of sections 5 and 6>
[12:06:41] --- vm has left: Disconnected
[12:08:55] <droms> Q: How do we pick a preferred solution? (Stig's draft)
[12:09:20] <droms> Q: Should we leave this doc separate or put into final chosen solution?
[12:13:43] <droms> Publish as informational...
[12:13:59] <droms> Stig's draft - <draft-ietf-dhc-lifetime>
[12:14:29] <timchown> ralph - i can scribe again after stig and dual stack if you like?
[12:14:52] <droms> Time - sure ... any contributions to scribing are welcome
[12:15:06] <droms> (oops, that was meant for Tim, not Time)
[12:15:29] <droms> Tells client when is a good time to contact server for new information.
[12:22:43] <timchown> Ralph: is this baked enough to be preferred solution?
[12:22:57] <timchown> no objections
[12:23:30] <timchown> anon: 4 questions need to be resolved, let's do so, then last call?
[12:23:39] <timchown> Ralph: OK, we're picking this one
[12:25:36] <timchown> ok, now on to draft-jang-dhc-haopt
[12:25:49] <timchown> (slight change of order, we missed this one earlier in agenda)
[12:26:27] <timchown> ie http://www.ietf.org/internet-drafts/draft-jang-dhc-haopt-00.txt
[12:26:48] <timchown> new dhcpv6 option with HA discovery option
[12:26:57] <timchown> mobile node identifier sub option
[12:27:04] <timchown> home network information sub-option
[12:29:43] <timchown> q: option 2 is dns encoding, but doesn't specify in detail you dont want to use std dns encoding or not - need to nail it down
[12:30:01] <timchown> Austin: use rfc1035
[12:30:10] <timchown> lemon: also in 3315 based on that
[12:30:27] <timchown> droms: has this been discussed in mip WG?
[12:30:41] <timchown> a: not yet, will be at today's mip6 agenda
[12:30:52] <timchown> droms: mip6 is expert WG for this and consumer
[12:31:34] <timchown> droms: what is information being moved around between the ....
[12:31:42] <timchown> Stapp: this is too much detail, will confuse
[12:31:56] <timchown> a: question is how to get info to dhcpv6 server
[12:32:14] <timchown> droms: ok, so this is tech discussion now, we need mip6 input
[12:32:23] <timchown> need to decide wg, probably mip6?
[12:32:46] <timchown> a: not sure, mip6 can approve, but rfc needs dhc adoption? like mipv4 version?
[12:33:04] <timchown> droms: may not be the process today. semantics expert wg is responsible today, we run parallel wg last call in dhc too
[12:33:21] <timchown> stapp: is that same for rr's?
[12:33:58] --- peterd has left: Disconnected
[12:34:13] <timchown> austin: distinction in dns land is dns gets involved in encoding, semantics must be settled by relevant wg before that encoding happens
[12:37:18] <timchown> [Discussing how DHCP server knows requested MIPv6 info]
[12:37:40] <timchown> thaler: just used while at home
[12:37:54] <timchown> thaler: no discussion of discovering outside home domain
[12:37:58] <timchown> stapp: ok
[12:38:11] <timchown> probably not clear enough in doc
[12:38:17] <timchown> a: outside doc scope
[12:38:28] <timchown> nice to know doc holds together
[12:38:47] <timchown> lemon: adding to much info in draft leads to out of scope comments
[12:39:05] <timchown> only use this when in home network - needs to be very clear in document
[12:39:40] <timchown> droms: will discuss with mip6
[12:40:25] <timchown> skipping dual-stack, leave to end as may be time sink :)
[12:40:46] <droms> Jinmei-san - DHCPv6 authentication.
[12:41:06] <timchown> that's draft-jinmei-dhc-dhcpv6-clarify-auth
[12:41:29] <timchown> comments based on implementation experiences
[12:41:38] <timchown> may require clarifications or changes in base spec
[12:41:43] <timchown> hence this draft
[12:41:51] <timchown> as base of discussion
[12:42:01] <timchown> today concentrate on major issues
[12:42:38] <timchown> 3315 and 3736 contradiction
[12:43:08] <timchown> 3315 has solict/adv exchanges, 3736 stateless subset can use auth within itself
[12:43:38] <timchown> do we allow two choices?
[12:44:50] <timchown> probably need to allow two choices concerning the tradeoff
[12:45:00] <timchown> next issue is possible dos attack
[12:45:25] <timchown> 3315 says client must restart on failure of auth, but attacker can send bogus message to cause validation failure
[12:45:35] <timchown> is concern real? not sure
[12:45:45] <timchown> maybe have a wait period
[12:47:00] <timchown> last major issue is inconsistent bahviour for unauthenticated messages
[12:47:20] <timchown> 3315 section 21.4.2 and 21.4.4.2 differ
[12:47:28] <timchown> requirements contradict here
[12:47:52] <timchown> probably just a wording issue, intent is 21.4.2, so just clarify 21.4.4.2
[12:49:53] <timchown> a few other misc issues
[12:50:14] <timchown> what does server do when client doesn't include auth info?
[12:50:21] <timchown> replay attacks?
[12:50:29] <timchown> Definition of unauthenticated messages?
[12:50:34] <timchown> Key consistency
[12:50:40] <timchown> Proposed next steps:
[12:50:54] <timchown> decide if issues are real - please comment!
[12:51:06] <timchown> if they are, revise draft as wg document
[12:51:25] <timchown> target could be separate bcp or ps rfc, or wait to revise base spec - opinions sought there too
[12:51:43] <timchown> i don't care, just happy if future spec is clear
[12:51:54] <timchown> droms: no tech discussion - take to list
[12:52:09] <timchown> droms: is this a wg document? what to do if we take it on?
[12:52:20] <timchown> droms: suggest we do take it on, and go bcp
[12:52:39] <timchown> lemon: or update to 3315?
[12:53:01] <timchown> wasserman: is it a clarification to ps?
[12:53:07] <timchown> droms: yes
[12:53:29] <timchown> austin: to modify existying std track doc - do it with new std track doc
[12:53:47] <timchown> austin: work on doc, look at what says when wg happy with it, tyhen decide
[12:54:00] <timchown> droms: ok, take as wg document
[12:54:12] <timchown> droms: merge into spec when we go draft std
[12:54:21] <timchown> Next
[12:54:26] <timchown> Jerome Durand
[12:54:39] <timchown> draft-jdurand-assign-addr-ipv6-multicast-dhcpv6
[12:55:17] <timchown> Ipv6 multicast address assignment with DHCPv6
[12:55:59] <timchown> Question is how end users choose an ipv6 multicast address to start a session
[12:56:17] <timchown> should work for all addresses and scopes
[12:57:33] <timchown> existing: madcap (2970), sap (2974), .... none suitable for this
[12:57:51] <timchown> choosing dhcpv6 because we believe will be widely deployed, and it is flexible
[12:58:10] <timchown> allows several addresses to be assigned to a single host
[12:58:43] <timchown> just want 2 new options:
[12:59:01] <timchown> IA_MA option - identity association for multicast addresses
[12:59:15] <timchown> Scope option - allow request within a specific scope
[13:01:51] <timchown> q: doesn't multicast address contain scope information itself?
[13:02:12] <timchown> a: we thought about it but maybe client wants scope option between site and organisation
[13:03:02] <timchown> a: scope option should be sub option in IA_MA not IA_ADDR
[13:03:58] <timchown> Durand: will consider this... we welcome specific suggestions
[13:04:13] <timchown> Durand: also question on address timers
[13:07:39] <timchown> may split to 2 drafts: assignment model in mboned, and options in dhc?
[13:08:52] --- sakai has joined
[13:14:27] <timchown> [Note to self - never volunteer to go last!]
[13:15:56] <Barr> HAHAHA
[13:18:30] <timchown> I thought I might have got at least 5 minutes... and there's two other drafts that had 5 mins allocated
[13:19:09] <timchown> thaler: need to consider dual stack issues of this
[13:19:23] <timchown> thaler: will we only have v6 asm?
[13:19:38] <timchown> thaler: would you just use madcap for v4?
[13:20:13] <timchown> tuy: madcap too complex, hence this method
[13:20:25] <timchown> droms: table and go to mboned
[13:20:35] <timchown> droms: dave, send questions to list
[13:21:28] <timchown> droms: ok, 10 minute extension
[13:22:11] <timchown> first, draft-chowdhury-dhc-bcmcv4-option and v6-option
[13:22:27] <timchown> lemon: lots of information in drafts not helpful
[13:22:42] <timchown> chowdhury: tries to give overvie and high level info
[13:23:14] <timchown> chowhury: needed for 3gpp2, see www.3gpp2.org
[13:23:26] <timchown> allows receipt of contexts for users
[13:23:51] <timchown> trying to discover controller address in wireless network
[13:24:11] <timchown> controller always in local network
[13:24:37] --- yushun has left: Disconnected
[13:26:04] --- tuy has left
[13:27:12] <timchown> droms: any more to this than client pops up and gets address to use?
[13:28:02] <timchown> stapp: why have two options? why is it necessary, or not?
[13:28:22] <timchown> droms: how do we go about this? do we talk to 3gpp2 people?
[13:28:23] --- narten has left
[13:28:49] --- sakai has left
[13:30:30] --- tskj has left
[13:30:44] <droms> Tim - <draft-ietf-dhc-dual-stack>
[13:31:05] <droms> Cutting to the chase...there is a list of 7 issues in the draft.
[13:31:25] <droms> Two solutions: Run separate DHCPv4/DHCPv6 servers ... or... one server that does both?
[13:31:52] <droms> Separate servers - may or may not be on same node; how is consistency maintained
[13:31:59] <droms> client needs some heuristics
[13:33:09] <droms> Need to detail situations in which two servers may be problematic
[13:33:31] <droms> single DHCPv6 server to carry IPv4 information
[13:33:47] <droms> provides transition path to move away from IPv4/DHCPv4/
[13:34:00] <droms> IPv4-only nodes can't get DHCPv4 information
[13:34:33] <droms> Coordination between DHCPv6/4 server and DHCPv4 server for IPv4 address assignment
[13:34:55] <droms> List leaning toward separate servers
[13:35:09] <droms> needs careful look at inconsistency issues
[13:35:34] <droms> issues need to be considered and new rev before WGLC.
[13:37:47] <droms> Anonymous hum for two server solution.
[13:38:08] <Barr> hum
[13:38:16] --- timchown has left
[13:39:35] <droms> For which?
[13:39:35] --- dudi has left
[13:39:42] <Barr> two server solution
[13:45:17] --- touchwood has left
[13:46:59] --- Tina has left
[13:51:34] --- droms has left: Disconnected
[13:52:08] --- Barr has left
[13:57:31] --- dthaler has left: Disconnected
[13:57:38] --- raj has left: Disconnected
[14:21:14] --- dthaler has joined
[14:27:37] --- droms has joined
[14:56:48] --- mike893 has left
[15:12:38] --- droms has left: Replaced by new connection
[15:59:06] --- dthaler has left
[16:10:23] --- mike893 has joined
[16:10:30] --- mike893 has left
[19:08:00] --- toro_toro has joined
[19:08:34] --- toro_toro has left