Script updating gh-pages from 386ec0a. [ci skip]

Author: ID Bot

draft-ietf-ace-key-groupcomm.html

@@ -1487,7 +1487,7 @@ <h2 id="name-introduction">
 <p id="section-1-3">In particular, this document defines the operations and interface available at the KDC, as well as general message formats for the interactions between Clients and KDC. At the same time, communications in the group can rely on different approaches, e.g., based on multicast <span>[<a href="#I-D.ietf-core-groupcomm-bis" class="cite xref">I-D.ietf-core-groupcomm-bis</a>]</span> or on publish-subscribe messaging <span>[<a href="#I-D.ietf-core-coap-pubsub" class="cite xref">I-D.ietf-core-coap-pubsub</a>]</span>, and can be protected in different ways.<a href="#section-1-3" class="pilcrow">¶</a></p>
 <p id="section-1-4">Therefore, this document delegates details on the communication and security approaches used in a group to separate application profiles. These are specialized instances of this document, targeting a particular group communication approach and defining how communications in the group are protected, as well as the specific keying material and configuration parameters provided to group members.<a href="#section-1-4" class="pilcrow">¶</a></p>
 <p id="section-1-5">In order to ensure consistency and aid the development of such application profiles, <a href="#req" class="auto internal xref">Appendix A</a> of this document defines a number of related compliance requirements. In particular, <a href="#req-mandatory" class="auto internal xref">Appendix A.1</a> compiles the requirements that application profiles are REQUIRED to fulfill; these are referred to by an identifier that starts with "REQ". Instead, <a href="#req-optional" class="auto internal xref">Appendix A.2</a> compiles the requirements that application profiles MAY fulfill; these are referred to by an identifier that starts with "OPT".<a href="#section-1-5" class="pilcrow">¶</a></p>
-<p id="section-1-6">New keying material is generated and distributed to the group upon membership changes (rekeying), if the application requires backward security (i.e., new group members must be prevented from accessing communications in the group prior to their joining) and forward security (i.e., former group members must be prevented from accessing communications in the group after their leaving).<a href="#section-1-6" class="pilcrow">¶</a></p>
+<p id="section-1-6">New keying material is intended to be generated and distributed to the group upon membership changes (rekeying). If the application requires backward security (i.e., new group members must be prevented from accessing communications in the group prior to their joining), then a rekeying has to occur every time new members join the group. If the application requires forward security (i.e., former group members must be prevented from accessing communications in the group after their leaving), then a rekeying has to occur every time current members leave the group or are evicted from the group.<a href="#section-1-6" class="pilcrow">¶</a></p>
 <p id="section-1-7">A group rekeying scheme performs the actual distribution of the new keying material, by rekeying the current group members when a new Client joins the group, and the remaining group members when a Client leaves the group. This can rely on different approaches, including efficient group rekeying schemes such as <span>[<a href="#RFC2093" class="cite xref">RFC2093</a>]</span>, <span>[<a href="#RFC2094" class="cite xref">RFC2094</a>]</span>, and <span>[<a href="#RFC2627" class="cite xref">RFC2627</a>]</span>.<a href="#section-1-7" class="pilcrow">¶</a></p>
 <p id="section-1-8">Consistently with what is recommended in the ACE framework, this document uses CBOR <span>[<a href="#RFC8949" class="cite xref">RFC8949</a>]</span> for data encoding. However, using JSON <span>[<a href="#RFC8259" class="cite xref">RFC8259</a>]</span> instead of CBOR is possible, by relying on the conversion method specified in Sections <a href="https://rfc-editor.org/rfc/rfc8949#section-6.1" class="relref">6.1</a> and <a href="https://rfc-editor.org/rfc/rfc8949#section-6.2" class="relref">6.2</a> of <span>[<a href="#RFC8949" class="cite xref">RFC8949</a>]</span>.<a href="#section-1-8" class="pilcrow">¶</a></p>
 <div id="terminology">
@@ -5646,7 +5646,7 @@ <h3 id="name-version-00-to-01">
       <h2 id="name-acknowledgments">
 <a href="#name-acknowledgments" class="section-name selfRef">Acknowledgments</a>
       </h2>
-<p id="appendix-D-1">The following individuals were helpful in shaping this document: <span class="contact-name">Christian Amsüss</span>, <span class="contact-name">Carsten Bormann</span>, <span class="contact-name">Roman Danyliw</span>, <span class="contact-name">Martin Duke</span>, <span class="contact-name">Thomas Fossati</span>, <span class="contact-name">Vidhi Goel</span>, <span class="contact-name">Rikard Höglund</span>, <span class="contact-name">Ben Kaduk</span>, <span class="contact-name">Erik Kline</span>, <span class="contact-name">Watson Ladd</span>, <span class="contact-name">John Preuß Mattsson</span>, <span class="contact-name">Daniel Migault</span>, <span class="contact-name">Zaheduzzaman Sarker</span>, <span class="contact-name">Jim Schaad</span>, <span class="contact-name">Ludwig Seitz</span>, <span class="contact-name">Göran Selander</span>, <span class="contact-name">Cigdem Sengul</span>, <span class="contact-name">Henry Thompson</span>, <span class="contact-name">Peter van der Stok</span>, and <span class="contact-name">Paul Wouters</span>.<a href="#appendix-D-1" class="pilcrow">¶</a></p>
+<p id="appendix-D-1">The following individuals were helpful in shaping this document: <span class="contact-name">Christian Amsüss</span>, <span class="contact-name">Carsten Bormann</span>, <span class="contact-name">Roman Danyliw</span>, <span class="contact-name">Martin Duke</span>, <span class="contact-name">Thomas Fossati</span>, <span class="contact-name">Vidhi Goel</span>, <span class="contact-name">Rikard Höglund</span>, <span class="contact-name">Ben Kaduk</span>, <span class="contact-name">Erik Kline</span>, <span class="contact-name">Warren Kumari</span>, <span class="contact-name">Watson Ladd</span>, <span class="contact-name">John Preuß Mattsson</span>, <span class="contact-name">Daniel Migault</span>, <span class="contact-name">Zaheduzzaman Sarker</span>, <span class="contact-name">Jim Schaad</span>, <span class="contact-name">Ludwig Seitz</span>, <span class="contact-name">Göran Selander</span>, <span class="contact-name">Cigdem Sengul</span>, <span class="contact-name">Henry Thompson</span>, <span class="contact-name">Peter van der Stok</span>, and <span class="contact-name">Paul Wouters</span>.<a href="#appendix-D-1" class="pilcrow">¶</a></p>
 <p id="appendix-D-2">The work on this document has been partly supported by VINNOVA and the Celtic-Next project CRITISEC; by the H2020 project SIFIS-Home (Grant agreement 952652); and by the EIT-Digital High Impact Initiative ACTIVE.<a href="#appendix-D-2" class="pilcrow">¶</a></p>
 </section>
 </div>

