[Sidrops] Re: AD Review of draft-ietf-sidrops-rpki-ccr

[Job Snijders <[e-mail]>]

Dear Med,

Thank you for your time to review this document and your help to get it
ready for publication!


On Mon, Jun 01, 2026 at 08:54:26AM +0000, [e-mail] wrote:
> Hi Job, Bart, Tim, and Theo,
> (also ccing @authors of draft-ietf-sidrops-aspa-profile<mailto:[e-mail]> as draft-ietf-sidrops-rpki-ccr has as normative dependency on aspa)
> 
> Thank you for the effort put into this well-written document.
>
> Please find below some comments (following the text order, not importance):
> 
> # Cite a reference when RPKI is call called out


You mean a reference to RFC 6480?

In the abstract or in the introduction? 

I don't recall you wanted the same thing in other recent RPKI drafts,
but I might be misunderstanding what your guidance here is?


> # Versatile
> 
> Both the abstract and introduction says that the format is versatile. What does that means concretely?


Versatile is an adjective that describes something capable of adapting
to many different functions, activities, or purposes.


> # Applicability
> 
> OLD:
> 1.1.  History
> 
>    The format was initially designed to support comparative analysis of
>    multiple RP instances using a variety of RPKI transport protocols
>    ([RFC5781], [RFC8182], and [I-D.ietf-sidrops-rpki-erik-protocol]).
> 
> 
> NEW:
>    The CCR format was initially designed to support comparative analysis of
>    multiple RP instances using a variety of RPKI transport protocols
>    ([RFC5781], [RFC8182], and [I-D.ietf-sidrops-rpki-erik-protocol]).
>    However, CCR can be applicable to various use cases such as those
>    listed in Section 4. It is out of the scope of this document
>    to provide an exhaustive inventory of such uses.


I'm not sure this is an improvement - this HISTORY paragraph details the
eh... overview of past events. I'm not sure how a sentence indicating
some kind of contrast to the previous sentence on historical fact
is responsive. As things currently are, both the Abstract, and the
Introduction section, and Section 4 make it clear that the CCR profile
is versatile (multi-functional).


> # ContentInfo
> 
> CURRENT:
> The content of a CCR file is an instance of ContentInfo.
> 
> Maybe add a reference to RFC5652?


sure.


> # Conflict in the ASN1.0 Module
> 
> CURRENT:
>    RpkiCanonicalCacheRepresentation-2025
>      { iso(1) member-body(2) us(840) rsadsi(113549)
>        pkcs(1) pkcs9(9) smime(16) mod(0) id-mod-rpkiCCR-2025(TBD) }
> 
>   ..
>      CAS, PAS
>      FROM RPKI-ASPA-2023 -- in [draft-ietf-sidrops-aspa-profile]
>        { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
>         pkcs-9(9) smime(16) modules(0) id-mod-rpki-aspa-2023(TBD) }
> 
> Vs.
> 
>       +=========+=====================+=============================+
>       | Decimal | Description         | References                  |
>       +=========+=====================+=============================+
>       | TBD     | id-mod-rpkiCCR-2025 | draft-ietf-sidrops-rpki-ccr |
>       +---------+---------------------+-----------------------------+
> 
> Please fix and add a note to the RFC Editor about how to handle the various TBDs.


I'm not sure I see the conflict? It is my understanding IANA will assign
OIDs for the module identifier upon RFC publication.

id-mod-rpki-aspa-2023 will be resolved through publication of
draft-ietf-sidrops-aspa-profile. Implication being that the CCR draft
might wait a bit in the RFC Editor queue waiting for ASPA profile draft
to arrive. That's ok.


> # Consistency
> 
> The narrative text includes normative text that do not completely morror the content of the ASN1.0 module. For example, the module includes:
> 
> CURRENT:
>      -- at least one of mfts, vrps, vaps, tas, or rks MUST be present
> 
> This raises the question about which one is authoritative. I guess in this case, both are authoritative. Please add an explicit text saying so.


The ASN.1 formal notation itself, the comment in the ASN.1 code, and the
natural language text are consistent with each other.

ASN.1 module: "at least one of mfts, vrps, vaps, tas, or rks MUST be present"

Section 3.4: "Each CCR contains one or more fields representing particular aspects of the cache's state."

What is not clear? Do you prefer the sentence to read as follows?

Section 3.4: "Each CCR MUST contain one or more fields representing particular aspects of the cache's state."



> # Ambiguity
> 
> CURRENT:
>    For the purposes of this
>    section, CCR generation begins once the RP's fetching and validation
>    operations are completed.
> 
> I fail to see how "For the purposes of this  section," restricts the behavior described here. Can that be deleted? If not, can you please explain the intent and reword accordingly.


It was added in collaboration with a working group participant (Tom
Harrison). Keep in mind that fetching, validation, and CCR generation
all three are operations that consume non-zero time. The goal is
to clarify the meaning of producedAt and how to produce internally
consistent CCRs. I'd prefer to keep the sentence as-is.


