diff --git a/draft-ietf-core-observe-multicast-notifications.html b/draft-ietf-core-observe-multicast-notifications.html index 4572d69..dc5b715 100644 --- a/draft-ietf-core-observe-multicast-notifications.html +++ b/draft-ietf-core-observe-multicast-notifications.html @@ -1297,7 +1297,7 @@

8.1. Multicast-Response-Feedback-Divider Option

In order to enable the rough counting of still active and interested clients, a new CoAP option is introduced, which SHOULD be supported by clients that listen to multicast responses.

-

The option is called Multicast-Response-Feedback-Divider. As summarized in Figure 6, the option is not Critical, not Safe-to-Forward, and integer valued. Since the option is not Safe-to-Forward, the column "N" indicates a dash for "not applicable".

-
-
-
-
-+-----+---+---+---+---+---------------------+--------+------+---------+
-| No. | C | U | N | R | Name                | Format | Len. | Default |
-+-----+---+---+---+---+---------------------+--------+------+---------+
-| TBD |   | x | - |   | Multicast-Response- | uint   | 0-1  | (none)  |
-|     |   |   |   |   | Feedback-Divider    |        |      |         |
-+-----+---+---+---+---+---------------------+--------+------+---------+
-
-      C = Critical, U = Unsafe, N = NoCacheKey, R = Repeatable
-
-
-
Figure 6: -Multicast-Response-Feedback-Divider -
+

The option is called Multicast-Response-Feedback-Divider and has the properties summarized in Table 1, which extends Table 4 of [RFC7252]. The option is not Critical, not Safe-to-Forward, and integer valued. Since the option is not Safe-to-Forward, the column "N" indicates a dash for "not applicable".

+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+Table 1: +The Multicast-Response-Feedback-Divider Option.    C=Critical, U=Unsafe, N=NoCacheKey, R=Repeatable +
No.CUNRNameFormatLengthDefault
TBD x- Multicast-Response-
Feedback-Divider		uint0-1(none)

The Multicast-Response-Feedback-Divider Option is of class E for OSCORE [RFC8613][I-D.ietf-core-oscore-groupcomm].

@@ -2598,7 +2614,7 @@

@@ -3074,26 +3090,40 @@

12.1. Listen-To-Multicast-Responses Option

In order to allow the proxy to listen to the multicast notifications sent by the server, a new CoAP option is introduced. This option MUST be supported by clients interested to take part in group observations through intermediaries, and by proxies that collect multicast notifications and forward them back to the observer clients.

-

The option is called Listen-To-Multicast-Responses and is intended only for requests. As summarized in Figure 8, the option is critical and not Safe-to-Forward. Since the option is not Safe-to-Forward, the column "N" indicates a dash for "not applicable".

-
-
-
-
-+-----+---+---+---+---+-------------------+--------+--------+---------+
-| No. | C | U | N | R | Name              | Format | Len.   | Default |
-+-----+---+---+---+---+-------------------+--------+--------+---------+
-| TBD | x | x | - |   | Listen-To-        |  (*)   | 3-1024 | (none)  |
-|     |   |   |   |   | Multicast-        |        |        |         |
-|     |   |   |   |   | Responses         |        |        |         |
-+-----+---+---+---+---+-------------------+--------+--------+---------+
-
-      C = Critical, U = Unsafe, N = NoCacheKey, R = Repeatable
-      (*) See below.
-
-
-
Figure 8: -Listen-To-Multicast-Responses -
+

The option is called Listen-To-Multicast-Response, is intended only for requests, and has the properties summarized in Table 2, which extends Table 4 of [RFC7252]. The option is critical and not Safe-to-Forward. Since the option is not Safe-to-Forward, the column "N" indicates a dash for "not applicable".

+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+Table 2: +The Listen-To-Multicast-Responses Option.                C=Critical, U=Unsafe, N=NoCacheKey, R=Repeatable +
No.CUNRNameFormatLengthDefault
TBDxx- Listen-To-
Multicast-Responses		(*)3-1024(none)

