Re: Simple Multicast - building a case for a BOF or WG

[Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk>]

 >>what is considered evolutionary is still a subjective.  whispers from
 >>others in the ietf hallways tend to feel that simply changing the API 
 >>is grounds for a revolutionary label.

yes, strange given the same change that achieves ipv6 can achieve
sm/express host api....i dont hear too many ip multicast people saying
'oh but we'll never move to ipv6 coz it will break ip multicast host
and application apis and the service model for multicast' :-) :)
 
 >>also given that the service model can be a candidate for change, it would
 >>seem helpful for any newly established WG to put forth an accompanying 
 >>interoperability info rfc that either supplements or replaces the same
 >>draft document put forth by Thaler.

lets be careful about api's, host/network interfacxes, and service
modesl

little of what we are proposing changes the _service_ model as it is
normally defined.


we envisage some part of the IP multicast space to have an enhancement
that constrains who can send or receive, but we dont stop some part
also allowing unconstrained sender/recveiver membership....

igmpv3 ALREADY does some part of this. people who say 'you cant change
ip multicast" were silent during that enhancement...
 
 >>so to go back to your original comment, is there sufficient case to
 >>have a BOF?  if something can't be provided (from either the user's
 >>perspective, or the provider's perspective), and there is a nugget
 >>of an idea (and an accompanying implementation) to address the problem, 
 >>i would think that's enough of a case.  

 >>gentle beings, let your arrows fly :-)
and, like,  time them:-)

 cheers

   jon