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

core-wg · Sep 5, 2024 · 857f2f0 · 857f2f0
1 parent 3114c37
commit 857f2f0
Show file tree

Hide file tree

Showing 2 changed files with 24 additions and 17 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
@@ -1966,7 +1966,7 @@ <h4 id="name-group-creation-and-membersh">
           </h4>
 <p id="section-2.2.2-1">To create a CoAP group, a configuring entity defines an IP multicast address (or hostname) for the group and optionally a UDP port number in case it differs from the default CoAP port number 5683. Then, it configures one or more devices as listeners to that IP multicast address, with a CoAP endpoint listening on the CoAP group's associated UDP port. These endpoints/devices are the group members.<a href="#section-2.2.2-1" class="pilcrow">¶</a></p>
 <p id="section-2.2.2-2">The configuring entity can be, for example, a local application with pre-configuration, a user, a software developer, a cloud service, or a local commissioning tool. Also, the devices sending CoAP requests to the CoAP group in the role of CoAP client need to be configured with the same information, even though they are not necessarily group members. One way to configure a client is to supply it with a group URI.<a href="#section-2.2.2-2" class="pilcrow">¶</a></p>
-<p id="section-2.2.2-3">The IETF does not define a mandatory protocol to accomplish CoAP group creation. <span>[<a href="#RFC7390" class="cite xref">RFC7390</a>]</span> defined an experimental protocol for configuring memberships of CoAP groups for unsecured group communication, based on JSON-formatted configuration resources, and the experiment is concluded. For IPv6 CoAP groups, common multicast address ranges that are used to configure group addresses from are ff1x::/16 and ff3x::/16.<a href="#section-2.2.2-3" class="pilcrow">¶</a></p>
+<p id="section-2.2.2-3">The IETF does not define a mandatory protocol to accomplish CoAP group creation. <span>[<a href="#RFC7390" class="cite xref">RFC7390</a>]</span> defined an experimental protocol for configuring memberships of CoAP groups for unsecured group communication, based on JSON-formatted configuration resources. The experiment is concluded as showing that the protocol has not been considered for deployment and use. For IPv6 CoAP groups, common multicast address ranges that are used to configure group addresses from are ff1x::/16 and ff3x::/16.<a href="#section-2.2.2-3" class="pilcrow">¶</a></p>
 <p id="section-2.2.2-4">To create an application group, a configuring entity may configure a resource (name) or a set of resources on CoAP endpoints, such that a CoAP request sent to a group URI by a configured CoAP client will be processed by one or more CoAP servers that have the matching URI path configured. These servers are the members of the application group.<a href="#section-2.2.2-4" class="pilcrow">¶</a></p>
 <p id="section-2.2.2-5">To create a security group, a configuring entity defines an initial subset of the related security material. This comprises a set of group properties including the cryptographic algorithms and parameters used in the security group, as well as additional information relevant throughout the group life-cycle, such as the security group name and description. This task <span class="bcp14">MAY</span> be entrusted to a dedicated administrator, that interacts with a Group Manager as defined in <a href="#chap-oscore" class="auto internal xref">Section 5</a>. After that, further security materials to protect group communications have to be generated, compatible with the configuration specified for the security group.<a href="#section-2.2.2-5" class="pilcrow">¶</a></p>
 <p id="section-2.2.2-6">To participate in a security group, CoAP endpoints have to be configured with the group security material used to protect communications in the associated application/CoAP groups. The part of the process that involves secure distribution of group security material <span class="bcp14">MAY</span> use standardized communication with a Group Manager as defined in <a href="#chap-oscore" class="auto internal xref">Section 5</a>.<a href="#section-2.2.2-6" class="pilcrow">¶</a></p>
@@ -4308,40 +4308,43 @@ <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 that rt=g.&lt;GROUPTYPE&gt; is used just as an example.<a href="#appendix-E.1-1.1.1" class="pilcrow">¶</a></p>
+            <p id="appendix-E.1-1.1.1">Clarified outcome of the RFC 7390 experiment on group membership configuration protocol.<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">Made RFC 7967 a normative reference.<a href="#appendix-E.1-1.2.1" class="pilcrow">¶</a></p>
+            <p id="appendix-E.1-1.2.1">Clarified that rt=g.&lt;GROUPTYPE&gt; is used just as an example.<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">Generalized resending of a group request with different Message ID.<a href="#appendix-E.1-1.3.1" class="pilcrow">¶</a></p>
+            <p id="appendix-E.1-1.3.1">Made RFC 7967 a normative reference.<a href="#appendix-E.1-1.3.1" class="pilcrow">¶</a></p>
 </li>
           <li class="normal" id="appendix-E.1-1.4">
-            <p id="appendix-E.1-1.4.1">Switched <span class="bcp14">SHOULD</span> to <span class="bcp14">MAY</span> on changing port number from group request to response.<a href="#appendix-E.1-1.4.1" class="pilcrow">¶</a></p>
+            <p id="appendix-E.1-1.4.1">Generalized resending of a group request with different Message ID.<a href="#appendix-E.1-1.4.1" class="pilcrow">¶</a></p>
 </li>
           <li class="normal" id="appendix-E.1-1.5">
