Hi Lenny, We have noted your approval on the AUTH48 status page for this document (https://www.rfc-editor.org/auth48/rfc9706).
We now await approvals from Chris and Rich prior to starting the publication process. Best regards, RFC Editor/kc > On Jan 3, 2025, at 9:10 AM, Leonard Giuliano <le...@juniper.net> wrote: > > 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
