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.) ### 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" _______________________________________________ OPSAWG mailing list -- [email protected] To unsubscribe send an email to [email protected]
