Content Delivery Network Interconnection (CDNI) Footprint and Capabilities Advertisement Using Application-Layer Traffic Optimization (ALTO)
draft-ietf-alto-cdni-request-routing-alto-22

[Ballot comment]
I have no substantive comments, but I did want to take a second to note how well written I found this document.

I especially liked the "Below is a non-normative review of key related points of [RFC8008] and [RFC8006]" summary in Section 2.2 Semantics of FCI Advertisement. It's really helpful for a newcomer to a topic to be able to read a document and get a reasonable understanding without having for first read 27 other documents, which also require reading 53 other documents, which also require an infinite recursion of other documents.

In addition, I found the rest of the document easy to read and understand, and appreciated the many good examples.

[Ballot comment]
Thank you for the work on this document, and for addressing my previous DISCUSS.

Many thanks to Thomas Fossati for his in-depth review: https://mailarchive.ietf.org/arch/msg/art/MKG2Cdin96WLcksnA6nAu6pvThM/ , and to Alexey Melnikov for his media-types review: https://mailarchive.ietf.org/arch/msg/media-types/uGakYYYPVjBEwei9isTaluPwhDE/.

[Ballot discuss]
Thank you for the work on this document, and for partly addressing my previous DISCUSS.

Many thanks to Thomas Fossati for his in-depth review: https://mailarchive.ietf.org/arch/msg/art/MKG2Cdin96WLcksnA6nAu6pvThM/ , and to Alexey Melnikov for his media-types review: https://mailarchive.ietf.org/arch/msg/media-types/uGakYYYPVjBEwei9isTaluPwhDE/.

Only 2 small changes noted by Alexey are still missing - quoting the relevant text in his mail https://mailarchive.ietf.org/arch/msg/media-types/LU4gHAY4fQZ6vK7rh8pdSfDwTO0/:

1. >>    Also when you split the registration template into 2 it would be
  >>    good to have a sentence here explaining how the two formats differ.
>
>
> Thanks for the suggestion. Could you kindly give us some further
> examples about what should be explained? Do we need to explain the
> different cases where the two subtypes should be used, or just explain
> the difference between the two registration forms?

The former. If I as an implementor read the registration, I need to
decide whether or not I should implement processing of this particular
media type.

2. I've just realized that you are also missing "Fragment identifier
considerations:" field after this one. (See RFC 6838) Having it as "N/A"
is fine.

Francesca

[Ballot discuss]
Thank you for the work on this document, and for partly addressing my previous DISCUSS.

Many thanks to Thomas Fossati for his in-depth review: https://mailarchive.ietf.org/arch/msg/art/MKG2Cdin96WLcksnA6nAu6pvThM/ , and thanks Alexey Melnikov for his media-types review.

I will keep this DISCUSS while waiting for the update making the changes discussed with Alexey: https://mailarchive.ietf.org/arch/msg/media-types/GhN8V1BqwcC4fEThhSRpCcn48gI/

Francesca

[Ballot comment]
Thanks to Klaas Wierenga for the SECDIR review.

Thanks for addressing my DISCUSS point

** Section 8.
    For authenticity and integrity of ALTO information, an attacker
      may disguise itself as an ALTO server for a dCDN, and provide
      false capabilities and footprints to a uCDN using the CDNI
      Advertisement service. 

-- I don’t follow the intent of the first clause.  Why is an _attacker_ concerned with the authenticity and integrity of the ALTO information?

-- What role can TLS, an associated server certificate (for the dCDN) and configured knowledge of this certificate at the uCDN mitigate some of this risk?  Shouldn’t the uCDNs only be communicating with a collection of known dCDNs with which it has some out-of-band negotiated arrangement?

** Section 8. 
      For availability of ALTO services, an attacker may conduct service
      degradation attacks using services defined in this document to
      disable ALTO services of a network.

Again, operating under the assumption that the dCDN (ALTO Server) would only be working with a known (prearranged) set of uCDNs and they would have authenticated somehow (per the DISCUSS), couldn’t repeated requested be rate limited and after attribution, filtered to minimize impact?

[Ballot comment]
I concur with Francesca's DISCUSS.

Please provide at least one complete sentence in Sections 3.3, 3.4, 5.4, 6.1.1.1, and 6.1.2.1.  For example:

  There are no applicable Accept Input parameters.

The "Interoperability considerations" part of Section 7.1 doesn't seem to be a complete answer to the corresponding guidance in Section 6.2 of RFC 6838.

