Skip to main content

IETF Last Call Review of draft-ietf-opsawg-prefix-lengths-08
review-ietf-opsawg-prefix-lengths-08-secdir-lc-smyslov-2025-10-27-00

Request Review of draft-ietf-opsawg-prefix-lengths
Requested revision No specific revision (document currently at 14)
Type IETF Last Call Review
Team Security Area Directorate (secdir)
Deadline 2025-11-12
Requested 2025-10-22
Authors Oliver Gasser , Randy Bush , Massimo Candela , Russ Housley
I-D last updated 2026-01-12 (Latest revision 2025-12-17)
Completed reviews Opsdir IETF Last Call review of -07 by Adrian Farrel (diff)
Secdir IETF Last Call review of -07 by Valery Smyslov (diff)
Rtgdir IETF Last Call review of -07 by Michael Richardson (diff)
Intdir IETF Last Call review of -08 by Sheng Jiang (diff)
Genart IETF Last Call review of -08 by Roni Even (diff)
Secdir IETF Last Call review of -08 by Valery Smyslov (diff)
Assignment Reviewer Valery Smyslov
State Completed
Request IETF Last Call review on draft-ietf-opsawg-prefix-lengths by Security Area Directorate Assigned
Posted at https://mailarchive.ietf.org/arch/msg/secdir/B3rqD4gZEtQELE6_dRvZNX8YGS8
Reviewed revision 08 (document currently at 14)
Result Has nits
Completed 2025-10-27
review-ietf-opsawg-prefix-lengths-08-secdir-lc-smyslov-2025-10-27-00
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.

I previously reviewed the -07 version of the draft. The -08 version addressed
the issues I have had with this draft. However, most of the nits were not
addressed. Since they are non-blocking, I list them below and leave to AD's
discretion.

Nits:
1. Section 6. I'd rather move para starting with "An address range A "covers"
address range B..." closer to the requirement "The address range of the signing
certificate MUST cover all prefixes in the signed prefixlen file." for
readability.

2. Section 6. I think that the following requirement "All of the above steps
MUST be successful to consider the prefixlen file signature as valid." is not
needed - the draft already have RFC 2119 language for each step of the
validation algorithm.

3. Section 7. "The prefixlen files MUST be published via and fetched using
HTTPS [RFC9110]." While I think this is a good requirement, I wonder why other
secure protocols are prohibited? Or say out-of-band delivery?

4. Section 7. "To dedicate a signing private key for signing a prefixlen file,
an RPKI Certification Authority (CA) may issue a subordinate certificate
exclusively for the purpose shown in Appendix A.". It is unclear to me what
purpose is shown in Appendix A. Perhaps it should be "...for this purpose, as
shown in Appendix A".