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

[Kevin Ma <[e-mail]>]

Hi Andrew,

  Thanks for the clarification.  If I look at this example:

   - traffic within 10.0.10/24 must stay under 20000000000 as per
   capacity_metrics_region2
   - traffic for serviceA.cdn.example.com within 10.0.0.0/8 must stay under
   30000000000 as per capacity_metrics_serviceA_region1

  "serviceA.cdn.example.com" is the "host" in the CDNI Metadata sense
(i.e., https://www.rfc-editor.org/rfc/rfc8006.html#section-4.1.2) and can
be extended with a "path-pattern" in the CDNI Metadata sense (i.e.,
https://www.rfc-editor.org/rfc/rfc8006.html#section-4.1.4), e.g., "
serviceA.cdn.example.com/hls".  It just feels to me like we already have a
construct for this, and perhaps just need a better surfacing of it.  Would
you agree that "host" or "host+path-pattern" (on top of existing
footprints) meet your requirements?  If so, we can figure out a good way to
use them.  If not, then I still may be misunderstanding the use case.

thanx!

--  Kevin J. Ma


On Wed, Nov 9, 2022 at 5:05 PM Andrew Ryan <[e-mail]> wrote:

> Kevin,
>
>   Apologies for the delayed response.
>
> The use case for the sub-scoping is as follows:  How could we define a
> limit specific to the type of traffic being delegated.  The type of traffic
> being delegated is a more granular component of the Footprint in which it
> would be associated with.
>
> My current understanding of the Footprints (there seems like there is some
> active discussion on this topic which I have yet to catch up with) is that
> these are associated with geoIP and/or network locations.  At this level,
> we would be dealing with a limit which is only defined by the user's
> location.  Some use cases were brought up surrounding the idea that "not
> all traffic is created equal". Example; game download traffic might be high
> bps low rps, where as Low Latency HLS could be high rps and high bps.
> These different traffic profiles could have different impact on the
> underlying CDN and therefore we wanted to allow for some additional
> granularity which would leverage an association of traffic type with the
> delivery host (or an identifier which maps to a configuration)
>
> The idea behind this is that the footprint provides the
> geographical/network boundary, which is consistent with FCI, but within the
> CapacityLimits FCI payload, we would leverage a scope object which would
> further define the limit to apply to not only the footprint but also this
> additional scope-type.
>
> The following was an example that was put together to highlight how this
> might be used in practive
> {
>   "capabilities":[
>     {
>       "capability-type":"FCI.CapacityLimits",
>       "capability-value":{
>           "limits":[
>           {
>             "id":"capacity_limit_region1",
>             "limit-type":"egress",
>             "maximum-hard":50000000000,
>             "maximum-soft":40000000000,
>             "telemetry-source":{
>               "id":"capacity_metrics_region1",
>                 "metric":"egress_5m"
>             }
>           },
>           {
>             "id":"capacity_limit_serviceA_region1",
>             "scope":{
>                 "type":"published-host",
>                 "values":[
>                 "serviceA.cdn.example.com"
>                 ]
>             },
>             "limit-type":"egress",
>             "maximum-hard":30000000000,
>             "maximum-soft":20000000000,
>             "telemetry-source":{
>                 "id":"capacity_metrics_serviceA_region1",
>                 "metric":"egress_5m"
>             }
>           }
>           ]
>       },
>       "footprints":[
>           {
>           "footprint-type": "ipv4cidr",
>           "footprint-value": ["10.0.0.0/8"]
>           }
>       ]
>     },
>     {
>       "capability-type":"FCI.CapacityLimits",
>       "capability-value":{
>         "limits":[
>         {
>           "id":"capacity_limit_region2",
>           "limit-type":"egress",
>           "maximum-hard":20000000000,
>           "maximum-soft":10000000000,
>           "telemetry-source":{
>             "id":"capacity_metrics_region2",
>               "metric":"egress_5m"
>           }
>          }
>           ]
>       },
>       "footprints":[
>           {
>           "footprint-type": "ipv4cidr",
>           "footprint-value": ["10.0.10.0/24"]
>           }
>       ]
>     }
>   ]
> }
>
>
>
> The following is a summary of what the FCI.CapacityLimits payload
> specifies represented in a hierarchical manner of the IPv4 CIDR ranges.
>
>    - 10.0.0.0/8
>       - ALL traffic <= 50000000000
>       - serviceA.cdn.example.com <= 30000000000
>    - 10.0.10/24
>       - ALL traffic <= 20000000000
>
>
> In a scenario a uCDN is considering how to delegate traffic for
> serviceA.cdn.example.com towards 10.0.10/24,   the following conditions
> need to be met:
>
>    - traffic within 10.0.10/24 must stay under 20000000000 as per
>    capacity_metrics_region2
>    - traffic for serviceA.cdn.example.com within 10.0.0.0/8 must stay
>    under 30000000000 as per capacity_metrics_serviceA_region1
>
>
> Ideally, the scoping would be fully contained within the Footprint object
> but in lieu of that, we implemented sub-scope specific to the
> CapacityLimits object
>
> This will likely be a good topic for discussion during IETF115.  We
> welcome any feedback on the topic.  Thanks!
>
> Andrew
> On 10/23/2022 11:27 PM, Kevin Ma wrote:
>
> Hi Andrew,
>
>   I wanted to restart the Capacity Limit Scope Object discussion.  If I
> understand correctly, you want to associate capacity more virtually with a
> specific host (in the Metadata interface HostMatch sense) and possibly with
> a specific path (in the Metadata interface PathMatch sense), as opposed to
> a Footprint which is more of a physical association?  Could we tie it back
> to the Metadata configuration?  Having something generic/opaque makes me
> uncomfortable.  Would a reference back to a Metadata interface
> HostMatch/PathMatch object work, or even to a specific Generic Metadata
> object?
>
> thanx!
>
> --  Kevin J. Ma
>
>
> On Fri, Jul 29, 2022 at 11:09 AM Kevin Ma <[e-mail]>
> wrote:
>
>> Hi Andrew,
>>
>>   Some quick responses:
>>
>> > Do you feel that clarifying the range to be positive integers and
>> leaving the limits "unbounded" would be sufficient here?
>> Yeah.  That's probably good.
>>
>> > I would propose that we state that invalid payloads can be ignored and
>> even state that any previously valid payloads can be honored until such a
>> time as a new valid payload can be acquired.
>> That works for me.
>>
>> > We may need some guidance on how to best define this.
>> You can look at how the footprint registry was defined here (it should be
>> pretty similar):
>> https://datatracker.ietf.org/doc/html/draft-ietf-cdni-metadata-21#section-7.2
>>
>> > ... Would the above two statements be useful if included into the
>> document?
>> Yes.  Thanks.  I think it is always better to show the IESG that we did
>> think about it and here's a quick explanation of the risks if something bad
>> were to happen.
>>
>> > I am wondering if it make sense to try and schedule a breakout session
>> to discuss this further, especially with several of the folks who have been
>> heavily involved with new draft for footprints.
>> It is probably worth starting a separate thread, and if necessary, we can
>> schedule an interim meeting if email is too cumbersome.
>>
>> thanx!
>>
>> --  Kevin J. Ma
>>
>> On Tue, Jul 19, 2022 at 10:48 AM Andrew Ryan <[e-mail]>
>> wrote:
>>
>>> Hi Kevin,
>>>
>>>   I wanted to take a moment before diving in to thank you for the
>>> fantastic feedback and engagement!  I am excited to have more and more
>>> folks involved with this.  As an FYI I will be unable to make the IETF CDNI
>>> session coming up, so I am hoping to drive a lot of progress on this
>>> through the email list.
>>>
>>> Please see answers inline
>>> On 7/9/2022 10:37 AM, Kevin Ma wrote:
>>>
>>> Hi Andrew,
>>>
>>>   Thanks for the responses.  Some additional comments:
>>>
>>> > > - 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?
>>> > @Ben keep me honest here, but the intention is that the ID be unique
>>> within the scope of the uCDN and dCDN, i.e. the namespace is specific to
>>> this CDNi delegation relationship.In this case, it would be up to the dCDN
>>> to ensure uniqueness in the payload that it is returning to the uCDN.
>>>
>>> This could probably just be clarified and made more explicit in the text.
>>>
>>> ack - I agree we can clarify this
>>>
>>>
>>>
>>> > > - 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?
>>> > In terms of valid ranges, I think the data-percentile would have a
>>> natural range of 0-100.  The others, I believe would not necessarily have a
>>> bound (outside of integer limits).  The usefulness of very large
>>> time-granularity and latency values somewhat diminish the usefulness of
>>> this data for near real time traffic steering decisions.
>>>
>>> I guess if you are only specifying a transport encoding, and not
>>> providing any guidance on how to interpret a given value, I guess I can see
>>> how you would want to limit restrictions on those fields.  Percentages
>>> outside of 0-100 are obvious ones, but I also don't know what a negative
>>> latency or negative time-granularity means, and a latency/time-granularity
>>> beyond a certain point (1yr?) is pretty meaningless.  My concern is that,
>>> from an interoperability standpoint, if the interpretation is different,
>>> then it could cause problems.  If the interpretation is going to be
>>> defined in a different spec or customized by individual CDNs, then we could
>>> make a stronger statement about that, but it feels like we could still be a
>>> little bit tighter on the bounds.
>>>
>>> You raise a very valid point in that at a bare minimum, we should be
>>> restricting to non negative values, as you point out, there is no situation
>>> that I can think of where an advertisement of negative capacity makes any
>>> sense.  Do you feel that clarifying the range to be positive integers and
>>> leaving the limits "unbounded" would be sufficient here?
>>>
>>>
>>>
>>> > > - What happens if there are duplicate names in a source object?
>>> > I think the intention behind declaring that the name needs to be
>>> unique circumvented any discussion on how to handle duplicate names
>>>
>>> With respect to error handling, I think it might be worth going a step
>>> beyond just specifying what a correctly formatted object looks like and
>>> provide some guidance on how to handle foreseeable error conditions (e.g.,
>>> non-unique or duplicated ids, out-of-range values, etc.).  I don't think
>>> we've done this as much in the past, but the previous capabilities were
>>> very binary (i.e., they contain a list of tokens and either you understand
>>> the token or not); but the complexity of information in the telemetry
>>> objects feels to me like there is more room for ambiguity and so could
>>> benefit from more discussion of how to handle unexpected data.  It may be
>>> as simple as: If the data doesn't make sense, ignore/discard it.  I could
>>> be off here, but that's my gut feel.
>>>
>>> I agree that specifying what to do if the payload doesn't make sense is
>>> a valuable addition.  I would propose that we state that invalid payloads
>>> can be ignored and even state that any previously valid payloads can be
>>> honored until such a time as a new valid payload can be acquired.  This
>>> will prevent situations where uCDNs who fail to get a valid payload from a
>>> dCDN don't stop all delegation due to a lack of updated limits, the uCDN
>>> will continue to use previously negotiated limits.  Using stale information
>>> might be considered a risk if the dCDN is truly having an outage, but in
>>> this case, this payload is more so about capacity guidance rather than any
>>> guarantee of service reliability, so I feel that the "use stale" case is
>>> probably more productive.
>>>
>>>
>>> > > - Should there be a registry for telemetry source types?  Will these
>>> be globally unique and well specified (in an RFC?) for interoperability?
>>> > @Ben I do think we will want a registry for telemetry source objects.
>>> > > - Should there be a registry for capacity limit types?  Will these
>>> be globally unique and well specified (in an RFC?) for interoperability?
>>> > I do believe this would make sense
>>>
>>> I agree that these should be registries.
>>>
>>> ack.  We may need some guidance on how to best define this.
>>>
>>> > > - I think we also need a privacy section that discusses the
>>> potential issues of divulging internal information about the CDN.
>>> > part of the data requirements are such that the data for capacity is
>>> scoped specifically to the uCDN,->dCDN delegation relationship..i.e. the
>>> data is very narrowly scoped.  The data being presented is also data about
>>> the dCDN by the dCDN.  Would there be any suggestions on how we might want
>>> to frame a statement for this?
>>>
>>> Though we rely on the underlying FCI protocol to handle auth and
>>> encryption (and the rest is out of the hands of the FCI object designer), I
>>> think it is worth discussing what happens if there is a breach, if there
>>> are specific consequences of specific data loss; or a statement that the
>>> data is so generic that it doesn't matter.  I think the question is: is
>>> there anything a competitor/adversary could gain from this data?  Since it
>>> only describes the source and doesn't contain the actual telemetry, the
>>> value of units and limits is minimal without hacking the actual source
>>> stream?  If so, a statement to that effect would probably suffice.
>>>
>>> In terms of the FCI.CapacityLimits payload, part of the design of the
>>> limits provided are what the dCDN is willing to offer to a specific uCDN
>>> for capacity.  If we look at this another way, it's not a full and complete
>>> mapping of all available capacity a dCDN may have.  We decided on this
>>> approach for several reasons, but at least one potential benefit of this is
>>> that it would limit the exposure to a dCDN of competitors being able to map
>>> out a full capacity footprint of the dCDN.
>>>
>>>
>>> In terms of someone gaining access to Telemetry endpoints which are
>>> referenced in FCI.Telemetry, this could be considered a issue for both the
>>> uCDN and the dCDN as this exposes actual usage information which is
>>> problematic for many reasons.  This particular data set though is provided
>>> outside the scope of the FCI payload, and relies on external
>>> APIs/datrasources/etc..
>>>
>>> Would the above two statements be useful if included into the document?
>>>
>>>
>>> > > - 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.
>>> > This was a very lengthy part of our discussion in this draft.  There
>>> are use cases where "all traffic is not created equal" i.e Low Latency HLS
>>> will have much different request characteristics than Bulk game downloads
>>> or even Video On Demand.  The CDNi Footprint object doesn't allow for
>>> granularity on a published host basis.  We were working under the
>>> fundamental premise that we were trying to cause as little disruption to
>>> the fundamental components of CDNi and trying to encapsulate as much as we
>>> could related to capacity management without major overhauls to the
>>> original spec.  We would greatly welcome discussion on this topic.
>>>
>>> I think this is the big one, and I too would welcome some discussion on
>>> the topic.  My initial reaction is: maybe we should try to define a new
>>> footprint type, rather than create a sub-footprint for just this one
>>> object; it sets a bad precedent.  But, it needs more thought.
>>>
>>> :-) this one may open up a large can of worms to be sure.  Part of our
>>> thought process with this draft was to keep it as isolated as we could to
>>> help with the adoption process, but perhaps that was not the right approach
>>> to take.
>>>
>>> As we mentioned, the purpose of providing the "scope" within the
>>> FCI.CapacityLimits object was to allow finer granularity within a
>>> Footprint, such that if an uCDN is delegating lots of different types of
>>> traffic to a dCDN, that the dCDN had a way to differentiate capacity
>>> advertisements for identifiers which might correlate to the type of
>>> delivery.  Another way of saying that would be that in a lot of cases,
>>> uCDNs would have different published hosts for different forms of video
>>> delivery (live.example.com, vod.example.com, etc..). The dCDN would be
>>> aware of these published hosts due to the configuration metadata associated
>>> with it, and would be able to be aware of "traffic type" and could decide
>>> to offer different rps or other such limits based on that.
>>>
>>> Published host is not the only differentiating factor though, different
>>> delivery types could be handled on the same domain, but with different
>>> paths (www.example.com/live, www.example.com/vod). In this case, using
>>> a published host in a scope within the FCI.CapacityLimits object would not
>>> be sufficient, but we did attempt to incorporate the ability to reference
>>> service-id or property-id which maps into groupings of configurations that
>>> the dCDN and uCDN are aware of.
>>>
>>> The summary of the issue is that we have a potential gap in the
>>> definition of footprint, the specificity that is provided by the
>>> configuration spec, and the potential use case for allowing capacity
>>> payloads to share the same specificity as the configuration spec.
>>>
>>> A counter point to providing this level of granularity is that in
>>> practice, it may be very cumbersome for dCDNs to provide very granular
>>> advertisements to a uCDN, and may simply opt to provide more of a blanket
>>> capacity advertisement, which the uCDN is free to use as it will (I feel
>>> like this will be the case for the most part).  There may be instances
>>> though where a dCDN does want to get very granular though, which is why we
>>> attempted to bring this functionality into the payload.
>>>
>>> I am wondering if it make sense to try and schedule a breakout session
>>> to discuss this further, esspecially with several of the folks who have
>>> been heavily involved with new draft for footprints.
>>>
>>>
>>>
>>>
>>> thanx!
>>>
>>> --  Kevin J. Ma
>>>
>>> On Fri, Jul 8, 2022 at 12:30 PM Andrew Ryan <[e-mail]>
>>> wrote:
>>>
>>>>
>>>> On 7/4/2022 12:35 PM, Kevin Ma wrote:
>>>>
>>>> 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.
>>>>
>>>>
>>>> The intention here was that the uCDN would interact with an interface
>>>> which provides FCI payloads.  To remove ambiguity I can remove the the
>>>> reference all together:
>>>>
>>>> Original:
>>>>
>>>> In normal operation a uCDN will communicate with a dCDN, via an
>>>> interface, to collect and understand any limits that a dCDN has set forth
>>>> for traffic delegation from a uCDN
>>>>
>>>> Proposed:
>>>>
>>>> In normal operation a uCDN will communicate with a dCDN to collect and
>>>> understand any limits that a dCDN has set forth for traffic delegation from
>>>> a uCDN
>>>>
>>>>
>>>>
>>>> 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?
>>>>
>>>> @Ben keep me honest here, but the intention is that the ID be unique
>>>> within the scope of the uCDN and dCDN, i.e. the namespace is specific to
>>>> this CDNi delegation relationship.In this case, it would be up to the dCDN
>>>> to ensure uniqueness in the payload that it is returning to the uCDN.
>>>>
>>>>   - 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.
>>>>
>>>> The Telemetry interface is NOT in scope of this document, we can add
>>>> clarifying language to explicitly state this.  In Section 2.1.1.1 an
>>>> additonal sentence can be added:
>>>> Proposed:  The definition of a CDNI Telemetry interface is outside the
>>>> scope of this document.
>>>>
>>>>
>>>>
>>>> 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?
>>>>
>>>> @Ben I do think we will want a registry for telemetry source objects.
>>>> The declaration of a "generic" type was meant as a place holder until a
>>>> formal Telemetry Interface was defined.  The Generic source type also
>>>> allows CDNs which already have an existing relationship and have already
>>>> established data channels for providing and consuming Telemetry to be used
>>>> "as is" without requiring additional integration steps.
>>>>
>>>>
>>>>
>>>> section 2.1.1.2:
>>>>   - What happens if there are duplicate names in a source object?
>>>>
>>>> I think the intention behind declaring that the name needs to be unique
>>>> circumvented any discussion on how to handle duplicate names
>>>>
>>>>
>>>>   - 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?
>>>>
>>>> The intention is that these are meant to provide guidance to the uCDN
>>>> in terms of how accurate and how far behind real time the data set is, to
>>>> help inform how to react from a traffic steering perspective.
>>>>
>>>> In terms of valid ranges, I think the data-percentile would have a
>>>> natural range of 0-100.  The others, I believe would not necessarily have a
>>>> bound (outside of integer limits).  The usefulness of very large
>>>> time-granularity and latency values somewhat diminish the usefulness of
>>>> this data for near real time traffic steering decisions.
>>>>
>>>>
>>>>
>>>>
>>>> section 2.2.1:
>>>>   - "CAN" is not an RFC2119 term.  "CAN" -> "MAY"?
>>>>
>>>> Understood, we will work to change this
>>>>
>>>>
>>>>   - 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?
>>>>
>>>> This should be unique between the uCDN and dCDN
>>>>
>>>>
>>>>   - 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?
>>>>
>>>> I am not sure we want to introduce an artificial cap outside of the
>>>> definition of the Integer itself as this will allow for the most
>>>> flexibility and hopefully prevent having to revisit the draft to increment
>>>> values in the future.
>>>>
>>>>
>>>>   - section 2.2.1 already defines a "Telemetry Source Object"; can we
>>>> come up with a different name to make it less confusing?
>>>>
>>>> @ben ^^
>>>>
>>>>
>>>>
>>>> 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?
>>>>
>>>> I do believe this would make sense and part of the intention of
>>>> defining it in this draft was an attempt to address that.  If there is a
>>>> more appropriate way to accomplish this, I would welcome guidance.
>>>>
>>>>
>>>> section 2.2.1.2:
>>>>   - so, these are pointers back into a "Telemetry Source Object"?  What
>>>> happens if the reference is not found?
>>>>
>>>> @Ben we will need to discuss this case.  It might be enough to require
>>>> that dCDNs ensure consistency in this manner, and if not, the payload could
>>>> be rejected by the uCDN.
>>>>
>>>>
>>>>
>>>> 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.
>>>>
>>>> This was a very lengthy part of our discussion in this draft.  There
>>>> are use cases where "all traffic is not created equal" i.e Low Latency HLS
>>>> will have much different request characteristics than Bulk game downloads
>>>> or even Video On Demand.  The CDNi Footprint object doesn't allow for
>>>> granularity on a published host basis.  We were working under the
>>>> fundamental premise that we were trying to cause as little disruption to
>>>> the fundamental components of CDNi and trying to encapsulate as much as we
>>>> could related to capacity management without major overhauls to the
>>>> original spec.  We would greatly welcome discussion on this topic.
>>>>
>>>>
>>>>
>>>> section 4:
>>>>   - I think there should probably be discussions of the potential
>>>> attacks if the data is intercepted/spoofed.
>>>>
>>>> Would there be any additional considerations outside of what is already
>>>> established for FCI in general?
>>>>
>>>>
>>>>   - I think we also need a privacy section that discusses the potential
>>>> issues of divulging internal information about the CDN.
>>>>
>>>> part of the data requirements are such that the data for capacity is
>>>> scoped specifically to the uCDN,->dCDN delegation relationship..i.e. the
>>>> data is very narrowly scoped.  The data being presented is also data about
>>>> the dCDN by the dCDN.  Would there be any suggestions on how we might want
>>>> to frame a statement for this?
>>>>
>>>>
>>>> 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"
>>>>
>>>> ACK
>>>>
>>>>
>>>>
>>>> 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"
>>>>
>>>> ack
>>>>
>>>>
>>>> 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)"
>>>>
>>>>
>>>>
>>>> ack
>>>>
>>>>
>>>>
>>>> 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
>>>>>
>>>>