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 — 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”. ---------------------------------------------------------------------- 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].” 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. — 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. — 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. — 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) 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 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. 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 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)? - 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? — 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. 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. 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”. — Section 5.2.2 — Server response is thus changed as follows, w.r.t [RFC7285] and Please don’t abbreviate “with respect to”. — Section 5.2.3 — Therefore, it needs to both schedule its resource-greedy networking activities and its ALTO transactions. Make it “schedule both”. — 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? 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 — 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. 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 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 _______________________________________________ alto mailing list alto@ietf.org https://www.ietf.org/mailman/listinfo/alto
