Script updating gh-pages from 92fe943. [ci skip]

christian-post-wglc-review/draft-ietf-core-groupcomm-bis.html

@@ -2396,13 +2396,15 @@ <h3 id="name-observing-resources">
 <p id="section-3.7-3">Multicast Observe is a useful way to start observing a particular resource on all members of a CoAP group at the same time. Group members that do not have this particular resource or do not allow the GET or FETCH method on it will either respond with an error status -- 4.04 (Not Found) or 4.05 (Method Not Allowed), respectively -- or will silently suppress the response following the rules of <a href="#sec-request-response-suppress" class="auto internal xref">Section 3.1.2</a>, depending on server-specific configuration.<a href="#section-3.7-3" class="pilcrow">¶</a></p>
 <p id="section-3.7-4">A client that sends a group GET or FETCH request with the Observe Option <span class="bcp14">MAY</span> repeat this request using the same Token value and the same Observe Option value, in order to ensure that enough (or all) members of the CoAP group have been reached with the request. This is useful in case a number of members of the CoAP group did not respond to the initial request. The client <span class="bcp14">MAY</span> additionally use the same Message ID in the repeated request, to avoid that members of the CoAP group that had already received the initial request would respond again. Note that using the same Message ID in a repeated request will not be helpful in case of loss of a response message, since the server that responded already will consider the repeated request as a duplicate message. On the other hand, if the client uses a different, fresh Message ID in the repeated request, then all the members of the CoAP group that receive this new message will typically respond again, which increases the network load.<a href="#section-3.7-4" class="pilcrow">¶</a></p>
 <p id="section-3.7-5">A client that has sent a group GET or FETCH request with the Observe Option <span class="bcp14">MAY</span> follow up by sending a new unicast CON request with the same Token value and same Observe Option value to a particular server, in order to ensure that the particular server receives the request. This is useful in case a specific member of the CoAP group did not respond to the initial group request, although it was expected to. In this case, the client <span class="bcp14">MUST</span> use a Message ID that differs from that of the initial group request message.<a href="#section-3.7-5" class="pilcrow">¶</a></p>