[Ballot discuss]
The security consideration is silent on how to handle client (uCDN) authentication for this specific CDN use case.  Hence, the default guidance from Section 15.13.2 of RFC7285 seems to apply -- that HTTP Digest Authentication or TLS client authentication could be used.

If I understand the use case right, it seems like the uCDNs and dCDNs should know about each other, and there wouldn’t be an unreasonably large number of them to prevent credentials existing for peers.  Is there a reason why there isn’t a normative guidance requiring some kind of peer authentication given this narrow use case?  If not, why is ok given the significance of this ALTO data in FCI model.

[Ballot comment]
Thanks to Klaas Wierenga for the SECDIR review.

** Abstract.  Typo? 
RFC 8008 defines
  precisely the semantics of FCI and provides guidelines on the FCI
  protocol, but the exact protocol is specified

Shouldn’t this read, “but the exact protocol is _NOT_ specified”?

** Section 8.
    For authenticity and integrity of ALTO information, an attacker
      may disguise itself as an ALTO server for a dCDN, and provide
      false capabilities and footprints to a uCDN using the CDNI
      Advertisement service. 

-- I don’t follow the intent of the first clause.  Why is an _attacker_ concerned with the authenticity and integrity of the ALTO information?

-- What role can TLS, an associated server certificate (for the dCDN) and configured knowledge of this certificate at the uCDN mitigate some of this risk?  Shouldn’t the uCDNs only be communicating with a collection of known dCDNs with which it has some out-of-band negotiated arrangement?

** Section 8. 
      For availability of ALTO services, an attacker may conduct service
      degradation attacks using services defined in this document to
      disable ALTO services of a network.

Again, operating under the assumption that the dCDN (ALTO Server) would only be working with a known (prearranged) set of uCDNs and they would have authenticated somehow (per the DISCUSS), couldn’t repeated requested be rate limited and after attribution, filtered to minimize impact?

[Ballot discuss]
Thank you for the work on this document.

Many thanks to Thomas Fossati for his in-depth review: https://mailarchive.ietf.org/arch/msg/art/MKG2Cdin96WLcksnA6nAu6pvThM/ , and thanks to the authors for addressing it.

I have two comments that need to be addressed before publication.

As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a
DISCUSS ballot is a request to have a discussion; I really think that the
document would be improved with a change here, but can be convinced otherwise.

Francesca

1. -----


    data:  },
    data:  { "op": "add",
    data:    "/cdni-advertisement/capabilities-with-footprints
    /0/footprints/0/footprint-value/-",
    data:    "value": "192.0.2.0/24"
    data:  }
    data: ]

FP: JSON doesn't validate. The key "path": is missing.

2. -----

Media type registration

FP: I haven't seen the media type registrations being reviewed by the media-type mailing list, as requested by RFC 6838. Before progressing the document, I would really appreciate the authors to post the registrations to the media-type mailing list for review. Note that people there might also weigh in to the point Thomas made about the media type name, and if it's worth specifying a more detailed media type name, or not in this case.

[Ballot comment]
Thank you for the work put into this document.

Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education).

Special thanks to Vijay Kurbanifor for the shepherd's write-up including the section about the WG consensus.

Other special thanks to Donald Eastlake for the Internet directorate at:
https://datatracker.ietf.org/doc/review-ietf-alto-cdni-request-routing-alto-17-intdir-telechat-eastlake-2021-11-26/
I would appreciate it if you replied to Donald's comments.

I hope that this helps to improve the document,

Regards,

-éric

-- Section 3.6 --
Suggest to add "https/2.0" as delivery protocol to appear not too legacy ;-)

-- Sectin 3.7.2 --
Any reason why there is no IPv6 examples ? (Feel free to ignore my question) The first IPv6/dual-stack examples only appears in section 6.3.3

-- Section 6.3.4 --
Possibly caused by my own lack of expertise in ALTO, but this section starts with:
  In this example, the client is interested in updates for the
  properties "cdni-capabilities" and "pid" of two footprints
  "ipv4:192.0.2.0/24" and "countrycode:fr".
But in the example, I fail to see anything related to "countrycode:fr".

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

The IANA Functions Operator has completed its review of draft-ietf-alto-cdni-request-routing-alto-16. If any part of this review is inaccurate, please let us know.

IANA understands that some of the actions requested in the IANA Considerations section of this document are dependent upon the approval of and completion of IANA Actions in another document:

The IANA Functions Operator understands that, upon approval of this document, there are four actions that we must complete.

First, in the application registry on the Media Types registry page located at:

https://www.iana.org/assignments/media-types/

