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
>