Hello Ben, A new version draft-ietf-alto-cost-calendar-10 has been submitted to address all the DISCUSS and COMMENT points of the IESG feedback. See https://tools.ietf.org/rfcdiff?url2=draft-ietf-alto-cost-calendar-10.txt I have completed inline my previous response of January 14 on your comments and nits (some of which were substantive). Thanks again for your review and suggestions, Sabine
-----Original Message----- From: Randriamasy, Sabine (Nokia - FR/Paris-Saclay) <[email protected]> Sent: Monday, January 14, 2019 6:06 PM To: Ben Campbell <[email protected]>; The IESG <[email protected]> Cc: [email protected]; [email protected]; [email protected]; Vijay Gurbani <[email protected]> Subject: RE: Ben Campbell's Discuss on draft-ietf-alto-cost-calendar-09: (with DISCUSS and COMMENT) Hello Ben, Thanks a lot for your review and questions. Please see inline for the answers and let me know if the proposals address your concerns. A new I-D will be produced and a new WGLC will occur in the WG to ensure that the changes proposed here are okay. The editorial and comments and Nits will be addressed as well. All my best wishes for 2019, Best regards, Sabine -----Original Message----- From: Ben Campbell <[email protected]> Sent: Wednesday, December 05, 2018 5:37 AM To: The IESG <[email protected]> Cc: [email protected]; Gurbani, Vijay (Nokia - US/Naperville) <[email protected]>; [email protected]; Gurbani, Vijay (Nokia - US/Naperville) <[email protected]>; [email protected] Subject: Ben Campbell's Discuss on draft-ietf-alto-cost-calendar-09: (with DISCUSS and COMMENT) Ben Campbell has entered the following ballot position for draft-ietf-alto-cost-calendar-09: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-alto-cost-calendar/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Thanks for the work on this document. I see value, but have a couple of points I think need to be resolved prior to publication: §3.1, definition of "time-interval-size": What is the reasoning behind using a string to define the unit? That requires text parsing/comparison to determine the interval. I assume this is intended more for machine use than for human use. Did the working group consider making this a multiple of some primitive time interval? E.g. number of seconds, or perhaps number of minutes? it seems like that would be easier (and therefore less error prone) to interpret. [[SR]] this has been indeed a concern raised in several reviews. The initial inspiration came from the encoding of filtering constraints in the filtered cost map input parameters, such as ["ge 5", "lt 10"] in RFC 7285 or ["[0] ge 5", "[1] lt 10"] in RFC 8189. We can actually take the opportunity of avoiding parsing errors as follows: - The value of "time-interval-size" is number defined in seconds. It is encoded in a JSON number. ALTO servers SHOULD use at least IEEE 754 double-precision floating point [IEEE.754-2008] to store the cost value, and SHOULD perform internal computations using double-precision floating-point arithmetic. In section 2.1 we may stress that encoding length in JSON number of seconds cover periods gives room to cover large periods. Would this address your concern? If there is a reason to use a text field, is there an enumeration of legal unit values? Can I use "12 parsecs"? [[SR]] this would no longer be applicable is we use seconds as the time unit. §4.1.2, last paragraph: "The ALTO Client thus may use the same calendar for the next 4 days starting at "calendar-start-time" and will only need to request a new one for Friday July 4th at 00:00:00 GMT." This implies that if an ALTO server delivers a calendar with a long duration, it cannot make changes to the metrics in that calendar, or if it does make them it cannot expect the client to learn about those changes. Is that the intent? If so, it seems to contradict language in the security considerations (§6) that future events may change and that the client should ensure information updates. (The operational considerations [§7] also say the client does not need to query again during the calendar duration.) [[SR]] Indeed, this issue should be addressed in the document and the following is proposed: - Section 2 Overview of ALTO Cost Calendars, after paragraph 4, says: "An ALTO Cost Calendar can be used like a "time table" to figure out the best time to schedule data transfers and also to proactively manage application traffic given predictable events such as flash crowds, traffic intensive holidays and network maintenance. It may be viewed as a synthetic abstraction of real measurements that can be historic or be a prediction for upcoming time periods." Add the following text: "However, like for any schedule, unexpected network incidents may require the current ALTO Calendar to be updated and re-sent to the ALTO Clients needing it. To this end, it is RECOMMENDED that an ALTO Server providing ALTO Calendars also provides "ALTO Incremental Updates Using Server-Sent Events" as specified in [draft-ietf-alto-incr-update-sse], and likewise, that ALTO Clients capable of using ALTO Calendars can also use ALTO Incremental updates." - In §4.1.2: extend the example in the last paragraph with how an ALTO Client can receive incremental updates when an incident in the network causes updates in the current version of the ALTO Calendar. - In §6 security considerations: repeat this text and stress that it is especially used when Calendars with "repeated" values are used. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I also have a number of substantive and editorial comments that do not rise to the level of a DISCUSS: *** Substantive Comments *** - General: (No action expected): For future reference, this is the sort of draft that I think should be referred to the ART area review team for review. It's effectively an application layer protocol, even if it affects transport layer decisions. (I note that none of the requested directorate reviews appear to have happened either, which is unfortunate.) §2, 4th paragraph: "that can be historic": I don't see mention of how historic data would be used. Maybe I missed something? [[SR]] Maybe replace "It may be viewed as a synthetic abstraction of real measurements that can be historic" with "It may be viewed as a synthetic abstraction of for example real measurements gathered over previous periods on which statistics have been computed" §2.2.1, 2nd paragraph: Please elaborate on what is meant by "carefully managed". What specific things need to be considered? [[SR]] Is the following wording clearer? - Simple version: ALTO Server provides updates of cost value based preferences. - Elaborated: "... a Calendar is suitable as well for time-varying metrics provided in the "ordinal" mode, if these values are time-varying and their update is managed by the ALTO Server and utilized by ALTO Clients with awareness on the operations that are suitable for ordinal values." §2.2.2, 3rd paragraph: This needs elaboration. I think it means that it must be possible to retrieve the "now" version of the metric, but one could not retrieve a future value as a single value. [[SR]] The sentence actually intended to express that: "When a Server provides a metric as a Calendar, it MUST also provide it as a single value as specified in [RFC7285]." Would this formulation be clearer? §3.1, - 3rd paragraph: "A member "calendar-attributes" MUST appear only once": Does that mean exactly once? No more than once? [[SR]] it means no more than once. Actually "cost-type-name" in this paragraph should be without "". Would the following formulation be OK? "Calendar attributes MUST be specified no more than once for each cost type name of a resource entry. If, in the "calendar attributes" member of the "capabilities" member of a resource entry, a cost type name appears several times, the ALTO client SHOULD consider only the attributes specified for the first occurrence of this cost type name and ignore calendar attributes specified for any additional occurrence of this cost type name. " - note after definition of "number-of-intervals": Where is "cost-type-name" defined? Was this meant to be "cost-type-names"? If so, this paragraph makes it sound optional, but it was not shown as optional in the schema. [[SR]] sorry, this is a typo, "s" is missing and it should be "cost-type-names". The dashes before the 2 paragraphs after definition of "number-of-intervals" are misleading and will be removed to avoid their confusion with field definition. In addition, expression "if used" will be removed as well in sentence "Attribute "cost-type-name" , if used, provides...", as this attribute is not optional. §4: It is not clear from the text if it saying the time zone is GMT in the example, or if it is always GMT. I assume the former, but the wording of the last paragraph suggests that the use of the HTTP header field format forces the time zone to always be GMT. [[SR]] Paragraph 4 will specify the following "The dates in Calendar attributes are encoded following RFC7231 "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", where section 7.1.1.1 "Date/Time Formats" specifies that the preferred format is a fixed-length and single-zone subset of the date and time specification used by the Internet Message Format [RFC5322]." "Note that the time zone is actually UTC, per RFC 7231, even though timestamps get displayed with the acronym "GMT." (as Alissa wrote). §4.1.1: - Third paragraph: I assume each entry corresponds to the requested metric at the same array position? If so, please say that explicitly. [[SR]] done 4th paragraph: 'This field SHOULD NOT be specified if no member "calendar-attributes" is specified in this information resource.' Why is the SHOULD NOT not a MUST NOT? (Also, should "specified" be "included"?) [[SR]] agree, it will be a MUST NOT and "included" will replace "specified". - 2nd to last paragraph: I don't understand the purpose of this paragraph. I assume "supporting single cost type values" means "only supporting" them. Why would the client request calendared values in the first place if it only supported single values? [[SR]] The wording indeed is unclear. These 2 paragraphs distinguish between Calendar-aware Clients that can query values for resp. a single cost type and multiple cost types as specified in RFC8189. Would the following formulation be ok for each paragraph: - "A Calendar-aware ALTO client that can query values for a single cost type, as specified in [RFC7285], ...." - "A Calendar-aware ALTO client that can query values for multiple cost types cost type, as specified in [RFC8189], ...." - last paragraph: How is this different than the requirement in the 2nd paragraph? [[SR]] see response above. §4.1.2 - first paragraph: "All arrays have a number of values equal to ’number-of-intervals’." Which "number-of-intervals" does this talk about? The one in the capabilities or in "Calendar ResponseAttributes"? [[SR]] Actually both values are the same. This is specified later in this section in the description of the Calendar ResponseAttributes fields. How about re-phrasing as: "All arrays have a number of values equal to the value of member ’number-of-intervals’ of the Calendar capabilities that are indicated in the IRD and will be conveyed as metadata in the Filtered Cost Map responses. Each element of the array is valid for the time-interval that matches its array position." Does that mean each element is valid for the time-interval that matches its array position? If so, please say that explicitly. [[SR]] see answer above I'm surprised to see this require a metric entry for each individual time interval. It your want a high resolution of time intervals, you may end up with a large number of entries. Did the WG consider making it possible to have a single metric entry cover multiple time intervals? As this is currently defined, I think there needs to be guidance to implementors that they need to balance calendar length and granularity against the required number of metric entries. [[SR]] indeed, high resolution intervals [[SR]] may be needed when values change[[SR]] , sometimes during very small time intervals but in a significant manner. And a way to avoid conveying too many entries is to leverage on the "repeated feature". A server can smartly set the calendar start time and number of intervals so as to declare them "repeated" for a large number of periods, until the Calendar values change and are conveyed to a requesting Client. Such text has been added to section 7. Operational considerations - definition of "Calendar-start-time" Please elaborate on why the start time SHOULD be no later than the current date? (Also, consider "SHOULD NOT be later...") [[SR]] ok, will use SHOULD NOT [[SR]] we may add: "so that the ALTO Client, immediately has applicable values. In addition, reading the Calendar start time and duration, the Client can figure out when the next Calendar will start." §6: last paragraph: - I'm not sure what it means for a repeat pattern to be "statistical". [[SR]] how about replacing "a repeat pattern may be only statistical" with "Calendar values, especially in "repeated" Calendars may be only statistical" ? - The guidance that future events can change and the client should ensure information updates seems to conflict with guidance elsewhere that the client does not need to requery until a calendar duration ends. (See DISCUSS point.) [[SR]] text recommending to use the ALTO Incremental updates SSE in conjunction with ALTO Calendars has been added in Sections 2, 4.1.2 and 6 (last para). *** Editorial Comments and Nits *** - IDNits reports some issues; please check. [[SR]] done: 1 warning remains on unused ref. RFC5246. I'll try to see why this comment appears - Abstract: Please expand ALTO on first mention in the abstract and the body. §1 - Please expand PID on first mention. - 6th paragraph: -- "specified by information resources capabilities": should that be something to the effect of "specified in terms of resource capabilities"? -- please expand IRD on first mention -- "the proposed extensions": They will no longer be "proposed" once this is published as an RFC. [[SR]] above nits done §2 - paragraph 4: "flash mobs" seems like an odd example of a predictable event, at least to anyone other than the event organizers and participants. [[SR]] replaced by "crowded events" §2.1, - first bullet: "attributes to interpret the time scope": I think the client does the interpreting. Perhaps "attributes to describe the time scope"? [[SR]] done, thanks - "repeated": I gather there is no option for unbounded repetition; it would be worth mentioning that up front. [[SR]] added a paragraph after the "repeated" item §3.1, third paragraph: "If "calendarattributes" are specified several times" I assume this means "more than one" time. "Several" often connotes a number greater than a "few" but less than "many". That is, people may not think of "2" as "several". [[SR]] yes, done - Please cite the json schema format you are using. I assume it is the one defined in the alto protocol RFC, but that should be mentioned explicitly. [[SR]] It's actually RFC 8259 upon recent discussions. Reference was added in Sections 1 Intro, 2.2, 3.1 and 7. - last paragraph: First sentence is hard to parse. [[SR]] new text is: "Multiplying ’time-interval-size’ by ’number-of-intervals’ provides the duration... " §3.2, first paragraph, first sentence: I'm not sure what "clarify" means in context; was that the correct word choice? [[SR]] actually unclear wording: new text is "One option to better sort out IRD resources w.r.t. for instance supported extended services...". We may also write "protocol extensions" instead of "extended services" if you think it is clearer §3.3, first paragraph: "As [RFC7285] makes it mandatory, it uses metric "routingcost" in the "numerical" mode." The antecedents for both occurrences of "it" have unclear antecedents. [[SR]] indeed, new text is: "since [RFC7285] makes it mandatory, the Server uses metric "routingcost" in the "numerical" mode" §4.1.2 - First paragraph: The first sentence is confusing. I think it means "instead of the format used by legacy implementations", but it con be interpreted the say that arrays are used for legacy implementations. [[SR]] this paragraph has been reworded. Text on new value format for Calendars was also added in para 2 of section 2.2 - 2nd paragraph: "include at least" doesn't really fit the content of the list entries. [[SR]] this paragraph and the bullets have been re-organized. The text means: include at least: the 2 listed fields for a single cost request and the 3 listed fields for a multi-cost request. - first major bullet: I suspect "supports" should be "requested". (same for 2nd major bullet) [[SR]] yes, done with precisions w.r.t. signle cost and Multi-Cost requests - paragraph starting with "- In addition, the "meta" field..." If this is required, why was it not included in the bullet list of required information? [[SR]] Section 4.1.2 has been re-organized so as to sort out "meta" fields w.r.t. "Calendar specific" and "single/multi cost" specific. Explanation text was added paragraph 2. - definition of "calendar-start-time" : I don't understand how "by default" interacts with SHOULD. [[SR]] text is now: "The value provided for the "calendar-start-time" attribute SHOULD NOT be later than the request date" §5, last paragraph: "For potential undesirable guidance of ALTO information..." That wording is confusing. I suggest something like "To avoid malicious or erroneous guidance from ALTO information..." [[SR]] you probably referred to §6, rewording done _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
