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
