[Gen-art] Gen-art LC Review of draft-ietf-alto-performance-metrics-17

[elwynd <[e-mail]>]

I am the assigned Gen-ART reviewer for this draft. The General AreaReview Team (Gen-ART) reviews all IETF documents being processedby the IESG for the IETF Chair.  Please treat these comments justlike any other last call comments.For more information, please see the FAQ at<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.Document: draft-ietf-alto-performance-metrics-17.txtReviewer: Elwyn DaviesReview Date: 2021/09/09IETF LC End Date: 2021/08/02IESG Telechat date: (if known) -Summary: Not ready.  My major concern with the document is the lack of precision in various aspects that would be needed to ensure an automated system could interpret the requests and responses that are  added to the basic ALTO protocol by this document.Major issues:The various examples of 'link' parameters:  It is unclear whether these links would be useful in an automated ALTO system.  Would it be expected that an ALTO server would read the contents of the link pointed to by the URL?  If so what structure would be expected?  This is particularly relevant in the 'estimation' cases where without a machine interpretable or set of standard mchanisms, the estimation option seems of minimal  use.  Do the authors anticipate that estimation methodologies might be standardized in the foreseeable future?   Similarly,  machine interpretable versions of SLA specifications are not something that sre conventionally available. Minor issues:s2.1, defininition of CostContext:  Given the name, I would expect that there could be more then one parameter specified.  For convenience and to make the information more machne readable, I would have expected the parameters to be passed over in a JSON object rather than an unspecified JSONvalue. [I observe that RFC 7285 does not define JSONobject.]   This particularly applies to the 'link' parameter case where the name and value need to be encoded.s7, ALTO Cost Source Registry:  The specification for this new registry is incomplete.  The review mechanism for new assgnments plus the definitions of the two fields are needed.   It may also be worth considering whether this field really nedes a registry.  Can the authors think of any other possibilities that might arise? Nits/editorial comments:General:  An RFC is not an academic paper and the form 'We xxxx' is not used.  A depersonalised form such as 'In this document...' needs to b used instead.  There are three instances that need fixing (s2, para 2;  s5, para 2; and s8. )  Abstract:  I suggest here a number of minor wording chages to improve the abstract:OLD:   Cost metric is a basic concept in Application-Layer Traffic
   Optimization (ALTO), and different applications may use different
   cost metrics.  Since the ALTO base protocol (RFC 7285) defines only a
   single cost metric (i.e., the generic "routingcost" metric), if an
   application wants to issue a cost map or an endpoint cost request to
   determine the resource provider that offers better delay performance,
   the base protocol does not define the cost metric to be used.

   This document addresses the issue by introducing network performance
   metrics, including network delay, jitter, packet loss rate, hop
   count, and bandwidth.

   There are multiple sources (e.g., estimation based on measurements or
   service-level agreement) to derive a performance metric.  This
   document introduces an additional "cost-context" field to the ALTO
   "cost-type" field to convey the source of a performance metric.
NEW:   The cost metric is a basic concept in Application-Layer Traffic
   Optimization (ALTO), and different applications may use different types of 
   cost metric.  Since the ALTO base protocol (RFC 7285) defines only a
   single cost metric (namely, the generic "routingcost" metric), if an
   application wants to issue a cost map or an endpoint cost request in order to
   identify a resource provider that offers a better delay performance,
   the base protocol does not define the cost metric to be used.

   This document addresses this issue by extending the specification to provide a variety  network performance   metrics, including network delay, jitter, packet loss rate, hop
   count, and bandwidth.

   There are multiple sources (e.g., estimation based on measurements or
   service-level agreement) to derive a performance metric.  This
   document introduces an additional "cost-context" field to the ALTO
   "cost-type" field to convey the source of a performance metric.
ENDs1, para 1: s/Cost metric/The cost metric/s1, para 5 (first on page 5): s/related with bandwith/related to bandwidth/s1, para 6: A refererence to RFC 7285 Section 9.2 should be given when the IRD is introduced.s1:  Some pieces of terminology are carried over from RFC 7285, notably JSONxxxx and PID.  These, together with the various media types defined in RFC 7285 and used in examples, should be documented in s1.s2.1, next to last para (above Figure 1): s/A potential architecture on estimating these metrics/A outline of potential information flows used for estimating these metrics/Figure 1 title: s/A framework to compute estimation to performance metrics/A framework for computing estimations of performance metrics/s3.1.3, para 1 and s3.3.3, para 1:  A reference to RFC 7285 Section 5.1 should be given when introducing PIDs.s4.3.4, last para: s/estimtation/estimation/Sent from my Galaxy