1. doc.: Submission, Slide 1 Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [SG ULI Report for Mar 2016 Session] Date Submitted: [14 Mar 2016] Source: [Patrick Kinney] Company [Kinney Consulting LLC] Address [Chicago area, IL, USA] Voice:[+1.847.960.3715], E-Mail:[pat.kinney@ieee.org] Re: [SG ULI Report for Mar 2016 Session.] Abstract:[Report for the Mar Session] Purpose:[] Notice:This document has been prepared to assist the IEEE P802.15. 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 P802.15.

2. doc.: Submission, Slide 2 SG ULI Meeting Goals  Tuesday, 15 Mar, PM2  Opening report, approve agenda, approve minutes from last session  Discussion on ULI PAR (15-15-760-07) and CSD (15-15-768-06)  Discussion on topics for tonight’s joint meeting with 802.1  802.15.12 PAR&CSD, Ethertype, et al  Wednesday 16 Mar, AM1:  Discussion on issues raised by WG comments or during joint 802.1 meeting  Modify ULI PAR and CSD, motion to WG to approve  Wednesday 16 Mar, PM1:  Discussion on issues raised during mid-week plenary meeting,  Modify ULI PAR and CSD.  Motion to WG to approve.  Thursday 17 Mar, AM1  Final edits to LLC PAR and CSD.  Motion to WG to approve.

3. doc.: Submission The IEEE-SA strongly recommends that at each WG meeting the chair or a designee: Show slides #1 through #4 of this presentation Advise the WG attendees that: The IEEE’s patent policy is described in Clause 6 of the IEEE-SA Standards Board Bylaws; Early identification of patent claims which may be essential for the use of standards under development is strongly encouraged; There may be Essential Patent Claims of which the IEEE is not aware. Additionally, neither the IEEE, the WG, nor the WG chair can ensure the accuracy or completeness of any assurance or whether any such assurance is, in fact, of a Patent Claim that is essential for the use of the standard under development. Instruct the WG Secretary to record in the minutes of the relevant WG meeting: That the foregoing information was provided and that slides 1 through 4 (and this slide 0, if applicable) were shown; That the chair or designee provided an opportunity for participants to identify patent claim(s)/patent application claim(s) and/or the holder of patent claim(s)/patent application claim(s) of which the participant is personally aware and that may be essential for the use of that standard Any responses that were given, specifically the patent claim(s)/patent application claim(s) and/or the holder of the patent claim(s)/patent application claim(s) that were identified (if any) and by whom. The WG Chair shall ensure that a request is made to any identified holders of potential essential patent claim(s) to complete and submit a Letter of Assurance. It is recommended that the WG chair review the guidance in IEEE-SA Standards Board Operations Manual 6.3.5 and in FAQs 14 and 15 on inclusion of potential Essential Patent Claims by incorporation or by reference. Note: WG includes Working Groups, Task Groups, and other standards-developing committees with a PAR approved by the IEEE-SA Standards Board. Instructions for the WG Chair, Slide 3

4. doc.: Submission Participants, Patents, and Duty to Inform All participants in this meeting have certain obligations under the IEEE-SA Patent Policy. Participants [Note: Quoted text excerpted from IEEE-SA Standards Board Bylaws subclause 6.2]: “Shall inform the IEEE (or cause the IEEE to be informed)” of the identity of each “holder of any potential Essential Patent Claims of which they are personally aware” if the claims are owned or controlled by the participant or the entity the participant is from, employed by, or otherwise represents “Should inform the IEEE (or cause the IEEE to be informed)” of the identity of “any other holders of potential Essential Patent Claims” (that is, third parties that are not affiliated with the participant, with the participant’s employer, or with anyone else that the participant is from or otherwise represents) The above does not apply if the patent claim is already the subject of an Accepted Letter of Assurance that applies to the proposed standard(s) under consideration by this group Early identification of holders of potential Essential Patent Claims is strongly encouraged No duty to perform a patent search Slide #1, Slide 4

