Re: [Roll] DRAFT minutes from IETF90 meeting
peter van der Stok <stokcons@xs4all.nl> Thu, 24 July 2014 15:24 UTC
Return-Path: <stokcons@xs4all.nl>
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 16F6D1A037A for <roll@ietfa.amsl.com>; Thu, 24 Jul 2014 08:24:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 3.695
X-Spam-Level: ***
X-Spam-Status: No, score=3.695 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, J_CHICKENPOX_46=0.6, J_CHICKENPOX_66=0.6, MANGLED_TOOL=2.3, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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 kw-_9o21lDvY for <roll@ietfa.amsl.com>; Thu, 24 Jul 2014 08:24:28 -0700 (PDT)
Received: from smtp-vbr2.xs4all.nl (smtp-vbr2.xs4all.nl [194.109.24.22]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BA571A0199 for <roll@ietf.org>; Thu, 24 Jul 2014 08:22:03 -0700 (PDT)
Received: from roundcube.xs4all.nl (roundcube4.xs4all.net [194.109.20.200]) by smtp-vbr2.xs4all.nl (8.13.8/8.13.8) with ESMTP id s6OFLxoc034906; Thu, 24 Jul 2014 17:22:00 +0200 (CEST) (envelope-from stokcons@xs4all.nl)
Received: from wireless-v6.meeting.ietf.org ([2001:67c:370:160:4504:afd5:eade:ce52]) by roundcube.xs4all.nl with HTTP (HTTP/1.1 POST); Thu, 24 Jul 2014 17:21:59 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Content-Transfer-Encoding: 7bit
Date: Thu, 24 Jul 2014 17:21:59 +0200
From: peter van der Stok <stokcons@xs4all.nl>
To: Routing Over Low power and Lossy networks <roll@ietf.org>
Organization: vanderstok consultancy
Mail-Reply-To: consultancy@vanderstok.org
In-Reply-To: <13664.1406213156@sandelman.ca>
References: <13664.1406213156@sandelman.ca>
Message-ID: <69c78be764b6c1aa4b55168b26090b52@xs4all.nl>
X-Sender: stokcons@xs4all.nl (rNj89yb3j7SHdDOiatU0g3wG2KTcKrtD)
User-Agent: XS4ALL Webmail
X-Virus-Scanned: by XS4ALL Virus Scanner
Archived-At: http://mailarchive.ietf.org/arch/msg/roll/ohER5Qvbz2oTYMqOJlcFxHhR0z0
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: consultancy@vanderstok.org, 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:24:35 -0000
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] 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