RE: Issue 29: AD REVIEW: IPv6 Node Requirements
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Issue 29: AD REVIEW: IPv6 Node Requirements
Thanks Jari, I agree this text is good.
John
> -----Original Message-----
> From: ext Jari Arkko [mailto:jari.arkko@kolumbus.fi]
> Sent: 20 November, 2003 13:56
> To: Loughney John (NRC/Helsinki)
> Cc: brian@innovationslab.net; ipv6@ietf.org
> Subject: Re: Issue 29: AD REVIEW: IPv6 Node Requirements
>
>
> john.loughney@nokia.com wrote:
> > Hi all,
> >
> > The 2nd paragraph in 4.6 looks like:
> >
> > If an application is going to support Source-Specific Multicast,
> > it "SHOULD support MLDv2 but MAY support MLDv1 and conform to the
> > Source-Specific Multicast overview document [RFC3569]; refer to
> > Source-Specific Multicast architecture document for
> details [SSMARCH].
> >
> > I think that is sufficient strength to address Jean-Jacques concern,
> > as SHOULD is quite strong.
>
> Hmm.... I think RFC 3569 says that you can only do SSM with MLDv2,
> not with MLDv1. Also, I wouldn't put an informative document like
> 3569 after a keyword.
>
> We need to put Brian's SHOULD..MAY suggestion into the text, but
> in a slightly different form. Here is one suggested rewrite:
>
> 4.6 Multicast Listener Discovery (MLD)
>
> Nodes that need to join multicast groups SHOULD implement MLDv2
> [MLDv2]. However, if the node has applications which only need
> support for Any-Source Multicast [RFC3569], the node MAY implement
> MLDv1 [MLDv1] instead. If the node has applications which need
> support for Source-Specific Multicast [RFC3569, SSMARCH], the
> node MUST support MLDv2 [MLDv2].
>
> When MLD is used, the rules in "Source Address Selection for the
> Multicast Listener Discovery (MLD) Protocol" [RFC-3590] MUST be
> followed.
>
> --Jari
>
>
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.