Re: comments on draft-ietf-6man-multicast-addr-arch-update-02
神明達哉 <jinmei@wide.ad.jp> Tue, 11 February 2014 19:55 UTC
Return-Path: <jinmei.tatuya@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 A90DF1A0722 for <ipv6@ietfa.amsl.com>; Tue, 11 Feb 2014 11:55:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.078
X-Spam-Level:
X-Spam-Status: No, score=-0.078 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, GB_I_LETTER=-2, 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 Ye9c-XSXyo4l for <ipv6@ietfa.amsl.com>; Tue, 11 Feb 2014 11:55:31 -0800 (PST)
Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) by ietfa.amsl.com (Postfix) with ESMTP id D852F1A072F for <ipv6@ietf.org>; Tue, 11 Feb 2014 11:55:30 -0800 (PST)
Received: by mail-wi0-f179.google.com with SMTP id hn9so5204857wib.6 for <ipv6@ietf.org>; Tue, 11 Feb 2014 11:55:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=qnZmLpFmKcjyF3bYLiYjkW0btSok4poUjw0uaOteWPg=; b=MWBJsy8CVwq2F0qJqXuMK7oXPkZOsBmJlaZxXuUrzXMn3lDkaYv5zKhM0H/d7P05Dz Z5kNMhgT/q5C8kMYX979m29NRl/aI3vnmf3gY9MGMKa2GD56p09GVtza7hnXNjySixXa 3O3cvycDWqJqJD/+MCfkCsEo91B/78Y0Z2LA7W58/BJAYlRe07zPdW/lqsMhRlIGa+gP PqT2MnOMRQ93TT3nw33uAD27E6/Z+VoWGxrzlDGt/ERJBId1ZtcACPOKyJLRXH3qVOah /Dn1FbU/Ug+h2INr1K3+2w4O5Lym72jWmxhc2BqfwsvIg92kVyGIdt8KWAtICTN9cORL mmmw==
MIME-Version: 1.0
X-Received: by 10.195.13.17 with SMTP id eu17mr27828806wjd.24.1392148529762; Tue, 11 Feb 2014 11:55:29 -0800 (PST)
Sender: jinmei.tatuya@gmail.com
Received: by 10.194.120.167 with HTTP; Tue, 11 Feb 2014 11:55:29 -0800 (PST)
In-Reply-To: <52F941A5.6040103@venaas.com>
References: <CAJE_bqdUiQznZDUDsQ3d1niuRE=q1YqYp9=mNMm8Bo8QzB6xiQ@mail.gmail.com> <52E0570D.4040403@venaas.com> <52F941A5.6040103@venaas.com>
Date: Tue, 11 Feb 2014 11:55:29 -0800
X-Google-Sender-Auth: BfaNs7p-gfefvncVf21HkDzYWfA
Message-ID: <CAJE_bqfqfF=zkhixYJWVu5DOGjpxjSYNT+21Cotz6oN8KFMf5g@mail.gmail.com>
Subject: Re: comments on draft-ietf-6man-multicast-addr-arch-update-02
From: 神明達哉 <jinmei@wide.ad.jp>
To: Stig Venaas <stig@venaas.com>
Content-Type: text/plain; charset="ISO-8859-1"
Cc: draft-ietf-6man-multicast-addr-arch-update@tools.ietf.org, IPv6 IPv6 List <ipv6@ietf.org>
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: Tue, 11 Feb 2014 19:55:33 -0000
At Mon, 10 Feb 2014 13:16:21 -0800, Stig Venaas <stig@venaas.com> wrote: > >> - Allowing FFF0::/12 to be considered an embedded RP address seems to > >> me a semantics change, not just a clarification (as hinted in the > >> introduction), since RFC 3956 clearly states (and also as cited in > >> the draft itself): [...] > >> So does this mean "such time" has come? I guess there was a > >> background discussion that I didn't follow and led to this change, > >> so I wouldn't oppose to the update per se. But the rationale isn't > >> really clear from the updated text, and I think it should be > >> clarified. > > As part of this update we are trying to treat the flag bits as > individual bits. Hence it should still be embedded-RP if the most > significant flag bit is set. I guess I was not clear/accurate enough. My point is that (at least technically) Section 3.1 is not just a "clarification" as this draft claims in Section 1: [...] The document provides also some clarifications related to the use of these flag bits (Section 3.1). since as a result of this the definition of embedded-RP addresses is changed (extended). Maybe revising the last sentence of Section 1 addresses my concern: This document updates [RFC3956], [RFC3306], and [RFC4291]. Some of the updates are logical consequences of the clarification on the flag bits. > >> - Aside from the previous point, the updated text is generally quite > >> confusing to me: > >> > >> R = 1 indicates a multicast address that embeds the address of > >> the RP. > >> P MUST be set to 1, and consequently T MUST be set to 1, according > >> to [RFC3306], as this is a special case of > >> unicast-prefix based addresses. This implies that for instance > >> prefixes > >> ff70::/12 and fff0::/12 are embedded RP prefixes, but all > >> multicast > >> addresses with the R-bit set to 1 MUST be treated as Embedded RP > >> addresses. The behavior is unspecified if P or T is not set to > >> 1. When the > >> R-bit is set, the last 4 bits of the previously reserved field are > >> interpreted as embedding the RP interface ID, as specified in > >> this memo. > > We can remove the sentence ", but all multicast addresses with the > R-bit set to 1 MUST be treated as Embedded RP addresses." It is a valid > statement, but not really needed. I think that works for me, although it looks a bit awkward that we can simply remove a statement containing a "MUST" while believing it's not a semantics change. > >> - (A very minor point) Also in the NEW format of Section 4.1, why > >> lower-cased letters are now used for the addresses? > >> > >> If the flag bits are set to 0011, these settings create an SSM > >> range of ff3x::/32 (where 'x' is any valid scope value). The > >> > >> The policy isn't consistent either with the original RFC 3306 or > >> with other parts of the draft. > > A lot of the OLD text has FF, but per recommendation in RFC 5952 we > use lower case in all the NEW text. Ah, okay. Maybe it's a distraction, but I'd consider adding a "TERMINOLOGY" section or something, where we clarify the point (i.e., the draft generally follows RFC 5952 to represent IPv6 addresses except in citation of already published documents). But I'd leave it to you. -- JINMEI, Tatuya