RE: Proposed charter, please comment

["Hilarie Orman" <HORMAN@novell.com>]

I'll step on the edge of the multicast rathole.  Suppose there are
a small set of requirements for utilization of multicast transport
(registration, join/leave, send/receive) and a small set of
requirements for the multicast (reliable, scalable to m/n
senders/receivers, mean throughput, mean latency).  Then
the documents could merely reference these in a few
places ("surrogate MUST attempt to join multicast
group if advertised in content description"; "CDN
MUST contain at least one router capable of
supporting the multicast protocol in the peering
agreement").  

I assume that the primary benefit of multicast is
reduced bandwith requirements, and the benefit is
proportional to the amount of data.  One might set
a limit - if the expected amount of data exceeds
M megabytes/month to more than k sites, then
we'd expect a multicast distribution scheme to
be employed?

IF the discussion could be kept a high level, without
imposing any specifics of particular multicast solutions
on the architecture, would that be an acceptable
approach?

Hilarie

>>> "Mark Day" <markday@cisco.com> 01/26/01 11:56AM >>>
> >I agree with Mark that this working group should be focussed, but 'web
> >based' seems too narrow. Shouldn't the aim be to facilitate the
> >interoperation of content networks that use IETF protocols? To
> be specific,
> >I would like CDI to work well with ip-multicast protocols.

> After the WEB documents are released the working group can expand its
> goals with a re-charter.
>
> I support Mark's position  here.

Hmm.  Both people agree with me but disagree with each other. Seems like a
problem. ;-)

I think I'm inclined to agree that we need to develop systems that are
compatible with multicast. Given the kinds of systems and content that
people are interested in, it would seem that there are places where people
will clearly want to have multicast as a component of the solution.

However, I'm a little nervous about the possibility of taking the group down
some sort of multicast-architecting rathole, in which we develop
multicast-enabled versions of every component (including, say, multicasting
accounting information?)

Do we have any good way to characterize what we want to do with multicast?

If not, is an answer to this question part of what we need the requirements
to answer?  If so, we should just note that and not try to resolve the issue
in the charter.

--Mark