From f67288468f333c18ce923e8efb0273f58975c222 Mon Sep 17 00:00:00 2001
From: ID Bot <idbot@example.com>
Date: Thu, 5 Sep 2024 20:42:06 +0000
Subject: [PATCH] Script updating gh-pages from 0a7352f. [ci skip]

---
 .../draft-ietf-core-groupcomm-bis.html              |  9 ++++++---
 .../draft-ietf-core-groupcomm-bis.txt               | 13 +++++++++----
 2 files changed, 15 insertions(+), 7 deletions(-)

diff --git a/christian-post-wglc-review/draft-ietf-core-groupcomm-bis.html b/christian-post-wglc-review/draft-ietf-core-groupcomm-bis.html
index 8794f93..ef61be2 100644
--- a/christian-post-wglc-review/draft-ietf-core-groupcomm-bis.html
+++ b/christian-post-wglc-review/draft-ietf-core-groupcomm-bis.html
@@ -2459,7 +2459,7 @@ <h4 id="name-tcp-tls-and-websockets">
           </h4>
 <p id="section-3.9.4-1">Because it supports unicast only, <span>[<a href="#RFC8323" class="cite xref">RFC8323</a>]</span> (CoAP over TCP, TLS, and WebSockets) has a restricted scope as a transport for CoAP group communication. This is limited to the use of block-wise transfer discussed in <a href="#sec-block-wise" class="auto internal xref">Section 3.8</a>.<a href="#section-3.9.4-1" class="pilcrow">¶</a></p>
 <p id="section-3.9.4-2">That is, after the first group request including the Block2 Option and sent over UDP, the following unicast CoAP requests targeting individual servers to retrieve further blocks may be sent over TCP or WebSockets, possibly protected with TLS.<a href="#section-3.9.4-2" class="pilcrow">¶</a></p>
-<p id="section-3.9.4-3">This requires the individually addressed servers to also support CoAP over TCP/TLS/WebSockets for the targeted resource. A server can indicate its support for multiple alternative transports, and practically enable access to its resources through either of them, by using the method defined in <span>[<a href="#I-D.ietf-core-transport-indication" class="cite xref">I-D.ietf-core-transport-indication</a>]</span>.<a href="#section-3.9.4-3" class="pilcrow">¶</a></p>
+<p id="section-3.9.4-3">This requires the individually addressed servers to also support CoAP over TCP/TLS/WebSockets for the targeted resource. While those transports do not support multicast, it is possible to rely on multicast for discovering that a server has those transports available and that they allow accessing the targeted resource, possibly with block-wise transfer used for random access to blocks within the resource reprentation. Such discovering can rely on means defined in <span>[<a href="#I-D.ietf-core-transport-indication" class="cite xref">I-D.ietf-core-transport-indication</a>]</span>.<a href="#section-3.9.4-3" class="pilcrow">¶</a></p>
 </section>
 </div>
 <div id="other-transports">
@@ -4276,10 +4276,13 @@ <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">Clarified security on the different legs with a proxy.<a href="#appendix-E.1-1.1.1" class="pilcrow">¶</a></p>
+            <p id="appendix-E.1-1.1.1">Clarified relation with TCP/TLS/WebSockets.<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">Editorial improvements.<a href="#appendix-E.1-1.2.1" class="pilcrow">¶</a></p>
+            <p id="appendix-E.1-1.2.1">Clarified security on the different legs with a proxy.<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">Editorial improvements.<a href="#appendix-E.1-1.3.1" class="pilcrow">¶</a></p>
 </li>
         </ul>
 </section>
diff --git a/christian-post-wglc-review/draft-ietf-core-groupcomm-bis.txt b/christian-post-wglc-review/draft-ietf-core-groupcomm-bis.txt
index bae85e9..c83f550 100644
--- a/christian-post-wglc-review/draft-ietf-core-groupcomm-bis.txt
+++ b/christian-post-wglc-review/draft-ietf-core-groupcomm-bis.txt
@@ -1906,10 +1906,13 @@ Table of Contents
    WebSockets, possibly protected with TLS.
 
    This requires the individually addressed servers to also support CoAP
-   over TCP/TLS/WebSockets for the targeted resource.  A server can
-   indicate its support for multiple alternative transports, and
-   practically enable access to its resources through either of them, by
-   using the method defined in [I-D.ietf-core-transport-indication].
+   over TCP/TLS/WebSockets for the targeted resource.  While those
+   transports do not support multicast, it is possible to rely on
+   multicast for discovering that a server has those transports
+   available and that they allow accessing the targeted resource,
+   possibly with block-wise transfer used for random access to blocks
+   within the resource reprentation.  Such discovering can rely on means
+   defined in [I-D.ietf-core-transport-indication].
 
 3.9.5.  Other Transports
 
@@ -3877,6 +3880,8 @@ Appendix E.  Document Updates
 
 E.1.  Version -11 to -12
 
+   *  Clarified relation with TCP/TLS/WebSockets.
+
    *  Clarified security on the different legs with a proxy.
 
    *  Editorial improvements.