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