Hello Hoerdt,
Do bear with me for the delayed reply. Do find my reply to you inline.
Hi Arun,
Thanks for this work, I think it can be very useful for multicast
application writers. Here are my comments :
Section 3:
You say that the current behavior is implementation specific, could you
give some references/samples ? My experience is that the multicast
socket/setsockopt behavior
is quite standard among implementations even is sometime functions
arguments are changing...
I ran some tests on a few implementations. I did see them behaving
differently while receving multicast packets destined to certain
addresses. We had actually formed the idea of a draft specifying the
rules for multicast filtering only after noticing that.
Section 4:
I guess that you want to say "Multicast socket" instead of multicast
client in this section.
Reducing multicast applications to Client and Server with a destination
and source port is quite dangerous here I think. That's of course the
way how current simple multicast applications are working today but
keeping the idea more general, multicast applications may contains
several sockets corresponding to several protocols and joining several
groups.
Also, you use the words host/node/client independantly, I understand
them as "sockets".
Agreed. However, i would prefer to have the word "applications" in the
text, but still add "sockets" to differentiate between the two entities
and putting the forth the point of them being some sort of a interface
handle. Do let me know of your suggestions of how else we can
differentiate between these two entities.
Section 5:
I dont think that I agree with this section, why should every
applications should listens to
some special multicast adresses ? I think my disagreement is a
consequence of the socket/Application/client definition.
RFC1112 talks how the all-host group is a special case and always starts
as an Idle Member and never transitions to another state. I reckon this
would suggest that the address should be ON all the time.
I would be working on including new filtering rules when SSM is present
on the machine. Do let me know if you would require the draft to address
any more issues.
Cheers,
Arun T
Section 6:
The behaviour is what I would expect from a system. Please note that the
information present in this section is redundant with RFC3678.
Cheers,
Hoerdt Mickaël
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
