Dear Authors, I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. Document Reviewed - draft-ietf-ospf-rfc4970bis-06 Link to Document - https://tools.ietf.org/html/draft-ietf-ospf-rfc4970bis-06 This document updates RFC4970 which originally defined extensions to OSPF optionally advertise router capabilities to neighbor OSPF speakers / routers. This BIS document is focused on making two key changes which include a new TLV for advertising functional capabilities and defines the ability to advertise multiple instances of the OSPF Router Information LSA. Other terminology was changed (“IETF Review”) per RFC5226 and references were updated. Much of the text was present in RFC4970, and well at the original extensions defined. The updated document is also well written and is clear. The new functionality introduced we clearly defined (Section 2.6: Router Functional Capabilities TLV) and the authors did add specific text (in Section 3) for backwards compatibility. One comment (shown below in review) was made here from an operational perspective, but is not seen as blocking (regarding some definition around configured state vs. potentially conflicting advertised state). Outside of that, the document is well done. Draft Review - OSPF RFC4970BIS Extensions to OSPF for Advertising Optional Router Capabilities 1.0: Introduction - ok 1.1: Requirements Notation - ok 1.2 Summary of Changes from RFC 4970 - ok - Good clear explanation of changes in BIS document. Section 2.0: OSPF Router Information (RI) LSA - Confirm in Paragraph 1, last sentence, that the word “subsequence” was to be used. Section 2.1: OSPFv2 Router Information (RI) Opaque LSA - ok Section 2.2: OSPFv3 Router Information (RI) Opaque LSA - ok Section 2.3: OSPF Router Information LSA TLV Format - Section paragraph. The author uses both the terms “octet” and “xx-bit” within the paragraph to describe the same basic padding concept. Although it’s technically correct, perhaps consistency may be valid here?. - Example “Nest TLVs are also 4-octet aligned”. Section 2.4: OSPF Router Informational Capabilities TLV - ok Section 2.5: Assigned OSPF Router Informational Capability Bits - ok Section 2.6: OSPF Router Functional Capabilities TLV - This section describes the additions to the OSPF RI LSAs. The new functional capabilities TLV is described, however it’s not 100% clear on how a device would behave if configured differently then the advertised capabilities may indicate from a neighboring router. Would it also be advisable (potentially) to note that configured router state supersedes advertised state? or would you consider that out of scope for this document? Section 2.7: Flooding Scope o the Router Information LSA - ok Section 3.0: Backwards Compatibility regards, Victor K