Gather ideas about configuration

[marco-tiloca-sics]

Migrated from https://gitlab.com/crimson84/draft-tiloca-core-observe-responses-multicast/-/issues/3

Original content and comments below

================================================

This falls in two categories:

• How would the server know for which requests it pays to multicast them?
  • Just see which observations are on and learn from them?
  • Use an external tool, which would either
    • use an extension of https://gitlab.com/crimson84/draft-tiloca-core-observe-responses-multicast/-/issues/2 to put in active observations, or
    • just start the observation like the first client would, and maybe even end it the same way?
      • (If the server only accepts to-multicast observations established by that tool, how does the tool authenticate? By being a particular member of the OSCORE group?)
• How would the client know which multicast address to join?
  • By looking at something https://gitlab.com/crimson84/draft-tiloca-core-observe-responses-multicast/-/issues/2 -ish? Would be unwieldy.
  • Could that derive from the network parameters, possibly the cache-key options as input to a hash? (Eg. such that for GET coap://[address]/path, the multicast group in the network 2001:db8:: would become ff35:30:2001:db8::XXYY where XXYY is a portion of hash(address, path))
  • Could a client say something about its ability to choose any multicast address in the request?

---

Much of this hinges on the address selection. Do we have anything on how link- and site-wide multicast addresses are selected by applications at all?

(All I know so far are special-purpose IANA-managed addresses, and that ff35:30:2001:db8::XXYY source-specific-multicast of which I don't even know whether they're actually used.)