Dear CORE-WG, We just adopted in ANIMA draft-ietf-anima-constrained-graps, and as i tried to outline in the adoption email, one of the probably main tasks is to figure out if/how to best leverage/use/extend CoAP for this work:
https://mailarchive.ietf.org/arch/msg/anima/3uOJU3Wcd_NNjPZRFpLKuHekyLg As that writeup hopefully outlines, there is no conclusion as to which way to go, but adoption is primarily meant as a way to confirm this is a problem ANIMA-WG wants to solve, and depending on how successful that turns out to be, the contribution(s) will be appropriately updateded and/or contributed to the right group. Also appended feedback we already received from Carsten on the matter, leading to this outcome. So, i was wondering if/how we could best get that understanding from CORE-WG, and i would be happy to have the discussion in a CORE-WG meeting (IETF123 or interim) if/how appropriate - before attempting write unfitting contributions. So : if there is time, i would like to ask for a slot @IETF123 CORE-WG to get feedback from CORE-WG to the following questions: 1. COAP defines a reliable datagram layer with retransmitt and (lightweight) CC, but does not expose it as a separate protocol. Yet, that reliable datagram layer of CoAP is likely the most widely deployed and hence tested reliable datagram mechanism for constrained networks. GRASP has so far only been defined on top of TCP for relability and CC. A version for constrained network is desired because ANIMA also targets them. ANIMA being in OPS, it alwys tried to eat as much pre-existing IETF dog food as beneficial. Hence it would be likely technically the most easy option trying to extract the reliable datagram layer from CoAP and run GRASP on top of it. So, what does CORE-WG think about this option, and if it was done, is such spec for CORE-type reliable datagram something CORE-WG would want to adopt, and/or reject if it was done in a different WG ? 2. GRASP could "simply" try to be written as an "application" to CoAP, but that likely would bring some undesirable overhead and inadequacies. Instead, GRASP could be specified as a combination of additional CoAP messages (which should be specified in CORE ?) and then a specification how to use them for constrained GRASP. For the below described functionality, would CORE-WG consider it appropriate to have specification of new CoAP messages ? - negotiation: transactions consisting of a sequence of multiple reliable message exchanges (as opposed to request/reply transaction style which - if i am not mistaken - applies to all currently specified CoAP message types. various use-cases, one for example is that you want to update several objects (in routers change different configs), but only if all changes will succeed, else none of the changes would be applied. - multicast:flood/discovery: network wide reliable multicast mechanism in GRASP relying only on per-hop reliable message exchange, eliminating the complexity/need of underlying network-wide unreliable datagram multicast (IP multicast or MPL for example) and end-to-end reliable multicast transport (aka: no RMT protocol needed). Even if both of these functionalities could be done as "applications" of CoAP, maybe there is an interest to do them at the message level so that other CoAP applications could also leverage them, without necessarily having to use all of GRASP (which e.g.: has its own rather simple application name space of "objectives" as opposed to URLs in CoAP). 3. there may be other, smaller question to resolve putting GRASP on top of CoAP Cheers Toerless On Sun, May 11, 2025 at 06:20:34PM +0200, Carsten Bormann wrote: > > > These are reasonable points. > > CoAP has congestion control, retransmissions, block-mode,... which are all > > the things that TCP was doing for us. Re-inventing that would be silly. > > So either all CoAP, or no-CoAP. > > > >> 2.2 However, i very much would like to re-use the CoAP "messaging model", > >> aka: > >> how messages over UDP are made reliable and in a limited fashion > >> flow-controlled. > > Here we are. > > I would assume that whatever “mini-CoAP” you start to design will grow > features over time until it is indistinguishable from CoAP, except just > different, looking like a bad example of NIH in the end. > > (From my IRTF perspective: When we designed CoAP, we didn’t have CBOR or CDDL > available to us, so I think it would be an interesting research project to > invent a CoAPng (next generation) that does use CBOR and CDDL. > I’m just not so sure that this is what ANIMA wants to do.) > > I would expect that building a cGRASP around CoAP would have a little more > design freedom than your garden-variety CoAP application. > E.g., using a different port number might work around BCP190 (so no need to > have /.well-known/coap-grasp in every message). > > The examples in Section 5 all use non-confirmable messages and then seem to > hobble together confirmable messages and separate responses by adding options. > Maybe the CoAP mechanisms are better for this; they have certainly received > more design attention than what is sketched in Section 3. > > In any case, this is a non-trivial design effort, and it seems to me this is > still a bit remote from a clear direction that the WG wants to work under, so > I think this is the time for formative contributions as opposed to already > adopting one (or, essentially, two) of them. > > Grüße, Carsten > -- --- [email protected] _______________________________________________ Anima mailing list -- [email protected] To unsubscribe send an email to [email protected]
