Handling of Resource Public Key Infrastructure (RPKI) Certificate Revocation List (CRL) Number Extensions
draft-ietf-sidrops-rpki-crl-numbers-05

[Ballot comment]
Thanks to Nancy Cam-Winget for their secdir reviews.

Section 5:  List RFC 9286 here. It appears that it is the RFC which requires manifestNumber to be strictly increasing.

Section 5:  Can a short paragraph be added discussing the issues associated with either the 'CRL Number' not matching the 'manifestNumber' (currently only RECOMMENDED) and/or the issue of not ignoring a CRL Number if and when it doesn't match the 'manifestNumber'.  Nothing too long, just a short note that outlines the issues.  I can help with the words for this, if that would help.

[Ballot comment]
Thanks to the authors for a short and easy to read document. I have just one comment.

Section 3.1, paragraph 5
>      OLD
>
>      |  Where two or more CRLs are issued by the same CA, the CRL with
>      |  the highest value of the "CRL Number" field supersedes all
>      |  other CRLs issued by this CA.
>
>      NEW
>
>      |  Per Section 5.2.3 of [RFC5280], CAs issue new CRLs using a
>      |  monotonically increasing sequence number in the "CRL Number"
>      |  extension.  It is RECOMMENDED that the "CRL Number" matches the
>      |  "manifestNumber" of the manifest that will include this CRL
>      |  (see Section 4.2.1 of [RFC9286]).

Maybe this is covered somewhere else, but reading the last sentence of the NEW I wonder what happens when the CRL Number does NOT match the manifestNumber. Is the session aborted? Does it fall back to previous behavior, i.e., checking the highest value of CRL Number. Some clarity would help.

[Ballot comment]
Thanks for writing this I-D. This document does not appear to introduce any transport requirements or related transport issues. I defer to other ADs on topics related to operational and security considerations.

[Ballot comment]
Thansk for writing this I-D. This document does not appear to introduce any transport requirements or related transport issues. I defer to other ADs on topics related to operational and security considerations.

Request for IETF Last Call review by GENART Completed: Ready with Issues. Reviewer: Peter Yee. Sent review to list. Submission of review completed at an earlier date.

IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-sidrops-rpki-crl-numbers-04, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Sr. Specialist

The following Last Call announcement was sent out (ends 2025-04-03):

From: The IESG
To: IETF-Announce
CC: draft-ietf-sidrops-rpki-crl-numbers@ietf.org, housley@vigilsec.com, mohamed.boucadair@orange.com, sidrops-chairs@ietf.org, sidrops@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Relying Party Handling of Resource Public Key Infrastructure (RPKI) Certificate Revocation List (CRL) Number Extensions) to Proposed Standard


The IESG has received a request from the SIDR Operations WG (sidrops) to
consider the following document: - 'Relying Party Handling of Resource Public
Key Infrastructure (RPKI)
  Certificate Revocation List (CRL) Number Extensions'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2025-04-03. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This document clarifies how Resource Public Key Infrastructure (RPKI)
  Relying Parties (RPs) handle Certificate Revocation List (CRL) Number
  extensions.  This document updates RFC 6487.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-sidrops-rpki-crl-numbers/



No IPR declarations have been submitted directly on this I-D.

Shepherd Write-up for draft-ietf-sidrops-rpki-crl-numbers-02

# Document History

1.  Does the working group (WG) consensus represent the strong concurrence of a
    few individuals, with others being silent, or did it reach broad agreement?

    There is broad consensus for this document in the SIDRops WG, and
    there is some implementation experience too.

2.  Was there controversy about particular points, or were there decisions where
    the consensus was particularly rough?

    There was no significant controversy.

3.  Has anyone threatened an appeal or otherwise indicated extreme discontent? If
    so, please summarize the areas of conflict in separate email messages to the
    responsible Area Director. (It should be in a separate email because this
    questionnaire is publicly available.)

    No one has threatened an appeal.

4.  For protocol documents, are there existing implementations of the contents of
    the document? Have a significant number of potential implementers indicated
    plans to implement? Are any existing implementations reported somewhere,
    either in the document itself (as RFC 7942 recommends) or elsewhere
    (where)?

    Appendix A shows implementation experience.  Appendix A will be dropped by
    the RFC Editor.

# Additional Reviews

5.  Do the contents of this document closely interact with technologies in other
    IETF working groups or external organizations, and would it therefore benefit
    from their review? Have those reviews occurred? If yes, describe which
    reviews took place.

    No external review is needed.

6.  Describe how the document meets any required formal expert review criteria,
    such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

    No special reviews are needed.

