Re: [core] New draft-tiloca-core-groupcomm-proxy on proxied CoAP multicast operation

[Christian Amsüss <[e-mail]>]

Hello Esko, hello Marco,
hello CoRE,

thanks for tackling this.

I'm only skimming over it in a first round, but a few things have come
up:

* Multicast-Signaling: Is this a CBOR unsigned integer or a CoAP uint?

* Response-Forwarding: Is this expected to be extensible to any other
  CoAP transport that may come up that supports multicast? The use of
  CBOR tags seems to imply that, but then there's the question of how
  the client would arrive at a URI for follow-up unicast communication.

  Have you considered just using values that'd go into Uri-Host in a
  follow-up request?

* Why is the information about the client being behind a proxy
  forwarded? We don't to this in other proxying cases, and it just puts
  an additional burden on the origin server I don't see a compelling
  need for.

  From reading up to 5.3, I'd have expected that the proxy strip
  Multicast-Signaling when doing the actual multicast, and put back the
  Response-Forwarding option.

* At some point, as a WG we will need to think of whether we really want
  to have another option with Observe-like multiresponses; Block-wise
  and Observe being the two extensions so early everyone knew from
  RFC7252 they would come does put them into a special position.

  I do see the benefits of doing things this way -- it is way more
  efficient than anything I could think of that works across unaware
  proxies.

  If we see this as general enough to be one of the few ways to have
  longer-lived tokens, all is fine, and I am fine with that outcome, but
  would like to hear some WG discussion on whether we are as a group.
  In particular, that process should come up with some criterion of
  whether a mechanism is special enough to be another Observe.

  Otherwise, one option is to define a single one more generalized
  longlived-token mechanism that'd go along any option that starts an
  observationish process (and tells the proxy the eventual-consistency
  semantics of the request). Observe doesn't need that because it's been
  known all along, but if it weren't, it could be expressed in terms of
  that one option (plus its own option).

  If even that doesn't fly, the whole protocol would need to look very
  different (but I hope it won't come to that).

* The proxy needs to authenticate the client, that's a sane requirement.

  In a situation where I alerady deploy OSCORE for E2E, it would be
  convenient to use OSCORE to protect the leg to the proxy as well.

  OSCORE rules that out per specification, but to my understanding
  that's not for technical reasons, but primarily due to how to
  everything is phrased as protecting and unprotecting a complete
  message rather than accessing options before and after unprotection.

  This would make a convincing use case for nested OSCORE, so I'd
  suggest thinking about this. It may help to describe it in terms of
  sending a message to a forward proxy; option classes might change in
  the course of that. (In particular, Uri-Host and OSCORE become Class E
  for that purpose).

Best regards, and thanks for working on that document
Christian

-- 
I shouldn't have written all those tank programs.
  -- Kevin Flynn