Publishing End-Site Prefix Lengths
draft-ietf-opsawg-prefix-lengths-14

[Ballot comment]
(revised ballot for -11)

Thank you to Roni Even for the GENART review.

Thank for addressing my DISCUSS feedback and parts of my COMMENT feedback.

** 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”.

[Ballot comment]
Thanks for resolving my (Sean's?) discuss.  I've left the comments below for historical reasons.

Thanks to Valery Smyslov for their secdir review.

This is well outside my normal area of expertise, however I had a couple of comments.  It isn't clear to me that there are no answers (which is why I didn't discuss them).

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)?

[Ballot discuss]
[ Sorry, I updated my COMMENTS to a DISCUSS, see below ]



        To minimize the load on RIRs' WHOIS [RFC3912] services, the
        RIR's FTP [RFC0959] services SHOULD be used for large-scale
        access to gather

I can't really ignore the fact that unsigned data is urged to be transfered
in the clear possibly (likely?) without authentication. Why can this data
not be made available over HTTPS ? (I understand RDAP might address this)

Update: I was told that all RIRs now support an HTTPS frontend for their ftp sides, eg:

https://ftp.arin.net/
https://ftp.ripe.net/
https://ftp.lacnic.net/
https://ftp.afrinic.net/
https://ftp.apnic.net/

In which case I think the RFC should say that FTP MUST NOT be used, but HTTPS MUST be used.

[Ballot comment]
I support Deb/Sean's DISCUSS on the ASN.1 module.
        [...] the authenticator is invalid.

What does this mean? Should all the data be thrown away? Should it be processed
as unauthenticated? If so, what would that mean in practise ?

Similarly for:

        All of the above steps MUST be successful to consider the
        prefixlen file signature as valid.

What if it is not valid?

        The prefixlen files MUST be published via and fetched using HTTPS [RFC9110].

Does this contradict this earlier statement?

        This document provides a guideline for how interested parties
        should fetch and read prefixlen files. 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.

Either this contradicts, or if the FTP fetch is to fetch data points
that point to where to fetch prefixlen files, then an attacker can
still fetch the prefixlen files over HTTPS, filter the signature(s),
modify what it wants, then serve this over their own HTTPS server by
updating the FTP fetch stream as MITM to point to its own HTTPS server?

Update: I think this should also note to use the HTTPS frontends of the FTP services.

So I am not sure I can agree with the following text in the Security Considerations
section:

        As mentioned in Section 6, some RPSL repositories have weak, if
        any, authentication. This allows spoofing of inetnum: objects
        pointing to malicious prefixlen files. Section 6 suggests an
        unfortunately complex method for stronger authentication based
        on the RPKI.

I think Section 6 still has an FTP fetch in its process that can be manipulated
to bypass the stronger authentication?

Update: this would be resolved if HTTPS is required.

[Ballot 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/

[Ballot 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”.

SMI Expert: "Did a quick look at this and have a questions about why there’s no ASN.1 module that formally defines the content type? The knock on effects for adding a module that come to mind would be:
- another section for the ASN.1 module
- another IANA request for SMIME ASN.1 Module Arc
- normative refs to X.680, X.690, & RFC 5911 (imports CONTENT-TYPE)"

[Ballot comment]
I support Deb/Sean's DISCUSS on the ASN.1 module.

The comments below I would have normally filed as a DISCUSS, but I think there is just no way to address these, and we will just have to wait for evolution in the RIR space to improve things.


        To minimize the load on RIRs' WHOIS [RFC3912] services, the
        RIR's FTP [RFC0959] services SHOULD be used for large-scale
        access to gather

I can't really ignore the fact that unsigned data is urged to be transfered
in the clear possibly (likely?) without authentication. Why can this data
not be made available over HTTPS ? (I understand RDAP might address this)


        [...] the authenticator is invalid.

What does this mean? Should all the data be thrown away? Should it be processed
as unauthenticated? If so, what would that mean in practise ?

Similarly for:

        All of the above steps MUST be successful to consider the
        prefixlen file signature as valid.

What if it is not valid?

        The prefixlen files MUST be published via and fetched using HTTPS [RFC9110].

Does this contradict this earlier statement?

        This document provides a guideline for how interested parties
        should fetch and read prefixlen files. 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.

Either this contradicts, or if the FTP fetch is to fetch data points
that point to where to fetch prefixlen files, then an attacker can
still fetch the prefixlen files over HTTPS, filter the signature(s),
modify what it wants, then serve this over their own HTTPS server by
updating the FTP fetch stream as MITM to point to its own HTTPS server?

So I am not sure I can agree with the following text in the Security Considerations
section:

        As mentioned in Section 6, some RPSL repositories have weak, if
        any, authentication. This allows spoofing of inetnum: objects
        pointing to malicious prefixlen files. Section 6 suggests an
        unfortunately complex method for stronger authentication based
        on the RPKI.

I think Section 6 still has an FTP fetch in its process that can be manipulated
to bypass the stronger authentication?

[Ballot discuss]
Courtesy of Sean Turner while looking at the CMS registry request:  "Did a quick look at this and have a questions about why there’s no ASN.1 module that formally defines the content type? The knock on effects for adding a module that come to mind would be:
- another section for the ASN.1 module
- another IANA request for SMIME ASN.1 Module Arc
- normative refs to X.680, X.690, & RFC 5911 (imports CONTENT-TYPE)"

[Ballot comment]
Thanks to Valery Smyslov for their secdir review.

This is well outside my normal area of expertise, however I had a couple of comments.  It isn't clear to me that there are no answers (which is why I didn't discuss them).

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)?

