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

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

On Mon, Sep 25, 2017 at 10:26 AM, Alvaro Retana <aretana@cisco.com> wrote:

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

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

> (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?
>

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

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

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

> (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?
>

[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
> take a
> look at rfc8174.
>

[VPB] We used the new template in -07

> Nits:
>
> s/interval interval/interval
>

[VPB] Fixed in -07

> When defining the new capability advertisements (in 2.2.1 and 2.3.1), it
> would
> 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
> 2.3.2
> are superfluous.
>

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

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

>
> _______________________________________________
> Teas mailing list
> Teas@ietf.org
> https://www.ietf.org/mailman/listinfo/teas
>