# IETF 108 - 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) # TUESDAY, July 28, 2020 Participants: 14:17 - 54, 15.20 - 52, 15:40 - 46 Etherpad: https://codimd.ietf.org/notes-ietf-108-core Minute takers: Niklas Widell, Ivaylo Petrov Jabber scribe: Francesca **14:10 - 15:50 UTC** Numbers in parentheses are minutes of time allocated. ## Intro (10) Jaime Jiménez (JJ): Welcome to Core WG, chair together with Marco. Note well, introduction, rules of engagement, going through agenda. JJ: Agenda bashing? Christian Amsüss (CA): Let's move ERT as first, since that's referred by other. JJ: Use queue request on Meetecho, try not to interrupt. * WG and document status * Published: * senml-more-units-06: RFC 8798 !! * senml-etch-07: RFC 8790 !! JJ: Congratulations to authors. More units already used in OMA. * IESG Processing: * draft-ietf-core-resource-directory-25: IESG Evaluation * draft-ietf-core-stateless-06: IESG Evaluation::Revised I-D Needed. JJ: A few comments remaining, Klaus is processing them. * In Post-WGLC processing: * draft-ietf-core-dev-urn-07: AD Evaluation::Revised I-D Needed JJ: Done. There was some discussion on having it Informational or Standards Track. Barry confirmed Standards Track is fine and already gave comments. Now new draft needed. * draft-ietf-core-echo-request-tag-10: On Shepherd's Writeup JJ: Marco to writeup. * draft-ietf-core-oscore-groupcomm-09: WGLC comments to be processed JJ: WGLC finished last week, now comments to process. * In WGLC: * draft-ietf-core-comi-10 * draft-ietf-core-sid-14 * draft-ietf-core-yang-cbor-13 * draft-ietf-core-yang-library-02 JJ: WGLC ends on July 29th (tomorrow). Please add any comments you could have before Friday ## Resource Directory (Christian) (5) * draft-ietf-core-resource-directory-25 - Overview latest updates - above probably w echo, right (comments) CA: - Major change on security policies (how -> what, rule ->options). Suggest use of echo for amplification mitigation and client identity in simple registration - Minor clarifications and editorial changes JJ: have had few interims, some about authorization and use of RD. Didn't come up with anything that could be applied to RD today. Will continue with current state and ship it. CA: There are some discussion for auth with RD, but they are outside the scope of the current specification. JJ: AIF later today. ## Echo-Request-Tag (Christian) (5) * draft-ietf-core-echo-request-tag-10 - Overview latest updates CA: Draft has not been presented for a year. Has passed WGLC. - echo for amplification mitigation - updates 7252 for the amplification mitigation - Echo: allow shorter values - Echo Proxies may process echo, should avoid deteriorate freshness - Request-Tag: don't solve all problems with stateless proxy blockwise problems - Better structured introduction, added privacy & security considerations - Suggest concrete numbers to IANA - Waiting for shepherd's writeup for more comments to process Marco Tiloca (MT): no comment from shepherd, the write up will be written up next week, then request for publication. ## CoRE Applications (Klaus) (10) * draft-ietf-core-problem-details-01 (10) --- Klaus - Present updates and discuss open points - KH: Draft that provides payload format for coap based apis - editorial: rebuilding doc, focus on expressing error details using CoRAL (instead of having it as exploration in appendix). Leave out things that are not sure to resolve. - GH repo with issues (https://github.com/core-wg/core-problem-details/issues), will work on those in the following revisions (not included in this version). - Extensions for special use cases. - Base: small set of common fields (error type, error description, human-readable details). - Feature: extensions per use case (tracing, log pipeline, 3rd party error reporting). - Everyone: feel free to join repo (https://github.com/core-wg/core-problem-details). - In -01 version, CoRAL all the way. Naming protocol elements is exciting. CoRAL has way to define new vocabulary, e.g, use URIs-as-identifiers as is done in the semantic web. -00 had custom scheme for new identifiers. - Identifiers should be compact, low barrier to entry (people should not need to register elements in an IANA registry - too complicated for normal applications), stability, private-public transitions, popularity /familiarity to REST API developers - why not use current way as was proposed - minor disadvantages that make them suboptimal - Survey: started looking in Singapore at different approaches to ID schemes. Naming things in a distributed way is one of the two hard problems in computer science. Examples include IANA registries, LwM2M, Bluetooth, ISBN etc. This remains a work in progress, hope to find a creative way that works well for Problem Types (and CoRAL in general). Please speak up if you have ideas! - CB: A new idea being tested is to use Github repo with IANA registration. Do PRs to add to registry. - KH. On our radar, but might be too much to ask. If developers have to register every error type, even throuh Github repo that might be too much to ask - CA: There should be some kind of hierarchical part of this, should be some kind of namespacing. E.g., able to set base URIs. - KH: What happens when registrant goes away? Please contribute. - JS: Started playing with this, need to look at privacy and security, how applications report errors. - KH: Anything specific beyond what is in the "Problem Details for HTTP APIs" RFC (RFC 7807)? - Jim: Did you expect me to read that draft? - KH: We can take it to the list. - JJ: Thanks for the presentation. ## Dynlink (Bill, Michael, Klaus, Jaime) (10) * draft-ietf-core-dynlink-11 (10) --- Bill - Updates and way forward. - Bill Silverajan (BS): Very short update on Dynlink, currently v -11. - Substantial changes, primarily restructuring and reformulating aspects. - From -08 --- -11, have been able to incorporate feedback. - From -10 --- -11, small changes. Small group of people has been working on small set of features. - 1. Editorial: current draft observed notifications reporting values, should instead reflect notifications as restful state change. - 2. The behaviour of pmax: pmax impacted when there are proxies. Working consensus to let pmax influence server's Max-Age. - 3. Proposal from Alan/OMA: to support two attributes (epmin, epmax) (min/max evaluation period) already used by LwM2M. Discussion in Github issue #18. - Carsten Bormann (CB): I'm not so interested in the new parameters. Are there IPR disclosures that we would need to look at? - BS: Yes, Qualcomm has declared. - CB: Before epmin/epmax? - BS: IPR raised against current draft, which do not contain them. - CB: need to keep in mind in the future discussion. - JJ: Maybe we should not discuss the IPR now. Topic is very interesting. - BS: ?? - Ari Keränen (AK): Given that LwM2M is the biggest user of dynlink today, it would make sense to have them in the spec. - Barry Leiba (BL): Clarification on the discussion on IPR issue. Not appropriate to discuss if the IPR itself applies, but it is proper to discuss the impact of the IPR on progress of the specification. - JJ: Should split the conversation, focus on pmax for the moment. - CA: I have an issue with the binding site? - BS: there is the thing about binding links ... - Dynlin next steps: v -12 will reflect editorial changes to reflect state transfers. Plan to continue discussion in small discussion group, please ping Bill if you want to be invited. Meetings over Jitsi. - JJ: Fine to send Jitsi inviation to the list to have a biger audience and involvement. Also, this will be material for the next series of interim meetings planned for after summer. ## SenML Documents (Carsten, Ari) (20) * draft-ietf-core-senml-versions-00 (10) --- Carsten - Status and open points - CB: We have talked about SenML versions before, will do quick recap. - SenML defines version number, it does not define how it is used. - Objective is extensibility, sometimes using extension points, sometimes other ways. Version is unitary declaration, stating that given features are needed in order to process a given Pack. - Version numbers are stupid, not always best ways to handle the problem. Has been discussed in many places. Have a mechanims to define required features (must-understand fields), however it becomes less useful as that list for a given Pack grows. - Ari proposed using a bit array to compactly describe features. - 53bits in JSON integers? Evil number? There are currently 48 left, can limit the way the bits are allocated. Not sure how many are needed - That was the background, defines a feature system, specification required. - Updates RFC 8428, now a WG draft. - Used by senml-more-units (FC 4 = more units). - Ready for WGLC, but would be good to have some reviews. - Request for folks that can do review (Bill, Jaime Jimenez) - JJ: Also read the draft. Thought on deprecation of features, how often will it happen? - CB: Hard to say and predict. - JJ: Any implications if things are deprecated? - CB: The good thing is that you simply will not need to use the features that are deprecated. - JJ: Bill and Jaime will review the document. * draft-ietf-core-senml-data-ct-02 (10) --- Carsten - Present updates and discuss open points - CB: can have binary data in SenML record, the idea is to introduce Content-Format indication so it can be interpreted correctly. - -02 is different from -01, removed ct_ which created problem with must-understand, so removed until a way to use is found. - CA: Good riddance. - CB: Ready for WGLC. - JJ: Reviewers needed? - CB: Minor change, not needed. - JJ: Will issue a 2-week WGLC. ## Blockwise for DOTS (Jon, Mohamed) (15) * draft-bosh-core-new-block-04 (15) --- Jon - Present the draft, status checkpoint, check for adoption - Jon Shallow (JSW): DOTS creates challenges where there are DDoS attacks, needs mitigation. - Talking about large body packets, problem in lossy environments. Two solutions, Block3 & Block4 (I thought one solution, but Block1 and Block2 are replaced by Block3 and Block4 ...). - Sample target development (see RFC 8782). - DOTS inferred CoAP requirement - need to transfer body w multiple payloads - handle packet loss - cannot rely on getting responses - want to keep CoAP way of working with this - BLOCK3 has BLOCK1 characteristics - can send packet without waiting for response, people can increase NSTART in order to allow more packets to be in the pipe - introduces congestion control to avoid DDoS, set MAX_PAYLOAD to 10, ... - Example shown - BLOCK4 has BLOCK2 characteristics. - GET and FETCH with BLOCK4 trigger BLOCK4 response provided that the response is big enough. - Example shown - Draft discussed at two interims, have incorporated comments. - Request adoption as a WG document. - CA: Sorry for not sending review. Still missing out where this should go, either bespoke solution to blockwise not being able to do everything, or a generic solution. Needs clarification on that. Can then start with layering violations, etc - JS: Direction is that in addition to. If someone in the chain does not understand new options, then go back to old. - CB: Good solution, few nits to be worked as WG doc. Supports adoption. Need to ensure that all CoAP components are actually used correctly. Good for implementers what the result will be. Also need work on applicability statement. - Mohamed Boucadair (MB): The document does say that it is not a generic solution. - JJ: For all those who participated to the interim meetings, tend to be supportive of adoption. Let's HUM. HUM Result PIANO (some interest). Enough to adopt as WG document. Please share the objectives etc. More comments? Authors will have to send a new version, can you work with github? - MB: There is already a version on GH, can move that. - CB: Chairs setting up repos is a great service! Take also this on the mailing list. - JJ: Thanks Jon and Mohamed for the patience to progress the draft. The decision to be validated on the ML. - Action item: start call for adoption; CA to send review. ## AIF (Carsten) (10) * draft-bormann-core-ace-aif-09 (10) --- Carsten - Present updates and way forward - CB: Pretty weird name, was originally both CoRE and ACE. Picked up by ACE, but also interesting for CoRE. - Access control and authorization. Access control matrix, map subject and object to a set of permissions. Commonly sliced into a ACL (Access Control List) - This draft slices by capabilities (c-list). No protection of capabilities, draft concerned with access authorization list - Represent C-list as array of pairs. Speced for RESTful case, but can be specified for other cases (e.g. MQTT). Objects are paths. Permissions - simple bits. A bit coarse, but good for most applications. - Good for describing static resources, but iot devices often have action resources, leads to dynamic action resources. Instead, derive permissions from the base resources. Done by doubling the bits. That way a person might not be able to delete the base resource, but do actions on its children (?). Deleting an action stops it for example. - Status: it has been around since 2014, came out of DCAF and was in the ACE BOF at IETF 89. ACE is looking at WG adoption, is there anywhere else where this can be used? On ACE agenda for tomorrow, will conclude result from adoption call. - Ben Kaduk asked if there is anything else like this. Most web services have more complicated needs, so AIF is probably too simple. On the other hand, when done, this might be used elsewhere, so we should not block such uses. - JJ: The AIF pattern is very similar to IPSO (CRUD instead of REST). - CB: Worth writing up for CRUD so a new set of registration bits is not needed every time. - JJ: intent to add additional protocols in LwM2M, everything there maps to CRUD. - CA: Is there room still for expanding this, e.g., to apply dynamic permissions? - CB: that would be a significant extension. - CA: Would not go in the same document (dynamic resources). - CA: There are lots of bits available. - JS: A difference between things I did create, and the ones I could have created. Also time aspect, e.g., pub-sub-topic, time might run out on the Access Token with the permissions, before one would want the topic to go away. Is it the same subject coming back again to act on the same child resources it created before? - CB: Management of subject identities is an interesting topic. Yes, the Access Token can be time-limited. Then the client gets a new Access Token with a new temporary identity. This seems more about managing identities than authentication. We can discuss tomorrow at the ACE meeting. - JS: On the agenda, but needs slides. - JJ: Any other questions/thoughts? ## Flextime (15) - MT: opportunity to pull in a document that would be presented on Friday. * draft-palombini-core-oscore-edhoc-00 (10) --- Francesca - Present the new work - Ask for reviews - Francesca Palombini (FP) - Combining EDHOC and OSCORE. - Started in IETF 106, brought to CORE since EDHOC is now in LAKE. Idea is to reduce number of roundtrips to run EDHOC. LAKE is scoped to produce one lightweight AKE. Document is an optimization, combine EDHOC and OSCORE sequentially. - Question, can the three 3 RT exhcange be optimized? Yes, we can merge EDHOC verification and OSCORE request. - How to send two messages together? - Send EDHOC in OSCORE or vice versa - Figures shown - How to signal which alternative is used? - 1. EDHOC in OSCORE - - Define new CoAP option - Define new CoAP option indicating that message is both EDHOC and OSCORE - Start with EDHOC, then do OSCORE - 2. EDHOC in OSCORE - Use the OSCORE option - Use the OSCORE flag byte to tell that payload contains both - 3. OSCORE in EDHOC - by the number of elements - Define new CoAP option indicating that message is both EDHOC and OSCORE - 4. OSCORE in EDHOC - by the number of elements - Signal with new content format. - CB: EDHOC message size? Delimited? - FP: Message size around 20 bytes. CBOR encoded, so known where it ends. - CB: I prefer alternative 2. - FP: Option 2 would save the most bytes, not using specific option and specific URI Path. - Göran Selander (GS): How does it work with FETCH? - FP: The ciphertext contains the method and the URI. - CA: Strongly in favour of first options, for 1 & 2 it is plain response to what is in the payload. Suggest to put EDHOC in an option, only if EDHOC message is short so that it fits. - FP: Not sure if option size is enough. - Ivaylo Petrov (IP) (on chat): +1 for option 2. - FP: Way forward is to get feedback and incorporate, signals preference for option. - JJ: Who will review? - Action item: Christian, Carsten and Jim to review. - FP: Jim brought up using multipart-core, has the same problem as Christian brought up. - FP: Please send comments, Klaus or Carsten please inform on length of options. JJ: This concludes the session, thanks for joining, remember ACE tomorrow! See you on Friday. Σ 100