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

Received changes through RFC Editor sync (changed state to RFC, created became rfc relationship between draft-ietf-cdni-capacity-insights-extensions and RFC 9808, changed IESG state to RFC Published)

[Ballot comment]
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/

[Ballot comment]
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]."

[Ballot comment]
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?

[Ballot discuss]
Thanks for this document, which I, a non-expert, found generally easy to read and understand.

## DISCUSS

I guess it is obvious by now that there are cOnCeRnS about the unusual nature of the advice to the DE in Section 3.2. I agree with and support the other DISCUSSes, and want to add one more point that hasn't been raised yet, namely, this particular aspect:

          Designated Expert should confirm that the specification is
      [...] unencumbered by a patent
     
is not achievable as written, because you are asking the DE to render a legal opinion and to have complete knowledge of the entire corpus of international patents and all the relevant case law. No person has that, and those who come anywhere close bill their time at an hourly rate that would make our eyes water.

I'm guessing what you meant was something like "not known to be encumbered by a patent".

I suggest simply deleting the entire sentence. If that's palatable to the authors and WG, it's a clean fix that doesn't require much effort from any of us. If on the other hand, the authors and WG feel that some kind of IPR policing is important for this role, I think we will have to roll up our sleeves and see if this even comports with IETF policy vis-à-vis IPR (generally, we take no position as to IPR validity, just for starters). We might also need review by counsel.

[Ballot comment]
## COMMENT

### Section 2.1.1.1, "draft" won't age well

  At the time of this draft [...]

The RFCEd would probably catch this, but... that's not going to age well when published as an RFC. "At the time of this writing" or some other formulation would work better.

### Section 2.1.1.1, not a registry; singular vs. plural

                                                      The intention of
  this type registry is to allow for reference to another
  specification, e.g. a future CDNI telemetry interface, which would
  standardize the definition and format of telemetry data between
  participants of a CDNI workflow. 

This section doesn't define a registry, though, does it? It defines a type. Maybe just removing the word "registry" would be sufficient. Also, you use the singular, "reference to another specification" but looking at Section 3.2 it seems clear you mean to allow for a multitude of future specifications.

### Section 2.2.1

      Property: maximum-soft

        Description: A soft limit at which a uCDN SHOULD reduce traffic
        before hitting the hard limit.  This value SHOULD be less than
        the value of maximum-hard.  If this value is not specified, it
        is equal to the value of maximum-hard.

For the second SHOULD... under what circumstances would it be reasonable for an implementor to disregard the guidance? Recall that RFC 2119 defines SHOULD as,

3. SHOULD  This word, or the adjective "RECOMMENDED", mean that there
  may exist valid reasons in particular circumstances to ignore a
  particular item, but the full implications must be understood and
  carefully weighed before choosing a different course.

I am wondering what those "valid reasons in particular circumstances" are in this case. The only one I can think of is when maximum-soft == maximum-hard, i.e. the default case. I can't think of any circumstances under which it would be OK for maximum-soft > maximum-hard.

Unless I'm missing something, it seems to me this should be a MUST, or alternatively a lower-case "should" in which case it's up to the reader to make a sane and sensible interpretation since there's no MAGIC RFC 2119 SEMANTICS.

## NITS

- s/agrred/agreed/

[Ballot discuss]
I agree with the raised discusses by Roman and Orie.

Additionally, I have a concern with the Introduction section (the Section 1 part
before Section 1.1) that contains a lot of specific references to entities that
seems superfluous. The IETF generally tries to avoid mentioning the names of likely
consumers of an RFC. Can this be rewritten to without such references.

[Ballot discuss]
** Section 3.2
      If the type references a commercial specification,
      the Designated Expert should confirm that the specification is
      publicly available and that it is unencumbered by a patent,
      trademark, or other intellectual property restriction.

This guidance is underspecified.  I also have some concerns whether this is too much to ask a DE.  More specifically:

-- How is the designated expert supposed to accomplish these legal reviews?  Is the DE expected to do a patent search?  In what jurisdictions?  Do we need to find DEs with legal background?

