Re: [Teas] Gen-art LC review: draft-ietf-teas-te-express-path-03

Alia Atlas <akatlas@gmail.com> Thu, 01 October 2015 14:29 UTC

MIME-Version: 1.0
In-Reply-To: <560D40AC.1070400@nostrum.com>
References: <56099533.8030600@nostrum.com> <CAG4d1rcG+i=_6bzX6tuc+iZ3aWitMcXMN7oKJhL6RiswcG7-zg@mail.gmail.com> <560D40AC.1070400@nostrum.com>
Date: Thu, 01 Oct 2015 10:29:10 -0400
Message-ID: <CAG4d1rcCC1ugcAMYwvjQobfaiO68se0598GyBH6QmaiRBKAqOg@mail.gmail.com>
From: Alia Atlas <akatlas@gmail.com>
To: Robert Sparks <rjsparks@nostrum.com>
Content-Type: multipart/alternative; boundary="001a11c30698d0ac6d05210bdeee"
Archived-At: <http://mailarchive.ietf.org/arch/msg/teas/b_20DotmF-tpvF1skJhLaOt8R1w>
Cc: draft-ietf-teas-te-express-path@ietf.org, "ietf@ietf.org" <ietf@ietf.org>, "TEAS WG (teas@ietf.org)" <teas@ietf.org>
Subject: Re: [Teas] Gen-art LC review: draft-ietf-teas-te-express-path-03
Precedence: list

On Thu, Oct 1, 2015 at 10:18 AM, Robert Sparks <rjsparks@nostrum.com> wrote:

>
>
> On 10/1/15 8:49 AM, Alia Atlas wrote:
>
> Hi Robert,
>
> Thanks for your review.
>
> On Mon, Sep 28, 2015 at 3:29 PM, Robert Sparks <rjsparks@nostrum.com>
> wrote:
>
>> I am the assigned Gen-ART reviewer for this draft. The General Area
>> Review Team (Gen-ART) reviews all IETF documents being processed
>> by the IESG for the IETF Chair.  Please treat these comments just
>> like any other last call comments.
>>
>> For more information, please see the FAQ at
>>
>> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
>>
>> Document: draft-ietf-teas-te-express-path-03
>> Reviewer: Robert Sparks
>> Review Date: 28 Sep 2015
>> IETF LC End Date: 30 Sep 2015
>> IESG Telechat date: 1 Oct 2015
>>
>> Summary: Ready for publication as Informational, with nits
>>
>> Nits/editorial comments:
>>
>> This document is all about considerations. Specifically, it discusses
>> what to consider if you were to build a path computation function that uses
>> the kind of information you get from the TE metric extensions in RFC7471
>> and draft-ietf-isis-te-metric-extensions. It does not appear to be
>> requirements for standardization work - rather, it is information for
>> operators to use when building functions that don't necessarily need
>> standardization.
>>
>> However, it looks as if the document may have once contemplated actually
>> specifying a path computation function, and has legacy text from that
>> thought?
>>
>
> No - it was always about how one could use the information and isn't
> trying to standardize a particular function.
>
>
>> The abstract says "This specification uses network performance data ...
>> to perform such path selections." But this document doesn't perform such
>> path selections (or specify how to do them).
>>
>
> Would you prefer
>
> "This specification describes how a path computation function may use
> network performance data, such as is advertised via the OSPF and ISIS TE
> metric extensions (defined outside the scope of this document) to perform
> such path selections."
>
> Yes, thanks!
>
>
>
>
>> Section 1.1 says "The following are the requirements that motivate this
>> solution." But this draft doesn't actually specify a "solution". It
>> discusses what to consider if you were to build a path computation
>> function. Could this be framed as a set of goals to keep in mind while
>> building your own such function?
>>
>
> Would you be ok with changing it to ".. that motivate this document?"
>
> They were used to drive the document contents (that's not obvious) and not
> to inform what an implementation should achieve?
>
> Perhaps the sentence could be replaced with
>
> "As these considerations were assembled, care was taken to discuss points
> relevant to an implementation's ability to:"
>
> ?
>

What about "The following are the requirements considered for a path
computation function that uses network performance criteria."

Alia

> The third paragraph of section 1.2 could use clarification. I suspect the
>> word "even" in the 4th sentence should be removed, and the judgement in
>> "There may be legitimate use" is out of place. Consider rewriting the
>> paragraph using simpler sentences.
>>
>
> I've removed the word "even" and changed the last sentence about "There
> may be legitimate use..." to be
> "However, there may be uses of a..."
>
> Section 2.3 appears to be considerations specifically for interpreting the
>> anomalous bit in one specific extension? If so, the introduction to the
>> section should call that out. If not, the section's structure needs
>> improvement. The section also calls out two questions, but only discusses
>> one of them explicitly.
>>
>
>  In Sec 2.3.1, the anomalous bit behavior is described for latency, loss,
> and jitter.  On double-checking, I see that the Anomalous Bit was removed
> for jitter in RFC7471 and draft-ietf-isis-te-metric-extensions.   I've
> removed the last sentence in the second paragraph of 2.3.1 that discussed
> how to handle that case.
>
> Sec 2.3.2 discusses the second question and how to handle it in detail.
>
> Thanks again for the review!  The changes will be in 04.
>
> Regards,
> Alia
>
>
>> RjS
>>
>>
>>
>
>

Re: [Teas] Gen-art LC review: draft-ietf-teas-te-… Jari Arkko
Re: [Teas] Gen-art LC review: draft-ietf-teas-te-… Alia Atlas
Re: [Teas] Gen-art LC review: draft-ietf-teas-te-… Alia Atlas