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

aarongable-patch-1/draft-ietf-acme-ari.html

@@ -1048,7 +1048,7 @@
 </tr></thead>
 <tfoot><tr>
 <td class="left">Gable</td>
-<td class="center">Expires 14 June 2025</td>
+<td class="center">Expires 19 June 2025</td>
 <td class="right">[Page]</td>
 </tr></tfoot>
 </table>
@@ -1061,12 +1061,12 @@
 <dd class="internet-draft">draft-ietf-acme-ari-latest</dd>
 <dt class="label-published">Published:</dt>
 <dd class="published">
-<time datetime="2024-12-11" class="published">11 December 2024</time>
+<time datetime="2024-12-16" class="published">16 December 2024</time>
     </dd>
 <dt class="label-intended-status">Intended Status:</dt>
 <dd class="intended-status">Standards Track</dd>
 <dt class="label-expires">Expires:</dt>
-<dd class="expires"><time datetime="2025-06-14">14 June 2025</time></dd>
+<dd class="expires"><time datetime="2025-06-19">19 June 2025</time></dd>
 <dt class="label-authors">Author:</dt>
 <dd class="authors">
 <div class="author">
@@ -1107,7 +1107,7 @@ <h2 id="name-status-of-this-memo">
         time. It is inappropriate to use Internet-Drafts as reference
         material or to cite them other than as "work in progress."<a href="#section-boilerplate.1-3" class="pilcrow">¶</a></p>
 <p id="section-boilerplate.1-4">
-        This Internet-Draft will expire on 14 June 2025.<a href="#section-boilerplate.1-4" class="pilcrow">¶</a></p>
+        This Internet-Draft will expire on 19 June 2025.<a href="#section-boilerplate.1-4" class="pilcrow">¶</a></p>
 </section>
 </div>
 <div id="copyright">
@@ -1396,7 +1396,7 @@ <h4 id="name-error-handling">
 </li>
             <li class="compact" id="section-4.3.3-2.2">Request timeout<a href="#section-4.3.3-2.2" class="pilcrow">¶</a>
 </li>
-            <li class="compact" id="section-4.3.3-2.3">5xx HTTP errors.<a href="#section-4.3.3-2.3" class="pilcrow">¶</a>
+            <li class="compact" id="section-4.3.3-2.3">5xx HTTP errors<a href="#section-4.3.3-2.3" class="pilcrow">¶</a>
 </li>
           </ul>
 <p id="section-4.3.3-3">On receiving a temporary error, clients SHOULD do exponential backoff with a capped number of tries. If all tries are exhausted, clients SHOULD treat the request as a long-term error.<a href="#section-4.3.3-3" class="pilcrow">¶</a></p>
@@ -1471,7 +1471,7 @@ <h2 id="name-security-considerations">
       </h2>
 <p id="section-6-1">The extensions to the ACME protocol described in this document builds upon the Security Considerations and threat model defined in <span>[<a href="#RFC8555" class="cite xref">RFC8555</a>]</span>, Section 10.1.<a href="#section-6-1" class="pilcrow">¶</a></p>
 <p id="section-6-2">This document specifies that <code>renewalInfo</code> resources <span class="bcp14">MUST</span> be exposed and accessed via unauthenticated GET requests, a departure from RFC8555's requirement that clients must send POST-as-GET requests to fetch resources from the server. This is because the information contained in <code>renewalInfo</code> resources is not considered confidential, and because allowing <code>renewalInfo</code> to be easily cached is advantageous to shed the load from clients which do not respect the Retry-After header. As always, servers should take measures to ensure that unauthenticated requests for renewal information cannot result in denial-of-service attacks. These measures might include ensuring that a cache does not include superfluous request headers or query parameters in its cache key, instituting IP-based rate limits, or other general best-practice measures.<a href="#section-6-2" class="pilcrow">¶</a></p>
