[08:13:05] --- akostur has joined
[08:36:12] --- jdq has joined
[08:56:25] --- raj has joined
[09:01:49] <akostur> scibe
[09:01:59] <akostur> err.. scribe
[09:02:22] --- Brzozowski has joined
[09:02:27] --- dhankins has joined
[09:02:37] <akostur> Two drafts ready for last call. dhcpv6-agentopt-delegate, dhc.timezone-option
[09:03:43] --- Willi has joined
[09:04:18] <akostur> There will be a revised agentopt-delegate before last call, as well as the timezone option, published after IETF
[09:04:22] --- pluscom has joined
[09:05:22] <akostur> dhankins-pxlinux raised for consideration. No objections. The list will be consulted for consensus.
[09:05:51] <raj> "dhankins-pxelinux-01"
[09:07:37] <akostur> The DHCP Server MIB issue has been raised again, and a proposal by the chair has been raised to forward Cisco's server MIB as an Informational draft.
[09:08:32] <akostur> ISC v3.1.0 is being delayed as the developer has been reassigned to working on a stateful DHCPv6 server.
[09:09:11] <akostur> Moving on to agenda items. Bernie Volz, draft-szeng-dhc-dhcpv6-ero-01
[09:11:36] <akostur> This draft is to provide a way for the relay to request which options it wants to see in the relay-reply. Much like the client's option request option, but for relays.
[09:11:50] <akostur> Do we accept as a WG item?
[09:11:59] <akostur> Opposition?
[09:12:44] <akostur> Next item. L. Morand, draft-ietf-dhc-paa-option-02
[09:15:28] <akostur> Concerns raised about the use of FQDNs in DHCP options. -03 will be published to address this problem.
[09:16:42] <akostur> -03 will drop the FQDN option for DHCPv6, and DHCPv4 becomes a normal list of IPs instead of a sub-optioned option.
[09:17:11] <akostur> Comments? Questions?
[09:17:56] <akostur> Jari Arkko: mentions that PANA WG is simplifying their desgin, and was wondering if that work is obsoleting this work.
[09:19:07] <akostur> JA: suggests we don't advance this without consulting PANA WG
[09:19:28] <akostur> Next Item. B. Joshi, draft-joshi-dhcp-lease-query-ext-00
[09:21:01] <Brzozowski> presentation change
[09:21:09] <Brzozowski> stand by
[09:21:25] --- dudi has joined
[09:21:27] <akostur> There are updated slides... Ralph will publish as soon as possible.
[09:22:36] --- Suzanne has joined
[09:24:13] --- Ralph Droms has joined
[09:24:58] <Ralph Droms> New slides for this presentation are available at: http://www3.ietf.org/proceedings/06jul/slides/dhc-0.pdf
[09:26:07] --- narten has joined
[09:28:02] <akostur> Feedback, discussion?
[09:28:30] <akostur> Ted Lemon: Suggesting support for the Option vs. Sub-option
[09:29:12] <akostur> Mark S.: Is it possible to do both? Option & sub-option?
[09:30:09] <akostur> MS: suggesting support for the Sub-option
[09:30:24] <akostur> TL: One cannot use Option 82 in the LQ
[09:31:26] <akostur> Dave Henkins: Why not use some other managment IP, and allow it to originate its own LQ
[09:31:37] <akostur> MS: The L2 device may not know where its DHCP servers are
[09:32:18] <akostur> To be sent back to the mailing list for more discussion.
[09:32:53] <akostur> Next items: F. Templin, draft-templin-autoconf-dhcp-01, draft-templin-autoconf-netlmm-dhcp-02
[09:40:17] <akostur> Jean-Michel Combes: does it use secure neighbor discovery?
[09:40:41] --- miyahiro@jabber.org has joined
[09:41:09] <akostur> Markus Stenberg: Question about the prefix delegation
[09:41:34] <akostur> MS: Netlmm seems to be moving away from prefix delegation to full /64s (?)
[09:42:06] <akostur> FT: Netlmm seems to have two options. 1) use local router announments, 2) use DHCP
[09:42:51] <akostur> Jari Aarko: Netlmm is still discussing how they are doing things.
[09:43:46] <akostur> Bernie Volz: you are likely using stateless autoconfig, and then have the DHCPv6 client tell the server the chosen address?
[09:44:02] <akostur> TL: Client is to treat the local address as tentative until confirmed by the DHCP server
[09:44:23] <akostur> BV: Then why use stateless... why not just use normal DHCP?
[09:44:40] <akostur> TL: The client may wish to generate its own CGA and notify the server
[09:45:15] <akostur> BV: Finds it odd to mix stateless and stateful, especially within the context of notifying the dhcp server about stateless addresses.
[09:46:09] <akostur> Mark Stafford: Also finds it odd to send the client generated address to the dhcp server
[09:46:46] <akostur> FT: suggests that dhcp has ip options in the solicit/request to support this usage
[09:47:28] <akostur> MS: Thinks that we are trying to fit DHCP onto something where perhaps a separate protocol may be more appropriate
[09:48:54] <akostur> Ralph Droms: Feels that this draft seems to fit between Netlmm & DHC. Perhaps this draft should be dealt with in Netlmm with DHC members contributing.
[09:49:30] <akostur> Rob ?: Wants some way for clients to send addresses to the DHCP server
[09:49:39] <Brzozowski> Rob Austein
[09:49:40] <Brzozowski> ISC
[09:50:12] <akostur> RA: doesn't feel that stateless + stateful is bad
[09:50:55] <akostur> Alex Petrescu: Netlmm has a protocol to talk between various devices, but is missing a trigger for this behaviour
[09:51:07] <akostur> AP: DHCP ma y be used as this trigger.
[09:51:56] <akostur> Moving on to MANET (draft-templlin-autoconnf-dhcp-01)
[09:58:54] <akostur> We may need a new option for DHCPv6 to support the MLA gateway
[09:58:56] <akostur> comments?
[09:59:08] <akostur> This will be discussed over in Autoconf WG
[09:59:33] <akostur> Next item: Marie Normoyle. draft-ietf-dhc-server-override-03
[10:00:20] <akostur> Whup.s. no. Relay Agent flags Suboption
[10:00:26] <akostur> draft-ietf-dhc-relay-agent-flags-00
[10:00:32] <akostur> Right presenter.
[10:01:19] <akostur> Comments?
[10:01:41] <akostur> Stig Venaas: Only has editorial comments...
[10:01:51] <akostur> To go to the list for last call.
[10:03:08] <akostur> Server override & Relay flags to go forward in concert
[10:03:26] <akostur> next Item: Vishnu ram: DHCP Service and Diameter interfaces
[10:07:22] --- evanjc has joined
[10:09:58] <akostur> Questions, comments?
[10:10:34] <akostur> Ralph Droms: IPR question. The notes talk about a patent application. Motorola has make the appropriate IPR disclosure.
[10:11:06] <akostur> Jari Aarko: what is the status of this. AAA WG, elsewhere, or just DHC WG?
[10:11:24] <akostur> VR: also in diameter WG
[10:11:42] <akostur> JA: it this a diam working item?
[10:11:50] <akostur> VR: this is a proposal
[10:12:19] <akostur> RD: is there a threat analysis in the document to show what it is defending against?
[10:12:33] <akostur> VR: mostly reused from 3315
[10:13:26] <akostur> Stig Venaas: not just using auth, but also carrying config from the home server to the client?
[10:14:22] <akostur> VR: If the admin changes in the AAA server, the system could then initiate pushing these changes down to clients
[10:15:19] <akostur> Mark S.: the names of the drafts suggest that this is inteded for the DHC working group. How are key lifetimes going to be managed, and have we considered failover & load-balanced dhcp environments.
[10:15:52] <akostur> VR: The keys are part of 3315.
[10:16:03] <akostur> MS: so there is a pre-shared key between the dhcp client & server?
[10:16:26] <akostur> VR: No.. we transfer the nonce inband and the client derives from this
[10:18:00] <akostur> John S.: Who is the principal for authentication? For DHC, it is the DHCP service authenticating the machine, AAA usually deals with users. This seems to blur who is the client, the machine or user/
[10:18:16] <akostur> VR: This is intended to authenticate the device.
[10:18:37] <akostur> JS: Authenticate who?
[10:18:40] <akostur> VR: The user and the client.
[10:19:32] <akostur> Discussion to be continued on the list before acceptance as a WG item.
[10:19:43] <akostur> Next item. J. Brzozowski, DHCPv6 Leasequery
[10:24:51] <akostur> Questions, comments?
[10:25:20] <akostur> David Henkins: Mentions RemoteID and Device Id, but there are no reference citations
[10:26:14] <akostur> Bernie Volz: Remote ID is currently in the editor queue. Device ID is a work in progress from Ralph Droms, related to DOCSIS 3.0.
[10:26:39] <akostur> Fred Templin: Is this the same as the previous leasequery discussed?
[10:26:49] <akostur> JB: No. The previous was DHCPv4
[10:27:38] <akostur> xx: was unclear that this was an option vs. a new protocol
[10:28:01] <akostur> xx: the server may not know which link the lq came from
[10:28:15] <akostur> xx: you only know the prefix, not the link
[10:28:47] <akostur> BV, JB, RD: The server only cares about prefixes
[10:29:15] <akostur> BV: The relay adds a link IP to relayed messages. The LQ is asking for that link IP.
[10:30:13] <akostur> xx: proposing to take the question offline with BV
[10:30:43] <akostur> RD: Perhaps this is a terminology confusion between LQ and 3315
[10:31:09] <akostur> xx: regarding bulk transport. seems to be "reinventing" tcp
[10:31:39] <akostur> JB: Volume of data can be significant. How to transfer?
[10:31:52] <akostur> xx: Why not use DNS-style fallback to a TCP connection?
[10:32:21] <akostur> Scribe: does anybody know that person's name? I couldn't see his nametag.
[10:33:11] <akostur> David Henkins: also on bulk. this seems to apply to all query types, and may be a problem for implementors.
[10:33:26] <akostur> JB: very few queries will required bulk
[10:33:57] <akostur> DH: Even with 2 or 3, there may be a lot of state required by the server in order to maintain the list between the individual requests from the requestor
[10:34:22] <akostur> JB: We need some mechanism to transfer the bulk data
[10:35:09] <akostur> BV: we're trying to use the same concepts as database access
[10:35:21] <akostur> BV: not claiming an atomic operation
[10:35:38] <akostur> JB: server doesn't have that much state
[10:35:44] <akostur> BV: can be stored in the cookie
[10:35:50] <akostur> JB: how big is that cookie going to get?
[10:36:22] <akostur> Err... those last JBs should be DH
[10:37:58] <akostur> DH: what is mandatory to implement?
[10:38:30] <akostur> Alain Durand: perhaps we should concentrate on framing the data, and make it transport agnostic
[10:38:41] <akostur> Note the previous "xx" is Alain Durand.
[10:40:38] <akostur> xx: The document doesn't impose order, but the querying mechanism appears to enforce some sort of ordering in order to support the querying.
[10:40:50] <akostur> Scribe: I don't know who this xx is...
[10:41:21] <akostur> do we accept as a WG item?
[10:41:31] <akostur> objections?
[10:41:44] <akostur> to confirm on the list.
[10:42:12] <akostur> Next item: Barr Hibbs draft-ietf-dhc-implementation-02
[10:42:23] <akostur> No Bar Hibbs.. presented by Ralph Droms
[10:43:31] --- rjaksa has joined
[10:44:58] <akostur> comments?
[10:45:13] --- joshlitt has joined
[10:45:50] <akostur> To go to mailing list for discussion
[10:46:15] <akostur> Next item. DHCPv4 Threat Analysis
[10:48:00] --- Willi has left
[10:48:20] --- dudi has left
[10:48:39] <akostur> Comments?
[10:48:55] <akostur> Next item. draft-hibbs-dhc-changes-02
[10:50:35] <akostur> comments?
[10:50:55] <akostur> End of agenda
[10:51:09] --- evanjc has left
[10:51:15] <akostur> End of session.
[10:51:47] --- akostur has left
[10:52:00] --- pluscom has left
[10:52:51] --- dhankins has left
[10:55:14] --- Ralph Droms has left: Logged out
[10:56:47] --- joshlitt has left
[10:58:10] --- raj has left
[10:59:42] --- Suzanne has left
[11:00:57] --- narten has left
[11:01:18] --- Brzozowski has left
[11:15:44] --- miyahiro@jabber.org has left: Logged out
[11:18:30] --- rjaksa has left
[11:46:12] --- jdq has left
[12:02:02] --- LOGGING STARTED
[13:02:30] --- dudi has joined
[13:02:42] --- dudi has left
[14:50:41] --- miyahiro has joined
[14:50:53] --- miyahiro has left