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

[Andrew Ryan <[e-mail]>]

Kevin,

   Correct, in this sense serviceA.cdn.example.com is the "host" in the 
metadata sense.  If I understand what you are proposing is that we would 
want to essentially reference and/or reuse the same construct that the 
configuration API uses?

  At a high level, that would probably be ideal, since one of the 
concepts were were looking to leverage is that the dCDN would become 
aware of the hostname during the provisioning process (config API) and 
there would be a "service type" associated at that time, which would 
somewhat define what type of traffic this is.  This would be the 
indicator to the underlying system providing the data for the capacity 
limits.    Having a way to use a one to one mapping of what was 
referenced/defined in the configuration api in the capacitylimits FCI 
payload would probably remove any ambiguity.

There are some considerations surrounding the fact that footprints don't 
cleanly align with configuration especially when you consider 
redirection models (especially DNS since ).

On 11/10/2022 11:48 PM, Kevin Ma wrote:
> 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
>     <http://serviceA.cdn.example.com> within 10.0.0.0/8
>     <http://10.0.0.0/8> must stay under 30000000000 as per
>     capacity_metrics_serviceA_region1
>
>   "serviceA.cdn.example.com <http://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 <http://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
>     <http://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 <http://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 <http://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 <http://10.0.0.0/8>
>           o ALL traffic <= 50000000000
>           o serviceA.cdn.example.com <http://serviceA.cdn.example.com>
>             <= 30000000000
>       * 10.0.10/24
>           o ALL traffic <= 20000000000
>
>
>     In a scenario a uCDN is considering how to delegate traffic for
>     serviceA.cdn.example.com <http://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
>         <http://serviceA.cdn.example.com> within 10.0.0.0/8
>         <http://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 <http://live.example.com>,
>>             vod.example.com <http://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 <http://www.example.com/live>,
>>             www.example.com/vod <http://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 <http://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 <http://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 <http://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 <http://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 <http://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 <http://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
>>>>