Found 2 records.

Status: Verified (1)

RFC 7296, "Internet Key Exchange Protocol Version 2 (IKEv2)", October 2014

Errata ID: 6667
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Qingyuan Gu
Date Reported: 2021-08-30
Verifier Name: Benjamin Kaduk
Date Verified: 2021-09-01

Section 3.3 says:

   the different groups.  For example, to propose ESP with (3DES or
   AES-CBC) and (HMAC_MD5 or HMAC_SHA), the ESP proposal would contain
   two Transform Type 1 candidates (one for 3DES and one for AEC-CBC)
   and two Transform Type 3 candidates (one for HMAC_MD5 and one for
   HMAC_SHA).

It should say:

   the different groups.  For example, to propose ESP with (3DES or
   AES-CBC) and (HMAC_MD5 or HMAC_SHA), the ESP proposal would contain
   two Transform Type 1 candidates (one for 3DES and one for AES-CBC)
   and two Transform Type 3 candidates (one for HMAC_MD5 and one for
   HMAC_SHA).

Notes:

"AES" is misspelled as "AEC".

Status: Reported (1)

RFC 7296, "Internet Key Exchange Protocol Version 2 (IKEv2)", October 2014

Errata ID: 6940
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: warren.wang
Date Reported: 2022-04-21

Section 3.10 says:

o SPI Size (1 octet) - Length in octets of the SPI as defined by the
 IPsec protocol ID or zero if no SPI is applicable. For a
 notification concerning the IKE SA, the SPI Size MUST be zero and
 the field must be empty.

It should say:

o SPI Size (1 octet) - Length in octets of the SPI as defined by the
 IPsec protocol ID or zero if no SPI is applicable. For a
 notification concerning the IKE SA, the SPI Size MUST be zero and
 the SPI field must be empty.

Notes:

the field must be empty -> the SPI field must be empty

so for a notification concerning the IKE SA, the Protocol ID field still shall be zero?(According to the last sentence of Protocol ID section:"If the SPI field is empty, this field MUST be sent as zero and MUST be ignored on receipt".)

Report New Errata