RE: draft-gundavelli-v6ops-l2-unicast WGLC

"Hemant Singh (shemant)" <shemant@cisco.com> Fri, 13 August 2010 23:52 UTC

Return-Path: <shemant@cisco.com>
X-Original-To: ipv6@core3.amsl.com
Delivered-To: ipv6@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D31803A6957 for <ipv6@core3.amsl.com>; Fri, 13 Aug 2010 16:52:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.387
X-Spam-Level:
X-Spam-Status: No, score=-10.387 tagged_above=-999 required=5 tests=[AWL=0.212, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W7e27WTRWZXJ for <ipv6@core3.amsl.com>; Fri, 13 Aug 2010 16:52:01 -0700 (PDT)
Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id DCBAF3A683C for <ipv6@ietf.org>; Fri, 13 Aug 2010 16:52:00 -0700 (PDT)
Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEADJ4ZUytJV2d/2dsb2JhbACgPnGjUptEhToEhC2IGA
X-IronPort-AV: E=Sophos;i="4.55,366,1278288000"; d="scan'208";a="147590637"
Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rtp-iport-2.cisco.com with ESMTP; 13 Aug 2010 23:52:25 +0000
Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core-6.cisco.com (8.14.3/8.14.3) with ESMTP id o7DNqPmr030090; Fri, 13 Aug 2010 23:52:25 GMT
Received: from xmb-rcd-114.cisco.com ([72.163.62.156]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 13 Aug 2010 18:52:25 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Subject: RE: draft-gundavelli-v6ops-l2-unicast WGLC
Date: Fri, 13 Aug 2010 18:52:23 -0500
Message-ID: <AF742F21C1FCEE4DAB7F4842ABDC511C025D6695@XMB-RCD-114.cisco.com>
In-Reply-To: <AF742F21C1FCEE4DAB7F4842ABDC511C0245DA82@XMB-RCD-114.cisco.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: draft-gundavelli-v6ops-l2-unicast WGLC
Thread-Index: Acsybfq0w7OBP1HeRKOhabbfWPDaNgAYDchQAhxaIuA=
References: <C87C6AF7.B8026%wbeebee@cisco.com><35EC7A29-8C16-4632-84C8-95988F49E92C@cisco.com> <AF742F21C1FCEE4DAB7F4842ABDC511C0245DA82@XMB-RCD-114.cisco.com>
From: "Hemant Singh (shemant)" <shemant@cisco.com>
To: "Hemant Singh (shemant)" <shemant@cisco.com>, "Fred Baker (fred)" <fred@cisco.com>, "Wes Beebee (wbeebee)" <wbeebee@cisco.com>, "Sri Gundavelli (sgundave)" <sgundave@cisco.com>
X-OriginalArrivalTime: 13 Aug 2010 23:52:25.0031 (UTC) FILETIME=[9430FD70:01CB3B42]
Cc: IPv6 Operations <v6ops@ops.ietf.org>, 6man Mailing List <ipv6@ietf.org>, Kurt Erik Lindqvist <kurtis@kurtis.pp.se>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 13 Aug 2010 23:52:01 -0000

I have made my points for pitfalls related to the rules of this
document.  However, since the new rules in this document have a language
of SHOULD NOT drop for receive and MAY for transmit, I don't see any
MUST language in the rules.  The only MUST in the rules section is a
MUST to apply such additional considerations where the actual
considerations have no MUST.  Thus if my hardware chooses to ignore the
receive and transmit rules of this document and comply to RFC 2464, my
hardware does not violate this document.  Therefore, I support this
document.

However, before we forward this document to the IESG, could we please
make some minor changes to text.  One change is suggested below.

OLD TEXT

[An IPv6 receiver node SHOULD NOT drop a received IPv6 multicast message
containing a multicast destination address in the IPv6 header, but with
a unicast destination address in the link-layer header, withstanding all
other validity considerations as specified in the relevant IPv6
standards specifications. ]

NEW TEXT

[An IPv6 receiver node SHOULD NOT drop a received IPv6 multicast message
containing a multicast destination address in the IPv6 header, but with
a unicast destination address in the link-layer header.]

The reason is the use of word "relevant" in old text which appears loose
to me because folks may question, well, which specific IPv6 standards
specifications and the discussion protracts.

I have other minor text changes to propose that I couldn't get to today.
I hope to get to the other suggestions early next week.

Hemant