5. doc.: Submission Patent Related Links All participants should be familiar with their obligations under the IEEE-SA Policies & Procedures for standards development. Patent Policy is stated in these sources: IEEE-SA Standards Boards Bylaws http://standards.ieee.org/develop/policies/bylaws/sect6-7.html#6 IEEE-SA Standards Board Operations Manual http://standards.ieee.org/develop/policies/opman/sect6.html#6.3 Material about the patent policy is available at http://standards.ieee.org/about/sasb/patcom/materials.html Slide #2 If you have questions, contact the IEEE-SA Standards Board Patent Committee Administrator at patcom@ieee.org or visit http://standards.ieee.org/about/sasb/patcom/index.html This slide set is available at https://development.standards.ieee.org/myproject/Public/mytools/mob/slideset.ppt, Slide 5

6. doc.: Submission Call for Potentially Essential Patents If anyone in this meeting is personally aware of the holder of any patent claims that are potentially essential to implementation of the proposed standard(s) under consideration by this group and that are not already the subject of an Accepted Letter of Assurance: Either speak up now or Provide the chair of this group with the identity of the holder(s) of any and all such claims as soon as possible or Cause an LOA to be submitted Slide #3, Slide 6

7. doc.: Submission, Slide 7 PAR and CSD discussion and changes  Opening report, approve agenda, approve minutes from last session  Review and discussion on ULI PAR (15-15-760-08) and CSD (15-15-768-07)  Discussion on topics for session’s joint meeting with 802.1  802.15.12 PAR&CSD, Ethertype, et al

8. doc.: Submission March 2016 Pat Kinney, Kinney Consulting LLCSlide 8 Resolutions to comments on SG 802.15.12 ULI PAR and CSD  WG 802.1 – sides 3 –7  WG 802.3 – slides 8 – 14  WG 802.11– slides 15 – 17  James Gilb – slides 18, 19  Paul Nikolich – slide 20

