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

[Ballot comment]
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".

[Ballot comment]
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 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".

[Ballot comment]
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 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.

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

[Ballot comment]
Hi Ran, Detao, Peter, Ketan, and Changwang,

Thanks for addressing in -10 all the comments raised in my previous ballot.

Cheers,
Med

** -09 Ballot (Addressed) **

Thank you for the effort put into this specification, which is about mirroring a functionality already specified for IS-IS and OSPFv3.

Thanks to Juergen for the OPSDIR review and Ran for engaging. Some of the replies in the thread are better if echoed in the document (e.g., backward compatibility mention).

I would ballot Yes if two first points below were addressed.

I have two main points and a set of more low-level comments:

# Summarization

CURRENT:
  The AC-flag MUST be preserved when re-advertising the prefix across
  areas.

Wouldn’t that be lost if the prefix is covered a summarized adv by an ABR?

Maybe tweak this as?

NEW:
    The AC-flag MUST be preserved when the
    OSPFv2 Extended Prefix Opaque LSA is propagated between areas.

# Operational Considerations

## Consistent configuration

In addition to the backward compatibility mentioned above, I would add a brief discussion that basically say that anycast prefixes should be consistently managed through the network. Stale configuration of a prefix tagged as anycast may have implications as that value will take precedence over other same prefix announcement with AC-flag set to 0. 

## Anomalies

You may also add a point retrieval of a router configuration having N-flag and AC-flag set to 1 for a given prefix should be used as an indication of configuration anomaly.

Alos, consider adding a point that receipt of adv with both N-flag and AC-flag set to 1 can be used as an indication of configuration anomaly. This can be used by a network controller.

BTW, how such function is supposed to be done using the YANG-based interface? Is retrieval of prefix flags from peers covered by the base YANG OSPF module? If so, please add a mention of the data nodes used for that purpose.

## Please find below some additional comments, fwiw:

## Identifier

CURRENT:
  It is useful for other
  routers to know that the advertisement is for an anycast identifier.

I appreciate this text is grabbed from SR OSPF/IS-IS extension, but I would s/anycast identifier/ anycast prefix

## Mention the YANG augmentation in the abstract

OLD:
  This document defines a new flag in the OSPFv2 Extended Prefix TLV
  Flags to advertise the anycast property.

NEW:
  This document defines a new flag in the OSPFv2 Extended Prefix TLV
  Flags to advertise the anycast property. The document also specifies
  a companion YANG module for managing this function.

You may consider a mention in the introduction as well.

## set/clear 

You may add a mention to say that “set” meant “set to 1” and “clear” means “set to 0”.

## Curiosity

CURRENT:
  When a prefix is configured as anycast, the AC-flag MUST be set

Just out of curiosity, why the WG went for a distinct behavior for the IS-IS part as RFC9352 has: “When the prefix/SRv6 Locator is configured as anycast, the A-flag SHOULD be set”


## Manage vs configure

OLD:
  This section defines a YANG data model that can be used to configure
  and manage the usage of OSPFv2 Anycast Property as defined in this

NEW:
  This section defines a YANG data model that can be used to manage
  the usage of OSPFv2 Anycast Property as defined in this

“configure” is one of the management (FCAPS) function

## nit

OLD: The following show the tree diagram of the module:

NEW: The following shows the tree diagram of the module:

## No need to have the NMDA mention in the module (*)

Consider deleting:

CURRENT:
        This YANG module conforms to the Network Management
        Datastore Architecture (NMDA) as described in RFC 8342.

## The module is not only about configuration, but also retrieval (*)

(1)

OLD:
      "This YANG module adds the support of configuring an OSPFv2
        prefix as anycast.

NEW:
      "This YANG module adds the support of managing an OSPFv2
        prefix as anycast.

(2) Delete:

OLD:
/* Configuration */

(3)

OLD: "This augments the OSPFv2 interface configuration.";

NEW: "This augments the OSPFv2 interface.";

(4)

OLD: "This augments OSPFv2 interface configuration with anycast

NEW: "This augments OSPFv2 interface with anycast


## Update to follow the IETF template + no need to have a reference clause

OLD:
        This version of this YANG module is part of RFC XXXX;
        see the RFC itself for full legal notices.";
    reference
      "RFC XXXX";

