Minutes interim-2017-lpwan-03: Wed 16:00
minutes-interim-2017-lpwan-03-201705241600-00

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

Meeting Minutes
minutes-interim-2017-lpwan-03-201705241600

   
Connection details
------------------

*    Date: 7-8am US Pacific, 4pm CEST:
http://www.worldtimebuddy.com/?qm=1&lid=100,12,5392171,1850147&h=100&date=2017-05-24&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                                             [ 7min]
    o    Note-Well, Scribes, Agenda Bashing
    o    Approval minutes from last meeting
    o    Review last interim todos
   o    Terminology

*    [7:12] LPWAN Overview  (Steve)                                  [ 5min]
    o    Status on Steve’s issues on ML
    o    Publication?

*    [7:17] SCHC IP/UDP Compression (Laurent, Ana)                   [10min]
*    [7:27] SCHC CoAP (Laurent)                                      [15min]
*    [7:42] SCHC Fragmentation (Carles)                              [15min]
*    [7:57] AOB                                                      [ 3min]

Action Items
------------

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

*    Ana minaburo
*    Arunprabhu Kandasamy
*    Pascal Thubert

Attendees
---------

*    Alex Pelov
*    Ana minaburo
*    Arunprabhu Kandasamy
*    Carles Gomez
*    Diego Dujovne
*    Juan-Carlos Zuniga
*    Laurent Toutain
*    Matt Gilmore
*    Rashid Sangi
*    Stephen Farrell

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                                             [ 7min]

    o    Note-Well, Scribes, Agenda Bashing

        * Ana asks for a few minues in the end to talk about future items

    o    Approval minutes from last meeting

        * Corrections or modification to the meeting minutes are aprouved

    o    Review last interim todos

        * JCZ reviewd the first half, frag outstanding.

        * Diego already started as well

        * Steven sent an update

        *  Missing Michel and Carsten review for CoAP draft

    o    Terminology

*    [7:12] LPWAN Overview  (Steve)                                  [ 5min]
 Steve: only issue seems to be AAA server. People are OK with LBES.
    AP: Back end server would mean lot of things to different people.
   Authentication Server is also in the LBES?
   PT: if we prefix it with LPWAN we can do what we want
   Do we only do authentication or authorization also?
   AP: Both are needed. BLES is what does it do?
   PT: still authenticationi and authorizatioin, considering roaming.
   SF: so just call it LP-AAA Server?
   JCZ: LP-AAA Server.. misleading as low power AAA server? Suggestion is
   LPWAN-AAA server AP: Any could works which represents what we are doing SF:
   to replace the terminology with LPWAN-AAA

   AP: Can we do last call next week?
   SF: yes, most of the things are ready
   AP: Steve to send when new version available.

    o    Status on Steve’s issues on ML

        * Stephen: only left issue is AAA server name. If people are OK can
        call it backend server

    o    Publications?

    * AP: Last call next week.

*    [7:17] SCHC IP/UDP Compression (Laurent, Ana)                   [10min]

    * Presenter : Ana

    * Important stuffs not clear , w.r.t. Diego's comments.

    * why we need order for the compression rules?. Can put it in any order,
    header format order.

    * Agree with the header format order ?

    * LT: Order is important

    * AP: IP/UDP headers fixed, CoaP has repeatable options.

    * Ana: Seems logical to have it in header format order.

     * Laurent: order is important for serialization

    * SCHC is protocol and fragmentation is mechanism, do we need to rewrite
    the introduction?

    PT: If there is an interaction between two devices, then you have a
    protocol. If there is any form of discussion, then it is a protocol. If you
    just compress stuff, then it is a mecanism. A CODEC is not a protocol.

    LT: Agrees. Compression is a mechanism, fragmentation is a protocol.

    * ANA: So we rewrite the terms in the draft.

    * LT: in ipv6 and udp , only one instance of field. but coap multiple
    instances so we need to make difference in the identifying the fiield. the
    position would help in this case.

    in future, when we add more options to ip header we might need it. Position
    is the relative position w.r.t the field

    * JCZ: It seems logical, but we'll need more explanation in the text - it's
    for extensions, not for UDP/UP.

    * JCZ: Do we mention that this is the generic approach, or do we jump
    directly to IP/UDP?

    * ANA: we jump into ipv6/udp

    * JCZ: Add small paragraph in the intro.

    * ANA: Target value can be described as any type. also consider a cbor.

    LT: field ID indicates the type of the target value(Can be int, string..).

    * we dont have to mandate the cbor type.

    * PT: If Diego had a question during the review, then other people may also
    get confused.

    * LT: just read what is written in the draft. may be wordings "consider"
    can be changed? to "for instance"

    * ANA: last point of review: equal is a matching operator., matching
    between rule target value and the incoming packet value.

    * Diego: I understand the idea. The field value in the rule is not the TV?
    (clarify the meaning of the sentence)

    * LT: correct version would be "Field value in the packet match the target
    value in the rule"

    * LT: also do it for ignore, and other MO.

    * JCZ: If newer version going to available soon, if so I would like to work
    on it.

    * ANA: Make the correrction of the Diego's comment and send to JCZ.

    * AP: next week we can have JCZ review.

    * PT: Better to have a new version published

    * JCZ: Agree. I would rather work on the published version.

    * PT: Ana, please publish the changes from Diego's comments. BTW, we also
    need to check what can be done for the fragmentation.

