RE: [Gen-art] Review of draft-ietf-softwire-multicast-prefix-option-11

Roni Even <roni.even@huawei.com> Mon, 09 January 2017 10:36 UTC

Return-Path: <roni.even@huawei.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C4A412940D; Mon, 9 Jan 2017 02:36:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.42
X-Spam-Level:
X-Spam-Status: No, score=-7.42 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 2gnVVDIj1EvS; Mon, 9 Jan 2017 02:36:57 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05F6E128874; Mon, 9 Jan 2017 02:36:55 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DEC05453; Mon, 09 Jan 2017 10:36:54 +0000 (GMT)
Received: from DGGEMM402-HUB.china.huawei.com (10.3.20.210) by lhreml704-cah.china.huawei.com (10.201.5.130) with Microsoft SMTP Server (TLS) id 14.3.301.0; Mon, 9 Jan 2017 10:36:35 +0000
Received: from DGGEMM506-MBX.china.huawei.com ([169.254.3.117]) by DGGEMM402-HUB.china.huawei.com ([10.3.20.210]) with mapi id 14.03.0301.000; Mon, 9 Jan 2017 18:36:08 +0800
From: Roni Even <roni.even@huawei.com>
To: "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com>, Roni Even <roni.even@mail01.huawei.com>, "gen-art@ietf.org" <gen-art@ietf.org>
Subject: RE: [Gen-art] Review of draft-ietf-softwire-multicast-prefix-option-11
Thread-Topic: [Gen-art] Review of draft-ietf-softwire-multicast-prefix-option-11
Thread-Index: AQHSakTvcdQqqowUCUaeKEwMp0GtyKEvtzTAgAA7kWA=
Date: Mon, 09 Jan 2017 10:36:07 +0000
Message-ID: <6E58094ECC8D8344914996DAD28F1CCD76BD21@DGGEMM506-MBX.china.huawei.com>
References: <148394474257.769.4965226716760320959.idtracker@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B933009DE1B41@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
In-Reply-To: <787AE7BB302AE849A7480A190F8B933009DE1B41@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.201.116.109]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A0B0205.587367C6.02A7, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.117, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 2c695f42638322b29d6ce1ba9c847735
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/OJfCAU9yjw3jjjo6ZORIUASTMws>
Cc: "softwires@ietf.org" <softwires@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>, "draft-ietf-softwire-multicast-prefix-option.all@ietf.org" <draft-ietf-softwire-multicast-prefix-option.all@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.17
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: <https://mailarchive.ietf.org/arch/browse/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, 09 Jan 2017 10:36:58 -0000

Hi Med,
Inline
Roni

-----Original Message-----
From: Gen-art [mailto:gen-art-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com
Sent: יום ב 09 ינואר 2017 09:43
To: Roni Even; gen-art@ietf.org
Cc: softwires@ietf.org; ietf@ietf.org; draft-ietf-softwire-multicast-prefix-option.all@ietf.org
Subject: Re: [Gen-art] Review of draft-ietf-softwire-multicast-prefix-option-11

Dear Roni,

Thank you for the review. 

Please see inline.

Cheers,
Med

> -----Message d'origine-----
> De : Roni Even [mailto:roni.even@mail01.huawei.com]
> Envoyé : lundi 9 janvier 2017 07:52
> À : gen-art@ietf.org
> Cc : softwires@ietf.org; ietf@ietf.org; draft-ietf-softwire-multicast- 
> prefix-option.all@ietf.org Objet : Review of 
> draft-ietf-softwire-multicast-prefix-option-11
> 
> Reviewer: Roni Even
> Review result: Almost Ready
> 
> 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-softwire-multicast-prefix-option-11
> Reviewer: Roni Even
> Review Date:2017-1-9
> IETF LC End Date: 2017–1-12
> IESG Telechat date:
> 
> Summary: This draft is almost  ready for publication as a standard 
> track RFC.
> 
> 
> Major issues:
> 
> Minor issues:
> 
> 1.	In section 4 first paragraph say “DHCP servers supporting
> OPTION_V6_PREFIX64 should be configured with U_PREFIX64 and at least 
> one multicast PREFIX64 (i.e., ASM_PREFIX64 and/or SSM_PREFIX64).” From 
> the rest of the section I understand that for SSM deployments both
> U_PREFIX64 and SSM_PREFIX64 MUST be configured.

[Med] Yes. If you prefer, I can change the text to make this more clear:

OLD:
  DHCP servers supporting OPTION_V6_PREFIX64 should be configured with
   U_PREFIX64 and at least one multicast PREFIX64 (i.e., ASM_PREFIX64
   and/or SSM_PREFIX64).

NEW:
   DHCP servers supporting OPTION_V6_PREFIX64 must be configured with
   ASM_PREFIX64 or SSM_PREFIX64, and may be configured with both.
   U_PREFIX64 must also be configured when SSM_PREFIX64 is provided.
   U_PREFIX64 may be configured when only ASM_PREFIX64 is provided.

Roni: OK

> What is the reason for “should” in the first paragraph? Are there 
> cases where ASM_PREFIX64 or ASM_PREFIX64 and SSM_PREFIX64 are 
> specified and there is no need to specify U_PREFIX64, maybe these 
> cases should be described.
> 

[Med] The presence of the unicast address is mandatory for the SSM case because it is required to form an IPv6 address from an IPv4 address to subscribe to a multicast content from a particular source. For the ASM case, the configuration of the U_PREFIX64 is not mandatory in the following cases: (1) a local mapping algorithm is enabled by the function that grafts the IPv4 multicast host side with an IPv6 multicast tree or (2) in deployments that make use of the WKP (64:ff9b::/96, RFC6052).

I can add this NEW text:

   Note that U_PREFIX64 is not mandatory for the ASM case if, for
   example, a local address mapping algorithm is supported or the Well-
   Know Prefix (64:ff9b::/96) is used.

Roni:OK

> 
> Nits/editorial comments:
> 1.	RFC2119 keywords in the document are sometime capitalized and
> sometime not. I think it will be good to have consistency and if they 
> do not intend to have RFC2119 semantics some other words should be 
> used
> 

[Med] I guess you are referring to Section 4. We are not using normative language on purpose because of previous comments we received from some DHC experts (T. Lemon). The use of normative text for the server behavior would mean that we are updating RFC 3315, which we do not want to do. This is why we are defining this section as configuration guidelines.

Roni: maybe add to section 4 text saying that this section is not normative and serves as guidelines, since this is a standard track document and usage of RFC2119 keywords may be confusing




_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art