Original text:
generation function, if the Forward Secrecy extension is taken into use.  It will also at the same time indicate the used or desired ECDHE group.  A new attribute is needed to carry this information, as <del> AT_KDF carries the legacy KDF value which is still used together with the forward secrecy KDF value.  The legacy KDF value is also used by </del>  those EAP peers that cannot or do not want to use this extension.  The format of the AT_KDF_FS attribute is shown below. The fields are as follows:

Reviewer comments:
I'm flying later today and unsure about how much I can do on Monday. I will need to deploy this change and submit the draft.
ATKDF carries the legacy KDF value for those EAP peers that cannot or do not want to use this extension. Gives the impression that ATKDF is ignored when ATKDFFS is used... Gives the impression that they are used together... The Specification is clear on how to derive keys when ATKDF in {1} and ATKDF_FS in {1,2} but does not give any descriptions on how other combinations are supposed to work.
I don't know how this is supposed to work but there are several options for how they are used together. ATKDF is completely ignored when ATKDFFS is used. ATKDF determines how to derive MK, Kaut, Kre ATKDFFS determines how to derive MKECDHE, Kre, MSK, EMSK Like 2. but the PRF used in deriving MKECDHE is determined by ATKDF.
Reasons that this need to be specified is. If someone specifies ATKDF = 2. How would that work with EAP-AKA' FS If someone wants to specify a PQC KEM for ATKDF_FS. Exactly what should they specify.
Ok this seems like a fair issues. Thanks for spotting this.
I see two options. Either we are (a) trying to be clever and split what impacts what (MK, K_aut) vs. everything else or (b) we only specify a specific combination (KDF=1 + FS=1 or 2) and explicitly say that future specs need to specify how new KDF or FS algorithms can be combined with others. Both have some drawbacks ... not sure we always want to have the same split in option a. And option b leaves out a lot of room for future extensions to forget to do this. Maybe go for option b? I will try to make a PR.
I am fine with b. The PR should make clear that this updates RFC 9048 with this new requirement.
Ok
A PR has been proposed: URL
Solved per the PR so that I can submit the draft (may not be able to work on Monday due to travel).

Revised text:
generation function, if the Forward Secrecy extension is taken into use.  It will also at the same time indicate the used or desired ECDHE group.  A new attribute is needed to carry this information, as  <ins> AT_KDF carries the basic KDF value which is still used together with the forward secrecy KDF value.  The basic KDF value is also used by </ins> those EAP peers that cannot or do not want to use this extension. <ins> This specification only specifies the behaviour relating to the following combinations of basic KDF values and forward secrecy KDF values: The basic KDF value in AT_KDF is 1, as specified in RFC5448 and RFC9048, and the forward secrecy KDF values in AT_KDF_FS are 1 or 2, as specified below and in kdf2. Any future specifications that add either new basic KDF or new forward secrecy KDF values need to specify how they are treated and what combinations are allowed.  This requirement is an update to how RFC5448 and RFC9048 may be extended in the future. </ins> The format of the AT_KDF_FS attribute is shown below. The fields are as follows: