1. PLE Comment Resolution Update
Authors:
Notice: This document has been prepared to assist IEEE It is offered as a basis for discussion and is not binding on the contributing individual(s) or organization(s). The material in this document is subject to change in form and content after further study. The contributor(s) reserve(s) the right to add, amend or withdraw material contained herein.
Release: The contributor grants a free, irrevocable license to the IEEE to incorporate material contained in this contribution, and any modifications thereof, in the creation of an IEEE Standards publication; to copyright in the IEEE’s name any IEEE Standards publication even though it may include portions of this contribution; and at the IEEE’s sole discretion to permit others to reproduce in whole or in part the resulting IEEE Standards publication. The contributor also acknowledges and accepts that this contribution may be made public by IEEE
Patent Policy and Procedures: The contributor is familiar with the IEEE 802 Patent Policy and Procedures < ieee802.org/guides/bylaws/sb-bylaws.pdf>, including the statement "IEEE standards may include the known use of patent(s), including patent applications, provided the IEEE receives assurance from the patent holder or applicant with respect to patents essential for compliance with both mandatory and optional portions of the standard." Early disclosure to the Working Group of patent information that might be relevant to the standard is essential to reduce the possibility for delays in the development process and increase the likelihood that the draft publication will be approved for publication. Please notify the Chair as early as possible, in written or electronic form, if patented technology (or technology under patent application) might be incorporated into a draft standard being developed within the IEEE Working Group. If you have questions, contact the IEEE Patent Committee Administrator at
Zhao et al., Intel Corporation

2. Abstract
This document summarizes the progress on comment resolution on peer link establishment protocol
Zhao et al., Intel Corporation

3. Comment Categories Comments on PLE belong to Security category
Total 117 open comments
6 rejected, 2 accepted
8 categories on PLE
Major issues
Interface definition
Finite state machine
Reason codes
Explanation
Zhao et al., Intel Corporation

4. Update on Categories Uncategorized comments Re-classified comments
EMSA: 4751
Re-classified comments
Change to Editorial: 3085, 3961, 2450, 3009
Change to RFI: 3986, 4033
Zhao et al., Intel Corporation

5. Interface Issues
This category of comments are on the issues of MLME primitive definition and SME control
Issues asserted by comments
Parameter definition is not consistent
Not clear how to invoke primitives
Suggested resolution
Modify MLME primitives in 2.3 and update text in 11A.1.5 to match the definition
Improve 11A.1.5 to clarify how the primitives are invoked
Zhao et al., Intel Corporation

6. Finite State Machine
This category has comments on design issue and text of finite state machine for PLE.
Issues asserted by comments
Text is not clear on explaining all state transitions
Misunderstanding of the behavior of state machine
Link Identifiers are not needed
4-message exchange is not needed
Unclear “configuration parameters”
Unnecessary complexity
Suggested resolution
Add informative text in Annex to explain design rationale and issues
Update 11A.1.5 to better state transition
Add a diagram in 11A to demonstrate state machine behavior
Add a subclause in 11A.1.5 to define configuration parameters
Zhao et al., Intel Corporation

7. PLE Reason Codes
This category contains comments on defining reason codes for peer link establishment
Issues asserted by comments
Not using
Inconsistent definition
Need explanation of the usage
Suggest resolutions
Redesign reason codes to reflect failure cases in PLE
Update text in to define reason codes for PLE
Update text in 11A.1.5 to specify usage of reason codes
Zhao et al., Intel Corporation

8. Explanation Needed
This category contains comments on clarification of protocol behavior and design
Issues asserted by comments
Random link identifiers
Connectionless or not
Lack of overview of operations
Open authenticaiton neded?
How to deal with mesh capability IE
Suggest resolutions
Add normative text in 11A.1.5 to clarify link identifier requirements, how to set mesh capability IE, and how to deal with mesh capability IE
Add a subclause to explain the overview of protocol behavior for secure link establishment
Add informative text in Annex to explain design rationale and protocol behavior
Zhao et al., Intel Corporation

9. Frame Format
This category contains comments on frame format specification
Issues asserted by comments
Peer Link Open/Confirm/Close messages are inaccurate terms
Open/Confirm/Close IEs can be merged
Format specification shall be more precise
Suggested resolutions
Merge IEs and update related text
Drop procedure discussion in format specification
Message specification depends on general definition on mesh frame format
Zhao et al., Intel Corporation

10. Other Issues Random number requirements Terminology
Why random?
Scope?
Terminology
Bad terms: remote system, local system
Suggested: candidate peer MP and peer MP
Other security related issues
S1: management frame protection
S8: GTK usage and mesh broadcast traffic protection
Zhao et al., Intel Corporation

11. Call for Informative Text
Many comments from misunderstanding protocol requirements and behavior
Need informative text to explain design rationale, protocol requirements, failure cases
Will put text in Annex to help understanding
Zhao et al., Intel Corporation

12. Need for Link Instance Identifier?
To uniquely identify an instance of session between MPs is essential to achieve robustness
Binding messages with instance
Avoid race conditions
Allow achieve consistency property
See 11-07/237r0
Failure examples and protocol requirements discussion
Zhao et al., Intel Corporation

13. Mesh Link Life Cycle
The current peer link establishment protocol takes care of the link
From initiation until tearing down
Issues
Misleading name: PLE
Proposal: Peer Link Management protocol
Mismatched lifetimes of the link and the security association
Physical link can go away while SA still exists
Need a mechanism to revoke SA when the mesh link no longer works
Zhao et al., Intel Corporation