two new registrations will be made as follows:

Name:alto-cdni+json
Template: [ TBD-at-Registration ]
Reference: [ RFC-to-be; Section 3 ]

Name: alto-cdnifilter+json
Template: [ TBD-at-Registration ]
Reference: [ RFC-to-be; Section 5 ]

Second, in the CDNI Metadata Footprint Types registry on the Content Delivery Network Interconnection (CDNI) Parameters registry page located at:

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

a new footprint type will be registered as follows:

Footprint Type: altopid
Description: A list of PID names
Reference: [ RFC-to-be; Section 4 ]

As this document requests registrations in a Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. This review must be completed before the document's IANA state can be changed to "IANA OK."

Third, in a registry to be created upon the approval of [I-D.ietf-alto-unified-props-new], the ALTO Entity Domain Type Registry, two new entity domain types are to be registered as follows:

Identifier: asn
Entity Address Encoding: See section 6.1.1.2 of [ RFC-to-be ]
Hierarchy and Inheritance: None
Media Type of Defining Resource: None

Identifier: countrycode
Entity Address Encoding: See section 6.1.2.2 of [ RFC-to-be ]
Hierarchy and Inheritance: None
Media Type of Defining Resource: None
Reference: [ RFC-to-be ]

Fourth, also in a registry to be created upon the approval of [I-D.ietf-alto-unified-props-new], the ALTO Entity Domain Type Registry one new entity property type is to be registered as follows:

Identifier: cdni-capabilities
Intended Semantics: See Section 6.2 of [ RFC-to-be ]
Media Type of Defining Resource: application/alto-cdni+json
Reference: [ RFC-to-be ]

The IANA Functions Operator understands that these are the only actions 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.

Thank you,

Sabrina Tanamal
Lead IANA Services Specialist

The following Last Call announcement was sent out (ends 2021-08-30):

From: The IESG
To: IETF-Announce
CC: Vijay Gurbani , alto-chairs@ietf.org, alto@ietf.org, draft-ietf-alto-cdni-request-routing-alto@ietf.org, martin.h.duke@gmail.com, vijay.gurbani@gmail.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Content Delivery Network Interconnection (CDNI) Request Routing: CDNI Footprint and Capabilities Advertisement using ALTO) to Proposed Standard


The IESG has received a request from the Application-Layer Traffic
Optimization WG (alto) to consider the following document: - 'Content
Delivery Network Interconnection (CDNI) Request Routing: CDNI
  Footprint and Capabilities Advertisement using ALTO'
  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 2021-08-30. 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 Content Delivery Networks Interconnection (CDNI) framework
  defines a set of protocols to interconnect CDNs, to achieve multiple
  goals such as extending the reach of a given CDN to areas that are
  not covered by that particular CDN.  One component that is needed to
  achieve the goal of CDNI described in CDNI framework is the CDNI
  Request Routing Footprint & Capabilities Advertisement interface
  (FCI).  RFC 8008 defines precisely the semantics of FCI and provides
  guidelines on the FCI protocol, but the exact protocol is explicitly
  outside the scope of that document.  This document defines an FCI
  protocol using the Application-Layer Traffic Optimization (ALTO)
  protocol, following the guidelines defined in RFC 8008.





The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-alto-cdni-request-routing-alto/



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

1. Summary

Vijay K. Gurbani is the document shepherd for draft-ietf-alto-cdni-request-routing-alto. Martin Duke is the responsible Area Director.

RFC 8008 defines the semantics for the CDNI Footprint & Capabilities Advertisement Interface (FCI). This document specifies a concrete protocol for the CDNI FCI using the ALTO protocol. A new ALTO service called the "CDNI Advertisement Service" which conveys JSON objects of media type "application/alto-cdni+json" is defined. This service can convey CDNI FCI Base Advertisement Objects as defined in RFC8008 to ALTO clients via the ALTO protocol.  This document is targeted as a Standards Track document (Proposed Standard). This designation is appropriate as the document contains normative behaviour and message formats that should be adhered to by the communicating entities in order to realize the extension.

2. Review and Consensus
The “ALTO Service for CDNI FCI” had been added as a new ALTO WG milestone in 2017, following an agreement between the CDNI WG and the ALTO WG to finalise the ALTO service for conveying (i.e transporting) CDNI FCI objects in the ALTO WG. draft-ietf-alto-cdni-request-routing-alto has a long history and had been iterated and presented multiple times in the CDNI WG prior to 2017 (see draft-seedorf-cdni-request-routing-alto).  The document is well-known in the ALTO working group and has been presented many times. The approach is agreed upon and no objections have been raised during the WGLC on draft-ietf-alto-cdni-request-routing-alto-09 in February 2020. All comments from the individual reviews during the WGLC have since been addressed and the document has been revised further multiple times since the WGLC (now in draft-ietf-alto-cdni-request-routing-alto-13).

