Subject: [alto] Barry Leiba's Discuss on draft-ietf-alto-cost-calendar-17: (with DISCUSS and COMMENT)

From: Barry Leiba via Datatracker <[email-masked]>
Date: Wed, 26 Feb 2020 00:56:41 -0800

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

---

From: "Randriamasy, Sabine (Nokia - FR/Paris-Saclay)" <[email-masked]>
Date: Thu, 27 Feb 2020 14:11:53 +0000

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-masked]> 
Sent: Wednesday, February 26, 2020 9:57 AM
To: The IESG <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; Vijay Gurbani <[email-masked]>; [email-masked]
Subject: Barry Leiba's Discuss on draft-ietf-alto-cost-calendar-17: (with DISCUSS and COMMENT)

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

— Section 5 —

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 —

That isn’t a valid calendar-start-time value unless you remove “ at”.
----- [[SR]] indeed, thanks, we will correct

— Section 1 —

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

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 —

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 —

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 CalendarAttributes object is” (the final “s” is missing)
----- [[SR]] thanks we will correct

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

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

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

“potential issues caused by the precision issues” is really awkward; I suggest rephrasing.

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

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

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 —

Change “as thus” to “are”.
----- [[SR]] thanks, we will correct

— Section 5.2.2 —

Please don’t abbreviate “with respect to”.
----- [[SR]] thanks, we will correct

— Section 5.2.3 —

Make it “schedule both”.
----- [[SR]] thanks, we will correct

— Section 7 —

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

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 —

There’s something missing in the second line.
----- [[SR]] indeed thanks, we will add "Braess"

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

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

---

From: "Randriamasy, Sabine (Nokia - FR/Paris-Saclay)" <[email-masked]>
Date: Fri, 28 Feb 2020 15:07:18 +0000

Hello Barry,

Please note that the update we proposed in section 4.1 was initially:
NEW
is the positive integer, at least equal to 1, that indicates the number of values of the Cost Calendar array. END

In the posted version it is will actually:

NEW
is a strictly positive integer (greater or equal to 1),  that indicates the number of values of the Cost Calendar array. END

Thanks,
Sabine

-----Original Message-----
From: Randriamasy, Sabine (Nokia - FR/Paris-Saclay) <[email-masked]> 
Sent: Thursday, February 27, 2020 3:12 PM
To: Barry Leiba <[email-masked]>; The IESG <[email-masked]>
Cc: [email-masked]; [email-masked]; IETF ALTO <[email-masked]>; Vijay Gurbani <[email-masked]>
Subject: FW: Barry Leiba's Discuss on draft-ietf-alto-cost-calendar-17: (with DISCUSS and COMMENT)

Hello Barry,

Best regards,
Sabine

-----Original Message-----
From: Barry Leiba via Datatracker <[email-masked]> 
Sent: Wednesday, February 26, 2020 9:57 AM
To: The IESG <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; Vijay Gurbani <[email-masked]>; [email-masked]
Subject: Barry Leiba's Discuss on draft-ietf-alto-cost-calendar-17: (with DISCUSS and COMMENT)

— Section 5 —

NEW

— Section 5.1.2 —

— Section 1 —

— Section 3.1 —

— Section 3.3.2 —

— Section 4.1 —

NEW

   multiple

NEW

— Section 4.2 —

   To achieve

And this one.

— Section 4.3 —

— Section 5.2.2 —

— Section 5.2.3 —

Make it “schedule both”.

— Section 7 —

NEW

— Section 8 —

NEW

NEW