[CDNi] draft-ryan-cdni-capacity-insights-extensions

Kevin Ma <kevin.j.ma.ietf@gmail.com> Sun, 07 November 2021 05:50 UTC

MIME-Version: 1.0
From: Kevin Ma <kevin.j.ma.ietf@gmail.com>
Date: Sun, 07 Nov 2021 01:50:21 -0400
Message-ID: <CAMrHYE2Nbqmh2nVQ5Cohz2+qkUcm-9YxMioARf3mZPktN0UdNA@mail.gmail.com>
To: Andrew Ryan <andrew.ryan@llnw.com>, "<cdni@ietf.org>" <cdni@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000051d0b505d02c744f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/cdni/OjvjftM00iiFMiZ8Hl7rgq9q0tY>
Subject: [CDNi] draft-ryan-cdni-capacity-insights-extensions
Precedence: list

Hi Andrew,

  Thanks for updating the draft.  There's a lot of good content in the new
version.  Some comments, questions, and nits below:

  - section 2.1.2: should "FCI.Telemetry" be "FCI.TelemetrySource"?
     Is it correct that this just describes attributes of the metrics
emitted by the given source and that it is not actually streaming any
metrics?  i.e., if I attached to the "capacity_metrics_region1" metrics
source, I could then expect to see streams of different types of metrics,
e.g., a 5m median bandwidth usage that is 25 minutes old?
    And is it then completely up to the CDNs to negotiate out-of-band how
to connect to a given source (push vs pull, endpoint addr/url, etc) and in
what format to expect the data (open telemetry, etc)?  Should that be in
the source object?

  - section 2.2: Do "total-limits" and "host-limits" need to be separate
arrays?  Is the only distinction that the former is not allowed to have
capacity limit objects with "host" names and the latter is?  Could it be a
single "limits" array, or is there some parsing efficiency to keeping them
separate?

  - section 2.3: I would remove RequestedCapacityLimits from the other
draft and just specify it here, if the context makes more sense.

  - section 3: Is the intent to also create new registries for the
telemetry source and capacity limit types?

  - sections 4/5: The security section probably needs to discuss issues
related to misuse or falsification of metrics information.  A privacy
section should also be added and probably needs to discuss concerns related
to exposing the proposed types of metrics information.

  thanx!

--  Kevin J. Ma

nits:
  - section 1: payload types are actually defined in section 2.2 of RFC
7736 (https://datatracker.ietf.org/doc/html/rfc7736#section-2.2)
  - section 2.1: "it's dCDN" -> "its dCDN" (multiple)
  - section 2.1: "a non ambiguous" -> "an unambiguous"
  - section 2.1.1.1: "format,etc" -> "format, etc"
  - section 2.1.1.2: "describe the metric" -> "describes the metric"
  - section 2.2.1: "deducing" -> "reducing"
  - section 2.3: "per host" -> "per-host"
  - section 3.1: "simialr" -> "similar"
  - section 3.1: will need to tighten up the language here
  - section 3.1.1; should link to section 2.1.2
  - section 3.1.2; should link to section 2.2.2
  - section 3.1.3; should link to section 2.3.2

[CDNi] draft-ryan-cdni-capacity-insights-extensio… Kevin Ma
Re: [CDNi] draft-ryan-cdni-capacity-insights-exte… Kevin Ma
Re: [CDNi] draft-ryan-cdni-capacity-insights-exte… Andrew Ryan