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

[Leonard Giuliano <[e-mail]>]

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...
| 
|  
| 
|  
| 
|  
| 
|  
| 
|  
| 
|  
| 
|  
| 
|  
| 
|  
| 
|  
| 
|  
| 
| 
|