[Sidrops] Re: I-D Action: draft-ietf-sidrops-rtr-yang-01.txt

[Jishnu Roy <[e-mail]>]

Hi Job,

  Thanks for taking a look and providing the valuable feedbacks on this draft.
  We will audit and cover the suggested changes as it can be done.


Best Regards,

Jishnu R


Juniper Business Use Only

From: Job Snijders <[e-mail]>
Date: Tuesday, 20 January 2026 at 5:00 PM
To: [e-mail] <[e-mail]>
Subject: [Sidrops] Re: I-D Action: draft-ietf-sidrops-rtr-yang-01.txt

[External Email. Be cautious of content]


Dear authors,

Thank you for your work on draft-ietf-sidrops-rtr-yang-01. I have a few
comments I wish to share.

Comment #1
==========

Draft-ietf-sidrops-rtr-yang-01 mentions "ROA records", "Router-key
records", and "ASPA records", in context of RPKI-To-Router.

If this specification is about the "cache to router" channel, e.g.  the
relationship between the RTR server and the BGP router, then I would
suggest to update draft to use different nomenclature and align with the
terms that RFC8210bis uses for this content, for example: "Validated ROA
Payload" (VRP).

I think this is minor detail is relevant because there is no 1:1 mapping
between ROAs, and RTR IPv4 Prefix PDUs: it is possible for multiple
different ROAs to convey the same information, and the RTR server MUST
deduplicate such duplicate information before dissemination. The same
goes for ASPA.

In other words, I suggest something along the lines of:

        $ sed -i 's/ROA/VRP/g;s/roa/vrp/g' draft-ietf-sidrops-rtr-yang.xml

[ SIDENOTE - Upon reviewing rfc8210bis I see that document also uses the
  phrase "ROA" in a handful of places where I'm not entirely convinced
  it is the best choice of words, so for clarity that draft might need a
  few minor modifications too. I'll check with Tom Harrison about those
  instances. ]

Comment #2
==========

With the adoption of draft-ietf-sidrops-rpki-ccr, the working group now
has a canonical way of expressing a set of VRPs byte-wise (and sets of
other types of validated payload records), and thusly also an unambigious way
of calculating a SHA-256 hash (message digest) over such a set.

May I suggest the "roa-table", "router-key-table", and "aspa-table"
leaves are extended with something like "ccr-roapayloadstate-hash",
"ccr-routerkeystate-hash", and "ccr-aspapayloadstate-hash",
respectively? Using the CCR construction method should make it MUCH
easier for external observation tooling to not only verify whether the
record counts between client & server are the same, but ALSO to confirm
the record table contents are the same. There are of course many hashing
algorithms, but it might be most convenient if a 1:1 mapping exists
between CCR and RTR, especially given that CCR can be used as an input
to produce RTR PDUs.

    typedef ccr-hash {
        type binary {
            length 32;
        }
        description "Canonical Cache Representation state hash.";
        reference "draft-ietf-sidrops-rpki-ccr";
    }

Kind regards,

Job


On Tue, Jan 20, 2026 at 02:32:48AM -0800, [e-mail] wrote:
> Internet-Draft draft-ietf-sidrops-rtr-yang-01.txt is now available. It is a
> work item of the SIDR Operations (SIDROPS) WG of the IETF.
>
>    Title:   YANG Data Model for RPKI to Router Protocol
>    Authors: Yisong Liu
>             Changwang Lin
>             Haibo Wang
>             Jishnu Roy
>             Jeffrey Haas
>             Hongwei Liu
>             Di Ma
>    Name:    draft-ietf-sidrops-rtr-yang-01.txt
>    Pages:   34
>    Dates:   2026-01-20
>
> Abstract:
>
>    This document defines YANG data models for configuring and managing
>    Resource Public Key Infrastructure (RPKI) to Router Protocol
>    (RFC6810 and RFC8210).
>
> The IETF datatracker status page for this Internet-Draft is:
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-sidrops-rtr-yang/__;!!NEt6yMaO-gk!CvXtAAnq4Lhy1XL-Wga0U0Q_q5sidJlKIhzMLN9tHEb6azvbJqdubIGQejMUwGDNl2WK4s3PPzw$
>
> There is also an HTMLized version available at:
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-rtr-yang-01__;!!NEt6yMaO-gk!CvXtAAnq4Lhy1XL-Wga0U0Q_q5sidJlKIhzMLN9tHEb6azvbJqdubIGQejMUwGDNl2WKGfqiiDY$
>
> A diff from the previous version is available at:
> https://urldefense.com/v3/__https://author-tools.ietf.org/iddiff?url2=draft-ietf-sidrops-rtr-yang-01__;!!NEt6yMaO-gk!CvXtAAnq4Lhy1XL-Wga0U0Q_q5sidJlKIhzMLN9tHEb6azvbJqdubIGQejMUwGDNl2WK1FYjVHo$
>
> Internet-Drafts are also available by rsync at:
> rsync.ietf.org::internet-drafts
>
>
> _______________________________________________
> Sidrops mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]

_______________________________________________
Sidrops mailing list -- [e-mail]
To unsubscribe send an email to [e-mail]