Minutes IETF110: core: Fri 13:00
minutes-110-core-202103121300-01

Meeting Minutes Constrained RESTful Environments (core) WG
Title Minutes IETF110: core: Fri 13:00
State Active
Other versions plain text
Last updated 2021-03-13

Meeting Minutes
minutes-110-core-202103121300

# IETF 110 - Constrained RESTful Environments (CoRE) WG

Chairs (core-chairs@ietf.org):

* Jaime Jiménez (jaime at iki dot fi)
* Marco Tiloca (marco dot tiloca at ri dot se)

Stand-in Chair for IETF 110:

* Carsten Bormann (cabo at tzi dot org)

# Friday, March 12, 2021

Number of participants: 12:10 ( 32 ); 12:50 ( 36 ); 13:30 ( 30 )

Meeting material: https://datatracker.ietf.org/meeting/110/session/core

Etherpad: https://codimd.ietf.org/notes-ietf-110-core?both

Meetecho video stream:
https://meetings.conf.meetecho.com/ietf110/?group=core&short=&item=2

Audio stream: http://mp3.conf.meetecho.com/ietf110/core/2.m3u

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

Jabber scribe: Marco Tiloca

**12:00 - 14:00 UTC**

Numbers in parentheses are minutes of time allocated.

## Intro, agenda (Chairs) (5)

MT: Carsten standing in as chair for Jaime

## CORECONF Comi (Carsten) (15) <1205>

* draft-ietf-core-comi-11

   - New open points from the shepherd review

CB: 4 CORECONF documents, of which 2 in last call, i.e. core-sid and
core-yang-cbor, while 2 waiting for shepherd review (from Carsten), i.e. Comi
and Yang-library.

CB: For Core-sid Ban Kaduk commented that this document wants to create a new
global naming system. That is the intention and we want views from security
community on this.

CB: For Comi issues came up. One in netmod about incompatibility between uint8
and int8. Do we need to rely on this? Is it really needed to encode uint8 and
int8 in two different ways? Other open points: string may not be URL-safe, the
definition of "CBOR key", and key vs. CBORencode(key).

CB: Further issues are text about block-wise transfers (can be changed to
mention briefly only). Also further details on instructions for pagination of
/.well-known/core. How can this be done? When can the SHOULD be violated (why
is it not a MUST, what are the conditions)? This is a general problem in YANG.
We may want to wait for YANG to solve this.

CB: Some NITS. Current text is not clear about leading zeros in base64 encoding
of SID numbers. SID 0 should be "A" and not the empty string.

CB: Plan is to have a new version of Comi with these things addressed. We need
one more round, for instance to be careful not to create the backwards
incompatibility between uint8 and int8.

MT (from chat): Christian and Ivaylo agree on the /.well-known/core point.

IP: We could consider changing the encoding. Should not be an issue for
implementations. I am interested in other implementations that are deployed
where this would be an issue.

CB: Do we have to do another WG last call if we change the table (of data
encoding)?

MT: Leaning for a not needed, we'll see, it would be the third WG Last Call if
one thinks of the CORECONF cluster as a whole.

## SenML Versions (Carsten) (10) <1220>

* draft-ietf-core-senml-versions-02

   - Check status before WGLC

CB: draft-ietf-core-senml-versions-02 submitted addressing comments from Jaime
(for instance approach to bitmapping a number). Ari added to his SenML
validator the bit for additional units. This is ready to go for me.

MT: Discussed in November meeting we wanted comments, got from Jaime now. Next
is starting WG last call. We will start that.

## SenML Data CT  (Carsten) (10) <1230>

* draft-ietf-core-senml-data-ct-03

   - Comments following WGLC and next steps

CB: draft-ietf-core-senml-data-ct-03 updated with editorial clarifications and
decompression bomb security consideration. Document has normative reference to
draft-bormann-core-media-content-type-format, seems that document will take a
while, based on the Monday discussion in DISPATCH. Proposal is to remove that
normative reference, and include in this document the minimal set of things
needed from the one above.

MT: I think this is a good thing to do. Does Francesca have input?

