Script updating gh-pages from 3af4bab. [ci skip]

john-comments/draft-ietf-core-groupcomm-bis.html

@@ -2532,7 +2532,7 @@ <h2 id="name-unsecured-group-communicati">
 <p id="section-4-2">The NoSec mode does not require and does not make use of a security group. Indications that endpoints can use the NoSec mode MUST NOT rely on setting up and advertising a pseudo security group with name "NoSec" or any of its lowercase/uppercase combinations.<a href="#section-4-2" class="pilcrow">¶</a></p>
 <p id="section-4-3">A CoAP server in NoSec mode MUST NOT be accessible through the public Internet.
 It is NOT RECOMMENDED to use CoAP group communication in NoSec mode.<a href="#section-4-3" class="pilcrow">¶</a></p>
-<p id="section-4-4">The possible, exceptional use of the NoSec mode ought to be limited to: applications that are proven to be neither sensitive nor critical; and specific, well-defined steps where security is not viable or is intrinsically unattainable, e.g., early discovery of devices and resources (see <a href="#chap-security-considerations-nosec-mode" class="auto internal xref">Section 6.1</a>).<a href="#section-4-4" class="pilcrow">¶</a></p>
+<p id="section-4-4">The possible, exceptional use of the NoSec mode ought to be limited to specific, well-defined steps that are proven to not require security or to not be able to attain it, e.g., early discovery of devices and resources (see <a href="#chap-security-considerations-nosec-mode" class="auto internal xref">Section 6.1</a>).<a href="#section-4-4" class="pilcrow">¶</a></p>
 <p id="section-4-5">Before possibly and exceptionally using the NoSec mode in such circumstances, the security implications in <a href="#chap-security-considerations-nosec-mode" class="auto internal xref">Section 6.1</a> must be very well considered and understood, especially as to the risk and impact of amplification attacks (see <a href="#ssec-amplification" class="auto internal xref">Section 6.3</a>). Consistently with such security implications, the use of the NoSec mode should still be avoided whenever possible.<a href="#section-4-5" class="pilcrow">¶</a></p>
 </section>
 </div>
@@ -2636,7 +2636,7 @@ <h3 id="name-group-oscore-2">
 <a href="#section-6.2" class="section-number selfRef">6.2. </a><a href="#name-group-oscore-2" class="section-name selfRef">Group OSCORE</a>
         </h3>
 <p id="section-6.2-1">Group OSCORE provides end-to-end application-level security. This has many desirable properties, including maintaining security assurances while forwarding traffic through intermediaries (proxies). Application-level security also tends to more cleanly separate security from the specific dynamics of security group membership (e.g., the problem of distributing security keys across large groups with many members that come and go).<a href="#section-6.2-1" class="pilcrow">¶</a></p>
-<p id="section-6.2-2">CoAP group communication MUST be protected by using Group OSCORE as specified in <span>[<a href="#I-D.ietf-core-oscore-groupcomm" class="cite xref">I-D.ietf-core-oscore-groupcomm</a>]</span>, with the possible exception of: applications that are proven to be neither sensitive nor critical; and specific, well-defined steps where security is not viable or is intrinsically unattainable (e.g., early discovery).<a href="#section-6.2-2" class="pilcrow">¶</a></p>
+<p id="section-6.2-2">CoAP group communication MUST be protected by using Group OSCORE as specified in <span>[<a href="#I-D.ietf-core-oscore-groupcomm" class="cite xref">I-D.ietf-core-oscore-groupcomm</a>]</span>, with the possible exception of specific, well-defined steps that are proven to not require security or to not be able to attain it (e.g., early discovery).<a href="#section-6.2-2" class="pilcrow">¶</a></p>
 <p id="section-6.2-3">The same security considerations from <span><a href="https://datatracker.ietf.org/doc/html/draft-ietf-core-oscore-groupcomm-20#section-13" class="relref">Section 13</a> of [<a href="#I-D.ietf-core-oscore-groupcomm" class="cite xref">I-D.ietf-core-oscore-groupcomm</a>]</span> hold for this specification.<a href="#section-6.2-3" class="pilcrow">¶</a></p>
 <div id="chap-security-considerations-sec-mode-key-mgmt">
 <section id="section-6.2.1">

john-comments/draft-ietf-core-groupcomm-bis.txt

@@ -2053,9 +2053,8 @@ Table of Contents
    NoSec mode.
 
    The possible, exceptional use of the NoSec mode ought to be limited
-   to: applications that are proven to be neither sensitive nor
-   critical; and specific, well-defined steps where security is not
-   viable or is intrinsically unattainable, e.g., early discovery of
+   to specific, well-defined steps that are proven to not require
+   security or to not be able to attain it, e.g., early discovery of
    devices and resources (see Section 6.1).
 
    Before possibly and exceptionally using the NoSec mode in such
@@ -2317,9 +2316,9 @@ Table of Contents
 
    CoAP group communication MUST be protected by using Group OSCORE as
    specified in [I-D.ietf-core-oscore-groupcomm], with the possible
-   exception of: applications that are proven to be neither sensitive
-   nor critical; and specific, well-defined steps where security is not
-   viable or is intrinsically unattainable (e.g., early discovery).
+   exception of specific, well-defined steps that are proven to not
+   require security or to not be able to attain it (e.g., early
+   discovery).
 
    The same security considerations from Section 13 of
    [I-D.ietf-core-oscore-groupcomm] hold for this specification.