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? ** 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/ ---------------------------------------------------------------------- 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. ** 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? -- What is “quite large” ** 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”. _______________________________________________ OPSAWG mailing list -- [email protected] To unsubscribe send an email to [email protected]