[Ballot discuss]
# Andy Newton, ART AD, comments for draft-ietf-opsawg-prefix-lengths-08
CC @anewton1998

* line numbers:
  - https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-opsawg-prefix-lengths-08.txt&submitcheck=True

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

## Discuss

As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/,
a DISCUSS ballot is just a request to have a discussion on the following topics.

### Problematic UTF8

138        prefixlen files are CSV (Comma Separated Values) files in UTF-8
139        [RFC3629] text format; not HTML, richtext, or other formats. ...

RFC 9839 describes problematic UTF-8 code points which are likely inappropriate
for this specification. Scanning the code points for US-ASCII that are defined
in RFC 4180, it would appear that some of them do fall within the problematic set
if there is to be a straightforward translation of the US-ASCII to UTF-8.
Would it be appropriate to restrict the UTF-8 to non-problematic sets as
described in RFC 9839?

Also (more of a comment, not a discuss), the wording "not HTML, richtext, ..." is confusing, in my opinion. Those
are document formats not character encodings, and my first read left me questioning
what they had to do with UTF-8.

### Skipping Errors

237        Upon encountering an erroneous entry in a prefixlen file, consumer
238        implementations SHOULD skip that entry, log the error, and continue
239        processing the remaining entries.

Under what circumstances is it ok for a consumer to continue processing an
entry it knows to be an error? If you think there are none, what about this proposed change:

>  Upon encountering an erroneous entry in a prefixlen file, consumer
>  implementations MUST skip that entry, and SHOULD log the error, and continue
>  processing the remaining entries.

### Transition From Remarks

298        An approach to introduce a new RPSL attribute of type extref: for
299        generic external references is described in
300        [I-D.ymbk-opsawg-rpsl-extref].  With this extref approach a prefixlen
301        can be referenced as follows:

303                  inetnum: 192.0.2.0/24 # example
304                  extref: Prefixlen https://example.com/prefixlen

The extref draft appears to have been expired for six months now. Are you sure
you want to reference a document that does not appear to be progressing.

306        Until all producers of inetnum: objects, i.e., the RIRs, state that
307        they have migrated to supporting a prefixlen: or extref: attribute,
308        consumers looking at inetnum: objects to find prefixlen URLs MUST be
309        able to consume the remarks:, prefixlen:, and extref: forms.

The extref draft is used in normative language here, but is listed as an
informative reference.

Also, I am confused by this transition strategy. If 2 of the RIRs switch
to prefixlen and 3 switch to extref, does that mean consumers can thus ignore
remarks?

Additionally, this appears to be a departure from RFC 9632, which states:

> This document allows, but discourages, an inetnum: to have
> both a geofeed remarks: attribute and a geofeed: attribute.

If we had to discourage the dual usage pattern from RFC 9092 with obsoletion in
RFC 9632, is it appropriate to have the dual usage pattern here?

