Minutes interim-2020-core-09: Thu 16:00
minutes-interim-2020-core-09-202009241600-00

# CoRE Virtual interim - 2020-09-24 - 14:00 UTC

Chairs:

* Marco Tiloca, RISE
* Jaime Jiménez, Ericsson

## Remote instructions

material: https://datatracker.ietf.org/meeting/interim-2020-core-09/session/core
webex: https://ietf.webex.com/ietf/j.php?MTID=m77b4ee5ef9869f87a24a3aa57f2c30f5
jabber: core@jabber.ietf.org
codimd: https://codimd.ietf.org/notes-ietf-interim-2020-core-09-core

Minute takers: Rikard Höglund, Marco (helping)
Jabber scribes: Marco

## Participants

1. Marco Tiloca, RISE
2. Francesca Palombini, Ericsson
3. Peter Yee, AKAYLA
4. Alan Soloway, Qualcomm
5. Carsten Bormann, Universität Bremen TZI
6. Rikard Höglund, RISE
7. Göran Selander, Ericsson
9. Bill Silverajan, Tampere University
9. Christian Amsüss
10. Michael Richardson, Sandelman Software Works Inc

*[MT]: Marco Tiloca
*[JJ]: Jaime Jiménez
*[JS]: Jim Schaad
*[FP]: Francesca Palombini
*[CB]: Carsten Bormann
*[CA]: Christian Amsüss
*[KH]: Klaus Hartke
*[RH]: Rikard Höglund
*[TF]: Thomas Fossati
*[DN]: David Navarro
*[GS]: Göran Selander
*[BS]: Bilhanan Silverajan
*[AS]: Alan Soloway

## Agenda

### Note Well

Remember that the [note well](https://datatracker.ietf.org/submit/note-well/)
applies, for [IPR](https://tools.ietf.org/html/bcp79) but also for [WG
processes](https://tools.ietf.org/html/bcp25) and [code of
conduct](https://tools.ietf.org/html/bcp54). Try to be nice.

### CoRE Resource Directory

  - Wrap-up on processing of IESG comments
  - https://tools.ietf.org/html/draft-ietf-core-resource-directory

MT: Is it correct that we do not have any updates to check?
CA: I have a lot of action items but no progress for today.
MT: Okay, we can take it to the next interim; that means more time for the
Dynlink document today.

### Dynlink [Bill, Alan]

  - Discuss status, open points and way forward
  - https://tools.ietf.org/html/draft-ietf-core-dynlink

  Presented slides at:
  https://www.ietf.org/proceedings/interim-2020-core-09/slides/slides-interim-2020-core-09-sessa-dynlink-status-update-00.pdf

  Recent pull request from Alan (discussed below):
  https://github.com/core-wg/dynlink/pull/20

BS: I have to confess we have not progressed that much either but we want to
take benefit of the interim since it was scheduled.

BS: Not that many updates from IETF 108 but I will give summary of next steps.
We are currently in draft -11 which was submitted just before the 108 meeting.
What we had then was a roadmap where we started changing the language to talk
about state transfers. We will also take time to address issues discovered with
pmax (particularly when the CoAP server and client are separated by a proxy),
and updates for epmin and epmax.

BS: The idea was to convene small research groups before IETF 109. Please let
us know if you want an invitation to join. I have not gotten any new
participants from IETF 108 so we are that same group.

BS: Ongoing discussions are notifications from setting observe attributes. The
current language is not very RESTful but sounds like a new protocol. There are
substantial editorial changes to do to update this language. Bringing it more
to how it's done in the observe RFC.

BS: For the last slide we want to support epmin and epmax which is a proposal
from OMA LWM2M. Alan has augmented this with example use cases. Basically epmin
and epmax differ in a significant way from pmin and pmax. The discussion about
this can be found on the core-wg dynlink github repo issue #18 at 
https://github.com/core-wg/dynlink/issues/18  . It started on the CoRE mailing
list and Alan raised this in the Gihub and some have contributed with opinions.
The latest status is some text to consider from Alan.

AS: It needs to be clear to the reader of the document what these new
attributes are and how to use them. So I started creating a PR to put the
changes to the draft I felt applicable. I wrote example text but wasn't sure
how we wanted to create the content so I put it in the issue instead of a PR.

AS: In the latest LWM2M spec attributes are translated. We created some we felt
important for LWM2M which are epmin, epmax and some others. I want to talk
about how I propose to modify Dynlink. Epmin & epmax are supposed to control
when a device takes a measurement. Edge indicates if the change was on the
rising or falling edge. A control parameter for confirmable notifications was
also added (can be used for important notifications). We also have a historical
queue depth to indicate the depth of history saved on the server. The ones I
started to put in into Dynlink were epmin and epmax, but we should consider the
other ones too.

CB: How do you get at this historical queue? Ok, so essentially send a piece of
SenML with particular values.

AS: Hopefully this will evolve or change based upon deployments.
After all the discussions we decided I should put in a PR. The new parameters
are really control parameters/attributes, controlling when measurements occurr.
The PR is now at: https://github.com/core-wg/dynlink/pull/20

AS: Example, going through the Github issue #18 at
https://github.com/core-wg/dynlink/issues/18  : Let's say we have a temperature
sensor. We want it to report no more than every 5 sec, meaning setting pmin at
5, and at least every 60 sec meaning setting pmax at 60. This means the device
can sleep for at least 5 seconds and maximum 60 seconds (since those are the
limits for reporting). But I don't think this is the wanted behaviour from the
client's point of view but nothing guides the device. To control how frequently
this measured there are 2 new parameters (epmin & epmax).

MR: Why did it set pmax to 60 if it wants to hear every 10 seconds?
AS: You still have to abide by the reporting criteria. I will not report if the
temperature has not changed but I will report it even if it has not changed
after 60 seconds. MR: It sounds like pmax is misnamed. AS: I'm using it as
currently defined. Even though my evaluation criteria may not change I will
still report, that is what pmax is for. MR: It sounds like you are introducing
a similar sounds attribute where the original one was poorly named. That is why
the need for the new parameters is not obvious. Some renaming may be helpful.
AS: I'm open for any changes. Just because pmax is 60 does not mean I am fine
with the client going to sleep 60 seconds at a time.

AS: (Continuing example.) epmin says you can do a measurement at the end of
this, and epmax says you must do a measurement at the end of this. The device
can decide based on epmin and epmax how it sleeps and wakes up.

BS: Do you have a guidance if epmin and epmax are not set?
AS: Then it's the same situation as now.
BS: In other words without epmin and epmax, what's logical is using pmin as
sleep interval? AS: Not neccessarily since there's nothing that says that. Now
it just says I must report at pmax. There is no guidance for the device's sleep
interval. We could say that pmin may be used to guide the device. But I don't
think we can enforce that. BS: In the current draft there's some code there on
what to do.

AS: Let's go to the PR. I will show the proposed changes. The first concept is
that they are not notification but control attributes. They have nothing to do
with generating the notification but rather when a notification should be
generated. They divide the cadence of measurement on what triggers
notifications. It allows controlling how often a server performs a measurement.
They configure the internal server-driven sampling process.

BS: Does pmax fit into the conditional control attributes? If so we should
change the wording. I wonder if the current language is accurate if we bring
pmax as a conditional control attribute. AS: True and pmin is also a
conditional control attribute. I agree.

AS: epmin controls the minimum period between measurements. It must wait this
long but does not have to perform a measurement when it expires. Similarly
epmax is the server time a server may wait between two consecutive
measurements. You must wait for epmin and _could_ do a measurement, but after
epmax the server _must_ perform a measurement. epmin must be greater than
epmax. I have not included the example text, but it may be valuable. AS: So
this is my PR, where do we want to go?

BS: Most of the text seems ok. It looks sensible. But if epmin is not set,
there was something we should consider. If pmin is set but epmin is not set we
could write that the server can use pmin. AS: I can edit the PR, should I? BS:
Yeah, sure. AS: (Adding to the PR). The server may use pmin if defined as a
guidance on the desired measurement cadence. BS: Is there anything in the
implementation considerations section? There was discussion there on the
internal sample period. That part needs to be considered as well. We should
rephrase things here like "internal sample period". AS: (Changing the text) BS:
Seems okay now. We just need to make sure things do not clash. AS: I considered
making a PR for edge and historical queue parameters. But I wanted to start
with epmin & epmax and then make separate future PRs. BS: That's reasonable.

CA: I'm happy with the attributes related to the sampling and not the resource
state, good they are separate. Some changes may be needed in the language on
how the parameter are transported. The control attributes can be used for
operations with side effects. AS: In reality in an observe request all control
and notification attributes can be included. CA: Parameters may affect other
observations on a resource. AS: If you have an existing observation and set a
new one. Is it separate or same? CA: Separate AS: Correct, so the parameters
are only applied to that observation. CA: But the history attribute affects the
whole resource. It affects how a later observation would see the state of the
resource. AS: You are talking about epmin and epmax? CA: Epmin, epmax and
history. AS: I'm trying to separate conditional notification and conditional
control attributes. Their scope is only on a particular observation, it's an
atomic thing. The device must take all notifications and all epmin & epmax
values to decide its wakeup cadence. But it must abide by epmin & epmax for
individual observations. Even if I measure one temperature every second, I have
to obey the limits for other observations which can be different. CA: What
about conflicts? Two observations on the same attribute. AS: It can never
violate the parameters. Regardless of other observations. We're talking about
cadence of measurement. One client says measure every 1 second, another every
10 second. Can I report on observation 1 at same time as 2? We have nothing
specified, it's implementation dependent. CA: I'm thinking about intermediaries
that understand the protocol. I may take some time to process the implications
further. AS: Do we want to provide guidance that the values are recommendations
to enable the server to maximize its power savings/wakeup cadence? AS: Does it
work to separate the attributes into 2 separate tables (notification versus
control)? CB: I was thinking of 2 clients. One has epmin and epmax at 7, and
another epmin and epmax at 13. How powerful are these values to be obeyed? AS:
Is the server invalidated from providing a notification to both at 7 seconds? I
think the client should be able to see that it's up either way so why not
generate a notification. If the device is able to do a measurement, then it
should evaluate the notification criteria. CB: What language do we need to
allow this? AS: Perhaps put it in the evaluation criteria? CA: Do we need to
phrase it as a minimum and maximum? Having a minimum assumes the device is
actively polling. AS: The way it started for me was having guidance on when to
wakeup (all there was, was waking up at least pmax). But that is not good, some
guidance was needed. I created my own scheduler. CA: How does epmin play into
the scheduler? AS: I use it as one element of an optional wakeup. I create list
of mandatory wakeup and add the optional too. Then the device can consider when
to wake up (if it gets enough power saving). Remember the observations are not
aligned, the T0s differ. CA: If epmin was always 0 would it make things a lot
worse? AS: Not for the implementation but for the client to receive a
notification. Or rather the utility is for the server to have a better
scheduler. With epmin 5 and epmax 10 the server has 5 seconds to decide within
for its scheduler. AS: Shall I change the text for the implementation
considerations now? CB: The implementation considerations have to consider the
semantics, so let's define the semantics first. CB: If you want to define the
implementation considerations first do that and make sure the other parts of
the text actually allow that. AS: (Changing the text). Changes may be needed
for the MUST in the epmin text. Changing to SHOULD may be better. Then I can
violate it when I decide to. CB: For SHOULD we must spell out the exceptions.
So I prefer "is encouraged" if it's a weak request. BS: We should have
correlation to epmax since it's a must there. AS: For epmax it is a MUST. CA: I
have trouble coming up with how a client would use this. The client has nothing
to put as epmin. Is not this value something the server can decide on its own?
Since it's more for its own scheduling. AS: It is but the server does not know
the preference of the client. If I know there is flexibility on the server I
can say wake up at least every 5 minutes but you may wake up every minute. I
know my server device and its capabilites. CA: It sounds like a general
configuration parameter, not exactly specific to an observation. AS: I may want
to say you must send it every minute but the server may wake up every 10
seconds if it wants to. CB: It's more like advice from the client that it does
not need information more often than a certain interval. "The client indicates
that it has no use for this being evaluated more often." AS: (Changing the text
live) BS: Text now is good but we can shorten it. BS: Regarding epmin & epmax,
and Carsten's example. If both epmin and epmax are defined epmax must be
greater than epmin. But is it > or >= ? AS: I always though it to be >. We can
consider how things are done for pmin and pmax. BS: Don't split things into
sections for now. I have editorial changes. CA: If my understanding of epmin
and epmax is correct, the mental exercise to do is: if 2 observations on the
same resource are coming in via a proxy aware of these attributes. Can it come
up with values to create just a single observation? I'd like to think offline.
CB: The intermediary is typically not aware of the server's internal
considerations. CA: But it could be a proxy set up explicitly for this server
so it would be aware. CB: This point from Christian on proxies needs more
consideration. AS: Okay, I am changing the PR. CB: I did a PR to fix the
tables. BS: I will try to merge these new PR(s).

MT: You are planning PRs for 3 additional parameters?
AS: I am not sure. I may create separate issues for each. But I don't know if
people would agree with adding them. BS: It would be useful since they are 3
different attributes. AS: Okay, I will do so.

MT: There is an outstanding open issue #17 on Github about proxy and caching
considerations. BS: Yes I will look at it. I think we resolved it. It was about
pmax? MT: Yes, I think so from discussions at side meetings. AS: Please
consider if we should include my example in the draft. MT: I think it would
help a lot, also with ASCII art figures.

MT: We have 3 more interims to go, so we can come back to this topic if need
be. Otherwise at IETF 109 for sure.

### AOB

CB: The Coreconf shepherd stuff is moving forward.
MT: Thanks, now you should also have all responses from the IPR call, right?
CB: Yes.