1. 5 June 2015 Webex IPv6 over the TSCH mode of IEEE 802.15.4e Chairs:
Pascal Thubert
Thomas Watteyne
Etherpad for minutes:

2. Note Well
This summary is only meant to point you in the right direction, and doesn't have all the nuances. The IETF's IPR Policy is set forth in BCP 79; please read it carefully.
The brief summary:
By participating with the IETF, you agree to follow IETF processes.
If you are aware that a contribution of yours (something you write, say, or discuss in any IETF context) is covered by patents or patent applications, you need to disclose that fact.
You understand that meetings might be recorded, broadcast, and publicly archived.
For further information, talk to a chair, ask an Area Director, or review the following:
BCP 9 (on the Internet Standards Process)
BCP 25 (on the Working Group processes)
BCP 78 (on the IETF Trust)
BCP 79 (on Intellectual Property Rights in the IETF) 2 2

3. Reminder: Minutes are taken. This meeting is recorded
Reminder: Minutes are taken * This meeting is recorded ** Presence is logged ***
* Scribe; please contribute online to the minutes at
** Recordings and Minutes are public and may be subject to discovery in the event of litigation.
*** From the Webex login 3 3 3 3

4. Agenda * Administrivia _[4min]_ * Approval agenda
* Approval minutes last call
* update IETF93
* chair's statement on refocusing the work
* draft-ietf-6tisch-minimal
* security text statement _[10min]_ (chairs)
* update minimal with RPL DAGrank _[10min]_ (Nicola Accettura)
* draft-ietf-6tisch-coap
* preparation: please read
* mail thread: YANG hash clashes & full extended name _[20min]_
* AOB _[1min]_ 4 4 4 4 4

5. Administrivia

6. Admin is trivia
Approval Agenda
Approval minutes 6 6 6 6

7.
Requesting 2.5h meeting, Monday if possible
Agenda:
July 17-18: ETSI plugtest
July 19: hackathon
July 19-24: IETF93
Important dates (selected)
(Friday): Cut-off date for requests to schedule Working Group meetings at UTC 23:59. To request a Working Group session, use the IETF Meeting Session Request Tool.
(Friday): Preliminary agenda published for comment.
(Wednesday): Cutoff date for requests to reschedule Working Group and BOF meetings UTC 23:59.
(Friday): Final agenda to be published.
(Monday): Internet Draft submission cut-off (for all drafts, including -00) by UTC 23:59, upload using IETF ID Submission Tool. 7 7 7 7

8. 6TiSCH Status We need to return to and wrap up:
draft-ietf-6tisch-6top-interface
draft-ietf-6tisch-coap (dependency: CoMI)
We have one month before cut-off
Proposal: sprints:
Dedicated webex on 6/15, 4-5pm CET
Updated draft by webex 6/19
draft-ietf-6tisch-coap
Dedicated webex on 6/29, 4-5pm CET
Updated draft by webex 7/3

9. DetNews
BoF request Updated tentative Charter BoF Chairs selected with ADs (Pat Thaler and Lou Berger) Need respin of draft-finn-detnet-problem- statement New 6TiSCH doc in support draft-thubert-6tisch-4detnet
1/29/2018

10. DetNet BoF proposed Agenda
DetNet Problem Statement: draft-finn-detnet-problem-statement 15mn Charter work (online editing) Relation with other WGs (6TiSCH, PCE, TEAS, CCAMP...) 20mn WG deliverable RFCs and timescale 15mn WG sustaining documents (reqs and problem statement) 10mn Sustaining documents Smartgrid: draft-wetterwald-detnet-utilities-reqs 10mn pro-audio: draft-gunther-detnet-proaudio-req 10mn RAN: draft-korhonen-detnet-telreq 10mn 6TiSCH: draft-thubert-6tisch-4detnet 10mn Architecture: draft-finn-detnet-architecture 20mn
1/29/2018

11. draft-ietf-6tisch-minimal

12. security text statement
We had consensus on text in Dallas
92_dallas
Further discussion about alternate text
On interim meeting 8 May, chairs indicated that, if no consensus reached on alternate text, would revert to “Dallas text”
No consensus reached. Chairs ask editor of draft-ietf-6tisch-minimal to keep “Dallas text” in draft-ietf-6tisch-minimal-07

13. draft-ietf-6tisch-minimal-06
Status
Status:
Corrected errors in examples
Update RPL rank for DagRoot
Indicated default key in security section for Interop.
draft-ietf-6tisch-minimal-06 13 13

16. draft-ietf-6tisch-coap

17. Status draft-ietf-6tisch-coap depends on draft- vanderstok-core-comi
 important we keep an eye on draft- vanderstok-core-comi
