Re: [CDNi] Request for WG Adoption: Capacity Insights

[Kevin Ma <[e-mail]>]

Hi Andrew,

  (As a chair) Given the reduced scope, i.e., just two FCI objects (though
see my comments below), I think adoption would be within scope of the
current charter if other folks feel this is good work for the WG to take
on.  I don't have a problem with issuing a formal call for adoption.  I've
included some comments on the current draft below.

thanx.

--  Kevin J. Ma

section 1.3:
  - In the new paragraph about the uCDN calling a dCDN API interface, what
interface is that?  Is that an interface outside of CDNI.  It's not clear
if that relates to anything in this particular draft?  It would be good to
clarify this.

section 2.1.1:
  - What is the scope of uniqueness for the id?  If it needs to be global,
then it needs a registry.  If it needs to be dCDN unique, then it is just
on the dCDN to ensure?
  - the configuration descriptions references a yet to be defined Telemetry
Interface?  Is that in the scope of this document?  If not, it would be
good to clarify (or remove) this.

section 2.1.1.1:
  - Should there be a registry for telemetry source types?  Will these be
globally unique and well specified (in an RFC?) for interoperability?

section 2.1.1.2:
  - What happens if there are duplicate names in a source object?
  - Is there a valid range for time-granularity, data-percentile, and/or
latency, e.g., 0-31622400, 0-100, and/or 0-2678400, respectively?  And what
happens if values are out of range?

section 2.2.1:
  - "CAN" is not an RFC2119 term.  "CAN" -> "MAY"?
  - What is the scope of uniqueness for the id?  If it needs to be global,
then it needs a registry.  If it needs to be dCDN unique, then it is just
on the dCDN to ensure?
  - Are there limits related to maximum-hard, maximum-soft, and current?
Should those be specified along with the capacity limit types?  And what
happens if values are out of range?
  - section 2.2.1 already defines a "Telemetry Source Object"; can we come
up with a different name to make it less confusing?

section 2.2.1.1:
  - Should there be a registry for capacity limit types?  Will these be
globally unique and well specified (in an RFC?) for interoperability?

section 2.2.1.2:
  - so, these are pointers back into a "Telemetry Source Object"?  What
happens if the reference is not found?

section 2.2.1.3:
  - This is subdividing a footprint?  Would it make more sense (or at least
be simpler) to just define more granular footprints.  It seems confusing to
make essentially another way specify footprints.

section 4:
  - I think there should probably be discussions of the potential attacks
if the data is intercepted/spoofed.
  - I think we also need a privacy section that discusses the potential
issues of divulging internal information about the CDN.

nits:

section 1.3:
  "it's current usage" -> "its current usage"
  "uCDN of limits of" -> "uCDN limit on"
  ", so that the uCDN can use to" -> " so that the uCDN can use it to"
  " i.e. " -> ", i.e., "
  "In the event that a" -> "In the event a"

section 2.1:
  "CDNi" -> "CDNI"
  "reference, allows" -> "reference allows"
  "non ambiguous metric use use" -> "non ambiguous metric use be used"
  "current usage and how" -> "current usage.  How"
  "to it's dCDN" -> "to its dCDN"

section 2.1.1.2:
  " .  I.e. is" -> ", e.g., is"
  "5 minutes" -> "300 seconds (i.e., 5 minutes)"
  "one hour" -> "3600 seconds (i.e., one hour)"




On Tue, Apr 5, 2022 at 9:08 AM Andrew Ryan <[e-mail]> wrote:

> Greetings,
>
>    Similar to the recent solicitation for adoption of the CDNI Metadata
> Model Extensions, I would like to submit a draft for consideration of
> adoption:
>
>
> https://datatracker.ietf.org/doc/draft-ryan-cdni-capacity-insights-extensions/
>
> The draft outlines extensions to the FCI payload registry, which will
> enable communication of Capacity/Delegation limits between a uCDN and
> dCDN.  This draft has been presented at IETF 111, IETF 112 and most
> recently at IETF 113  from which we have incorporated some great feed
> back into several revisions of the draft.
>
> I look forward to any feedback and/or support for the adoption of this
> draft.  Thank you very much for your time.
>
> Andrew Ryan
>
> _______________________________________________
> CDNi mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/cdni
>