Karen, The updated doc looks good to me. Thanks for your excellent suggestions.
I approve this document for publication. -Lenny On Thu, 2 Jan 2025, Karen Moore wrote: | | Dear Lenny, | | We have updated our files with your suggested text for the Abstract and Introduction. Please review and let us know if any further changes are needed. We will await approvals from each author prior to publication. | | -- FILES (please refresh) -- | | The updated XML file is here: | https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9706.xml__;!!NEt6yMaO-gk!EED8z53POoqI68PlvezQAzXZ_u5cpO2i1vwt9TZMYKyalSek-H4YOS86KHmHFLKChbP7UzSlHUk$ | | The updated output files are here: | https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9706.txt__;!!NEt6yMaO-gk!EED8z53POoqI68PlvezQAzXZ_u5cpO2i1vwt9TZMYKyalSek-H4YOS86KHmHFLKChbP7oNesOkg$ | https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9706.pdf__;!!NEt6yMaO-gk!EED8z53POoqI68PlvezQAzXZ_u5cpO2i1vwt9TZMYKyalSek-H4YOS86KHmHFLKChbP7eI_nnWI$ | https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9706.html__;!!NEt6yMaO-gk!EED8z53POoqI68PlvezQAzXZ_u5cpO2i1vwt9TZMYKyalSek-H4YOS86KHmHFLKChbP79dH149A$ | | This diff file shows all changes made during AUTH48: | https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9706-auth48diff.html__;!!NEt6yMaO-gk!EED8z53POoqI68PlvezQAzXZ_u5cpO2i1vwt9TZMYKyalSek-H4YOS86KHmHFLKChbP70rKoUjk$ | | These diff files show only the changes made during the last edit round: | https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9706-lastdiff.html__;!!NEt6yMaO-gk!EED8z53POoqI68PlvezQAzXZ_u5cpO2i1vwt9TZMYKyalSek-H4YOS86KHmHFLKChbP7cdUXvKY$ | https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9706-lastrfcdiff.html__;!!NEt6yMaO-gk!EED8z53POoqI68PlvezQAzXZ_u5cpO2i1vwt9TZMYKyalSek-H4YOS86KHmHFLKChbP7uRtB2eg$ | | This diff file shows all changes made to date: | https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9706-diff.html__;!!NEt6yMaO-gk!EED8z53POoqI68PlvezQAzXZ_u5cpO2i1vwt9TZMYKyalSek-H4YOS86KHmHFLKChbP7oFDVgio$ | | For the AUTH48 status of this document, please see: | https://urldefense.com/v3/__https://www.rfc-editor.org/auth48/rfc9706__;!!NEt6yMaO-gk!EED8z53POoqI68PlvezQAzXZ_u5cpO2i1vwt9TZMYKyalSek-H4YOS86KHmHFLKChbP70xyzIF0$ | | Thank you, | RFC Editor/kc | | > On Dec 26, 2024, at 11:29 AM, Leonard Giuliano <le...@juniper.net> wrote: | > | > | > Thanks Karen, see inline: | > | > On Mon, 23 Dec 2024, Karen Moore wrote: | > | > | Hi Lenny, | > | | > | Thank you for the additional suggestions. We have updated our files accordingly. Please see comments below. | > | | > | 1) We updated "4K/8K/Augmented Reality (AR)” to “4K / 8K / Augmented Reality (AR)” as terms with 2 words require a space before and after the slash. | > | > In the abstract, there is a missing space between the slash and 8K. But | > thinking about this more, how about the following change to this first | > sentence in the abstract and intro: | > | > As Internet audience sizes for high-interest live events reach | > unprecedented levels and bitrates climb to support formats and | > applications such as 4K, 8K and Augmented Reality (AR), ... | > | > | | > | 2) We reverted the dashes as requested (2 instances) and reverted the bulleted list in Section 5. | > | > The dashes are in the abstract, but the intro still has the semicolon. | > Recall, you copied the abstract into the intro so they shoudl be the same. | > | > Also, could we revert to "in some cases, at no additional cost" instead of | > "in some cases, there is no additional cost"? Your call. | > | > | | > | 3) We removed “and” in Section 6.2. | > | > Thx | > | > | | > | 4) Regarding the capitalization of “deprecation”, we assume that | > | "Any-Source Multicast (ASM) deprecation” is intended to be a nickname | > | for the title of RFC 8815, so we capitalized “deprecation”. Otherwise, | > | another option is to list the exact title as shown below. | > | > Current looks perfect now, thx. | > | > | | > | Current: | > | Further rationale for this SSM-only approach can be found in | > | Any-Source Multicast (ASM) Deprecation [RFC8815]. | > | | > | Perhaps: | > | Further rationale for this SSM-only approach can be found in | > | "Deprecating Any-Source Multicast (ASM) for Interdomain | > | Multicast" [RFC8815]. | > | | > | 5) In Section 7, we updated "Section 8" to "Section 9”. | > | > Thx | > | > | | > | 6) In Section 10, we updated the reference entry for [Multicast-Menu] | > | and added a citation for [Offnet-Sourcing-Multicast-Menu] (note that we | > | took out “with” in the name as it’s fairly long). Please review the text | > | and the reference entries and let us know if any further updates are | > | needed. | > | > Current text looks perfect now, thx. | > | > | | > | -- FILES (please refresh) -- | > | | > | The updated XML file is here: | > | https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9706.xml__;!!NEt6yMaO-gk!EWtceeKI4JKaRAa7FhFKA1M3uh7Voj19BN3s6aQgYSU8C_7rulw4qBpJsxe1C7BV_iou-ubLadw$ | > | | > | The updated output files are here: | > | https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9706.txt__;!!NEt6yMaO-gk!EWtceeKI4JKaRAa7FhFKA1M3uh7Voj19BN3s6aQgYSU8C_7rulw4qBpJsxe1C7BV_ioujHpie10$ | > | https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9706.pdf__;!!NEt6yMaO-gk!EWtceeKI4JKaRAa7FhFKA1M3uh7Voj19BN3s6aQgYSU8C_7rulw4qBpJsxe1C7BV_ioufmPIGyA$ | > | https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9706.html__;!!NEt6yMaO-gk!EWtceeKI4JKaRAa7FhFKA1M3uh7Voj19BN3s6aQgYSU8C_7rulw4qBpJsxe1C7BV_ioub4lELH4$ | > | | > | This diff file shows all changes made during AUTH48: | > | https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9706-auth48diff.html__;!!NEt6yMaO-gk!EWtceeKI4JKaRAa7FhFKA1M3uh7Voj19BN3s6aQgYSU8C_7rulw4qBpJsxe1C7BV_iouMCa60g8$ | > | | > | These diff files show only the changes made during the last edit round: | > | https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9706-lastdiff.html__;!!NEt6yMaO-gk!EWtceeKI4JKaRAa7FhFKA1M3uh7Voj19BN3s6aQgYSU8C_7rulw4qBpJsxe1C7BV_iou18sYfcE$ | > | https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9706-lastrfcdiff.html__;!!NEt6yMaO-gk!EWtceeKI4JKaRAa7FhFKA1M3uh7Voj19BN3s6aQgYSU8C_7rulw4qBpJsxe1C7BV_iour3sfs6U$ | > | | > | This diff file shows all changes made to date: | > | https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9706-diff.html__;!!NEt6yMaO-gk!EWtceeKI4JKaRAa7FhFKA1M3uh7Voj19BN3s6aQgYSU8C_7rulw4qBpJsxe1C7BV_iout1-EQKY$ | > | | > | Please contact us with any further updates or with your approval of the document in its current form. We will await approvals from each author prior to moving forward in the publication process. | > | | > | For the AUTH48 status of this document, please see: | > | https://urldefense.com/v3/__https://www.rfc-editor.org/auth48/rfc9706__;!!NEt6yMaO-gk!EWtceeKI4JKaRAa7FhFKA1M3uh7Voj19BN3s6aQgYSU8C_7rulw4qBpJsxe1C7BV_iou0GRASdk$ | > | | > | Thank you, | > | RFC Editor/kc | > | | > | | > | > On Dec 23, 2024, at 3:02 PM, Leonard Giuliano <le...@juniper.net> wrote: | > | > | > | > Karen, | > | > | > | > Thanks for the update. | > | > | > | > I went through the entire doc and found a few minor nits. LMK what you | > | > think: | > | > | > | > 1) Abstract and Intro | > | > Old: | > | > 4K/8K Augmented Reality (AR) | > | > | > | > New: | > | > 4K/8K/Augmented Reality (AR) | > | > | > | > Explanation: these are 3 different (but related) things, so the / should | > | > be between 8K and AR for the same reason it is between the 4K and 8K | > | > | > | > 2) Abstract and Intro | > | > Old | > | > unicast-based CDNs; in some cases, there is no additional cost to the infrastructure. | > | > | > | > New: | > | > unicast-based CDNs- in some cases, at no additional cost to the | > | > infrastructure. | > | > | > | > Explanation: not to ignite a grammar war, but the em dash seems more | > | > appropriate here than the semicolon, as it isolates and creates a dramatic | > | > pause for emphasis, rather than combining ideas; plus, the latter clause | > | > doesn't feel independent enough to earn a semicolon ;) | > | > | > | > 3) Sect 5: Any chance the three problems mentioned in sect 5 can go back | > | > to being a bulletized list? Seems like it would improve readability. | > | > | > | > 4) Sect 6.1 | > | > Old: | > | > (aka, "off-net receivers"); this addresses the "All or Nothing" problem. | > | > Links and devices that do not support multicast are simply tunneled over; | > | > they no longer present a barrier to the overall replication service for | > | > end users. | > | > | > | > New: | > | > (aka, "off-net receivers"), which addresses the "All or Nothing" problem. | > | > Links and devices that do not support multicast are simply tunneled over- | > | > they no longer present a barrier to the overall replication service for | > | > end users. | > | > | > | > Explanation: the "addresses the "All or Nothing" problem" was intended to | > | > be a nonrestrictive clause (an aside of "oh, by the way, this also | > | > addresses the AoN problem..."). And the em dash again seems more | > | > appropriate than semicolon for the same reasons mentioned above- dramatic | > | > emphasis. | > | > | > | > 5) Sect 6.2 | > | > | > | > Old: | > | > such as mLDP, Global Table Multicast (GTM) [RFC7716] and BGP-based | > | > Multicast [BGP-MULTICAST], or even BGP Multicast VPN | > | > | > | > New: | > | > such as mLDP, Global Table Multicast (GTM) [RFC7716], BGP-based Multicast | > | > [BGP-MULTICAST], or even BGP Multicast VPN | > | > | > | > Explanation- is the "and" before the BGP-Mcast needed? | > | > | > | > 6) Sect 6.2, last sentence: shouldn't "Deprecation" be capitalized bc | > | > it's referring to a specific doc? | > | > | > | > 7) Sect 7, last sentence: | > | > | > | > Old: | > | > can be found in Section 8 | > | > | > | > New: | > | > can be found in Section 9 | > | > | > | > 8) Sect 10, 2nd para: can we add the link to the actual Multicast Menu | > | > (https://urldefense.com/v3/__https://menu.treedn.net__;!!NEt6yMaO-gk!EWtceeKI4JKaRAa7FhFKA1M3uh7Voj19BN3s6aQgYSU8C_7rulw4qBpJsxe1C7BV_iouSQGB5yY$ ) somewhere in here? Perhaps something like: | > | > | > | > The Multicast Menu (https://urldefense.com/v3/__https://menu.treedn.net__;!!NEt6yMaO-gk!EWtceeKI4JKaRAa7FhFKA1M3uh7Voj19BN3s6aQgYSU8C_7rulw4qBpJsxe1C7BV_iouSQGB5yY$ ) is a web-based portal... | > | > | > | > or maybe add the URL in the refs section (and then rename the second ref): | > | > | > | > The Multicast Menu [Multicast-Menu] is a web-based portal that lists and can launch | > | > active multicast streams that are available on a global TreeDN | > | > network of various research and educations networks. Details of the | > | > this TreeDN network, as well as the Multicast Menu, are described in | > | > [Offnet-Sourcing-With-Multicast-Menu]. | > | > | > | > where [Multicast-Menu] points to https://urldefense.com/v3/__https://menu.treedn.net__;!!NEt6yMaO-gk!EWtceeKI4JKaRAa7FhFKA1M3uh7Voj19BN3s6aQgYSU8C_7rulw4qBpJsxe1C7BV_iouSQGB5yY$ in the ref and | > | > [Offnet-Sourcing-With-Multicast-Menu] points to | > | > https://urldefense.com/v3/__https://datatracker.ietf.org/meeting/114/materials/slides-114-mboned-offnet-sourcing-with-the-multicast-menu-01__;!!NEt6yMaO-gk!EWtceeKI4JKaRAa7FhFKA1M3uh7Voj19BN3s6aQgYSU8C_7rulw4qBpJsxe1C7BV_iouXgTkrTE$ | > | > | > | > Thanks, | > | > Lenny | > | > | > | > On Mon, 23 Dec 2024, Karen Moore wrote: | > | > | > | > | | > | > | | > | > | Dear Leonard, | > | > | | > | > | Thank you for your reply. We have updated our files accordingly. Please review and let us know if any further changes are needed. Note that we made an additional update. | > | > | | > | > | 1) For the reference entry for "[BIER-AMT-Deployment]” (Section 14.2), we updated the title as shown below because it did not match the title of the presentation at <https://urldefense.com/v3/__https://datatracker.ietf.org/meeting/112/materials/slides-112-mboned-bier-amt-depolyment-in-geantrare-network-00__;!!NEt6yMaO-gk!HM_dVJ8rwtcBrGlzI2KXnwMILArZITJ4CQL0iq-DcpV5UyerQFtmmUAG5AtYK_TCxa-2qPtKFoI$ >. | > | > | | > | > | Old: | > | > | BIER + AMT Deployment in GEANT/RARE Network | > | > | | > | > | New: | > | > | BIER & AMT implementation | > | > | | > | > | | > | > | -- FILES -- | > | > | | > | > | The updated XML file is here: | > | > | https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9706.xml__;!!NEt6yMaO-gk!HM_dVJ8rwtcBrGlzI2KXnwMILArZITJ4CQL0iq-DcpV5UyerQFtmmUAG5AtYK_TCxa-2007c1QE$ | > | > | | > | > | The updated output files are here: | > | > | https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9706.txt__;!!NEt6yMaO-gk!HM_dVJ8rwtcBrGlzI2KXnwMILArZITJ4CQL0iq-DcpV5UyerQFtmmUAG5AtYK_TCxa-2f0tFVOE$ | > | > | https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9706.pdf__;!!NEt6yMaO-gk!HM_dVJ8rwtcBrGlzI2KXnwMILArZITJ4CQL0iq-DcpV5UyerQFtmmUAG5AtYK_TCxa-2vvEiC7c$ | > | > | https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9706.html__;!!NEt6yMaO-gk!HM_dVJ8rwtcBrGlzI2KXnwMILArZITJ4CQL0iq-DcpV5UyerQFtmmUAG5AtYK_TCxa-2Iulue_s$ | > | > | | > | > | This diff file shows all changes made during AUTH48: | > | > | https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9706-auth48diff.html__;!!NEt6yMaO-gk!HM_dVJ8rwtcBrGlzI2KXnwMILArZITJ4CQL0iq-DcpV5UyerQFtmmUAG5AtYK_TCxa-2mYmGjXE$ | > | > | | > | > | This diff file shows all changes made to date: | > | > | https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9706-diff.html__;!!NEt6yMaO-gk!HM_dVJ8rwtcBrGlzI2KXnwMILArZITJ4CQL0iq-DcpV5UyerQFtmmUAG5AtYK_TCxa-25nRkvl4$ | > | > | | > | > | Note that it may be necessary for you to refresh your browser to view the most recent version. Please review the document carefully to ensure satisfaction as we do not make changes once it has been published as an RFC. | > | > | | > | > | Please contact us with any further updates or with your approval of the document in its current form. We will await approvals from each author prior to moving forward in the publication process. | > | > | | > | > | For the AUTH48 status of this document, please see: | > | > | https://urldefense.com/v3/__https://www.rfc-editor.org/auth48/rfc9706__;!!NEt6yMaO-gk!HM_dVJ8rwtcBrGlzI2KXnwMILArZITJ4CQL0iq-DcpV5UyerQFtmmUAG5AtYK_TCxa-28Eusw0c$ | > | > | | > | > | Thank you, | > | > | RFC Editor/kc | > | > | | > | > | > On Dec 20, 2024, at 3:22 PM, Leonard Giuliano <lenny=40juniper....@dmarc.ietf.org> wrote: | > | > | > | > | > | > | > | > | > Thanks for the careful review. See responses inline: | > | > | > | > | > | > On Wed, 18 Dec 2024, rfc-edi...@rfc-editor.org wrote: | > | > | > | > | > | > | | > | > | > | Authors, | > | > | > | | > | > | > | While reviewing this document during AUTH48, please resolve (as necessary) the following questions, which are also in the XML file. | > | > | > | | > | > | > | 1) <!-- [rfced] Please review the following questions regarding this document's title: | > | > | > | | > | > | > | a.) Per Section 3.6 of RFC 7322 ("RFC Style Guide"), abbreviations should be | > | > | > | expanded in document titles and upon first use in the document. How would you | > | > | > | like to expand "CDN" in the title and running text? | > | > | > | | > | > | > | b.) In addition, we note "TreeDN" is not expanded in the document. Is TreeDN | > | > | > | meant to be an abbreviation or just a general term? Please let us know how | > | > | > | to update the document's title to better reflect your intent. | > | > | > | | > | > | > | Original: | > | > | > | | > | > | > | TreeDN- Tree-based CDNs for Live Streaming to Mass Audiences | > | > | > | | > | > | > | Perhaps 1 (describes TreeDN as a term): | > | > | > | | > | > | > | TreeDN: Tree-Based Content Delivery Network (CDN) for Live | > | > | > | Streaming to Mass Audiences | > | > | > | | > | > | > | or | > | > | > | | > | > | > | Perhaps 2 (TreeDN appears to be an abbreviation): | > | > | > | | > | > | > | Tree-Based Content Delivery Network (TreeDN) for Live Streaming | > | > | > | to Mass Audiences | > | > | > | --> | > | > | > | > | > | > TreeDN is not an abbreviation, but more of a general term. As such, I | > | > | > think your first suggestion is the best option: | > | > | > | > | > | > "TreeDN: Tree-Based Content Delivery Network (CDN) for Live Streaming to | > | > | > Mass Audiences" | > | > | > | > | > | > | > | > | > | | > | > | > | | > | > | > | 2) <!-- [rfced] The RFC Style Guide | > | > | > | (https://urldefense.com/v3/__https://www.rfc-editor.org/rfc/rfc7322.html*section-4__;Iw!!NEt6yMaO-gk!FuYy0eG6mdL9XjYvhXVc3f0t7b2z0lxME49sDQRZ5uvtWm5xc7yZbdr0g9Ct85opuoXhIhGjuFYIh-s4IeRmgMk$ ) states that RFCs | > | > | > | must have an Introduction. We have added an Introduction and copied in | > | > | > | text from the Abstract; please review and let us know if any changes or | > | > | > | updates should be made. --> | > | > | > | > | > | > OK | > | > | > | > | > | > | | > | > | > | | > | > | > | 3) <!-- [rfced] We note that MUST and SHOULD are capitalized in Sections 7.1 and | > | > | > | 7.2. These appear to be the requirement key words defined in RFC 2119, so | > | > | > | we have added the paragraph describing their usage and cited RFCs 2119 | > | > | > | and 8174 as normative references. If that was not your intention, please let | > | > | > | us know any objections. --> | > | > | > | > | > | > No objection | > | > | > | > | > | > | | > | > | > | | > | > | > | 4) <!-- [rfced] FYI - For readability, we have updated the text below as | > | > | > | follows. Please review and let us know any objections. | > | > | > | | > | > | > | Original: | > | > | > | | > | > | > | To achieve ubiquitous availability on the global Internet, this | > | > | > | essentially means nearly every interface on every router and firewall | > | > | > | between all end hosts must support a multicast routing protocol like | > | > | > | Protocol Independent Multicast - Sparse Mode (PIM- SM) [RFC7761] or | > | > | > | Multipoint Label Distribution Protocol (mLDP) [RFC6388]. | > | > | > | | > | > | > | Current: | > | > | > | | > | > | > | To achieve ubiquitous availability on the global Internet, this | > | > | > | essentially means that nearly every interface on every router and | > | > | > | firewall between all end hosts must support a multicast routing protocol | > | > | > | (such as Protocol Independent Multicast - Sparse Mode (PIM- SM) [RFC7761] | > | > | > | or the Multipoint Label Distribution Protocol (mLDP) [RFC6388]). | > | > | > | --> | > | > | > | > | > | > Much better, thanks! | > | > | > | > | > | > | | > | > | > | | > | > | > | 5) <!-- [rfced] Please review the following questions regarding the text below. | > | > | > | | > | > | > | a.) Although the term "SR P2MP" does appear in RFC 9524, RFC 9524 | > | > | > | cites the Internet-Draft "draft-ietf-pim-sr-p2mp-policy-10" | > | > | > | [P2MP-POLICY] as the source of this term. Should the citation to | > | > | > | "[RFC9524]" be updated to "[P2MP-POLICY]" instead? | > | > | > | > | > | > No, RFC9524 is the more relevant reference. | > | > | > | > | > | > | | > | > | > | b.) Per Section 3.6 of RFC 7322 ("RFC Style Guide"), abbreviations should be | > | > | > | expanded upon first use. How would you like to expand "VRF" below? Note that | > | > | > | RFC 9300 uses "Virtual Routing and Forwarding (VRF)". | > | > | > | > | > | > "Virtual Routing and Forwarding (VRF)" is correct. | > | > | > | > | > | > | | > | > | > | Original: | > | > | > | | > | > | > | However, any multicast routing protocol | > | > | > | capable of supporting SSM can be used as a TreeDN native on-net, such | > | > | > | as mLDP, Global Table Multicast (GTM) [RFC7716] and BGP-based | > | > | > | Multicast [I-D.ietf-bess-bgp-multicast], or even BGP-MVPN [RFC6513] | > | > | > | for those operators who carry the global routing table in a VRF. | > | > | > | Likewise, any data plane technology that supports SSM, including BIER | > | > | > | [RFC8279] and SR-P2MP [I-D.ietf-spring-sr-replication-segment] can | > | > | > | be used. | > | > | > | | > | > | > | Perhaps: | > | > | > | | > | > | > | However, any multicast routing protocol | > | > | > | capable of supporting SSM can be used as a TreeDN native on-net, such | > | > | > | as mLDP, Global Table Multicast (GTM) [RFC7716] and BGP-based | > | > | > | Multicast [BGP-MULTICAST], or even BGP Multicast VPN (BGP-MVPN) | > | > | > | [RFC6513] for those operators who carry the global Virtual Routing | > | > | > | and Forwarding (VRF) table. Likewise, any data plane technology that | > | > | > | supports SSM, including Bit Index Explicit Replication (BIER) [RFC8279] | > | > | > | and Segment Routing (SR) Point-to-Multipoint (P2MP) [P2MP-POLICY], can | > | > | > | be used. | > | > | > | --> | > | > | > | > | > | > "Global routing table" should remain in there, but you can expand VRF. | > | > | > Also, just noticed the word "component" was missing in the first sentence. | > | > | > So this section should read: | > | > | > | > | > | > Networks that support multicast provide the native on-net component | > | > | > of TreeDN. The primary requirement of the native on-net component is to | > | > | > support Source-Specific Multicast (SSM) [RFC4607]. PIM-SSM, which is | > | > | > merely a subset of PIM-SM, is the multicast routing protocol | > | > | > typically used in SSM. However, any multicast routing protocol | > | > | > capable of supporting SSM can be used in the TreeDN native on-net component, such | > | > | > as mLDP, Global Table Multicast (GTM) [RFC7716] and BGP-based | > | > | > Multicast [BGP-MULTICAST], or even BGP Multicast VPN (BGP-MVPN) | > | > | > [RFC6513] for those operators who carry the global routing table in a Virtual Routing | > | > | > and Forwarding (VRF) table. Likewise, any data plane technology that | > | > | > supports SSM, including Bit Index Explicit Replication (BIER) [RFC8279] | > | > | > and Segment Routing (SR) Point-to-Multipoint (P2MP) [RFC9524], can | > | > | > be used. | > | > | > | > | > | > | | > | > | > | | > | > | > | 6) <!-- [rfced] For clarity, may we update the text below as follows? | > | > | > | | > | > | > | Original: | > | > | > | | > | > | > | In many cases, these issues are more related to TCP-UDP differences than | > | > | > | unicast- multicast differences, thus UDP-based solutions can be leveraged | > | > | > | to address most gaps. | > | > | > | | > | > | > | Perhaps: | > | > | > | | > | > | > | In many cases, these issues are more related to differences between TCP and | > | > | > | UDP than differences between unicast and multicast; thus, UDP-based | > | > | > | solutions can be leveraged to address most gaps. | > | > | > | --> | > | > | > | > | > | > Yes, this sounds much better, thx. | > | > | > | > | > | > | | > | > | > | | > | > | > | 7) <!-- [rfced] May we update the text below as follows for ease of the reader? | > | > | > | | > | > | > | Original: | > | > | > | | > | > | > | Since SSM inherently implies unidirectional traffic flows from one to | > | > | > | many, mechanisms that rely on bidirectional communication between | > | > | > | receivers and the content provider, such as bespoke advertising, | > | > | > | telemetry data from receivers detailing end user experience, | > | > | > | distribution of decryption keys, switching to higher/lower bandwidth | > | > | > | streams, etc, are not well suited to SSM delivery. | > | > | > | | > | > | > | Perhaps: | > | > | > | | > | > | > | Since SSM inherently implies that unidirectional traffic flows from one to | > | > | > | many, mechanisms that rely on bidirectional communication between | > | > | > | receivers and the content provider (such as bespoke advertising, | > | > | > | telemetry data from receivers detailing end-user experience, | > | > | > | distribution of decryption keys, switching to higher or lower bandwidth | > | > | > | streams, etc.) are not well suited to SSM delivery. | > | > | > | --> | > | > | > | > | > | > Much better, thx. | > | > | > | > | > | > | | > | > | > | | > | > | > | 8) <!-- [rfced] FYI - We have updated the text below to avoid the duplicate | > | > | > | appearance of these terms. Please review and let us know any objections. | > | > | > | | > | > | > | Original: | > | > | > | | > | > | > | DVB MABR [DVB-MABR] and MAUD [MAUD] extensively | > | > | > | describe an architecture that enables reliability and dynamic bitrate | > | > | > | adaptation. | > | > | > | | > | > | > | DVB MABR [DVB-MABR] and | > | > | > | MAUD [MAUD] extensively describe an architecture that includes | > | > | > | encryption of multicast streams. | > | > | > | | > | > | > | Current: | > | > | > | | > | > | > | [DVB-MABR] and [MAUD] extensively describe an | > | > | > | architecture that enables reliability and dynamic bitrate adaptation. | > | > | > | | > | > | > | [DVB-MABR] and [MAUD] extensively describe an architecture that | > | > | > | includes encryption of multicast streams. | > | > | > | --> | > | > | > | > | > | > No objections. | > | > | > | > | > | > | | > | > | > | | > | > | > | 9) <!-- [rfced] For clarity, may we add a noun to the text in parentheses below? | > | > | > | | > | > | > | Original: | > | > | > | | > | > | > | That is, even if unauthorized end hosts (eg, non- | > | > | > | paying) receive the datastream, without decryption keys, the data is | > | > | > | useless. | > | > | > | | > | > | > | Perhaps: | > | > | > | | > | > | > | That is, even if unauthorized end hosts (e.g., non-paying end hosts) | > | > | > | receive the data stream, without decryption keys, the data is useless. | > | > | > | --> | > | > | > | > | > | > OK, no objections | > | > | > | > | > | > | | > | > | > | | > | > | > | 10) <!-- [rfced] May we update the text below for clarity? Please let us | > | > | > | know if it changes the sentence's intended meaning. | > | > | > | | > | > | > | Original: | > | > | > | | > | > | > | That is, the BGP peer advertising the | > | > | > | reachability of the source's subnet can do so in ways that can prefer | > | > | > | a particular path through the network for multicast distribution that | > | > | > | are not as easy to accomplish with traditional, destination-based | > | > | > | unicast routing. | > | > | > | | > | > | > | Perhaps: | > | > | > | | > | > | > | That is, the BGP peer advertising the | > | > | > | reachability of the source's subnet can do so in ways where | > | > | > | a particular path through the network is preferred for | > | > | > | multicast distribution; these methods are not as easy to | > | > | > | accomplish with traditional, destination-based unicast | > | > | > | routing. | > | > | > | --> | > | > | > | > | > | > Great suggestion, thanks! | > | > | > | > | > | > | | > | > | > | | > | > | > | 11) <!-- [rfced] Please review the use of the "/" character to separate terms | > | > | > | throughout this document and let us know if it may be updated for | > | > | > | clarity. In some cases, it may be unclear to the reader whether the "/" | > | > | > | stands for "and", "or", or "and/or". | > | > | > | | > | > | > | Originals: | > | > | > | | > | > | > | As Internet audience sizes for high-interest live events reach | > | > | > | unprecedented levels and bitrates climb to support 4K/8K/Augmented | > | > | > | Reality (AR)... | > | > | > | | > | > | > | ...(LISP) [RFC9300] can be utilized to deliver | > | > | > | content from multicast-enabled networks to end hosts that are | > | > | > | separated by portions of the network (at the last/middle/first mile) | > | > | > | that do not support multicast. | > | > | > | | > | > | > | Decentralization/Democratization of Content Sourcing | > | > | > | | > | > | > | That is, multicast routers maintain a forwarding cache of multicast flows | > | > | > | that usually includes the source address, group address, incoming/outgoing | > | > | > | interfaces and forwarding rate. | > | > | > | | > | > | > | Additionally, since multicast leverages reverse-path forwarding | > | > | > | (RPF), the source of the content can potentially have a greater | > | > | > | influence over the path taken through the network from source to | > | > | > | native receivers/AMT relays. | > | > | > | | > | > | > | In particular, Section 6 of [RFC7450] candidly notes that AMT, like UDP, | > | > | > | IGMP and MLD, provides no mechanisms for ensuring message delivery or | > | > | > | integrity, nor does it provide confidentiality, since sources/groups joined | > | > | > | through IGMP/MLD could be associated with the particular content being | > | > | > | requested. | > | > | > | --> | > | > | > | > | > | > Hmm, the / does mean "and", "or" and "and/or" in different places. But I | > | > | > would think these differences are clear to the reader. TBH, I find the / | > | > | > to be easier to read than the extra "and" "or". | > | > | > | > | > | > | | > | > | > | | > | > | > | 12) <!-- [rfced] Abbreviations | > | > | > | | > | > | > | a) FYI - We have added expansions for abbreviations upon first use | > | > | > | per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each | > | > | > | expansion in the document carefully to ensure correctness. | > | > | > | | > | > | > | BGP Multicast VPN (BGP-MVPN) | > | > | > | Bit Index Explicit Replication (BIER) | > | > | > | European Organisation for the Exploitation of | > | > | > | Meteorological Satellites (EUMETSAT) | > | > | > | Internet Key Exchange Protocol Version 2 (IKEv2) | > | > | > | Point-to-Multipoint (P2MP) | > | > | > | Segment Routing (SR) | > | > | > | --> | > | > | > | > | > | > Looks good | > | > | > | > | > | > | | > | > | > | | > | > | > | 13) <!-- [rfced] Please review the "Inclusive Language" portion of the online | > | > | > | Style Guide <https://urldefense.com/v3/__https://www.rfc-editor.org/styleguide/part2/*inclusive_language__;Iw!!NEt6yMaO-gk!FuYy0eG6mdL9XjYvhXVc3f0t7b2z0lxME49sDQRZ5uvtWm5xc7yZbdr0g9Ct85opuoXhIhGjuFYIh-s4PBJflAg$ > | > | > | > | and let us know if any changes are needed. Updates of this nature typically | > | > | > | result in more precise language, which is helpful for readers. | > | > | > | | > | > | > | a.) For example, please consider whether various instances of "native" and | > | > | > | "natively" should be updated throughout this document. | > | > | > | | > | > | > | b.) In addition, please consider whether "traditional" should be updated for | > | > | > | clarity. While the NIST website <https://urldefense.com/v3/__https://www.nist.gov/nist-research-library/__;!!NEt6yMaO-gk!FuYy0eG6mdL9XjYvhXVc3f0t7b2z0lxME49sDQRZ5uvtWm5xc7yZbdr0g9Ct85opuoXhIhGjuFYIh-s43PapqNM$ | > | > | > | nist-technical-series-publications-author-instructions#table1> indicates | > | > | > | that this term is potentially biased, it is also ambiguous. "Tradition" | > | > | > | is a subjective term, as it is not the same for everyone. | > | > | > | --> | > | > | > | > | > | > "Native" is a well-understood term of art for multicast forwarding with | > | > | > precise meaning. I also think "traditional" is the most appropriate term | > | > | > here. I don't think either could be found non-inclusive given the context | > | > | > used in the doc. | > | > | > | > | > | > | | > | > | > | | > | > | > | Thank you. | > | > | > | | > | > | > | RFC Editor/kf/kc | > | > | > | | > | > | > | | > | > | > | On Dec 18, 2024, at 6:30 PM, rfc-edi...@rfc-editor.org wrote: | > | > | > | | > | > | > | *****IMPORTANT***** | > | > | > | | > | > | > | Updated 2024/12/18 | > | > | > | | > | > | > | RFC Author(s): | > | > | > | -------------- | > | > | > | | > | > | > | Instructions for Completing AUTH48 | > | > | > | | > | > | > | Your document has now entered AUTH48. Once it has been reviewed and | > | > | > | approved by you and all coauthors, it will be published as an RFC. | > | > | > | If an author is no longer available, there are several remedies | > | > | > | available as listed in the FAQ (https://urldefense.com/v3/__https://www.rfc-editor.org/faq/__;!!NEt6yMaO-gk!FuYy0eG6mdL9XjYvhXVc3f0t7b2z0lxME49sDQRZ5uvtWm5xc7yZbdr0g9Ct85opuoXhIhGjuFYIh-s4AQJ1zIk$ ). | > | > | > | | > | > | > | You and you coauthors are responsible for engaging other parties | > | > | > | (e.g., Contributors or Working Group) as necessary before providing | > | > | > | your approval. | > | > | > | | > | > | > | Planning your review | > | > | > | --------------------- | > | > | > | | > | > | > | Please review the following aspects of your document: | > | > | > | | > | > | > | * RFC Editor questions | > | > | > | | > | > | > | Please review and resolve any questions raised by the RFC Editor | > | > | > | that have been included in the XML file as comments marked as | > | > | > | follows: | > | > | > | | > | > | > | <!-- [rfced] ... --> | > | > | > | | > | > | > | These questions will also be sent in a subsequent email. | > | > | > | | > | > | > | * Changes submitted by coauthors | > | > | > | | > | > | > | Please ensure that you review any changes submitted by your | > | > | > | coauthors. We assume that if you do not speak up that you | > | > | > | agree to changes submitted by your coauthors. | > | > | > | | > | > | > | * Content | > | > | > | | > | > | > | Please review the full content of the document, as this cannot | > | > | > | change once the RFC is published. Please pay particular attention to: | > | > | > | - IANA considerations updates (if applicable) | > | > | > | - contact information | > | > | > | - references | > | > | > | | > | > | > | * Copyright notices and legends | > | > | > | | > | > | > | Please review the copyright notice and legends as defined in | > | > | > | RFC 5378 and the Trust Legal Provisions | > | > | > | (TLP – https://urldefense.com/v3/__https://trustee.ietf.org/license-info__;!!NEt6yMaO-gk!FuYy0eG6mdL9XjYvhXVc3f0t7b2z0lxME49sDQRZ5uvtWm5xc7yZbdr0g9Ct85opuoXhIhGjuFYIh-s4uKDvD5w$ ). | > | > | > | | > | > | > | * Semantic markup | > | > | > | | > | > | > | Please review the markup in the XML file to ensure that elements of | > | > | > | content are correctly tagged. For example, ensure that <sourcecode> | > | > | > | and <artwork> are set correctly. See details at | > | > | > | <https://urldefense.com/v3/__https://authors.ietf.org/rfcxml-vocabulary__;!!NEt6yMaO-gk!FuYy0eG6mdL9XjYvhXVc3f0t7b2z0lxME49sDQRZ5uvtWm5xc7yZbdr0g9Ct85opuoXhIhGjuFYIh-s4nX6M8ZE$ >. | > | > | > | | > | > | > | * Formatted output | > | > | > | | > | > | > | Please review the PDF, HTML, and TXT files to ensure that the | > | > | > | formatted output, as generated from the markup in the XML file, is | > | > | > | reasonable. Please note that the TXT will have formatting | > | > | > | limitations compared to the PDF and HTML. | > | > | > | | > | > | > | | > | > | > | Submitting changes | > | > | > | ------------------ | > | > | > | | > | > | > | To submit changes, please reply to this email using ‘REPLY ALL’ as all | > | > | > | the parties CCed on this message need to see your changes. The parties | > | > | > | include: | > | > | > | | > | > | > | * your coauthors | > | > | > | | > | > | > | * rfc-edi...@rfc-editor.org (the RPC team) | > | > | > | | > | > | > | * other document participants, depending on the stream (e.g., | > | > | > | IETF Stream participants are your working group chairs, the | > | > | > | responsible ADs, and the document shepherd). | > | > | > | | > | > | > | * auth48archive@rfc-editor.org, which is a new archival mailing list | > | > | > | to preserve AUTH48 conversations; it is not an active discussion | > | > | > | list: | > | > | > | | > | > | > | * More info: | > | > | > | https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc__;!!NEt6yMaO-gk!FuYy0eG6mdL9XjYvhXVc3f0t7b2z0lxME49sDQRZ5uvtWm5xc7yZbdr0g9Ct85opuoXhIhGjuFYIh-s4-ri5sSc$ | > | > | > | | > | > | > | * The archive itself: | > | > | > | https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/browse/auth48archive/__;!!NEt6yMaO-gk!FuYy0eG6mdL9XjYvhXVc3f0t7b2z0lxME49sDQRZ5uvtWm5xc7yZbdr0g9Ct85opuoXhIhGjuFYIh-s4Un1hWRQ$ | > | > | > | | > | > | > | * Note: If only absolutely necessary, you may temporarily opt out | > | > | > | of the archiving of messages (e.g., to discuss a sensitive matter). | > | > | > | If needed, please add a note at the top of the message that you | > | > | > | have dropped the address. When the discussion is concluded, | > | > | > | auth48archive@rfc-editor.org will be re-added to the CC list and | > | > | > | its addition will be noted at the top of the message. | > | > | > | | > | > | > | You may submit your changes in one of two ways: | > | > | > | | > | > | > | An update to the provided XML file | > | > | > | — OR — | > | > | > | An explicit list of changes in this format | > | > | > | | > | > | > | Section # (or indicate Global) | > | > | > | | > | > | > | OLD: | > | > | > | old text | > | > | > | | > | > | > | NEW: | > | > | > | new text | > | > | > | | > | > | > | You do not need to reply with both an updated XML file and an explicit | > | > | > | list of changes, as either form is sufficient. | > | > | > | | > | > | > | We will ask a stream manager to review and approve any changes that seem | > | > | > | beyond editorial in nature, e.g., addition of new text, deletion of text, | > | > | > | and technical changes. Information about stream managers can be found in | > | > | > | the FAQ. Editorial changes do not require approval from a stream manager. | > | > | > | | > | > | > | | > | > | > | Approving for publication | > | > | > | -------------------------- | > | > | > | | > | > | > | To approve your RFC for publication, please reply to this email stating | > | > | > | that you approve this RFC for publication. Please use ‘REPLY ALL’, | > | > | > | as all the parties CCed on this message need to see your approval. | > | > | > | | > | > | > | | > | > | > | Files | > | > | > | ----- | > | > | > | | > | > | > | The files are available here: | > | > | > | https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9706.xml__;!!NEt6yMaO-gk!FuYy0eG6mdL9XjYvhXVc3f0t7b2z0lxME49sDQRZ5uvtWm5xc7yZbdr0g9Ct85opuoXhIhGjuFYIh-s4nLw2eFE$ | > | > | > | https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9706.html__;!!NEt6yMaO-gk!FuYy0eG6mdL9XjYvhXVc3f0t7b2z0lxME49sDQRZ5uvtWm5xc7yZbdr0g9Ct85opuoXhIhGjuFYIh-s4rE817iQ$ | > | > | > | https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9706.pdf__;!!NEt6yMaO-gk!FuYy0eG6mdL9XjYvhXVc3f0t7b2z0lxME49sDQRZ5uvtWm5xc7yZbdr0g9Ct85opuoXhIhGjuFYIh-s4KeivKDI$ | > | > | > | https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9706.txt__;!!NEt6yMaO-gk!FuYy0eG6mdL9XjYvhXVc3f0t7b2z0lxME49sDQRZ5uvtWm5xc7yZbdr0g9Ct85opuoXhIhGjuFYIh-s4yRD_75w$ | > | > | > | | > | > | > | Diff file of the text: | > | > | > | https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9706-diff.html__;!!NEt6yMaO-gk!FuYy0eG6mdL9XjYvhXVc3f0t7b2z0lxME49sDQRZ5uvtWm5xc7yZbdr0g9Ct85opuoXhIhGjuFYIh-s4RlCLhZ8$ | > | > | > | https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9706-rfcdiff.html__;!!NEt6yMaO-gk!FuYy0eG6mdL9XjYvhXVc3f0t7b2z0lxME49sDQRZ5uvtWm5xc7yZbdr0g9Ct85opuoXhIhGjuFYIh-s4h-TpX3o$ (side by side) | > | > | > | | > | > | > | Diff of the XML: | > | > | > | https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9706-xmldiff1.html__;!!NEt6yMaO-gk!FuYy0eG6mdL9XjYvhXVc3f0t7b2z0lxME49sDQRZ5uvtWm5xc7yZbdr0g9Ct85opuoXhIhGjuFYIh-s4RGBvWxw$ | > | > | > | | > | > | > | | > | > | > | Tracking progress | > | > | > | ----------------- | > | > | > | | > | > | > | The details of the AUTH48 status of your document are here: | > | > | > | https://urldefense.com/v3/__https://www.rfc-editor.org/auth48/rfc9706__;!!NEt6yMaO-gk!FuYy0eG6mdL9XjYvhXVc3f0t7b2z0lxME49sDQRZ5uvtWm5xc7yZbdr0g9Ct85opuoXhIhGjuFYIh-s4TqdzGrA$ | > | > | > | | > | > | > | Please let us know if you have any questions. | > | > | > | | > | > | > | Thank you for your cooperation, | > | > | > | | > | > | > | RFC Editor | > | > | > | | > | > | > | -------------------------------------- | > | > | > | RFC9706 (draft-ietf-mops-treedn-07) | > | > | > | | > | > | > | Title : TreeDN- Tree-based CDNs for Live Streaming to Mass Audiences | > | > | > | Author(s) : L. Giuliano, C. Lenart, R. Adam | > | > | > | WG Chair(s) : Leslie Daigle, Kyle Rose | > | > | > | | > | > | > | Area Director(s) : Warren Kumari, Mahesh Jethanandani | > | > | > | | > | > | > | | > | > | > | | > | > | > | | > | > | > | > | > | | > | > | | > | > | > | | > | | > | | | -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
