Chairs: Pascal Thubert Thomas Watteyne Etherpad for minutes: (exceptionally) IPv6 over the TSCH mode of IEEE e 09 January 2015 Webex

22 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)

3333 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

44444 Agenda Administrivia[7min] –Approval agenda –Approval minutes last call –Updates since last call Status draft-ietf-6tisch-minimal[10min] summary of security discussions[10min] open mike rechartering[30min] AOB[3min]

Administrivia

6666 Approval Agenda Approval minutes last call

Updates since 12/16/2014 draft-ietf-6tisch-tsch-05 published Nits Updated thanks Fixing references Publication requested to IESGPublication requested to IESG draft-ietf-6tisch-minimal-05 published See next presentation 6TiSCH security call Tuesday 1/6 11pm CET Minutes pending

Status draft-ietf-6tisch-minimal

LC completed Comments on impact of join discussion by Kris (Pascal Answered) Minimal starts after key is obtained Maybe a need to be more open to the way the key and schedule are obtained (if a result of a join process) Comments on Time Sync by Kris Solved on bitbucket Open issue on NHC reference What of we do not reference anything Else what should default be Status on appeal to ADs See Brian’s answer next slide

Talk with Brian Haberman > All in all, if you agree, we can progress the draft in IESG review leaving that particular reference open to be changed till later in the process? Why would you expect that to be acceptable? If a piece of the spec is needed for interoperability, it needs to be there during the review. Why send it to the IESG if there are still questions on how that piece will be done? If it is left out, how will anyone know if there is consensus on the spec as a whole? It seems to me that: 1. There have been several proposals put forth 2. Issues have been raised on each one So, it seems prudent (to me) to look at each of the alternatives and determine which warts everyone concerned is willing to live with. Running code is a good way to do that. Making that determination needs to be done before the spec is sent to the IESG.

Summary RPL RPI/RH3 call Problem: * RPL adds 3 artifacts in data packets. These are an IP in IP encapsulation, an option in HbH header (called RPI) and an RH (RH type 3). * These artifacts are only partially and sub- optimally compressed in 6LoWPAN. * The RPI is not compressed at all, consumes 8 octets per packet, and will cause IP in IP encapsulation in some packets.

Summary RPL RPI/RH3 call History * ROLL agreed in Toronto to place the RPI data in the IPv6 flow label, which would reduce the per- packet overhead from 8 bytes into 20 bits and would avoid additional overhead from IP in IP encapsulation. Implementation was demonstrated at the 6TiSCH plug fest. * Brian Carpenter reviewed the work and approved it, provided that the LLN operations would not leak outside the LLN. * ROLL submitted the case to 6MAN for validation (that’s the flow label draft) * During the 6MAN review, it was suggested that an alternate approach to compress the RPI data could be found at 6lo, and evaluation work started in that direction (that’s the NHC draft). * 6TiSCH supported that work and asked for help from 6lo * reviewing the NHC draft in Honolulu, 6lo decided that we would need to understand how RH3 would be compressed in that approach to fully evaluate it. * The authors found that extending the NHC approach to IP in IP and RH3 lead to too much implementation complexity, and that placing the RPL artifacts in a separate dispatch from the original packet lead to a more efficient processing at source, destination and intermediate nodes a better reuse of existing 6LoWPAN compression code. They produced a new draft called the Routing Dispatch draft.

Summary RPL RPI/RH3 call 3 proposals to compress RPL artifacts in data not all of them necessarily in all packets, which makes the compression operation delicate: * The most efficient is based on Flow Label (less bits and no IP in IP) but is incomplete since it does not cover the RH. * A 6LoWPAN alternate, the NHC draft, which also compresses the RPI, but requires IP in IP and does not cover RH either. * Another 6LoWPAN alternate called the Routing Dispatch draft. This one addresses the whole story (IP in IP, RPI, and RH3). This is the response from the NHC authors to the 6lo concerns on the NHC approach.

Summary RPL RPI/RH3 call 3 possible outcomes on the IoT/FL question to 6MAN: * No change to existing specs. In that case, even resetting the Flow Label inside the LLN is not acceptable. There are little chances that IoT devices conform. * Only (re)setting the FL to zero inside the LLN is acceptable, in which case the FL cannot be used for RPI. This ask is critical for all LLNs and ensures continued conformance of existing standards such as ISA100.11a. * LLNs are free to use the FL as seem fit, as long as this activity does not leak outside the LLN and the setting of outgoing packets conforms 6437 (this is the current ask of the 6MAN FL draft that Brian Carpenter reviewed)

Summary RPL RPI/RH3 call 6MAN chairs and Brian questioned the process order: * We appear to be doing things backwards. First IOT groups should agree on a solution and then, IF that solution really needs to impact the flow label, then the case should be presented to 6MAN. To which is was replied that: * There may be a need to involve 6MAN iff IPv6 is impacted, which may also be the case in the 3 rd approach, to be evaluated. * There is a need to reset the flow label regardless of whether we use it to transport RPL information. * We are in a loop where 6TiSCH refuses to evaluate a flow label proposal unless 6MAN agrees it is acceptable. This loop will probably kill the approach without evaluation.

Summary RPL RPI/RH3 call Actions Brian suggested an cross IoT groups interim call. The call should move forward with Ralph’s items and conclude on the approach that we decide to follow for the RPI. Depending on the outcome, the asks to 6MAN may be revised. The procedures for virtual interim meetings ( indicate that "Conference calls and jabber sessions must be announced at least two weeks prior to the call or session, and the agenda must be published at least one week before call or session"). If the announcement goes early next week, the meeting could happen around January

last call draft-ietf-6tisch-coap

Status draft-ietf-6tisch-coap-02 published 04 December 2014 To avoid parallel last calls, it was proposed to do last call beginning of January 2015 Since last call for draft minimal completed are we ready to start now?

preparation for draft-ietf- 6tisch-terminology last call

Draft I-D Unpublished version ready for preview terminology/src/master/draft-ietf-6tisch- terminology-03.txthttps://bitbucket.org/6tisch/draft-ietf-6tisch- terminology/src/master/draft-ietf-6tisch- terminology-03.txt Announced at archive/web/6tisch/current/msg02908.htmlhttp:// archive/web/6tisch/current/msg02908.html Next steps: OK for WG to publish? Send feedback to ML (deadline 1/16)?

summary of security discussions

open mike rechartering

Rechartering Revise current charter to point on ? => decision to maintain 15.4e for now When should we recharter? Potential new items for rechartering Join Process Dynamic scheduling OTF Chunks appropriation DetNet / Tracks

AOB ?

Next call Next call 23 January am PDT archive/web/6tisch/current/msg02902.htmlhttp:// archive/web/6tisch/current/msg02902.html Change time from 8am to 7am PDT? Indicate your preference on ML Presentation Update I-Ds? draft-dujovne-6tisch-on-the-fly-04 draft-piro-6tisch-security-issues-03

Thank you!