RE: Proposed charter, please comment

["Maciocco, Christian" <christian.maciocco@intel.com>]

Comments below.
Hilarie

> -----Original Message-----
> From: Hilarie Orman [mailto:HORMAN@novell.com]
> Sent: Friday, January 26, 2001 11:07 AM
> To: markday@cisco.com; condry@intel.com; jmartin@netapp.com;
> cdn@ops.ietf.org; premium@pavilion.co.uk
> Subject: RE: Proposed charter, please comment
> 
> 
> 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?
> 

CDI will deal with inter-domain communication, and as we know the 
state of inter-domain multicast support, should we impose this
in the requirements?  


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