### RDAP Remarks

607        At the time of publishing this document, the registry data published
608        by ARIN are not the same RPSL as that of the other registries (see
609        [RFC7485] for a survey of the WHOIS Tower of Babel); therefore, when
610        fetching from ARIN via FTP [RFC0959], WHOIS [RFC3912], the
611        Registration Data Access Protocol (RDAP) [RFC9082], etc., the
612        "NetRange" attribute/key must be treated as "inetnum", and the
613        "Comment" attribute must be treated as "remarks".

The reference to RDAP is inappropropriate as it has neither NetRange nor Comment.
Additionally, the appropriate RDAP RFC would be RFC 9083 as that describes the
ip network object class, not RFC 9082. Regarding the NetRange key, it might also
be useful to refer to the CIDR0 extension.

[Ballot comment]
## Comments

### Geolocation Use Case

110        *  Geolocation: Getting the right prefix size for IPv6 geolocation is
111          similarly hard.  If you aggregate too much, you throw together
112          different clients in different locations, and if you aggregate too
113          little, you fill up the geolocation database with unnecessary
114          entries.

Does this imply that RFC 9632, from which this document borrows many concepts,
is inappropriate for IPv6 geolocation?

## Nits

### RDAP GeoFeeds

362        On the other hand, RIRs are converging on RDAP support which includes
363        geofeed data, see [I-D.ietf-regext-rdap-geofeed].  It is hoped that
364        this will be extended, or generalized, to support prefixlen data.

This is now RFC 9877.

[Ballot comment]
Generally speaking, this document is solid. My one overall feedback would be to improve the equality of presentation between IPv4 and IPv6, rather than presenting a primarily-IPv4 mechanism with an aside that IPv6 works the same way.

## COMMENTS (non-blocking)

### 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.)

### Abstract, Scheme

Considering that "scheme" is a technical term with implications across much of the IETF, consider choosing an alternate word -- "mechanism", perhaps? Section 1 uses "means", while Section 6 refers to it as "an optional authenticator". Either of those seem fine.

### Section 1, IPv4/6 wording

Blocking/throttling: Variable prefix lengths aren't a trait of IPv4. Consider wording this to reflect that while the lengths will differ between IP versions, the overarching problem is the same.

### Section 4, clarity

The first sentence of Section 4 probably needs its commas adjusted to help parse the outer sentence correctly; consider parentheses instead:

CURRENT: The original RPSL specifications starting with [RIPE81], [RIPE181], and a trail of subsequent documents were written by the RIPE community.

CONSIDER: The original RPSL specifications ([RIPE81], [RIPE181], and a trail of subsequent documents) were written by the RIPE community.

OR PERHAPS: The RIPE community produced the original RPSL specifications: [RIPE81], [RIPE181], and a trail of subsequent documents.

## NITS (non-blocking)

- Section 4, "can not" => "cannot"

[Ballot comment]
# Orie Steele, ART AD, comments for draft-ietf-opsawg-prefix-lengths-08
CC @OR13

* line numbers:
  - https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-opsawg-prefix-lengths-08.txt&submitcheck=True

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

## Comments

### Signing Canonicalization & UTF-8

```
138   prefixlen files are CSV (Comma Separated Values) files in UTF-8
139   [RFC3629] text format; not HTML, richtext, or other formats.  Lines
140   MUST be delimited by a line break (CRLF), and blank lines MUST be
141   ignored.  Text from a '#' character to the end of the current line
142   MUST be treated as a comment only and is similarly ignored.  The
143   first field of each non-ignored line specifies the prefix in
144   question, the second field the end-site prefix length within that
145   prefix as an integer, and the third field the number of end-sites
146   within an end-site prefix length for networks using Carrier-Grade NAT
147   (CGN) [RFC6598].  Note that all three fields MUST be present.  This
148   means there MUST be exactly two commas in each non-commented line
149   delimiting the three fields.  The first field MUST NOT be empty on
150   lines which are not comments, while the second and third field can be
151   empty in certain scenarios.
```

... later ...

