RE: [Gen-art] Gen-ART LC Review of draft-ietf-6man-multicast-addr-arch-update-05
<mohamed.boucadair@orange.com> Mon, 07 July 2014 06:40 UTC
Return-Path: <mohamed.boucadair@orange.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D25471A0B0D; Sun, 6 Jul 2014 23:40:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 G4nsMmZEHWyT; Sun, 6 Jul 2014 23:40:23 -0700 (PDT)
Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 854BD1A0AFA; Sun, 6 Jul 2014 23:40:22 -0700 (PDT)
Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id A67F218C21F; Mon, 7 Jul 2014 08:40:20 +0200 (CEST)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.30]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 811F935C058; Mon, 7 Jul 2014 08:40:20 +0200 (CEST)
Received: from OPEXCLILM23.corporate.adroot.infra.ftgroup ([169.254.2.67]) by OPEXCLILH02.corporate.adroot.infra.ftgroup ([10.114.31.30]) with mapi id 14.03.0181.006; Mon, 7 Jul 2014 08:40:20 +0200
From: mohamed.boucadair@orange.com
To: Ben Campbell <ben@nostrum.com>
Subject: RE: [Gen-art] Gen-ART LC Review of draft-ietf-6man-multicast-addr-arch-update-05
Thread-Topic: [Gen-art] Gen-ART LC Review of draft-ietf-6man-multicast-addr-arch-update-05
Thread-Index: AQHPliljVXixK6Twy0KPL9jRmwbmPZuOEcoAgACHSACAANiMcIAEvb1g
Date: Mon, 07 Jul 2014 06:40:19 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B933002DE4F@OPEXCLILM23.corporate.adroot.infra.ftgroup>
References: <C8F7216E-A827-462C-917F-6B766682CA59@nostrum.com> <787AE7BB302AE849A7480A190F8B933002BA2A@OPEXCLILM23.corporate.adroot.infra.ftgroup> <C7A509EE-C5E4-4C0D-8430-3B9C12D02F71@nostrum.com> <787AE7BB302AE849A7480A190F8B933002CD2A@OPEXCLILM23.corporate.adroot.infra.ftgroup>
In-Reply-To: <787AE7BB302AE849A7480A190F8B933002CD2A@OPEXCLILM23.corporate.adroot.infra.ftgroup>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.168.234.3]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.7.7.34519
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf/h3HGZUij1kRYKjasE0DUAhKEOhA
Cc: "draft-ietf-6man-multicast-addr-arch-update.all@tools.ietf.org" <draft-ietf-6man-multicast-addr-arch-update.all@tools.ietf.org>, "gen-art@ietf.org Team (gen-art@ietf.org)" <gen-art@ietf.org>, "ietf@ietf.org list" <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 07 Jul 2014 06:40:26 -0000
Hi Ben, An updated version that takes into account your comments is available online: http://tools.ietf.org/html/draft-ietf-6man-multicast-addr-arch-update-06 A diff can be found here: http://tools.ietf.org/rfcdiff?url2=draft-ietf-6man-multicast-addr-arch-update-06.txt Cheers, Med >-----Message d'origine----- >De : mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com] >Envoyé : vendredi 4 juillet 2014 15:45 >À : Ben Campbell >Cc : draft-ietf-6man-multicast-addr-arch-update.all@tools.ietf.org; gen- >art@ietf.org Team (gen-art@ietf.org); ietf@ietf.org list >Objet : RE: [Gen-art] Gen-ART LC Review of draft-ietf-6man-multicast-addr- >arch-update-05 > >Hi Ben, > >Please see inline. > >Cheers, >Med > >>-----Message d'origine----- >>De : Ben Campbell [mailto:ben@nostrum.com] >>Envoyé : jeudi 3 juillet 2014 21:18 >>À : BOUCADAIR Mohamed IMT/OLN >>Cc : draft-ietf-6man-multicast-addr-arch-update.all@tools.ietf.org; gen- >>art@ietf.org Team (gen-art@ietf.org); ietf@ietf.org list >>Objet : Re: [Gen-art] Gen-ART LC Review of draft-ietf-6man-multicast-addr- >>arch-update-05 >> >>Hi, thanks for the response. I've got some more comments inline, and I >>removed sections that do not seem to need further comment. >> >>On Jul 3, 2014, at 6:20 AM, <mohamed.boucadair@orange.com> >><mohamed.boucadair@orange.com> wrote: >> >>[...] >> >>>> Major issues: None >>>> >>>> Minor issues: >>>> >>>> -- Section 2 >>>> >>>> I'd like to see more motivation for the creation of ff2. The text says >>it >>>> "... allows addresses to be treated in a more uniform and generic way, >>and >>>> allows for these bits to be defined in the future for different >>>> purposes..." >>>> >>>> That seems pretty vague to me. Can you offer specifics on what problem >>is >>>> being solved here, and how you expect this new flags to be used? Most >>>> importantly, are there likely to be interoperability issues for things >>>> implemented prior to the definition of these? >>> >>> [Med] Typical encountered issues are listed in section 3: e.g., some >>implementations do not treat the flag bits as separate bits, this leads in >>particular to not consider prefixes starting with fffx as RP-embedded. >>> >> >>I understood those issues to motivate the clarifications on ff1. But if >>they explain why some of the reserved space is updated to be ff2, then I >>missed it. >> >> >[Med] see below. > > >>> What is the purpose of >>>> redefining them as flags prior to defining the meaning of the flags? >>> >>> [Med] In fact we started by associating a meaning with an unreserved bit >>(http://tools.ietf.org/html/draft-ietf-mboned-64-multicast-address-format- >>05)... but when that draft went to the IETF LC, it was decided that it is >>better to clarify first the usage of flag bits + define reserved bits as >>flag bits. The 6man draft is not overloaded with all these details, hence >>the generic sentence you quoted in your comment. >> >>It would be good to mention that in the draft as part of the motivation. >It >>doesn't need a lot of detail, but a couple of sentences would make it >>easier for a reader to understand the reasons for defining ff2. > >[Med] Ok, will add some text. This text will also address the previous >comment. > >> >>[...] >> >>>> >>>> -- section 4.1, "old" >>>> >>>> It would be nice to include a reference for [ADDRARCH]. I realize it's >>an >>>> artifact of the quoted text, but I think it's still worth a [perhaps >>>> informational] reference. >>> >>> [Med] [ADDRARCH] is not listed in the reference list because this is a >>quoted text from RFC3306. BTW, [ADDRARCH] is obsoleted by RFC 4291 which >is >>listed in the reference list. I have no problem to add [ADDRARCH] as an >>informative reference if you think this is helpful for the reader. >>> >> >>I think it might be helpful, but on further reflection, I think it >probably >>does no real harm to leave it as is. It might be better to simply add a >>line somewhere nearby to point out that [ADDRARCH] refers to the reference >>in that RFC, not this document, and that it has been since obsoleted. > >[Med] OK, added a note as suggested. > >> >>>> >>>> -- section 4.2, 2nd "new" proposed text: >>>> >>>> " P MUST be set to 1, and consequently T MUST be set to 1 ..." >>>> >>>> Is this intended to be for all multicast addresses, or just those with >>R=1? >>> >>> [Med] This context of this text is RFC3956: R=1. The text says >explicitly >>the motivation for such setting ", as this is a special case of unicast- >>prefix >>> based addresses.". I do think the text is clear. >> >>I understand that is the intent, but I think the text can be read >>otherwise. The old text unambiguously made the second sentence dependent >on >>the first; the new text does not. >> > >[Med] I added "Then" to the new text. > >>> >>>> The proposed text can be read to mean the former, but the old text >seems >>to >>>> mean the latter (due to the word "Then" which is dropped from the new >>>> text.) >>>> >> >>[...] >> >>>> -- idNits complains about the lack of a pre-5378 disclaimer >boilerplate. >>I >>>> found a discussion in the 6man archives ( http://www.ietf.org/mail- >>>> archive/web/ipv6/current/msg20838.html ) indicating the authors >>preferred >>>> not to contact all possible authors of pre-5378 text. Doesn't that mean >>the >>>> draft should carry the boilerplate? >>> >>> [Med] We prefer to leave this point for the RFC Editor. >>> >> >>Do you mean that you prefer to leave the _decision_ to the RFC Editor, or >>that you recognize the pre-5378 boilerplate is needed, but would like the >>RFC editor to insert it? > >[Med] We don't think a disclaimer is needed because we quote old text + the >new one is largely the same. If the RFC editor re-raises the point, we will >clarify our position and then discuss. This is what I meant by " leave this >point for the RFC Editor." > >> >>If the former, The RFC editor will not have the background about the pre- >>5378 text needed to make that call. That's the responsibility of the >>authors. If there's text from pre-5378 IETF documents included, and the >>current authors have not verified that all authors of the original text >>agree to the BCP 78 and 79 terms, then the pre-5378 boilerplate needs to >go >>in. This is important; getting it wrong involves misrepresentation of the >>license terms. >> >>If the latter, then the draft needs some directive to the RFC editor to >add >>the boilerplate. (But keep in mind that the pre-5378 boilerplate >>requirement applies to all contributions. That is, I-Ds as well as RFCs -- >>so it's important to get this right in the _draft_, not just the final >>RFC.) >> >>[...]
- Gen-ART LC Review of draft-ietf-6man-multicast-ad… Ben Campbell
- RE: Gen-ART LC Review of draft-ietf-6man-multicas… mohamed.boucadair
- Re: [Gen-art] Gen-ART LC Review of draft-ietf-6ma… Ben Campbell
- RE: [Gen-art] Gen-ART LC Review of draft-ietf-6ma… mohamed.boucadair
- RE: [Gen-art] Gen-ART LC Review of draft-ietf-6ma… mohamed.boucadair
- Re: [Gen-art] Gen-ART LC Review of draft-ietf-6ma… Ben Campbell
- RE: [Gen-art] Gen-ART LC Review of draft-ietf-6ma… mohamed.boucadair
- Re: [Gen-art] Gen-ART LC Review of draft-ietf-6ma… Ben Campbell
- Re: [Gen-art] Gen-ART LC Review of draft-ietf-6ma… Jari Arkko