doc.: IEEE /0010r1 Submission NameAffiliationsAddressPhone Hitoshi MORIOKAAllied Telesis R&D Center Tenjin, Chuo-ku, Fukuoka JAPAN January 2014 Hitoshi Morioka, Allied Telesis R&D CenterSlide 1 Resolution Policies for Remaining Comments Date: Authors:

doc.: IEEE /0010r1 Submission January 2014 Hitoshi Morioka, Allied Telesis R&D CenterSlide 2 Abstract This document describes the resolution policies for the remaining comments assigned to Hitoshi Morioka. The CIDs are 3242, 2389, 2998, 3078, 3367, 3388, 2090, 2164, 3178 and 2613.

doc.: IEEE /0010r1 Submission CID3242 Comment –It is odd that the GTK is not wrapped with AES key wrap, as is done elsewhere in While this field is covered by the AEAD encryption, best practices as defined by NIST would have the key wrapped even when covered by AEAD. Proposed Change –Either add key wrapping or include a note as to why the GTK does not need to be key wrapped. Resolution Policy –Add key wrapping for GTK. The key wrapping method will be imported from existing EAPOL-Key key wrapping. January 2014 Hitoshi Morioka, Allied Telesis R&D CenterSlide 3

doc.: IEEE /0010r1 Submission CID2389, 2998, 3078, 3367, 3388 Comment –These comments pointed out the lack of Annex B (PICS). Proposed Change –Add description in Annex B. Resolution Policy –I already presented in 11-13/1503r0 and I got feedback. –I’ll implement the feedback in the next revision. January 2014 Hitoshi Morioka, Allied Telesis R&D CenterSlide 4

doc.: IEEE /0010r1 Submission CID2090, 2164, 3178 (Comments) Comment –"The choice is determined by the STA based on what IP Address assignment methods are supported by the AP.” [CID2090] This smacks of multiple options for political rather than technical reasons. If there is genuinely no good technical reason, expect the market to be confused and support neither of them. –I really question the wisdom of doing L3 work at L2. L3 will evolve... IPv9, IPv99. By adding these fixed fields in billions of deployed products in the wrong layer we make it VASTLY harder to upgrade the network. We run the risk of forcing the network to ossify. Related, the video I have seen for poor discovery performance without FILS (~10sec) must have used the worst DHCP server in the world since IMHO most users in most environments have a completely different & better experience; so I am not yet convinced of the technical need for this layer violation. (OK, Proxy ARP has already gone here...) [CID2164] –"using FILS IP address assignment method" No reference to this method is provided. Assuming the intended reference is to subclause (IP address assignment using FILS IP Address Configuration), then I have the following additional comment: as an IP address assignment protocol definition, this procedure is unnecessary and inadequate. Unnecessary because it does not differentiate itself in any way from widely implemented protocols that achieve the same purpose (DHCP and IPv6 autoaddress configuration). Inadequate because it does not address failure cases, address revocation, exchange timeouts, address renewal, conflict resolution, mobility within an ESS, etc. [CID3178] January 2014 Hitoshi Morioka, Allied Telesis R&D CenterSlide 5

doc.: IEEE /0010r1 Submission CID2090, 2164, 3178 (Proposed Changes) Proposed Change –Either justify why there are two optional methods, or make one of them mandatory. [CID2090] –Remove the encapsulated IPv4/v6 address assignment at L2 (just rely on encapsulated HLPs, or - require that ALL FILS STAs shall support the HLP encap mechanism so that IPv9 or v99 (and other-than-IP address assignment) can be supported without ANY future change to L2 devices built in 2014/15. Else, as a minimum, a) provide a survey of high density networks using properly desinged DHCP servers and show that this is a genuine problem needing an IEEE solution, and b) review this layer violation with ARCH and [CID2164] –Remove subclauses , and [CID3178] January 2014 Hitoshi Morioka, Allied Telesis R&D CenterSlide 6

doc.: IEEE /0010r1 Submission CID2090, 2164, 3178 (Resolution Policy) Resolution Policy –Remove “FILS IP address configuration”. (clause , and modify related clauses) –Because the all information carried by “FILS IP address request TLV” ( ), “FILS IP address response TLV” ( ) and “FILS DNS Information TLV” ( ) can be carried by the higher layer packets such as DHCP, ARP, RA and NA. –By this modification, the higher layer setup method (frame format and protocol sequense) can be unified. –It will affect the resolution for CID2172, 2176 and the resolutions for removed clauses. –I discussed with George Cherian by . But I cannot find any technical benefits of “FILS IP address configuration” at this moment. –I’ll make a resolution proposal to remove “FILS IP address configuration”. January 2014 Hitoshi Morioka, Allied Telesis R&D CenterSlide 7

doc.: IEEE /0010r1 Submission CID2613 Comment –Example usage of "FILS HLP wrapped data TLV" should be introduced. Proposed Change –Add examples usage of "FILS HLP wrapped data TLV" as a new Annex. See 11-13/1047r0. Resolution Policy –Add the example usage based on 11-13/1047r0 according to the resolution for CID2090. –Or reject the comment as “out of scope”. IETF matter? –I’ll make a resolution proposal based on 11-13/1047r0 and ask the group whether “it’s our business” or “it’s IETF business”. January 2014 Hitoshi Morioka, Allied Telesis R&D CenterSlide 8