Reviewer: Adrian Farrel Review result: Ready with nits Hello, I have reviewed this document as part of the Operational Directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. Regards, Adrian === Reviewer: Adrian Farrel Draft reviewed: draft-ietf-opsawg-prefix-lengths-07.txt Review Result: Ready with nites This document describes an augmentation to the inetnum: file format to indicate prefix lengths. This document is easily readable and ready for publication modulo a few minor points and nits that could be usefully cleared up. = Manageability = Thank you for including Section 7 to give the operational considerations. This made my job much easier. I see no other manageability considerations that need to be covered. = Minor = I think you have backward compatiblity covered in Section 4, but it takes some working out. The cases to cover are: - How will legacy implementations react on encountering the additional inetnum fields? - Will a new implementation correctly parse a legacy prefixlen file? Might it be worth calling this out in a separate section for clarity? --- Section 3 specifies some clear rules for how prefixlen files must be formed. But I did not find an explanation of what to do if a malformed entry line or file is found. This may be something that can be explained by reference to a previous document. --- Section 3.5 Duplicate prefix entries MUST be considered an error Is it necessary to expand on the definitin of "duplicate"? Initially it appears that "duplicate" applies to "entry" such that an example would be: 2001:db8::/32,56,1 2001:db8::/32,56,1 But, (obviously?) you mean lines that refer to the same prefix, but might be otherwise different. That is not just: 2001:db8::/32,56,1 2001:db8::/32,56,1 # Ooops, a duplicate ... but also: 2001:db8::/32,56,1 2001:db8::/32,56,2 ... and: 2001:db8::/32,56,1 2001:db8::/32,64,1 Further, I suspect you mean to consider overlapping prefixes? --- Section 4 You have... In addition to publishing the location of prefixlen files in WHOIS with the prefixlen: or remarks: approaches, there is currently a proposal being discussed to introduce a new RPSL attribute of type extref: for generic external references [I-D.ymbk-opsawg-rpsl-extref]. With this extref approach a prefixlen can be referenced as follows: inetnum: 192.0.2.0/24 # example extref: Prefixlen https://example.com/prefixlen I'm sure draft-ymbk-opsawg-rpsl-extref is a worthy document. But I think the text here makes it into a normative reference, which would be unfortunate for the rapid progress of this document. Probably you could leave out this paragraph. Alternatively reduce it to something like: An aproach to introduce a new RPSL attribute of type extref: for generic external references is described in [I-D.ymbk-opsawg-rpsl- extref]. = Nits = I think the Abstract assumes I should know what a "prefixlen data file" is. Perhaps I should! Looking ahead to Seciton 3, I find a detailed definition, which is good. But there it has: prefixlen files are CSV (Comma Separated Values) files in UTF-8 [RFC3629] text format; not HTML, richtext, or other formats. So, it appears that all prefixlen files are CSV files. In that case, the Abstract is ambiguous or tautological when it says: prefixlen comma-separated values (CSV) data files Please have a think about the Abstract and whether it needs cleaning. --- Section 1 Therefore, there are countless variations of different end-site prefix length present in the Internet Are they countless? I mean, there are only 128 different prefix lengths available. Maybe "very many"? --- Section 1 [I-D.ietf-opsec-ipv6-addressing] recently also raised this issue. Maybe future-proof the text as: [I-D.ietf-opsec-ipv6-addressing] also raises this issue. --- Section 1 * Geolocation: Getting the right prefix size for IPv6 geolocation is similarly hard. If you aggregate too little, you throw together different clients in different locations, and if you aggregate too much, you fill up the geolocation database with unnecessary entries. Is this back-to-front? That is, too much aggregation throws together addresses from different locations, while too little aggregation fills the geolocation table? --- 3.2 CGN end sites would is specified as follows: s/is/be/ --- The plural of inetnum: as inetnum:s is ugly! Maybe s/inetnum:s/inetnum: instances/ --- 7. Harvesting and publishing aggregated prefixlen data outside of the RPSL model should be avoided as it can have the effect that more specifics from one aggregatee could undesirably affect the less specifics of a different aggregatee. Is that "SHOULD BE"?