doc.: Submission, Slide 1 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [SG ULI Comment Responses on PAR and CSD] Date Submitted: [16 Mar 2016] Source: [Patrick Kinney] Company [Kinney Consulting LLC] Address [Chicago area, IL, USA] Voice:[ ], Re: [SG ULI Comment Responses on PAR and CSD] Abstract:[Comment Responses on PAR and CSD] Purpose:[] Notice:This document has been prepared to assist the IEEE P 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 acknowledges and accepts that this contribution becomes the property of IEEE and may be made publicly available by P

doc.: Submission, Slide 2 Resolutions to comments on SG ULI PAR and CSD  WG – sides 3, 4  WG – slides 5, 6, 7, 8, 9  WG – slides 10, 11  James Gilb – slide 12  Paul Nikolich – slide 13

doc.: Submission, Slide 3 Responses and changes due to WG comments (1) PAR Comments 6.1.b answer is not clear. It says there will be registration but it doesn't say what will be registered. Accept; 6.1.b now reads: “As noted in the scope and need for the project, this project will use EPD for multiple higher layer protocols. Values of the Multiplex ID below 1500, as defined in IEEE Std Key Management Protocol, will be administered by the IEEE Assigned Number Authority (ANA). ” 5.2 The scope does not obviously allow for fragmentation. If fragmentation is part of the project it must be mentioned in the scope. Please clarify what is optional ("for optional use"). If the project is going to define header compression, this needs to be mentioned in the scope. Please clarify what you mean by "upper Layer-2 sublayer (L2+)”. Accept; fragmentation is now listed in scope, wording changed to clarify what is optional, header compression is now listed in scope, “upper Layer-2 sublayer (L2+)” changed to “upper Layer 2”.

doc.: Submission, Slide 4 Responses and changes due to WG comments (2) PAR 5.5 Does the L3 abstraction refer to header compression? Revise; “L3 abstraction” was not appropriate for this PAR and has been deleted 8.1 The material here does not belong in the PAR. This material might belong in the CSD. Accept; material in 8.1 deleted, now 8.1 states lists and description of standards stated in PAR as per NesCom procedure CSD We would like to discuss the relevance of 802.1AC to this project Accept; this subject was discussed at Monday‘s 802.1/ joint meeting (note: on this point no change to the CSD is needed) with an agreement to carry on this discussion at next 802.1/ joint meeting Are you planning to use Ethernet Protocol Discrimination (EPD)? Accept; PAR and CSD now use wording “EtherType Protocol Discrimination“ In 1.2.4(a) the phrase "along with new functionalities" undermines the technical feasibility argument. Accept; phrase deleted 1.2.5(a) the answer given doesn't address the question. The proposed project does not affect the balance of costs between the infrastructure and attached stations. Accept; 1.2.5(a) replaced with “The proposed project does not affect the balance of costs between the infrastructure and attached stations.“

doc.: Submission, Slide 5 Responses and changes due to WG comments (1) PAR, active participants seems a bit optimistic, though the PAR instruction has moved back to a very liberal wording (our WGs are different than the WGs in most of IEEE-SA). How many will be actively involved in development of the draft (perhaps starting with anticipated TG members), not including those submitting a meaningless WG ballot to keep working group voting rights. Accept; active participants changed to 30

doc.: Submission, Slide 6 Responses and changes due to WG comments (2) PAR, 5.2 -The scope is uses language and a reference architecture that does not appear to be in IEEE Std As an upper layer protocol for , it should use terminology consistent with that standard's Figure-3 LP-WPAN device architecture. The scope should also indicate how it relates to the service interfaces defined in that standard. As written, it is very difficult to relate the proposed work to the architecture of If the proposed project will also better map architectural blocks to the OSI reference model, that needs to be stated somewhere (not in the scope). The term regulation requirements is very loaded and left very undefined. Regulation of what, or how is it related to radio frequency regulation? The phrase "Furthermore, the ULI integrates upper Layer 2 sub-layer (L2+) functionalities..." is unnecessarily loaded with jargon for an unspecified architecture. How about "Furthermore, the ULI integrates upper Layer 2 functionalities...". Accept; language changed to that used in IEEE Std , for example “The ULI provides data and management service access points (SAPs) for interface to the IEEE MAC.” Additionally, text has been changed to define regulation as “radio regulation.”

doc.: Submission, Slide 7 Responses and changes due to WG comments (3) PAR, 5.2, (continued) How does "L2 routing (L2R) protocols" relate to IEEE 802 bridging? The number of acronyms in the scope makes it very difficult to read. It is noted that 5.5 Need reuses many of the terms, but a cleaner reading Scope is recommended as it appears in the standard, and catalog listings for the standard. Response: L2 routing protocols does not relate to IEEE bridging since IEEE 802 bridging does not exist between 64-bit MAC address protocols and 48-bit MAC address protocols, L2R is a layer 2 routing protocol for mesh networking (i.e. mesh under). Acronym comment noted but acronyms were used correctly (spelled out first time used) and not using them would make Scope more difficult to understand. PAR, 5.5 -The bulleted list seems to be two level with the last five belonging nested under the sixth from last bullet. Consider an outline format and proper use of capitalization and punctuation for lists (first three items as sentences and the last six items as a single sentence with each list item except last ending with a semicolon). Text formatting that is not supported by the PAR tool should not be used. Accept; text was changed to clarify and eliminate bullets as suggested by ’s comment

