Re: [Roll] DRAFT minutes from IETF90 meeting
Ines Robles <mariainesrobles@googlemail.com> Thu, 24 July 2014 15:29 UTC
Return-Path: <mariainesrobles@googlemail.com>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33A181A0205 for <roll@ietfa.amsl.com>; Thu, 24 Jul 2014 08:29:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.124
X-Spam-Level: **
X-Spam-Status: No, score=2.124 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_46=0.6, J_CHICKENPOX_66=0.6, MANGLED_TOOL=2.3, SPF_PASS=-0.001, WEIRD_PORT=0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5NiRb7uh9FAp for <roll@ietfa.amsl.com>; Thu, 24 Jul 2014 08:29:42 -0700 (PDT)
Received: from mail-vc0-x22e.google.com (mail-vc0-x22e.google.com [IPv6:2607:f8b0:400c:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59CB61A0309 for <roll@ietf.org>; Thu, 24 Jul 2014 08:29:23 -0700 (PDT)
Received: by mail-vc0-f174.google.com with SMTP id la4so5177139vcb.33 for <roll@ietf.org>; Thu, 24 Jul 2014 08:29:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Rdf7zQTr8Hq4WdZTyYv30yjXnam+0y32qmw81nbCg7k=; b=evyoJ/qc1YqYwUbPv9GDBWIV2tcoUuyvkWDNJ8nKfemIWyWORDUGYy6117ZFbdwCEw KIo9FNn3c4IByqbYChdCTkVpPaVVelFuL0tJ9l37EWjDGmFp6nn1IG9VxucSHBYukz1d cpBXEnAdeY+ON8whCLG0SYjnvIEzq7LQ/W8ePZqd+2d6s4QeN5MMAs2pIQxTzUZU+Yh1 rxb62GkzuapbAYl0DhMfrn3wA5pbuOOmcad+OVp9LQJ0a8mNVZze/4yj6lIBkE9l+dY4 Zb3QC5cxLrcx1/aff0S4sE0/pcjULN19mhK4rQfSMVfLKyGP+KFCUKGRNgKWTu1c7sIB ouTQ==
MIME-Version: 1.0
X-Received: by 10.220.74.10 with SMTP id s10mr13222244vcj.61.1406215762218; Thu, 24 Jul 2014 08:29:22 -0700 (PDT)
Received: by 10.220.58.69 with HTTP; Thu, 24 Jul 2014 08:29:22 -0700 (PDT)
In-Reply-To: <69c78be764b6c1aa4b55168b26090b52@xs4all.nl>
References: <13664.1406213156@sandelman.ca> <69c78be764b6c1aa4b55168b26090b52@xs4all.nl>
Date: Thu, 24 Jul 2014 11:29:22 -0400
Message-ID: <CAP+sJUfWwd5vvOuVAPzyPz4y1CH8GAGkQi7wx+9z4pA4ALrT0Q@mail.gmail.com>
From: Ines Robles <mariainesrobles@googlemail.com>
To: consultancy@vanderstok.org, Routing Over Low power and Lossy networks <roll@ietf.org>
Content-Type: multipart/alternative; boundary="e89a8f647193fc146404fef21e9e"
Archived-At: http://mailarchive.ietf.org/arch/msg/roll/V1igZWIHGllxFDuUkVxyVDpRU2g
Cc: Michael Richardson <mcr+ietf@sandelman.ca>
Subject: Re: [Roll] DRAFT minutes from IETF90 meeting
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Routing Over Low power and Lossy networks <roll@ietf.org>
List-Id: Routing Over Low power and Lossy networks <roll.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/roll/>
List-Post: <mailto:roll@ietf.org>
List-Help: <mailto:roll-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 24 Jul 2014 15:29:46 -0000
Thank you Peter, the minutes are going to be updated with the audio of meetecho. Best, 2014-07-24 11:21 GMT-04:00 peter van der Stok <stokcons@xs4all.nl>: > Peter van der Stock indicated that you need control over <XXXX ????>. > -> I'm sorry, I don't remember this intervention. > > > [Pvds] can you send e-mail? XXXX > (was re: Autonomic/ANIMA) > -> I said probably "many thanks" > > Michael Richardson schreef op 2014-07-24 16:45: > >> many thanks to Thomas. Please /XXX for pieces that might need comment, >> here >> they are: >> - Peter van der Stock indicated that you need control over <XXXX >> ????>. >> Changed SHOULD to MAY >> >> - [Pvds] can you send e-mail? XXXX >> (was re: Autonomic/ANIMA) >> >> >> I'm not sure what "poipoi" means. >> >> >> 1300-1500 EDT Wednesday Afternoon Session I >> Territories room >> >> Agenda: https://datatracker.ietf.org/meeting/90/agenda/roll/ >> Etherpad: http://etherpad.tools.ietf.org:9000/p/notes-ietf-90-roll >> Meetecho (slides, audio, video): http://www.meetecho.com/ietf90/roll >> Audio-only stream: http://ietf90streaming.dnsalias.net/ietf/ietf907.m3u >> >> ROLL (Routing Over Low Power and Lossy Networks) >> >> Agenda >> ------ >> >> - State of all drafts (5min) >> - Related Internet-Drafts >> - State of all Issues (3min) >> - Updates to Milestones, Schedule and Practice (5min) >> - Feedback from Plugfest Event (5min) >> - Updates on: draft-ietf-roll-security-threats (10min) >> - Updates on: draft-ietf-roll-mpl-parameter-configuration (15min) >> - Updates on: draft-ietf-roll-admin-local-policy (15min) >> - Updates on: draft-ietf-roll-applicability-template. (5min) >> - Updates on: draft-ietf-roll-applicability-ami (10min) >> - Updates on: draft-thubert-6man-flow-label-for-rpl (15min) >> - Open floor (15 minutes) >> >> Minutes >> ------- >> >> - _[1300]_ Meeting starts >> - **[Ines]** starts the meeting >> - reminds note well >> - meetecho available, minutes taken, Jabber as well >> - presents agenda >> >> - _[1302]_ State of all drafts **(poipoi)** >> - Ines reminds status of drafts on sldies >> - Ines presents related I-D not adopted yet >> - Ines presents open tickets (see slides). Some work needed on the >> open >> tickets. >> - Ines presents milestones. Industrial applicability is behind. >> >> -Ines: need to decide whether nee to recharter or close. >> After work on MPL done, >> >> - Related Internet-Drafts **(poipoi)** >> - poipoi >> - _[1305]_ State of all Issues **(poipoi)** >> - poipoi >> - _[1310]_ Updates to Milestones, Schedule and Practice **(poipoi)** >> - poipoi >> - _[1315]_ Feedback from Plugfest Event **(poipoi)** >> - Thomas presents >> - Updates on: draft-ietf-roll-security-threats **(Michael >> Richardson)** >> - security applicability review. >> There was some lack of understanding amoung reviewers about the >> relationship between documents. After some voice communications, we >> agreed that we needed to be more explicit about the relatinoship to >> other documents. Peter van der Stock proposed some text which is >> now in >> different documents >> - Michael presents threats document >> >> - secu area review about sec doc (september 2013). Very good reivew. >> Some tickets were opened. Lots got fixed. Robert Cragie found >> innaccuracies >> and things tha didn't make sense. Tickets got opened and fixed >> The -08 uploaded on Monday July 21. Use the diff tool to see the >> changes. >> This document went through WGLC in Feb. Robert Cragie looked at it >> before >> sending to Adrian. Button pushed on Monday!!!!, should be discussed at >> IESG soon. This has been a long (3 year) process. >> Will be nice to have done. >> >> - one of the things that came up is that we have a number of messages >> in ROLL which are important and multicast. >> From DICE, we know that secuirty multicast is tricky. >> With symmetric keying, members can impersonate. Pieces in ROLL are >> not >> as strong as they could be as a result. >> -We clarified some of the text. Affects people that have a >> group-shared L2 key >> which is the same across the entire network. If you have a L2 master >> key >> from which link messags are derived, you can do something different. >> Ultimately, when multicast, you need to use key that all can read. >> This is something we clarified. >> - although DISare multicast, it's a "please answer me". >> The effect is that a timer goes faster. Not a huge deal if >> impersonated. >> - DIOs, if they are impersonated, that's an issue. >> One of the defenses is that is to unicast a DIS back, so mote sends >> a >> DIO again. There is a workaround for the paranoid. >> >> (Ines reminds about blue sheets) >> >> - Updates on: draft-ietf-roll-mpl-parameter-configuration **(Yusuke >> Doi)** >> - draft tp [ropose DHLC option to configureMPL >> - idea: control MPL. Used in smart meter network. Intended for slow >> update of MPL forwarded. Because MPL trickle algo has control >> between >> network usage and MPLlatency,this is a tradeoff. >> >> -parameter should be modifiable. >> >> - updated the draft to -01 weeks before the IETF meeting. >> Asking ROLL and DHC WG for feedback. DHC gave feedback. >> -02 on Monday. >> - operational considerations were added. What happens when >> MPL parameters were changes when MPL network is running >> - Peter van der Stock indicated that you need control over <XXXX >> ????>. >> Changed SHOULD to MAY >> >> - Asks WG for feedback. Please give review on these sentences >> >> -last week, lots of feedback from DHC. Most concern idea to make timer >> in floating point. Didn't like that. Changed the format, simplified. >> - Yusuke presents the format of the packets. the unit of the time is >> added to the packet. e.g.of tunit is 100,timer is 100ms. timers in >> uint16 >> - [MR] like floating point, but easily absorbed? >> - [YD] encoding is simple >> - [MR] for unknown options on DHCP server,people will have to >> calculate >> the hex anyway... >> - [YD] believe almost all implementers don't need to worry about >> this. Wrote Python code to generate this >> - mostly clients have to worry about this >> - very simple and straight forwards. Needs experience and feedback on >> range fo timers >> - current specification is only able to go up to 4.6 hours. >> Not sure if enough for all of usages, including expiration timers. >> If we need larger duration, need to think again on these timers >> - message: please give meyour feedback. >> - <no feedback from the room> >> - Ines asks to read the drafts and comment on ML >> >> - _[1325]_ Updates on: draft-ietf-roll-admin-local-policy >> **(Peter van der Stok)** >> - draft is about having admin local be automatically determined >> - multiple: realm-local scope, link-local and admin-local >> - different topologies possible >> - linklocal scope: automatically determined, single hop >> -real: local: automatically, determined by L2 >> - admin-local: multiple hop, include different L2 networks. >> - wish is that it would be automatically discovered >> - idea is that we have 2 router: one standard, and one router has MPL >> router with MPL forwarded. They all subscribe to >> ALL_MPL_FORWARDER scope 3 >> and 4 >> - about MPL routers, assuming R1 and R2, assuming they have 2 mesh >> networks >> What we want to do is have an MPL scope which includes mesh >> networks but excludes <the enterprise/home/etc.> >> - introduce boolean flag call MPL blocked. >> - we use protocol to determine whether should be true or false >> - start with MPLlock false. at least every hour, send an MPL message >> to >> MPL_FORWARDEDS_SCOPE. If no get message back, no interested nodes >> on that >> line, >> - query for nodes are interested, if none, close and don't use >> - result is that some interfaces are enabled (to the mesh), >> disabled (to the Northbound) >> - allows to automatically determine MPL zone >> -if you have an egde router, you should false interface to block >> - [Pascal]flow reminds in autonomic, see BoF.Encourages to ANIMA. >> Probably you could propose this there. >> - [Pvds] can you send e-mail? XXXX >> - [Michael] could you derive the 1h period, i.e. 3 Imax. If it >> can't maybe you have a new parameters forthat other doc. >> - [Pvds] good suggested >> - need also security section >> >> - _[1400]_ Updates on: draft-ietf-roll-applicability-template. >> - see beginning >> >> - Updates on: draft-ietf-roll-applicability-ami **(Daniel Popa)** >> - daniel indicates what changed . Sections 9-1, 9-2, 10, 7.2.2 >> - [Micheal] which issues are open? >> - [Daniel] open tickets: >> - #135, missed pointer to security section of RFC6550 >> - #136 add a section on security consideration when RPL >> security >> mechanisms are not used >> - #137 incorporate a model for initial and incremental >> deployments. Added section 9.1. and 9.2. For #136 >> and #137 will ask the WG to what we can change in the >> draft on what we can change >> - [Michael] excellent >> >> - _[1415]_ Updates on: draft-thubert-6man-flow-label-for-rpl **(poipoi)** >> - when started RPL, idea what to transport Hop by hop in flow label. >> 6man was redefining how it wouldoperate. At roll, we created hop by >> hop >> header in RFC6583. Header cannot be compressed >> - if a frame is coming from outside the RPL domain, you need to >> encapsulate the packet in IP-in-IP to be able to send back ICMP >> error and be >> able to strip it >> - these are many bit that we don't want to 802.15.4-2006 MAC >> - when worked in ISA100.11a, worked hard to eliminate in single bit. >> Real >> war to remove UDP checksum. Just for 2 bytes. This was key to the >> adoption >> of 6LoWPAN. >> - here, we are talking about 5+ octets: not acceptable >> - what important in 6282 compressed in the 2 bits which indicates how >> 6LoWPAN compresses the flow label and traffic class. we can have >> flow label >> with or without DSCP >> >> - proposed encoding fits in the 20 bits of the flow label. We are >> to replace 5 bytes by 20 bits. Rank expressed as 8 bites. You >> need to have a >> deployment with a min hop of 256. >> -[Michael]you are using upper 8 bits of rank? >> - [PT] yes. You can compress the rank in single octet. Described in >> OF0, operates wih minhop rank of 256 >> - RPL was prepared for this. Text says that 6583 is only one was. WE >> went >> to ROLL and 6man with this. Brian Carpenter has good response. Idea >> is to >> have a WGLC in this group, then a confirmation WGLC from 6man to >> make sure >> they agree. >> - if a packet has to come from the outside, it's responsibility of the >> root to add flow label that makes sense >> - Adrian was help out >> - draft has been out there for year. >> - [MR] feeling is that this is something we should adopt and seems >> that we >> can close to WGLC even with this document. Pascal, agree? >> - [PT] yes, different revisions from different WGs >> - [MR] is there a technical reason to adopt before publshing? >> - [Adrian] yes you can, the WG can support a draft with a name that >> doesn't start with WG name. People who think you should >> not be working >> - [Michael] will write line in charter? Will talk to 6man chairs >> to make sure >> - [PK] chair fo ISA100.11a. Fought over every bytes. As vice chair of >> 802.15, there is a reason why we don't haev longer packets. >> Shorter packets >> means less energy and better probability. Both hats say >> that this is what >> we need >> - [Pascal] we have running code for thos, Xavi demonstration de draft >> on >> OpenWSN implementation. Screenshot indicate wireshark,. You >> don't have a >> H2H header, was implemented very rapidly in OpenWSN >> >> - _[1448]_ Open floor **(poipoi)** >> - Ines asks AOB >> - Pascal: we are working at 6TiSCH how a pure 6LoWPAN client can be a >> leaf in a RPLnetwork. Today, all devices have to have code specific >> to RPL. >> A better idea is that you have what is necessary in 6LoWPAN, so >> that6LoPWAN >> device can be a lieaf of a RPL network. THere is a need for a >> classical IP >> host and moile hist. Invite you to 6lo. >> - as we work on 6TiSCH, there is a case where a node moves. >> We would have work on how to clean upstate route. Aswechartered? >> - [MR] cleaning up stale motes is in charter, but depends on >> milestones. >> Let's take to ML to have a better understanding on what this >> means. The >> question is what the impact is on node which don' have the code. >> - [Pascal] additional functionality >> =[MR] then this might fit in maintenance. >> - [MR]any other elements in open mic? >> - [Peter] will there be any other ROLL meetrings? >> =- [MR] opinion is that not in Honolulu. We have the home automation, >> threads, and AMI document which seems close to done. Unless we >> do somethng >> that expands the charter, don't see a reason to meet again >> before closing >> the WG. Of course, AD could put WG in maintenant mode. Maybe >> will becomes >> controversial and we need F2F meeting. >> - [PT]what would help you make that decision? 6TiSCH might come up >> with >> elements, and we would need ROLL to be there. >> - [MR]good idea, send question. We could go in hibernation and resume >> when needed. >> - [PT] plan is to fire a number of drafts, and when >> - [MR] better now than in december >> - [Ultich] personally, don't feel 6lo is right WG because not >> always RPL. >> - [MR] we could go to the routing Area WG >> - [Adrain] good point. It's ok for WG to say that shut down. It's >> nicer >> to close the WG and create a new WG when needed. Not a good >> idea to have WG >> sitting around. AD can sponsor documents. Do we need a >> forum for discussion >> and driving the work? If yes, we'll create a spacefor it. >> - [Ines] there were e-mails about open topics. We need to work on >> issues before rechartering/closing. >> >> >> >> >> -- >> Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works >> IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ >> >> >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >> > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll >
- [Roll] DRAFT minutes from IETF90 meeting Michael Richardson
- Re: [Roll] DRAFT minutes from IETF90 meeting Thomas Watteyne
- Re: [Roll] DRAFT minutes from IETF90 meeting peter van der Stok
- Re: [Roll] DRAFT minutes from IETF90 meeting Ines Robles