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 <[email protected]> > Sent: Tuesday, March 10, 2020 1:21 AM > To: The IESG <[email protected]> > Cc: [email protected]; [email protected]; > [email protected]; Vijay Gurbani <[email protected]>; > [email protected] > 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 [email protected] https://www.ietf.org/mailman/listinfo/alto