```
412   The canonicalization procedure converts the data from their internal
413   character representation to the UTF-8 [RFC3629] character encoding,
414   and the  sequence MUST be used to denote the end of each line
415   of text.  A blank line is represented solely by the  sequence.
416   For robustness, any non-printable characters MUST NOT be changed by
417   canonicalization.  Trailing blank lines MUST NOT appear at the end of
418   the file.  That is, the file must not end with multiple consecutive
419     sequences.  Any end-of-file marker used by an operating system
420   is not considered to be part of the file content.  When present, such
421   end-of-file markers MUST NOT be covered by the digital signature.
```

You might find https://datatracker.ietf.org/doc/rfc9839/ helpful for being more precise about the repertoire.

This text seems to suggest that the first and second fields can contain non-printable characters, and whitespace.

A more restricted ABNF might be helpful here.

[Ballot comment]

# Éric Vyncke INT AD comments for draft-ietf-opsawg-prefix-lengths-08
CC @evyncke

Thank you for the work put into this document. This document addresses a real issue especially for IPv6 networks.

Please find below some non-blocking COMMENT points/nits (replies would be appreciated even if only for my own education).

Special thanks to John Levine for the shepherd's detailed write-up including the WG consensus (noting only 4 reviewers :-( ...) *but it lacks* the justification of the intended status especially since this I-D could have been BCP or informational.

Other thanks to Sheng Jiang, the Internet directorate reviewer, that reviewed this I-D as "ready":
https://datatracker.ietf.org/doc/review-ietf-opsawg-prefix-lengths-08-intdir-lc-jiang-2025-11-09/

I hope that this review helps to improve the document,

Regards,

-éric

Note: this ballot comments follow the Markdown syntax of https://github.com/mnot/ietf-comments/tree/main, i.e., they can be processed by a tool to create github issues.

## COMMENTS (non-blocking)

### Intended status

Did the WG discuss whether this I-D should be published as BCP or informational rather than PS ?

### Section 1

Should there be a reference to `CAPTCHA` ? E.g., in 10 years, people may wonder what this was about...

Is it really only an IPv6 issue in `prefix size for IPv6 geolocation` ?

Why "should" rather than "must" in `In all places inetnum: is used, inet6num: should also be assumed` ?

### Section 3

s/using Carrier-Grade NAT (CGN) [RFC6598]/using Carrier-Grade NAT (CGN) [RFC6598] *or proxies*/

### Section 3.1

`Note the third field being set to '1', which signals the absence of CGN or proxies.` why not empty in this case ? I.e., what is the meaning of an empty 3rd field ?

### 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.

### Section 3.3

`If both the second and third fields are empty, this means that the publisher does not want to disclose any prefix length information.` should really be in section 3. (note: I hesitated to raise a blocking DISCUSS on this point).

### Section 3.4

This section (longest prefix) must appear before section 3.3 as section 3.3 example uses longest prefix match.

### Section 3.5

Why not a "MUST" in `Publishers SHOULD take measures to ensure there is one and only one entry per prefix` and in `consumer implementations SHOULD skip that entry` ?

Please define `significant horizontal scale` or use other terms.

`This document also suggests an optional signature` should probably be in the introduction section.

### Section 4

What an ugly nightmare to be backward compatible...

Why does this I-D proposes `extref: Prefixlen` in addition to `prefixlen:` ? The client then would have to process only `prefixlen:` and `remarks: Prefixlen`. I am also unclear why not only `prefixlen:` having intermediate steps can be cumbersome on the long term as 'remarks: Prefixlen' will probably stay forever.

### Section 5

Does the discussion about RDAP vs. WHOIS relevant to this I-D ? IMHO, it is much broader, i.e., it does not belong within this I-D.

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.

### 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.` ?

### Section 7

This section contains the first use of NIR and LIR. Should this rather be done in the introduction or terminology by stating (like for the equivalence of IPv4 and IPv6) that "using RIR for RIR/LIR/NIR"?

Isn't the last paragraph implicit by the normal use of HTTP (and associated CDN/proxies)?

### Section 8

s/At the time of publishing this document/In November 2025/

