Thanks to the authors for making the changes “live”. In reviewing the changes, and the COMMENTS received, here are a few that I have not seen addressed.
Eric Vyncke’s: I do not see the rephrasing to include IPv4. Was that intentional? > Section 1: > Is it really only an IPv6 issue in `prefix size for IPv6 geolocation` ? We'll rephrase this to include IPv4 as well. I am not seeing the general statement here. > > ### Section 3.2 > > Except for the first sentence, all the rest of this section appears to work > only with CGN and not proxies. Please clarify that this is also applicable to > proxies. We'll add a general statement that all statements about CGN in this document also apply to proxies. Did Russ confirm these observations? > > Why restricting to only unsigned files `When reading data from an unsigned > prefixlen file, one MUST ignore data outside the referring inetnum: object's > address range.` ? I do not see why signed files can escape this common sense > check. This is implicitly done as the signature won'T be valid for address ranges outside the address range. @Russ can you confirm this? > > ### Section 6 > > Why using an IP address range rather than the usual prefix notation used > through all this I-D in `The RPKI Signature's IP address range MUST match that > of the prefixlen URL in the inetnum: that points to the prefixlen file.` ? @Russ I defer to you on this one. Erik Kline posted this comment, but did not send it out, but I think it is not a bad idea. ### S3 * Consider possibly referencing RFC 4180 for CSV. Deb had the following COMMENTs but I have not see a response. Gorry and Roman had a similar comment. Section 6: So what is the chance that this is ever used? And if used, what is the chance that it will be done properly? [according to Section 9, para 4, 'not happening anytime soon'.] Section 9: So the choices are implement this with weak or no authentication, or with complex, stronger authentication (where the struggle will be doing it securely/properly)? Mike Bishop had a few COMMENTs as well I am not sure if I am seeing the clarification. > ### Empty fields > > Section 3 says "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." > However, the only instance where the second or third field can be empty is > mentioned in Section 3.3, where both are empty. > > Please consider clarifying the first statement to indicate that one empty > field > is valid only when both are empty, and replace/augment the "in certain > scenarios" with a forward-reference to this one scenario. > > (Or if there are other scenarios, describe them.) The third field can also be empty in the scenario where there is exactly '1' end-site in a prefix. We will clarify that. and finally a couple of COMMENTs from Roman, for which I am not sure I see a response (on list). > > ** Section 6 > Unfortunately, the RPSL in > some repositories is weakly authenticated at best. > > What does “weakly authenticated” mean? > > ** Section 9 > If signatures were mandatory, the above attack would be stymied, but > of course that is not happening anytime soon. > > Perhaps explain the “… of course that is not happening anytime soon” by > articulating “why not”. > I'll defer to @Russ Housley for the two points raised above. Will be happy to send the document for publication once these have been addressed. Thanks > On Dec 4, 2025, at 7:28 AM, [email protected] wrote: > > Internet-Draft draft-ietf-opsawg-prefix-lengths-12.txt is now available. It is > a work item of the Operations and Management Area Working Group (OPSAWG) WG of > the IETF. > > Title: Publishing End-Site Prefix Lengths > Authors: Oliver Gasser > Randy Bush > Massimo Candela > Russ Housley > Name: draft-ietf-opsawg-prefix-lengths-12.txt > Pages: 31 > Dates: 2025-12-04 > > Abstract: > > This document specifies how to augment the Routing Policy > Specification Language (RPSL) inetnum: class to refer specifically to > prefixlen files which are comma-separated values (CSV) files used to > specify end-site prefix lengths. This document also describes an > optional mechanism that uses the Resource Public Key Infrastructure > (RPKI) to authenticate the prefixlen files. > > The IETF datatracker status page for this Internet-Draft is: > https://datatracker.ietf.org/doc/draft-ietf-opsawg-prefix-lengths/ > > There is also an HTMLized version available at: > https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-prefix-lengths-12 > > A diff from the previous version is available at: > https://author-tools.ietf.org/iddiff?url2=draft-ietf-opsawg-prefix-lengths-12 > > Internet-Drafts are also available by rsync at: > rsync.ietf.org::internet-drafts > > Mahesh Jethanandani [email protected]
_______________________________________________ OPSAWG mailing list -- [email protected] To unsubscribe send an email to [email protected]