NEW:
        All revisions of IETF and IANA published modules can be found
        at the YANG Parameters registry group
        (https://www.iana.org/assignments/yang-parameters).

        This version of this YANG module is part of RFC XXXX; see
        the RFC itself for full legal notices.";

## This is an identity, not a boolean

“when set” does not parse here.

OLD:
      description
        "Anycast flag.  When set, it indicates that the prefix
          is configured as anycast.";

NEW:
      description
        "Indicates that the prefix is configured as anycast.";

## Data node description

OLD:
      leaf anycast-flag {
        type boolean;
        default "false";
        description
          "Sets the prefix as an anycast address.";

NEW:
      leaf anycast-flag {
        type boolean;
        default "false";
        description
            “Indicates that the prefix is an anycast address, if set to 1.
            It indicates a node-specific prefix if set to 0.";

## Please update Section 6 to follow the template at https://datatracker.ietf.org/doc/html/draft-ietf-netmod-rfc8407bis-28#name-security-considerations-sect

## These are not normative

### Move RFC6241 and RFC8040 to be listed as Informative

### I don’t think RFC9085 is normative, but I leave it to you to double check.

Cheers,
Med

[Ballot comment]
# 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".

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

The document has strong consensus.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

No controversy. The YANG model augmentations were added based on Yingzhen's
review.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

No implementations. However, this will be very simple to implement once
the IANA assignments are maed.


## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

N/A

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

Both Routing Directorate and YANG doctors reviews are requested.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

No YANG errors. Validating using https://www.yangcatalog.org/yangvalidator


8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

N/A


## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Yes.


10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

N/A

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Proposed Standard. The document extends OSPF prefix encodings which need to be
standardized along with the IANA allocation.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Yes.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

Yes.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

Yes.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

No.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

N/A

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.
No   

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?
No.   

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

There is only one flag added to an existing registry. The correct registry
is chosen.


21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

N/A

[Ballot comment]
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 ;-)

[Ballot comment]
Hi Ran, Detao, Peter, Ketan, and Changwang,

Thank you for the effort put into this specification, which is about mirroring a functionality already specified for IS-IS and OSPFv3.

Thanks to Juergen for the OPSDIR review and Ran for engaging. Some of the replies in the thread are better if echoed in the document (e.g., backward compatibility mention).

I would ballot Yes if two first points below were addressed.

I have two main points and a set of more low-level comments:

# Summarization

CURRENT:
  The AC-flag MUST be preserved when re-advertising the prefix across
  areas.

Wouldn’t that be lost if the prefix is covered a summarized adv by an ABR?

Maybe tweak this as?

NEW:
    The AC-flag MUST be preserved when the
    OSPFv2 Extended Prefix Opaque LSA is propagated between areas.

# Operational Considerations

## Consistent configuration

In addition to the backward compatibility mentioned above, I would add a brief discussion that basically say that anycast prefixes should be consistently managed through the network. Stale configuration of a prefix tagged as anycast may have implications as that value will take precedence over other same prefix announcement with AC-flag set to 0. 

## Anomalies

You may also add a point retrieval of a router configuration having N-flag and AC-flag set to 1 for a given prefix should be used as an indication of configuration anomaly.

Alos, consider adding a point that receipt of adv with both N-flag and AC-flag set to 1 can be used as an indication of configuration anomaly. This can be used by a network controller.

BTW, how such function is supposed to be done using the YANG-based interface? Is retrieval of prefix flags from peers covered by the base YANG OSPF module? If so, please add a mention of the data nodes used for that purpose.

## Please find below some additional comments, fwiw:

## Identifier

CURRENT:
  It is useful for other
  routers to know that the advertisement is for an anycast identifier.

I appreciate this text is grabbed from SR OSPF/IS-IS extension, but I would s/anycast identifier/ anycast prefix

## Mention the YANG augmentation in the abstract

OLD:
  This document defines a new flag in the OSPFv2 Extended Prefix TLV
  Flags to advertise the anycast property.

NEW:
  This document defines a new flag in the OSPFv2 Extended Prefix TLV
  Flags to advertise the anycast property. The document also specifies
  a companion YANG module for managing this function.

You may consider a mention in the introduction as well.

## set/clear 

You may add a mention to say that “set” meant “set to 1” and “clear” means “set to 0”.

## Curiosity

CURRENT:
  When a prefix is configured as anycast, the AC-flag MUST be set

Just out of curiosity, why the WG went for a distinct behavior for the IS-IS part as RFC9352 has: “When the prefix/SRv6 Locator is configured as anycast, the A-flag SHOULD be set”


## Manage vs configure

OLD:
  This section defines a YANG data model that can be used to configure
  and manage the usage of OSPFv2 Anycast Property as defined in this

NEW:
  This section defines a YANG data model that can be used to manage
  the usage of OSPFv2 Anycast Property as defined in this

“configure” is one of the management (FCAPS) function

## nit

OLD: The following show the tree diagram of the module:

NEW: The following shows the tree diagram of the module:

## No need to have the NMDA mention in the module (*)

Consider deleting:

CURRENT:
        This YANG module conforms to the Network Management
        Datastore Architecture (NMDA) as described in RFC 8342.

## The module is not only about configuration, but also retrieval (*)

(1)

OLD:
      "This YANG module adds the support of configuring an OSPFv2
        prefix as anycast.

NEW:
      "This YANG module adds the support of managing an OSPFv2
        prefix as anycast.

(2) Delete:

OLD:
/* Configuration */

(3)

OLD: "This augments the OSPFv2 interface configuration.";

NEW: "This augments the OSPFv2 interface.";

(4)

OLD: "This augments OSPFv2 interface configuration with anycast

NEW: "This augments OSPFv2 interface with anycast


## Update to follow the IETF template + no need to have a reference clause

OLD:
        This version of this YANG module is part of RFC XXXX;
        see the RFC itself for full legal notices.";
    reference
      "RFC XXXX";

NEW:
        All revisions of IETF and IANA published modules can be found
        at the YANG Parameters registry group
        (https://www.iana.org/assignments/yang-parameters).

        This version of this YANG module is part of RFC XXXX; see
        the RFC itself for full legal notices.";

## This is an identity, not a boolean

“when set” does not parse here.

OLD:
      description
        "Anycast flag.  When set, it indicates that the prefix
          is configured as anycast.";

NEW:
      description
        "Indicates that the prefix is configured as anycast.";

## Data node description

OLD:
      leaf anycast-flag {
        type boolean;
        default "false";
        description
          "Sets the prefix as an anycast address.";

NEW:
      leaf anycast-flag {
        type boolean;
        default "false";
        description
            “Indicates that the prefix is an anycast address, if set to 1.
            It indicates a node-specific prefix if set to 0.";

## Please update Section 6 to follow the template at https://datatracker.ietf.org/doc/html/draft-ietf-netmod-rfc8407bis-28#name-security-considerations-sect

## These are not normative

### Move RFC6241 and RFC8040 to be listed as Informative

### I don’t think RFC9085 is normative, but I leave it to you to double check.

Cheers,
Med

IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-lsr-anycast-flag-08. If any part of this review is inaccurate, please let us know.

IANA understands that, upon approval of this document, there are three actions which we must complete.

First, in the OSPFv2 Extended Prefix TLV Flags registry in the Open Shortest Path First v2 (OSPFv2) Parameters registry group located at:

https://www.iana.org/assignments/ospfv2-parameters/

a single new flag is to be registered as follows:

Value: [ TBD-at-Registration ]
Description: AC-flag (Anycast Flag)
Reference: [ RFC-to-be ]

Second, in the ns registry in the IETF XML Registry group located at:

https://www.iana.org/assignments/xml-registry/

a single new namespace will be registered as follows:

ID: yang:ietf-ospf-anycast-flag
URI: urn:ietf:params:xml:ns:yang:ietf-ospf-anycast-flag
Filename: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

As this document requests a registration in an Expert Review or Specification Required (see RFC 8126) registry, we have completed the required Expert Review via a separate request.

Third, in the YANG Module Names registry on the YANG Parameters registry group located at:

https://www.iana.org/assignments/yang-parameters/

a single new YANG module will be registered as follows:

Name: ietf-ospf-anycast-flag
File: [ TBD-at-Registration ]
Maintained by IANA? N
Namespace: urn:ietf:params:xml:ns:yang:ietf-ospf-anycast-flag
Prefix: ospf-anycast-flag
Module:
Reference: [ RFC-to-be ]

While the YANG module name will be registered after the IESG approves the document, the YANG module file will be posted after the RFC Editor notifies us that the document has been published.

We understand that these are the only actions required to be completed upon approval of this document.

NOTE: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Sr. Specialist

The following Last Call announcement was sent out (ends 2025-12-02):

From: The IESG
To: IETF-Announce
CC: acee.ietf@gmail.com, draft-ietf-lsr-anycast-flag@ietf.org, gunter@vandevelde.cc, lsr-chairs@ietf.org, lsr@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (OSPFv2 Anycast Property Advertisement) to Proposed Standard


The IESG has received a request from the Link State Routing WG (lsr) to
consider the following document: - 'OSPFv2 Anycast Property Advertisement'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2025-12-02. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


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

  This document defines a new flag in the OSPFv2 Extended Prefix TLV
  Flags to advertise the anycast property.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-lsr-anycast-flag/



No IPR declarations have been submitted directly on this I-D.

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

The document has strong consensus.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

No controversy. The YANG model augmentations were added based on Yingzhen's
review.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

No implementations. However, this will be very simple to implement once
the IANA assignments are maed.


## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

N/A

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

Both Routing Directorate and YANG doctors reviews are requested.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

No YANG errors. Validating using https://www.yangcatalog.org/yangvalidator


8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

N/A


## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Yes.


10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

N/A

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Proposed Standard.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Yes.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

Yes.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

Yes.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

No.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

N/A

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.
No   

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?
No.   

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

There is only one flag added to an existing registry. The correct registry
is chosen.


21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

N/A

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

The document has strong consensus.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

No controversy. The YANG model augmentations were added based on Yingzhen's
review.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

No implementations. However, this will be very simple to implement once
the IANA assignments are maed.


## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

N/A

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

Both Routing Directorate and YANG doctors reviews are requested.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

No YANG errors. Validating using https://www.yangcatalog.org/yangvalidator


8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

N/A


## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Yes.


10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

N/A

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Proposed Standard.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Yes.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

Yes.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

Yes.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

No.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

N/A

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.
No   

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?
No.   

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

There is only one flag added to an existing registry. The correct registry
is chosen.


21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

N/A