IGMPv3 for really dumb hosts

The discussion up to this point has been the elimination of the
EXCLUDE filter mode on the router.

Still the sending exchange is rather complicated since only
one type has been eliminated.  TO_EX and IS_EX with a source list.
And the EXCLUDE filter mode still exists on the host.

I would like to propose reconsideration of what an EXCLUDE filter
mode means on the host.

I would also like to consider simplifying the message requirements
for hosts.  The purpose being specification that is very simple to
implement and simple to understand.

If the router no longer supports the EXCLUDE filter mode, there is
no need for hosts to send reports for sources they are not interested
in.  (which is what Hui Liu's draft is all about)

But these hosts must still send IS_IN (with a source-list) and IS_EX
(without a source list) TO_IN, ALLOW, and BLOCK messages.  Saving only
the TO_EX message.

If we consider host filter state to specify only those sources and/or
groups that the host is interested in then the required messages can
be further simplified.  If such a host wants to explicitly filter
certain hosts out of a group, while receiving from all the other hosts
in the group, it is immaterial to the network how this is accomplished.
So for the purposes of this discussion, the host has only an
INCLUDE filter mode.   The host ether listens to the source or it
does not.  So there is no need to advertise to the router IS_EX,
the router doesn't know anything about EXCLUDE filter mode.

If the host uses only ALLOW and BLOCK records to indicate sources it
is interested in, it can still specify (*,G) and (S,G) records to the
router.

The current spec says that an empty ALLOW or BLOCK should not be  
transmitted.
However, if ALLOW() were to mean all sources, it would be equivalent to
an IGMPv2 join.  If BLOCK() meant all sources, it would be equivalent to
an IGMPV2 leave.

ALLOW(A) and BLOCK(A) would still cause the same actions on the router
as specified in the v3 RFC and Liu's draft.

Dumb hosts could respond to router queries with ALLOW reports.

This is the similar to Dino's proposal except that rather than using IS_
record types it uses ALLOW/BLOCK which keeps it compatible with other  
hosts
that might be on the same subnet but have a more complete implementation
of IGMPv3, and it doesn't change the actions that are required by the
router when it receives an IS_ record type.

Additionally, A router that had enabled explicit-host-tracking might  
use some
means other than periodic queries to determine the presence of a host  
and that
host's interest in receiving specific source and/or groups.


If the desired goal is to simplify IGMPv3 why not go "all the way"?