Carsten:
Thanks for the insight , some comments and Q.. All the coap(related) RFCs still leave open the question what, if any, option there is to zero-touch discover (and ideally set up) discovery in mesh networks, or for that matter any other L3 networks with lets say two or more router hops. > https://www.rfc-editor.org/rfc/rfc9176.html#section-4.1.1 This RDAO in RAs is an efficient way to announce an RD address that is not on the same subnet, but unless i know of any network profile that introduces an automated mechanism to configure this, i will contend, that - like IMHO all other RA parameters - this needs to be "manually configured" (which means at best you need to write some proprietary SDN provisioning system to configure it). I am also not sure i find the need to announce the RD address from a router the most easy to deploy when the original CoAP design should actually allow to deploy it as pure application and not router code. E.g.: If i had a bunch of VMs in one or across multiple Cloud-DCs, i would have some good trouble with setting up announcement and discovery via router RDs, but no problem of using subnet "standard" CoAP discovery via FF02::FD (and just CoAP(+security)/UDP unicast/multicast sockets from application layer code as opposed to "where the heck is the application layer API" RA packets. Q: To what extent is it, or is it not possible to announce "third-party" service information, including RD addresses just via "normal" Coap Discovery responses ? If thats possible, then i could much more easily figure out a distributed CoAP application infra that just needs to have an agent on every subnet that would do proxy-announcements. Especially given how we're having to build such an agent anyhow (join-proxy). There is some notion of proxying in the CoAP RFCs, but its rather evasive to me. But if i for example put my DNS server with SRP onto my registrar system (or equally a CoAP RD), then i can use simple hop-by-hop proxying of the service-discovery for those services (DNS or CoAP-RD). Given how simple proxying will often give me stale information (simple expiring mechanism), i would need to use anycast for the service address, which is a bit of implementation pain, but thats not network-wide, but only on those instances that would run the services (registrar(s))... Cheers Toerless On Thu, May 05, 2022 at 08:55:18PM +0200, Carsten Bormann wrote: > > > > If we had known that we'd spend 2 years in the RFC-editor Q waiting for > > DTLS1.3, then maybe we would have done the document differently. > > > >> Except that neither one works for L3 networks multicast IMHO (i am getting > >> no > >> response to that request i sent meaning at least nobody knows or cares), > >> and COAP > >> does not provide unicast discovery like DNS-SD from all i know. > > > > RD is a core part of RFC7252: > > https://www.rfc-editor.org/rfc/rfc7252.html#section-7 > > This section discusses both service discovery and resource discovery, which > employ Web Linking (e.g., with the Link-Format RFC 6690). > > (Be careful with the abbreviation RD, as that is usually taken to mean > resource directory, as in RFC 9176. RD is useful here on its own, but also > works with CoAP resource discovery, see > > https://www.rfc-editor.org/rfc/rfc9176.html#section-5.1 > > Together with > https://www.rfc-editor.org/rfc/rfc9176.html#section-4.1.1 > this is a viable alternative to relying on subnet-wide multicast to work > well.) > > > you can do it multicast or unicast, and RFC9148 does that. > > (It = CoAP Resource Discovery?) > > Grüße, Carsten -- --- [email protected] _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