The Listen-To-Multicast-Responses Option includes the byte serialization of a CBOR array. This specifies transport-specific message information required for listening to the multicast notifications of a group observation, and intended to the proxy adjacent to the origin server sending those notifications. In particular, the serialized CBOR array has the same format specified in Section 4.2.1 for the 'tp_info' parameter of the informative response (see Section 4.2).

The Listen-To-Multicast-Responses Option is of class U for OSCORE [RFC8613][I-D.ietf-core-oscore-groupcomm].

@@ -3168,9 +3198,9 @@

This document defines a number of fields used in the informative response defined in Section 4.2.

The table below summarizes them and specifies the CBOR key to use as abbreviation, instead of the full descriptive name. Note that the media type application/informative-response+cbor MUST be used when these fields are transported.

- +
@@ -3333,7 +3363,7 @@

The table below summarizes them, specifies the integer value to use instead of the full descriptive name, and provides the corresponding comprehensive set of information elements to include in the 'tp_info' parameter.

Note to RFC Editor: Please replace in the table below all occurrences of "[RFC-XXXX]" with the RFC number of this specification and delete this paragraph.

-
+
 +-----------+-------------+-------+----------+-----------+------------+
@@ -3349,7 +3379,7 @@ 

 +-----------+-------------+-------+----------+-----------+------------+
-
Figure 9: +
Figure 7: Transport protocol information
@@ -3391,8 +3421,8 @@

-

-15.3. Listen-To-Multicast-Responses Option +

+15.3. Listen-To-Multicast-Responses Option

The CoAP option Listen-To-Multicast-Responses defined in Section 12.1 is of class U for OSCORE and Group OSCORE [RFC8613][I-D.ietf-core-oscore-groupcomm].

This allows the proxy adjacent to the origin server to access the option value conveyed in a ticket request (see Section 12.2), and to retrieve from it the transport-specific information about a phantom request. By doing so, the proxy becomes able to configure an observation of the target resource and to receive multicast notifications matching to the phantom request.

@@ -3487,9 +3517,9 @@

16.3. CoAP Option Numbers Registry

IANA is asked to enter the following option numbers to the "CoAP Option Numbers" registry within the "CoRE Parameters" registry group.

-

-Table 1: +Table 3: Informative Response Parameters.
+
@@ -3785,10 +3815,10 @@

In a Publish-Subscribe scenario [I-D.ietf-core-coap-pubsub], a group observation can be discovered along with topic metadata.

To this end, together with topic metadata, the server has to publish the same information associated with the group observation that would be conveyed in the informative response returned to observer clients (see Section 4.2).

This information especially includes the phantom observation request associated with the group observation, as well as the addressing information of the server and the addressing information where multicast notifications are sent to.

-

Figure 10 provides an example where a group observation is discovered. The example assumes a CoRAL namespace [I-D.ietf-core-coral], that contains properties analogous to those in the content-format application/informative-response+cbor.

+

Figure 8 provides an example where a group observation is discovered. The example assumes a CoRAL namespace [I-D.ietf-core-coral], that contains properties analogous to those in the content-format application/informative-response+cbor.

Note that the information about the transport protocol used for the group observation is not expressed through a dedicated element equivalent to 'tp_id' of the informative response (see Section 4.2.1). Instead, it is expressed through the scheme component of the two URIs specified as 'tp_info_srv' and 'tp_info_cli', where the former specifies the addressing information of the server (like 'srv_host' and 'srv_port' in Section 4.2.1.1), while the latter specifies the addressing information where multicast notifications are sent to (like 'cli_host' and 'cli_port' in Section 4.2.1.1).

-
+
 Request:
@@ -3812,7 +3842,7 @@ 

     ]
-
Figure 10: +
Figure 8: Group observation discovery in a Pub-Sub scenario
@@ -3828,7 +3858,7 @@

For network debugging purposes, it can be useful to query a server that sends multicast responses as matching a phantom registration request.

Such an interface is left for other documents to specify on demand. As an example, a possible interface can be as follows, and rely on the already known Token value of intercepted multicast notifications, associated with a phantom registration request.

