[core] Review of draft-bormann-core-responses-01

[Marco Tiloca <[e-mail]>]

Hi all,

Please find below some comments about this document.

Best,
/Marco

---------------------------------

[General]

* The reference [I-D.tiloca-core-observe-multicast-notifications] should 
be changed to [I-D.ietf-core-observe-multicast-notifications].


[Section 2]

* The first paragraph looks like an alternative and complementary 
definition to what is defined in Section 1.1. Perhaps the two can be 
merged together already in Section 1.1?

* "Where tokens are involved, all non-traditional responses use the 
request's token; in any case, they are bound to the original request"

    To cover all cases, it would help to expand the end of the sentence, 
e.g., "to the original transmitted or configured request".

* "by using the same request_kid/request_piv pair in OSCORE [RFC8613]"

    This may be expanded by mentioning the use of the triple 
request_kid/request_kid_context/request_piv in Group OSCORE.

* "Some established responses (observations defined in [RFC7641], and 
multicast responses in [I-D.ietf-core-groupcomm-bis]) match ..."

    I think you mean "and responses to multicast requests in 
[I-D.ietf-core-groupcomm-bis]) match ..." . Multicast responses are not 
part of that document and are rather used in 
-core-observe-multicast-notifications.


[Section 2.2]

* "One way to do that is to exchange a "phantom request", which is a 
request that client and server will agree to have sent and received, 
respectively, without it actually being sent between those endpoints."

    Basically, the "phantom request" referred here (and used in 
-core-observe-multicast-notifications) is an example of "configured 
request" as defined in this document. Correct? If so, it's worth mentioning.

    It is also consistent with the first paragraph of Section 4.2.

* "As tokens are managed by the client, that request needs to be 
generated by the client, or in close collaboration with the client (for 
example by the client allowing a third party to use a subset of its 
token values in order to set up non-traditional responses)."

    It's worth mentioning how this happens in 
core-observe-multicast-notifications, i.e., in that case there is no 
third party. As potential group observers, the clients entrust the 
server to manage the Token space used for phantom requests generated by 
that server, against which multicast notifications will match.


[Section 3]

* "The option "Response-For" contains a request packaged as in Section 
5.3 of [RFC8613]."

    I suppose that, unlike in RFC 8613, the request packaging should 
actually consider all the CoAP options of the embedded request, and not 
only its Class E options.

    That is, with reference to Figure 9 of RFC 8613, it should be 
"Options (if any) ..." instead of "Class E options (if any) ...".

* Is the Response-For Option of class E for OSCORE?

* If OSCORE is used, which peer is the encryptor of the embedded request 
encoded as value of the Response-For option? Is it the server or the 
client? In particular, what is used as request_kid and request_piv for 
the external_aad, when protecting both the response and the embedded 
request?


[Section 4.0]

* Like for a previous comment, this is different in 
core-observe-multicast-notifications. That is, the clients entrust the 
server to manage the Token space used for phantom requests generated by 
that server, against which multicast notifications will match.


[Section 4.2]

* "Note that, as the originator of a multicast response is a unicast 
address, the relaxation of matching rules described in Section 8.2 of 
[RFC7252] does not apply."

    Is this actually relevant here? The configured request is typically 
crafted as targeting a unicast address as its destination address.

    It would be relevant if the same configured request was configured 
at multiple servers, and crafted as targeting a multicast destination 
address that all those servers listen to.

* "all nodes joined to that multicast address"

    Perhaps clarify that this means listening to the same multicast 
address, regardless the exact way that the nodes used to gain knowledge 
of it.

* "The congestion control considerations for non-confirmable multicast 
messages apply unchanged."

    Actually, Section 4.4 of core-observe-multicast-notifications 
provides further guidelines and considerations about that.


[Section 4.3]

* "If a single client wants to request a server to send the response to 
a specific multicast address ..."

    Does it make sense to consider this also for non-multicast addresses?

* This contains an opaque string with the port number as a 16-bit number 
(in network byte order), followed by the IP address (4-byte IPv4 or 
16-byte IPv6).

    As also suggested for the current Response-Forwarding option in 
core-groupcomm-proxy, the value of this option can instead be a CRI 
without local part.

* If this option of class U and E for OSCORE?


[Section 4.4]

* "It allows the server to send that number of non-traditional response 
messages in addition to the requested response."

    Exactly that number? At most that number?

    If combined with Observe, would this option still influence the 
