[alto] First set of comments on draft-ietf-alto-multi-cost-00.txt

["Y. Richard Yang" <[e-mail]>]

Dear Sabine, Wendy, Nico,

Great work in the multi-cost document! I read the first sections (before
Section 4, which provides the formal grammar). I will dig into the formal
spec in the next one or two days. In the mean time, please see below for
initial (some quite minor) comments.

=====
page 4:
  IETF has designed a new service called ALTO that provides guidance to
   overlay applications, which have to select one or several hosts from

 [yry] Is there a need to emphasize on overlay?

  This guidance is based on parameters that affect performance and
   efficiency of the data transmission between the hosts, e.g., the
   topological distance.  The purpose of ALTO is to improve Quality of

 [yry] The location of "e.g., ..." makes it a bit hard to read. I assume
that it is an example of guidance? If so, how about move to be after "This
guidance"?

  System (AS).  Together with this Network Map, it provides the

 [yry] "this Network Map" is not defined.

   Last, it provides the Ranking of Endpoints w.r.t. their routing cost.

 [yry] The preceding is cost map centric. Since there is also the ECS, how
about mention cost map just as an example?

   It would be ...
   emerging applications that need information on several Cost Types,
   having them gathered in one map will save time.

  [yry] Another potential aspect is consistency: since it is a single
batch,
  it is less likely to be inconsistent.

page 5:
  o  {1.2.3}: References of this form are to sections in the ALTO
      protocol specification [RFC7285].

[yry] What if you want to refer to a section in this document? Maybe
mention that if it is a section in this document, there will be no {}?

     client to include the case of a CDN client, a client of an
      application running on a virtual server, a GRID application client

[yry] GRID or Grid?

page 6:
   The multi-cost extensions defined in this document should not break
   legacy implementations (that is, clients and servers which are not
   aware of these extensions).

[yry] "should not" is not a normative term here. I wonder what a legacy
client will behave if it seems an array. One issue is that the "meta"
field will not be compatible.

page 7:
                               "num-hopcount" ],
          ...
        }

[yry] The max-cost-types is 3, and the example has two types. So it is an
example of max?

page 8:
   This document uses the technique described above to extend Endpoint

 [yry] replace "above" with Section 3.3?

   destination PIDs.  Hence a client can use an extended Filtered Cost
   Map resource to get a full Multi Cost Map.

[yry] So the implication is that multi cost maps are provided and
retrieved only by filtered cost maps? How about make it clear upfront, in
intro?

page 8:
  Second, the "AND" of simple predicates is not sufficient; to be
   useful, clients must be able to express "OR" tests.  Hence we add a

[yry] To support "is not sufficient", how about refer to the previous
example using or?

page 8:
  Thus the following request tells the server to limit its response to
   cost points with "routingcost" <= 100 AND "hopcount" <= 2, OR else
   "routingcost" <= 10 AND "hopcount" <= 6:

[yry] So it is disjunctive normal form without not? Then why not include
"not", to be compete?

page 9:
4.  Protocol Extensions for Multi-Cost ALTO Transactions

[yry] How about adding a transition sentence to say that now it is formal
spec?