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
_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
