Minutes interim-2018-lpwan-12: Wed 17:00

Meeting Minutes IPv6 over Low Power Wide-Area Networks (lpwan) WG
Title Minutes interim-2018-lpwan-12: Wed 17:00
State Active
Other versions plain text
Last updated 2018-10-03

Meeting Minutes

   Connection details

*    Date: October 3rd 2018
*    Time: 8-9AM DST, 17:00 CEST:
*    Webex Link:
*    Meeting number: 203 710 782 *    Meeting password: JM3Y2Kqf *    To join
by phone or other means, please go to the Webex Link for details.


*    [17:05] Administrivia                                           [ 5min]
    o    Note-Well, Scribes, Agenda Bashing
    o    Status of drafts

*    [17:10] SCHC Updates since last Interim - Dominique             [15min]
*    [17:25] Open discussion on Fragmentation                        [25min]
*    [17:40] SCHC Minimal (Alexander).                               [10min]
*    [18:00] AOB                                                     [ 0min]

Minute takers

*    Ana Minaburo
*    Dominique Barthel Orange
*    Carles Gomez
*    Arunprabhu Kandasamy
*    Ivaylo Petrov


* Ana Minaburo
* Laurent Toutain
* Pascal Thubert
* Alexander Pelov
* Carles Gomez
* Dominique Barthel
* Juan Carlos Zuniga
* Edgard Ramos
* Ivaylo Petrov
* Arunprabhu Kandasamy

Past Attendees

Action Items from last time
* Chairs: find reviewers for drafts


*    [17:05] Administrivia                                           [ 5min]
    o    Note-Well, Scribes, Agenda Bashing
    o    Status of drafts
    o    No objection: minutes of last interim are adopted.
    o    No request for the agenda
    o    Pascal: LoRa Alliance is developing its own fragmentation algorithm.
    Doubts expressed that ours works for them o    LoRa meeting on Oct 10th. We
    need to let them know Ack-on-Error works. o    The LoRa fragmentation is at
    app layer, for Firmware update. Our frag is wider-use and works well.
         To publish before 10th. [Laurent] email from Nicolas Sornin convinced
         with ACK-on-Error would help to solve changing MTU.
    o    DB: request that frag works with variable L2 PDU size?
    o    Laurent: believe we can make SCHC F/R work with variable L2 PDU size.

*    [17:10] SCHC Updates since last Interim - Dominique             [15min]
* Changes available at the github
* merge request from Arun. clean up on state-machine of ack-always.
* SCHC F/R MIC option - created ticket #32
* temporary conculsion-  no need to change the text in the draft. please read,
comment. 2 supports received from JCZ, Pascal. * State machines normative or
not? consensus to be in appendix, non-normative. only the text is normative. *
2 questions from Arun. one question throws light on assuming l2word that is
smaller than upper layer word length,(1 byte). new assumption (l2word < the
upperlayer_word size) would be written to the draft. * still single padding is
efficient. * design session last week with authors, chairs. * reached agreement
on mechanism on ack-on-error; Laurent's version was abstract, JCZ is more
detailed. Both drawingx express another view of the same thing. * W field is
multiple bit length and doesn't roll over. opens up new degrees of freedom, can
send ack later to previous windows. * 3  supports expressed on the mailing
list. * request to define the notion of profile from Pascal. Ana expressed a
different opinion. * [Alex]: SCHC context--> profile? is it same ?
different? * [DB]: yes(different), we might have several releases of context
for different technologies, for devices with different capabilities. It is more
than renaming a single context. * Pascal: profile is more abstract, containing
the feature set. devices have different rules that may have same profile. *
Laurent: not really interested in this discussion just before the cutoff date
of the draft.

* Pascal: This might be needed for the technology specific drafts, so maybe
here it's a good place to put it. * Edgar: First time hear about profile for
SCHC. Related to context provisioning. * Alex: is there more in a profile than
a list of Rules? * Pascal: yes, definitely. E.g., for Ack-on-Error frag, when
are ACKs sent and expected by the receiver. * Pascal: Profile desribes
variations in the protocol, that don't reflect in the Rules themselves.
Technology is part of the profile identification, but is not the complete thing
as variations (when do you send the acks for example) could be changed
independently. * Alex: shall be put this(profile info) on the side of the
context? * Laurent: prefer to do this discussion about profile outside the
document and priority to submit before 10th. * Charlie's answers to be
processed. ACkalways, ACKonError to be written, JCZ already provided state
machine drawings of ackOnError. * Dominique: no change in ACKalways. NoACk mode
reviewed by the authors. ACkalways still empty but no changes expected but
fitting with the new document structure and better describing protocol as
sender behaviour / receiver behaviour (as suggested JCZ). * Edgar: ackalways
still retains 1bit W (binary)?. Pascal: yes , since we ack on every window. *
Dominique: W field only defined in Section 8, more precisely at the section
8.2.3 (the definition of the tools in our SCHC F/R toolbox). * Dominique:
ACK-Always is defined in 8.4.2, and will say it uses the W field with a width
of 1 bit. * Deadlines shortened a bit, 22nd --> 10th. * Alex: do we have any
big things to discuss on ACkonError; Carlos: nope, Dominique: writing base
mechanism, significant work remaining. Lora alliance might expect schc over
lorawan document. * Edgar: Will have meeting with Nbiot people, will come back
if there is any feedback from them.
     * JCZ: see no big deal with the new protocol, he is happy with the work

*    [17:25] Open discussion on Fragmentation                        [25min]

*    [17:40] SCHC Minimal (Alexander).                               [10min]

* Alex: Chair hat off - how do we do the bootstrap
How do we ensure interoperability? Maybe different techonologies. How do they
learn their capabilities? Maybe they just need to know each other in advance,
or they much know sufficiently about each other in advance, so that they can
bootstrap. Or a default configuration * No default config, means the context
need to be config in different means * We can have: In band or out band

* JCZ: No default you say is always out of band - why?
*AP: No default and SCHC Minimal are they the same?
*JCZ: No default is not SCHC minimal
* AP: No default means there is are no default rules that you can use to
provide in-band the context. * JCZ: There are 3 options: default ones,
out-of-band and ?? * AP: SCHC Minimal can be implemented in every technology
that can be seen as the default (world-wide default) * AP: A second level: with
a very simple defautl with the technologies defining more complex rules * AP:
with the default we can enable bootstrap, with interoperability among
technologies * AP: Each of them has advantages and disadvantages - disadvantage
could be that we might be mandating things that are not really useful in the
end. Maybe some techonlogies will not need a fragremtation technic and we have
mandated it, so it will be a waste of bits/bytes.

 * ER: This SCHC minimal is related to the profile, because we implement what
 we need
    * ER: could define a Minimal profile. Device manufactures can decide to
    implement it or not. So you dont force every device to implement -minimal.
*AP: How we know what the device supports? DO a global rule showing what do you
have, can help to interop *ER: How the device can config another profile it
wants to use?, how to distribute the profiles? *PT: Profiles need to be
standardize, to be known. To signal that by the name of profile or something
*AP: So we can also do it with the Rule, Rule 1 is going to give this profile
*DB: assigning Rule IDs for "default" Rules eats into the freedom of present
and future technologies to number Rules as they like. *AP: We can define a
number of bits but to define the same for the same profile *PT: more concerned
about provisioning the back-end than the device.

*    [18:10] AOB                                                     [ 0min]