deploy: 786a4c3

Author: klassert

draft-ietf-ipsecme-eesp-latest.html

@@ -1223,11 +1223,11 @@
 <thead><tr>
 <td class="left">Internet-Draft</td>
 <td class="center">EESP</td>
-<td class="right">July 2025</td>
+<td class="right">August 2025</td>
 </tr></thead>
 <tfoot><tr>
 <td class="left">Klassert, et al.</td>
-<td class="center">Expires 10 January 2026</td>
+<td class="center">Expires 2 February 2026</td>
 <td class="right">[Page]</td>
 </tr></tfoot>
 </table>
@@ -1238,12 +1238,12 @@
 <dd class="workgroup">IPSECME Working Group</dd>
 <dt class="label-published">Published:</dt>
 <dd class="published">
-<time datetime="2025-07-09" class="published">9 July 2025</time>
+<time datetime="2025-08-01" class="published">1 August 2025</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="2026-01-10">10 January 2026</time></dd>
+<dd class="expires"><time datetime="2026-02-02">2 February 2026</time></dd>
 <dt class="label-authors">Authors:</dt>
 <dd class="authors">
 <div class="author">
@@ -1295,7 +1295,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 10 January 2026.<a href="#section-boilerplate.1-4" class="pilcrow">¶</a></p>
+        This Internet-Draft will expire on 2 February 2026.<a href="#section-boilerplate.1-4" class="pilcrow">¶</a></p>
 </section>
 </div>
 <div id="copyright">
@@ -1794,9 +1794,7 @@ <h4 id="name-fixed-base-header">
             <dt id="section-2.2.1-6.1">Packet Format (F)</dt>
             <dd style="margin-left: 1.5em" id="section-2.2.1-6.2">
               <p id="section-2.2.1-6.2.1">1 bit: Set to zero for full EESP packet Format (i.e., the EESP header includes the
-'<code>Payload Info Header</code>'), set to 1 for Optimized EESP Packet format. This bit
-MAY be only set to 1 if the Crypt Offset is positive. It MUST be set to
-0 otherwise.<a href="#section-2.2.1-6.2.1" class="pilcrow">¶</a></p>
+'<code>Payload Info Header</code>'), set to 1 for Optimized EESP Packet format.<a href="#section-2.2.1-6.2.1" class="pilcrow">¶</a></p>
 </dd>
             <dd class="break"></dd>
 <dt id="section-2.2.1-6.3">Reserved (RR)</dt>
@@ -2036,18 +2034,8 @@ <h3 id="name-padding-for-encryption">
 requirements noted above, but all implementations MUST support
 generation and consumption of padding.<a href="#section-2.6-3" class="pilcrow">¶</a></p>
 <p id="section-2.6-4">If Padding bytes are needed but the algorithm does not
-specify the padding contents, then the following default processing
-MUST be used.  The default processing follows exactly ESP as of <span>[<a href="#RFC4303" class="cite xref">RFC4303</a>]</span>.
-The Padding bytes are initialized with a series of
-(unsigned, 1-byte) integer values.  The first padding byte appended
-to the plaintext is numbered 1, with subsequent padding bytes making
-up a monotonically increasing sequence: 1, 2, 3, ....  When this
-padding scheme is employed, the receiver SHOULD inspect the Padding
-field.  (This scheme was selected because of its relative simplicity,
-ease of implementation in hardware, and because it offers limited
-protection against certain forms of "cut and paste" attacks in the
-absence of other integrity measures, if the receiver checks the
-padding values upon decryption.)<a href="#section-2.6-4" class="pilcrow">¶</a></p>
+specify the padding contents, then the Padding bytes
+MUST be set to 0.<a href="#section-2.6-4" class="pilcrow">¶</a></p>
 <p id="section-2.6-5">If an algorithm imposes constraints on
 the values of the bytes used for padding, they MUST be specified by
 the RFC defining how the algorithm is employed with EESP.  If the