APPSDIR review of draft-ietf-mboned-64-multicast-address-format-01
Carsten Bormann <cabo@tzi.org> Sun, 06 May 2012 20:57 UTC
Return-Path: <cabo@tzi.org>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B735A21F84F0; Sun, 6 May 2012 13:57:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.287
X-Spam-Level:
X-Spam-Status: No, score=-106.287 tagged_above=-999 required=5 tests=[AWL=-0.038, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FaWMSzbt2TOr; Sun, 6 May 2012 13:57:51 -0700 (PDT)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 890AA21F84AA; Sun, 6 May 2012 13:57:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id q46KvdU6003700; Sun, 6 May 2012 22:57:39 +0200 (CEST)
Received: from [192.168.217.105] (p548996D9.dip.t-dialin.net [84.137.150.217]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id F1E4B111; Sun, 6 May 2012 22:57:38 +0200 (CEST)
Content-Type: text/plain; charset="iso-8859-1"
Mime-Version: 1.0 (Apple Message framework v1257)
Subject: APPSDIR review of draft-ietf-mboned-64-multicast-address-format-01
From: Carsten Bormann <cabo@tzi.org>
Date: Sun, 06 May 2012 22:57:38 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <92309DC0-A179-4B5B-9D8C-4B55F64A4668@tzi.org>
To: draft-ietf-mboned-64-multicast-address-format.all@tools.ietf.org, "apps-discuss@ietf.org application-layer protocols" <apps-discuss@ietf.org>
X-Mailer: Apple Mail (2.1257)
X-Mailman-Approved-At: Sun, 06 May 2012 14:12:47 -0700
Cc: mboned@ietf.org, 6man@ietf.org, The IESG <iesg@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.12
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: Sun, 06 May 2012 20:57:52 -0000
I have been selected as the Applications Area Directorate reviewer for this draft (for background on appsdir, please see http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate ). Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Grüße, Carsten --------------------------------- Document: draft-ietf-mboned-64-multicast-address-format-01 Title: IPv4-Embedded IPv6 Multicast Address Format Reviewer: Carsten Bormann Review Date: 2012-05-06 IETF Last Call Date: 2012-04-19 ** Summary: This draft is NOT ready for publication as a Proposed Standard and should be revised before publication. The document appears as an attempt to extend the reasoning of RFC 6052 to multicast IPv4 addresses. However, while unicast IPv4 addresses and their IPv6 counterparts are assigned as part of network configuration, multicast addresses are decided upon by applications. The document is very short on information how an application should decide when to make use of the newly defined formats. It is therefore also hard to understand why these formats are needed in the first place. There appears to be a transition model in the minds of the authors that makes this necessary or practical, and this information must be made part of the document for it to be useful. ** Major Issues: To continue the summary: I don't understand which network elements need to be able to determine, by looking at an IP address, that this document is in use. What for? More generally, which entities need to interoperate based on a common understanding of this format? Of the various fields left "configurable according to local policies of the entity managing the IPv4-IPv6 Interconnection Function", which are important for applications? How do they know these policies? If that information is all in the two parameters "ASM_MPREFIX64" and "SSM_MPREFIX64", what is the protocol that will be used to make this information available to applications? I don't think this can be a standards-track document without defining at least one MTI protocol for disseminating this information. What is an implementation supposed to do that receives an address that looks like it is governed by this document but does not conform to either of the agreed prefixes disseminated to the implementation? This document needs editorial attention. I will abstain from trying to make detailed corrections, as this would become tedious quickly. While much of this work could be done by the RFC editor, some of the editorial decisions will enter e.g. IANA registries, so the technical terms need to be decided now. More importantly, understanding this document during its development process (including mine as a reviewer) may be hampered by its editorial shortcomings. ** Minor Issues: My first editorial problem is with the title. This address format is not embedded in IPv4, as the title wants to make us believe. Instead, it is talking about an multicast address format for IPv6 that embeds an IPv4 multicast address. (While this misleading naming repeats the same mistake that has been made in RFC 6052, at least there it is not part of the title.) 3 The role of 64IX is very unclear. My conjecture is that this draft is defining the address format for the case M=1 only (i.e., address[16] = 1). No text defines what happens for M=0, so the assumption appears to be that RFC 4291 applies unchanged in this case. If this conjecture is correct, this needs to be made much clearer. What is "r"? Define. 4 Why is 64IX moving around here? (The discriminating bit M now seems to be address[32].) How does one find out which of the two positions of the M bit to use? . o sub-group-id: The default value is all zeros. How does an application find out when to choose a different one? . 232.0.0.1-232.0.0.255 range is being . reserved to IANA. Who is making this reservation? ("is being reserved" means the resernation is going on right now, but I don't find anything in 9.) 7 7 seems to imply this format is only useful where RFC 6052 is in use. If this is true, this should be clearly stated. More specifically, the assumption appears to be that all nodes that need to exchange information that concerns IPv4 sources need to have the same RFC 6052 parameters in effect. How is that ensured? ** Nits: 10 -- s/defined/defines/ (And many more, see above.)
- APPSDIR review of draft-ietf-mboned-64-multicast-… Carsten Bormann
- RE: APPSDIR review of draft-ietf-mboned-64-multic… mohamed.boucadair
- Re: APPSDIR review of draft-ietf-mboned-64-multic… Carsten Bormann
- Re: [MBONED] APPSDIR review of draft-ietf-mboned-… Tina TSOU
- Re: APPSDIR review of draft-ietf-mboned-64-multic… Lee, Yiu
- Re: [MBONED] APPSDIR review of draft-ietf-mboned-… Jacni Qin
- RE: APPSDIR review of draft-ietf-mboned-64-multic… mohamed.boucadair
- Re: [MBONED] APPSDIR review of draft-ietf-mboned-… Carsten Bormann
- RE: [MBONED] APPSDIR review of draft-ietf-mboned-… mohamed.boucadair
- Re: [MBONED] APPSDIR review of draft-ietf-mboned-… Brian Haberman
- RE: [MBONED] APPSDIR review of draft-ietf-mboned-… Manfredi, Albert E
- RE: [MBONED] APPSDIR review of draft-ietf-mboned-… Tina TSOU
- RE: [MBONED] APPSDIR review of draft-ietf-mboned-… mohamed.boucadair
- Re: [MBONED] APPSDIR review of draft-ietf-mboned-… Lee, Yiu
- Re: [MBONED] APPSDIR review of draft-ietf-mboned-… Stig Venaas
- Re: [MBONED] APPSDIR review of draft-ietf-mboned-… Lee, Yiu
- Re: [MBONED] APPSDIR review of draft-ietf-mboned-… Behcet Sarikaya
- Re: [MBONED] APPSDIR review of draft-ietf-mboned-… Jacni Qin