Reviewer: Reese Enghardt Review result: Ready with Issues I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://wiki.ietf.org/en/group/gen/GenArtFAQ>. Document: draft-ietf-mops-treedn-04 Reviewer: Reese Enghardt Review Date: 2024-05-01 IETF LC End Date: 2024-05-06 IESG Telechat date: Not scheduled for a telechat Summary: The document presents a fairly clear and concise case study. To make it more readable and useful, I suggest a few clarifications and tweaks in tone, as well as adding a bit more content to the interesting points about the multicast deployment issues. Major issues: None. Minor issues: Section 1: "[…] while more efficiently utilizing network resources, and thus, improving the experience of end users" Why does more efficiently utilizing network resources improve the experience of end users? Please consider explicitly stating any assumptions you are making, e.g., about bottleneck links. Section 3: How do these reasons interact with RFC 9049, which lists obstacles to deployment of path-aware networking techniques? Please consider reading Section 4 of RFC 9049 and naming the lessons from RFC 9049 that apply to Multicast. RFC9049 lists multicast as "future work" and I think it would be nice if this draft could be considered the future work item for multicast, as the authors appear to already have done the work of thinking through the deployment obstacles. Section 4: Please consider starting by saying that TreeDN can be either an overlay or a "native on-net". Section 8 summarizes it well: "TreeDN is essentially the synthesis of SSM plus overlay networking technologies like AMT." I think stating this basic principle early on will make it much easier for the reader to follow the rest of Section 4. "TreeDN leverages advances in the availability and understanding of overlay and underlay networking." What specific advances does TreeDN leverage? Does it use a new type of overlay different from previous overlays or underlays, or any new techniques that weren't available in previous overlays? If not, please consider rephrasing this text to explain in a more neutral tone that TreeDN leverages overlay networks because they have certain advantages, or similar. Section 5: "[…] specialized CDN devices, which typically are servers that need to be racked, powered and connected to revenue-generating ports on routers" I'm not sure revenue-generating port is a widely understood term. Please consider providing a brief explanation. "In this way, SPs can offer new RaaS functionality to content providers at potentially zero additional cost in new equipment (modulo the additional bandwidth consumption)." At face value, this text appears to be at odds with the previous statement that TreeDN reduces bandwidth consumption. Please consider rephrasing this text to make it clearer what is meant here. "Additionally, TreeDN is an open, standards-based architecture based on mature, widely implemented protocols." The term "standard" has a specific meaning in the IETF and refers to only RFCs published on the Standards Track, and not as Experimental or Informational RFCs. While it appears that TreeDN can be implemented based on specifications that are published as Standards-Track RFCs, I'm not sure if TreeDN mandates that only Standards Track protocols can be used, as opposed to Experimental or proprietary protocols. Please consider rephrasing this text to clarify to what extent TreeDN is always based on IETF standards. Section 6: "This reduces the cost for content sourcing […] By effectively reducing to zero the marginal cost to the source of reaching each additional audience member" I wonder if this text makes any implicit assumptions about the networks in which content sources are located and about the interconnections and cost models used by these networks. Please consider making these assumptions explicit. Section 7.2: "Traditional unicast-based CDNs frequently rely on HTTPS over TCP transport" Does this statement apply equally to QUIC, assuming we're not talking about MoQ but simply replicating the existing unicast model using HTTP/3? If so, please consider rephrasing this statement to be more generic and talk about HTTP in general, independent of version. Nits/editorial comments: Section 3: Please consider expanding PIM-SM and mLDP on first use. Section 4.2 Please consider expanding GTM on first use. -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
