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

[S2.2, nit]

* "maps can signed" -> "maps can be signed"

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/.

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.

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?

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.

I am supporting Francesca's DISCUSS on media type registration

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".