-- How severe would the intellectual property restrictions have to be to prevent registrations?

-- Does “encumbered by a patent” mean there is a patent, even if the commercial entity has very favorable terms?

[Ballot discuss]
# Orie Steele, ART AD, comments for draft-ietf-cdni-capacity-insights-extensions-10
CC @OR13

* line numbers:
  - https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-cdni-capacity-insights-extensions-10.txt&submitcheck=True

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

Thanks to Carsten Bormann for the ART ART Review.

## Discuss

### DE's required to perform IPR check

```
615   *  The registration is applicable for general use and not
616       proprietary.  If the type references a commercial specification,
617       the Designated Expert should confirm that the specification is
618       publicly available and that it is unencumbered by a patent,
619       trademark, or other intellectual property restriction.
```

How should a DE handle cases where this confirmation is negative?
Does the DE have the ability to proceed with the registration request even when the confirmation is negative?

[Ballot comment]

## Comments

### SHOULD -> should?

```
381   advertisement.  The limits specified by the dCDN will inform the uCDN
382   on how much traffic may be delegated to the dCDN.  The limits
383   specified by the dCDN SHOULD be considered Not To Exceed (NTE)
384   limits.  The limits should be based on near real-time telemetry data
385   that the dCDN provides to the uCDN.  In other words, for each limit
386   that is advertised, there should also exist a telemetry source which
387   provides current utilization data against the particular advertised
388   limit.
```

When is it ok to ignore this advice regarding NTE?
What impact on interoperability does this SHOULD have?


### Why not MUST?

```
440         Description: A soft limit at which a uCDN SHOULD reduce traffic
441         before hitting the hard limit.  This value SHOULD be less than
442         the value of maximum-hard.  If this value is not specified, it
443         is equal to the value of maximum-hard.
```

For the second case a MUST seems perhaps better choice, for the first case, under which circumstances can the advice be ignored?


### Not an object

```
345   The following shows an example of Telemetry Capability including two
346   metrics for a source, that is scoped to a footprint.

348   "capabilities": [
```

```
527   The following shows an example of an FCI.CapacityLimits object.

529   "capabilities":[
```

Add wrapping curly braces, so the example is a well formed object?