> # Implementation note
> 
> CURRENT:
>    Implementers should note the ellipsis
>    extension marker in the RpkiCanonicalCacheRepresentation ASN.1
>    notation and anticipate future changes as new signed object types are
>    standardized.
> 
> ## What does that mean concretely?


Are you familiar with the meaning of '...' in ASN.1 ?
https://www.ibm.com/support/pages/what-does-string-three-elipses-mean-asn1

In many ASN.1-related RFCs the '...' ellipsis extension marker is used.

It seems friendlier to the reading implementer to put in a reminder (A)
the ellipsis is there (B) perhaps structure their code in a way that
future extensions are frictionless.


> ## Future state support would require a new module structure, anyway.
> 
> # Ordering
> 
> CURRENT:
>    The sequence elements of the subordinates field MUST be
>    sorted in ascending order by interpreting each SubjectKeyIdentifier
>    value as an unsigned 160-bit integer and MUST be unique with respect
>    to each other.
> 
> This text and similar imposes ordering constraints, however, it is not clear what are the implications of not following these MUSTs. Does violating these MUST lead to a broken file? Can we please be explicit about the intended behavior?


Yes, if it is not ordered in the specified way the file is broken.

I personally am not entirely sure it would be super helpful to replace
all occurances of MUST with a pattern of "MUST do xyz, otherwise the
file is invalid". I think it is clear these MUSTs stand on their own.


> # Rationale
> 
> CURRENT:
> Readers and
>    writers of CCR data are RECOMMENDED to support data compression using
>    Gzip ([RFC1952]) in context of durable storage.
> 
> Please add some text to explain the rationale of the recommendation and why this is not provided as a mandatory to implement.


Please provide a rationale why this should be mandatory-to-implement? :-)

To be clear: a non-compressed CCR is _not_ an invalid CCR!

In Section 5.3 it is noted that CCR compresses very well.

Operators can choose to take advantage of that, or not. It is up to
them?

For example, when storing multiple CCRs in a single Posix Pax
Interchange Format archive which itself is compressed (.tar.gz file),
it would not make sense to store the CCRs in Gzipped form (i.e., double
compression does not lead to increased efficiency). Or, operators might
use a filesystem that does compression at the block level (for example,
ZFS).

Mandating Gzip support seems a step too far, it depends a bit on the
deployment context of the consumer & reader whether using Gzip makes
sense, but certainly a recommendation is in order to make folks aware of
the benefits of LZ77 / Huffman coding in context of CCR.


> # Media types
> 
> ## Please update so that the registration template in RFC 6838 is followed for each type requests.


You'd like me to repeat the fields that the same for the two flavours?
Note that the second registration is just a structured syntax specifier.


> ## In order to ease referencing a specific type, please use a specific subsection for each media type.


ok.


> # Normative references
> 
> The following are listed as Informative, while there are normatively cited in the doc:
> 
>    [RFC1952]  Deutsch, P., "GZIP file format specification version 4.3",
>               RFC 1952, DOI 10.17487/RFC1952, May 1996,
>               <https://www.rfc-editor.org/info/rfc1952>.
> 
>    [RFC8205]  Lepinski, M., Ed. and K. Sriram, Ed., "BGPsec Protocol
>               Specification", RFC 8205, DOI 10.17487/RFC8205, September
>               2017, <https://www.rfc-editor.org/info/rfc8205>.
>
> CURRENT:
>    writers of CCR data are RECOMMENDED to support data compression using
>    Gzip ([RFC1952]) in context of durable storage.
>    ...
>    An instance of RouterKeyState contains an rksets field which
>    represents the current set of valid BGPsec Router Keys [RFC8205]
>    encoded as a SEQUENCE of RouterKeySet instances.


Yup, those should be normative. Thanks.


> # Missing reference
> 
> ## Add RFC8792 as an Informative reference.


ok, thanks.


> ## Make sure that RFC is also called out as a reference in the text.


sure, but ... why? Isn't the heading above the text enough?


> # Examples
> 
> ## Consider adding some brief narrative text to explain what this example is illustrating.


sure. https://github.com/job/draft-sidrops-rpki-ccr/issues/20


> ## Documentation ranges
> 
> The examples uses various ranges reserved for documentation. However, there is this ASN 65123 which does not fall under such ranges. Please update.


Thanks - Theo is addressing that through https://github.com/job/draft-sidrops-rpki-ccr/pull/19


> ## Interop
> 
> Can we please confirm that this example can be decoded correctly by at least of the other implementations listed in the document?

Correct decoding of the example was confirmed by two implementations.


> # You may find some editorial proposals, fixes, and nits at: https://github.com/job/draft-sidrops-rpki-ccr/pull/18/changes.


Fantastic, thank you.

There are a few details we need to hash out, but by and large the
editorial suggestions seem OK.

Kind regards,

Job