Dear Xin, Thank you for your feedback. Please see answers inline and let me know if they address your questions. We will further try to clarify wherever is needed.
Thanks, Sabine De : wang xin [mailto:[email protected]] Envoyé : jeudi 7 juillet 2016 08:00 À : Randriamasy, Sabine (Nokia - FR); [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> Cc : IETF ALTO Objet : My review on multi-cost Dear authors, First, this draft looks concrete and interesting to me. It should be a key extension to RFC7285. Followings are my comments: 1. The third paragraph in Introduction section. In this paragraph, it mentions "cost values that change more frequently than previously assumed". This is the only sentence in the whole draft trying to discuss the changing frequency of cost values. I didn't find any further discussion in the content of the draft. Is it necessary to mention that? Or the draft should give some explanations for this sentence? [SR ] The idea is to introduce the need to minimize the number of ALTO transactions for metrics with frequently changing values. Would the following phrasing address your question? "..., in particular cost values that change more frequently than previously assumed and thus require more frequent ALTO requests. Moreover, to be sure to have up to date values, applications using several frequently changing metrics will tend to refresh their values simultaneously." 2. Application Client (AC) in Terminology section. "Client" and "client" should have different meanings in this draft. The former one indicates Alto Client and the latter one is for the general client of applications. I think "... any Client that ..." should use "client"? [SR ] I agree with your concern. To get rid of ambiguities I suggest that we systematically use "ALTO client" and "application client. Would that be OK? 3. Section 3.6.3 and Section 3.6.5 These two sections mainly discuss "testable-cost-type-name" as well as "cost-constraints" fields in RFC7285. To be compatible with RFC7285, the exclusive requirement seems a little complicate to me. As the draft already defines a new capability, "test-cost-types", why doesn't define a new constraints for that, something like "testable-constraints"? This is different from "cost-constraints" in RFC7285 that a client uses "testable-constraints" to filter costs and doesn't care the actual values. Is there any difficulties or problems for that? [SR ] "testable-cost-type-name" is a field used in the IRD capabilities for resource "filtered-cost-map-extended" that does not allow constraints on all of the metrics it provides, see example in section 3.6.5. The field "cost-constraints" is a Boolean capability of resource "filtered-multicost-map" compatible with RFC7285. That means this resource MUST allow constraints on all the metrics it provides. This distinction is done for legacy ALTO clients because they do not see the capability fields "testable-cost-type-name", "max-cost-types" since they are not defined in RFC7285. The presence of these fields ensures that legacy clients can safely use both resources . For example, a legacy client using "filtered-cost-map-extended" will not use constraints on this resources as there is no capability "cost-constraints: true". 4. Section 4.1.1 The definition of FilteredCostMapCapabilities doesn't reflect the exclusive requirement for "cost-constraints" and "testable-cost-type-names". Maybe it should add two types of FilteredCostMapCapabilities to reflect that or this is not important. [SR ] this section is a formal specification of the descriptions in sections 3.6.3 and 3.6.5. The description of member "testable-cost-type-names ", in its second paragraph states that: ""testable-cost-typenames" and "cost-constraints" are mutually exclusive to prevent legacy clients from issuing constraint tests on untestable cost types" Do you think we should better highlight this rule? Thanks, Xin
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
