Hi All, The following are my comments on the draft-ietf-alto-incr-update-sse draft.
1. The last sentence of Paragraph 4 in Sec. 2 and the last sentence in Sec. 6.5 use the same example. but the first one uses "should" and the second one uses "SHOULD". I suggest capitalize the first one to make the draft consistent. 2. Section 6.6.3, "the that stream" -> "the same stream". 3. Section 6.9, first sentence of Paragraph 1: "a line-at-a-time" -> "one line-at-a-time" seems more appropriate. 4. Section 6.9, second sentence of Paragraph 1: "of not tens of" -> "if not tens of". 5. Regarding the exclusion issue of "start-updates" and "stop-updates", discussed by Hans, Wendy and Jensen, I am inclined to vote for Wendy's option 3, i.e., using two separate request "start-new-update-stream" and "modify-existing-update-stream". I will post to the group if I have any other comments. Thanks. Best Qiao On Tue, Feb 23, 2016 at 3:36 AM, Jensen Zhang <[email protected]> wrote: > Hi all, > > There are some considerations about draft-ietf-alto-incr-update-sse. > > According to this thread [1], there is an unclear description in the input > parameters of update steam service (Section 6.3). I also suggest the first > fixing option from Wendy, which is to make “start-updates” and > “stop-updates” exclusive. Since “stream-id” is only used by “stop-updates”, > why not make it a filed in the value of “stop-updates”? > > And another consideration is about Stream Restart (Section 9.2). Can we > support to compute a merge patch between two special tags (for those > resource with tags, such as networkmap). > > Also looking forward to a more detailed review for this draft. > > [1] https://mailarchive.ietf.org/arch/msg/alto/peGfjZ4_s1GXsKx5hlEhQX_CIK0 > > Regards, > Jensen > > 2016-02-23 15:51 GMT+08:00 Gao Kai <[email protected]>: > >> 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 >> >> > > _______________________________________________ > 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
