|
CID
|
Page
|
Line
|
Clause
|
Comment
|
Proposed Change
|
Ad-hoc Notes
|
mgr Reply to Ad-hoc Notes
|
|
6806
|
|
|
|
The document does not include all the changes w.r.t. D2.0 agreed in D2.0 comment resolution
|
Accurately implement all agreed changes
|
TGai and the Editor would appreciate if the comment would specify the submission or the CID of the comment resolutions which is claimed to be overlooked.
|
I can't provide a complete list, almost by definition. Some of my comments on D3.0 identify some instances, e.g. CID 6500 points out that CID 4744 was not implemented. Similarly, CID 6164 suggests CID 4746 was not implemented correctly,
and CID 6886 suggests CID 4693 was not implemented.
I don't know whether this is required TG practice, but TGm at least has a procedure whereby the correct implementation of each agreed change is independently (of the editor(s)) verified. TGai should adopt such a procedure (retrospectively, so stuff missed
out in D3.0 is not lost).
|
|
6804
|
|
|
|
The document does not accurately represent all the changes being proposed w.r.t. the baseline. It is therefore not possible to fully review it (cf. "unknown unknowns"), and furthermore this is likely to result in material being lost
when 11ai is merged into the baseline by TGmd
|
Accurately represent all proposed changes
|
The Editor would appreciate if the comment could identify a specific remidy, i.e. stating the part where of the draft where the comment claims that the draft does not reflect correctly changes to the baseline.
|
I can't provide a complete list, almost by definition. I did jot down instances for a while, until it became clear the problem was endemic, and then I gave up. Here are the instances I did capture:
83.60 para refers to FILS but nothing is underlined
90.7 refers to FILS but nothing is underlined
33.10 spurious underlining
16.11 spurious underline
s9.6 incorrect change tracking
106.45 "IEEE 802.11" insertion+deletion
106.60 change from "four" to "five" not tracked
107.57 spurious hyphen
109.56 spurious underline of "Key MIC"
81.42 deletion of "Figure 10-4" not shown
|
|
6779
|
|
|
8
|
Various things in clause 8 hint at normative behavioural requirements, but there is nothing to actually make them normative (see another comment for just one specific example)
|
Make sure that all behaviour hinted at in clause 8 actually has corresponding normative requiremets in subsequent clauses
|
The task group would very much appreciate a more detailed feedback on this matter, i.e. a submission identifying the remedy (including page and line number).
|
I cannot provide a complete list. CIDs 6111, 6499, 6591, 6928 and 6929 are examples. What is needed is for each field/subfield added to clause 8 to be matched to at least one normative statement in clause 9 onwards.
While addressing some of the points below, I found, for example, that there are no behavioural requirements on anything to do with DNS servers (DNS Server Address Request subfield, DNS Server IPv4 Address subfield, DNS Server IPv6 Address subfield, IPv4 DNS
Server MAC Address subfield, IPv6 DNS Server MAC Address subfield, DNS Server IPv4 Address Present subfield, DNS Server IPv6 Address Present subfield, IPv4 DNS Server MAC Address Present subfield, IPv6 DNS Server MAC Address Present subfield). NB: I am asking
about normative statements on *behaviour*, _not_ *format*.
Similarly, nothing on (Maximum) PHY Type or FILS Minimum Rate behaviour.
These are just the tip of the iceberg.
|
|
6645
|
|
|
|
NIST SP 800-56a-2013 seems to be important to FILS
|
Add a reference to this in clause 2
|
Please specify a page and line number
|
115.3, 115.49, 116.56, 117.21, 2.29
|
|
6632
|
111
|
34
|
11.11.2
|
Is this "shared [and secret] key" the same "shared key" as the key used for FILS authentication when a public key is not used? Apparently not, since this paragraph has no restrictions ... but then what is it?
|
Add a note to clarify that this "shared key" is not the same "shared key"
|
The TG believed that the word "derives" implies that the keys are not the same. The TG is open to reviewing a suggest text change that helps to clarify this issue.
|
I don't know what is intended here, so I cannot provide text. 1) Is "a shared and secret key" one key or two keys? 2) Which key(s) is/are this/these (i.e. reference to (a) subclause(s) which define(s) it/them)?
|
|
6624
|
|
|
|
There are 16 instances of "AEAD counter", but Aren't there two, one for sending stuff to the peer, and one for checking stuff received from the peer? Only two of the 16 instances are "peer's AEAD counter" and the rest are vague
|
Add some words to indicate which AEAD counter is being used in the 14 vague instances
|
Please spedify a page and line number / Cls.
|
109.53, 118.55 (2x), 118.57, 118.58, 120.12, 120.20, 120.21, 122.10, 122.19, 122.20, 123.20, 123.27, 123.31
|
|
6536
|
55
|
27
|
8.4.2.181.1
|
A STA might want to use a specific IP version for access to a DNS server
|
Make the "DNS Server Address Request" field into separate "IPv4" and "IPv6" fields (and make it clear this refers to the server address not to the type of addresses the server returns!)
|
TGai General: 2014-11-06 21:20:20Z - commenter asked to provide feedback on the use case for the specified issue.
|
The behavioural requirements are unclear (see CID 6779), but clearly an IPv4-only device does not want to be given an IPv6 DNS server. Also, even if a device supports both flavours of IP, it may be that its resolver only supports one
flavour (e.g. it is hard-wired, for simplicity, to send a specific DNS request using a template fixed to IPv4).
|
|
6404
|
49
|
42
|
8.4.2.177
|
The Public Key Indicator field is not described. All fields in all elements are always described in clause 8 -- that's the primary aim of clause 8!
|
Add a description of the Public Key Indicator field
|
Group would appreciate a submission that suggest detailed text / changes to the draft that can be adopted by the group
|
I have no idea what this field contains! Apparently it indicates "the issuer of [an AP's] certificate or a hash of its raw (uncertified) public key, as appropriate", but how it does so and how you know whether it contains the issuer
or the hash is a mystery to me.
|
|
6349
|
5
|
7
|
4.5.4
|
Can FILS be used by DMG STAs? The text suggests not
|
Reword to make it clear that DMG non-IBSS STAs can use FILS too. Suitable text is available on demand from the commenter
|
TGai General: 2014-11-06 15:04:07Z -- discussion of the comment. The group would favor the authentication and HLP parts to be supported by DMG non-IBSS STAs.
Group requests submission with corresponding text.
|
[Actually, this is just to allow DMG to be used with DMG infrastructure STAs. I don't think FILS is appropriate for DMG IBSS/PBSS/MBSS STAs. I don't know what "the authentication and HLP parts" means -- what are the other parts and
why should they not be supported by DMG infrastructure STAs?]
Delete "non-DMG" at 70.50, 96.61, 97.45.
At the end of 46.42 add "This valus is only used in the 2.4 GHz or 5 GHz band."
At the end of 46.45 add "This valus is only used in the 5 GHz band."
Change "An AP" to "A non-DMG AP" at 97.49.
Make the changes in 10.1.4.3.2 in 10.1.4.3.3 too.
Add "immediately" in 10.1.4.2.1 to match 10.1.4.2.2.
In Table 8-308d add the value 4 for DMG and in Table 8-308e add MCSes for DMG (need to find a DMG expert to say what would be a good choice).
See also CID 6722.
|
|
6329
|
|
|
|
There are mechanisms in clauses 6, 8 and 11 to transfer the GTK during FILS authentication. However, there are no mechanisms to transfer the IGTK, if MFP is being used
|
Add material in all the clauses identified in this comment to allow the IGTK to be transferred during FILS authentication
|
Request a submission from the commenter to show detailed changes to the draft that can be discussed and adopted by the group.
|
The mechanisms are actually there, they're just not described.
Change the para at 121.12 to say: "The AP constructs a Key Delivery element indicating the current GTK and Key RSC, and the current IGTK and IPN if management frame protection is enabled. The AP puts this element into the (Re)Association Response frame."
Add after the para: "NOTE—The GTK is carried in a GTK KDE. The IGTK and IPN are carried in an IGTK KDE."
At 123.2 change "as described in 8.4.2.182 (Key Delivery element)" to "in the (Re)Association Response frame"
At 123.2 change "The STA install GTK and set key RSC. GTK rekeying" to "The STA installs the GTK and Key RSC, and IGTK and IPN if management frame protection is enabled. GTK rekeying, and IGTK rekeying if management frame protection is enabled,".
At 59.31 change "KDE(s)" to "KDE List".
At 59.46 change "The encoding of the KDE field is defined in Table 11-6 (KDE) of 11.6.2 (EAPOL-Key frames)." to "The KDE List field contains one or more KDEs (see Figure 11-34 onwards in 11.6.2)."
Delete "for the GTK" at 18.28, 20.42, 22.60, 25.39.
Delete "of the GTK" at 59.25, 59.43.
[With acknowledgements to Jouni for his guidance.]
|