Script updating gh-pages from 224ed1a. [ci skip]

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

@@ -2621,7 +2621,7 @@ <h3 id="name-coap-nosec-mode">
 The requirement in <a href="#chap-unsecured-groupcomm" class="auto internal xref">Section 4</a> on publically accessible CoAP servers also aims to prevent amplification attacks.<a href="#section-6.1-2" class="pilcrow">¶</a></p>
 <p id="section-6.1-3">Exceptionally, and only after the security implications have been very well considered and understood, some applications may rely on a limited use of the NoSec mode, when performing specific, well-defined "unsecured steps" (see <a href="#chap-unsecured-groupcomm" class="auto internal xref">Section 4</a>).<a href="#section-6.1-3" class="pilcrow">¶</a></p>
 <p id="section-6.1-4">For example, early link-local discovery of devices and resources as part of an onboarding protocol is a typical use case where the NoSec mode or equivalent unsecured mode is used. In such a discovery step, there may be a querying device that needs to discover nearby devices capable of helping it with the network onboarding process. But there are no mutual security relationships configured on the querying device and its neighbor devices at the time it performs the early discovery. These relationships are configured later in the process based on secure device identities. Alternatively, a new device to be onboarded may wait for advertisements of nearby devices able to help it do the network onboarding process. Also in this case, these messages cannot be secured initially because the new device does not yet have any security relationship configured with devices that are already a member of the network. See <span>[<a href="#I-D.ietf-anima-constrained-voucher" class="cite xref">I-D.ietf-anima-constrained-voucher</a>]</span> for an example of an onboarding protocol that can use CoAP multicast for early link-local discovery.<a href="#section-6.1-4" class="pilcrow">¶</a></p>
-<p id="section-6.1-5">As a further example, the NoSec mode may be useful in simple applications that neither involve nor may have an impact on sensitive data and personal information. These include, e.g., read-only temperature sensors deployed in an environment where a client reads temperature values but does not use this data to control actuators or to perform other automated actions.<a href="#section-6.1-5" class="pilcrow">¶</a></p>
+<p id="section-6.1-5">As a further example, the NoSec mode may be useful and acceptable in simple read-only applications that do not involve, impact, or disclose sensitive data and personal information. These include, e.g., read-only temperature sensors deployed in a public gathering environment, where unauthenticated clients retrieve temperature values but do not use this data to control actuators or to perform other automated actions.<a href="#section-6.1-5" class="pilcrow">¶</a></p>
 <p id="section-6.1-6">In the exception cases where NoSec mode is used, high-volume and harmful amplifications need to be prevented through appropriate and conservative device configurations: taking the early discovery query as an example, only a few CoAP servers are expected to be configured for responding to multicast group requests that are sent for discovery. And the time window during which such unsecured requests are accepted, can be limited as well. Furthermore, the scope is also limited: only link-local requests are accepted.<a href="#section-6.1-6" class="pilcrow">¶</a></p>
 <p id="section-6.1-7">Except for the class of applications discussed above, and all the more so in applications that obviously have hard security requirements (e.g., health monitoring systems and alarm monitoring systems), CoAP group communication <span class="bcp14">MUST NOT</span> be used in NoSec mode.<a href="#section-6.1-7" class="pilcrow">¶</a></p>
 </section>

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

@@ -2315,12 +2315,13 @@ Table of Contents
    [I-D.ietf-anima-constrained-voucher] for an example of an onboarding
    protocol that can use CoAP multicast for early link-local discovery.
 
-   As a further example, the NoSec mode may be useful in simple
-   applications that neither involve nor may have an impact on sensitive
-   data and personal information.  These include, e.g., read-only
-   temperature sensors deployed in an environment where a client reads
-   temperature values but does not use this data to control actuators or
-   to perform other automated actions.
+   As a further example, the NoSec mode may be useful and acceptable in
+   simple read-only applications that do not involve, impact, or
+   disclose sensitive data and personal information.  These include,
+   e.g., read-only temperature sensors deployed in a public gathering
+   environment, where unauthenticated clients retrieve temperature
+   values but do not use this data to control actuators or to perform
+   other automated actions.
 
    In the exception cases where NoSec mode is used, high-volume and
    harmful amplifications need to be prevented through appropriate and