Hello Benjamin and all, Sorry, I mistakenly clicked the "Send" button and I still need to address a couple of comments. In the meantime however, I'll be happy to have your feedback on the proposed updates.
Best regards, Sabine >-----Original Message----- >From: Randriamasy, Sabine (Nokia - FR/Paris-Saclay) >Sent: Wednesday, March 11, 2020 7:18 PM >To: Benjamin Kaduk <ka...@mit.edu>; The IESG <i...@ietf.org> >Cc: draft-ietf-alto-cost-calen...@ietf.org; alto-cha...@ietf.org; >alto@ietf.org; >Vijay Gurbani <vijay.gurb...@gmail.com>; vijay.gurb...@nokia.com >Subject: RE: Benjamin Kaduk's No Objection on draft-ietf-alto-cost-calendar-20: >(with COMMENT) > >Hello Benjamin, > >Thanks again for your review. A version v21 is under edition to finish >addressing >all the review comments. >Please see inline for my responses to your comments. >Best regards, >Sabine > >>-----Original Message----- >>From: Benjamin Kaduk via Datatracker <nore...@ietf.org> >>Sent: Tuesday, March 10, 2020 1:21 AM >>To: The IESG <i...@ietf.org> >>Cc: draft-ietf-alto-cost-calen...@ietf.org; alto-cha...@ietf.org; >>alto@ietf.org; Vijay Gurbani <vijay.gurb...@gmail.com>; >>vijay.gurb...@nokia.com >>Subject: Benjamin Kaduk's No Objection on draft-ietf-alto-cost-calendar-20: >>(with COMMENT) >> >>Benjamin Kaduk has entered the following ballot position for >>draft-ietf-alto-cost-calendar-20: No Objection >> >>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/ >> >> >> >>---------------------------------------------------------------------- >>COMMENT: >>---------------------------------------------------------------------- >> >>Thanks for adding text about the incompatibility of constraints with >>the calendar functionality. I would suggest further clarifying that >>this reflects a limitation of this method or reduction in functionality >>when compared to RFC >>7285 (and 8189), but do not insist upon it. >> >>[comments from -19 preserved for posterity] >> >>Section 1 >> >> In this document, an "ALTO Cost Calendar" is specified in terms of >> information resources capabilities that are applicable to time- >> >>nit: "information resources capabilities" has two plurals. Either make >>"resources" possessive ("resources'") or just use "resource". >[ [SR] ] done thanks >> >>Section 1.1 >> >>I'm not sure how much *archival* value there is in the current >>discussion of SENSE and Unicorn. >[ [SR] ] Text changed to be less project-centric ans instead focusing on >the >motivating use-case. >Reference [I-D.xiang-alto-multidomain-analytics] was changed to an archived >journal paper. >> >>Section 3.1 >> >> sent to the ALTO Clients needing it. The "ALTO Incremental Updates >> Using Server-Sent Events (SSE)" Service >> [I-D.ietf-alto-incr-update-sse] can be used to update the calendar >> faster if supported by both the Server and the Client. >> >>nit(?): faster than what? >[ [SR] ] the text has been changed as follows in v20: >NEW >The "ALTO Incremental Updates > Using Server-Sent Events (SSE)" Service > [I-D.ietf-alto-incr-update-sse] can be used to directly update the > Calendar upon value changes, if supported by both the Server and the > Client. END >> >>Section 3.3 >> >> The present document extends the definition of a legacy cost map >> given in [RFC7285] to allow a cost entry to be an array of values, >> with one value one per time interval, instead of being just one >> number. Therefore the implementor of this extension MUST consider >> that a cost entry is an array of values. Specifically, an >> >>nit: this is not quite true, strictly speaking -- the cost entry is >>only an array when the cost calendar functionality is active, which is >>not a subset of when the extension is implemented. >>Also, if the cost entry is definitively an array, then this would be >>replacing the definition, not extending it. >[ [SR] ] Would the following text be better? >NEW >The present document extends the > definition of a legacy cost map given in <xref target="RFC7285"/> to allow a >cost > entry to be an array of values, with one value one per time interval, > instead of > being just one number, when the Cost Calendar functionality is activated on >this cost. > Therefore the implementor of this extension MUST consider that a cost entry >is an array of values > if this cost has been queried as a Calendar. END > >> >> implementation of this extension MUST parse the "number-of-intervals" >> attribute of the "calendar-attributes" in an IRD entry announcing a >> service providing Cost Calendar. The implementation then will know >> that a cost entry of the service will be an array of values, and the >> expected size of the array is that specified by the "number-of- >> intervals" attribute. >> >>Is it a protocol error if the cost entry is a scalar or an array of >>different size than expected? Where do we specify error handling for those >cases? >> >> To realize an ALTO Calendar, this document extends: the IRD and the >> ALTO requests and responses for Cost Calendars. >> >>nit: no colon needed. >[ [SR] ] done, thanks >> >> o it allows an ALTO Server to offer Calendar capabilities on a cost >> type, with attributes values adapted to each information resource. >> >>I'm not entirely sure what this is intending to say. Is the idea that >>this is a general mechanism that could be applied to capabilities of >>all cost types (as opposed to, e.g., making a new cost mode for >>"calendar of numerical" that would need many new types to support different >types of calendar)? >> >>Section 3.3.2 >> >> The ALTO protocol extensions for Cost Calendars have been defined so >> as to ensure that Calendar capable ALTO Servers can provide legacy >> >>nit: hyphenate "Calendar-capable" (and similarly throughout). I see >>that "calendar-aware" is already hyphenated, which is good. >[ [SR] ] done in v20 thanks > >> >> ALTO Clients with legacy information resources as well. That is, a >> legacy ALTO Client can request resources and receive responses as >> specified in [RFC7285]. >> >>Should we say anything about Calendar-aware ALTO Clients being able to >>get useful responses from legacy Servers as well? >[ [SR] ] Agree. The following sentence has been added after paragraph 2: >NEW > A Calendar-aware ALTO Client MUST implement the base protocol > specified in <xref target="RFC7285"/>. >END > >> >>Section 4 >> >> The Calendar attributes in the IRD information resources capabilities >> carry constant dateless values. A Calendar is associated with an >> >>"constant" in what sense? >[ [SR] ] Agree, the main idea is that the attribute values are dateless. So >"constant" has been removed: >NEW >The Calendar attributes in the IRD information resources capabilities carry >dateless values. >END >> >>Section 4.1 >> >> types. A cost type name MUST NOT appear more than once in the >> "calendar-attributes" member of a resource entry; multiple >> appearances of a cost type name in the CalendarAttributes object of >> the "calendar-attributes" member MUST cause the ALTO Client to ignore >> any occurrences of this name beyond the first encountered occurrence. >> >>It seems that this is most important in that the given resource entry >>has an array of calendar-attributes, and we need to know which element >>of that array to use when processing calendars for that cost type. >>Indicating the extra layer of structure in the description around this >>requirement would help the reader. >> >> An ALTO Server SHOULD specify the "time-interval-size" in the IRD as >> the smallest it is able to provide. A Client that needs a longer >> interval can aggregate multiple cost values to obtain it. >> >>nit: we haven't defined "time-interval-size" yet, so either moving this >>later or giving a bit more explanation might be useful. >[ [SR] ] Agree. This text was moved right after the definition of >CalendarAttributes >> >> o "cost-type-names": >> >> * An array of one or more elements indicating the cost-type-names >> in the IRD entry to which the capabilities apply. >> >>Which capabilities? >[ [SR] ] The text was clarified as follows: >NEW >An array of one or more elements indicating the cost-type-names > in the IRD entry to which the values of "time-interval-size" and > "number-of-intervals" apply. >END >> >> * is the duration of an ALTO Calendar time interval in a unit of >> seconds. A "time-interval-size" value contains a non-negative >> JSONNumber. Example values are: 300 and 7200, meaning that >> each Calendar value applies on a time interval that lasts 5 >> minutes and 2 hours, respectively. Since an interval size >> (e.g., 100 ms) can be smaller than the unit, the value >> specified may be a floating point (e.g., 0.1). Both ALTO >> Clients and Servers should be aware of potential precision >> issues caused by using floating point numbers; for example, the >> floating number 0.1 cannot be represented precisely using a >> finite number of binary bits. To improve interoperability and >> be consistent with [RFC7285] on the use of float point numbers, >> the Server and the Client SHOULD use IEEE 754 double-precision >> floating point [IEEE.754.2008] to store this value. >> >>nit: please be consistent about using "floating-point number" (vs., >>e.g., "floating point" or "float point"). >[ [SR] ] thanks, used "floating" everywhere >> >> - Providing attribute "cost-type-names" together with "time-interval- >> size" and "number-of-intervals" improves the readability of the >> Calendar attributes specified for an IRD resource and avoids >> confusion with Calendar attributes of other cost types. >> >>I'm not sure I understand either of these points (how readability is >>helped and how confusion is avoided). >[ [SR] ] Indeed the text was clarified as follows in v20, as readability was >not >the main point >NEW >- Attribute "cost-type-names" is associated with "time-interval-size" and > "number-of-intervals", because multiple cost types may share the same > values for attributes "time-interval-size" and "number-of-intervals". > To avoid redundancies, cost type names sharing the same values for "time- >interval-size" > and "number-of-intervals" are grouped in the "cost-type-names" attribute. > In the example IRD provided in <xref target="sect-4.3"/>, the information >resource > “filtered-cost-map-calendar” provides a Calendar for cost type names > "num-routingcost", "num-throughputrating" and "string-servicestatus". > Cost type names "num-routingcost" and "num-throughputrating" are > grouped in the "cost-type-names" attribute because they share the > same values for "time-interval-size" and "number-of-intervals", > which are respectively 7200 and 12. >END >> >>Section 4.2 >> >> It may be useful to distinguish IRD resources supported by the base >> ALTO protocol from resources supported by its extensions. To achieve >> this, one option, is that a "root" ALTO Server implementing base >> protocol resources and running at a given domain, delegates >> "specialized" information resources such as the ones providing Cost >> Calendars, to another ALTO Server running in a subdomain. The "root" >> >>How would a Client know that this mechanism is in use? >> >> This document provides an example, where a "root" ALTO Server runs in >> a domain called "alto.example.com". It delegates the announcement of >> Calendars capabilities to an ALTO Server running in a subdomain >> called "custom.alto.example.com". The location of the "delegate >> Calendar IRD" is assumed to be indicated in the "root" IRD by the >> resource entry: "custom-calendared-resources". >> >>This is "assumed" only for the purpose of the example, and not as a >>general protocol mechanism, right? >> >> Another benefit of delegation is that some cost types for some >> resources may be more advantageous as Cost Calendars and it makes few >> sense to get them as a single value. For example, if a cost type has >> predictable and frequently changing values, calendared in short time >> intervals such as a minute, it saves time and network resources to >> track the cost values via a focused delegate Server rather than the >> more general "root" Server. >> >>Is the idea just that you compartmentalize the fast-changing stuff from >>the slow-changing stuff, so that your listing of what is changing >>quickly only includes the things actually changing on that timescale, >>so you don't end up also listing the calendar for the slowly-changing things >>in >the same response? >>Also, nit: s/few/little/ >> >> >>Is there a reason for "map" and "calendar" to be in different orders in >>"filtered-cost-map-calendar" and "endpoint-cost-calendar-map"? >> >> o the Calendar for "owdelay": is an array of 12 values each provided >> on a time interval lasting 300 seconds (5 minutes). >> >>nit: s/owdelay/num-owdelay/ >[[SR]] Done, thanks > >> >>Sectgion 5 >> >>I'd consider using a more recent Date in the example. >[[SR]] agree, done thanks >> >>Section 5.1.1 >> >> The input parameters of a "legacy" request for a filtered cost map, >> defined by object ReqFilteredCostMap in section 11.3.2 of [RFC7285], >> are augmented with one additional member. >> >>There's probably some pedantic consideration here about "other >>extensions", such as the "multi-cost-types" member from RFC 8189. >> >> This field is an array of 1 to N boolean values, where N is the >> number of requested metrics. Each entry corresponds to the >> requested >> >>Maybe reference RFC 8189 so the reader doesn't get confused by RFC 7285 >>specifying only a single metric type? >> >>Section 5.1.2 >> >> The non Calendar specific "meta" fields of a calendared Filtered Cost >> Map response MUST include at least: >> [...] >> >>side note: this structure where we effectively repeat the requirements >>of all previous specifications is not going to scale well with future >>extensions. >> >> o each "CalendarResponseAttributes" object in the array is specified >> for one or more cost types for which the value of member >> "calendared" is equal to 'true' and for which a Calendar is >> provided for the requested information resource. >> >>Member 'calendared' of what data structure? >> >> o "cost-type-names": is an array of one or more cost-type-names to >> which the capabilities apply and for which a Calendar has been >> requested. The value of this member is a subset of the "cost- >> type-names" array specified in the corresponding IRD Calendar >> attributes. >> >>Just to check my understanding: in the IRD Calendar attributes, there's >>a "calendar-attributes" member whose value is an array of objects, and >>each of those objects has a "cost-type-names" member whose value is an >>array of cost-type names. So what we're saying here is that the >>"cost-type-names" in a CalendarResponseAttributes entry are a subset of >>the union of the "cost-type- names" members in all of the entries in >>the "calendar-attributes" array of objects in the IRD calendar >>attribute, which is not exactly what the quoted text seems to be saying. >> >> o "time-interval-size": as specified in Section 4.1 and with the >> same value. >> >> o "number-of-intervals": as specified in Section 4.1 and with the >> same value. >> >>nit: "with the same value" could perhaps imply that there is a >>requirement to have actually published an IRD calendar for this >>resource and literally take the value from that existing calendar; >>"with the same semantics" should relax that >>(perceived) requirement. >> >>Section 5.1.3 >> >> An example of non-real time information that can be provisioned in a >> Calendar is the expected path throughput. While the transmission >> >>nit: "non-real time" and "non-real-time" have different meanings, and I >>think the latter is the intended one. >> >> usage patterns. In this example, we assume that an ALTO Client >> requests a Calendar of network provider defined throughput ratings, >> >>nit: hyphenate "network-provider-defined". >> >> Content-Length: 1013 >> Content-Type: application/alto-costmap+json >> >>Please double-check the content length (for all the examples) -- it's a >>bit annoying to do from the text rendering of the I-D that applies a >>left indent, but assuming that the initial '{' is supposed to be the >>first byte of the response body and the rest of the whitespace is part >>of the response, I get something more like 1043 octets of content. >> >>Section 5.2.1 >> >>We should probably say that the interpretation of the various fields is >>the same as the RFC 7285/8189 ReqEndpointCostMap, and "calendared" the >>same as for ReqFilteredCostMap. >> >>Section 5.2.3 >> >> o C1 for Monday, Tuesday, Wednesday, Thursday, (weekdays) >> >> o C2 for Saturday, Sunday, (weekend) >> >> - C3 for Friday (maintenance outage on July 4, 2014 from 02:00:00 GMT >> to 04:00:00 GMT, or big holiday such as New Year evening). >> >>I'd consider using a more recent date than 2014 throughout this example. >>Also, nit: please use a consistent character to represent the bullet point. >> >> Host: alto.example.com >> >>Would it be more consistent with previous examples to use >>custom.alto.example.com here (and in other examples)? >> >>Section 7 >> >> >> [RFC8446] specifies TLS 1.3 and writes in its section 1: "While TLS >> 1.3 is not directly compatible with previous versions, all versions >> of TLS incorporate a versioning mechanism which allows Clients and >> Servers to interoperably negotiate a common version if one is >> supported by both peers". ALTO Clients and Servers SHOULD support >> both TLS 1.3 [RFC8446] and TLS 1.2 [RFC5246], and MAY support and use >> newer versions of TLS as long as the negotiation process succeeds. >> >>I know this document has been in the works for a long time and so there >>may be reluctance to make changes on this front, but I'll note that RFC >>8446 has been out for a year and half, so under normal conditions we'd >>just say "use TLS 1.3 or newer" without mentioning 1.2. >> >> participate in a DDoS attack. The Calendar information would be >> valuable information for when to persecute a DDoS attack. A >> >>nit: "persecute" is an unusual word here; "execute" or "perform" seem >>like better alternatives. >> >> Hence, a more robust ALTO Client should adapt and extend protection >> strategies specified in Section 15.2 of the base protocol. For >> >>It's probably better to use the RFC number than just "the base protocol". >> >>Section 10.2 >> >>I think [IEEE.754.2008] needs to be normative, as do RFCs 5246 and >>8446, and draft-ietf-alto-incr-update-sse. >> >> _______________________________________________ alto mailing list alto@ietf.org https://www.ietf.org/mailman/listinfo/alto
