Re: Issue 29: AD REVIEW: IPv6 Node Requirements

Brian Haberman <brian@innovationslab.net> Thu, 20 November 2003 12:43 UTC

Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02068 for <ipv6-archive@odin.ietf.org>; Thu, 20 Nov 2003 07:43:07 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMo93-0005sm-C4 for ipv6-archive@odin.ietf.org; Thu, 20 Nov 2003 07:42:49 -0500
Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAKCgnWg022612 for ipv6-archive@odin.ietf.org; Thu, 20 Nov 2003 07:42:49 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMo92-0005sd-Vd for ipv6-web-archive@optimus.ietf.org; Thu, 20 Nov 2003 07:42:49 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02035 for <ipv6-web-archive@ietf.org>; Thu, 20 Nov 2003 07:42:36 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMo92-0002Am-00 for ipv6-web-archive@ietf.org; Thu, 20 Nov 2003 07:42:48 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMo91-0002Aj-00 for ipv6-web-archive@ietf.org; Thu, 20 Nov 2003 07:42:47 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMo8I-0005a7-A2; Thu, 20 Nov 2003 07:42:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMo8D-0005Zo-LV for ipv6@optimus.ietf.org; Thu, 20 Nov 2003 07:41:57 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02008 for <ipv6@ietf.org>; Thu, 20 Nov 2003 07:41:45 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMo8C-00029p-00 for ipv6@ietf.org; Thu, 20 Nov 2003 07:41:57 -0500
Received: from uillean.fuaim.com ([206.197.161.140]) by ietf-mx with esmtp (Exim 4.12) id 1AMo8C-00029m-00 for ipv6@ietf.org; Thu, 20 Nov 2003 07:41:56 -0500
Received: from clairseach.fuaim.com (clairseach.fuaim.com [206.197.161.141]) by uillean.fuaim.com (8.11.6/8.11.6) with ESMTP id hAKCfPV09220; Thu, 20 Nov 2003 04:41:25 -0800
Received: from innovationslab.net (md-wmnsmd-cuda2-c6a-a-4.chvlva.adelphia.net [68.65.120.4]) (authenticated bits=0) by clairseach.fuaim.com (8.12.8/8.12.8) with ESMTP id hAKCjstX025332 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Thu, 20 Nov 2003 04:45:57 -0800
Message-ID: <3FBCB65B.8000704@innovationslab.net>
Date: Thu, 20 Nov 2003 07:40:59 -0500
From: Brian Haberman <brian@innovationslab.net>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Jari Arkko <jari.arkko@kolumbus.fi>
CC: john.loughney@nokia.com, ipv6@ietf.org
Subject: Re: Issue 29: AD REVIEW: IPv6 Node Requirements
References: <DADF50F5EC506B41A0F375ABEB320636A8BA98@esebe023.ntc.nokia.com> <3FBCABEC.7050301@kolumbus.fi>
In-Reply-To: <3FBCABEC.7050301@kolumbus.fi>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: ipv6-admin@ietf.org
Errors-To: ipv6-admin@ietf.org
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Id: IP Version 6 Working Group (ipv6) <ipv6.ietf.org>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

I agree with Jari's proposed text.

Brian

Jari Arkko wrote:

> 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
> --------------------------------------------------------------------


--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------