[07:39:15] --- scribe has joined
[07:47:16] --- scribe has left
[07:48:45] --- dudi has joined
[07:48:53] --- suz has joined
[07:49:34] --- suz has left
[07:49:38] --- dudi has left
[07:52:13] --- frodek has joined
[07:52:24] --- raj has joined
[07:54:11] --- toro_toro has joined
[07:55:01] --- suz has joined
[07:55:24] --- tskj has joined
[07:59:35] --- dudi has joined
[07:59:47] --- dudi has left
[08:01:10] --- struk has joined
[08:01:11] --- scribe has joined
[08:02:03] <scribe> I'll do some "lazy" scribing then...
[08:02:21] <scribe> Starting with Agenda bashing/summary
[08:02:51] --- dudi has joined
[08:02:56] <struk> DHCP server mib has been reviewed, feedback from IESG, fairly close to being done
[08:03:13] <struk> q: what is the interest level from wg on seeing this come to completion?
[08:03:35] <struk> anon: interesting in seeing "a" server mib, but not necessarily this one
[08:03:52] <raj> anon=ted lemon
[08:03:56] <struk> (thanks :)
[08:04:08] <struk> droms: interested enough to do edit/review
[08:04:18] <struk> lemon: not 'quickly', ~march
[08:05:07] <struk> glen and droms try to finish it up (action droms)
[08:05:23] <scribe> Glen will work with Ralph into getting the MIB work done/reviewed
[08:06:09] <struk> next up: dns zone suffix option (Renxiang Yan)
[08:08:08] <struk> (abort: av problem)
[08:08:21] <struk> next up: reclassifying dhcpv4 options (bernie volz)
[08:08:28] <struk> with the rfc editor
[08:09:54] <struk> procedure to reclassify options 128-223, leave 224-254
[08:10:02] <struk> ... as site-specific
[08:11:36] <struk> call for assistance: what options being used (and who to contact) in "shipping" products
[08:11:41] --- arifumi has joined
[08:14:07] --- Alexis has joined
[08:14:28] <struk> call to go on general ietf working list; volz following up with 'known' vendors; volz also hitting other public lists (suggestion from floor: ISC lists)
[08:15:38] <struk> next up: dns zone suffic option
[08:17:46] <struk> prefix delegation from ISP core/aggregation device to CPE; CPE then issues RAs to terminals in user network
[08:19:32] <struk> three existing methods for dns registrations: manually add DNS RR; RA-based DNS auto-registration, FQDN option by DHCP
[08:21:06] <struk> relative advantages presented (refer to draft/published slides later ;-))
[08:22:52] --- scribe has left
[08:26:50] <struk> new proposal: DNS zone suffix option for DHCPv6; transfer zone suffix from DHCP server to client, where client typically a router used for stateless conf
[08:30:17] <struk> lemon: if you send a dns suffix to a client; that means that the client doesn't know in advance what it's dns suffix is. when it gets the suffix, it has authentication info to update the DNS
[08:30:34] <struk> lemon: the other case is when the dns server is 'open' and no authentication is required
[08:31:04] <struk> lemon: statement made that 'fqdn option not appropriate' but [lemon] opinion is that fqdn is useful
[08:31:47] <struk> yan: understanding from fqdn draft is that its use is in enterprise network, where suffix option is for access network
[08:33:12] <struk> lemon: fqdn option in information request context seems a good solution
[08:33:29] <struk> lemon: from administrator perspective fqdn makes more sense
[08:35:03] --- raj has left: Replaced by new connection
[08:35:20] --- raj has joined
[08:36:03] <struk> lemon: it's really hard to configure every device on the network with authentication information to do their own updates
[08:36:42] <struk> droms: similar issue to RA-based draft
[08:37:23] <struk> obs. droms/lemon need to read RA-based draft as submitted to IPv6 wg and then follow-up on the list with regards authentication for updates, etc.
[08:38:37] <struk> yan: filter DNS registrations from terminals as means to control update rights
[08:39:14] <struk> wasserman: RA-based doc not yet an IPv6 WG item
[08:39:41] <struk> droms: suggest not take this as WG item yet, but to discuss on-list and co-ordinate with ipv6wg
[08:41:24] <struk> next up: vendor-specific information suboption (mark stapp)
[08:42:27] <struk> 0 comments received so far (a sign of success?)
[08:42:42] <struk> suggestion to go to wglc to see if that wakes any dissenters
[08:44:26] <struk> droms: this has been republished as a wg item; question for floor: take this to wglc?
[08:44:29] <struk> consensus: yes
[08:44:47] <struk> droms: follow up on list
[08:44:58] <struk> next up: dhcp authentication using eap (mark stapp)
[08:46:23] <struk> requiring people to send another set of keys around just to do dhcp is a non-starter; dnssec not ready; so why not credentials provisioned already for 802.1x ?
[08:46:48] --- raj has left: Disconnected
[08:46:54] <struk> ("cheap and sleazy" rather than "security panacea")
[08:52:13] <struk> can AAA server be extended to generate a DHCP session key?; only 'things with a brain' (client and AAA) can generate session keys
[08:58:52] <arifumi> [ping]
[08:59:44] <struk> yoshiba: state synchronisation is a problem; strapp: yes, should stay stateless strapp: i can imagine extending the relay agent code to pluck something out of radius-land and drop it into dhcp-land; building a new protocol is a 'big enough cloud' that we won't actually do it next step: 'do some work' and publish draft
[08:59:48] <struk> [jabber drop out!]
[09:00:22] <struk> next up: information refresh time option for dhcpv6 (stig venaas)
[09:00:41] <struk> nota bene: title change
[09:01:03] <struk> lifetime a bad name because timeout doesn't mean invalid
[09:02:52] <struk> on changes, droms: "client must specify the info-request message in option-request option"; what does the MUST mean?
[09:03:12] <struk> venaas: a client implementing this draft must include the option
[09:03:39] <struk> lemon: the point of the MUST is to get people to put it in the option ("be careful what you send and permissive in what you accept")
[09:04:53] --- HannesTschofenig has joined
[09:04:55] <struk> author considers it ready for last call
[09:05:19] <struk> two independent implementation (one client, one server)
[09:05:55] <struk> lemon: draft is great, one debate remaining (during wglc process?): lot like DNS TTL, therefore some of the things in the draft said about times 'probably aren't right'
[09:06:40] <struk> lemon: thresholding times (less than minimum = use minimum; no maximum but there should be - no benefit for long ttls on DHCP INFORM stuff)
[09:07:13] <struk> lemon: 0 ttl (i.e. never cache, always look-up) probably not useful
[09:07:25] <struk> lemon: infinite time v. maximum time
[09:07:51] <struk> droms: key diff between DNS and DHCP ttl: when DHCP expires, client explicitly does something c.f. DNS clients do not
[09:08:04] <struk> droms: wglc?
[09:08:35] <struk> daley: in RA there is explicit 0 (to retract state); is there a way to retract state in this draft?
[09:09:00] <struk> (do we have trust? will it lead to DoS?)
[09:10:01] <struk> wglc to be confirmed on-list
[09:10:51] <struk> next up: multicast reconfiguration protocol for stateless dhcpv6 (daniel park)
[09:12:16] --- raj has joined
[09:14:26] <struk> intention: reconfirgure DHCPv6 domain in conjunction with RA; take account of how M&O flag of RA are used and defined
[09:22:07] <struk> droms: why use the relay-reply message? --> why would we put this into DHCP at all? (particularly where M&O flags are clever ideas)
[09:22:20] <struk> droms: new ICMPv6 option?
[09:22:31] <struk> park: transaction ID used to track transitions
[09:24:29] <struk> lemon: if you're actually renumbering, dhcp client should be going out to get new information
[09:24:33] <struk> schnizlein: how does it know that you've renumbered?
[09:24:47] <struk> lemon: if you've renumbered then you have a different prefix?
[09:24:55] <struk> chown: you might be renumbering a node and not a link?
[09:25:19] <struk> droms: changes in dhcp-supplied addressing might not be reflected in changes in RA-provided addresses
[09:25:36] <struk> lemon: if it's dhcp info that's changing, then makes sense that it's done with dhcp messages
[09:26:30] <struk> volz: venaas handles 'planned' reconfiguration event pretty well (can predict and set lifetimes); it's the unplanned/emergency situation that could make this work useful
[09:26:47] <struk> volz: if we move the lifetime draft forward then 'this' is unclear
[09:27:01] <struk> droms: which "this"? M&O is not dhc wg, it's ipv6 wg
[09:27:39] <struk> droms; we change the m&o flags *to* instigate a reconfiguration of the clients
[09:28:39] <struk> droms: thing that's novel here is the thing that 'toggles' the O flag to instigate info request
[09:29:03] <struk> venaas: there might be some changes that you want to give to stateless clients but the router may not have changed at all, but you want to trigger the router to 'do the toggling'
[09:29:39] --- sra has joined
[09:30:07] <struk> lemon: if no method other than CLI, then that's "broken" (is it our problem?)
[09:30:33] <struk> daley: use snmp
[09:30:37] <struk> *klaxon sounds*
[09:30:58] <struk> daley: mechs out there aren't synchronous; clients fetch at boot-time
[09:31:42] <struk> daley: should be either (broken) router renumbering, or SNMP
[09:32:38] <struk> lemon: SNMP or DHCP decision - would likely make more sense for the former for this kind of thing
[09:32:45] <struk> droms: hum for taking this on as wg item
[09:32:47] <struk> (silence)
[09:32:52] <struk> droms: hum for not
[09:32:53] <struk> (silence)
[09:32:54] --- dudi has left
[09:33:43] <struk> lemon: no hum because no strong argument for doing thing with anything other than SNMP, but don't feel strongly that way
[09:35:07] <struk> daley: dhc 'informational' on issues; back-end probably realisable with current protocols
[09:35:46] <struk> droms: course of action to defer decision as to whether this is a wg item, but open for resubmission later in light of comments
[09:36:12] <struk> next up: anycast addr assignment using dhcpv6 (syam madanapalli)
[09:36:44] --- xiaodong has joined
[09:37:18] <struk> currently no method for assigning service oriented addresses (e.g. anycast addresses, well-known unicast, etc.)
[09:37:24] --- xiaodong has left
[09:37:39] <struk> new name space: Service Type
[09:40:42] <struk> volz: piece missing here? could be relay agents involved - do they need info of anycast addressing? routing infrastructure needs to know that this is an anycast address (to route toward 'closest')
[09:41:06] <struk> madanapalli: this is just assigning the address
[09:41:37] <struk> lemon: slides appear different to draft; 2nd part is starting to look like SLP
[09:41:51] <struk> schnizlein: ... which has already been published
[09:41:55] <struk> droms: there are two parts
[09:42:09] <struk> lemon: ... which should be separated because the 2nd part will have trouble gettign through IESG
[09:42:26] <struk> droms: are the service types to be defined here? IANA? anycast bof?
[09:42:52] <struk> will need to reconsider previous work on service types
[09:43:02] <struk> lemon: suggest text strings; else go through formal process with IANA
[09:43:14] <struk> droms; "site specific services"
[09:43:35] <struk> droms: hums for wg
[09:43:38] <struk> *some*
[09:43:41] <struk> droms; hums against
[09:43:46] <struk> (silence)
[09:43:57] <struk> droms: if split - any objection to publishing either/both?
[09:43:59] <struk> (none)
[09:45:07] <struk> next up: source address selection policy (tomohiro fujisaki)
[09:46:50] <struk> 3484 describes selection mechanism with provision for policy tables; however no protocol to actually distribute the policy
[09:50:00] <struk> current draft: assumes option used with slaac; that lifetime of policy option tied to lifetime of address prefixes
[09:51:12] <struk> related drafts in ipv6 wg and multi6 wg
[09:52:59] --- HannesTschofenig has left
[09:53:23] <struk> schnizlein: why are you advocating use of DHCP (typ. for 'static'-like things) for something that is about routing
[09:54:45] <struk> lemon: reason for dhcp option is that this is envisaged that site is 'stably' multi-homed and policy static ?
[09:54:50] <struk> fujisaki: yes
[09:55:09] <struk> lemon: not for transient changes in routing infrastructure?
[09:55:09] --- arifumi has left: Replaced by new connection
[09:55:37] <struk> (co-author): don't want to use routing protocols because this is a mechanism for distirbuting SAS *policy*, not routing information
[09:58:11] <struk> droms: this is an issue to take to the list, therefore defer decision about wg adoption
[09:59:14] <struk> chown: SAS selection issue: standard agreed way to define policy needed; RA could get bloated (whilst good for other things)
[09:59:37] <struk> daley: this is per-interface, "this is what's available through this interface" - be careful about crossing interfaces
[09:59:53] <struk> lemon: this option is 'big'; consider putting it into IA
[10:01:10] <struk> next up: DHCPv6 Relay Agent Information Option (Wing Cheong Lau)
[10:02:28] --- dudi has joined
[10:06:31] <struk> droms: adopt in wg? (with provision of changes)
[10:06:33] <struk> adopted.
[10:07:42] <struk> next up: clarifications on dhcpv6 authentication (Jinmei Tatuya)
[10:08:23] <struk> list-initiated changes made
[10:09:00] <struk> tradeoff between securing multiple exchanges and keeping the server 'stateless'
[10:10:04] <struk> draft recommends treating multiple exhcanges as a single 'session' (server keeping perclient status with replay protection); but permits separation of each exchange with regards authentication
[10:12:07] <struk> awaiting feedback from wg regarding proposed changes from previous draft
[10:12:19] <struk> if resolutions are deemed okay, then author considers ready for wglc
[10:13:48] <struk> lemon: clear set of changes here that could be applied to 3315
[10:13:52] <struk> droms: rat hole alert
[10:15:00] <struk> droms: have the proposals been published as an I-D?
[10:15:06] <struk> jinmei: yes
[10:15:07] --- dudi has left
[10:15:08] <struk> droms: then it's ready for wglc
[10:15:14] --- arifumi has joined
[10:17:39] --- arifumi has left: Replaced by new connection
[10:18:13] <struk> next up: dhcp relay agent option to support mobile ipv6 boostrapping (J. Bharatia)
[10:18:35] <struk> netops are getting ready to deploy mobile ipv6
[10:23:43] <struk> new option proposed for MIPv6 boostrapping (pending number from IANA), an envelope for suboptions
[10:25:02] --- arifumi has joined
[10:25:09] --- toro_toro has left: Disconnected
[10:26:31] --- tskj has left
[10:26:49] <struk> stapp: objection to relay agent injecting into DHCP messages
[10:28:46] --- dudi has joined
[10:29:18] --- arifumi has left: Logged out
[10:29:18] <struk> (confusion over role of relay agent inserting into message)
[10:29:24] --- frodek has left
[10:33:03] <struk> anon: there's a draft in mobilev6 that does this without dhcpv6
[10:33:54] --- dudi has left
[10:34:58] <struk> 'state' in DHCR is cached from AAA, not replicated
[10:36:38] <struk> resolution: revise the draft to avoid the DHCR injection issue and then go round the loop again
[10:36:45] <struk> next up: volz summary
[10:37:23] <struk> fqdn-option, ddns-resolution and dhcpv6-fqdn 'been around a while'
[10:38:23] <struk> fqdn-option-07 ready for wglc
[10:38:34] --- toro_toro has joined
[10:38:42] <struk> ddns-resolution-08 has revisions, particular in s6.3
[10:39:11] <struk> comments on language improvements solicited
[10:39:37] <struk> dnsext's-dhcid-rr-08 desired to keep alive but needs conflict resolution draft to complete
[10:39:47] <struk> droms: these are going to iesg as a package
[10:40:00] <struk> droms: dhcid-rr in a 'holding pattern' waiting for the rest to catch up
[10:41:12] <struk> droms: wglc on v4 fqdn and have it in the same state as dhcid-rr
[10:42:07] --- toro_toro has left
[10:42:10] <struk> v4 fqdn option: hums for wglc: passed
[10:43:38] <struk> ddns-resolution-08: hum for wglc: one hum, therefore hold for more to have read
[10:43:40] <struk> *close*
[10:43:43] --- suz has left: Disconnected
[10:43:46] <struk> chown: dhc-dual-stack?
[10:43:55] <struk> droms: status?
[10:44:18] <struk> chown: reasonably good state; had consensus with approach at last meeting; comments addressed; author feels near last-call
[10:44:31] <struk> droms: .. will follow up, thank you
[10:44:33] <struk> *close close* :-)
[10:44:36] <struk> [apologies for the drop-outs, darn beta jabber client(!); apologies too for any misrepresentation - last minute scribe new to the field]
[10:44:43] --- struk has left
[10:45:26] --- Alexis has left
[10:46:05] --- sra has left
[11:08:25] --- raj has left: Disconnected
[12:03:15] --- HannesTschofenig has joined
[12:44:09] --- HannesTschofenig has left
[13:15:37] --- HannesTschofenig has joined
[16:42:46] --- HannesTschofenig has left