7.  If the document contains a YANG module, has the final version of the module
    been checked with any of the recommended validation tools for syntax and
    formatting validation? If there are any resulting errors or warnings, what is
    the justification for not fixing them at this time? Does the YANG module
    comply with the Network Management Datastore Architecture (NMDA) as specified
    in RFC 8342?

    YANG is not used in this document.

8.  Describe reviews and automated checks performed to validate sections of the
    final version of the document written in a formal language, such as XML code,
    BNF rules, MIB definitions, CBOR's CDDL, etc.

    This document updates RFC 6487, which makes use of ASN.1; however, the ASN.1
    module is not updated by this document.

# Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
    document is needed, clearly written, complete, correctly designed, and ready
    to be handed off to the responsible Area Director?

    Yes, the document is ready, clear, and complete.  The document shepherd did
    a thorough review of the document as part of WG Last Call.  All issues that
    were raised during WG Last Call have been resolved.

10. Several IETF Areas have assembled lists of common issues that their
    reviewers encounter. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

    No concerns.

11. What type of RFC publication is being requested on the IETF stream (Best
    Current Practice, Proposed Standard, Internet Standard,
    Informational, Experimental or Historic)? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

    Proposed Standard.  Yes, the header calls for a Standards Track RFC, and
    this is reflected in the Datatracker.  This document provides an update
    to RFC 6487, which is a Standards Track RFC.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in BCP 79? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

    The authors have explicitly stated that they are unaware of any IPR
    related with the document.

    No IPR disclosures were issued against this document.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front
    page is greater than five, please provide a justification.

    The authors have each responded to the shepherd about the document.

14. Document any remaining I-D nits in this document. Simply running the
    IDnits tool is not enough; please review the "Content Guidelines" on
    authors.ietf.org. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

    No concerns.

15. Should any informative references be normative or vice-versa? See the IESG
    Statement on Normative and Informative References.

    No concerns.

16. List any normative references that are not freely available to anyone.
    Did the community have sufficient access to review any such normative
    references?

    All normative references are freely available.

17. Are there any normative downward references (see RFC 3967 and BCP 97)
    that are not already listed in the DOWNREF registry? If so, list them.

    There are no downward normative references.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear
    state? If so, what is the plan for their completion?

    All normative references are already published.

19. Will publication of this document change the status of any existing RFCs?
    If so, does the Datatracker metadata correctly reflect this and are those
    RFCs listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

    No document status changes.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see RFC 8126).

    No new IANA registries are needed.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

    None are needed.

Shepherd Write-up for draft-ietf-sidrops-rpki-crl-numbers-02


(1) What type of RFC is being requested (BCP, Proposed Standard, Internet
Standard, Informational, Experimental, or Historic)?  Why is this the
proper type of RFC?  Is this type of RFC indicated in the title page
header?

  Proposed Standard.  Yes, the header calls for a Standards Track RFC.


(2) The IESG approval announcement includes a Document Announcement
Write-Up.  Please provide such a Document Announcement Write-Up.  Recent
examples can be found in the "Action" announcements for approved
documents.  The approval announcement contains the following sections:

  Technical Summary:

  This document clarifies how Resource Public Key Infrastructure (RPKI)
  Relying Parties (RPs) handle Certificate Revocation List (CRL) Number
  extensions.  This document updates RFC 6487.

  Working Group Summary:

  There is consensus for this document in the SIDRops WG.

  Document Quality:

  There are multiple implementations available today.
   
  Personnel:

  Russ Housley is the document shepherd.
  Warren Kumari is the responsible area director.


