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

["Randriamasy, Sabine (Nokia - FR/Paris-Saclay)" <[e-mail]>]

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

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
----- [[SR]] Thanks a lot for the suggestion, we will use your proposed text

— 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”.
----- [[SR]] indeed, thanks, we will correct



----------------------------------------------------------------------
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].”
----- [[SR]] would the new text below be OK?
NEW
"with legacy ALTO Clients - those that only support RFC7285". 


   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.
----- [[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 —

   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.
----- [[SR]] thanks, we indeed mean Server and the Client and will correct this

— 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.
----- [[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 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)
----- [[SR]] thanks we will correct

   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
----- [[SR]] thanks we will correct

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

   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
----- [[SR]] Thanks a lot, we will use this text

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

   - 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?
----- [[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, 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.
----- [[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

   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.
----- [[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 —

   The cost type names used in the example IRD as thus as follows:

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

— Section 5.2.2 —

   Server response is thus changed as follows, w.r.t [RFC7285] and

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

— Section 5.2.3 —

   Therefore, it needs to both schedule its
   resource-greedy networking activities and its ALTO transactions.

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

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

   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
----- [[SR]] thanks, we will use this text

— 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.
----- [[SR]] indeed thanks, we will add "Braess"

   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
----- [[SR]] thanks a lot, we will use this text

   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
----- [[SR]] thanks a lot, more reader friendly indeed, we will use this text