@@ -4181,7 +4211,7 @@

This section provides an example when a proxy P is used between the clients and the server. The same assumptions and notation used in Section 7 are used for this example. In addition, the proxy has address PRX_ADDR and listens to the port number PRX_PORT.

Unless explicitly indicated, all messages transmitted on the wire are sent over unicast.

@@ -4477,7 +4507,7 @@

The same assumptions and notation used in Section 10 are used for this example. In addition, the proxy has address PRX_ADDR and listens to the port number PRX_PORT.

Unless explicitly indicated, all messages transmitted on the wire are sent over unicast and protected with OSCORE end-to-end between a client and the server.

diff --git a/draft-ietf-core-observe-multicast-notifications.txt b/draft-ietf-core-observe-multicast-notifications.txt index 6c7257c..9b31f6d 100644 --- a/draft-ietf-core-observe-multicast-notifications.txt +++ b/draft-ietf-core-observe-multicast-notifications.txt @@ -1094,21 +1094,21 @@ Table of Contents clients, a new CoAP option is introduced, which SHOULD be supported by clients that listen to multicast responses. - The option is called Multicast-Response-Feedback-Divider. As - summarized in Figure 6, the option is not Critical, not Safe-to- - Forward, and integer valued. Since the option is not Safe-to- - Forward, the column "N" indicates a dash for "not applicable". - - +-----+---+---+---+---+---------------------+--------+------+---------+ - | No. | C | U | N | R | Name | Format | Len. | Default | - +-----+---+---+---+---+---------------------+--------+------+---------+ - | TBD | | x | - | | Multicast-Response- | uint | 0-1 | (none) | - | | | | | | Feedback-Divider | | | | - +-----+---+---+---+---+---------------------+--------+------+---------+ - - C = Critical, U = Unsafe, N = NoCacheKey, R = Repeatable - - Figure 6: Multicast-Response-Feedback-Divider + The option is called Multicast-Response-Feedback-Divider and has the + properties summarized in Table 1, which extends Table 4 of [RFC7252]. + The option is not Critical, not Safe-to-Forward, and integer valued. + Since the option is not Safe-to-Forward, the column "N" indicates a + dash for "not applicable". + + +=====+=+=+=+===+=====================+========+========+=========+ + | No. |C|U|N| R | Name | Format | Length | Default | + +=====+=+=+=+===+=====================+========+========+=========+ + | TBD | |x|-| | Multicast-Response- | uint | 0-1 | (none) | + | | | | | | Feedback-Divider | | | | + +-----+-+-+-+---+---------------------+--------+--------+---------+ + + Table 1: The Multicast-Response-Feedback-Divider Option. + C=Critical, U=Unsafe, N=NoCacheKey, R=Repeatable The Multicast-Response-Feedback-Divider Option is of class E for OSCORE [RFC8613][I-D.ietf-core-oscore-groupcomm]. @@ -1866,7 +1866,7 @@ Table of Contents | | | | - Figure 7: Example of group observation with Group OSCORE + Figure 6: Example of group observation with Group OSCORE The two external_aad used to encrypt and sign the multicast notification above have 'request_kid' = 5, 'request_piv' = 501, and @@ -2015,23 +2015,21 @@ Table of Contents multicast notifications and forward them back to the observer clients. - The option is called Listen-To-Multicast-Responses and is intended - only for requests. As summarized in Figure 8, the option is critical - and not Safe-to-Forward. Since the option is not Safe-to-Forward, - the column "N" indicates a dash for "not applicable". - - +-----+---+---+---+---+-------------------+--------+--------+---------+ - | No. | C | U | N | R | Name | Format | Len. | Default | - +-----+---+---+---+---+-------------------+--------+--------+---------+ - | TBD | x | x | - | | Listen-To- | (*) | 3-1024 | (none) | - | | | | | | Multicast- | | | | - | | | | | | Responses | | | | - +-----+---+---+---+---+-------------------+--------+--------+---------+ + The option is called Listen-To-Multicast-Response, is intended only + for requests, and has the properties summarized in Table 2, which + extends Table 4 of [RFC7252]. The option is critical and not Safe- + to-Forward. Since the option is not Safe-to-Forward, the column "N" + indicates a dash for "not applicable". - C = Critical, U = Unsafe, N = NoCacheKey, R = Repeatable - (*) See below. + +=====+=+=+=+===+=====================+========+========+=========+ + | No. |C|U|N| R | Name | Format | Length | Default | + +=====+=+=+=+===+=====================+========+========+=========+ + | TBD |x|x|-| | Listen-To- | (*) | 3-1024 | (none) | + | | | | | | Multicast-Responses | | | | + +-----+-+-+-+---+---------------------+--------+--------+---------+ - Figure 8: Listen-To-Multicast-Responses + Table 2: The Listen-To-Multicast-Responses Option. + C=Critical, U=Unsafe, N=NoCacheKey, R=Repeatable The Listen-To-Multicast-Responses Option includes the byte serialization of a CBOR array. This specifies transport-specific @@ -2190,7 +2188,7 @@ Table of Contents | exp | 16 | uint | Appendix C | +-----------------+----------+-------------+-------------+ - Table 1: Informative Response Parameters. + Table 3: Informative Response Parameters. 14. Transport Protocol Information @@ -2223,7 +2221,7 @@ Table of Contents | | RFC7252 | | srv_port | ?cli_port | | +-----------+-------------+-------+----------+-----------+------------+ - Figure 9: Transport protocol information + Figure 7: Transport protocol information 15. Security Considerations @@ -2403,7 +2401,7 @@ Table of Contents | TBD | Listen-To-Multicast-Responses | [RFC-XXXX] | +--------+-------------------------------------+------------+ - Table 2: Registrations in the CoAP Option Numbers Registry + Table 4: Registrations in the CoAP Option Numbers Registry 16.4. Informative Response Parameters Registry @@ -2763,10 +2761,10 @@ A.1. Topic Discovery in Publish-Subscribe Settings information of the server and the addressing information where multicast notifications are sent to. - Figure 10 provides an example where a group observation is - discovered. The example assumes a CoRAL namespace - [I-D.ietf-core-coral], that contains properties analogous to those in - the content-format application/informative-response+cbor. + Figure 8 provides an example where a group observation is discovered. + The example assumes a CoRAL namespace [I-D.ietf-core-coral], that + contains properties analogous to those in the content-format + application/informative-response+cbor. Note that the information about the transport protocol used for the group observation is not expressed through a dedicated element @@ -2799,7 +2797,7 @@ A.1. Topic Discovery in Publish-Subscribe Settings ] ] - Figure 10: Group observation discovery in a Pub-Sub scenario + Figure 8: Group observation discovery in a Pub-Sub scenario With this information from the topic discovery step, the client can already set up its multicast address and start receiving multicast @@ -2842,7 +2840,7 @@ A.2. Introspection at the Multicast Notification Sender / last_notif / 2 : h'256105/.../' } - Figure 11: Group observation discovery with server introspection + Figure 9: Group observation discovery with server introspection For example, a network sniffer could offer sending such a request when unknown multicast notifications are seen in a network. @@ -3452,7 +3450,7 @@ Appendix E. Example with a Proxy (#) Sent over IP multicast to GROUP_ADDR:GROUP_PORT. - Figure 12: Example of group observation with a proxy + Figure 10: Example of group observation with a proxy Note that the proxy has all the information to understand the observation request from C2, and can immediately start to serve the @@ -3741,7 +3739,7 @@ Appendix F. Example with a Proxy and Group OSCORE (##) Sent over IP multicast to GROUP_ADDR:GROUP_PORT, and protected with Group OSCORE end-to-end between the server and the clients. - Figure 13: Example of group observation with a proxy and Group OSCORE + Figure 11: Example of group observation with a proxy and Group OSCORE Unlike in the unprotected example in Appendix E, the proxy does _not_ have all the information to perform request deduplication, and can

-Table 2: +Table 4: Registrations in the CoAP Option Numbers Registry