Re: [secdir] [spam] secdir review of draft-ietf-ancp-mc-extensions-14

Tom Taylor <tom.taylor.stds@gmail.com> Sat, 01 February 2014 02:20 UTC

Return-Path: <tom.taylor.stds@gmail.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B7231ACCF4; Fri, 31 Jan 2014 18:20:28 -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 RMhurur0kvv7; Fri, 31 Jan 2014 18:20:26 -0800 (PST)
Received: from mail-ig0-x22a.google.com (mail-ig0-x22a.google.com [IPv6:2607:f8b0:4001:c05::22a]) by ietfa.amsl.com (Postfix) with ESMTP id D3C6B1ACCE3; Fri, 31 Jan 2014 18:20:25 -0800 (PST)
Received: by mail-ig0-f170.google.com with SMTP id m12so2238043iga.1 for <multiple recipients>; Fri, 31 Jan 2014 18:20:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=d6sb92ttkxEobdFj82ZWJhH65++uS/Zlj7Krse7GY7Y=; b=KyWr1Jz8IS/fd9hXE/3U0TttuxRf4U9AFooC6B2by9Se2NJzJyy6ClX2u9FlmQQO6t ERUjx1yxnXbLMMKlEFmyKqKdyckZrMqDBPYx0RBj/0RtTcAkMplKiOGQNBLShq/Z7SNF K5D7bj8ohf/hd6cvVlMiG1UGYo2MYR6yjEgqolV8QRtMvGczyVqEFn7pmk15iyXE6AoN nI723djMdincEYWMAI6cS2vArMCLQ2r+e/Z5/wGSI3D38kBTUFUj4e10oRlGTHX+nlhq 2F/syJbGrEoB9E+cKikBNMTzwJVGAXgSwGyLTBj/7NYFWVRg8MWQOgUsqPW0j72473uN Imdw==
X-Received: by 10.50.176.165 with SMTP id cj5mr1486645igc.19.1391221221991; Fri, 31 Jan 2014 18:20:21 -0800 (PST)
Received: from [192.168.0.101] ([199.246.39.82]) by mx.google.com with ESMTPSA id l7sm3530347igx.2.2014.01.31.18.20.20 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 31 Jan 2014 18:20:21 -0800 (PST)
Message-ID: <52EC59E2.7090500@gmail.com>
Date: Fri, 31 Jan 2014 21:20:18 -0500
From: Tom Taylor <tom.taylor.stds@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: "Zhangdacheng (Dacheng)" <zhangdacheng@huawei.com>, "iesg@ietf.org" <iesg@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>, "draft-ietf-ancp-mc-extensions.all@tools.ietf.org" <draft-ietf-ancp-mc-extensions.all@tools.ietf.org>
References: <C72CBD9FE3CA604887B1B3F1D145D05E3B4292C2@nkgeml507-mbs.china.huawei.com> <52E1B176.9070209@gmail.com> <C72CBD9FE3CA604887B1B3F1D145D05E3B429E8F@nkgeml507-mbs.china.huawei.com>
In-Reply-To: <C72CBD9FE3CA604887B1B3F1D145D05E3B429E8F@nkgeml507-mbs.china.huawei.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [secdir] [spam] secdir review of draft-ietf-ancp-mc-extensions-14
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 01 Feb 2014 02:20:28 -0000

On 26/01/2014 12:53 AM, Zhangdacheng (Dacheng) wrote:
>>>
>>> 4)
>>>
>>> Section 6.1.3 lists the protocol elements that MUST be
>>> implemented to support the conditional access with white and
>>> black lists multicast capability. I found White-List-CAC TLV is
>>> included in the list. However, the White-List-CAC TLV is used to
>>> indicate that the NAS wishes the AN to do admission control for
>>> white-listed flows, and this use case is discussed in Section
>>> 3.4.2.3 of RFC 5851 "Multicast Admission Control and White
>>> Lists". So, I doubt whether this TLV needs to be supported is
>>> this case.
>>>
>> [PTT] Doesn't Section 3.4.2.3 describe a case where the AN does
>> both admission control and white listing, and sets the conditions
>> for doing that?
>>
>> "IPTV is an example of a service that will not be offered as best
>> effort, but requires some level of guaranteed quality of service.
>> This requires the use of Multicast Admission Control.  Hence, if
>> the Access Node wants to autonomously perform the admission
>> process, it must be aware of the bandwidth characteristics of
>> multicast flows. Otherwise, the Access Node would have to query the
>> NAS for Multicast Admission Control (per the grey list behavior);
>> this would defeat the purpose of using a white and black list."
>>
>
> [Dacheng Zhang:] Maybe I didn't explain my point view clearly last
> time. Sorry for that.
>
> If the title of section 6.13 is "Protocol Requirements For Admission
> Control With White and Black Lists ", then everything is perfect
> because this TLV is used to indicate that the NAS wishes the AN to do
> admission control for white-listed flows. The use case you provided
> above is also one for admission control. But at the moment, the tile
> of this section is " Protocol Requirements For Conditional Access
> With White and Black Lists ". That is why I raised a question here
> for your consideration. ^_^
>
> Cheers
>
> Dacheng
>
>
[PTT] This is the last outstanding item from your review.

The simple resolution is as you suggest: change the names of the 
capabilities. I'll do that.

Tom