9. doc.: Submission March 2016 Pat Kinney, Kinney Consulting LLCSlide 9 15.12 Comments from 802.1 (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 802.15.9 Key Management Protocol, will be administered by the IEEE 802.15 Assigned Number Authority (ANA).”

10. doc.: Submission March 2016 Pat Kinney, Kinney Consulting LLCSlide 10 15.12 Comments from 802.1 (2) PAR Comments 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”.

11. doc.: Submission March 2016 Pat Kinney, Kinney Consulting LLCSlide 11 15.12 Comments from 802.1 (3) PAR(cont) 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

12. doc.: Submission March 2016 Pat Kinney, Kinney Consulting LLCSlide 12 15.12 Comments from 802.1 (4) CSD: We would like to discuss the relevance of 802.1AC to this project Accept; this subject was discussed at Monday‘s 802.1/802.15 joint meeting with an agreement to carry on this discussion at next 802.1/802.15 joint meeting (note: on this point, no change to the CSD is needed) Are you planning to use Ethernet Protocol Discrimination (EPD)? Accept; PAR and CSD now use wording “EtherType Protocol Discrimination“

13. doc.: Submission March 2016 Pat Kinney, Kinney Consulting LLCSlide 13 15.12 Comments from 802.1 (5) CSD: 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.“

14. doc.: Submission March 2016 Pat Kinney, Kinney Consulting LLCSlide 14 15.12 comments from 802.3 (1) PAR, 5.1 -100 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

15. doc.: Submission March 2016 Pat Kinney, Kinney Consulting LLCSlide 15 15.12 comments from 802.3 (2) PAR, 5.2 -The scope uses language and a reference architecture that does not appear to be in IEEE Std 802.15.4. As an upper layer protocol for 802.15.4, 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 802.15.4. If the proposed project will also better map 802.15.4 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? (comment continued on next slide)

16. doc.: Submission March 2016 Pat Kinney, Kinney Consulting LLCSlide 16 15.12 comments from 802.3 (3) PAR, 5.2 (cont) 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 802.15.4, for example “The ULI provides data and management service access points (SAPs) for interface to the IEEE 802.15.4 MAC.” Additionally, text has been changed to define regulation as “radio regulation.”

17. doc.: Submission March 2016 Pat Kinney, Kinney Consulting LLCSlide 17 15.12 comments from 802.3 (4) 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 much more difficult to understand.

18. doc.: Submission March 2016 Pat Kinney, Kinney Consulting LLCSlide 18 15.12 comments from 802.3 (5) 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 802.11’s comment PAR 5.6 -Missing full stop. Accept; period added.

19. doc.: Submission March 2016 Pat Kinney, Kinney Consulting LLCSlide 19 15.12 comments from 802.3 (6) 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 802.15.9 Key Management Protocol, will be administered by the IEEE 802.15 Assigned Number Authority (ANA). ”

20. doc.: Submission March 2016 Pat Kinney, Kinney Consulting LLCSlide 20 15.12 comments from 802.3 (7) CSD, 1.1.2 - 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

21. doc.: Submission March 2016 Pat Kinney, Kinney Consulting LLCSlide 21 15.12 Comments from 802.11 (1) 5.2 Scope: A consistent reference to “IEEE 802.15.4 MAC” should be made. The third instance of IEEE 802.15.4 should be IEEE 802.15.4 MAC. Expand 6TiSCH in first use. Accept: 3 rd instance changed, 6TiSCH expression was expanded at first use to “IPv6 over the TSCH mode of IEEE Std 802.15.4” 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 802.15.4 ancillary functionality, e.g. fragmentation, protocol differentiation and configuration.” Accept; text replaced with above

22. doc.: Submission March 2016 Pat Kinney, Kinney Consulting LLCSlide 22 15.12 Comments from 802.11 (2) 5.4 Need: The need statement is overstated. Suggest replace with: “As IEEE 802.15.4 devices have become widely deployed, deficiencies in IEEE Std 802.15.4 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 802.15.4 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

23. doc.: Submission March 2016 Pat Kinney, Kinney Consulting LLCSlide 23 15.12 Comments from 802.11 (3) 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 802.15.4” 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 802.15.4 Accept; full titles added 5.2 Scope: “KMP” should be “KMPs” Accept; changed to “KMPs”

24. doc.: Submission March 2016 Pat Kinney, Kinney Consulting LLCSlide 24 15.12 Comments from James Gilb (1) 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 PAR comments: 5.2: The Scope references EtherType as a protocol differentiation. To be more precise and to align with IEEE 802-2014, I suggest changing "EtherType" to be "EtherType Protocol Differentiation (EPD)" and add a note to 8.1 that EPD is defined in IEEE 802-2014 (including the full name of the standard to avoid NesCom comments). Accept; changed as suggested

25. doc.: Submission March 2016 Pat Kinney, Kinney Consulting LLCSlide 25 15.12 Comments from James Gilb (2) PAR comments(cont): 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 802.15.9 Key Management Protocol, will be administered by the IEEE 802.15 Assigned Number Authority (ANA).”

26. doc.: Submission March 2016 Pat Kinney, Kinney Consulting LLCSlide 26 15.12 Comments from Paul Nikolich 802.15.12 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 802.15 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? Response: We used to show project estimates but then the pendulum seemed to move in the direction of showing WG voters. We are fine with making this a project estimate and will do that for all future projects. 15.12 is attracting more interest because of the tie-in to IETF and the fact it facilitates the use of 15.4 in IP based IoT apps which is becoming the preferred model. Our guess is we will see around 30 regular participants at 802 sessions, 20 of whom are already active in 802.15 with 10 new ones from those who have a stake in IETF IoT oriented RFCs and or have a stake in IoT networks. Additionally we expect a lot of non-member participation, in particular from IETF WGs, such as 6tisch, 6lo and CORE, outside of our 802 face to face sessions.

27. doc.: Submission, Slide 27 Meeting Accomplishments  Resolved comments from WGs  Modified PAR and CSD accordingly WG Motion: request that the PAR and CSD contained in documents 15-15-760-08 and 15-15-768-07, respectively, be approved by the IEEE 802.15 WG and that the EC be requested to forward the PAR to NesCom. The 802.15 working group chair and technical editor are authorized to make additional modifications to the PAR and CSD as needed to reflect EC discussion at its closing meeting. Moved by Pat Kinney, seconded by Ben Rolfe Upon no discussion the vote was taken with the results of 40/0/0, motion carries