draft-ietf-ace-key-groupcomm.txt

@@ -205,12 +205,15 @@ Table of Contents
    application profiles MAY fulfill; these are referred to by an
    identifier that starts with "OPT".
 
-   New keying material is generated and distributed to the group upon
-   membership changes (rekeying), if the application requires backward
-   security (i.e., new group members must be prevented from accessing
-   communications in the group prior to their joining) and forward
-   security (i.e., former group members must be prevented from accessing
-   communications in the group after their leaving).
+   New keying material is intended to be generated and distributed to
+   the group upon membership changes (rekeying).  If the application
+   requires backward security (i.e., new group members must be prevented
+   from accessing communications in the group prior to their joining),
+   then a rekeying has to occur every time new members join the group.
+   If the application requires forward security (i.e., former group
+   members must be prevented from accessing communications in the group
+   after their leaving), then a rekeying has to occur every time current
+   members leave the group or are evicted from the group.
 
    A group rekeying scheme performs the actual distribution of the new
    keying material, by rekeying the current group members when a new
@@ -5589,10 +5592,10 @@ Acknowledgments
 
    The following individuals were helpful in shaping this document:
    Christian Amsüss, Carsten Bormann, Roman Danyliw, Martin Duke, Thomas
-   Fossati, Vidhi Goel, Rikard Höglund, Ben Kaduk, Erik Kline, Watson
-   Ladd, John Preuß Mattsson, Daniel Migault, Zaheduzzaman Sarker, Jim
-   Schaad, Ludwig Seitz, Göran Selander, Cigdem Sengul, Henry Thompson,
-   Peter van der Stok, and Paul Wouters.
+   Fossati, Vidhi Goel, Rikard Höglund, Ben Kaduk, Erik Kline, Warren
+   Kumari, Watson Ladd, John Preuß Mattsson, Daniel Migault,
+   Zaheduzzaman Sarker, Jim Schaad, Ludwig Seitz, Göran Selander, Cigdem
+   Sengul, Henry Thompson, Peter van der Stok, and Paul Wouters.
 
    The work on this document has been partly supported by VINNOVA and
    the Celtic-Next project CRITISEC; by the H2020 project SIFIS-Home

index.html

@@ -45,7 +45,7 @@ <h2>Preview for branch <a href="warren-kumari-review">warren-kumari-review</a></
       <tr>
         <td><a href="warren-kumari-review/draft-ietf-ace-key-groupcomm.html" class="html draft-ietf-ace-key-groupcomm" title="Key Provisioning for Group Communication using ACE (HTML)">Key Provisioning for Group Communication</a></td>
         <td><a href="warren-kumari-review/draft-ietf-ace-key-groupcomm.txt" class="txt draft-ietf-ace-key-groupcomm" title="Key Provisioning for Group Communication using ACE (Text)">plain text</a></td>
-        <td><a href="https://author-tools.ietf.org/api/iddiff?url_1=https://ace-wg.github.io/ace-key-groupcomm/draft-ietf-ace-key-groupcomm.txt&amp;url_2=https://ace-wg.github.io/ace-key-groupcomm/warren-kumari-review/draft-ietf-ace-key-groupcomm.txt" class="diff draft-ietf-ace-key-groupcomm">diff with master</a></td>
+        <td>same as master</td>
       </tr>
     </table>
     <h2>Preview for branch <a href="iana-reviews">iana-reviews</a></h2>
@@ -69,7 +69,7 @@ <h2>Preview for branch <a href="martin-duke-review">martin-duke-review</a></h2>
       <tr>
         <td><a href="martin-duke-review/draft-ietf-ace-key-groupcomm.html" class="html draft-ietf-ace-key-groupcomm" title="Key Provisioning for Group Communication using ACE (HTML)">Key Provisioning for Group Communication</a></td>
         <td><a href="martin-duke-review/draft-ietf-ace-key-groupcomm.txt" class="txt draft-ietf-ace-key-groupcomm" title="Key Provisioning for Group Communication using ACE (Text)">plain text</a></td>
-        <td>same as master</td>
+        <td><a href="https://author-tools.ietf.org/api/iddiff?url_1=https://ace-wg.github.io/ace-key-groupcomm/draft-ietf-ace-key-groupcomm.txt&amp;url_2=https://ace-wg.github.io/ace-key-groupcomm/martin-duke-review/draft-ietf-ace-key-groupcomm.txt" class="diff draft-ietf-ace-key-groupcomm">diff with master</a></td>
       </tr>
     </table>
     <h2>Preview for branch <a href="erik-kline-review">erik-kline-review</a></h2>