Resending the review, adding opsawg to the Cc list. > On Aug 25, 2025, at 3:30 PM, Mahesh Jethanandani <mjethanand...@gmail.com> > 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? > > 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. > > 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? > > 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? > > 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? > > 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). > > 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? > > Also, is it possible to specify normative client caching behavior, e.g., MUST > honor Expires/Cache-Control? > > "Authors' Addresses", paragraph 0 > > Oliver Gasser > > IPinfo > > Email: oli...@ipinfo.io <mailto:oli...@ipinfo.io> > > Randy Bush > > IIJ Research & Arrcus > > 5147 Crystal Springs > > Bainbridge Island, Washington 98110 > > United States of America > > Email: ra...@psg.com <mailto:ra...@psg.com> > > Wonder why we are missing a space between Oliver and Randy Bush. > > ------------------------------------------------------------------------------- > 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), 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 > mjethanand...@gmail.com <mailto:mjethanand...@gmail.com> > > > > > >
Mahesh Jethanandani mjethanand...@gmail.com
_______________________________________________ OPSAWG mailing list -- opsawg@ietf.org To unsubscribe send an email to opsawg-le...@ietf.org
