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
