Re: Gen-Art Review: draft-ietf-nsis-qspec-22.txt

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



If the problem is that the base documents are experimental, then I am very confused by the repeated references in the document to standards track documents for defining new state machine transitions. If that state machines are standards track, it would seem that the QoS encodings for those state machines ought to be standards track as well.

If the state machines are not standards track, then it would seem that this document should be experimental, to match the rest of the set.

Yours,
Joel

Gerald Ash wrote:

Joel,
Thanks for the quick review. I agree with all your comments and suggestions. Regarding your suggestion on RFC type (change it from Informational to PS), I believe it could not become PS since the other NSIS documents (GIST & QoS-NSLP) are Experimental. Thanks again,
Jerry

--- On *Sat, 11/21/09, Joel M. Halpern /<jmh@xxxxxxxxxxxxxxx>/* wrote:


    From: Joel M. Halpern <jmh@xxxxxxxxxxxxxxx>
    Subject: Gen-Art Review: draft-ietf-nsis-qspec-22.txt
    To: "General Area Review Team" <gen-art@xxxxxxxx>, "Mary Barnes"
    <mary.barnes@xxxxxxxxxx>
    Cc: "Magnus Westerlun" <magnus.westerlund@xxxxxxxxxxxx>, "IETF
    discussion list" <ietf@xxxxxxxx>, nsis@xxxxxxxx,
    draft-ietf-nsis-qspec@xxxxxxxxxxxxxx
    Date: Saturday, November 21, 2009, 6:32 PM

    I have been selected as the General Area Review Team (Gen-ART)
    reviewer for this draft (for background on Gen-ART, please see
    http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html ).

    Please resolve these comments along with any other Last Call comments
    you may receive.

    Document: draft-ietf-nsis-qspec-22
        QoS NSLP QSPEC Template
    Reviewer: Joel Halpern
    Review Date: 21-Nov-2009
    IETF LC End Date: 25-Nov-2009
    IESG Telechat date: N/A

    Summary: This document is almost ready for publication as an RFC.
    I am concerned about the RFC type.  If a revision of the document is
    needed, there are a few minor items to consider for inclusion.

    Major:
    I am unclear about whether the intended status (Informational) for
    this document is correct.
    At first, it seemed correct.   The document is defined as providing
    a template for a resource specification block (a QSPEC), and other
    model specific documents are expected to define exactly what QoS
    paramters they will use.
    It even seemed fine that this document mandates that the QSPEC
    include the indication of the QoS Model.  That is necessary information.

    Where I start to have concerns is in section 3.1 of this document.
    There, the document starts specifying requirements on any and of QoS
    Model documents.  It says things like "A QOSM specification MUST
    include the following:".  If this document is defining normative
    requirements for standards track documents (and the text explicitly
    states that QOSM definitions sometimes need to be standards track),
    then I don't see how it can be an informational document.
    If the QOSM requirements, and the QSPEC support requirements ("The
    QSPEC objects ... MUST be supported by QNEs.") are actually copied
    from some other document, then the problem is a lesser issue of
    unclear referent.  But if this document is the source for these
    normative requirements, it does seem that Informational is wrong.

    Given that this document actually defines bits to be used on the
    wire, it may be appropriate to publish it as a PS.
    Alternatively, BCP may be acceptable, although a bit unusual.

    The fact that this document defines the format of information fields
    and includes the IANA registration for those fields to be used in
    QOSM documents also suggests that informational is inappropriate as
    it would create a conceptual dependence of all standards track QOSM
    documents on an Informational RFC.  Also, this document includes
    guidelines to follow in future IANA allocations.


    Minor:
    In describing the constraints parameters, the text in section 3.3.2
carefully describes the semantics, and the composition rule. However, it seems to leave out the unit of measure. (The constraints
    are given in the detailed message information formats section, but
    it would seem sensible to include them in 3.3.2.)

    Editorial:
    Should there be an editorial note when "minimum QoS" is first
    described indicating that the term "minimum" is used generically, as
    for many parameters, like loss rate or latency, what needs to be
    specified is the maximum acceptable value?


_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]