-<p id="section-3.7-6">Furthermore, consistent with <span><a href="https://rfc-editor.org/rfc/rfc7641#section-3.3.1" class="relref">Section 3.3.1</a> of [<a href="#RFC7641" class="cite xref">RFC7641</a>]</span> and following its guidelines, a client <span class="bcp14">MAY</span> at any time send a new group/multicast GET or FETCH request with the same Token value and same Observe Option value as the original request. This allows the client to verify that it has an up-to-date representation of an observed resource and/or to re-register its interest to observe a resource.<a href="#section-3.7-6" class="pilcrow">¶</a></p>
-<p id="section-3.7-7">In the above client behaviors, the Token value is kept identical to the initial request to avoid that a client is included in more than one entry in the list of observers (<span><a href="https://rfc-editor.org/rfc/rfc7641#section-4.1" class="relref">Section 4.1</a> of [<a href="#RFC7641" class="cite xref">RFC7641</a>]</span>).<a href="#section-3.7-7" class="pilcrow">¶</a></p>
-<p id="section-3.7-8">Before repeating a request as specified above, the client <span class="bcp14">SHOULD</span> wait for at least the expected round-trip time plus the Leisure time period defined in <span><a href="https://rfc-editor.org/rfc/rfc7252#section-8.2" class="relref">Section 8.2</a> of [<a href="#RFC7252" class="cite xref">RFC7252</a>]</span>, to give the server time to respond.<a href="#section-3.7-8" class="pilcrow">¶</a></p>
-<p id="section-3.7-9">A server that receives a GET or FETCH request with the Observe Option, for which request processing is successful, <span class="bcp14">SHOULD</span> respond to this request and not suppress the response. If a server adds a client (as a new entry) to the list of observers for a resource due to an Observe request, the server <span class="bcp14">SHOULD</span> respond to this request and <span class="bcp14">SHOULD NOT</span> suppress the response. An exception to the above is the overriding of response suppression according to a CoAP No-Response Option <span>[<a href="#RFC7967" class="cite xref">RFC7967</a>]</span> specified by the client in the GET or FETCH request (see <a href="#sec-request-response-suppress" class="auto internal xref">Section 3.1.2</a>).<a href="#section-3.7-9" class="pilcrow">¶</a></p>
-<p id="section-3.7-10">A server <span class="bcp14">SHOULD</span> have a mechanism to verify the aliveness of its observing clients and the continued interest of these clients in receiving the Observe notifications. This can be implemented by sending notifications occasionally using a Confirmable message (see <span><a href="https://rfc-editor.org/rfc/rfc7641#section-4.5" class="relref">Section 4.5</a> of [<a href="#RFC7641" class="cite xref">RFC7641</a>]</span> for details). This requirement overrides the regular behavior of sending Non-confirmable notifications in response to a Non-confirmable request.<a href="#section-3.7-10" class="pilcrow">¶</a></p>
-<p id="section-3.7-11">A client can use the unicast cancellation methods of <span><a href="https://rfc-editor.org/rfc/rfc7641#section-3.6" class="relref">Section 3.6</a> of [<a href="#RFC7641" class="cite xref">RFC7641</a>]</span> and stop the ongoing observation of a particular resource on members of a CoAP group. This can be used to remove specific observed servers, or even all servers in the CoAP group (using serial unicast to each known group member). In addition, a client <span class="bcp14">MAY</span> explicitly deregister from all those servers at once, by sending a group/multicast GET or FETCH request that includes the Token value of the observation to be canceled and includes an Observe Option with the value set to 1 (deregister). In case not all the servers in the CoAP group received this deregistration request, either the unicast cancellation methods can be used at a later point in time or the group/multicast deregistration request <span class="bcp14">MAY</span> be repeated upon receiving another observe response from a server.<a href="#section-3.7-11" class="pilcrow">¶</a></p>
-<p id="section-3.7-12">For observing at servers that are members of a CoAP group through a CoAP-to-CoAP proxy, the limitations stated in <a href="#sec-proxy" class="auto internal xref">Section 3.5</a> apply. The method defined in <span>[<a href="#I-D.ietf-core-groupcomm-proxy" class="cite xref">I-D.ietf-core-groupcomm-proxy</a>]</span> enables group communication including resource observation through proxies and addresses those limitations.<a href="#section-3.7-12" class="pilcrow">¶</a></p>
+<p id="section-3.7-6">Since the first Observe notification from a server can be lost, a client should be ready to start receiving the Observe notifications from a server long after the Non-confirmable group request with the Observe Option was sent.<a href="#section-3.7-6" class="pilcrow">¶</a></p>
+<p id="section-3.7-7">At the same time, the loss of initial responses with the Observe Option from a server is less problematic than in the case where the group request is a regular request, i.e., when the request does not include the Observe Option. That is, as per <span><a href="https://rfc-editor.org/rfc/rfc7641#section-4.5" class="relref">Section 4.5</a> of [<a href="#RFC7641" class="cite xref">RFC7641</a>]</span>, servers that have registered a client as an observer have to ensure that the client achieves eventual consistency with respect to the representation of the observed resource. This realistically relies on the sending of new Observe notifications, which are occasionally expected to be sent as Confirmable messages also in order to assess client aliveness (see below).<a href="#section-3.7-7" class="pilcrow">¶</a></p>
+<p id="section-3.7-8">Furthermore, consistent with <span><a href="https://rfc-editor.org/rfc/rfc7641#section-3.3.1" class="relref">Section 3.3.1</a> of [<a href="#RFC7641" class="cite xref">RFC7641</a>]</span> and following its guidelines, a client <span class="bcp14">MAY</span> at any time send a new group/multicast GET or FETCH request with the same Token value and same Observe Option value as the original request. This allows the client to verify that it has an up-to-date representation of an observed resource and/or to re-register its interest to observe a resource.<a href="#section-3.7-8" class="pilcrow">¶</a></p>
+<p id="section-3.7-9">In the above client behaviors, the Token value is kept identical to the initial request to avoid that a client is included in more than one entry in the list of observers (<span><a href="https://rfc-editor.org/rfc/rfc7641#section-4.1" class="relref">Section 4.1</a> of [<a href="#RFC7641" class="cite xref">RFC7641</a>]</span>).<a href="#section-3.7-9" class="pilcrow">¶</a></p>
+<p id="section-3.7-10">Before repeating a request as specified above, the client <span class="bcp14">SHOULD</span> wait for at least the expected round-trip time plus the Leisure time period defined in <span><a href="https://rfc-editor.org/rfc/rfc7252#section-8.2" class="relref">Section 8.2</a> of [<a href="#RFC7252" class="cite xref">RFC7252</a>]</span>, to give the server time to respond.<a href="#section-3.7-10" class="pilcrow">¶</a></p>
+<p id="section-3.7-11">A server that receives a GET or FETCH request with the Observe Option, for which request processing is successful, <span class="bcp14">SHOULD</span> respond to this request and not suppress the response. If a server adds a client (as a new entry) to the list of observers for a resource due to an Observe request, the server <span class="bcp14">SHOULD</span> respond to this request and <span class="bcp14">SHOULD NOT</span> suppress the response. An exception to the above is the overriding of response suppression according to a CoAP No-Response Option <span>[<a href="#RFC7967" class="cite xref">RFC7967</a>]</span> specified by the client in the GET or FETCH request (see <a href="#sec-request-response-suppress" class="auto internal xref">Section 3.1.2</a>).<a href="#section-3.7-11" class="pilcrow">¶</a></p>
+<p id="section-3.7-12">A server <span class="bcp14">SHOULD</span> have a mechanism to verify the aliveness of its observing clients and the continued interest of these clients in receiving the Observe notifications. This can be implemented by sending notifications occasionally using a Confirmable message (see <span><a href="https://rfc-editor.org/rfc/rfc7641#section-4.5" class="relref">Section 4.5</a> of [<a href="#RFC7641" class="cite xref">RFC7641</a>]</span> for details). This requirement overrides the regular behavior of sending Non-confirmable notifications in response to a Non-confirmable request.<a href="#section-3.7-12" class="pilcrow">¶</a></p>
+<p id="section-3.7-13">A client can use the unicast cancellation methods of <span><a href="https://rfc-editor.org/rfc/rfc7641#section-3.6" class="relref">Section 3.6</a> of [<a href="#RFC7641" class="cite xref">RFC7641</a>]</span> and stop the ongoing observation of a particular resource on members of a CoAP group. This can be used to remove specific observed servers, or even all servers in the CoAP group (using serial unicast to each known group member). In addition, a client <span class="bcp14">MAY</span> explicitly deregister from all those servers at once, by sending a group/multicast GET or FETCH request that includes the Token value of the observation to be canceled and includes an Observe Option with the value set to 1 (deregister). In case not all the servers in the CoAP group received this deregistration request, either the unicast cancellation methods can be used at a later point in time or the group/multicast deregistration request <span class="bcp14">MAY</span> be repeated upon receiving another observe response from a server.<a href="#section-3.7-13" class="pilcrow">¶</a></p>
+<p id="section-3.7-14">For observing at servers that are members of a CoAP group through a CoAP-to-CoAP proxy, the limitations stated in <a href="#sec-proxy" class="auto internal xref">Section 3.5</a> apply. The method defined in <span>[<a href="#I-D.ietf-core-groupcomm-proxy" class="cite xref">I-D.ietf-core-groupcomm-proxy</a>]</span> enables group communication including resource observation through proxies and addresses those limitations.<a href="#section-3.7-14" class="pilcrow">¶</a></p>
 </section>
 </div>
 <div id="sec-block-wise">
