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-segment-routing-extensions-19 Reviewer: Dan Romascanu Review Date: 2017-10-05 IETF LC End Date: 2017-10-13 IESG Telechat date: Not scheduled for a telechat Summary: A useful and well-written document. It requires previous reading and understanding of OSPF, SPRING and other routing work. It is Ready for publication. I found some unclear minor issues. I recommend to address them before approval and publication. Major issues: Minor issues: 1. I am wondering why, at this stage of progress of the document, the type values are still 'TBD, suggested value x'. Is there any other document defining this? 2. Section 3.1 - are there other algorithms planned to be added in the future? If yes, do we need a registry? If no, what is this field an octet? 3. It would be useful to mention that the Length fields are expressed in Octets. Also please clarify if padding is applied or not. 4. Section 3.3: 'The originating router MUST NOT advertise overlapping ranges.' How are conflicts resolved at receiver? 5. I like Section 9 - Implementation Status - which I found rather useful. Is there any chance to keep a trimmed down version of it, with synthetic information on the lines of 'at the time the document was discussed a survey was run, it showed that there were x implementation, y were implementing the full specification, z were included in released production software ....' 6. Section 10 - beyond recommending the counting and logging of the mal-formed TLVs and sub-TLVs, should not supplementary security recommendations be made? for example - throttling mechanisms to preempt DoS attacks. Nits/editorial comments: