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-mpls-sfl-control-04 Reviewer: Ines Robles Review Date: 2023-11-27 IETF LC End Date: 2023-11-27 IESG Telechat date: Not scheduled for a telechat Summary: This document describes a control protocol that runs over an associated control header to request, withdraw, and extend the lifetime of MPLS synonymos flow labels (SFL). I have some minor comments/questions indicated below. Major issues: None Minor issues: * In the text it is mentioned - "well-managed MPLS Network" (Section 1, Section 6). I think that this is vague because it lacks specific, measurable criteria. Thus, to improve the clarity and precision of the document, it would be nice to replace the term "well-managed" with more specific and quantifiable attributes. Something like: "...This protocol is designed for use in an MPLS network that adheres to Internet standard management practices such as .... [addReference, e.g. RFC6427?]..." * Should this draft describe how this control protocol might interact with or support various SFL Actions? (for context and understanding the broader application of SFLs in a network.) * Should this draft specify topics related to the performance impact of the protocol, including how it handles high volumes of SFL requests and scalability in large-scale networks? * Section 3.1 - error codes: While the draft mentions error codes, Should this draft specify comprehensive error handling at various stages of the SFL request, management process or operational inconsistencies?, What do you think? * Section 3.2.4: More precise definitions or examples of what constitutes "significantly" would be helpful. * Section 3.2.4: Should this draft explain how these time margins might impact network performance, especially in high-density or high-traffic scenarios? * Section 3.2.4: Should this draft explain or reference how to manage potential inaccuracies in timer synchronization across the network? * Section 6: Should this draft reference RFC 5920? Nits/editorial comments: * Section 3. Related with the terminology, it would be nice to add RFC 5586 in here, since it defines the Generic Associated Channel Header. I understand RFC 5586 is mentioned in IANA section, but it would be nice to include it in here as well. * Section 3.1: In "Flags" and "Control Code" definition it would be nice to add a sentence such as "See below for detailed explanation", since these concepts are expanded below in the text. * Section 3.1: (Allocated (A) --> (Allocated (A)) Thanks for this document, Ines.