Hi Adam, Thanks a lot for your feedback. The JSON examples and ipv6 address ranges will be corrected. Otherwise, see my answer to one of your comments inline, All the best for 2019, Sabine
-----Original Message----- From: Adam Roach <[email protected]> Sent: Thursday, November 29, 2018 3:48 AM To: The IESG <[email protected]> Cc: [email protected]; Gurbani, Vijay (Nokia - US/Naperville) <[email protected]>; [email protected]; Gurbani, Vijay (Nokia - US/Naperville) <[email protected]>; [email protected] Subject: Adam Roach's No Objection on draft-ietf-alto-cost-calendar-09: (with COMMENT) Adam Roach has entered the following ballot position for draft-ietf-alto-cost-calendar-09: 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 to everyone who worked on creating this extension. It seems useful, and the document is easy to read. I have a handful of suggestions for improvement. --------------------------------------------------------------------------- General: I found a surprising number of JSON errors in this document by casual examination. Those errors I found are called out below, but it is extremely likely that I have missed some issues. Please run the JSON examples in this document through a formal validation prior to publication. With a reasonably modern version of nodejs, validation can be as simple as something like: node -e 'console.log(JSON.stringify(JSON.parse(` { "meta" : { "cost-type" : {"cost-mode" : "numerical", "cost-metric" : "routingcost"}, "calendar-response-attributes" : [ {"calendar-start-time" : Mon, 30 Jun 2014 00:00:00 GMT, "time-interval-size" : "1 hour", "number-of-intervals" : 24, "repeated": 4 } ], } "endpoint-cost-map" : { "ipv4:192.0.2.2": { "ipv4:192.0.2.89" : [v1, v2, ... v24], "ipv4:198.51.100.34" : [v1, v2, ... v24], "ipv4:203.0.113.45" : [v1, v2, ... v24], "ipv6:2000::1:2345:6789:abcd" : [v1, v2, ... v24] } } } `)));' Running this example shows the first error in this example, involving the date. After fixing that error, you will find the missing comma. And so on. --------------------------------------------------------------------------- General: Please expand "ALTO" in the title, in the Abstract, and on first use in the body of the document. [[SR]] DONE --------------------------------------------------------------------------- §6: > [RFC7285] ensures the availability of such a solution in its Section > 8.3.5. "Authentication and Encryption", which specifies that "ALTO > server implementations as well as ALTO client implementations MUST > support the "https" URI scheme [RFC2818] and Transport Layer Security > (TLS) [RFC5246]". Based on this guidance, I would encourage updating all instances of "http://"; in this document to instead be "https://";. I count four such instances. [[SR]] DONE --------------------------------------------------------------------------- §1: > In this draft an "ALTO Cost Calendar" is specified by information > resources capabilities that are applicable to time-sensitive ALTO > metrics. An ALTO Cost Calendar exposes ALTO Cost Values in JSON Please cite RFC 8259. [[SR]] DONE --------------------------------------------------------------------------- §4.1.3: > "calendar-response-attributes" : [ > "calendar-start-time" : Tue, 1 Jul 2014 13:00:00 GMT, > "time-interval-size" : "2 hour", Nit: The value for calendar-start-time needs to be enclosed in quotation marks. "cost-map" : { "PID1": { "PID1": [v1,v2, ... v12], "PID2": [v1,v2, ... v12], "PID3": [v1,v2, ... v12] }, "PID2": { "PID1": [v1,v2, ... v12], "PID2": [v1,v2, ... v12], "PID3": [v1,v2, ... v12] } } I don't quite follow this closely enough to understand what is intended here, but the naked 'v1,v2' in the arrays are not valid JSON. Assuming these are literal values, they need to each be enclosed in quotation marks. Both of these comments apply to the examples given in §4.2.3 and §4.2.3 as well. [[SR]] The purpose is actually to lighten the reading. Would the following addition to paragraph 3 of section 4.1.3 be OK ? "The Server returns Calendars with arrays of 12 numbers. To lighten the text, the arrays in the provided example are symbolized by expression "[v1,v2, ... v12]" that is otherwise not valid in JSON. The same type of symbolization is used in the example Server responses." --------------------------------------------------------------------------- §4.2.3: > "ipv6:2000::1:2345:6789:abcd" Please use an address from the range reserved by RFC 3489. This comment applies to the example given in §4.2.4 as well. > } > "endpoint-cost-map" : { There is a missing comma after the closing brace. --------------------------------------------------------------------------- §4.2.4: > "calendar-response-attributes" : [ > {"cost-type-name : num-routingcost" Nit: This line is missing two quotation marks and a comma. It should be: {"cost-type-name" : "num-routingcost", _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
