Hello Benjamin, All right, thanks for your suggestion. I will insert such a text. Best regards, Sabine
>-----Original Message----- >From: Benjamin Kaduk <ka...@mit.edu> >Sent: Wednesday, March 11, 2020 2:24 AM >To: Randriamasy, Sabine (Nokia - FR/Paris-Saclay) <sabine.randriamasy@nokia- >bell-labs.com> >Cc: The IESG <i...@ietf.org>; 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) > >Hi Sabine, > >On Tue, Mar 10, 2020 at 09:40:13AM +0000, Randriamasy, Sabine (Nokia - >FR/Paris-Saclay) wrote: >> Hello Benjamin, >> >> Thank you for your review and feedback. As you saw, in draft-ietf-alto-cost- >calendar-20, there are still comments from v19 that will be addressed in the >next update. > >I'm happy to hear that :) > >> I would have a question : in your sentence " 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.", what does "this >method" refer to? Is the idea that using constraints is less efficient with >Calendars that with RFC 7285 and 8189? If yes I will propose a sentence to >reflect this idea. > >"This method" is ALTO Cost Calendars in general. So, I was thinking something >like adding a sentence at the end of Section 3.3 to say "The absence of >constraints on filtered cost map and endpoint cost map calendars reflects a >divergence from the non-calendared functionality defined in RFC >7285 and updated by RFC 8189; providing the constraint functionality in >conjunction with calendar functionality is not feasible for the reasons >described >above, so the two features are mutually exclusive." > >I am sure you can come up with a more elegant phrasing than I just wrote on >the fly. > >Thanks, > >Ben > >> 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". >> >> Section 1.1 >> >> I'm not sure how much *archival* value there is in the current discussion of >SENSE and Unicorn. >> >> 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? >> >> 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. >> >> 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. >> >> 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. >> >> 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? >> >> 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? >> >> 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. >> >> 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? >> >> * 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"). >> >> - 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). >> >> 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/ >> >> Sectgion 5 >> >> I'd consider using a more recent Date in the example. >> >> 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