(maximum) number of notifications that are delivered back to the client?

* The whole discussion about using this option in the presence of 
proxies suggests that the option would be both inner and outer for 
OSCORE, right? That is, an outer option should also be added if a proxy 
is involved, and overall the same inclusion rules as for the Observe 
option should be followed.


[Appendix A.2]

* "When the destination address of a CoAP request is a multicast 
address, that token is valid for any member of that group (which, for 
the purpose of the client, is any server at all) on any port."

    Thinking of the terminology of draft-ietf-core-groupcomm-bis, I 
think you mean "CoAP group" here. However, there the definition of CoAP 
groups does take into account also the port number, i.e.:

    "A CoAP group is defined as a set of CoAP endpoints, where each 
endpoint is configured to receive CoAP group messages that are sent to 
the group's associated IP multicast address and UDP port."

* "it might be seen as a template for creating a phantom request to any 
endpoint"

    Could you expand on this and on where this template would be used? 
Is this, for instance, an abstractions model for multiple servers 
fabricating a same phantom request?

* "plus the application's timeout (in proxy situations, this needs to be 
communicated explicitly in the Multicast-Signaling option of 
[I-D.tiloca-core-groupcomm-proxy])."

    Yes, and that option was renamed to "Multicast-Timeout" as suggested 
by Carsten :-)


[Appendix A.3]

* "The Response-To option"

   I guess you mean the Respond-To option and not yet another different 
option. Correct?

* "make it into a CoAP-over-UDP request with that particular address as 
a source and any address of yours as a response, and treat that as a 
phantom request."

    I can't fully parse this sentence. What do you mean with "and any 
address of yours as a response"? Do you mean "and any address of yours 
as source address of a follow-up response"?


[Appendix A.4]

* "[I-D.tiloca-core-observe-multicast-notifications] is a 
straightforward application of the phantom requests (the concept was 
developed there)"

    Yes, although, based on the terminology of this document, it feels 
more about an application of the "configured requests".

* "Leisure-For-Responses could help it around the topic of joining a 
multicast group securely through a proxy."

    Can you elaborate more on that? Would this specifically help the 
proxy? How?

    I guess you have in mind the case where Group OSCORE is used (but 
without deterministic requests), and thus each and every client has to 
perform one more exchange with the proxy to provide it with the phantom 
request (see Section 12 of core-observe-multicast-notifications)

    Section 5.4 of core-observe-multicast-notifications is defining that 
a client would just silently forget about a grup observation if not 
interested anymore. The same would apply at the proxy when acting as 
client towards the origin server.

* "[I-D.tiloca-core-groupcomm-proxy] seems to fit well with the concepts 
here as well, and might be simplified by it both in terminology and by 
replacing Response-Forwarding with Response-For(Proxy-Scheme, Uri- Host)."

    When you say "in terminology", do you think about emphasizing that 
the responses received and forwarded back by the proxy, as well as 
ultimately received by the client are non-traditional responses?

    As to an alternative to Response-Forwarding, the current option 
content is the serialization of the following CBOR array

    tp_info = [
           tp_id : 1,               ; UDP as transport protocol
           srv_host : #6.260(bstr), ; IP address where to reach the server
         ? srv_port : uint / null   ; Port number where to reach the server
    ]

    We discussed that at some point it would be good to change this 
format to rather consider a CRI, specifying only scheme and authority. 
Actually, this would first apply to the definition of tp_info in 
core-observe-multicast-notifications , and then be inherited from there 
in -core-groupcomm-proxy.

    Thinking of rather using Response-For(Proxy-Scheme, Uri-Host) as 
above, would that still be aligned with the Response-For format defined 
in Section 3? That seems intended to pack the "whole" request with which 
the response is associated, including its options and payload. Instead, 
the intent of the Response-Forwarding option is to specify only 
addressing information.

    Even if Response-For could be used to specify only the options 
(Proxy-Scheme, Uri-Host) (or, better, the options (Proxy-Scheme, 
Uri-Host, Uri-Port)), wouldn't that result in additional overhead 
compared to a single option such as Response-Forwarding conveying a CRI 
without local part?

-- 
Marco Tiloca
Ph.D., Senior Researcher

Phone: [phone]

RISE Research Institutes of Sweden AB
Box 1263
164 29 Kista (Sweden)

Division: Digital Systems
Department: Computer Science
Unit: Cybersecurity

https://www.ri.se