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



On 10/1/15 9:29 AM, Alia Atlas wrote:

On Thu, Oct 1, 2015 at 10:18 AM, Robert Sparks <rjsparks(_at_)nostrum(_dot_)com<mailto:rjsparks(_at_)nostrum(_dot_)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(_at_)nostrum(_dot_)com <mailto:rjsparks(_at_)nostrum(_dot_)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 pathcomputation function that uses network performance criteria."

OK


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