Hi Mahesh,
Responses to the COMMENTs are inline.
Cheers,
Oliver
On 12/5/25 7:20 PM, Mahesh Jethanandani wrote:
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./
We already rephrased this stating that this is a general problem, but
especially problematic for IPv6 (due to its large address space).
/
/
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./
See Section 3: "In all places Carrier-Grade NAT or CGN is used in this
document, this applies to proxies as well."
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?/
We'll make this explicit in the next revision to be submitted shortly.
/
/
/> /
/> ### 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./
We'll add that.
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)?/
See here:
https://mailarchive.ietf.org/arch/msg/opsawg/nsq-Ex2HJL3DoW3l3TGo1Dp-mc4/
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./
The scenario is now explicitly mentioned in Section 3.1: "Note the third
field being set to '1', which signals the absence of CGN or proxies.
This has the same meaning as the third field being left empty in this
scenario."
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./
@Russ: Can you respond to the above two comments from Roman?
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]
