[mpls] Rtgdir last call review of draft-ietf-mpls-sfl-control-03

[Stig Venaas via Datatracker <[e-mail]>]

Reviewer: Stig Venaas
Review result: Has Nits

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”.