-            <p id="appendix-E.1-1.5.1">Further generalized the handling of multiple responses from the same server to the same request.<a href="#appendix-E.1-1.5.1" class="pilcrow">¶</a></p>
+            <p id="appendix-E.1-1.5.1">Switched <span class="bcp14">SHOULD</span> to <span class="bcp14">MAY</span> on changing port number from group request to response.<a href="#appendix-E.1-1.5.1" class="pilcrow">¶</a></p>
 </li>
           <li class="normal" id="appendix-E.1-1.6">
-            <p id="appendix-E.1-1.6.1">Clarifications on response suppression.<a href="#appendix-E.1-1.6.1" class="pilcrow">¶</a></p>
+            <p id="appendix-E.1-1.6.1">Further generalized the handling of multiple responses from the same server to the same request.<a href="#appendix-E.1-1.6.1" class="pilcrow">¶</a></p>
 </li>
           <li class="normal" id="appendix-E.1-1.7">
-            <p id="appendix-E.1-1.7.1">Mentioned PROBING_RATE as a means to enforce congestion control.<a href="#appendix-E.1-1.7.1" class="pilcrow">¶</a></p>
+            <p id="appendix-E.1-1.7.1">Clarifications on response suppression.<a href="#appendix-E.1-1.7.1" class="pilcrow">¶</a></p>
 </li>
           <li class="normal" id="appendix-E.1-1.8">
-            <p id="appendix-E.1-1.8.1">Consideration on how eventual consistency from Observe compensates for lost notifications.<a href="#appendix-E.1-1.8.1" class="pilcrow">¶</a></p>
+            <p id="appendix-E.1-1.8.1">Mentioned PROBING_RATE as a means to enforce congestion control.<a href="#appendix-E.1-1.8.1" class="pilcrow">¶</a></p>
 </li>
           <li class="normal" id="appendix-E.1-1.9">
-            <p id="appendix-E.1-1.9.1">Admitted resource retrieval through consecutive group requests with the Block2 Option.<a href="#appendix-E.1-1.9.1" class="pilcrow">¶</a></p>
+            <p id="appendix-E.1-1.9.1">Consideration on how eventual consistency from Observe compensates for lost notifications.<a href="#appendix-E.1-1.9.1" class="pilcrow">¶</a></p>
 </li>
           <li class="normal" id="appendix-E.1-1.10">
-            <p id="appendix-E.1-1.10.1">Clarified relation with TCP/TLS/WebSockets.<a href="#appendix-E.1-1.10.1" class="pilcrow">¶</a></p>
+            <p id="appendix-E.1-1.10.1">Admitted resource retrieval through consecutive group requests with the Block2 Option.<a href="#appendix-E.1-1.10.1" class="pilcrow">¶</a></p>
 </li>
           <li class="normal" id="appendix-E.1-1.11">
-            <p id="appendix-E.1-1.11.1">Clarified security on the different legs with a proxy.<a href="#appendix-E.1-1.11.1" class="pilcrow">¶</a></p>
+            <p id="appendix-E.1-1.11.1">Clarified relation with TCP/TLS/WebSockets.<a href="#appendix-E.1-1.11.1" class="pilcrow">¶</a></p>
 </li>
           <li class="normal" id="appendix-E.1-1.12">
-            <p id="appendix-E.1-1.12.1">Editorial improvements.<a href="#appendix-E.1-1.12.1" class="pilcrow">¶</a></p>
+            <p id="appendix-E.1-1.12.1">Clarified security on the different legs with a proxy.<a href="#appendix-E.1-1.12.1" class="pilcrow">¶</a></p>
+</li>
+          <li class="normal" id="appendix-E.1-1.13">
+            <p id="appendix-E.1-1.13.1">Editorial improvements.<a href="#appendix-E.1-1.13.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
@@ -791,10 +791,11 @@ Table of Contents
    The IETF does not define a mandatory protocol to accomplish CoAP
    group creation.  [RFC7390] defined an experimental protocol for
    configuring memberships of CoAP groups for unsecured group
-   communication, based on JSON-formatted configuration resources, and
-   the experiment is concluded.  For IPv6 CoAP groups, common multicast
-   address ranges that are used to configure group addresses from are
-   ff1x::/16 and ff3x::/16.
+   communication, based on JSON-formatted configuration resources.  The
+   experiment is concluded as showing that the protocol has not been
+   considered for deployment and use.  For IPv6 CoAP groups, common
+   multicast address ranges that are used to configure group addresses
+   from are ff1x::/16 and ff3x::/16.
 
    To create an application group, a configuring entity may configure a
    resource (name) or a set of resources on CoAP endpoints, such that a
@@ -3950,6 +3951,9 @@ Appendix E.  Document Updates
 
 E.1.  Version -11 to -12
 
+   *  Clarified outcome of the RFC 7390 experiment on group membership
+      configuration protocol.
+
    *  Clarified that rt=g.<GROUPTYPE> is used just as an example.
 
    *  Made RFC 7967 a normative reference.