OSPFv2 Anycast Property Advertisement
draft-ietf-lsr-anycast-flag-13

Thanks to Wes Hardaker for their multiple secdir reviews.

A glimpse of the "good ole IPv4" OSPFv2 ;-)

This sounds like a useful addition, but it would be nice to explain why `It is useful for other routers to know` as written in the abstract and in the introduction.

Finally, the shepherd's write-up misses the justification for the intended status.

Thanks for the work done

-éric

PS: nice to have such a sweet and easy I-D as my last AD review of 2025 ;-)

Thanks for the work is described in this document. I do not see any transport-protocol related concerns for this document.

Thanks to all the folks who have provided review comments on this document. In particular want to call out OPSDIR review comments from Juergen, and YANG Doctor comments provided by Joe Clarke. Some of these comments builds on the review they have provided.

Section 1, paragraph 0
>    An IP prefix may be configured as anycast and as such the same value
>    can be advertised by multiple routers.  It is useful for other
>    routers to know that the advertisement is for an anycast prefix.

I agree with Juergen that this section could do more to explain the motivation for the draft, and move all the implementation details to later sections.
For example, and as Juergen asks, what are the implications of other routers not knowing about the advertisement? I know that Ran provided the explanation in his response, but it would be even better if that was added here.

Section 2, paragraph 0
>    An IP prefix may be configured as anycast and it is useful for other
>    routers to know that the advertisement is for an anycast prefix.

I would encourage the authors to add some of the responses Ran gave to the OPSDIR review to be added in this document. In this case, the question asked was, what is prefix and where is it being applied? This might be obvious to "router folks" but it cannot be assumed that everyone knows what it means.

Section 4.2, paragraph 0
>    The following is the YANG module:

Please reference all the RFC from which the module imports data from or refers to. For example, it could say - "This YANG module imports definitions from [RFC8349] and [RFC9129]".

Section 4.2,

The file name "ietf-ospf-anycast-flag@2025-08-28.yang" does not match the revision of the module:

  revision 2025-11-18 {
    description
      "Initial version";
    reference
      "RFC XXXX: OSPFv2 Anycast Property Advertisement";
  }

Please make sure they are the same.

Section 6.2, paragraph 3
>    There are a number of data nodes defined in this YANG module that are
>    writable/creatable/deletable (i.e., config true, which is the
>    default).  These data nodes can be considered sensitive or vulnerable
>    in some network environments.  Write operations (e.g., edit-config)
>    to these data nodes without proper protection can have a negative
>    effect on network operations.  Specifically, the following subtrees
>    and data nodes have particular sensitivities/vulnerabilities:

Is it true that this YANG module defines multiple data nodes? I can see only one. The last statement should also be corrected for its pluarity.

Section 6.2, paragraph 3
>    As specified in Section 2, the AC-flag and the N-flag MUST NOT both
>    be set to 1.  An attacker or a misconfiguration that violates this
>    rule creates a configuration anomaly.  The handling of such anomalies
>    is defined in Section 2.  Modifications to these data nodes without
>    proper protection could prevent interpreting the IPv4 prefix as
>    anycast or node-specific.

If the idea is to detect a configuration anomaly, why is that not detected using a "must" statement? Please add one. Otherwise, this hardly belongs in a Security Considerations section.

Section 6.2, paragraph 3
>    Some of the readable data nodes in this YANG module may be considered
>    sensitive or vulnerable in some network environments.  It is thus
>    important to control read access (e.g., via get, get-config, or
>    notification) to these data nodes.  Specifically, the following
>    subtrees and data nodes have particular sensitivities/
>    vulnerabilities:

Same issue with pluraity in this section.

Section 6.2, paragraph 3
>    Exposure of the OSPF link state database may be useful in mounting
>    Denial-of-Service (DoS) attacks.

How is lsdb being exposed by this model? If not, please remove.

Finally, an example showing the use of the new flag and the identity in an instance data example would really help.

-------------------------------------------------------------------------------
NIT
-------------------------------------------------------------------------------

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

"I", paragraph 2
> OULD be logged as an operational error(subject to rate-limiting). The AC-fla
>                                       ^
It appears that a white space is missing.

"I", paragraph 9
> eted according to OSPFv2 [RFC7684]. Thus the Flags field of the BGP-LS Prefix
>                                     ^^^^
A comma may be missing after the conjunctive/linking adverb "Thus".

# IESG review of draft-ietf-lsr-anycast-flag-10

CC @MikeBishop

## Comments

### Section 6.1, paragraph 2

This doesn't need 2119 keywords; just highlight the requirement for receivers.

## Nits

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

### Typos

#### Section 5.1, paragraph 1
```
-    This document requests the allocation of new value in the "OSPFv2
+    This document requests the allocation of a new value in the "OSPFv2
+                                             ++
```

### Grammar/style

#### Section 2, paragraph 3
```
OULD be logged as an operational error(subject to rate-limiting). The AC-fla
                                      ^
```
It appears that a space is missing.

#### Section 2, paragraph 10
```
eted according to OSPFv2 [RFC7684]. Thus the Flags field of the BGP-LS Prefix
                                    ^^^^
```
A comma may be missing after the conjunctive/linking adverb "Thus".