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]
> https://www.ietf.org/mailman/listinfo/alto
_______________________________________________
alto mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/alto
