Hi Hans, Thanks a lot for your feedback. Please find answers to your questions inline. Don't hesitate to get back with further questions as it may help for the next draft version.
Thanks, Sabine >>-----Message d'origine----- >>De : alto [mailto:[email protected]] De la part de Hans Seidel >>Envoyé : lundi 20 juin 2016 16:35 >>À : Randriamasy, Sabine (Nokia - FR); Kai GAO; Qiao Fu; [email protected] >>Cc : [email protected] >>Objet : Re: [alto] TR: I-D Action: draft-ietf-alto-multi-cost-02.txt >> >>Sabine, Wendy, >> >>Below, my comments/questions on draft-ietf-alto-multi-cost-02.txt. >> >> >>S4.1.2 "constraints" paragraph: >> >>If I get this correct, in case "max-cost-types" > 0 and extended >>predicates are used, the logical OR applies instead of logical AND. [SR ] [SR ] It is perfectly fine for a MC(Multi-Cost) capable client to specify a "constraint" parameter composed by an array of extended predicates related by an AND. The "constraints" description just stresses that the client cannot specify both "constraints" and "or-constraints". The "or-constraints" specification supports "constraints". For example: a client willing to express "b in [12, 20] and r in [1, 10]" using "constraints" formulates it as follows, (assuming [0], [1] are the indexes of metrics b and r: ["[0] gt 12", "[0] le 20", "[1] gt 10", "[1] le 10"] A client willing to express "b in [12, 20] and r in [1, 10]" using "or-constraints" adds 2 brackets and formulates it as follows: [ ["[0] gt 12", "[0] le 20", "[1] gt 10", "[1] le 10"] ] A client willing to express "(b > 12 and b < 20) or r < 10 or h < 2" formulates the or-constraint as follows: [ ["[0] gt 12","[0] le 20"], ["[1] le 10], ["[2] le 20"] ] >>Why changing the behavior? Is there an advantage in using the logical >>OR? [SR ] some MC clients may find it simpler to only use one type of extended constraints and thus "or-constraints" supporting both "and- only" and "and-or" combinations is an advantage. >> >>What is used if no extended predicates are used, for example when a >>legacy client is requesting a multi-cost resource? [SR ] a legacy client is not allowed to request a multi-cost resource and must comply to RFC7285. >>I assume the logical AND as stated in RFC7285 but it is not entirely >>clear to me. [SR ] right, a legacy client MUST use the "constraints" member as specified in RFC7285 >> >>How can a server distinguish between RFC7285 predicates and the new >>extended predicates? [SR ] a legacy server will only understand legacy client requests. A MC Server MUST be able to understand both MC and legacy clients. >>Here, I am especially thinking of the case, that cost type index "0" >>can be omitted and the extended predicate becomes indistinguishable >>from >>RFC7285 predicates. [SR ] a MC client must be able to talk with both MC Servers and legacy Servers. It MUST omit index "0" when interacting with a legacy server. It MAY omit it when requesting a single cost resource with constraints on that cost to a MC server. >> >> >>In general, I noticed some upper/lower case inconsistencies for certain >>nouns on several occasions. E.g. "client" and "Client" or "endpoint" >>and "Endpoint". >>For consistency reasons only one notation should be used. [SR ] thanks a lot for notifying this. Will be corrected. >> >> >>Regards >>Hans [SR ] Thanks, Sabine >> >> >>On 14.06.2016 11:30, Randriamasy, Sabine (Nokia - FR) wrote: >>> Hi Kai, Qiao, Fred and all, >>> >>> We have posted a new version of Multi-Cost ALTO according to your >>feedback. For short: >>> >>> - The extensions overview on "testable-cost-type-names", >>"constraints" >>> and "or-constraints" has been further clarified with additional >>> subsections see 3.6.1 to 3.6.5, >>> >>> - the design for the testable-cost-type-names capability (section >>> 4.1.1) has been updated according to Kai's feedback: >>> "testable-cost-type-names" and "cost-constraints" are now mutually >>> exclusive to prevent legacy clients from issuing constraint tests on >>> untestable cost types, >>> >>> - the text on "constraints" and "or-constraints" input members in >>> section 4.1.2 has been updated accordingly, >>> >>> - the or-constraint member has been corrected to [JSONString or- >>constraints<0..*><0..*>;], >>> please note that this member will be corrected to [JSONString or- >>constraints<1..*><1..*>;] in the next draft version. >>> >>> - the ipv4 examples in section 5.6 have been extended with ipv6 >>> examples, >>> >>> Again thank you all for your valuable comments. >>> >>> Please take a look and let us know if these updates meet your >>> expectations, Thanks, >>> >>> Sabine, Wendy >>> >>> _______________________________________________ >>> alto mailing list >>> [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
