Thanks for your comments, Mike! More details inline.
Cheers, Oliver On 12/2/25 8:52 PM, Mike Bishop via Datatracker wrote:
Mike Bishop has entered the following ballot position for draft-ietf-opsawg-prefix-lengths-08: No Objection 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/ ---------------------------------------------------------------------- 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.)
The third field can also be empty in the scenario where there is exactly '1' end-site in a prefix. We will clarify that.
### 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.
We'll change this to "mechanism".
### 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.
We'll emphasize that the difference between IPv4 and IPv6 in this situation is the larger address space.
### 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.
We'll change it to this.
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"
Will fix.
_______________________________________________ OPSAWG mailing list -- [email protected] To unsubscribe send an email to [email protected]
