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

Thanks very much for the work on this document and the discussion during IESG evaluation.

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

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

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"

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

# 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 <CRLF> sequence MUST be used to denote the end of each line
415	   of text.  A blank line is represented solely by the <CRLF> 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	   <CRLF> 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.