`the "NetRange" attribute/key must be treated as "inetnum", and the "Comment" attribute must be treated as "remarks".` should this be part of section 4 ? Of course at the obvious risk of offering even more choices :-(


## NITS (non-blocking / cosmetic)

### draft-ietf-regext-rdap-geofeed

As indicated by id-nit, draft-ietf-regext-rdap-geofeed is now RFC 9877, please update the references.

###  e.g.

s/ e.g./, e.g.,/
s/i.e./, i.e.,/

[Ballot comment]
Thanks for the work is described in this document. I do not see any transport-related concerns for this document.

The following is probably not the most obvious formulation of words to see in a future RFC;-).
"If signatures were mandatory, the above attack would be stymied, but
of course that is not happening anytime soon."

[Ballot comment]
# Internet AD comments for draft-ietf-opsawg-prefix-lengths-08
CC @ekline

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

## Comments

### S3

* Consider possibly referencing RFC 4180 for CSV.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

Four people and a reviewer commented, all favorably.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

No major controversy, minor points all resolved.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

RIPE NCC says they'll implement it:

https://mailarchive.ietf.org/arch/msg/opsawg/d0Y6-yyZOJc6vjVnDeDIKJwUBgU/

A large mail provider has informally told me they will use this information
to enable IPv6 mail.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

No close interactions, one informal review:
https://mailarchive.ietf.org/arch/msg/opsawg/6oJpwS0VQAvZe32MLCCaqS_5N-4/

INTDIR and GENART reviews said ready. RTGDIR said it had nits but reviewer now says it's ready.
https://mailarchive.ietf.org/arch/msg/rtg-dir/I0aWMp6_miutWm_rMtE3rXQwhK4/

Smyslov's SECDIR review had issues, resolved in later discussion.
https://mailarchive.ietf.org/arch/msg/secdir/mrbbM-UaI8j4gIzTR0MsC2Zhh7U/

OPSDIR review had nits, now resolved.
https://mailarchive.ietf.org/arch/msg/ops-dir/Mlg-Y9UpJcYwFDQeD5ff54l-92E/

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

None.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

N/A


8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

N/A

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Yes.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

N/A

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Proposed standard, Datatracker is consistent with that.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Authors confirmed they're not aware of any more IPR after Orange filed
IPR disclosure 6622, updated by 6641.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

Yes.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

None, idnits stuff all looks like false alarms.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

No.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

N/A

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

No.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

No

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

One new registry entry, expert is one of the draft's authors so I expect it's OK.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

N/A

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

Four people and a reviewer commented, all favorably.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

No major controversy, minor points all resolved.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

RIPE NCC says they'll implement it:

https://mailarchive.ietf.org/arch/msg/opsawg/d0Y6-yyZOJc6vjVnDeDIKJwUBgU/

A large mail provider has informally told me they will use this information
to enable IPv6 mail.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

No close interactions, one informal review:
https://mailarchive.ietf.org/arch/msg/opsawg/6oJpwS0VQAvZe32MLCCaqS_5N-4/

INTDIR and GENART reviews said ready. RTGDIR said it had nits but reviewer now says it's ready.
One SECDIR an OPSDIR review had nits, other SECDIR review has issues.


6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

None.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

N/A


8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

N/A

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Yes.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

N/A

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Proposed standard, Datatracker is consistent with that.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Authors confirmed they're not aware of any more IPR after Orange filed
IPR disclosure 6622, updated by 6641.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

Yes.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

None, idnits stuff all looks like false alarms.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

No.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

N/A

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

No.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

No

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

One new registry entry, expert is one of the draft's authors so I expect it's OK.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

N/A

Authors, the document has completed IETF LC. However, several *DIR reviews have been performed on the document. Some have nits, but others such as RTGDIR review from Michael asks several questions. Please address those questions before I progress the documents further.

IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-opsawg-prefix-lengths-08. If any part of this review is inaccurate, please let us know.

IANA has a question about one of the actions requested in the IANA Considerations section of this document.

IANA understands that, upon approval of this document, there are two actions which we must complete.

First, in the SMI Security for S/MIME CMS Content Type (1.2.840.113549.1.9.16.1) registry in the Structure of Management Information (SMI) Numbers (MIB Module Registrations) registry group located at:

https://www.iana.org/assignments/smi-numbers/

a single new registration is to be made as follows:

Decimal: [ TBD-at-Registration ]
Description: id-ct-prefixlenCSVwithCRLF
Reference: [ RFC-to-be ]

IANA notes that the authors have requested decimal 47 for this registration but that value is not available for registration.

