Re: [Mops] AD review of draft-ietf-mops-treedn-03

["Eric Vyncke (evyncke)" <[e-mail]>]

Thank you, Lenny. The SVG was just a suggestion ;-)

As you may have seen, I have just requested an IETF Last Call, i.e., expect some more reviews.

Best regards

-éric

From: Leonard Giuliano <[e-mail]>
Date: Friday, 19 April 2024 at 23:28
To: Eric Vyncke (evyncke) <[e-mail]>
Cc: MOPS Working Group <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>
Subject: Re: AD review of draft-ietf-mops-treedn-03

Thanks Eric.  Just posted revised I-D with the proposed edits.  Did keep
the ASCII figure in there as it seemed pretty simple and straightforward
and wasn't clear that SVG would improve.  If you feel strongly otherwise,
let us know and we can update.

-Lenny

On Fri, 19 Apr 2024, Eric Vyncke (evyncke) wrote:

|
| Lenny, Chris, and Richard,
|
|
|
| Just to be avoid a stalemate, were you expecting a reply of mine before submitting a revised I-D?
|
|
|
| If so, then sorry about not replying: all the proposed changes were OK for me, i.e., you can proceed with a revised I-D without further wait.
|
|
|
| Regards
|
|
|
| -éric
|
|
|
| From: Leonard Giuliano <[e-mail]>
| Date: Wednesday, 3 April 2024 at 23:43
| To: Eric Vyncke (evyncke) <[e-mail]>
| Cc: MOPS Working Group <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>
| Subject: Re: AD review of draft-ietf-mops-treedn-03
|
|
| Eric- thanks for the detailed review and suggestions.  See comments
| inline:
|
| On Tue, 2 Apr 2024, Eric Vyncke (evyncke) wrote:
|
| |
| | Dear authors, shepherd, and MOPS WG participants,
| |
| |
| |
| | Thanks for the work done on this document.
| |
| |
| |
| | As usual, please find below my AD review for this document. I am
| | requesting either a revised I-D or a reply/explanation for all the
| | points below before proceeding with the publication process (i.e., an
| | IETF-wide Last Call).
| |
| |
| |
| |  *  Abstract: expand AR
|
| Will expand
|
| |
| |  *  Abstract: please explain ?democratizing technology?
| |
|
| How about augmenting the last sentence of the abstract to:
|
| "Finally, TreeDN is a decentralized architecture and a democratizing
| technology in the way that it makes content distribution more accessible
| to more people by dramatically reducing the costs of replication."
|
| |
| |
| |  *  Section 1: a reference to "seven-second delay" would be welcome.
| |
|
| Will add ref to https://en.wikipedia.org/wiki/Broadcast_delay
|
| |
| |
| |  *  Please remove section 1.1 as there is no normative language in this I-D.
| |
|
| Will remove
|
| |
| |
| |  *  Section 3: s/ layer 3 hop/ layer-3 hop/
| |
|
| Will add
|
| |
| |
| |  *  Section 3: ?firewall on the Internet ? unsure whether there are firewalls on the Internet (either delete ?firewall? or specify the location, e.g., ?at the edge?).
| |
|
| Taking an expansive view of the Internet here to include all L3 devices
| between end hosts (sources and receivers).  Distinction between "edge" and
| non-edge doesn't seem as germane here, plus a fw could theoretically sit
| anywhere.  How about the following:
|
| "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
| PIM-SM [RFC7761] or mLDP [RFC6388]."
|
| |
| |  *  Section 4: suggest specifying that the global Internet is used as the underlay.
| |
|
| How about:
|
| "That is, the replication service is available to users and applications
| across the global Internet regardless of what protocols may exist in the
| underlying networks that constitute the underlay."
|
| |
| |  *  Section 4: suggest using https://github.com/martinthomson/aasvg for a nicer SVG graphic.
| |
|
| Hmm, will work on that.
|
| |
| |
| |  *  Section 4: expand AMT already in this section.
| |
|
| Can you elaborate?  AMT is first used in the first sentence of 4.1, and it
| is expanded there.
|
| |
| |
| |  * Section 4.1: ?users on unicast-only networks (AMT Gateways)? is ?(AMT
| | gateways)? at the right location in this sentence or should it be
| | phrased differently ? or s/users/residential gateways/ ? or both ?
|
| AMT Gateways is correct. Probably better to s/ users/ end hosts/
|
| |
| |  *  Section 4.2 should there be a reference to figure 1 when mentioning ?on-net? ?
| |
|
| Well, Figure 1 is meant to provide an overall picture of the architecture
| that is then detailed in 4.1 and 4.2.
|
| |
| |
| |  *  Section 4.2: unsure whether a long digression on ASM vs. SSM fits this I-D. If so, then expand ASM.
| |
|
| Will expand ASM here.
|
| |
| |
| |  *  Section 5 while I like the ?RaaS? concept, the actual term is not really defined in this section.
| |
|
| Well, this entire section (particularly the first para, and more
| specifically the first sentence) is defining what RaaS is.
|
| |
| |
| |  * Section 5: is there any operational drawbacks associated to TreeDN ?
| | E.g., MTU reduction (due to tunnels), ... how to avoid ?leak? of paid
| | content sent over mcast ? A forward reference to section 7 seems
| |     required to me.
|
| Can add the following to Sect 5:
|
| "TreeDN introduces a deployment model that requires new considerations for
| transport layer mechanisms that are frequently relied upon by traditional
| unicast-based CDNs.  A discussion on these considerations and differences
| can be found in section 7."
|
|
| |
| |  *  Section 7.2: CDN also tend to use HTTPS over QUIC (i.e., not over TCP).
| |
|
| Will re-word first sentence of 7.2 to:
|
| "Traditional unicast-based CDNs frequently rely on HTTPS over TCP
| transport and are...."
|
| |
| | Thanks again for the work done.
| |
| |
| |
| | -?ric
| |
| |
| |
| | PS: thanks also for your patience: I took some vacations before and after the IETF week...
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
|
|
|