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

From: Alvaro Retana <[email-masked]>
Date: Mon, 25 Sep 2017 07:26:58 -0700

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.

---

From: Vishnu Pavan Beeram <[email-masked]>
Date: Wed, 27 Sep 2017 23:19:25 -0400

Alvaro, Hi!

Thanks for the review. We just posted a new revision (-07) to address the
Gen-Art review comments. Please go through the new diffs (
https://www.ietf.org/rfcdiff?url2=draft-ietf-teas-rsvp-te-scaling-rec-07)
and let us know if additional changes are required.

Please see inline for further responses (prefixed VPB).

Regards,
-Pavan

> https://datatracker.ietf.org/doc/draft-ietf-teas-rsvp-te-scaling-rec/

[VPB] The implementation of the RFC2961 specific recommendations (Section 2
in rev -07) alone will not provide any significant improvement to the
existing scaling numbers.

> the recommendations is not an absolute requirement?

[VPB] Please see if the changes in rev -07 address the above comment.

> that it is not in the actual prerequisites section may be confusing to

[VPB] We reshuffled a few sections to address the Gen-Art review comments.
Please see if the new narrative takes care of removing this confusion.

> techniques), why isn't there a formal Update of rfc2961?

[VPB] As stated above, there isn't much value in Section 2 being used by
itself.

> (5) This reminds me, please use the new RFC2119-related template: please

[VPB] We used the new template in -07

> s/interval interval/interval

[VPB] Fixed in -07

> be nice to include a reference to rfc5063.

[VPB] Fixed in -07

> Given the specification in the preceding sections, I think that 2.2.2 and

[VPB] The two "Compatibility" sections were added to address specific WG LC
comments. If this continues to be a concern, we can consider rolling the
text in these sections into the preceding sections.

>
> _______________________________________________
> Teas mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/teas
>

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Thu, 28 Sep 2017 12:33:21 +0000

Pavan:

Hi!

Thanks for the update!

Maybe a nit, but I think it would be good to explicitly state that the rfc2961 recommendation by themselves won’t do much.

Thanks!

Alvaro.

On 9/27/17, 11:19 PM, "Vishnu Pavan Beeram" <[email-masked]<mailto:[email-masked]>> wrote:

[VPB] The implementation of the RFC2961 specific recommendations (Section 2 in rev -07) alone will not provide any significant improvement to the existing scaling numbers.