[Gen-art] Gen-ART review of draft-ietf-mboned-auto-multicast-17

Alexey Melnikov <alexey.melnikov@isode.com> Mon, 26 May 2014 09:47 UTC

Return-Path: <alexey.melnikov@isode.com>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EEE11A00B0; Mon, 26 May 2014 02:47:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.651
X-Spam-Level:
X-Spam-Status: No, score=-2.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i-A-HFqIuDBU; Mon, 26 May 2014 02:47:42 -0700 (PDT)
Received: from statler.isode.com (statler.isode.com [62.3.217.254]) by ietfa.amsl.com (Postfix) with ESMTP id D38BE1A00A6; Mon, 26 May 2014 02:47:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1401097658; d=isode.com; s=selector; i=@isode.com; bh=rIO+NT5WFOl+cOuY1vPHvjPc6BLUP523QLBSr/VFUx4=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=H0fQkBo1QXhoTb+mzuplOwA93eYijl/fIqZ0VVLcE4CV0bVpRf8+v9tCm/5plEt1HFWQKU FkwljfgBHGDpMZ6CWSmGIHmFCrA5jHnbGnbi8smxniC3SYDjQB7Nj2/TB+wym3FoeVelEF hYqyrpOMu2HesGOgSFIAzB0TBVvujTA=;
Received: from [192.168.0.4] (cpc5-nmal20-2-0-cust24.19-2.cable.virginm.net [92.234.84.25]) by statler.isode.com (submission channel) via TCP with ESMTPA id <U4MNuQAis6VY@statler.isode.com>; Mon, 26 May 2014 10:47:38 +0100
Message-ID: <53830DC9.7070202@isode.com>
Date: Mon, 26 May 2014 10:47:53 +0100
From: Alexey Melnikov <alexey.melnikov@isode.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.5.0
To: draft-ietf-mboned-auto-multicast.all@tools.ietf.org
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/gen-art/LcbeKNpD17K-0xIkPvlF_1lsp3g
Cc: "General Area Review Team (gen-art@ietf.org)" <gen-art@ietf.org>, The IESG <iesg@ietf.org>
Subject: [Gen-art] Gen-ART review of draft-ietf-mboned-auto-multicast-17
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 26 May 2014 09:47:43 -0000

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at

<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-mboned-auto-multicast-17
Reviewer: Alexey Melnikov
Review Date: May 26, 2014
IETF LC End Date: May 26, 2014

Summary:  Nearly ready for publication as a Proposed Standard.

Major issues:


In the document, I am seeing:

5.1.1.1.  Version (V)

    [And in several other similar sections]

    The protocol version number for this message is 0.

5.2.3.2.  Handling AMT Messages

    A gateway that conforms to this specification MUST ignore any message
    with a Version field value other than zero.

5.3.3.1.  Handling AMT Messages

    A relay that conforms to this specification MUST ignore any message
    with a Version field value other than zero.



This might not actually be an issue, if it was discussed in the WG. But 
I am wondering if the WG thought about versioning, backward 
compatibility and other related issues.
How likely is it that a new version of AMT is going to be designed? At 
the moment the document reads like "we have a stub field for future 
versions, but we haven't thought about how they are going to be handled 
yet".


Minor issues: None

Nits/editorial comments:

5.3.3.4.  Handling a Membership Update Message

   o  The computed checksums for the encapsulated IP datagram and its
       payload MUST match the values contained therein.  Checksum
       computation and verification varies by protocol; See [RFC0791] for
       IPv4, [RFC3376] for IGMPv3, and [RFC4443] for MLD (ICMPv6).

Any recommendation for IPv6 or is it covered by one of the other choices?