On Mon, Jul 22, 2024 at 04:20:39PM -0400, Paul Wouters wrote: > On Mon, 22 Jul 2024, RFC Errata System wrote: > > > Subject: [IPsec] [Technical Errata Reported] RFC9347 (8042) > > > > The following errata report has been submitted for RFC9347, > > "Aggregation and Fragmentation Mode for Encapsulating Security Payload > > (ESP) and Its Use for IP Traffic Flow Security (IP-TFS)". > > > > -------------------------------------- > > You may review the report below and at: > > https://www.rfc-editor.org/errata/eid8042 > > > > -------------------------------------- > > Type: Technical > > Reported by: Antony Antony <antony.ant...@secunet.com> > > > > Section: 7.2 > > > > Original Text > > ------------- > > 3-255 Unassigned > > > > Corrected Text > > -------------- > > 2-255 Unassigned > > > > Notes > > ----- > > The same section, in the previous line, states "1 Congestion Control > > Format RFC 9347" so 2 is not covered in the registry. It's likely > > meant to be "Unassigned"? > > While true, I would be tempted to reject this errata because this list > is not meant to be correct over time anyway, when other documents > register things in the registry anyway. > > Especially since technical errata show up prominently at the datatracker > and this is not something that implementers really do need to be warned > about.
I filed the errata to update the IANA registry. Maybe I should have mentioned it. https://www.iana.org/assignments/esp-aggfrag-payload/esp-aggfrag-payload.xhtml Once this is updated I can request next available number, 2, for Encrypted ESP Ping. -antony _______________________________________________ IPsec mailing list -- ipsec@ietf.org To unsubscribe send an email to ipsec-le...@ietf.org