-<p id="section-6-3">Note that this protocol could exhibit undesired behavior in the presence of significant clock skew between the ACME client and server. For example, if a server places the suggested renewal window wholly in the past to encourage a client to renew immediately, a client with a sufficiently slow clock might nonetheless see the window as being in the future. Similarly, a server which wishes to schedule renewals very precisely may have difficulty doing so if some clients have skewed clocks (or do no implement ARI at all). Server operators should take this concern into account when setting suggested renewal windows. However, many other protocols (including TLS handshakes themselves) fall apart with sufficient clock skew, so this is not seen as a particular hindrance to this protocol.<a href="#section-6-3" class="pilcrow">¶</a></p>
+<p id="section-6-3">Note that this protocol could exhibit undesired behavior in the presence of significant clock skew between the ACME client and server. For example, if a server places the suggested renewal window wholly in the past to encourage a client to renew immediately, a client with a sufficiently slow clock might nonetheless see the window as being in the future. Similarly, a server which wishes to schedule renewals very precisely may have difficulty doing so if some clients have skewed clocks (or do no implement ARI at all). Server operators should take this concern into account when setting suggested renewal windows. However, many other protocols (including TLS handshakes themselves) fall apart with sufficient clock skew, so this is not unique to this protocol.<a href="#section-6-3" class="pilcrow">¶</a></p>
 </section>
 </div>
 <div id="iana-considerations">

aarongable-patch-1/draft-ietf-acme-ari.txt

@@ -4,8 +4,8 @@
 
 ACME Working Group                                              A. Gable
 Internet-Draft                          Internet Security Research Group
-Intended status: Standards Track                        11 December 2024
-Expires: 14 June 2025
+Intended status: Standards Track                        16 December 2024
+Expires: 19 June 2025
 
 
 Automated Certificate Management Environment (ACME) Renewal Information
@@ -53,7 +53,7 @@ Status of This Memo
    time.  It is inappropriate to use Internet-Drafts as reference
    material or to cite them other than as "work in progress."
 
-   This Internet-Draft will expire on 14 June 2025.
+   This Internet-Draft will expire on 19 June 2025.
 
 Copyright Notice
 
@@ -324,7 +324,7 @@ Table of Contents
 
    *  Connection timeout
    *  Request timeout
-   *  5xx HTTP errors.
+   *  5xx HTTP errors
 
    On receiving a temporary error, clients SHOULD do exponential backoff
    with a capped number of tries.  If all tries are exhausted, clients
@@ -439,7 +439,7 @@ Table of Contents
    operators should take this concern into account when setting
    suggested renewal windows.  However, many other protocols (including
    TLS handshakes themselves) fall apart with sufficient clock skew, so
-   this is not seen as a particular hindrance to this protocol.
+   this is not unique to this protocol.
 
 7.  IANA Considerations
 

index.html

@@ -37,7 +37,7 @@ <h2>Preview for branch <a href="aarongable-patch-1">aarongable-patch-1</a></h2>
       <tr>
         <td><a href="aarongable-patch-1/draft-ietf-acme-ari.html" class="html draft-ietf-acme-ari" title="Automated Certificate Management Environment (ACME) Renewal Information (ARI) Extension (HTML)">ACME ARI</a></td>
         <td><a href="aarongable-patch-1/draft-ietf-acme-ari.txt" class="txt draft-ietf-acme-ari" title="Automated Certificate Management Environment (ACME) Renewal Information (ARI) Extension (Text)">plain text</a></td>
-        <td>same as main</td>
+        <td><a href="https://author-tools.ietf.org/api/iddiff?url_1=https://aarongable.github.io/draft-acme-ari/draft-ietf-acme-ari.txt&amp;url_2=https://aarongable.github.io/draft-acme-ari/aarongable-patch-1/draft-ietf-acme-ari.txt" class="diff draft-ietf-acme-ari">diff with main</a></td>
       </tr>
     </table>
     <h2>Preview for branch <a href="tsvart-comments">tsvart-comments</a></h2>