Thanks to Carl Wallace for their secdir review. 

Section 5, para 3:  Consider changing the reference from RFC 8446 to draft-ietf-tls-8446bis which is currently in Auth48 (so it should be completed before this draft).

Section 2.2, paragraph 7
>    The "Red" links that are used by Flex-Algorithm 128 calculation.
>    However, these "Red" links are also included in the default algorithm
>    calculation [RFC9350] since they are reachable.  Note that links used
>    by the default algorithm are omitted from Figure 3 for clarity.

The first sentence seems to be a fragment. I think you meant to say:

"The "Red" links are used by Flex-Algorithm 128 calculation."

Section 3.2, paragraph 6
>    OSPF Routers MUST NOT treat links with an advertised metric of
>    LSLinkInfinity as unreachable unless all routers in the OSPF area,
>    i.e., all routers with Router-LSAs in the area Link State Database
>    (LSDB), have advertised this capability.  If all OSPF Routers in the
>    area have advertised this capability, then links with an advertised
>    metric of LSLinkInfinity MUST be treated as unreachable.  Upon
>    detection of a change in the number of routers in the area not
>    supporting the Unreachable Link capability changes to 0 or from 0 to
>    greater than 0, all OSPF routers in the area MUST recalculate their
>    routes.

The last sentence in the paragraph is hard to parse. Could it be reworded to say:

"When the number of routers in the area that do not support the Unreachable Link 
capability changes to 0 or from 0 to a value greater than 0, all OSPF routers
in the area MUST recalculate their routes."

Section 3.3, paragraph 3
>    When an OSPF router supports [RFC6987] and the Unreachable Link
>    capability defined in this document, it MUST also support
>    advertisement all its non-stub links with a link cost of
>    MaxReachableLinkMetric (0xfffe).  Since MaxLinkMetric will not be
>    used to indicate a link is unreachable unless all OSPF routers in the
>    area support this specification as specified in Section 3.2, all
>    routers in the area will also support the usage of
>    MaxReachableLinkMetric to discourage the usage of stub router links
>    for transit traffic.  If there are any OSPF routers in the area that
>    do not support the Unreachable Link capability, then all OSPF routers
>    in the area will treat links advertised with a cost MaxLinkMetric as
>    reachable (Section 3.2).

Similarly, the first sentence should be reworded to say:

"... it MUST support the advertisement of all its non-stub links."

Section 4.2, paragraph 0
>    This section defines three YANG [RFC7950] modules.  Module iana-ospf-
>    functional-cap-bits defines the identities for OSPF Functional
>    Capabilities as per the "OSPF Router Functional Capability Bits" IANA
>    registry [IANA-OSPF-FC-Bits].  Module ietf-ospf-functional-capability
>    and module ietf-ospf-unreachable-links can be used to configure and
>    manage the usage of OSPF LSLinkInfinity for unreachable links as
>    defined in this document, which augments the OSPF YANG data model
>    [RFC9129] and the YANG Data Model for Routing Management [RFC8349].

The description above states that the module ietf-ospf-functional-capability
will be used to configure and manage the usage of OSPF LSLinkInfinity.
However, all the nodes are ro nodes. I assume that the actual configuration
of the capabilities is happening somewhere else, and this module is only 
being used to query those capabilities??

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

Section 2.2, paragraph 7
>    If the OSPF metrics for all the "Red" links are advertised as
>    unreachable, they will be excluded from the default SPF calculation
>    as shown in Figure 4, This allows the "Red" links from A to B and C
>    to D to be used exclusively by the Flex-Algorithm 128 calculation.

s/Figure 4,/Figure 4./

Section 5, paragraph 5
>    The following data nodes defined in the ietf-ospf-unreachable-links
>    YANG module that are writable/creatable/deletable (i.e., config true,
>    which is the default).  The modification of these data nodes without
>    proper protection can prevent interpretation of the OSPF
>    LSLinkInfinity metric as unreachable.

s/that are/are/

# IESG review of draft-ietf-lsr-ospf-ls-link-infinity-23

CC @MikeBishop

## Comments

### Section 6, paragraph 0

Please add links to the relevant registries.

## 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 2.2, paragraph 11
```
- 3.  LSLinkInfinity Based Solution
-                   ^
+ 3.  LSLinkInfinity-Based Solution
+                   ^
```

#### Section 3.2, paragraph 7
```
-    metric of LSLinkInfinity MUST be treated as unreachable.  Upon
-                                                              ^^
-    detection of a change in the number of routers in the area not
+    metric of LSLinkInfinity MUST be treated as unreachable.  When the number of routers in the area not
+                                                              ^^^^^^^^^^^^^^^^ +++++++++++ +++++++++++++
```

#### Section 3.3, paragraph 4
```
-    [RFC5340] to prevent usage stub router links for transit traffic.
+    [RFC5340] to prevent the usage of stub router links for transit traffic.
+                         ++++     +++
```

#### Section 5, paragraph 2
```
-    The security considerations for [RFC2328],[RFC5340], [RFC6987], and
+    The security considerations for [RFC2328], [RFC5340], [RFC6987], and
+                                              +
```

#### Section 5, paragraph 3
```
-    SSH [RFC4252], TLS [I-D.ietf-tls-rfc8446bis], and QUIC [RFC9000]) and
-                                                  ^^^
+    SSH [RFC4252], TLS [I-D.ietf-tls-rfc8446bis], or QUIC [RFC9000]) and
+                                                  ^^
```

### URLs

These URLs in the document did not return content:

 * https://www.iana.org/assignments/iana-ospf-functional-cap-bits/iana-ospf-functional-cap-bits.xhtml

### Grammar/style

#### Section 4.2.5, paragraph 8
```
egistry with all spaces replaced with “-“. The "identity" statement should ha
                                      ^ ^
```
Please do not use "smart-quotes".

Thank you to Behcet Sarikaya for the GENART review.