CDNI Capacity Capability Advertisement Extensions
draft-ietf-cdni-capacity-insights-extensions-12

Introduction:  I do agree with Paul's comment on superfluous information in this section.  I think that all of the first paragraph can be deleted.  In paragraph 3, the first sentence looks out of place in an introduction (especially in a standards track document), I would delete it.  The last paragraph is covered in the Terminology section. This leaves:  

"While delegating traffic from one CDN to the other, it is important to ensure that an appropriate amount of traffic is delegated. To achieve that, the SVTA Open Caching Capacity Insight Specification [OC-CII] defines a feedback mechanism to inform the delegator how much traffic may be delegated. The traffic level information provided by that interface will be consumed by services, such as the Open Caching Request router [OC-RR], to inform that service's traffic delegation decisions. 

This document defines and registers CDNI Payload Types (as defined at section 7.1 of [RFC8006]). These Payload types are used for Capability Objects added to those defined at section 4 of [RFC8008], which are required for the Open Caching Capacity Insights Interface [OC-CII]."

-12 has addressed my discuss.

Thanks for addressing my concerns. I have updated my ballot to No Objection.

Thank you to Peter E. Yee for the GENART review.

Thank you for resolving my DISCUSS feedback.

Thanks for addressing my DISCUSS and comments. FYI there's one residual nit, IMO not worth addressing unless you're doing another revision anyway.

## NITS

- s/agrred/agreed/

I support John's, Orie's, and Roman's DISCUSS positions.  I have perhaps an unfortunate suggestion to work around this, which is to change the registry to "RFC Required"; this would (in theory) force any such encumbrances to be declared according to our BCPs, and then the DE might be able to decide whether and how to proceed without having to do their own research and determination.

A minor point: In Section 3.1, the second column's title is "Reference", not "Specification".

In Section 2.2.1, for "maximum-soft", why the second SHOULD?  What might a legitimate reason be to set the soft limit higher than the hard limit, or to tolerate such an input?  What should a consumer do with such a situation?

Thanks for working on this specification, it seems to be usefull specification. I agreed with discusses related to DE checking on IPRs.