[OPSAWG]Re: I-D Action: draft-ietf-opsawg-prefix-lengths-12.txt

[Mahesh Jethanandani <[e-mail]>]

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, [e-mail] 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
[e-mail]