I went through all reported errata, and here is my take on them. It seems that if we mark errata as "verified" then it will get inline fixes for the rfc by the rfc-editor, but if we mark it as hold for document update we do not... I think most of those could also be hold for document update, but if we get the inline fixes by marking them as just "verified" then even better...
Actually some of those held for document update errata could also be useful to be inlined... Especially for documents which are not yet obsoleted ( RFC2104, RFC4301, RFC4302, and RFC4303). Actually there should be new state which is "Was Held for Document Update, Document was already updated, and errata was incorporated"... -- https://www.rfc-editor.org/errata/eid6388 This simple typo in RFC2408 (ISAKMP), should be verified. Status: Verified -- https://www.rfc-editor.org/errata/eid4936 This is incorrect errata to the RFC3947 (IKEv1 NAT-T negotiation). It asks to change where initiator MUST send NAT-OA payloads if it proposes any UDP-Encapsulation mode, compared to the proposing EDP-Encapsulated-Transport mode. The original text is correct, we only need to send NAT-OA payloads if UDP-Encapsulated-Transport mode is proposed, it is not required if only UDP-Encapsulated-Tunnel mode is proposed. So this errata should be rejected. Status: Rejected -- https://www.rfc-editor.org/errata/eid4937 Simple typo fix in RFC3947 (IKEv1 NAT-T negotiation) changing "source IP and port address" to "source IP and port number". So verified. Status: Verified -- https://www.rfc-editor.org/errata/eid4709 By checking the ASN1 code in the RFC4301 (IPsec architecture) it seems to already have the changes that are listed in the errata. The ASN.1 mostly matches the one in the corrected text except RFC4301 still uses parameters ANY -- DEFINED BY algorithm} -- defined outside -- of this document for AES modes. not the one in the corrected text which has version: parameters ANY } -- defined outside -- of this document for AES modes. I think the one in the RFC4301 is correct, so I think this errata should be rejected. Status: Rejected. -- https://www.rfc-editor.org/errata/eid6559 This is updating the figure in RFC4303 (ESP) and I think the errata should be set to verified, as I think we should use "updated IP hdr" instead of "orig IP header", as we do in fact modify the protocol, total length and checksum fields. In the document update we most likely want to add text explaining which fields are updated like what is done in the RFC3948: The Total Length, Protocol, and Header Checksum (for IPv4) fields in the IP header are edited to match the resulting IP packet. As we are still using ESP, we might want to make a RFC4303bis at some point and this change should be made then. Perhaps we should think about moving it from proposed standard to internet standard at one point. Status: Verified -- https://www.rfc-editor.org/errata/eid4798 Fixing wrong reference in the RFC4303 (ESP) from 2.4 to 2.7 when talking about the transport flow confidentiality. Status: Verified -- https://www.rfc-editor.org/errata/eid4799 Fixing wrong reference in the RFC4303 (ESP) from 2.4 to 2.7 when talking about the transport flow confidentiality. Status: Verified -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
