Script updating gh-pages from b590f2d. [ci skip]

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

@@ -2400,7 +2400,7 @@ <h3 id="name-observing-resources">
 <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-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>
 </section>

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

@@ -1760,7 +1760,7 @@ Table of Contents
 
    A server SHOULD 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
+   receiving the Observe notifications.  This can be implemented by
    sending notifications occasionally using a Confirmable message (see
    Section 4.5 of [RFC7641] for details).  This requirement overrides
    the regular behavior of sending Non-confirmable notifications in