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

[[e-mail]]

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

# Versatile

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

# 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.

# ContentInfo

CURRENT:
The content of a CCR file is an instance of ContentInfo.

Maybe add a reference to RFC5652?

# 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.

# 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.

# 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.

# 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?

## 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?

# 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.

# Media types

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

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

# 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.

# Missing reference

## Add RFC8792 as an Informative reference.

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

# Examples

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

## 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.

## Interop

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

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

Cheers,
Med
____________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.