Hiall, I'd like to share some of my thoughts on the draft-ietf-alto-incr-update-sse.
There has been a debate on the options of "start-updates" and "stop-updates" and Wendy has already proposed some options. I think since we need two channels, one for data and the other one for control, it is better to separate them explicitly. Basically I would vote for option 3 but there are still a few details I'd like to discuss. One of the reasons that "start-updates" and "stop-updates" cannot be mixed together is that the draft allows one stream to push updates for several resources. In my understanding, it is aimed to reduce the number of connections. However, there is a constraint that requests are identified only by the their resource id which is the reason why it is difficult to add/modify resources. Consider a system-wide ALTO client, which can have multiple ECS/EPS requests with different parameters. By allowing clients to label the requested parameters, we can provide better control functionality and also further reduce the number of active connections. Your thoughts and suggestions can highly appreciated. Regards, Kai On 29/02/16 06:26, Qiao Xiang wrote: > 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] <mailto:[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] > <mailto:[email protected]>>: > > Hiall, > > 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, >> >> Ican 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 list >> [email protected] <mailto:[email protected]> >> https://www.ietf.org/mailman/listinfo/alto > > > _______________________________________________ > alto mailing list > [email protected] <mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/alto > > > > _______________________________________________ > alto mailing list > [email protected] <mailto:[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
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
