Re: [Roll] DRAFT minutes from IETF90 meeting

Thomas Watteyne <watteyne@eecs.berkeley.edu> Thu, 24 July 2014 15:02 UTC

Return-Path: <twatteyne@gmail.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 C72171A03D6 for <roll@ietfa.amsl.com>; Thu, 24 Jul 2014 08:02:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.224
X-Spam-Level: **
X-Spam-Status: No, score=2.224 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-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 bTrGA9sK7d4Y for <roll@ietfa.amsl.com>; Thu, 24 Jul 2014 08:02:39 -0700 (PDT)
Received: from mail-pd0-x232.google.com (mail-pd0-x232.google.com [IPv6:2607:f8b0:400e:c02::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A04AB1A03F7 for <roll@ietf.org>; Thu, 24 Jul 2014 08:01:53 -0700 (PDT)
Received: by mail-pd0-f178.google.com with SMTP id w10so3786666pde.23 for <roll@ietf.org>; Thu, 24 Jul 2014 08:01:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:content-type; bh=ZAsCg+53bNBF/ytDmMSdMhNA942O9jJXA4Uou2ZfKzc=; b=UxXuUqxEBOkNce3prsYAxTSMNCBYeo6F3KRl6tlQOEgQmeIZ7pGIjdg3YUGX9ipgm3 8LN4hkOPJMB8rmmPom4oFQqj47C0xHZCql3WfFvwtEJPOytF5hAm3k+gjLB6rIo1qxjZ 3R8OVk9bPrbhXT3f/g0cIKG9wxG2Dipv+1ot54C61yp33P48tznr/ubOAeDZ/YQWLiS+ OBh6y926Bcs6+e2petkMgyq6kTSF4l0MTPcnVucX6H5pI1AjMNWrZUuxb2an+pBPu4Tj +7A+ihma12e0A10J1cWu+D+AHQyqLxXA8Jx6WR+unRVQynddOcmAroHPPB1OGbd7A8kt eQaw==
X-Received: by 10.68.68.133 with SMTP id w5mr3277410pbt.166.1406214113175; Thu, 24 Jul 2014 08:01:53 -0700 (PDT)
MIME-Version: 1.0
Sender: twatteyne@gmail.com
Received: by 10.66.144.1 with HTTP; Thu, 24 Jul 2014 08:01:32 -0700 (PDT)
In-Reply-To: <13664.1406213156@sandelman.ca>
References: <13664.1406213156@sandelman.ca>
From: Thomas Watteyne <watteyne@eecs.berkeley.edu>
Date: Thu, 24 Jul 2014 11:01:32 -0400
X-Google-Sender-Auth: K_JJx_qSrEgdyaY_L9NN6IPavRg
Message-ID: <CADJ9OA9tNZYLjmHNneYQbM0qVo09wnRXAo58AkQT1sGZQpTPiw@mail.gmail.com>
To: Routing Over Low power and Lossy networks <roll@ietf.org>
Content-Type: multipart/alternative; boundary="001a11c3e352b1af9104fef1bc60"
Archived-At: http://mailarchive.ietf.org/arch/msg/roll/ernYsi0oB2V-zoA7sZb49GfCxAg
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:02:43 -0000

Michael,
These are the raw notes at the end of the meeting. "poipoi" is just a
placeholder.
Thomas


On Thu, Jul 24, 2014 at 10:45 AM, Michael Richardson <mcr+ietf@sandelman.ca>
wrote:

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