[OPSEC] Adam Roach's No Objection on draft-ietf-opsec-urpf-improvements-03: (with COMMENT)

[Adam Roach via Datatracker <[e-mail]>]

Adam Roach has entered the following ballot position for
draft-ietf-opsec-urpf-improvements-03: 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/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-opsec-urpf-improvements/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks for a clearly written document. My understanding of routing is pretty
simplistic, and I still found the technique well-explained and easy to follow.
This is no small feat. The one term I had to go searching for was "stub AS". If
this is a generally known term, that's fine -- but if not, it may warrant a
short definition or citation.

---------------------------------------------------------------------------

§1.1:

>  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>  "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
>  document are to be interpreted as described in RFC 2119 [RFC2119].

Please use the boilerplate from RFC 8174.

---------------------------------------------------------------------------

§3.3:

I believe I understand how the described Algorithm B, is applied by AS4, will
result in acceptance of AS1's packets from AS2. I'm a bit lost, however, about
the means by which AS2 will accept them such that they could be delivered to
AS4.  Is there an assumption that AS2 is employing an ACL-based approach? If
so, this should probably be stated explicitly. (This might be implied by text
elsewhere, in which case I apologize for my confusion; although it may still be
worth explicitly explaining.)

---------------------------------------------------------------------------

§3.5:

>  It is worth emphasizing that an indirect part of the proposal in the
>  draft is that RPF filters may be augmented from secondary sources.

Nit: "the draft" won't age gracefully. I suggest changing to "this document"
or somesuch.

---------------------------------------------------------------------------

§3.6.1:

>  +---------------------------------+---------------------------------+
>  | Very Large Global ISP           | 32392                           |
>  | ------------------------------- | ------------------------------- |
>  | Very Large Global ISP           | 29528                           |
>  | ------------------------------- | ------------------------------- |

I suspect there was a transcription error copying these lines from the source
material, as the appearance of two rows with identical labels seems unlikely
to be intended. I skimmed the cited source material to see if I could figure
out what happened here, but found neither of these numbers (nor any mention of
"Mid-size Global ISP"), so I'm afraid I can't make a concrete suggestion for a
fix. I did find that adding the numbers in the first column on slide 6
yielded 32393, which is tantalizingly close to the first number, but that
might just be a coincidence.