IDMR met in one session at the Adelaide IETF.  These minutes were
collected by Bill Fenner.

Bill Fenner spoke on IDMR document status.  The DVMRPv3 spec needs
an update for GenID per interface (and perhaps some others), and
DVMRPv3 needs an applicability statement.  The DVMRP MIB is ready
but is blocked on the spec.  Multicast Traceroute had a recent
update (presented later) and was going to be put to WG Last Call
except for a suggestion of an appendix on the heuristics that the
mtrace client currently uses to get good data from buggy sources.
The Multicast Router Discovery spec has expired and needs to be
updated.  IGMPv2 needs to be updated based on Erik Nordmark's MLD
spec comments in order to go to Draft Standard.  IGMPv3 was recently
updated (presented later) and a little more needs to be done.  The
IGMPv3 API spec is brand new and needs comments from the WG.

The Domain Wide Report and IGMP Proxying specs are in "working
group chair limbo" -- they both passed their WG Last Calls but the
chair never submitted them to the IESG.  The PIM, IPMROUTE and IGMP
MIBs are in the IESG black hole; Rob Coltun said something about
MIB compiler flags that I didn't understand but we decided to take
it offline.


Bill Fenner continued on the multicast traceroute document update.
These details are available both in the updated document and in
the slides; please refer to one or the other to find out what's
changed.  The document will be updated again to include known
implementation problems and workarounds in an appendix, and then
be submitted for Working Group Last Call.


Isidor Kouvelas then gave an update on the IGMPv3 spec.  Refer to
the slides for the details of the changes.  The comment was made
that the document says that reserved bits MUST be 0 when receiving;
this precludes certain types of forward compatibility so should be
changed.


Dave Thaler presented the new Multicast Source Filtering API; this
is a concrete API for both group membership and source filtering
in IPv4 (i.e. IGMPv1,v2 and v3) and IPv6 (i.e. MLD and ??).  The
original specification of the advanced API used a setsockopt() to
set the filter, and ioctl() to get the filter.  Dave made the
proposal to change them both to ioctl() for symmetry, and the WG
had no objections.

Dave Thaler then talked about treating IPv6 in the existing multicast
MIBs.  His plan is to submit protocol-independent IPMROUTE and PIM
MIBs; these will be useful for both IPv4 and IPv6.  IGMP and MLD
are similar but not the same protocol, so it doesn't necessarily
make sense to have a single MIB for IGMP (IPv4) and MLD (IPv6).


Hugh Holbrook then talked about IGMP and Source-Specific Multicast.
This is Appendix I of draft-holbrook-ssm-00.txt .  No changes to
host IP stacks are required; a normal IGMPv3 host stack can handle
the requirements of source-specific multicast.  Source-Specific
applications are required to only use the IGMPv3 API to join
source-specific sessions; if a host stack sends a 'join group'
(e.g. IGMPv2 membership or IGMPv3 exclude-none), it will simply be
ignored.

IGMP-speaking routers doing source-specific multicast are configured
with the group range (currently 232/8 but could change in the
future) that is to be used for source-specific sessions.  These
routers only pay attention to IGMPv3 'include'-style requests for
these groups; any request to join the entire group is ignored.

There was some discussion about whether or not it makes sense to
restrict the range in this way; the current IANA assignment says
that behavior is undefined if you join the whole group (e.g. a
router could do Internet Standard Multicast).  The assertion was
made that one of the reasons content providers want Source-Specific
multicast is to prevent reception of other sources, thus Internet
Standard Multicast is unacceptable.  No consensus was reached in
this discussion.