doc.: Submission, Slide 8 Responses and changes due to WG comments (4) PAR 5.6 -Missing full stop. Accept; period added PAR, 6.1.b -The compression of higher layer protocols is unrelated to registration activities. If it needs to be said, say it somewhere else. If the only registration activity is use of EtherTypes, or being allocated an EtherType, just say that. If the standard will have other registration components, those should be explained. Members of the RAC participating in the ad hoc are worried if you will attempt to get EtherType assignments to use as subtypes. This would be an improper use! Please engage the RAC early (before mandatory coordination) to make sure there will not be a problem. Response; thank you for your guidance. 6.1.b has been modified to: “As noted in the scope and need for the project, this project will use EPD for multiple higher layer protocols. Values of the Multiplex ID below 1500, as defined in IEEE Std Key Management Protocol, will be administered by the IEEE Assigned Number Authority (ANA). ”

doc.: Submission, Slide 9 Responses and changes due to WG comments (5) CSD, This seems to be in possible conflict with the PAR scope including "regulation requirements". (PAR, 5.2 comment notes this term is undefined and consequently fixing the scope may clarify the relationship to "regulation" so that this answer is valid.) Accept; PAR 5.2 changed to state “radio regulation” CSD, 1.2.1,a - The Internet of Things is more than wireless sensors. (Wireless sensors would generally be considered some of the things in the IOT.) Minor grammar: line 6 should read the IOT marketplace, Accept; text changed to read “…part of the Internet of Things...”, and “IOT marketplace” CSD, 1.2.1,b - Minor readability: line 4, remove "and many more”. Accept; “and many more” deleted

doc.: Submission, Slide 10 Responses and changes due to WG comments (1) 5.2 Scope: A consistent reference to “IEEE MAC” should be made. The third instance of IEEE should be IEEE MAC. Expand 6TiSCH in first use. Accept; 3 rd instance changed, expression was expanded, “IPv6 over the TSCH mode of IEEE Std ” 5.4 Purpose: The purpose is not clear -it seams to refer to changes required for itself Suggested replacement: “This standard defines an upper layer interface to support and harmonize the IEEE ancillary functionality, e.g. fragmentation, protocol differentiation and configuration.” Accept; text replaced with above 5.4 Need: The need statement is overstated. Suggest replace with: “As IEEE devices have become widely deployed, deficiencies in IEEE Std became apparent as an expanding set of applications were addressed. To address these deficiencies numerous L2+ protocols were independently developed to interface to the IEEE MAC sublayer. These L2+ protocols, such as KMP, L2R, 6TOP, and network layer abstraction, often replicate ancillary functionality, e.g. fragmentation and protocol differentiation, in an inconsistent and often incompatible manner.” Accept; text replaced with above except L2+ was replaced with L2

doc.: Submission, Slide 11 Responses and changes due to WG comments (2) 8.1 This section is for explanatory text, not expanded text from the PAR sections. Suggest that 8.1 be deleted, and that the titles of the cited standards be listed: i.e. “IEEE ” Note: From NesCom Conventions #5. “…For references to other standards within the Scope and Purpose fields, the number, title, date (if appropriate), and source of the referenced standards shall be listed in the Additional Explanatory Notes field. “ Add full titles for IEEE Accept; full titles added 5.2 Scope: “KMP” should be “KMPs” Accept; changed to “KMPs”

doc.: Submission, Slide 12 Responses and changes due to James Gilb’s comments PAR comments: 5.2: The Scope references EtherType as a protocol differentiation. To be more precise and to align with IEEE , I suggest changing "EtherType" to be "EtherType Protocol Differentiation (EPD)" and add a note to 8.1 that EPD is defined in IEEE (including the full name of the standard to avoid NesCom comments). Accept; changed as suggested 6.1.b: What registration is anticipated with regards to this proposed standards? EtherTypes already exist and so I don't see that this adds any new registration activity. When we use MAC addresses in the standard, we don't mention that there is a registration activity associated with them because it is not a new activity. Response: in response to this and other comments on this subject 6.1.b has been changed to the following “As noted in the scope and need for the project, this project will use EPD for multiple higher layer protocols. Values of the Multiplex ID below 1500, as defined in IEEE Std Key Management Protocol, will be administered by the IEEE Assigned Number Authority (ANA). ” CSD comments: General: A similar comment about using just "EtherType" which is a number and EPD, which is a function/protocol. I would suggest using EPD instead. Accept; changed as noted

doc.: Submission, Slide 13 Responses and changes due to Paul Nikolich’s comment project item 5.1. Please provide justification for the approximately 100 participants identified for this project. Approximately how many man-years of effort will be required to complete the project over its projected 28 month duration? Which classes of entities (e.g., silicon vendor, system vendor, service provider, etc.) do you believe will sponsor for these individuals over the project's lifetime? A large portion of these individuals will be new additions to the roster and I'm wondering if you can provide the rationale that will attract new participants given the high cost of participation. Perhaps a reduction in the estimate for the approximate number of people to be actively involved will be more realistic? Accept; number changed to 30