Source: https://datatracker.ietf.org/doc/draft-ietf-alto-cost-calendar/ballot/
Timestamp: 2019-04-22 12:35:26+00:00

Document:
Summary: Has a DISCUSS. Needs one more YES or NO OBJECTION position to pass.
§3.1, definition of "time-interval-size": What is the reasoning behind using a string to define the unit? That requires text parsing/comparison to determine the interval. I assume this is intended more for machine use than for human use. Did the working group consider making this a multiple of some primitive time interval? E.g. number of seconds, or perhaps number of minutes? it seems like that would be easier (and therefore less error prone) to interpret.
If there is a reason to use a text field, is there an enumeration of legal unit values? Can I use "12 parsecs"?
§4.1.2, last paragraph: "The ALTO Client thus may use the same calendar for the next 4 days starting at "calendar-start-time" and will only need to request a new one for Friday July 4th at 00:00:00 GMT."
§2, 4th paragraph: "that can be historic": I don't see mention of how historic data would be used. Maybe I missed something?
§2.2.1, 2nd paragraph: Please elaborate on what is meant by "carefully managed". What specific things need to be considered?
§2.2.2, 3rd paragraph: This needs elaboration. I think it means that it must be possible to retrieve  the "now" version of the metric, but one could not retrieve a future value as a single value.
- 3rd paragraph: "A member "calendar-attributes" MUST appear only once": Does that mean exactly once? No more than once?
- note after definition of "number-of-intervals": Where is "cost-type-name" defined? Was this meant to be "cost-type-names"? If so, this paragraph makes it sound optional, but it was not shown as optional in the schema.
§4: It is not clear from the text if it saying the time zone is GMT in the example, or if it is always GMT. I assume the former, but the wording of the last paragraph suggests that the use of the HTTP header field format forces the time zone to always be GMT.
- Third paragraph:  I assume each entry corresponds to the requested metric at the same array position? If so, please say that explicitly.
- 2nd to last paragraph: I don't understand the purpose of this paragraph. I assume "supporting single cost type values" means "only supporting" them. Why would the client request calendared values in the first place if it only supported single values?
- last paragraph: How is this different than the requirement in the 2nd paragraph?
- first paragraph: "All arrays have a number of values equal to ’number-of-intervals’."
Which "number-of-intervals" does this talk about? The one in the capabilities or in "Calendar ResponseAttributes"?
Does that mean each element is valid for the time-interval that matches its array position? If so, please say that explicitly.
I'm surprised to see this require a metric entry for each individual time interval. It your want a high resolution of time intervals, you may end up with a large number of entries. Did the WG consider making it possible to have a single metric entry cover multiple time intervals? As this is currently defined, I think there needs to be guidance to implementors that they need to balance calendar length and granularity against the required number of metric entries.
- I'm not sure what it means for a repeat pattern to be "statistical".
- IDNits reports some issues; please check.
- Abstract: Please expand ALTO on first mention in the abstract and the body.
- Please expand PID on first mention.
resources capabilities": should that be something to the effect of "specified in terms of resource capabilities"?
-- "the proposed extensions": They will no longer be "proposed" once this is published as an RFC.
- paragraph 4: "flash mobs" seems like an odd example of a predictable event, at least to anyone other than the event organizers and participants.
- first bullet: "attributes to interpret the time scope": I think the client does the interpreting. Perhaps "attributes to describe the time scope"?
- "repeated": I gather there is no option for unbounded repetition; it would be worth mentioning that up front.
§3.1, third paragraph: "If "calendarattributes"
I assume this means "more than one" time. "Several" often connotes a number greater than a "few" but less than "many". That is, people may not think of "2" as "several".
- Please cite the json schema format you are using. I assume it is the one defined in the alto protocol RFC, but that should be mentioned explicitly.
- last paragraph: First sentence is hard to parse.
§3.2, first paragraph, first sentence: I'm not sure what "clarify" means in context; was that the correct word choice?
"routingcost" in the "numerical" mode."
The antecedents for both occurrences of "it" have unclear antecedents.
- First paragraph: The first sentence is confusing.  I think it means "instead of the format used by legacy implementations", but it con be interpreted the say that arrays are used for legacy implementations.
- 2nd paragraph: "include at least" doesn't really fit the content of the list entries.
- paragraph starting with "- In addition, the "meta" field..." If this is required, why was it not included in the bullet list of required information?
- definition of "calendar-start-time" : I don't understand how "by default" interacts with SHOULD.
§5, last paragraph: "For potential undesirable guidance of ALTO information..."
That wording is confusing. I suggest something like "To avoid malicious or erroneous guidance from ALTO information..."
This is a process DISCUSS.
This document replaces draft-randriamasy-alto-cost-calendar, but this information is not reflected in the datatracker.  The individual draft has an IPR declaration attached to it , but the failure to link the two documents has resulted in the IPR indication not carrying over.   The direct effect is that the IETF Last Call  explicitly says that "No IPR declarations have been submitted directly on this I-D."
The Shepherd writeup says that "The entire author team has confirmed conformance with BCP 78/79 with the shephered." -- but that doesn't indicate whether IPR is present or not, just conformance.  In looking through the mailing list archive, I couldn't find mention of the IPR at adoption   or at WGLC .
The declaration was made early in the process , and there was no discussion in the WG about it.  I can see how it would be easy to overlook.
Nonetheless, it is necessary for the WG (and the IETF as a whole) to explicitly consider the declaration before proceeding with the publication of this document.
Please use HTTPS URIs in the examples.
Section 4: I think the correct description of the time zone is actually UTC, per RFC 7231, even though timestamps get displayed with the acronym "GMT."
Thanks for specifying this useful capability.
allowed a cyclic pattern to repeat indefinitely. Just for my background, that's an intentional omission, right?
the member "cost-type-names" is an array of 1 or more values.
I don't really follow this argument.  Why does the value for "cost-type-names"
affect the structure of the containing "calendar-attributes"?
Where is the normative requirement on the server to behave in this fashion?
structured element in the language/structure.
the server returns an error.
Is it a MUST requirement for the server to check?
response-attributes", as specified for the Filtered Cost Map Service.
responses, but rereading it looks like it's just data structure reuse.
for the Filtered Cost Map Service (Section 4.1.2)".
* Section 4.2.3. and 4.2.4.
This document uses addresses from the allocatable global unicast IPv6 space in 2000::/3 in the examples. Please use addresses from the 2001:db8::/32 documentation prefix instead for the examples as per RFC6890.
Any reason this document requires the use of TLS 1.2 instead of TLS 1.3?
I agree that JSON issues found by Adam must be fixed before publication.
the document is easy to read. I have a handful of suggestions for improvement.
document through a formal validation prior to publication.
date. After fixing that error, you will find the missing comma. And so on.
this document to instead be "https://". I count four such instances.
Nit: The value for calendar-start-time needs to be enclosed in quotation marks.
literal values, they need to each be enclosed in quotation marks.
Please use an address from the range reserved by RFC 3489.
This comment applies to the example given in §4.2.4 as well.
There is a missing comma after the closing brace.

References: §3

§4

§2

§2

§2

§4

§3

§3

§5
 §4