Discussion about hash collision, 75 s, see archive/web/6tisch/current/maillist.html
Thanks to all for very constructive discussion
6TiSCH role: issue requirements to CoMI

18. CoMI crash-course
Check out archive/web/6tisch/current/msg03587.html

19. 6TiSCH requirements (WIP)
A client MUST NOT be required to read a file/get a well-known resource before being able to interact with it CoMI management interface
Example: 1000 nodes are switched on an try to join a network
1/29/2018

20. Andy’s proposal
I agree we should not need the client to retrieve the rehash info before using a server. The CoMI authors have discussed a solution which I will try to write up today where a special "hash-clash" error is returned by CoMI if a rehash is needed.    1) client requests module-A object with hash  "1234";         there is no extended-name/local-name,         just the YANG hash, used in any request    2) if '1234' has a collision in this server then a special error code is returned;        The return payload has the rehash info [old-hash, { module-name, new-hash }+]            { "1234": [                   "module-A":"4567",                   "module-X":"6523"               ]            }     3) the client gets the error info, and knows which module its "1234" is from.          It finds the correct module name in the array and replaces its old-hash          with the new-hash.    4) client re-sends the request, using hash "4567" instead of "1234" The rehash table goes away, and only this error info is used instead.

21. Requirements Discover version of module
We are standardizing a 6TiSCH YANG module in draft-ietf-6tisch-6top-interface
There will be multiple versions, a CoMI client MUST be able to retrieve the version of the YANG model (i.e. I-D version #, RFC #?)
Who should standardize the resource to retrieve the version number?
Resource Alias
Hashes are flexible and powerful, at the cost of complexity
In the case of 6TiSCH, we have a completely defined management interface.
We could easily define an alias for each resource 
That is:
Instead of GET example.com/mg/VNwQI ( super flexible, but has collisions possible)
Use GET example.com/6t/PoI ( no hash collisions, not flexible, but that’s find in this case)
 make hashes optional?
[similar to Alexander Pelov’s proposal to reserve some hash value for aliases, or use a hash with <30 bits]

22. Goal: Short IDs for frequent resource access for CoMI
(and hash clashes)

23. Problems discussed on the ML
Long ID values in URI and CBOR
YANG hash IDs take 5 characters in URI
5 bytes in CBOR
Hash clashes
No way to make sure hash values are unique..
Need mechanism to handle hash clashes

24. Long ID values in URI (5 char) and CBOR (5 bytes)
If IDs start with lots of leading zeroes…
CBOR has better representations (1 byte for IDs < 24, 2 bytes for IDs < 256)
Define YANG hash ID “compressed” URI form
Omit sending leading zeroes (e.g. “A”s)
Example:
0x e -> AAAA_ -> _
Minimal change to the draft, at no cost
Problem: very little probability for a hash to start with lots of zeroes
We want to chose which resources should profit most from the compression (e.g. IDs 0-255)

25. Very little probability for a hash to start with lots of zeroes
Reserve these special YANG hash IDs for local use
YANG hash aliases
Minimal change to the draft, at no cost
“YANG string hash values MUST be >= 256.” (checked by compiler before publishing)
IDs are used and assigned locally to optimize resource usage
E.g. ID = 1 uses 1 byte in CBOR and 1 byte in URI
Questions
Specify alias assignment mechanism in CoMI? Separate draft?

26. Configuring aliases Idea
Alias 0 contains meta-information : GET /mg/0
Aliases not supported
Resource not found
No alias configuration {}
Alias configuration
{"source_uri" : "/mg/yang.hash-alias", "hash": 0x127804bc}
{"source_uri" : "example.com/mg/yang.hash-alias", "hash": 0x127804bc}
POST to create or update /mg/0

27. Hash clashes Problem: How to handle YANG hash collisions
Idea: use managed module IDs and deterministic data node ID -> NO clashes
The YANG hash is no more a hash…
30 bits YANG id
20 bits for module ID (assigned by IETF)
10 bits for data node ID (generated deterministically)
Could have some structure (e.g. managed/unmanaged bit, etc.)
Deterministic ID assignment
Breadth-first ID assignment (?)

28. No hash clashes
Id=1 list CellList { Id=2 leaf CellID {} Id=3 leaf SlotframeID {} Id=4 leaf SlotOffset {} Id=5 leaf ChannelOffset {} Id=6 leaf LinkOption {} Id=7 leaf LinkType {} Id=8 leaf CellType {} Id=9 leaf NodeAddress {} Id=10 leaf TrackID {}

29. Conclusion YANG hash ID compression YANG hash ID aliasing
Runtime network optimization
Managed YANG hash
No clashes! (but need IETF management)
Lots of leading zeroes…
Reserve 0x x000000FF (or even 0x000003FF) for aliases

30. AOB ?

31. Thank you!