@@ -4285,16 +4287,19 @@ <h3 id="name-version-11-to-12">
         </h3>
 <ul class="normal">
 <li class="normal" id="appendix-E.1-1.1">
-            <p id="appendix-E.1-1.1.1">Admitted resource retrieval through consecutive group requests with the Block2 Option.<a href="#appendix-E.1-1.1.1" class="pilcrow">¶</a></p>
+            <p id="appendix-E.1-1.1.1">Consideration on how eventual consistency from Observe compensates for lost notifications.<a href="#appendix-E.1-1.1.1" class="pilcrow">¶</a></p>
 </li>
           <li class="normal" id="appendix-E.1-1.2">
-            <p id="appendix-E.1-1.2.1">Clarified relation with TCP/TLS/WebSockets.<a href="#appendix-E.1-1.2.1" class="pilcrow">¶</a></p>
+            <p id="appendix-E.1-1.2.1">Admitted resource retrieval through consecutive group requests with the Block2 Option.<a href="#appendix-E.1-1.2.1" class="pilcrow">¶</a></p>
 </li>
           <li class="normal" id="appendix-E.1-1.3">
-            <p id="appendix-E.1-1.3.1">Clarified security on the different legs with a proxy.<a href="#appendix-E.1-1.3.1" class="pilcrow">¶</a></p>
+            <p id="appendix-E.1-1.3.1">Clarified relation with TCP/TLS/WebSockets.<a href="#appendix-E.1-1.3.1" class="pilcrow">¶</a></p>
 </li>
           <li class="normal" id="appendix-E.1-1.4">
