Proposed changes: Change Table 9-78—Coverage Class field parameters at 738.8 as follows: Coverage class value aAirPropagationTime (µs) 0–31 × 3, n is the value of the coverage class n 33-121 (n 32) / 30, – where is the value of the coverage class n 32,122–255 Reserved Proposed resolution: REVISED Make the changes shown under changes” for CID 7500 in <this document>, which effect the requested “Proposed change, allowing specification of coverage classes up to 900 m in 10 m increments. Identifiers Comment Proposed change CID 7572 "If the Direction element of the As it says in the comment Mark RISON SetKeyDescriptor indicates Transmit or Both 6.3.19.1 then the MAC uses the key information for the 222.31 transmission of all subsequent frames to which the key applies." -- it should be clearer this applies to the Key ID also, i.e. all subsequent frames transmitted for that type and peer specify the Key ID given CID 7604 Why is "Valid range" N/A for the Key ID in Copy the corresponding cell in Mark MLME-DELETEKEYS.request? MLME-SETKEYS.request 6.3.20.1.2 224.15 Discussion: Something needs to specify the Key ID to be used for transmission of encrypted frames. I originally thought this had to be the MLME-SETKEYS.request primitive, since no other request primitive, other than seems to carry a Key ID. However, Jouni MALINEN thinks that actually it’s the MAC that picks the Key ID (in an implementation-defined manner). MLME-PN-EXHAUSTION.indication and MLME-PN-WARNING.indication have N/A for the Key ID, which needs to be addressed too.
Proposed changes: Change Table 9-78—Coverage Class field parameters at 738.8 as follows: Coverage class value aAirPropagationTime (µs) 0–31 n × 3, n is the value of the coverage class 33-121 (n – 32) / 30, where n is the value of the coverage class 32,122–255 Reserved Proposed resolution: REVISED Make the changes shown under “Proposed changes” for CID 7500 in <this document>, which effect the requested change, allowing specification of coverage classes up to 900 m in 10 m increments. Identifiers Comment Proposed change CID 7572 Mark RISON 6.3.19.1 222.31 "If the Direction element of the SetKeyDescriptor indicates Transmit or Both then the MAC uses the key information for the transmission of all subsequent frames to which the key applies." -- it should be clearer this applies to the Key ID also, i.e. all subsequent frames transmitted for that type and peer specify the Key ID given As it says in the comment CID 7604 Mark 6.3.20.1.2 224.15 Why is "Valid range" N/A for the Key ID in MLME-DELETEKEYS.request? Copy the corresponding cell in MLME-SETKEYS.request Discussion: Something needs to specify the Key ID to be used for transmission of encrypted frames. I originally thought this had to be the MLME-SETKEYS.request primitive, since no other request primitive, other than seems to carry a Key ID. However, Jouni MALINEN thinks that actually it’s the MAC that picks the Key ID (in an implementation-defined manner). MLME-PN-EXHAUSTION.indication and MLME-PN-WARNING.indication have N/A for the Key ID, which needs to be addressed too.