[03:06:07] --- jlcjohn has joined
[03:26:22] --- arifumi@jabber.org has joined
[03:26:50] --- raj has joined
[03:29:01] --- Struk has joined
[03:31:38] --- suz has joined
[03:32:01] <Struk> droms: one or two additions to agenda: status announcements and a request
[03:32:10] --- mo7sen has joined
[03:32:49] --- Xag has joined
[03:32:50] <Struk> http://www1.tools.ietf.org/agenda/63/dhc.html
[03:34:02] --- aibo7 has joined
[03:34:07] <Struk> ... and T. Lemon "DHCPv6 client" 02 minutes after TAHI
[03:34:49] --- tskj has joined
[03:35:51] <Struk> headsup: draft-ietf-geopriv-dhcp-civil-07.txt - option for passing location information by DHCPv6
[03:36:05] --- iljitsch has joined
[03:36:35] <Struk> new revision coming "very soon". droms to post notice to dhc wg. wg to confirm that IESG-invoked changes are still acceptable to dhc wg
[03:37:25] <Struk> milestones: (refer http://www1.tools.ietf.org/wg/dhc/)
[03:38:53] --- aibo7 has left: Replaced by new connection
[03:39:05] <Struk> -threat-analysis started to analyse RFC3118 - has gone quiescent. desire to get it started up again. droms stepping away, wants someone to pick it up and drive it
[03:39:06] --- aibo7 has joined
[03:39:39] <Struk> dhcpv4 specification review report completed. effort has "run out of steam", droms looking for someone to drive
[03:40:16] <Struk> failover protocol, droms "mea culpa" - chairs doing final review to complete cover sheet to go with protocol review to the IESG
[03:40:49] <Struk> droms posted comments about sec9 to dhc wg list, but doc may not have been revised since comments
[03:40:55] <Struk> BUT chair comments may instigate further changes
[03:41:12] <Struk> milestones required for:
[03:41:52] <Struk> -dhcpv6-fqdn-02; -dhcpv6-remoteid-00, -dhcpv6-subid-00, -agent-vpn-id, -dual-stack-02, -proxyserver-opt-02, -server-override-01, -soa-optionk, -subnet-alloc, and one other...
[03:42:24] <Struk> lemon: (unheard - mic!)
[03:43:00] <Struk> droms/venaas: no knowledge of any revisions
[03:43:10] <Struk> lemon: do a quick last call, in light of statements about applicability
[03:43:17] <Struk> (anyone else local: was this about a review of 3315?)
[03:45:08] <Struk> mahendran: bcmc status, particularly a 3gpp2 waiting on it;; venaas: comments with the IESG, draft updated a few days ago to cater for disucssions;; droms: ask wasserman as to status
[03:45:40] <Struk> lemon: made a comment on last rev. concern was inclusion of fqdn options
[03:46:05] <Struk> lemon: prefer just IP address
[03:46:26] <raj> draft-ietf-dhc-bcmc-options-03.txt
[03:46:27] <Struk> droms: folks designing may have preference, author should comment
[03:46:52] <Struk> davies: reviewed draft for gen area team. revision -03 does not address comments made
[03:47:09] <Struk> davies: why multiple domains needed? not explained on mailing list or in draft
[03:48:17] <Struk> davies: issues with both v4 and v6 inclusion. changes between revisions of drafts lacks consistency as regards v6 and v4. not clear that you'll get two DHCPv4 codepoints
[03:49:39] <Struk> mahendran: one DHCPv4 cp requested; multiple domain qn should have been answered in an email; multiple domains presented because intent is for user to decide from list of candidates
[03:50:22] <Struk> lemon and davies: current rev asks for two codepoints
[03:51:02] <Struk> (co-author): is there a list of issues that we can address?
[03:51:09] <Struk> lemon: answer the questions made on the list
[03:51:56] <Struk> (co-author): can we have a list of actions
[03:52:15] <Struk> venaas: suggest you start a thread on the ml on issues from IESG, from wg, etc.
[03:52:31] <Struk> droms: chairs will look into making issue tracker available, with this doc as first-up
[03:53:11] <Struk> austein: multiple domain name thing "odd" - SRV used to get priority rankings etc., but the draft pushes back to user. "odd"
[03:53:25] <Struk> austein: volunteers himself to set up an issue tracker
[03:53:31] <Struk> (chairs): accept
[03:53:42] <Struk> (chairs): "thanks"
[03:54:22] <Struk> narten: multi-dns names for SRV is a "funny thing". doc says "use the first one, and then iff that fails, use the next one"
[03:54:39] <Struk> mahendran: the operator may choose to use differently
[03:55:06] <Struk> (co-chair looks itchy to say something, along the lines of "take it offline")
[03:55:12] <Struk> (narten spots this and stops ;-))
[03:55:30] --- suz has left
[03:55:37] <Struk> * Alexander on proxy failover
[03:56:02] <Struk> - use case on various client parameters, e.g. http, ftp, smtp, ... proxies
[03:56:19] <Struk> - requirements: simple, flexible, with rulesets, covering range of proxy types
[03:56:49] <Struk> - curr. at rev-04, had input, including requests for javascript push, etc.
[03:57:04] --- dudi has joined
[03:57:07] <Struk> - issues: encoding RDF v. XML (has been _many_ comments)
[03:59:07] <Struk> - major issue: JS, code vs data. option 1, c.f. netscape proxyautoconf file as rdf/xm,l elements with similar syntax and same semantics; option 2, rdf/xml framing of javascript; option 3, send URI where either JS, RDF/XML, or framed JS is located (PAC file format)
[04:00:03] <Struk> venaas: use of xml or rdf: is there any more appropriate place for deciding whether to use XML or RDF or whatever
[04:00:47] <Struk> venaas: if not discussed elsewhere, this sounds like its something outside of dhc
[04:00:57] <Struk> .. to consider opinion on
[04:01:06] <Struk> lemon: stuffing the data into a DHCP packet. it seems big
[04:01:15] <Struk> alexander: it's an issue
[04:01:28] <Struk> lemon: consideration of sending URI rather than data already made, sounds good to me
[04:02:41] <Struk> thompson: sending uri makes changing implementation easier later
[04:02:44] <Struk> venaas: concur
[04:03:24] <Struk> hankins: replacing javascript with xml is a good thing; having something that's just a translational layer isn't so great
[04:03:42] <Struk> alexander: that's an intension as well
[04:04:45] <Struk> (didn't catch name or question)
[04:05:17] <Struk> hankin: redhat project called "network manager" uses 'dbus' to allow dhc svr, client and applications to use a mac-style drop-down box, e.g. for SSID selection
[04:05:43] <Struk> .. delivery of options to applications becoming available, yes
[04:06:42] <Struk> venaas: web proxies had a way (wpad). general use for any client to use URIs or URLs to obtain proxy config; would be more comfortable with some other group looking at how best to convey proxy config
[04:07:22] <Struk> wasserman: not sure if i'm agreeing or expanding. not entirely sure why specific configuration mechanism for these proxies rather than some more generic configuration mechanism for the box
[04:07:54] <Struk> alexander: this is very lightweight, all the other ways (e.g. snmp) are "way-heavier"
[04:08:50] <Struk> wasserman: ... but if those machines have one of those "heavyweight" ones anyway for other reasons, then why does it matter that this is lightweight?
[04:09:31] <Struk> droms cuts the mic
[04:09:56] <Struk> droms: meta-question here: where else to have the conversation for where the appropraite place to discuss how applications configure proxies
[04:10:01] <Struk> droms: ... to the list
[04:10:10] <Struk> * Venaas dual-stack-merge-00
[04:10:28] <Struk> - looking for solns to -dual-stack-03
[04:11:01] <Struk> - main issue: v4-only and v6-only easy, dual-stack clients less so
[04:11:40] <Struk> - draft lists some possible tools. e.g. preference for v6 over v4 options; use fqdns as options and rely on 3484 implementations
[04:11:50] --- iljitsch has left
[04:12:19] <Struk> - if server knows client is dualstack, could pre-empt and give different answers (e.g. omit ipv4 info in DHCPv4 path knowing/guessing that DHCPv6 request coming)
[04:12:38] <Struk> - DUID might be of help in integrated server
[04:13:20] <Struk> - possibly useful to use DHCP INFORM with with v6 to tell client to get v4 info
[04:13:40] <Struk> - use IPv4-mapped addresses in address lists in DHCPv6
[04:13:59] <Struk> - draft not trying to solve the problem right now, but sketch out possible partial solutions
[04:14:20] <Struk> - need more experience to understand which issues important
[04:14:36] <Struk> - draft evolve over time with new tools, new issues, new priorities
[04:14:42] <Struk> - need to decide which issues are worth solving
[04:15:51] <Struk> Durand: 1/ should try to solve this now - deployment will have DHCPv4 and v6 for addresses and parameters therefore wg encouraged to solve; 2/ agree with DUID giving hints to the servers about the client - but also push some intelligence to clients so that they know which server sources may or may not be merged
[04:16:11] <Struk> venaas: ref. 1/ agree that it will be a problem really soon now. dhcpv6 implementations coming, so, yes
[04:17:17] <Struk> chown: as co-author, yes we do need to work on it now. the draft is early to instigate discussion. DHCPv6 implementations we've seen are DHCPv6-only;
[04:17:34] <Struk> chown: management presentation to know where info coming from
[04:17:58] <Struk> lemon: draft doesn't actually say what's going on before talking about how to solve the problem. domain-specific configuration information being treated as domain independent
[04:18:20] <Struk> e.g. "I intend to send a DNS request out of this interface using IPv4, so what IP address should I send that to?"
[04:19:05] <Struk> droms: need to get that description in the draft, therefore authors encouraged to work with lemon et al
[04:19:14] <Struk> lemon: we don't want a different API
[04:19:30] <Struk> venaas: not sure i understand your issue
[04:19:42] <Struk> lemon: there could be three different servers that have no common administrative control
[04:20:40] <Struk> Van Beijnum: if no ipv6 address info needed, then getting "other" config from DHCPv4 is probably enough. but doing stateful stuff is dangerous, e.g. if IPv4 issues arise then IPv6 service suffers
[04:21:08] <Struk> droms cuts the mic
[04:21:12] <Struk> ... but not before
[04:21:19] <Struk> durand: is this now a wg item?
[04:21:24] <Struk> droms: adopt?
[04:22:01] <Struk> chown: problem trying to solve should be reasonably captured in the -dual-stack-03, which has gone through last call
[04:22:34] <Struk> venaas: i'm not in a rush to get it adopted
[04:22:44] <Struk> durand: ... but i'm in a rush to get the solutions
[04:22:48] <Struk> *hums*
[04:23:15] <Struk> draft adopted
[04:23:27] --- aibo7 has left: Replaced by new connection
[04:23:35] --- aibo7 has joined
[04:23:52] <Struk> * Fujisaki on -addr-select-opt-00.txt
[04:24:36] <Struk> - 3484 useful
[04:25:21] <Struk> - proposal started in Washington61 based just on source addr sel; Minneapolis62 moved to full policy distribution, but soliciting support of ipv6 wg
[04:26:11] <Struk> - map policy table elements to 8-bit fields, prefix encoding method is same as default router selection draft
[04:26:37] <Struk> (use cases presented as per http://www.nttv6.net/dass)
[04:29:22] <Struk> - at ipv6 wg at Paris63: "policy table is host specific and not link specific, so multiple IF host may have broken policy table"
[04:29:47] <Struk> response "multiple interface environment is not our concern"
[04:29:56] <Struk> - "APP(socket) specific policy is useful"
[04:30:15] <Struk> response "3484 doesn't support app-specific policy; nordmark proposes APIs for that"
[04:30:22] <Struk> - "Privacy Address on/off control is desirable"
[04:30:35] <Struk> response "it's possible to do that at policy table, but not beautiful"
[04:31:53] <Struk> - next steps: insufficient discussion, no consensus to move forward; continue to discuss on ipv6 ml
[04:32:20] <Struk> chown: thinks the work is important. 3484 talks about methods for policy to be configurable, this provides a means to configure it
[04:32:38] <Struk> chown: how do you configure use or non-use of privacy address, could someone clarify on list how to do this?
[04:33:07] <Struk> venaas: personally, ipv6 wg should try to understand whether this is useful or not. our job is to go there and argue for it
[04:33:47] <Struk> venaas: qn for ipv6 wg: do we need a way to configure policy in a distributed way? if so, dhc is likely a good candidate :)
[04:34:32] <Struk> droms: has spoken with ipv6 wg chairs sincs ipv6 wg. seems that they have similar questions to us, particularly ref 3484 being the most appropriate way of doing address policy
[04:34:35] <Struk> ^selection
[04:35:50] <Struk> lemon: disagree with that approach. fundamentally this is expressing a way of specifying something that is already an rfc, so why are we stalling?
[04:35:54] <Struk> volz: concur
[04:36:57] <Struk> durand: what exactly do we want to achieve? if enterprise deploying address selection, then what are the requirements? won't they want app-specific policy, ...?
[04:37:28] <Struk> Van Beijnum: concern that this mechanism may lead to so many policy expressions such that it won't fit in a dhcpv6 option any more
[04:37:51] <Struk> wasserman: tech issues aside: we're not trying to make a dhcp option to configure everything in the world. there has to be a need, a reason
[04:38:41] <Struk> e.g. if 3gpp said we needed it, or operators in v6ops saying that they needed it, etc., then great. but we don't have that
[04:39:29] <Struk> chown: 3484 will have to be updated before v6 wg closes, e.g. due to site-locals, cornercase defaults that are possibly less relevant or prohibitive to current deployments
[04:40:42] <Struk> daley: following wasserman: essentially dhc is a host-config mechanism wg. there are alternative mechanisms available, e.g. ipv6 router discovery
[04:41:45] <Struk> venaas: it's not per host, it's likely per (network)
[04:42:34] <Struk> van beijnum: i'm here, i think shim6 people may well want this or something very much like this. not sure whether dhcpv6 is the right mechanism
[04:43:01] <Struk> droms: if shim6 may be interested, we should contact them
[04:43:46] <Struk> durand: this sounds like a solution needing a problem
[04:44:57] <raj> draft-yan-dhc-dhcpv6-opt-dnszone-02.txt
[04:44:59] <Struk> * -dhcpv6-opt-dnszone-02
[04:45:32] <Struk> - in v6 access network, may have multi-level dhc deployment, e.g. terminal - CPE/CPE - aggregation device
[04:46:27] <Struk> - option will be placed in the options field IA-PD
[04:46:32] <raj> actually, it's draft-yan-dhc-dhcpv6-opt-dnszone-03.txt
[04:46:57] <Struk> - updates since -02, both stateless and stateful DHPCv6; different suffix to different CPE according to admin policy
[04:47:00] <Struk> (good catch!/
[04:47:08] --- dudi has left: Replaced by new connection
[04:47:09] --- dudi has joined
[04:47:09] --- dudi has left
[04:47:39] <Struk> lemon: draft may have more general uses than perhaps your original intent
[04:48:07] <Struk> suggestion is to take out all language about how you intend to use the option and put in language that defines what the option should look like (therefore not restricting it's use)
[04:48:30] <Struk> venaas: concur. e.g. would it be useful for just a single host? could you use fqdn to get just the suffix?
[04:49:40] <Struk> (didn't catch question)
[04:50:03] <Struk> venaas: several cases where dns search paths would be different, but domain suffix common
[04:50:08] <Struk> droms: accept as wg?
[04:50:10] <Struk> *hums*
[04:50:16] <Struk> adopted
[04:51:27] <Struk> * Dawkins on behalf of Jun on -dhc-clf-nass-option-00.txt
[04:51:38] <Struk> - TISPAN NGN func. arch. uses DHCP to configure TE
[04:51:45] <Struk> - need DHCP option to carry network access id
[04:52:26] <Struk> - (draft has pictures of encoding)
[04:52:39] <Struk> - NASS format has cut-n-paste typos, will be corrected
[04:52:48] <Struk> - qn: what else are we overlooking?
[04:52:55] <Struk> - qn: what work still needs to be done?
[04:53:04] <Struk> no ipv6 encoding needed right now
[04:53:38] <Struk> venaas: fuzzy why you need to identify network and how it should be identified. are there other cases outside this area where you need to tell the client about the network its connected to?
[04:53:57] <Struk> dawkins: author coming explicitly from tispan background
[04:54:03] <Struk> lemon: what is a tispan ngn?
[04:54:33] <Struk> droms: overlooking a terminology section
[04:54:50] <Struk> hankins: growing angst over growing number of different encodings for options
[04:55:14] <Struk> dawkins: two different options or one option with different encodings?
[04:55:33] <Struk> hankins: that's the qn. but should we have a document that specifies a document with various encodings in to become standard across dhc
[04:55:43] <Struk> droms: (paraphrase) wanna write it?
[04:56:05] <Struk> dawkins: .. had assumed that multiple options wouldn't be good
[04:56:24] <Struk> lemon: use sub-option field?
[04:56:33] <Struk> droms/hankin/dawkins: concur
[04:57:29] <Struk> hankins: in authors best interest to make encodings as easy as possible for implementers. (those drafts that look like they require the most work to implement go straight to the bottom of the list)
[04:57:29] --- aibo7 has left: Disconnected
[04:57:59] <Struk> dawkins: we expect that ipv4 address lit. encoding is the only one to get used
[04:58:10] <Struk> lemon: if that's the only place you're expecting to use, then why not just run with it
[04:58:21] <Struk> dawkins: i'm not tispan, but there are other places
[04:58:28] <Struk> lemon: ... sub-option
[04:59:43] <Struk> droms: accept as wg item?
[04:59:52] <Struk> *hums*
[05:00:14] <Struk> not enough consensus to take it today, will take another look after the revisions
[05:00:31] <Struk> wasserman: relatively small no of people have read it, so encourage for next rev
[05:01:42] <Struk> (change of agenda due to beamer issues)
[05:02:17] <Struk> * Nobumichi-san, TAHI test tool
[05:03:21] <Struk> - www.tahi.org has test suites for ipv6, freely available
[05:03:45] <Struk> - DHCPv6 test tool now on their agenda; testing server, agent and client
[05:04:04] <Struk> - covering 3315, 3633, 3646, 3736
[05:04:32] <Struk> - oct 05 window for beta version of test. 6th ETSI plugtest in association with 7th TAHI test event
[05:04:39] <Struk> - apr 06 will show version 1
[05:04:53] <Struk> www.etsi.org/plugtests/IPv6.htm
[05:05:37] <Struk> - current test specs are on www.tahi.org/dhcpv6/
[05:05:37] <Struk> - tool will appear at same url
[05:05:42] <Struk> - mailinglist on dhcptest@tahi.org
[05:05:43] --- Xag has left: Lost connection
[05:05:57] <Struk> *round of applause* for TAHI biting the bullet
[05:06:19] <Struk> * Lemon's client
[05:06:48] <Struk> - hacking on ISC dhcpv4 client to turn it into a dhcpv6 client
[05:06:53] <Struk> - "pretty much done", but a few more problems to complete and then more to find
[05:07:07] <Struk> - unlikely to be foldbackable into dhcpv4 code
[05:07:09] <Struk> hankins: send text!
[05:07:12] <Struk> - dbus is the intended hook
[05:07:39] <Struk> - contact Ted if you want to get involved
[05:07:46] <Struk> * Volz on 3942 update
[05:08:21] <Struk> - reclassifying vendor-specific options
[05:08:47] <Struk> - plenty of clashes, e.g. option 128, ..., 150, ...
[05:09:04] <Struk> - 18 options tentatively assigned (10 option numbers with multiple reported uses, i.e. conflicts)
[05:09:20] <Struk> - 78 options unassigned due to no reports on usage
[05:09:35] <Struk> - some options that surfing and googling show as in use, but not reported
[05:10:42] <Struk> - 3942 procedures: IANA would put 128-223 in an unassignable cat. for the first 6mo., vendors would have 6mo to report usage and then we would have a way for moving them away from those options
[05:10:48] <Struk> (considering shipped code)
[05:11:40] <Struk> - next step for users of options to write drafts detailing their use, informational or standards-track. dhc wg should accept as work items when requested, but review most likely limited to whether usage is clearly documented (given that they're already deployed)
[05:12:10] <Struk> - I-Ds for options with conflicts should be documented with existing usage and existing option number and then ask IANA for new assigned option number for use in future
[05:12:48] <Struk> * Kumar on suraj-dhcpv4-paa-option-00
[05:13:25] <Struk> - new option request. PANA is run between PANA client and PANA authentication agent (PaC and PAA) in order to perform authentication and authorization for serivce access
[05:13:39] <Struk> - existing: manual config, multicast based; proposed: dhcp-based discovery
[05:14:03] <Struk> - new DHCPv4 option for PaC to discover PAA, carries IPv4 list or doman name symbol list
[05:14:26] <Struk> - using an "encoding" field to distinguish between literals and symbols
[05:14:52] <Struk> - consideration given for nature of response based on having both literals and symbols available
[05:15:20] <Struk> - pana wg has seen the draft presented and there is general agreement from them that this is something to go forward
[05:15:47] <Struk> staap: we just had a conversation about preferring embedded sub-options over an encoding byte in cases where one option code desired to carry different types of data
[05:16:19] <Struk> s/staap/stapp/ (apologies)
[05:17:01] <Struk> stapp: server shouldn't need to have special code to treat just one option, so consider this request
[05:17:21] <Struk> lemon: i'd like to see you take out domain names if possible. really prefer just literals
[05:17:40] <Struk> venaas: discuss adoption here, and what encodings may or may not use later
[05:17:54] <Struk> daley: we can do this without DNS because we can't get to DNS if not authenticated
[05:17:58] <Struk> droms: accept?
[05:18:00] <Struk> *hums*
[05:18:00] <Struk> adopted
[05:18:52] <Struk> (flammable substance alert: RA M/O bits coming...)
[05:19:04] <Struk> * Park on M&O Flags of IPv6 RA
[05:20:58] <Struk> - three requirements: 1: ok, 2: exploring dhcpv6 extension (3315/3716) is this 3315-bis; 3: not suitable
[05:21:59] <Struk> (for the log, the mail discussion archive is 'around'; http://www1.ietf.org/mail-archive/web/dhcwg/current/msg05255.html)
[05:22:15] <Struk> venaas: is it apporpraite to give the same message to all clients on the link as to whether use dhc or not
[05:22:37] <Struk> droms: multiple CPEs on the same link in docsis3.0 may require different behaviours
[05:22:40] <Struk> ... a real use
[05:22:55] <Struk> stapp: what's being advertised is that a service is available, not that it's mandatory
[05:23:57] <Struk> droms: important to ensure that this is an enhacement to existing service (i.e. not disrupting)
[05:24:53] <Struk> * Pentland on DCHP-DNA interaction
[05:25:05] <Struk> - dna wg has id'd an issue with 3315 and dna
[05:25:51] <Struk> - two proposals under consideration. landmarks: prefix in RS, routers say "yes" or "no"; linkid: routers mark numerically lowest prefix as the "link identifier". both have procedures to cope with prefix changes, etc.
[05:26:04] <Struk> - dnav6 eliminates the need for confirm/reply exchange
[05:26:17] <Struk> -- dnav6 returns "same link": no dhcpv6 message exchange
[05:26:45] <Struk> -- dnav6 returned "different link": client goes immediately to solicit/adv/request/reply
[05:26:55] <Struk> - next step: discussion on dhc/dna wg lists
[05:27:09] <Struk> there's definite interaction, discussion as to how to go about it
[05:27:39] <Struk> daley: don't mind if most of discussion on dhc and if you like cc dna
[05:27:43] <Struk> (as cochair of dna wg)
[05:27:45] <Struk> * Droms on injection of routing information of dhcp pd
[05:28:05] <Struk> - headsup regarding discussion on injection of routing info
[05:28:40] <Struk> - PD (3633) from Delegating Router to Requesting Router, for use in RR's downstream
[05:28:51] <Struk> - 3633 requires DR and RR on same link (no relays)
[05:29:01] <Struk> - PD users have expressed interest in centralised PD service
[05:29:07] <Struk> - IA_PD option carries PD info
[05:29:28] <Struk> - IA_PD option can be carried in DHCP msg fwd by agents
[05:29:42] <Struk> - routing info about PD prefixes needs to be injected into routing infrastructure
[05:29:47] <Struk> -- DR can do injection when on same link as RR
[05:29:59] <Struk> -- how does route injection happen with relay agents if 3633 restriction relaxed?
[05:30:35] <Struk> (pretty picture not asciiable from here ;-))
[05:30:57] <Struk> - possibly include relay agent options to signal relays
[05:31:20] <Struk> option 1/ RR participates in routing protocol and does own route injection.
[05:32:03] <Struk> option 2/ element with relay injects route (explicit DHCP relay agent mesage; dhcp snooping, out-of-band update from dhcp server, static provisioning in network element with relay agent)
[05:33:16] <Struk> - RR pariticipating in routing protocol requires RR to be "trusted'
[05:33:29] <Struk> -- id of RR, contents of routing update from RR, RR has authoirty to make update
[05:33:46] <Struk> -- easiest if RR is in same administrative domain, e.g. use a regular routing protocol; harder if the RR is a CPE
[05:34:47] <Struk> - Relay agent option use: server can explicitly inform network element with relay agent about prefix delegation; snooping may also work, but state update in case of agent failiure needed
[05:35:14] <Struk> - requires "pdquery" to restore state in router
[05:35:27] <Struk> we will have a draft soon to discuss - this is mostly a heads-up
[05:35:58] <Struk> Jinmei-san: similar to signalling requiremetns for configuring the M&O bits in RA
[05:36:46] <Struk> lemon: when doing PD, how does device getting delegation know that it's got it across power cycles?
[05:37:07] <Struk> droms: it doesn't have to have persistent state. when it comes back up it' a bit like DHCPv4 in that when it comes back up it asks for it again
[05:38:19] <Struk> unknown: if relay still acting as DR then snooping for free?
[05:38:27] <Struk> (i think is a paraphrase)
[05:39:29] <Struk> volz: (to jinmei-san) there are a lot of other things we could configure here, but let's restrict to routing problem here
[05:39:50] <Struk> jinmei-san: just pointing out similarities
[05:40:09] <Struk> lemon: why isn't RR doing route injection anyway? it's trusted to route packets to clients but not...?
[05:40:26] <Struk> unknown: clients can trust RR, but nobody else should
[05:40:33] <Struk> unknown: RR could just inject a /8 and smile
[05:41:47] <Struk> droms: in v4 case where RR is a NAT, the relay only accepts packet from the one global address it allocates and throws the rest away. in our case, the DR/Relay needs to be able to trust the RR
[05:41:58] <Struk> chairs thank attendees
[05:42:01] <Struk> scribe runs for beer
[05:42:03] --- Struk has left
[05:42:18] --- raj has left: Disconnected
[05:47:22] --- arifumi@jabber.org has left: Logged out
[05:51:35] --- tskj has left: Disconnected
[05:54:21] --- mo7sen has left: Disconnected
[06:16:55] --- jlcjohn has left
[07:45:18] --- brabson has joined
[07:49:22] --- brabson has left