First of, thanks a lot for the constructive review, Mahesh!
Comments from the author team are inline.
On 9/3/25 6:52 PM, Mahesh Jethanandani wrote:
Resending the review, adding opsawg to the Cc list.
On Aug 25, 2025, at 3:30 PM, Mahesh Jethanandani
<[email protected]> wrote:
Hi Authors,
Thank you for working on this document. Here are some comments on the
document. Hopefully, they will go towards improving the draft further.
Section 3, paragraph 0
> prefixlen files are CSV (Comma Separated Values) files in UTF-8
> [RFC3629] text format; not HTML, richtext, or other formats. Lines
> MUST be delimited by a line break (CRLF), and blank lines MUST be
> ignored. Text from a '#' character to the end of the current line
> MUST be treated as a comment only and is similarly ignored. The
> first field of each non-ignored line specifies the prefix in
> question, the second field the end-site prefix length within that
> prefix as an integer, and the third field the number of end-sites
> within an end-site prefix length for networks using Carrier-Grade NAT
> (CGN) [RFC6598]. Note that all three fields MUST be present. This
> means there MUST be exactly two commas in each non-commented line
> delimiting the three fields. The first field MUST NOT be empty on
> lines which are not comments, while the second and third field can be
> empty in certain scenarios.
The rules around the file format seem to be unusually strict. What
about producers/consumers that emit \n? How about accepting CRLF and
LF? Is there an exception rule for when a future extension might need
a comma in the field?
When the signature is applied, we need to be strict. Otherwise, each
party (signer and validator) will need to convert to the canonical form.
This is also in line with other RFCs (e.g., Geofeeds, SMTP).
I can't think of future extensions where a comma in the field would be
absolutely necessary. If that were to be the case I suggest to
standardize that in a bis.
The third field semantics seems to conflate a boolean (CGN present)
with a cardinality and is ambiguous for mixed deployments. How about
splitting this into two fields? A boolean/enum (for none/CGN/proxy/
both) with an optional integer. Or if you want to keep one field,
define unambiguous values and bounds such as 0 == none, >=1 == count.
With the current definition the third field specifies the number of
end-sites per prefix. If it is set to '1' it means that there is no
CGN/proxy present, if it is set to values larger than '1', a CGN/proxy
is present. A value of '0' or any negative value does not adhere to the
specification.
I don't see in which scenarious there's ambiguity with the current
specification. Could you provide an example, Mahesh?
Section 4, paragraph 0
> The original RPSL specifications starting with [RIPE81], [RIPE181],
> and a trail of subsequent documents were written by the RIPE
> community. The IETF standardized RPSL in [RFC2622] and [RFC4012].
> Since then, it has been modified and extensively enhanced in the
> Regional Internet Registry (RIR) community, mostly by RIPE [RIPE-DB].
> At the time of publishing this document, change control of RPSL
> effectively lies in the operator community.
Reading this paragraph, it is not entirely clear who governs the
production or maintenance of these files. Are they generated and
maintained by NIRs, RIRs, LIRs, etc., and what policy governs the
updates to these files? Who can update these files, and who mediates
any conflicts? Can that be explained here or in the Operational
Considerations section?
The RPSL is the "Routing Policy Specification Language", which specifies
the different objects used in the WHOIS database. If by "these files"
you mean prefixlen files, those are to be maintained by the LIRs, i.e.
the actual network operators maintaining their respective inetnum object
in the WHOIS database.
Section 4, paragraph 13
> An unsigned, and only an unsigned, prefixlen file MAY be referenced
> by multiple inetnum:s and MAY contain prefixes from more than one
> registry.
>
> When fetching, the most specific inetnum: object with a prefixlen
> reference MUST be used.
If I understand this correctly, having a signed file does not allow
for multi-inetnum references, while an unsigned file does allow. Does
that not create a perverse incentive for an operator not to move to a
signed file? Would it make sense to specify a precedence of signed
data (even with a less-specific inetnum) over unsigned data (with a
more-specific inetnum) when both exist? Is it possible to have signed
files via per-prefix signature scoping?
That is correct. We do not see a way to accomodate this without carrying
multiple RPKI certificates, one for each inetnum. As we point out two
paragraphs before, when multiple prefixlen files cover the same address
range, a signed prefixlen file MUST be preferred over an unsigned file.
This aligns with the other two RFCs.
Section 5, paragraph 2
> On the other hand, RIRs are converging on RDAP support which includes
> geofeed data, see [I-D.ietf-regext-rdap-geofeed]. It is hoped that
> this will be extended, or generalized, to support prefixlen data.
The fact that this document hopes that RDAP will be extended/
generalized to support prefixlen data makes it aspirational. Why not
explicitly defer to regext and/or mark it as out of scope of this
document?
RDAP has already been deployed in multiple RIRs. Furthermore, the
prefixlen: attribute has been as well.
Section 6, paragraph 17
> 5. Confirming that the eContentType object identifier (OID) is id-
> ct-prefixlenCSVwithCRLF (1.2.840.113549.1.9.16.1.TBD). This OID
> MUST appear within both the eContentType in the encapContentInfo
> object and the ContentType signed attribute in the signerInfo
> object (see [RFC6488]).
I am not a security expert, but I am curious about the choice of
defining a new CMS content type OID versus using an existing signature
container (e.g., CMS application/pkcs7-signature).
This is the way that CMS carries the content type. This tells the
recipient how to parse the content.
Section 7, paragraph 9
> To prevent undue load on RPSL and prefixlen servers, entity-fetching
> prefixlen data using these mechanisms MUST NOT do frequent real-time
> lookups. prefixlen servers SHOULD send an HTTP Expires header
> [RFC9111] to signal when prefixlen data should be refetched. As the
> data change very infrequently, in the absence of such an HTTP Header
> signal, collectors SHOULD NOT fetch more frequently than weekly. It
> would be polite not to fetch at magic times such as midnight UTC, the
> first of the month, etc., because too many others are likely to do
> the same.
Thanks for putting together the Operational Considerations section.
However, it does not mention how often the prefixlen files change.
Would there be a case of stale data in the files, or if the files have
to be rolled back? Are there any scale or performance implications for
consumers of RPSL data?
The change rate of prefixlen files depends on a operator by operator
basis and thus we can't make any general determination here.
Re scale/performance implications for consumers: Publishers of prefixlen
files could publish a file with a CSV large number of prefix entries.
This scenario would then need to be handled accordingly by consumers. We
can mention that explicitly, if that helps.
Also, is it possible to specify normative client caching behavior,
e.g., MUST honor Expires/Cache-Control?
Good point! We will add that to the next revision.
"Authors' Addresses", paragraph 0
> Oliver Gasser
> IPinfo
> Email: [email protected] <mailto:[email protected]>
> Randy Bush
> IIJ Research & Arrcus
> 5147 Crystal Springs
> Bainbridge Island, Washington 98110
> United States of America
> Email: [email protected] <mailto:[email protected]>
Wonder why we are missing a space between Oliver and Randy Bush.
There is no missing space if I look at the html or txt files. Might be
because there is a page break between Randy and me.
-------------------------------------------------------------------------------
NIT
-------------------------------------------------------------------------------
All comments below are about very minor potential issues that you may
choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool
<https://github.com/larseggert/ietf-reviewtool>), so there
will likely be some false positives. There is no need to let me know
what you
did with these suggestions.
Section 2, paragraph 2
> bout splitting this into two fields. An boolean/enum (for none/CGN/
proxy/bot
> ^^
Use "A" instead of "An" if the following word doesn't start with a
vowel sound,
e.g. "a sentence", "a university".
Section 3.3, paragraph 1
> ix of the first entry. Therefore, longest prefix matching has to be
performe
> ^^^^^^^
A determiner may be missing.
Section 3.5, paragraph 5
> the token "prefixlen" MUST be case sensitive, followed by a URL
that will v
> ^^^^^^^^^^^^^^
This word is normally spelled with a hyphen.
Section 3.5, paragraph 16
> understand this correctly, having a signed does not allow for multi-
inetnum
> ^^^^^^^^
A noun may be missing here.
Section 3.5, paragraph 16
> low for multi-inetnum refernces while a unsigned file does allow.
Does that n
> ^
Use "an" instead of "a" if the following word starts with a vowel
sound, e.g.
"an article", "an hour".
Section 6, paragraph 6
> ssing would be quite complex and error prone. And, the certificates
do not g
> ^^^^^^^^^^^
This word is normally spelled with a hyphen.
Section 6, paragraph 25
> regatee could undesirably affect the less specifics of a different
aggregatee
> ^^^^
Did you mean "fewer"? The noun "specifics" is countable.
Section 7, paragraph 8
> produced and/or processed by a third-party places significant trust
in the th
> ^^^^^^^^^^^^^^^^^^^^
The plural noun "places" cannot be used with the article "a". Did you
mean "a
third-party place" or "third-party places"?
Section 7, paragraph 8
> places significant trust in the third-party. As mentioned in
Section 6, som
> ^^^^^^^^^^^
The noun "third party" is written as two words.
Thanks
Mahesh Jethanandani
[email protected] <mailto:[email protected]>
Mahesh Jethanandani
[email protected]
_______________________________________________
OPSAWG mailing list -- [email protected]
To unsubscribe send an email to [email protected]
