Ted Lemon: 3 drafts published and two in IETF -Failover requirements in IESG awaiting update from John -failover requirements still being pushed by authors -failover design adopted by wg and -00 published. -secure-dhcpv6 - Ted would like more review and belief is it is important item. -addr-registration - awaiting updates from Suresh -client-id time for new wglc -dhcpv4-over-ipv6 - would like feedback on list to move forward -solmaxrt - john will talk to brian to see what position to take going forward Shen - draft on prefix assignment - slides need to be uploaded, Ted will handle Draft: Options for ANQP Servers -Tao Sun Presenting -no questions -John - is this work premature? Work needed in WiFi Alliance needed first? Kobel(sp?) - Nokia - access points have to talk to backend server - currently proprietary so this would help open that interface. access point to the ANQP server. Program just started in WiFi Alliance and in the process of being implemented. Needed to open a currently proprietary interface. DHCPv4 Options for Port-Set Assignments -Peng presenting -Q1:Multiple options or One options with multiple sub-options? -Q2: IPv4 address in original message vs port-set option Mic: Francis - Q: explain why in the documents on how you can have fragments and a list of protocols supported? Kim Kinnear - are these four options in use today? Comment - four seems like a lot. don't put the IP address inside the option. Peng: My organization has only implemented the first one. Kim: Four seems like a lot. Peng: it's always a tradeoff, so we are trying to narrow it down. Kim: I would not assign IP address inside an option. Ralph - Which WG are customers for this work? -Peng: motivated by lightweight 4over6 draft from softwire -Ted: doing this work elsewhere would not be a good idea since this is an extension to DHC Ralph - Are there other WGs with similar needs? Peng: I am from software, if other groups also interested they can raise their requirements, get in touch? Tirumaleswar Reddy from Cisco: PCP has a similar option and may be another place to do similar functionality ** No action items for working group draft-ietf-softwire-map Pres: Tomek Remi: MAP and 4rd implications ** Requesting comments and review. DHCPv6 Options guidelines -presenter: Sheng -Ted: Publish what you have. ** Please read and comment on the draft. DHCPv4 over IPv6 Server option -Pres: Tomek -two Approaches: FQDN vs single IPv6 address Francis - don't need name - use IP address - Do we need the flexibility and complexity inherent with using the name? Ted agrees with 3 pros and no name Bernie: Why only one address? Tomek: configured to have only one endpoint. Ted: would not want to send DHCP packet to many destinations and try to work through results Tomek: Asking for Adoption Suresh - no issue on asking for a last call in both WGs ** Tomek will send mail asking for adoption in dhc Agregated Traffic of DHCP Discover Messages Lianyuan Li - no presenter moved to end of schedule DHCPv4 and DHVPv6 Access-Network-ID Options Pres: Shwetha Need DHCP Option to relay this information to to gateway and server Authors asking to adopt as a WG Item mic: Kim Kinnear: Cisco - have one description about payload - describe once to say they have to be the same between IPv4 and IPv6, no definition of sub-options to 82 seen, may also need an IPv4 sub-option to 82. Suresh - need to do the relay options separately, one from client and another from relay if you want both to do it Sheng Jiang: separate IPv4 and IPv6 into two documents Sri: location based id based on ssid sees this as useful work to address and supports work ** Call for adoption on mailing list? DHCPv6 class-based-prefix Pres: Shwetha Use case for WLAN-EPC Integrated Architecture prefix propert requested by client Feedback? Kim Kinnear: if specified in ORO it changes the behavior of the server? Correct? Shwetha - want server to be capable of offering multiple prefixes. Either way it offers the prefix. ** No action proposed client-link-layer-addr-option Pres:Shwetha Bernie - in v4 client puts the address in not the relay, so little strange to say this is for correlating IPv4 and IPv6. Ted - are you proposing both relay and client approach Shwetha - proposing just using the relay agent ** No action proposed Lemon-dhc-dns-pd Pres: Ted -Let's CPE device say what it is capable of doing and let operator chose how to respond -Bernie comments on list ** Send out call for adoption RADIUS Option for DHCPv6 Relay Agents on Broadband Access Server Pres: Ted Container option for RADIUS attributes options included in relay forward packet ** Please read this draft and send comments. Prefix Pool Option for DHCPv6 Relay Agent Pres: Ted Paul asking about DHCP server pool knowledge provides automatic mechanism for route aggregation - just sending prefix related to the relay agent Erik Kline - what happens if prefix in the PD is not covered by the pool? ** Will do a call for adoption on the mailing list ** Leaf should check to make sure that the draft addresses Erik Kline's concern that the case where the delegated prefix is not covered by the prefix pool--this case should be specifically excluded. Multiple Stateful DHCPv6 Options Issues Pres: Bernie One set of messages exchanges is favored - if multiple timers use the shortest lifetime across all bindings Costas: would go for separate messages , didn't say he was not in favor of moving forward, will give formal review. Does not see performance review. Bernie: for multiple interfaces useful to have message bound together in single message exchange Andre, Incognito: 2nd state machine to deal with TAs anyway Bernie: since TAs are not renewable you need a different process Last Call? Ted - move to LC and see what happens ** Will do last call on mailing list. dhc-host-gen-id Pes: Sheng move to WGLC - been an wg item for a long time ** Will do last call on mailing list. yang-dhc-ipv4-dis-01 Mitigating Aggegated Traffic- New DHCPv4 Option Ted: should we move Ralph: overlaps with sunset4 WG, is there an option to never send a DISCOVER? if so move to sunset4. John Brzozowski: saw this with originally with the incremental addition of IPv6. in a perfect world we would just like to turn off IPv4. but in the realm world it would be useful to have this in Ipv4 as well Kim: How does the client find out about this? Ted: Problem with a v4 option is you send out a DHCPDISCOVER and what do you get back? work case is nothing. Ralph: scope of solution needs to be broader Ted: may need to belong in an RA ** No working group action at this time.