[Mops] TreeDN next steps

[Kyle Rose <[e-mail]>]

We're now a little over a month out from the start of IETF 116, and the
chairs would like WG participants to help us with a little prep work.

Now that we've completed adoption of the TreeDN draft, one next step for
the chairs is to add WG milestones related to the document's development.
Lenny stated that he should have sufficient time to devote to the document
over the course of the year, so we could aim for a fairly aggressive
timeline to WGLC. To that end, it seems like a reasonable approach would be
for interested participants to identify areas where we think the document
could use work and from that try to pin a rough date by which we think the
document would be ready for preliminary expert reviews.

In my initial review, I noted that the document as it stood was very
high-level. For example, the architecture section outlines and briefly
describes a set of technologies leveraged by TreeDN, but no architectural
description of how those pieces fit together to solve particular aspects of
the problem space. A diagram or set of diagrams would be a good start in
helping readers without deep knowledge of the multicast ecosystem form a
mental model of how TreeDN works.

Similarly, the problem statement section lists three challenges for
deployment of applications based on IP multicast, but does not translate
these into specific requirements that motivate the combination of
technology choices listed in the architecture section.

Being the type who prefers the horse in front of the cart, I would aim to
flesh out the requirements first. One traditional way of doing this is to
consider user stories for the problem space, but I'm not sure anything so
formal is really required here: there exists plenty of literature looking
at trend lines on the growth of internet video traffic and extrapolating
those trends to very large numbers (q.v. one of Jake's presentations to
mboned from a few years back). I could also see requirements related to
democratization of content distribution, and probably a bunch of things I
haven't thought of yet.

That having been said, I think good progress could also be made in parallel
in detailing a more formal architectural description. The success criteria
I would propose here is "Could multiple teams working independently create
mutually-interoperating implementations of TreeDN from this document and
normative references?" At this point the document seems a long way from
that.

How does this sound? Once we have agreement on next steps, we can talk
about what granularity of milestones for this draft makes sense for the WG.

Kyle