-            <p id="appendix-E.1-1.4.1">Editorial improvements.<a href="#appendix-E.1-1.4.1" class="pilcrow">¶</a></p>
+            <p id="appendix-E.1-1.4.1">Clarified security on the different legs with a proxy.<a href="#appendix-E.1-1.4.1" class="pilcrow">¶</a></p>
+</li>
+          <li class="normal" id="appendix-E.1-1.5">
+            <p id="appendix-E.1-1.5.1">Editorial improvements.<a href="#appendix-E.1-1.5.1" class="pilcrow">¶</a></p>
 </li>
         </ul>
 </section>

christian-post-wglc-review/draft-ietf-core-groupcomm-bis.txt

@@ -1732,6 +1732,22 @@ Table of Contents
    expected to.  In this case, the client MUST use a Message ID that
    differs from that of the initial group request message.
 
+   Since the first Observe notification from a server can be lost, a
+   client should be ready to start receiving the Observe notifications
+   from a server long after the Non-confirmable group request with the
+   Observe Option was sent.
+
+   At the same time, the loss of initial responses with the Observe
+   Option from a server is less problematic than in the case where the
+   group request is a regular request, i.e., when the request does not
+   include the Observe Option.  That is, as per Section 4.5 of
+   [RFC7641], servers that have registered a client as an observer have
+   to ensure that the client achieves eventual consistency with respect
+   to the representation of the observed resource.  This realistically
+   relies on the sending of new Observe notifications, which are
+   occasionally expected to be sent as Confirmable messages also in
+   order to assess client aliveness (see below).
+
    Furthermore, consistent with Section 3.3.1 of [RFC7641] and following
    its guidelines, a client MAY at any time send a new group/multicast
    GET or FETCH request with the same Token value and same Observe
@@ -3892,6 +3908,9 @@ Appendix E.  Document Updates
 
 E.1.  Version -11 to -12
 
+   *  Consideration on how eventual consistency from Observe compensates
+      for lost notifications.
+
    *  Admitted resource retrieval through consecutive group requests
       with the Block2 Option.