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

carsten-wglc-2/draft-ietf-core-groupcomm-bis.html

@@ -2543,7 +2543,7 @@ <h3 id="name-group-oscore">
         </h3>
 <p id="section-5.1-1">The application-layer protocol Object Security for Constrained RESTful Environments (OSCORE) <span>[<a href="#RFC8613" class="cite xref">RFC8613</a>]</span> provides end-to-end encryption, integrity, and replay protection of CoAP messages exchanged between two CoAP endpoints. These can act both as CoAP Client as well as CoAP Server, and share an OSCORE Security Context used to protect and verify exchanged messages. The use of OSCORE does not affect the URI scheme and OSCORE can therefore be used with any URI scheme defined for CoAP.<a href="#section-5.1-1" class="pilcrow">¶</a></p>
 <p id="section-5.1-2">OSCORE uses COSE <span>[<a href="#RFC9052" class="cite xref">RFC9052</a>]</span><span>[<a href="#RFC9053" class="cite xref">RFC9053</a>]</span> to perform encryption operations and protect a CoAP message carried in a COSE object, by using an Authenticated Encryption with Associated Data (AEAD) algorithm. In particular, OSCORE takes as input an unprotected CoAP message and transforms it into a protected CoAP message transporting the COSE object.<a href="#section-5.1-2" class="pilcrow">¶</a></p>
-<p id="section-5.1-3">OSCORE makes it possible to selectively protect different parts of a CoAP message in different ways, while still allowing intermediaries (e.g., CoAP proxies) to perform their intended functionalities. That is, some message parts are encrypted and integrity protected; other parts are only integrity protected to be accessible to, but not modifiable by, proxies; and some parts are kept as plain content to be both accessible to and modifiable by proxies. Such differences especially concern the CoAP options included in the unprotected message.<a href="#section-5.1-3" class="pilcrow">¶</a></p>
+<p id="section-5.1-3">OSCORE makes it possible to selectively protect different parts of a CoAP message in different ways, while still allowing intermediaries (e.g., CoAP proxies) to perform their intended functionalities. That is, some message parts are encrypted and integrity protected; other parts are only integrity protected to be accessible to, but not modifiable by, proxies; and some parts are kept as plain content to be both accessible to and modifiable by proxies. <span><a href="https://rfc-editor.org/rfc/rfc8613#section-4" class="relref">Section 4</a> of [<a href="#RFC8613" class="cite xref">RFC8613</a>]</span> defines in detail if and what protection is applied to the CoAP header fields, payload, and CoAP options specified in the unprotected message, in accordance with their class for OSCORE.<a href="#section-5.1-3" class="pilcrow">¶</a></p>
 <p id="section-5.1-4">Group OSCORE <span>[<a href="#I-D.ietf-core-oscore-groupcomm" class="cite xref">I-D.ietf-core-oscore-groupcomm</a>]</span> builds on OSCORE, and provides end-to-end security of CoAP messages exchanged between members of an OSCORE group, while fulfilling the same security requirements.<a href="#section-5.1-4" class="pilcrow">¶</a></p>
 <p id="section-5.1-5">In particular, Group OSCORE protects CoAP group requests sent by a CoAP client, e.g., over UDP/IP multicast, as well as multiple corresponding CoAP responses sent as (IP) unicast by different CoAP servers. However, the same security material can also be used to protect CoAP requests sent over (IP) unicast to a single CoAP server in the OSCORE group, as well as the corresponding responses.<a href="#section-5.1-5" class="pilcrow">¶</a></p>
 <p id="section-5.1-6">Group OSCORE ensures source authentication of all messages exchanged within the OSCORE group. That is, the recipient of a CoAP message protected with Group OSCORE is able to securely verify whether the CoAP endpoint that has generated and sent the message is indeed the alleged one. This is achieved by means of two possible methods.<a href="#section-5.1-6" class="pilcrow">¶</a></p>

carsten-wglc-2/draft-ietf-core-groupcomm-bis.txt

@@ -2106,9 +2106,10 @@ Table of Contents
    is, some message parts are encrypted and integrity protected; other
    parts are only integrity protected to be accessible to, but not
    modifiable by, proxies; and some parts are kept as plain content to
-   be both accessible to and modifiable by proxies.  Such differences
-   especially concern the CoAP options included in the unprotected
-   message.
+   be both accessible to and modifiable by proxies.  Section 4 of
+   [RFC8613] defines in detail if and what protection is applied to the
+   CoAP header fields, payload, and CoAP options specified in the
+   unprotected message, in accordance with their class for OSCORE.
 
    Group OSCORE [I-D.ietf-core-oscore-groupcomm] builds on OSCORE, and
    provides end-to-end security of CoAP messages exchanged between