[alto] Ben Campbell's Discuss on draft-ietf-alto-cost-calendar-09: (with DISCUSS and COMMENT)

[Ben Campbell <[e-mail]>]

Ben Campbell has entered the following ballot position for
draft-ietf-alto-cost-calendar-09: 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:
----------------------------------------------------------------------

Thanks for the work on this document. I see value, but have a couple of points
I think need to be resolved prior to publication:

§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."

This implies that if an ALTO server delivers a calendar with a long duration,
it cannot make changes to the metrics in that calendar, or if it does make them
it cannot expect the client to learn about those changes. Is that the intent?
If so, it seems to contradict language in the security considerations (§6) that
future events may change and that the client should ensure information updates.
(The operational considerations [§7] also say the client does not need to query
again during the calendar duration.)


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I also have a number of substantive and editorial comments that do not rise to
the level of a DISCUSS:

*** Substantive Comments ***

- General: (No action expected): For future reference, this is the sort of
draft that I think should be referred to the ART area review team for review.
It's effectively an application layer protocol, even if it affects transport
layer decisions. (I note that none of the requested directorate reviews appear
to have happened either, which is unfortunate.)

§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.

§3.1,
- 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.

§4.1.1:

- Third paragraph:  I assume each entry corresponds to the requested metric at
the same array position? If so, please say that explicitly.

4th paragraph: 'This field SHOULD NOT be specified if no member
"calendar-attributes" is specified in this information resource.' Why is the
SHOULD NOT not a MUST NOT?  (Also, should "specified" be "included"?)

- 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?

§4.1.2
- 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.

- definition of "Calendar-start-time" Please elaborate on why the start time
SHOULD be no later than the current date? (Also, consider "SHOULD NOT be
later...")

§6: last paragraph:
- I'm not sure what it means for a repeat pattern to be "statistical".
- The guidance that future events can change and the client should ensure
information updates seems to conflict with guidance elsewhere that the client
does not need to requery until a calendar duration ends. (See DISCUSS point.)

*** Editorial Comments and Nits ***

- IDNits reports some issues; please check.

- Abstract: Please expand ALTO on first mention in the abstract and the body.

§1
- Please expand PID on first mention.

- 6th paragraph:
-- "specified by information
resources capabilities": should that be something to the effect of "specified
in terms of resource capabilities"? -- please expand IRD on first mention --
"the proposed extensions": They will no longer be "proposed" once this is
published as an RFC.

§2
- paragraph 4: "flash mobs" seems like an odd example of a predictable event,
at least to anyone other than the event organizers and participants.

§2.1,
- 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"
are specified several times"
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?

§3.3, first paragraph: "As [RFC7285] makes it mandatory, it uses metric
"routingcost" in the "numerical" mode."
The antecedents for both occurrences of "it" have unclear antecedents.

§4.1.2
- 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. - first major
bullet: I suspect "supports" should be "requested". (same for 2nd major bullet)

- 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..."