Hello Barry, Thank you very much for your thorough review feedback and update proposals. Please see inline for proposed responses. We are editing a new draft version that will be amended upon your feedback on the present e-mail.
Best regards, Sabine -----Original Message----- From: Barry Leiba via Datatracker <[email protected]> Sent: Wednesday, February 26, 2020 9:57 AM To: The IESG <[email protected]> Cc: [email protected]; [email protected]; [email protected]; Vijay Gurbani <[email protected]>; [email protected] Subject: Barry Leiba's Discuss on draft-ietf-alto-cost-calendar-17: (with DISCUSS and COMMENT) Barry Leiba has entered the following ballot position for draft-ietf-alto-cost-calendar-17: 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: ---------------------------------------------------------------------- Very easy-to-fix issue with date format specification: — Section 5 — Both extensions need to return calendar start time (calendar-start- time, a point in time), which MUST be specified using the HTTP header fields format specified in [RFC7231] where, however, timestamps are still displayed with the acronym "GMT" rather than "UTC": Date: Tue, 15 Nov 2014 08:12:31 GMT The problem with this text is that 7231 specifies three formats and you don’t make it clear which one you want, other than by example. The lack of a section reference doesn’t help (7231 is not small), but that wouldn’t be sufficient anyway. I suggest this: NEW Both extensions return calendar start time (calendar-start-time, a point in time), which MUST be specified as an HTTP “Date” header field using the IMF-fixdate format specified in Section 7.1.1.1 of [RFC7231]. Note that the IMF-fixdate format uses “GMT”, not “UTC”, to designate the time zone, as in this example: Date: Tue, 15 Nov 2014 08:12:31 GMT END ----- [[SR]] Thanks a lot for the suggestion, we will use your proposed text — Section 5.1.2 — For example: suppose the "calendar-start-time" member has value "Mon, 30 Jun 2014 at 00:00:00 GMT", the "time-interval-size" member has That isn’t a valid calendar-start-time value unless you remove “ at”. ----- [[SR]] indeed, thanks, we will correct ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Non-blocking comments, but some are important for clarity: — Section 1 — applicable to any Cost Mode and they ensure backwards compatibility with legacy ALTO Clients. What, exactly, are legacy ALTO Clients? Are you referring to ALTO clients that don’t support this spec, or do you mean something else? It would be worth saying here, as, “with legacy ALTO Clients — those that [whatever].” ----- [[SR]] would the new text below be OK? NEW "with legacy ALTO Clients - those that only support RFC7285". In the rest of this document, Section 2 provides the design characteristics. Sections 3 and 4 define the formal specifications for the IRD and the information resources. IANA, security and operational considerations are addressed respectively in sections Section 6, Section 7 and Section 8. It’s a tiny thing, but I’ve never seen the value of paragraphs such as this, when there’s a table of contents two pages earlier. And it’s wrong anyway (check it if you doubt me). I would prefer that you just take this paragraph out. But this is really just a rant: do as you think best. ----- [[SR]] thanks a lot for catching this, indeed, as we added a Requirements language section, we need to update or remove this text — Section 3.1 — faster if supported by both the server and the client. Do you mean, here, “both the Server and the Client.”? The terminology section makes a point of citing the significance of the capitalization, so it would be good to check he document for consistent usage of the capitalized terms, as I see quite a number of other such cases. ----- [[SR]] thanks, we indeed mean Server and the Client and will correct this — Section 3.3.2 — In the base protocol [RFC7285] section 11.2.3.6, an ALTO cost is specified as a generic JSONValue, allow extensions. I can’t parse this and don’t understand what it’s trying to say. ----- [[SR]] Indeed the sentence misses a "to". Would the text below be clearer? NEW "In the base protocol [RFC7285] section 11.2.3.6, an ALTO cost is specified as a generic JSONValue to allow extensions." — Section 4.1 — A Cost Calendar for a given Cost Type MUST be indicated in the IRD by an object of type CalendarAttributes. A CalendarAttribute object is “A CalendarAttributes object is” (the final “s” is missing) ----- [[SR]] thanks we will correct A Cost Type name MUST appear no more than once in the "calendar-attributes" member of a resource entry Using “MUST” with a negative is usually, as here, more confusing than using “MUST NOT”. I strongly recommend this instead: NEW A given Cost Type name MUST NOT appear more than once in the "calendar-attributes" member of a resource entry END ----- [[SR]] thanks we will correct multiple appearances of a Cost Type name in CalendarAttributes object of the "calendar-attributes" member MUST cause the ALTO Client to ignore You’re missing an article before “CalendarAttributes”: should it be “the” or “a”? You might consider rewording that sentence to be clearer. ----- [[SR]] Would the text below be clearer? NEW multiple appearances of a Cost Type name in the CalendarAttributes object of the "calendar-attributes" member MUST cause the ALTO Client to ignore END It is RECOMMENDED for an ALTO Server that the time interval size specified in the IRD is the smallest possible one that it can provide. The Client can aggregate cost values on its own if it needs a larger granularity. The English in the first sentence feels awkward (because you’re straining to make it passive). In the second sentence, “larger” doesn’t really go with “granularity”, and it’s probably clearer to use “interval”. So: NEW 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. END ----- [[SR]] Thanks a lot, we will use this text and servers should be aware of potential issues caused by the precision issues caused by using floating point numbers. “potential issues caused by the precision issues” is really awkward; I suggest rephrasing. * is the positive integer number, at least equal to 1, to indicate of number of values of the Cost Calendar array. Are there integers that are not numbers? Is it possible to have a positive integer that is not at least equal to 1? So is there a reason not to just say, “is a positive integer that specifies the number of values in the Cost Calendar array.” (which also fixes the “of...of...of” error)? ----- [[SR]] the purpose is to avoid ambiguities as the value "1" is sometimes defines as a strictly positive while positive is interpreted as >= 0. Would the following re-phrasing be OK? NEW is the positive integer, at least equal to 1, that indicates the number of values of the Cost Calendar array. END - Attribute "cost-type-names" provides a better readability to the Calendar attributes specified in the IRD and avoids confusion with Calendar attributes of other cost-types. I don’t understand what this means. I can’t figure out “provides a better readability to”. Can you rephrase? ----- [[SR]] Would the following re-phrasing be OK? NEW - 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. END — Section 4.2 — To achieve this, one option, is that a "root" ALTO Server implementing base protocol resources delegates "specialized" information resources such as the ones providing Cost Calendars, to another ALTO Server running in a subdomain that is specified with its URI in the "root" ALTO Server. This sentence also blows out my parsing circuit; please try rephrasing. ----- [[SR]] Would the following re-phrasing be OK? NEW 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" ALTO Server can provide a Calendar-specific resource entry where it specifies the URI allowing to retrieve the location of a Calendar-aware Server and relevant resources. END Another advantage 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, Cost Types with predictable and frequently changing values, calendared in short time intervals such as a minute. And this one. ----- [[SR]] Would the following re-phrasing be OK? NEW 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. END I’m sorry to pick on these, but the RFC Editor will have to try to fix the wording when they get to it, and they’re likely to get it wrong if the sentences are sufficiently difficult to follow. That will result in problems during the editing phase, at best, and errors in the published RFC, at worst. — Section 4.3 — The cost type names used in the example IRD as thus as follows: Change “as thus” to “are”. ----- [[SR]] thanks, we will correct — Section 5.2.2 — Server response is thus changed as follows, w.r.t [RFC7285] and Please don’t abbreviate “with respect to”. ----- [[SR]] thanks, we will correct — Section 5.2.3 — Therefore, it needs to both schedule its resource-greedy networking activities and its ALTO transactions. Make it “schedule both”. ----- [[SR]] thanks, we will correct — Section 7 — For confidentiality of ALTO information, an operator should be cognizant that this extension may introduce a new risk: an ALTO Client may get information for future events that are scheduled through Calendaring. Possessing such information, the client may use it to achieve its goal: (1) initiating connections only at advantageous network costs, leading to unexpected network load; (2) generating massive connections to the network at times where its load is expected to be high. I couldn’t make sense of this until I realized that I think you mean that “an attacker” (not “the client”) may use it to achieve its goal. Am I correct? The phrase “at advantageous network costs” also doesn’t make sense here. Maybe you mean “at very large network costs”, or some such? ----- [[SR]] Indeed we mean "malicious client". Would the following text be OK? NEW For confidentiality of ALTO information, an operator should be cognizant that this extension may introduce a new risk: a malicious ALTO Client may get information for future events that are scheduled through Calendaring. Possessing such information, the Client may use it to generate massive connections to the network at times where its load is expected to be high. END So ALTO Clients and servers MAY use newer versions (e.g., 1.3) of TLS as long as the negotiation process succeeds. To ensure backward compatibility with [RFC7285], it is RECOMMENDED for both Calendar-aware Clients and Servers to both support at least TLS 1.2, until it gets deprecated. This seems a little confused, and I would suggest a different recommendation anyway. Maybe this, or something like it?: NEW 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. END ----- [[SR]] thanks, we will use this text — Section 8 — result in congestion or result in a less optimal global outcome (e.g., the 's Paradox [Braess-paradox]). There’s something missing in the second line. ----- [[SR]] indeed thanks, we will add "Braess" Second, Although there are theoretical analysis [Selfish-routing-Roughgarden-thesis] and Internet based evaluations [Selfish-routing-Internet-eval] showing that uncoordinated behaviors may not result in substantial sub-optimal results, when a network operator updates the cost calendar, and when an application reacts to the update, they should still consider the potential feedback effects. I think I understand what you’re saying here, but it seems hard to follow. Maybe it could do with some rephrasing. Does this work?: NEW Second, when a network operator updates the cost calendar and when an application reacts to the update, they should consider the feedback effects. This is the best approach even though there is theoretical analysis [Selfish-routing-Roughgarden-thesis] and Internet based evaluation [Selfish-routing-Internet-eval] showing that uncoordinated behaviors do not always cause substantial sub-optimal results. END ----- [[SR]] thanks a lot, we will use this text Clients and Servers supporting ALTO Calendars use [RFC8259]. [RFC7285] encodes its requests and responses using the JSON Data Interchange Format specified in [RFC7159]. In the meantime, [RFC7159] has been obsoleted by [RFC8259], that among others makes UTF-8 mandatory for text encoding to improve interoperability. Rather than making the reader look up the references to figure this out, maybe we can help?: NEW The newer JSON Data Interchange Format specification [RFC8259] used in ALTO Calendars replaces the older one [RFC7159] used in the base ALTO protocol [RFC7285]. The newer JSON mandates UTF-8 text encoding to improve interoperability. END ----- [[SR]] thanks a lot, more reader friendly indeed, we will use this text _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