In summary, there is clear consensus for draft-ietf-alto-cdni-request-routing-alto in the ALTO WG, and it provides a very useful extension needed also by the CDNI WG to convey CDNI FCI objects defined in RFC8008. A WGLC has successfully been passed, and extensive
reviews were provided by various members of the WG and have all been addressed.

3. Intellectual Property
The shepherd confirms that each author has stated to him that to the best of his/her (i.e. the author’s) knowledge, all IPR related to this document has been disclosed.

4. Other Points
Note any downward references (see RFC 3967) and whether they appear in the DOWNREF Registry (http://trac.tools.ietf.org/group/iesg/trac/wiki/DownrefRegistry), as these need to be announced during Last Call.  All normative references are ok (with respect to RFC 3967) as they are all towards documents with standards-level “Proposed Standards”, “Internet Standard”, or “BCP”.

1. Summary

Vijay K. Gurbani is the document shepherd for draft-ietf-alto-cdni-request-routing-alto. Martin Duke is the responsible Area Director.

RFC 8008 defines the semantics for the CDNI Footprint & Capabilities Advertisement Interface (FCI). This document specifies a concrete protocol for the CDNI FCI using the ALTO protocol. A new ALTO service called the "CDNI Advertisement Service" which conveys JSON objects of media type "application/alto-cdni+json" is defined. This service can convey CDNI FCI Base Advertisement Objects as defined in RFC8008 to ALTO clients via the ALTO protocol.  This document is targeted as a Standards Track document (Proposed Standard). This designation is appropriate as the document contains normative behaviour and message formats that should be adhered to by the communicating entities in order to realize the extension.

2. Review and Consensus
The “ALTO Service for CDNI FCI” had been added as a new ALTO WG milestone in 2017, following an agreement between the CDNI WG and the ALTO WG to finalise the ALTO service for conveying (i.e transporting) CDNI FCI objects in the ALTO WG. draft-ietf-alto-cdni-request-routing-alto has a long history and had been iterated and presented multiple times in the CDNI WG prior to 2017 (see draft-seedorf-cdni-request-routing-alto).  The document is well-known in the ALTO working group and has been presented many times. The approach is agreed upon and no objections have been raised during the WGLC on draft-ietf-alto-cdni-request-routing-alto-09 in February 2020. All comments from the individual reviews during the WGLC have since been addressed and the document has been revised further multiple times since the WGLC (now in draft-ietf-alto-cdni-request-routing-alto-13).

In summary, there is clear consensus for draft-ietf-alto-cdni-request-routing-alto in the ALTO WG, and it provides a very useful extension needed also by the CDNI WG to convey CDNI FCI objects defined in RFC8008. A WGLC has successfully been passed, and extensive
reviews were provided by various members of the WG and have all been addressed.

3. Intellectual Property
The shepherd confirms that each author has stated to him that to the best of his/her (i.e. the author’s) knowledge, all IPR related to this document has been disclosed.

4. Other Points
Note any downward references (see RFC 3967) and whether they appear in the DOWNREF Registry (http://trac.tools.ietf.org/group/iesg/trac/wiki/DownrefRegistry), as these need to be announced during Last Call.  All normative references are ok (with respect to RFC 3967) as they are all towards documents with standards-level “Proposed Standards”, “Internet Standard”, or “BCP”.

Need IPR declaration from Jon Peterson.
Reminder email to Jon sent on Jun-17-2021.
Other than that, the I-D is ready to go.  As soon as the IPR is received,  I will upload the shepherd writeup and request publication.

Waiting for shepherd (vkg) to go over the revisions to path-vector and unified-props as a result of chair review of the documents.  As soon as I (vkg) have reviewed the revisions to these two drafts, they, along with cdni can move ahead to IESG as a cluster.

Request for posting confirmation emailed to previous authors: "Y. Yang" , Jan Seedorf , alto-chairs@ietf.org, Jon Peterson , Xiao Lin , Kevin Ma , Jingxuan Zhang

Request for posting confirmation emailed to previous authors: "Y. Yang" , Jingxuan Zhang , Xiao Lin , Jan Seedorf , Jon Peterson , alto-chairs@ietf.org, Kevin Ma