[Teas] Alvaro Retana's No Objection on draft-ietf-teas-rsvp-te-scaling-rec-06: (with COMMENT)

[Alvaro Retana <[e-mail]>]

Alvaro Retana has entered the following ballot position for
draft-ietf-teas-rsvp-te-scaling-rec-06: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-teas-rsvp-te-scaling-rec/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

(1) This document seems to do two things: make a series of rfc2961
recommendations, and introduce a couple of new techniques.  What is not clear
to me is whether the first part is independent of the second.  Will the
implementation of Section 2.1. ("RFC2961 Specific" Recommendations) provide
scaling benefits on their own (i.e. without the new techniques)?  If so, please
add some text (maybe in the Introduction) to indicate that.

(2) As for as the new techniques, it is confusing to me the use of rfc2119
language in Section 2.1.1. (Basic Prerequisites), which reads:

   An implementation that supports the techniques discussed in Sections
   2.2 and 2.3 must meet certain basic prerequisites.
...
   o  It SHOULD initiate all RSVP Refresh Overhead Reduction mechanisms...

I know that the leading "must" is not an RFC2119 keyword, but it may be
confusing with the "SHOULD" used later...specially because it sounds as if (in
some cases) it may be ok to not "initiate all RSVP Refresh Overhead Reduction
mechanisms" and still use the new mechanisms described later.  What are those
cases?  Maybe the mandatory prerequisites should all be listed in the same
sub-section, while other recommendations can be elsewhere.

Note also that later in 2.2 and 2.3 the text says that an implementation "MUST
support all the recommendations" in 2.1.  What does that MUST mean if one of
the recommendations is not an absolute requirement?

(3) Section 2.1.2 (Making Acknowledgements Mandatory) seems to also be a
prerequisite, right?  At lease the text says that "an implementation that
supports the techniques discussed in Sections 2.2 and 2.3...MUST...".  The fact
that it is not in the actual prerequisites section may be confusing to some.

(4) Section 2.1.3. (Clarifications On Reaching Rapid Retry Limit (Rl)) is (by
clarifying and using normative language) making specific changes to rfc2961. 
Assuming that there is value in 2.1 being used by itself (without the new
techniques), why isn't there a formal Update of rfc2961?

(5) This reminds me, please use the new RFC2119-related template: please take a
look at rfc8174.

Nits:

s/interval interval/interval

When defining the new capability advertisements (in 2.2.1 and 2.3.1), it would
be nice to include a reference to rfc5063.

Given the specification in the preceding sections, I think that 2.2.2 and 2.3.2
are superfluous.

It would be nice to point at the Appendix from the main text.