Hi All, The following are my comments on draft-ietf-alto-multi-cost-01:
Some typos: Sec 1, paragraph 5, "RTT" -> "Round Trip Time (RTT)" Sec 2, paragraph 2, "refering" -> "referring" Sec 2, move the abbreviation "Content Delivery Networks (CDN)" to the 2nd paragraph of Sec 1, where it appears in the draft for the first time. Sec 4.1.1, the paragraph of "multi-cost-types", second line: "thlis" -> "the" Comments on testable-cost-types and multi-cost-types: I am a bit confused about "testable-cost-types". From the example in Sec 5.2, "cost-type" and "testable-cost-types" can coexist. And when they do, the constraint will be applied to "testable-cost-types". But from the description in paragraph 2 on page 10, it seems that if "multi-cost-types" exists, test will be applied only to "multi-cost-types", not "testable-cots-types". What if a client wants to get *routingcost* and *delaycost* when *routingcost*, *delaycost* and *hopcount* all satisfy certain constraints? In this case, there are two costs in "multi-cost-type", but three types of costs are desired to be tested. It seems the current design does not allow client to express a request like this. It would be great if anyone could shed some lights on this issue. Thank you very much. Best Qiao On Tue, Feb 23, 2016 at 2:51 AM, Gao Kai <[email protected]> wrote: > Hi all, > > Below are my feedbacks on the multi-cost draft: > > Review on draft-ietf-alto-multi-cost-01: > > Notation: > sec#X: Section X > para#X: paragraph X > line#X: line X > ===== > > sec#1-para#1-line#3: > Typo: "such" -> "such as" > > sec#1-para#7-line4: > Typo: "definition" -> "definitions" > > sec#3.6: > > Instead of reusing the "constraints" field for "testable-cost-types", I'd > like > to propose that we enforce the use of "or-constraints". > > Firstly, the format of "testable-cost-types" is a list of cost types, but > the > "constraints" field is originally designed for testing one cost type. Even > using the extended format, the conditions can only be concatenated by the > AND > operator. Using "or-constraints", on the other hand, provides better > flexibility. > > Secondly, according to the draft, if the "testable-cost-types" is missing, > the > servers will test the "multi-cost-types" with the conditions specified by > "or-constraints". Thus using "or-constraints" for both cases can simplify > the > implementation because the "constraints" field can be totally ignored in > this > case. > > Finally, from the example in section 5.4, I feel the extended usage of > "constraints" seems to be only designed for the special case that the > number of > elements in "testable-cost-types" is 1, which I think the benefits are not > worth the complexity it brings to both clients and servers. > > sec4.1.1-para#1: > > The type of "or-constraints" should be: > > [JSONArray or-constraints<0..*>;] > > sec4.1.1: > > In the description for "testable-cost-types", the first paragraph says it > is > described for the "constraints" parameter, which should be for the > "or-constraints" parameter or, if we decide to reuse the "constraints" > field, > for both parameters. > > sec4.1.2: > > The description for "testable-cost-type-names" capability indicates it > requires > the "cost-constraints" capability to be "true". However, in that case, > according to RFC 7285, all cost types should be able to be included in > constraints, which means they are "testable". I cannot think of a good > reason > of doing that so my proposal is that we do the opposite: > > When the "cost-constraints" is set to "true", all types are testable and > the > "testable-cost-type-names" SHOULD NOT appear and MUST be omitted if it > does. > Otherwise, only the types specified in the "testable-cost-type-names" are > considered testable. > > > You thoughts and opinions are highly appreciated! > > Regards, > Kai > > > On 23/02/16 09:48, Gao Kai wrote: > > Hello Vijay and all, > > I can go through the WG drafts 2 and 3 (the SSE and Multi-cost) and give > some feedbacks as soon as possible. > > Regards, > Kai > > On 26/01/16 23:29, Vijay K. Gurbani wrote: > > Folks: The mailing list has been awfully quiet. > > Presently, we have 3 active I-Ds that are being tracked towards charter > fulfillment: > > 1. draft-ietf-alto-deployments is in its second WGLC. The new WGLC ends > on February 3, 2016. > > 2. draft-ietf-alto-incr-update-sse appears to be moving along and there > do not seem to be any stop gap issues that we are aware of. Authors, > please inform the WG if there are. > > 3. draft-ietf-alto-multi-cost is also fairly mature. > > It seems reasonable to move 2 and 3 ahead. > > Then there are a number of independent submissions dating back to Sep- > Oct 2015 timeframe. These have not been updated and nor has there been > much discussion on the mailing list. Some of these submissions are > important for charter deliverables related to graph representation > formats. Can the authors of the independent submissions kindly > share what their plans are with respect to the drafts? > > This will help us gauge whether or not we should meet face-to-face in > Buenos Aires or have an interim meeting before it and meet face-to-face > in Berlin. > > Note that while the final plans are still up in the air and subject > to change, there is a good chance that neither Jan or I will be able to > make it to Buenos Aires. However, if a F2F meeting is desired, it is > important to get a sense of the energy behind the independent drafts, > as the list traffic has been woefully quiet on this front. > > Thanks, > > - vijay > > > > > _______________________________________________ > alto mailing [email protected]https://www.ietf.org/mailman/listinfo/alto > > > > _______________________________________________ > alto mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/alto > > -- Qiao Xiang Postdoctoral Fellow, Department of Computer Science, Yale University
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
