Skip to main content

Minutes interim-2017-lpwan-04: Wed 16:00
minutes-interim-2017-lpwan-04-201706071600-00

Meeting Minutes IPv6 over Low Power Wide-Area Networks (lpwan) WG
Title Minutes interim-2017-lpwan-04: Wed 16:00
State Active
Other versions plain text
Last updated 2017-06-07

minutes-interim-2017-lpwan-04-201706071600-00
Connection details
------------------

*       Date: 7-8am US Pacific, 4pm CEST:
http://www.worldtimebuddy.com/?qm=1&lid=100,12,5392171,1850147&h=100&date=2017-06-07&sln=14-15
*       Webex Link:
https://cisco.webex.com/ciscosales/j.php?MTID=me7f536292c568c696a054a7ff7ef0746
*       Meeting number (access code): 203 453 401 *       Meeting password:
chicalors
    o 24422567 from phones

Agenda
------

*       [7:05]Administrivia                                             [ 5min]
    o   Note-Well, Scribes, Agenda Bashing
    o   Approval minutes from last meeting
    o   Review last interim todos
    o   Terminology

*       [7:10] LPWAN Overview  (Steve)                                  [ 5min]
*       [7:15] SCHC Fragmentation (Carles)                              [15min]
*       [7:30] SCHC IP/UDP Compression (Laurent, Ana)                   [15min]
*       [7:45] SCHC CoAP (Laurent)                                      [ 5min]
*       [7:50] New items (Ana)                                          [10min]
*       [8:00] AOB                                                      [ 0min]

Minute takers
-------------

*    Ana minaburo
*    Arunprabhu Kandasamy
*    Pascal Thubert
*    Alexander Pelov
*    Dominique Barthel

Attendees
---------
Pascal Thubert
Samian Kaur
Alexander Pelov
Ana Minaburo
Arunprabhu Kandasamy
Alexander Pelov
Carles Gomez
Diego Dujovne
Bob Heile
Tomas Lagos
Tomas Bolckmans (no audio!)
Erika (no audio!)
Dominique Barthel
Laurent Toutain
Juan Carlos Zuniga

Past Attendees (previous meeting, for cc)
---------
*    Stephen Farrell
*    Ana minaburo
*    Laurent Toutain
*    Alex Pelov
*    Julien Catalano
*    Sumankumar Panchal
*    Tomas Bolckmans
*    Carsten Bormann
*    Hannes Tschofenig
*    Carles Gomez
*    Diego Dujovne
*    Juan-Carlos Zuniga
*    Paul Duffy
*    A Paventhan
*    Friedhelm Rodermund
*    Arunprabhu Kandasamy
*    Pascal Thubert
*    Samian Kaur
*    Uday Davuluru

Minutes
------

*       [7:05]Administrivia                                             [10min]
    o   Note-Well, Scribes, Agenda Bashing

The Etherpad doesn’t work. We’re using Google Doc as sent the link to
https://docs.google.com/document/d/1_FZCtq0qRgkbcaqYc6E6xrnozMCoCAyXW_172RVPQHw/edit

Milestone, we are behind schedule, we need to go forward to be on time.
Let’s try to work hard for CoAP compression

    o   Approval minutes from last meeting

    o   Review last interim todos
-Reviews, and feedback for CoAP (CB and MV) we need more input,
- Simplification of the fragmentation part of SCHC draft

    o   Terminology

*       [7:15] LPWAN Overview  (Steve)                                  [ 5min]

SF thinks things are fixed, could we go for a LC?
The LC will be sent into the ML


*       [7:20] SCHC Fragmentation (Carles)                              [15min]
Updates since last version of the document
After some discussions and results, the idea is that packet mode has been
extracted from the SCHC document We keep 3 modes: No ACK, Window Mode Ack
always  and Window Mode on error More than one type of Window size: e.g. big
window (for big packets) & small window (for small packets) AP: some are
commented on ML. no negative feedback. Can DD  make review for the
fragmentation part?
      - Tools as New section:different components that enable fragmentation
      functionality. - Need rule id to identify fragment,  ACK, aborting the
      transmission. -    Dont’ see any outstanding big issues at the moment. -
      PT: Consuming of Rule-IDs, is this a concern? -    Rule-ID for ACK and
      one for Abort, so the number of Rule-IDs is big, may they be together?
     -    CG: Abort may have Rule-Id for specific datagram, may be used for
     large datagram
        Fine grain functionality Vs consumption of more rule ids?