(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready for
publication, please explain why the document is being forwarded to the
IESG.

  The document shepherd did a thorough review of the document as part of
  WG Last Call.  All issues that were raised during WG Last Call have
  been resolved.


(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

  No concerns.


(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization?  If so, describe the review that took
place.

  No concerns.


(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the IESG
should be aware of?  For example, perhaps he or she is uncomfortable with
certain parts of the document, or has concerns whether there really is a
need for it.  In any event, if the WG has discussed those issues and has
indicated that it still wishes to advance the document, detail those
concerns here.

  No concerns.


(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed.  If not, explain why?

  The authors have explicitly stated that they are unaware of any IPR
  related with the document.


(8) Has an IPR disclosure been filed that references this document?  If
so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

  No IPR disclosures were issued against this document.


(9) How solid is the WG consensus behind this document?  Does it
represent the strong concurrence of a few individuals, with others being
silent, or does the WG as a whole understand and agree with it?

  There is consensus for this document in the SIDRops WG.


(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent?  If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director.  (It should be in a
separate email because this questionnaire is publicly available.)

  No one has threatened an appeal.


(11) Identify any ID nits the Document Shepherd has found in this
document.  (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist).  Boilerplate checks are not enough; this check needs to be
thorough.

  No concerns.


(12) Describe how the document meets any required formal review criteria,
such as the MIB Doctor, media type, and URI type reviews.

  No special reviews are needed.


(13) Have all references within this document been identified as either
normative or informative?

  Yes.


(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state?  If such normative
references exist, what is the plan for their completion?

  No.


(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in the
Last Call procedure.

  There are no downward normative references.


(16) Will publication of this document change the status of any existing
RFCs?  Are those RFCs listed on the title page header, listed in the
abstract, and discussed in the introduction?  If the RFCs are not listed
in the Abstract and Introduction, explain why, and point to the part of
the document where the relationship of this document to the other RFCs is
discussed.  If this information is not in the document, explain why the
WG considers it unnecessary.

  No.


(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document.  Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly identified.
Confirm that newly created IANA registries include a detailed
specification of the initial contents for the registry, that allocations
procedures for future registrations are defined, and a reasonable name
for the new registry has been suggested (see RFC 5226).

  No updates to the IANA registries are needed.


(18) List any new IANA registries that require Expert Review for future
allocations.  Provide any public guidance that the IESG would find useful
in selecting the IANA Experts for these new registries.

  No new IANA registries are needed.


(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

  None are needed.

Shepherd Write-up for draft-ietf-sidrops-rpki-crl-numbers-02


(1) What type of RFC is being requested (BCP, Proposed Standard, Internet
Standard, Informational, Experimental, or Historic)?  Why is this the
proper type of RFC?  Is this type of RFC indicated in the title page
header?

  Proposed Standard.  Yes, the header calls for a Standards Track RFC.


(2) The IESG approval announcement includes a Document Announcement
Write-Up.  Please provide such a Document Announcement Write-Up.  Recent
examples can be found in the "Action" announcements for approved
documents.  The approval announcement contains the following sections:

  Technical Summary:

  This document clarifies how Resource Public Key Infrastructure (RPKI)
  Relying Parties (RPs) handle Certificate Revocation List (CRL) Number
  extensions.  This document updates RFC 6487.

  Working Group Summary:

  There is consensus for this document in the SIDRops WG.

  Document Quality:

  There are multiple implementations available today.
   
  Personnel:

  Russ Housley is the document shepherd.
  Warren Kumari is the responsible area director.


(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready for
publication, please explain why the document is being forwarded to the
IESG.

  The document shepherd did a thorough review of the document as part of
  WG Last Call.  All issues that were raised during WG Last Call have
  been resolved.


(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

  No concerns.


(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization?  If so, describe the review that took
place.

  No concerns.


(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the IESG
should be aware of?  For example, perhaps he or she is uncomfortable with
certain parts of the document, or has concerns whether there really is a
need for it.  In any event, if the WG has discussed those issues and has
indicated that it still wishes to advance the document, detail those
concerns here.

  No concerns.


(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed.  If not, explain why?

  The authors have explicitly stated that they are unaware of any IPR
  related with the document.


(8) Has an IPR disclosure been filed that references this document?  If
so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

  No IPR disclosures were issued against this document.


(9) How solid is the WG consensus behind this document?  Does it
represent the strong concurrence of a few individuals, with others being
silent, or does the WG as a whole understand and agree with it?

  There is consensus for this document in the SIDRops WG.


(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent?  If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director.  (It should be in a
separate email because this questionnaire is publicly available.)

  No one has threatened an appeal.


(11) Identify any ID nits the Document Shepherd has found in this
document.  (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist).  Boilerplate checks are not enough; this check needs to be
thorough.

  No concerns.


(12) Describe how the document meets any required formal review criteria,
such as the MIB Doctor, media type, and URI type reviews.

  No special reviews are needed.


(13) Have all references within this document been identified as either
normative or informative?

  Yes.


(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state?  If such normative
references exist, what is the plan for their completion?

  No.


(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in the
Last Call procedure.

  There are no downward normative references.


(16) Will publication of this document change the status of any existing
RFCs?  Are those RFCs listed on the title page header, listed in the
abstract, and discussed in the introduction?  If the RFCs are not listed
in the Abstract and Introduction, explain why, and point to the part of
the document where the relationship of this document to the other RFCs is
discussed.  If this information is not in the document, explain why the
WG considers it unnecessary.

  No.


(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document.  Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly identified.
Confirm that newly created IANA registries include a detailed
specification of the initial contents for the registry, that allocations
procedures for future registrations are defined, and a reasonable name
for the new registry has been suggested (see RFC 5226).

  No updates to the IANA registries are needed.


(18) List any new IANA registries that require Expert Review for future
allocations.  Provide any public guidance that the IESG would find useful
in selecting the IANA Experts for these new registries.

  No new IANA registries are needed.


(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

  None are needed.