Thanks for your comments, Roman. Responses are inline.
Cheers,
Oliver
On 12/3/25 5:25 PM, Roman Danyliw via Datatracker wrote:
Roman Danyliw has entered the following ballot position for
draft-ietf-opsawg-prefix-lengths-08: Discuss
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer to
https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.
The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-opsawg-prefix-lengths/
----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------
** Section 4
An approach to introduce a new RPSL attribute of type extref: for
generic external references is described in
[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
Until all producers of inetnum: objects, i.e., the RIRs, state that
they have migrated to supporting a prefixlen: or extref: attribute,
consumers looking at inetnum: objects to find prefixlen URLs MUST be
able to consume the remarks:, prefixlen:, and extref: forms.
-- The above text makes [I-D.ymbk-opsawg-rpsl-extref] a normative reference.
It is currently listed as informative.
-- Is an expired, unadopted I-D appropriate?
Deferring to @Randy as he is also an author of the referenced I-D.
** Section 5.
To minimize the load on RIRs' WHOIS [RFC3912] services, the RIR's FTP
[RFC0959] services SHOULD be used for large-scale access to gather
inetnum: instances with prefixlen references.
Why can’t HTTPS be used? The RIRs all appear to provide:
https://ftp.arin.net/
https://ftp.ripe.net/
https://ftp.lacnic.net/
https://ftp.afrinic.net/
https://ftp.apnic.net/
Yes, you're correct. We'll update that in the text.
----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------
Thank you to Roni Even for the GENART review.
** Section 1.
[I-D.ietf-opsec-ipv6-addressing] also raises
this issue.
Unclear why this would be needed if the issue was already explained without
reference.
We'll remove the reference then.
** Section 3.5
prefixlen data for large providers with significant horizontal scale
and high granularity can be quite large. The size of a file can be
even larger if an unsigned prefixlen file combines data for many
prefixes, if dual IPv4/IPv6 spaces are represented, etc.
-- What does a publisher or consumer implementation do with these qualitative
statements?
We'll add a quantifiable statement.
-- What is “quite large”
See above.
** 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.
_______________________________________________
OPSAWG mailing list -- [email protected]
To unsubscribe send an email to [email protected]
