**** General comments

I have two questions regarding the overall logic of router functional capabilities:

1. The ietf-ospf-unreachable-links module defines the "functional-capability" identity that appears to be intended as a potential base for identities other than "unreachable-link" that may be defined elsewhere. If it is the case, it would be better to define the base identity "functional-capability" in a special module.
   
2. Support for interpreting LSLinkInfinity as unreachable seems to be a feature of a particular router implementation. Would it make sense to define a YANG feature for it?

**** Specific comments

- The augment statement for "unreachable-link-advertisement" contains the following substatement:

  when "../rt:type = 'ospf:ospfv2' or "../rt:type = 'ospf:ospfv3'"

XPath equality check uses *literal strings*, so the above condition will fail if another prefix is used for the "ietf-ospf" module in XML representation of instance data, and will always fail for JSON representation where the identityref values are "ietf-ospf:ospfv2" and "ietf-ospf:ospfv3".

This problem was the reason for defining XPath functions derived-from() and derived-from-or-self(), see sec. 10.4 in RFC 7950.

- The remaining four augments use "when" statements like this:

      when "derived-from(/rt:routing/rt:control-plane-protocols/"
         + "rt:control-plane-protocol/rt:type, 'ospf:ospfv2')"

This avoids the above problem but won't work either because identity derivation is irreflexive (see sec. 7.18.2 in RFC 7950), so the above expression will be false if "rt:type" is "ospf:ospfv2". In all four cases the XPath function derived-from-or-self() has to be used rather than derived-from().

**** Nits

- Section 3.1 uses "this document" and "this specification" but, as I understand it, it means some prior OSPF spec and *not* draft-ietf-lsr-ospf-ls-link-infinity. I would recommend to clarify this and refer to a specific document explicitly.
  
- Typos:

  * sec. 1, 2nd paragraph: s/his/This/

  * sec. 3.1, 2nd paragraph: s/interpretaion/interpretation/

  * sec. 3.1, 3rd paragraph: s/metic/metric/