I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-ospf-mpls-elc-13 Reviewer: Elwyn Davies Review Date: 2020-05-06 IETF LC End Date: 2020-05-05 IESG Telechat date: 2020-05-21 Summary: Ready with nits. Aside: I have to say that the convolutions and cross-referencing of doing the OSPF and IS-IS extensions plus BGP-LS added to the cross-linking with MPLS is leading to mind-blowing complexity. Sooner or later something is going to blow up here! Major issues: None Minor issues: None Nits/editorial comments: Abstract and title :  The application to BGP-LS (s5) is not mentioned in the abstract or the title.  Also the first use of BGP-LS needs to be expanded. Abstract: s/tunnel/LSP/ s1: Suggest s/SR-MPLS/Segment Routing with the MPLS Data Plane/ s1: Query:  As a non-expert in this area, I was wondering if the signalling capability is or will be implemented in IS-IS?  A brief comment on the status wrt IS-IS would be helpful.  [It turns out that you already reference the document that implements this later in this draft.] s1, last sentence: s/it's/it is/ s3: It would be a good idea to expand 'prefix' to 'address prefix advertisement' on its first occurrence here.  Thereafter 'prefix' is fine by me. s3, para 3: Why would a router not advertise the ELC with all prefixes?  Can you say why this ought not to be a MUST.    s4, para 3: In that case, what does the absence signify?  Should we care? s4, para 4: This needs a correction and a reference to where the Link MSD Sub-TLV is defined.  As a matter of interest, is there any reason why this should be sent in an OSPF context?  If not why not just prohibit sending it? If it is received should it provoke an error rather than being ignored? OLD: When the ERLD MSD-Type is received in the OSPFv2 or OSPFv3 Link MSD Sub-TLV, it MUST be ignored. NEW: When the ERLD-MSD type is received in the OSPFv2 or OSPFv3 Link MSD Sub-TLV [RFC8476], it MUST be ignored. ENDS s5:  This section needs to be rewritten to be 'future proof' rather than referring to the temporary allocations.  A note about the temporary allocations can be added with a RFC Editor note requesting its removal on final publication.