As this document requests registrations in an Expert Review or Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. This review must be completed before the document's IANA state can be changed to "IANA OK."

Second, the draft requests the following:

"In the SMI Security for S/MIME CMS Content Type (1.2.840.113549.1.9.16.1) in the Structure of Management Information (SMI) Numbers (MIB Module Registrations) registry group located at: https://www.iana.org/assignments/smi-numbers/ there is no existing registration for prefixlen files yet. On publication of this document, that reference needs to be changed to the new [ RFC-to-be ]."

IANA Question --> Could the authors identify specifically which registration needs to have it's reference changed?

We understand that these are the only actions required to be completed upon approval of this document.

NOTE: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Sr. Specialist

The following Last Call announcement was sent out (ends 2025-11-12):

From: The IESG
To: IETF-Announce
CC: draft-ietf-opsawg-prefix-lengths@ietf.org, johnl@taugh.com, mjethanandani@gmail.com, opsawg-chairs@ietf.org, opsawg@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Publishing End-Site Prefix Lengths) to Proposed Standard


The IESG has received a request from the Operations and Management Area
Working Group WG (opsawg) to consider the following document: - 'Publishing
End-Site Prefix Lengths'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2025-11-12. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

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 scheme that uses the Resource Public Key Infrastructure
  (RPKI) to authenticate the prefixlen files.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-opsawg-prefix-lengths/


The following IPR Declarations may be related to this I-D:

  https://datatracker.ietf.org/ipr/6641/
  https://datatracker.ietf.org/ipr/6622/

Based on the responses received from Valery (SECDIR), authors responding to Adrian's (OPSDIR) review, and now Russ responding to Michael's RTG-area review, I believe the document is ready to proceed.

However, this is not the final gate. Reviewers can continue their discussion while the IETF WGLC is in progress, and I will make a note of it before it is sent for IESG evaluation.

Based on the response from Michael, see https://mailarchive.ietf.org/arch/msg/opsawg/ONU2-H2ClKJWUHxfrIytiLu0tJE/, it appears further changes are needed in the draft. If the authors disagree, can they articulate that or respond to the thread? Thanks!

The following people have provided reviews on the documents. Thanks to them.
- Michael Richardson RTGDIR
- Valery Smyslov SECDIR
- Adrian Farrel OPSDIR

Authors, please address comments and update the draft as needed. Marking the document for "Revised I-D Needed".

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

Four people and a reviewer commented, all favorably.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

No major controversy, minor points all resolved.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

RIPE NCC says they'll implement it:

https://mailarchive.ietf.org/arch/msg/opsawg/d0Y6-yyZOJc6vjVnDeDIKJwUBgU/

A large mail provider has informally told me they will use this information
to enable IPv6 mail.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

No close interactions, one informal review:

https://mailarchive.ietf.org/arch/msg/opsawg/6oJpwS0VQAvZe32MLCCaqS_5N-4/

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

None.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

N/A


8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

N/A

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Yes.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

N/A

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Proposed standard, Datatracker is consistent with that.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Authors confirmed they're not aware of any more IPR after Orange filed
IPR disclosure 6622, updated by 6641.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

Yes.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

None, idnits stuff all looks like false alarms.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

No.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

N/A

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

No.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

No

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

One new registry entry, expert is one of the draft's authors so I expect it's OK.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

N/A

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

Four people and a reviewer commented, all favorably.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

No major controversy, minor points all resolved.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

RIPE NCC says they'll implement it:

https://mailarchive.ietf.org/arch/msg/opsawg/d0Y6-yyZOJc6vjVnDeDIKJwUBgU/

A large mail provider has informally told me they will use this information
to enable IPv6 mail.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

No close interactions, one informal review:

https://mailarchive.ietf.org/arch/msg/opsawg/6oJpwS0VQAvZe32MLCCaqS_5N-4/

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

None.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

N/A


8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

N/A

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Yes.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

N/A

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Proposed standard, Datatracker is consistent with that.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Authors confirmed they're not aware of any more IPR after Orange filed
IPR disclosure 6622, updated by 6641.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

Yes.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

None, idnits stuff all looks like false alarms.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

No.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

N/A

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

No.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

No

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

One new registry entry, expert is one of the draft's authors so I expect it's OK.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

N/A