*    [7:27] SCHC CoAP (Laurent)                                      [15min]

    * LT: Used the last slides that were presented from IETF98

    * Refresh the ideas of CoAP draft

    * LT: Not the goal of schc to reduce the size of the IDs.

    Proxy reduces the value nd the SCHC mechanism can apply

    * LT: in coap , we have the list of values; URI PATH that can be repeated
    several times. to reduce ambiguity we introduce position.

    position is mandatory for all the fields.

     * Deal with variable length, we do not know the lenght of the value.Value
     can change and the size also, we need to send the new size of we reduce
     the type * The asymmetric in CoAP is important the request and the reponse
     are different. We have move this asymetric to the general rules of SCHC
     compression draft that can be used for Hop Limit. As UPL and DWL * JCZ:
     similar to Diego's comments. * Ana: Thisis an input to the SCHC
     compression part of previous draft to divided in framework and IP/UDP
     compression

    * PT: Who is going to prepare the rules. What is dependent on device? Most
    of the rules could be done by the manufacturer/vendor of the rules.

    * PT: certain things depend on the deployment. How to put in the way the
    direction,

    * LT: If I said a variable-length representation, then it's going to be
    limited to CoAP. (?)

     * PT: Rules are comming from the vendor and not for the device, but may
     come with the deployment, how to describe a rule with a variable part, a
     part that can be added later

    * LT: to be as generic as possible. What said by pascal is related to
    provisioning of the device. currently just focussing on the mechanism.

    * LT ?? about comi??

    *PT: ways to encode integer with unkown number of bits.

    *LT: coap way of representing length is very efficient.

      *AP: How to have flexibility, in the rule-ID on how we represent header
      information.

       * LT: we need it if we have ipatch. we may need it for oscoap as well..
       yet to explore.

       * AP: Continue discussion on the ML

       * LT: Revieuw the draft is important but the one important thing is that
       all the options are described on the draft, if you want we can use block
       and we can fragment it.

        *AP: CB said there are complementary mechanisms, so no contradictions.

    * LT: working on Comi, would update soon if it is working or not.

    *LT: discussion of timer on the coap draft. similar needs to be done in the
    lpwa networks as it would impact the way we do the compression.

    *AP: Take up the further discussion on the Mailing List.

*    [7:42] SCHC Fragmentation (Carles)                              [15min]

    PT: Question on the ML about the fragmentation, need for a stable draft.
    Split the draft in two parts. PT: make another draft with the possible
    improvements. AP: Stable part with the window mode, and can be shipped
    today(almost). Would like to retain it here and move the other part to
    newer draft.? PT: is this decision to retain the Window mode OK, Carles ?
    Diego? Diego: OK! seems practical to keep the window mode. LT: more generic
    is the window mode and could work everywhere. also retain the
    unidirectional too, the one with the last msg as MIC. LT: Keep also the
    unidirectional mode and the MIC AP: Keep Window moe and Unidirectinal and
    then we can work on the other modes PT: Unidirectional there is not
    ambiguity so we can keep them and then we can work on the other modes PT:
    What do you think, JCZ? JCZ: Afraid to move so fast, and have an
    misunderstanding, it makes sense but perhaps we need to things more in
    details. PT: Remove mechanisms where you loose packets you do not know
    where you are, (packet mode) and only leave what does not have ambiguity We
    need time to solve the problem of renumbering when retrying. AP: agrees
    with PT. Reminder about Deadlines with Schc ip/udp. Window mode doesn't
    seem to have a problem. would consider splitting the draft keeping the
    window mode. Other non-ambiguous things can also be added. Unclear stuffs
    can be worked on a separate documents.

    LT: Do we do an interop in Prague
    AP: Put this also in the ML,

*    [7:57] AOB                                                      [ 3min]

Chat room log
--------------

http://etherpad.tools.ietf.org:9000/p/lpwan?useMonospaceFont=true
from Pascal Thubert (Cisco) to everyone:
http://etherpad.tools.ietf.org:9000/p/lpwan?useMonospaceFont=true

from arunprabhu kandasamy (Guest) to everyone:
I would like to know if we can have an interop for schc at Prague

from Juan Carlos Zuniga (Guest) to everyone:
http://etherpad.tools.ietf.org:9000/p/lpwan

from Diego Dujovne (Guest) to everyone:
thanks!

from Stephen Farrell (Guest) to everyone:
"LP-AAA server"

from Matt Gillmore (Guest) to everyone:
I like LPWAN-AAA

from Juan Carlos Zuniga (Guest) to everyone:
L-AAA
fg

from Carles Gomez (Guest) to everyone:
I disagree about the ambiguity point... Look at my slide

from Carles Gomez (Guest) to everyone:
So, overall, I think Packet mode (without the recent suggestions) is stable as
well

from Carles Gomez (Guest) to everyone:
The main point here is the trade-off with message cost in window mode

from Carles Gomez (Guest) to everyone:
I'd say let each implementer decide

from laurent (Guest) to everyone:
The thing is that what will be defined in the main standard does not block an
evolution

from Carles Gomez (Guest) to everyone:
Large enough N means zero ambiguity :)