The only somewhat substantial comment I have is regarding this: In section 3.1: Editors Note - We need to revisit the RFC6374 errors and the protocol to see if we need some more error codes. Has this been done? This note should be removed before publication. The remaining comments are all editorial. In abstract: extend the lifetime of such labels. It is not the only control protocol that might be used to support SFL, but it has the benefit of being able to be used without modifying of the existing MPLS control ^^^^^^^^^^^^ protocols. The existence of this design is not intended to restrict Should say “modifying the existing” or “modification of the” Same in section 1. I don’t think there should be normative language in the abstract. It has MUST and SHOULD. In section 3.1. Missing period at the end. 0x3: SFL Withdraw-Ack. This indicates that the responder has received the Withdraw message and will withdraw the SFLs 1 (Request (R)) Indicates to the Querier that this member of the SFL batch is requested. Where a value is specified in the request, but the Responder is unable honour ^^^^^^^ that request, no SFL is allocated and the corresponding A flag MUST be cleared. Should be “Is unable to honour” In 3.2.1: If the Responder is unable to allocate all of the requested SFLs it MUST respond with a response code of SFL-Unable. The Querier MUST determine whether the allocated SFLs were adequate for its purposes and MUST send a withdraw if there are not adequate. A Querier MUST ^^^^^^^^^^ NOT attempt to hoard labels in the hope that the residual labels needed may become available in the future. “if they are not adequate”? In section 4: 4. Return Path Where the LSP (or other MPLS construct) is multi-point to point, or multi-point to multi- point the RFC6374 Address TLV MUST be included in Query packet, even if the response is requested in-band, since this is needed to provide the necessary return address for this request. Remove space “multi- point”.