As agreed during IETF 120 and following up from the ART ART review (see https://datatracker.ietf.org/doc/review-ietf-cdni-capacity-insights-extensions-06-artart-lc-bormann-2024-07-01/ and also https://mailarchive.ietf.org/arch/msg/cdni/8WIyMeC7QHJpCpPQ5oBbL2xdBsE/ ), the draft should be updated with IANA registries.

Request for Last Call review by GENART Completed: Ready with Nits. Reviewer: Peter Yee. Sent review to list. Submission of review completed at an earlier date.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-cdni-capacity-insights-extensions-06. If any part of this review is inaccurate, please let us know.

IANA understands that, upon approval of this document, there is a single action which we must complete.

In the CDNI Payload Types registry in the Content Delivery Network Interconnection (CDNI) Parameters registry group located at:

https://www.iana.org/assignments/cdni-parameters/

two new registrations are to be made as follows:

Payload Type: FCI.Telemetry
Reference: [ RFC-to-be ]

Payload Type: FCI.CapacityLimits
Reference: [ RFC-to-be ]

As this document requests registrations in an Expert Review or Specification Required (see RFC 8126) registry, we have initiated and completed the required Expert Review via a separate request.

We understand that this is the only action required to be completed upon approval of this document.

NOTE: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Sr. Specialist

The following Last Call announcement was sent out (ends 2024-06-17):

From: The IESG
To: IETF-Announce
CC: cdni-chairs@ietf.org, cdni@ietf.org, draft-ietf-cdni-capacity-insights-extensions@ietf.org, francesca.palombini@ericsson.com, sanjay.mishra@verizon.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (CDNI Capacity Capability Advertisement Extensions) to Proposed Standard


The IESG has received a request from the Content Delivery Networks
Interconnection WG (cdni) to consider the following document: - 'CDNI
Capacity Capability Advertisement Extensions'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2024-06-17. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  The CDNI Capacity Capability Advertisement Extensions define a set of
  additional Capability Objects that provide information about current
  dCDN utilization and specified usage limits to the delegating uCDN in
  order to inform traffic delegation decisions.

  This document supplements the CDNI Capability Objects defined in RFC
  8008 with two additional Capability Objects: FCI.CapacityLimits and
  FCI.Telemetry.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-cdni-capacity-insights-extensions/



No IPR declarations have been submitted directly on this I-D.

Document Shepherd: Sanjay Mishra

Responsible AD: Francesca Palombini

This document defines a framework for information exchange to facilitate traffic delegation decisions between an upstream CDN (uCDN) and a downstream CDN (dCDN) specifically about acceptable levels of traffic to delegate. The framework establishes limits that are specific to delegation relationship and defines limits in unambiguous and mutually understood units. To achieve this goal, the document defines two new payload types:

1. FCI.CapacityLimits to specify the limit of traffic that should be delegated in units, such as Bits per Second called limit-types (also references a specific Telemetry source which outlines current usage of a particular limit-type

2. FCI.Telemetry that allows the advertisement of what types of Telemetry sources are supported. This is Initially scoped to generic Telemetry sources, but paves the way for a formal Telemetry interface integration

The above two payload types are defined as per Section 5 of [RFC8008] that describes the FCI Capability Advertisement Object, which contains a CDNI Capability Object as well as the capability object type (a CDNI Payload Type).

This document was first submitted in July 2021 and since then has been extensively discussed and reviewed within the CDNI working group and there was no disagreement about its usage and the proposed changes. This document allows a downstream CDN to expose its capacity limit and potentially the current usage and avoid being overloaded by the upstream CDN.

The draft has gone through many rounds of review and I feel confident that the document and is ready for the AD.
The draft creates two new IANA payload registries as mentioned earlier.

The draft is being submitted as a proposed standard. The draft is clear of any nits.

There is also currently one CDN provider that has implemented and other has indicated plans to implement.

The authors have confirmed that there is no undisclosed IPR to their knowledge.

The normative references are all freely available and normative. 

There are no downrefs or unpublished RFC references.

Publication of this draft does not change the status of any other RFCs.

Document Shepherd: Sanjay Mishra

Responsible AD: Francesca Palombini

This document defines a framework for information exchange to facilitate traffic delegation decisions between an upstream CDN (uCDN) and a downstream CDN (dCDN) specifically about acceptable levels of traffic to delegate. The framework establishes limits that are specific to delegation relationship and defines limits in unambiguous and mutually understood units. To achieve this goal, the document defines two new payload types:

1. FCI.CapacityLimits to specify the limit of traffic that should be delegated in units, such as Bits per Second called limit-types (also references a specific Telemetry source which outlines current usage of a particular limit-type

2. FCI.Telemetry that allows the advertisement of what types of Telemetry sources are supported. This is Initially scoped to generic Telemetry sources, but paves the way for a formal Telemetry interface integration

The above two payload types are defined as per Section 5 of [RFC8008] that describes the FCI Capability Advertisement Object, which contains a CDNI Capability Object as well as the capability object type (a CDNI Payload Type).

This document was first submitted in July 2021 and since then has been extensively discussed and reviewed within the CDNI working group and there was no disagreement about its usage and the proposed changes. This document allows a downstream CDN to expose its capacity limit and potentially the current usage and avoid being overloaded by the upstream CDN.

The draft has gone through many rounds of review and I feel confident that the document and is ready for the AD.
The draft creates two new IANA payload registries as mentioned earlier.

The draft is being submitted as a proposed standard. The draft is clear of any nits.

There is also currently one CDN provider that has implemented and other has indicated plans to implement.

The authors have confirmed that there is no undisclosed IPR to their knowledge.

The normative references are all freely available and normative. 

There are no downrefs or unpublished RFC references.

Publication of this draft does not change the status of any other RFCs.