Comments on draft-ietf-6man-multicast-scopes-02

Jouni Korhonen <jouni.nospam@gmail.com> Mon, 10 February 2014 10:41 UTC

Return-Path: <jouni.nospam@gmail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C42B1A07E9 for <ipv6@ietfa.amsl.com>; Mon, 10 Feb 2014 02:41:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] 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 pxwacZU9gFE3 for <ipv6@ietfa.amsl.com>; Mon, 10 Feb 2014 02:41:21 -0800 (PST)
Received: from mail-lb0-x234.google.com (mail-lb0-x234.google.com [IPv6:2a00:1450:4010:c04::234]) by ietfa.amsl.com (Postfix) with ESMTP id AEA161A07F5 for <ipv6@ietf.org>; Mon, 10 Feb 2014 02:41:20 -0800 (PST)
Received: by mail-lb0-f180.google.com with SMTP id n15so4689969lbi.11 for <ipv6@ietf.org>; Mon, 10 Feb 2014 02:41:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:message-id:date :to:mime-version; bh=iuLtTtflyQapuv60CbX/T6+aoFi6JaLEGEuBxZomv28=; b=wBPI1deml+9erALLxeTA18wRm1kqwrOhd85c9t3wARjUMV4gnIrXDknlRxBACzWkEd a3xaQyre+Q8qWySrf269NLhCLIKZOBcQaV2CIJ+8UgPWo077dmZeIcBzRL56pb6ILMGB loUISoEpWo7suqc/s3CQXYO/bm2CpoF579f6xg0kk1Noa//DcbFOFALcqSuDntx9ET/G IrEDfNK88mmr+Pr1i2IDCwIYsRC0JMtO4a4tuYJZvjHa78ELMWVi3Pa3TgtRJLSy+cI6 frt7wHBm3DOvLu2XweuyVNFHrVc5snQLl6k4Kn5HZLzNn54Lbi/qrMaPnVNxwfqiz8Sz t1Kg==
X-Received: by 10.152.229.225 with SMTP id st1mr21677769lac.2.1392028879821; Mon, 10 Feb 2014 02:41:19 -0800 (PST)
Received: from ?IPv6:2001:1bc8:101:f101:a0bf:a610:ae3e:9851? ([2001:1bc8:101:f101:a0bf:a610:ae3e:9851]) by mx.google.com with ESMTPSA id k1sm15348991lbc.5.2014.02.10.02.41.18 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 10 Feb 2014 02:41:19 -0800 (PST)
From: Jouni Korhonen <jouni.nospam@gmail.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Subject: Comments on draft-ietf-6man-multicast-scopes-02
Message-Id: <DFE48030-8647-4F96-B38E-E5F6E6CA1635@gmail.com>
Date: Mon, 10 Feb 2014 12:41:17 +0200
To: IPv6 IPv6 List <ipv6@ietf.org>, draft-ietf-6man-multicast-scopes@tools.ietf.org
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
X-Mailer: Apple Mail (2.1510)
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Mon, 10 Feb 2014 10:41:24 -0000

Sorry for being late with my comments but here we go anyway.

I think this document is almost ready. Few comments/questions
though.

** In Section 3:

   NEW:

     o  The boundaries of zones of a scope are defined by the IPv6
        addressing architecture [RFC4291].

Ok.. this is confusing since it is *this* I-D that updates RFC4291
with a new Realm-scope aware boundary, thus RFC4291 would eventually
point back to this I-D. So while the above change is correct it
definitely is confusing.

Just like with draft-ietf-6man-multicast-addr-arch-update I see a
need for RFC4291bis, where Section 1 like enhancements would
belong to rather than stacking up I-Ds that patch things here and
there.  Again I recon it might be too late for this, though.

** Section 5

What would go under the other scopes than 3? Shouldn't we say at
least something about the possible future use of those? Will they
also list RFCs? 

** Section 7

I don't think it is sufficient just to refer to RFC4291 (almost non
existent) security considerations. For example there should be a
reference to RFC4007 which actually has text related to security
considerations of boundaries and scopes.

- JOuni