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

Tom Taylor <tom.taylor.stds@gmail.com> Sun, 26 January 2014 10:10 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 8C7A71A011F; Sun, 26 Jan 2014 02:10:22 -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 NePiGCbrWeqU; Sun, 26 Jan 2014 02:10:21 -0800 (PST)
Received: from mail-ie0-x22d.google.com (mail-ie0-x22d.google.com [IPv6:2607:f8b0:4001:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id DE5FA1A0119; Sun, 26 Jan 2014 02:10:20 -0800 (PST)
Received: by mail-ie0-f173.google.com with SMTP id e14so4679446iej.4 for <multiple recipients>; Sun, 26 Jan 2014 02:10:19 -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=AO7G0cS+U2+IsXg3iAHhGLJWDjMvOZPCPHdNSbovCBc=; b=EOoUmMhrlPM4RbzBTakLtKb3Ft1X71r7Pq0cPrISfTTtdnzOTLnSY9k2pSnWkDlg9W qgjH99d/gcfbey/AVl/oVoRnpxJScax+yF/vG26UWzioEdSexlchFw/ZNEOFYtuMITHa mD4OGBgA6mOxwY/FB67rAlCp4O2J8/1fT5hSlAPyjGTVs09DXRAoyUQBqHAq/pEUZQ4V VfrbqpOcf0Kq9fVXGOWVRMVHUzhcbZrBWzOEALUghLFd47syZrttlTVwSv2JmzHB54Di XKEerA7QM9D4U3dSEm9HcjDhouNqRSxkBZpsVpC+HZIJDBKcQmFm0YyO8XT+TTF8wGia XPYA==
X-Received: by 10.42.228.65 with SMTP id jd1mr8589icb.62.1390731019031; Sun, 26 Jan 2014 02:10:19 -0800 (PST)
Received: from [192.168.1.69] ([64.56.225.169]) by mx.google.com with ESMTPSA id w4sm31478820igb.5.2014.01.26.02.10.17 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 26 Jan 2014 02:10:18 -0800 (PST)
Message-ID: <52E4DF07.6070303@gmail.com>
Date: Sun, 26 Jan 2014 05:10:15 -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: Sun, 26 Jan 2014 10:10:22 -0000

OK. let's review this point when I clean up all the terminology. I think 
you may be right and this belongs in one of the combined sections.

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
>
>