Skip to main content

Last Call Review of draft-ietf-regext-epp-eai-12
review-ietf-regext-epp-eai-12-secdir-lc-lonvick-2022-06-12-00

Request Review of draft-ietf-regext-epp-eai
Requested revision No specific revision (document currently at 16)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2022-06-09
Requested 2022-05-26
Authors Dmitry Belyavsky , James Gould
Draft last updated 2022-06-12
Completed reviews I18ndir Early review of -15 by Yoshiro Yoneya (diff)
Genart Last Call review of -10 by Pete Resnick (diff)
Artart Last Call review of -12 by Takahiro Nemoto (diff)
Secdir Last Call review of -12 by Chris M. Lonvick (diff)
Assignment Reviewer Chris M. Lonvick
State Completed Snapshot
Review review-ietf-regext-epp-eai-12-secdir-lc-lonvick-2022-06-12
Posted at https://mailarchive.ietf.org/arch/msg/secdir/9zHJ5WzQK6hhNWwS2VJ4GYodIq4
Reviewed revision 12 (document currently at 16)
Result Has Issues
Completed 2022-06-12
review-ietf-regext-epp-eai-12-secdir-lc-lonvick-2022-06-12-00
Hello,

I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the  IESG.  These
comments were written primarily for the benefit of the  security area
directors.  Document editors and WG chairs should treat  these comments just
like any other last call comments.

The summary of the review is that it has issues.

The document is well written and the Security Considerations seems appropriate.
However, there is insufficient guidance given regarding when the EAI functional
extension is negotiated, but when the server cannot satisfy the required
obligations. The specification says that when the client and server negotiate
the EAI functional specification that, "implies the possibility to process the
EAI address". The draft needs to specify what happens if the client and server
negotiate the EAI functional extension, but when the server cannot fulfill its
obligations to provide the required information, or when the client cannot
process the received information.

This may be easily fixed by saying in the specification that the server will
only accept the negotiation if it can (MUST) provide the required information
specified in section 5.3.1 and that the client can (MUST) accept and act upon
that received information. The specification should also go on to say what MUST
happen if those conditions are not met.

Best regards,
Chris