Hi Jensen,
Indeed, the revison of the drafts is in progress and thanks a lot for your comments that will be considered for the next version. Please see my feedback inline. In the new text proposals, text in ++blabla++ format means "blabla" is added to the initial text. Thanks, Sabine ________________________________ De : Jensen Zhang <[email protected]> Envoyé : samedi 2 décembre 2017 09:04 À : Randriamasy, Sabine (Nokia - FR/Paris-Saclay); [email protected] Cc : IETF ALTO Objet : Update review of draft-ietf-alto-cost-calendar-02 Hi Sabine and other authors, How are you? Since the last review from Dawn (https://mailarchive.ietf.org/arch/msg/alto/ZSH5Z1ujBvh4YjQxZLwjPNocXRM/?qid=4922c9c845f02b2bd9c02cc751c74c87), I have not found the draft was updated yet. From the agreement in IETF 99, there are a lot of text harmonization work. I assume the revision is in progress. I just append some technical review for the current version below. Hopefully, it will be helpful. === Section 3.1., paragraph 3: > A member "calendar-attributes" MUST appear only once for each > applicable cost type name of a resource entry. If "calendar- > attributes" are specified several times for a same "cost-type-name" > in the capabilities of a resource entry, the ALTO client SHOULD > ignore any calendar capabilities on this "cost-type-name" for this > resource entry. I think it will be much better to adopt the finest granularity than just ignore all, if there are more than one "calendar-attributes" object for the same "cost-type-name". => OK, the text may be too careful and we may allow a client to consider the first set of attributes and ignore the next ones. The sentence would then become: "... the ALTO client SHOULD ++ only consider the first occurrence of "calendar-attributes and++ ignore any ++additional++ calendar capabilities ..." Section 3.1., paragraph 9: > * is the duration of an ALTO calendar time interval, expressed as > a time unit appended to the number of these units. The time > unit, ranges from "second" to "year". The number is encoded > with an integer. Example values are: "5 minute" , "2 hour", > meaning that each calendar value applies on a time interval > that lasts respectively 5 minutes and 2 hours. I prefer to use another field (i.e. "time-interval-unit") to express the time unit and make "time-interval-size" a simple JSONNumber. Because it can simplify the data validation. In this way, the server and client only need to check the data type (number and enumeration) without validating the data content. ==> the motivation here was mainly to lighten the data volume by using only one fieldand make sure that a change in either units and number of units will not be missed by the client. Do you mean that the parsing of the value of the current "time-interval-size" is longer and more complex? Section 4.1.1., paragraph 5: > This field MUST NOT be specified if member "calendar-attributes" is > not present for this information resource. From section 8.3.7 of RFC7285, "ALTO implementations MUST ignore unknown fields when processing ALTO messages", I think we need to change "This field MUST NOT be specified" to "This field MUST be ignored". Because if "calendar-attributes" is not present, the server should be a legacy ALTO server which doesn't support calendar extension. So the "calendared" field is an unknown field in the request. ==> Indeed, we should minimize the error messages. So how about writing: "This field MUST NOT be specified if ++no++ member "calendar-attributes" is present for this information resource. ++ It will be ignored by a legacy ALTO Server, according to section 8.3.7 of RFC 7285. A Calendar-aware Server will return a response with a single cost value as specified in RFC 7285 ++ ". Section 4.2.1., paragraph 1: > The extensions to the requests for calendared Endpoint Cost Maps are > the same as for the Filtered Cost Map Service, specified in section > XXXX of this draft. Just a reminder. Don't forget to change "section XXXX". ==> good catch, thanks a lot. === Once we have an update, I would like to proofread the revision. Chears, Jensen
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
