Hi Rich, We have noted your approval on the AUTH48 status page (https://www.rfc-editor.org/auth48/rfc9706).
We now have all necessary approvals and will move this document through the publication process. Thank you to all of the authors for your time! Best regards, RFC Editor/kc > On Jan 12, 2025, at 11:49 PM, Rich Adam <richard.a...@geant.org> wrote: > > Morning folks, > > Sorry for the delay. I approve this document for publication. > > Thank you all for your efforts, much appreciated. > > Rich. > > From: Lenart, Christopher <chris.len...@verizon.com> > Date: Monday, 6 January 2025 at 20:45 > To: Karen Moore <kmo...@amsl.com> > Cc: Leonard Giuliano <le...@juniper.net>, Rich Adam <richard.a...@geant.org>, > RFC Editor <rfc-edi...@rfc-editor.org>, mops-...@ietf.org > <mops-...@ietf.org>, mops-cha...@ietf.org <mops-cha...@ietf.org>, > alfic...@gmail.com<alfic...@gmail.com>, Eric Vyncke (evyncke) > <evyn...@cisco.com>, auth48archive <auth48archive@rfc-editor.org> > Subject: Re: [E] Re: AUTH48: RFC-to-be 9706 <draft-ietf-mops-treedn-07> for > your review > > Karen, > > I reviewed the changes and they look good. > > Thanks to all of the suggestions during this step. > > I approve this document for publication. > > Thanks, > > Chris Lenart > > > On Fri, Jan 3, 2025 at 5:48 PM Karen Moore <kmo...@amsl.com> wrote: > Hi Lenny, > > We have noted your approval on the AUTH48 status page for this document > (https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-2Deditor.org_auth48_rfc9706&d=DwIFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=5ZnSC0o7o-NxpjLWKPDyZ5A_hTkyLOIlD_fsRhfBFAU&m=rfaxFUS2aw8-hjuTOTv8seCQABRqP7rrdOqgil6iHxFhkDtDPd3tr8kUXaviWH9I&s=a5kHJylQLHi79KGvaesCs_gUt_fROheNuPubIGPI7N8&e= > ). > > 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