PT: How many Rule-IDs we have? A realistic number could be good.
CG: Something with an specific technology and leave this document with an open
number AP: simple devices, abort may abort everything
        Could be problem when 2 packets fragmented parallel, aborting one
        sender can finish one flow and abort the other ongoing transmission.
        LPWAN, expect sender to finish one and go for another. AP: keep it
        simple.
AM: Future works to decide the size of the rule ID.
AP: One rule ID for abort all, if future demands, add the rule id that
specifies which datagram is aborted. PT: Published the draft as it is,
        AM: only one comment left. If agree, we can publish the next version.
PT: Start the Last call in two weeks for this doc (schc
compression/fragmentation)?

*       [7:35] SCHC IP/UDP Compression (Laurent, Ana)                   [15min]
        AM: comments from JCZ: one point to discuss: IID for ipv6 address.
        Confusion about the naming ? Better to keep the ipv6 terminology even
        if this ID is created by MAC, Ipv4, whatever.. JCZ: on section 5,
        talking about action. Section about ipv6. Action may be generic
        dependent on the technologies. Rfc7217, also talks about IID. AM:
        doesn’t matter if  the IID is derived from MAC or elsewhere. Just to
        represent the IID of the ipv6 address. JCZ: Right now in the document
        there is only one way to do it, which is confusing device ID and
        Interface Id. Agree with LT AP: Continue the exchange over the Mailing
        List. Ana to look again and propose addition to the document. AM: do we
        join both security, from fragmentation and compression? AP: keep it as
        one part. To be general security concerns. JCZ: subsections would be
        good? AM: Subsections about security problem? JCZ: depends on the
        security problem and its specifics. PT: As you introduce a new code on
        the road of the packets, you may add bugs.. For example variable length
        fields could provoke buffer over-flows, so we could add a sentence on
        “normal coding practice”, such as - make sure you have enough buffer
        space, make sure to check boundaries, etc. This is new code - do add
        checks AM: SCHC draft points overview draft as informational ? PT:
        Normally you never do a “normative down-reference”. A Standard Track
        document should not reference an Experimental or Informational
        document. If you put reference to the meanings and the terms, and the
        architectures - and reference them from the Informational Document -
        then it’s not clean. Doable, but not clean. PT: Ideally: Add a new
        section / in the introduction - position the architecture, and make
        sure to define all the terms. (and add non-normative reference to LPWAN
        Overview doc) JCZ: is it not allowed to reference an informational
        document? PT: ?? JCZ: Not sure there is a problem.. Could you send the
        RFC that describes the down-referencing ? JCZ: If it is not an action,
        but a term (and not use SHALL / MUST), then it should be OK ? PT: If it
        is not too much text, prefer to include it in the document. AP: send
        email to AD. suresh JCZ: agree if it makes the document self contained.

*       [7:50] SCHC CoAP (Laurent)                                      [ 5min]
        AM: need reviewers specially for the security section.
        Sent email to core emailing list to address the security section.
        In case if other people to review, step forward. Havent’ pushed carsten
        or michel for review. LT: testing out comi, works well! But the draft
        doesn’t look good grammatically. AP: can be fixed easily. LT: need
        implementers for the comments.

*       [7:58] New items (Ana)                                          [10min]
        AM: Next steps - ICMP draft received attention.
        LT: LPWAN-over-FOO
        JCZ: SCHC-over-FOO.
        AP: SCHC-over-SIGFOX ? SCHC-over-LoRaWAN ?
        JCZ: It makes sense as a complement to the SCHC document to have a
        SCHC-over-FOO. PT: How do you provision the rules? What are the flows?
        JCZ: there are several ways of doing it. Not against the way to do it.
        The data model is the same anyways AP: having yang data model doesn’t
        limit to using comi, opens up for other tools.


*       [8:00] AOB                                                      [ 0min]