The draft describes TreeDN, a scheme for using AMT (automatic multicast tunnelling) to overcome issues with IP multicast. Overall, the ideas appear sound enough, esp. for an informational/overivew document, but I did see a few issues that probably ought be fixed before publication. (They should be easily fixed though.)

- The security considerations section needs to refer to the security considerations of RFC7450 (AMT) and also really ought include some analysis of how esp. the potential DoS issues described there might (or do not) affect uses such as broadcasting large-scale sports events.

- I only had a quick look I had at RFC7450 but if the anycast IP of the AMT relay tends to identify the kind of content (whether a specific event, or some kind of "TV channel" equivalent), then TreeDN may have a privacy issue that perhaps wouldn't have been as much appreciated when RFC7450 was being developed. (And certainly wasn't when the -00 that became RFC7450 was started:-) In other contexts we're starting to be much more sensitive to such issues and those also deserve consideration here, e.g. adding some text to the effect that if the AMT gateway is associated with a mobile-device/home/person, then the privacy issue exists (that a n/w observer can know e.g. the time, the g/w and relay IPs and base inferences on those) and maybe something like MASQUE would be an appropriate way to improve matters. (I'd not expect a document like this to provide solutions there, but it is important to recognise such issues as early as possible I think.)

- There's a conflict between the kind of sales/marketing text claiming (without references) that TreeDN is super-good, and the arm-waving in section 7.3 that says that there are loads of (unspecified) ways to distribute keys to authorized clients. Given the lack of references to e.g. things deployed following the TreeDN approach and stats as to how much those deployments actually improved things, I guess a way to handle this would be to tone down the sales/marketing text and just say that TreeDN is a neat idea and that deploying it would need some TBD way to distribute keys to authorized receivers. Or else maybe add the references that back up the sales/marketing claims and then point to how some of those deployments did key distribution.(*)

(*) Apologies if this point is made a little bluntly, but my antennae fire when I read lots of text like "the TreeDN architecture is ideal for..." with zero backup via references;-)