RE: Artart telechat review of draft-ietf-alto-multi-cost-08

["Randriamasy, Sabine (Nokia - FR/Nozay)" <[e-mail]>]

Hello Martin,

Thanks a lot for your review. The draft will be updated so as to address them.
Best regards,
Sabine


>>-----Original Message-----
>>From: Martin Thomson [mailto:[e-mail]]
>>Sent: 06 April 2017 04:08
>>To: [e-mail]
>>Cc: [e-mail]; [e-mail]; [e-mail]
>>Subject: Artart telechat review of draft-ietf-alto-multi-cost-08
>>
>>Reviewer: Martin Thomson
>>Review result: Ready with Issues
>>
>>Document: draft-ietf-alto-multi-cost-08
>>Date: 2017-04-06
>>Reviewer: Martin Thomson
>>
>>This document describes how ALTO can be used to acquire cost maps with
>>multiple cost metric instead of a single metric.
>>
>>The document very carefully deals with backwards compatibility with existing
>>ALTO servers and clients.  I don't anticipate many issues arising from the
>>deployment of this protocol.
>>
>>I started reading -07, but finished with -08.  I checked that the issues I raise
>>still exist, but I'm not infallible.  Apologies if I get something wrong.
>>
>>Minor issues: I've identified a few issues that are more than nits, these are
>>marked "IMPORTANT" below.
>>
>>
>>The abstract includes considerable justificiation.  An abstract only needs to
>>describe the *what*, not the *why*.  Thus, what is there could be simplified
>>considerably, e.g.,
>>
>>   This document defines a new method for retrieving multiple cost metrics in
>>a
>>   single request for an ALTO filtered cost map.  It also defines improvements
>>   to the constraints that can be used for filtered cost maps.
>>
>>Section 1
>>
>>The introduction uses a bunch of odd terms.  Some of these are recognizable
>>from the ALTO specification, but some of the jargon seems unnecessary.  In
>>particular, "Internet View", "Provider Network region" and "Vector costs".
>>All of which I think that I understand, but they make the doc hard to follow.
>>
>>Generally, I found the introduction quite hard to follow, both for that reason
>>and structurally.  The introduction could be a lot shorter and more
>>concise:
>>
>>1. ALTO defines multiple cost types (and more are being defined).
>>2. Clients sometimes consume multiple cost types.
>>3. Requesting multiple cost types at the same time is more efficient (for
>>   several reasons).
>>4. This document defines how to do that.
>>5. Separately, when multiple cost types are present, more sophisticated
>>   filtering can improve efficiency further.
>>6. This document defines how to do that too.
>>
>>Section 2
>>
>>There are several items in the list here that are not used:
>>Application Client,
>>Network Service Provider, maybe more.  Please check and remove those
>>that don't apply.
>>
>>The RFC 7285 section reference thing is unnecessary.
>>
>>This document doesn't cite RFC 2119, but it uses the keywords.
>>
>>Section 3.1
>>
>>The example shows an empty cost-type, but the schema you define allows it
>>to be absent.  You REALLY need to pick one.  I don't believe that this is a
>>compatibility issue: once you have determined that a client supports multi-
>>cost, then you can do anything you like, just be clear about it.
>>
>>Section 3.2
>>
>>I found the argument about the ease of writing a parser to be quite
>>unconvincing.  However, a new media type that is largely the same as the
>>existing media type won't necessarily result in code duplication.
>>
>>Just say what it is you expect to happen and don't try to be apologetic about
>>it.  What you have appears to be a workable design.
>>
>>Section 3.5
>>
>>This section is confusing.  You only need to say that you are not altering full
>>cost map resources in any way and that clients need to use filtered cost maps
>>if they want multiple costs at the same time.  (Obviously you could have, but
>>creating multiple resources with the full combinatorial mess caused by
>>combining many cost types is unwieldy.)  At a minimum, the second
>>paragraph here can be removed.
>>
>>Section 3.6.2
>>
>>IMPORTANT: You don't define what happens when a client provides "or-
>>constraints"
>>and "constraints" at the same time.  There are several valid options, but you
>>need to choose.
>>
>>Section 3.6.3
>>
>>It is probably worth explicitly noting that if "testable-cost-types"
>>does not
>>include values from "multi-cost-types", then those types can't be included in
>>"constraints"/"or-constraints".
>>
>>Please explain the default value for the index for the "constraints"/"or-
>>constraints" express in this section in addition to where it is hidden in a note
>>later in the document.
>>
>>Section 3.6.5
>>
>>Uppercase for "must not" in the second paragraph.  (The "may" later in the
>>paragraph might be better as "can".)
>>
>>In the example, the resource named "filtered-multicost-map" is provided for
>>legacy reasons only.  Why bother including "max-cost-types" and "cost-type-
>>names" at all when "filtered-cost-map-extended" includes all that and more?
>>
>>Section 4.1.1
>>
>>The definition of the schema here (and later) actually redefines the object
>>completely.  I found that confusing initially.  It would be good to identify the
>>*changes* from the base specification somehow.
>>
>>Can testable-cost-type-names be present and empty if cost-constraints is
>>false?
>>The first part of the definition permits that, the second forbids it.
>>
>>Section 4.1.2
>>
>>The redefinition of PIDFilter is unnecessary.
>>
>>IMPORTANT: pids is optional in RFC 7285.  Why the change?
>>
>>I find the redefinition of the optionality of cost-type to be worthy of special
>>note.
>>
>>In the definition of "or-constraints", you use a "database query"
>>where words
>>would suffice.
>>
>>Section 4.1.3
>>
>>I find the choice of value for "cost-type" to be problematic.  It is a string in the
>>base protocol, so changing to an empty object is likely to cause more issues
>>than simply omitting it.
>>
>>Section 4.2 contains mismatched braces/parens for section references.
>>
>>Section 4.2.2
>>
>>IMPORTANT: This provides a definition for ReqFilteredCostMap that is very
>>different to that in the base specification.  I think that this should have been
>>ReqEndpointCostMap.
>>
>>As before, repeating the definition of EndpointFilter is unnecessary.
>>
>>Section 4.2.3 - see comment on 4.1.3
>>
>>Section 5
>>
>>I would be more comfortable if the examples used obviously-spurious
>>metrics (e.g., "cattle-head-count", "smell", "shoe-size", etc...) than these
>>metrics that are pretty plausible.  More so when you claim that they are
>>widely valued, which implies some sort of validity.
>>
>>It should be relatively easy to populate Content-Length now that the
>>examples are "final".
>>
>>Section 5.1
>>
>>You have unmatched braces in "meta" due to the comment.
>>
>>Section 5.2
>>
>>Do you want to show one of the examples as having no cost values at all
>>across all the cost types?
>>