Extensions to RSVP-TE for Label Switched Path (LSP) Ingress Fast Reroute (FRR) Protection
draft-ietf-teas-rsvp-ingress-protection-17

"The Private Use ranges can be used for experimental use, they
   will not be registered with IANA and MUST NOT be mentioned by RFCs."

This is an inappropriate use of normative language since the ranges are defined in RFC 3936.

(1) As written, the expected result of the experiment is to select one approach.  Clearly, the intent is for the mechanisms to be compared.  That's good!  But what will the criteria be?  Are there benchmarks related to (for example) packet loss or state...?  Maybe it is simply an experiment to figure out which approach is implemented and deployed.  In any case, it would be nice to add some text about the expectations.

(2) The IANA Considerations Section still needs some work.  I know that the authors have been in conversations with IANA (IESG was cc'd) and that the result is to add the "This document does not request any IANA actions" text.

However, to avoid confusion it would be better if the IANA Considerations section only contained that text, and a new Section (maybe "Class Name and Number") was added to include the current text.

(2.1) About the current text...  I find the text about the Class Number a little confusing as in the end it doesn't matter which Private Use range is used; and the use of Normative Language...  Suggestion:

OLD>
   The assignment of a new Class Name and corresponding 8-bit Class
   Number data object in an RSVP message is defined in ([RFC3936]) with
   ranges for Standards Action, Expert Review, and Reserved for Private
   Use. The Private Use ranges can be used for experimental use, they
   will not be registered with IANA and MUST NOT be mentioned by RFCs.

   It is suggested to use the following Private Use range:

     o  124-127 Reserved for Private Use

   It is for an experimental implementation to choose a value from the
   Private Use range, and to agree with cooperating implementations
   participating in the same experiments what values to use.

NEW>
   The IANA Registry for Class Numbers created by [rfc3936] didn't define a 
   range to be used for Experimental Use [rfc8126]; instead several Private Use 
   ranges exist.  It is suggested that a value from a Private Use range 
   (124-127 for example) be chosen for experimentation.

I agree with the SecDir reviewer that the referenced security considerations are adequate, but it would be helpful to restate what's available in this draft.  One does not expect an RFC from 1997 to cover integrity protections (hop-by-hop) and authentication, so stating that these mechanisms are part of the protocol would be helpful.  I did not dig into to see what was used for those functions or if they are adequate today (if they have not been updated, they are likely due).  Additionally, 2 of the other referenced RFCs had the additional use of filters, does that apply here?  Can you add a couple sentences about that as well?  I assume they do apply, otherwise the references would not be included. 

Thank you!