jiebi/ids-paragraph-commentary-corpus huggingface dataset:
Draft: draft-ietf-emu-aka-pfs-latest

Commentary: Can you review ( and  ) ? 
 ... since 9048 did not obsolete 5448 
 That is is good question . I changed " updates " from RFC 5448 to RFC 9048 as the document do not even mention RFC 5448 except in the Acknowledgments . Updating increases visability and makes it easier to find the EAP - AKA'-FS document . If it updates 5448 some more mentioning of 5448 would be needed in the introduction 
  , fix merged to the document .
This specification updates RFC 9048, the EAP-AKA' authentication
method, with an optional extension.  The extension, when negotiated,
provides Forward Secrecy for the session key generated as a part of
the authentication run in EAP-AKA'.  This prevents an attacker who
has gained access to the long-term pre-shared secret in a SIM card
from being able to decrypt any past communications.  In addition, if
the attacker stays merely a passive eavesdropper, the extension
prevents attacks against future sessions.  This forces attackers to
use active attacks instead.
This specification updates RFC 9048, the EAP-AKA' authentication
method, with an optional extension.  Similarly, this specification
also updates the earlier version of the EAP-AKA' specification in RFC
5448.  The extension, when negotiated, provides Forward Secrecy for
the session key generated as a part of the authentication run in EAP-
AKA'.  This prevents an attacker who has gained access to the long-
term pre-shared secret in a SIM card from being able to decrypt any
past communications.  In addition, if the attacker stays merely a
passive eavesdropper, the extension prevents attacks against future
sessions.  This forces attackers to use active attacks instead.
Draft: draft-ietf-emu-aka-pfs-latest

Commentary:  : Why is this " e.g. " inserted in section 5 ? " generate temporary keys as specified in e.g. , [  ] " It sounds non - deterministic . If using  is an option that can be negotiated or need to be pre - established , then maybe we could write something like : " according to the negotiated ciphersuite , e.g. [ 7748 ] . " If the sentence is more describing a general way of how one would go about designing FS here , then perhaps something like : " To provide FS , a key exchange must run in an ephemeral manner ... " . 
 I think you are right . The text is a bit sloppy ( but I do n’t think it has changed in a while ) . I like your first formulation . Once you know the ciphersuite this is all specified & determined . 
 Will make a PR 
  merged to the base .
Forward Secrecy for EAP-AKA' is achieved by using an Elliptic Curve
Diffie-Hellman (ECDH) exchange RFC7748.  To provide FS, the exchange
must be run in an ephemeral manner, i.e., both sides generate
temporary keys as specified in e.g., RFC7748.  This method is
referred to as ECDHE, where the last 'E' stands for Ephemeral.  The
two initially registered elliptic curves and their wire format is
chosen to align with the elliptic curves and formats specified for
Subscription Concealed Identifier (SUCI) encryption in Appendix C.3.4
of 3GPP TS 33.501 TS.33.501.
Forward Secrecy for EAP-AKA' is achieved by using an Elliptic Curve
Diffie-Hellman (ECDH) exchange RFC7748.  To provide FS, the exchange
must be run in an ephemeral manner, i.e., both sides generate
temporary keys according to the negotiated ciphersuite, e.g., for
X25519 this is done as specified in RFC7748.  This method is referred
to as ECDHE, where the last 'E' stands for Ephemeral.  The two
initially registered elliptic curves and their wire format is chosen
to align with the elliptic curves and formats specified for
Subscription Concealed Identifier (SUCI) encryption in Appendix C.3.4
of 3GPP TS 33.501 TS.33.501.
Draft: draft-ietf-emu-aka-pfs-latest

Commentary: Suggested fix for 
  : -- In Section 7.4 it says : " The Initiator and the Responder must make sure that unprotected data and  do not reveal any sensitive information . " Should it be put in a less requirement - like form ? For example : " unprotected data and  can reveal sensitive information and need to be selected with care . " ? 
 I agree that the metadata text should not be requirement form as much as it is now – there ’s little that implementations can actually do about this , e.g. , about the network name . Will make a PR .
The Initiator and the Responder must make sure that unprotected data
and metadata do not reveal any sensitive information.  In particular,
this applies to AT_KDF, AT_KDF_FS, AT_PUB_ECDHE, and AT_KDF_INPUT.
AT_KDF, AT_KDF_FS, and AT_PUB_ECDHE reveals the used cryptographic
algorithms, if these depend on the peer identity they leak
information about the peer.  AT_KDF_INPUT reveals the network name.
An attacker observing network traffic may use such information for
traffic flow analysis or to track an endpoint.
Unprotected data and metadata can reveal sensitive information and
need to be selected with care.  In particular, this applies to
AT_KDF, AT_KDF_FS, AT_PUB_ECDHE, and AT_KDF_INPUT.  AT_KDF,
AT_KDF_FS, and AT_PUB_ECDHE reveals the used cryptographic
algorithms, if these depend on the peer identity they leak
information about the peer.  AT_KDF_INPUT reveals the network name,
although that is done on purpose to bind the authentication to a
particular context.
An attacker observing network traffic may use the above types of
information for traffic flow analysis or to track an endpoint.