FP: Seems most straightforward, I want more discussion in DISPATCH. We should
try if we can figure out things, otherwise remove it as normative.

AK: Can we do it in parallell?

CB: Yes.

MT: So next step is making a PR on the senml-data-ct document to gain time and
be ready to take the new direction (*action on Carsten).

## New Block (Med/Jon) (15) <1240>

* draft-ietf-core-new-block-07

   - Discuss updates following WGLC; ready to move on?

JS: Christian Amsüss provided comments. Updates to latest version: CSM Option
was removed. Emphasized disadvantage of mixing NON/CON in same
request/response. Clarity over different MAX_PAYLOADS. Naming is Q-Block1 and
Q-Block2. Emphasis on non-confirmable support. Require use of confirmable when
testing Q-Block. Clarified mixing Q-Blockx and Blockx with OSCORE. Also
clarified use of the M bit in requests.

JS: Request-Tag was removed, congestion control was defined with new variables,
examples were updated, security considerations updated to include OSCORE and
updated references to CBOR RFCs.

JS: Implementation is based on libcoap, PR has been submitted. Has been tested
in DOTS environment and behaving as expected. We believe all issues have been
considered and handled. We request publication of the document.

CA: I am largely happy with the changes. It fits the scope it sets out. Not
enthusiastic about some mechanisms, but should work fine for what it wants to
do. Thank you for addressing my comments.

MT: The last updates better clarifies the intended scope. Agree it can be
seminal material for a blockwise bis document. Next step is shepherding (Marco
can take it). Will start a final review next week (not expecting big comments),
then start the write-up.

## Dynlink (Bill) (15) <1255>

* draft-ietf-core-dynlink-13

   - Discuss status and next steps

BS: Current version is at 13, continuing incorporating feedback. Dynlink was
also discussed during a Core interim meeting.

BS: Separated Conditional Attributes into Conditional Notification Attributes
and Conditional Control Attributes. Separate table for each now. Edge attribute
and confirmable notificatiom attribute was added in last version. The "edge"
attribute indicates wanting notifications on falling or rising edge of boolean
resource state. The "con" attribute indicates if a notification should be
confirmable or either NON/CON.

BS: Currently we have "band" and "con" defined as parameters with boolean type
value. Do we need to harmonize so that "band" and "con" have an actual value
(in key, value format)?

MK: I would be fine if we made it explicit requiring key, value pair. But there
may be reasons not to do that.

CB: I checked RFC7252, it says the argument is often in key, value pair. So
query parameters without "=" sign is fine. For parameters without "=" sign you
have presence and absence. So you can either express a parameter or that you
have nothing to say. Seems it fits with the "con" attribute (not setting means
no preference, setting means preference).

AS: Presence indicates desired behaviour. We did not want to spend extra bytes
("=" + 1 character) since it did not add value. I assume "band" is same logic
(as "con").

BS: We have 3 boolean attributes, the last being "edge", where it is
significant if it's 0 or 1.

MK: I think for "band" you always have a preference. You will get notifications
based on how it is set. It is very much like "edge". "con", in my
implementation experience, it is useful to specify. It can work better to avoid
the extra messages (using NON). I have seen value in being able to set it as
false.

AS: In LWM2M we created a resource covering the default meaning you don't need
to send if using default. Default is NON, certain cases make it CON.

MK: This is for LWM2M, not clear if "can" in our spec can be just
presence/absence. Not being able to set false may limit some uses.

AK (on Jabber): LwM2M use of parameters:
http://www.openmobilealliance.org/release/LightweightM2M/V1_2-20201110-A/HTML-Version/OMA-TS-LightweightM2M_Core-V1_2-20201110-A.html#Table-512-2-lessNOTIFICATIONgreater-class-Attributes

AS: I agree, if you have no default state you want each independent observation
to be able to set full characteristics, due to not having a default. As Carsten
says, there are 3 states, 0, 1 or absent.

MK: I was thinking 2 states. If you don't include "band" that is now considered
as equal to false. For "con" we have historically said the system can choose.

CA: Doing "con" as more of a hint seems like the correct thing, also
considering proxies. Making this a hard rule seems excessive. I would phrase
this as a recommendation. Would it make sense to distinguish which attributes
are useable for which methods (eg. edge makes sense for POST but not for PUT
and observation).

BS: For instance how will pmax/pmin combine with "edge"? We need more work to
understand this.

AK (on Jabber): We need at least 0/1 since LWM2M uses that.
Alan supports that.

BS: Changes done and planned. pmin == pmax is now allowed (implementation
considerations covers this more). Considering impact from proxies, should
include more examples, in section 3.3 Michael contributed code for server
processing of Conditional Attributes.

CB: Recent discussion on second part of draft?

BS: Not much recently.

MK: Dynamic link concept can be used independent of link attribute. We may want
to split things further.

BS: So when we split it the link part gets link name, and other part gets other
name. So we need to update other documents considering this.

MK: Parameters close to being RFC, needs more work on link part.

CA: I agree it makes sense to split this. (As much as I regret losing the
chance to let the document's drive push the bindings part that I care about.)

BS: Looks like group is in favor of splitting it.

CB: So we agree to keep dynlink document with the link material, and split out
the other part.

MT: What about considerations for proxies? Like usage of with pmax. I think
this can be coverd in a future interim meeting.

BS: Yes, it boils down to plans of interactions (end-to-end or hop-by-hop.) We
were looking at hop-by-hop approach, but if we need to look at it considering
proxies sitting in the middle we have to consider its impact.

## RD extensions and protocol negotiations (Christian) (15) <1310>

* draft-amsuess-core-resource-directory-extensions-05

* draft-amsuess-core-transport-indication-00

   - Discuss status and current directions, plus new document

CA: RD extensions are about what you can do with the RD without changing the
spec. Most important here is reverse proxy extension. Can ask resource
directory to provide you with a proxying service (publically reachable name),
thus becoming a reverse proxy for you. It is being used in practic a lot, most
of LWM2M uses a similar mechanism. The reverse proxy has been used in the
hackathon for simplified testing.

CB (on Jabber): Can the RD partner with a proxy?

CA: In part, since the RD has to contact an endpoint on the Internet to
establish the addresses in the first place and open up the firewall state. The
RD could use a separate proxy but the endpoint would need to open up the
endpoint to that proxy. Doing it in the RD seems a practical thing.

CA: We end up with a property that is better to avoid in the general web. It
can be avoided if devices use RD only as proxy. Similar problem in protocol
negotiation case, coap+tcp:// and coap:// both collapse onto same resource.

CA: Proxy discovery started in transport-indication-00. A server announces
using link-relations that it has a proxy at a location. Everything hosted on
this host is reachable via a specific proxy. No URI aliasing in the application
(only on the wire when has-unique-proxy is set).

CB: I wonder if the /res line is in addition to a resource?

CA: That is just another resource advertised on the server. You discover this
(resource and proxy information).

CB: It could also say anchor="/res".

CA: Yes but then it would only apply to this resource. Employing this
indirection allows one statement for everything hosted on that server.

CA: Next steps are to gather feedback, tuning relationships, and update the RD
extensions to show how it can be used. Reverse proxy in RD may not go away,
some applications may not care about URI aliasing. But in other cases we do
care. Do I want reverse or forward proxy can be distinguished.

MT: The idea would be to build on transport indication document in the RD
extensions?

CA: Yes. Last point is that in the -00 it outlines security considerations
(some can be taken from the HTTP working group.)

MK (on Jabber): NAT => URIT.
MK: Meant jokingly. We are building a URI translating gateway rather than a NAT
translating gateway.

## A Data-centric Deployment Option for CoAP (Cenk) (10) <1325>

* draft-gundogan-core-icncoap-00

   - Present new work

CG: Can draw parallells between ICN and CoAP deployments. Shared this with ICN
community earlier. ICN allows not specifying a server endpoint, focused on
content delivery. Two prominent architectures are NDN and CCNx. Features are
name-based stateful forwarding, content caching, object security.

CG: Object security provides end-to-end protection (this also applies to cached
content). Parallells to CoAP between NDN and CCNx. Request-response paradigm.
All hops on the path creates state, state is consumed when response traverses
back. Can prevent traffic amplification (DDOS). Caching is hop-wise.

CG: One benefit is retransmission can originate from any intermediate entity in
the path, which reduces link traversals. Content object security has been
deployed.

CG: There is paper from 2020 about bulding a CoAP deployment similar to an ICN
deployment using only standard CoAP features. For the standard deployment
retransmissions are end-to end. In the data-centric each hop is also a cache
(provides hop-wise caching and retransmissions). Forwarding decisions based on
names. Between proxies we used link-local IPv6 which helped saving bytes due to
6LoWPAN compression.

CG: Most ICN systems support multiparty communication (mostly using request
aggregation and response fan-out, or request fan-out and response
deduplication.) We are working on providing more results focusing on the
multi-party communication.

CG: The take-away is we were able to show this kind of deployment reduces
latency and improves resilience. Location indedepent of content mobility,
efficient multi-party communication and gave new perspectives on CoAP
deployment. Future work is dynamic proxy discovery.

CB: What about interest routing? How would it work in a network mostly looking
like a CoAP network?

CG: Slide 8 shows a CoAP deployment. Forwarding is on proxy-level (it knows for
each GET for a URI where to forward the message.) For now we have hardcoded
parameters, future work is dynamic parameters.

CB: How could the RD aid this process?

CG: For discovery we thought about using the RD.

CA: It's more about local discovery of links than using the RD. I can see the
RD serving as announcement point for routes. If for a particular host there is
a particular good next-hop proxy this can be discovered from the RD.

CG: It's an unconventional way of deploying CoAP using proxy all the way. Is
this still a good home for this kind of work?

MT: I think it's worth exploring. It's not out of scope.

CB: Adding OSCORE can be interesting.

CG: We did add OSCORE, and used the cacheable OSCORE draft
https://datatracker.ietf.org/doc/draft-amsuess-core-cachable-oscore/. It worked
quite good. Saw improvement of success rates in lossy network.

MT: May be easy to build a relation with the multi-party case. There are
building blocks for this too as work in progress in CoRE.

AK (on Jabber): Can also be brought to the attention of T2TRG.

CB: Can we come up with experiment that broadens the base?

CG: This deployment works well with safe or idempotent requests. The same
request giving the same content. Firmware updates is a good potential use case.

CB: We have a whole working group for this, i.e. SUIT. They are looking mostly
at security. But many of them do firmware updates. Can be good basis for
further experiment. Not using OSCORE there but their SUIT approach. Can be
interesting to propose getting the update from the closest location, rather
than always from a certain update server.

CG: More comments are welcome on the mailing list.

## Flextime (25) <1335>

MT: Will resume interim meetings from April 28, on Wednesdays. 6 meetings
planned before IETF 111.

CB: Can you give an overview or guess of what the interims will be about?

MT: No agenda yet. I can imagine Dynlink, cachable OSCORE and groupcomm-bis, as
a tentative list.

CB: Can be good to have an agenda for the first interim. We can discuss this on
the mailing list.

***Meeting closed at 13:36 UTC***

---

*[MT]: Marco Tiloca
*[JJ]: Jaime Jiménez
*[GS]: Göran Selander
*[JM]: John Mattsson
*[FP]: Francesca Palombini
*[CG]: Cenk Gündogan
*[CB]: Carsten Bormann
*[CA]: Christian Amsüss
*[KH]: Klaus Hartke
*[BS]: Bill Silverajan
*[NW]: Niklas Widell
*[IP]: Ivaylo Petrov
*[MR]: Michael Richardson
*[BL]: Barry Leiba
*[AK]: Ari Keränen
*[JS]: Jon Shallow
*[MB]: Mohamed Boucadair
*[AS]: Alan Soloway
*[BL]: Barry Leiba
*[MG]: Matthew Gillmore
*[ED]: Esko Dijk
*[HB]: Henk Birkholz
*[MG]: Matthew Gillmore
*[DN]: David Navarro
*[CG]: Carles Gomez
*[MK]: Markku Kojo
*[HT]: Hannes Tschofenig
*[BK]: Benjamin Kaduk
*[AM]: Alexey Melnikov
*[RH]: Rikard Höglund