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

"Zhangdacheng (Dacheng)" <zhangdacheng@huawei.com> Sun, 26 January 2014 05:53 UTC

Return-Path: <zhangdacheng@huawei.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 1E3661A00FC; Sat, 25 Jan 2014 21:53:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.736
X-Spam-Level:
X-Spam-Status: No, score=-4.736 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535, 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 qICkwoVd7eFh; Sat, 25 Jan 2014 21:53:39 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 7DCC71A00FB; Sat, 25 Jan 2014 21:53:38 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BAK68708; Sun, 26 Jan 2014 05:53:36 +0000 (GMT)
Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sun, 26 Jan 2014 05:53:11 +0000
Received: from NKGEML406-HUB.china.huawei.com (10.98.56.37) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sun, 26 Jan 2014 05:53:35 +0000
Received: from NKGEML507-MBS.china.huawei.com ([169.254.6.75]) by nkgeml406-hub.china.huawei.com ([10.98.56.37]) with mapi id 14.03.0158.001; Sun, 26 Jan 2014 13:53:28 +0800
From: "Zhangdacheng (Dacheng)" <zhangdacheng@huawei.com>
To: Tom Taylor <tom.taylor.stds@gmail.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>
Thread-Topic: [spam] [secdir] secdir review of draft-ietf-ancp-mc-extensions-14
Thread-Index: Ac8XPd+LcI+ULRdMSv6oBbGFFsLvBwBGPR0AAHy3lIA=
Date: Sun, 26 Jan 2014 05:53:27 +0000
Message-ID: <C72CBD9FE3CA604887B1B3F1D145D05E3B429E8F@nkgeml507-mbs.china.huawei.com>
References: <C72CBD9FE3CA604887B1B3F1D145D05E3B4292C2@nkgeml507-mbs.china.huawei.com> <52E1B176.9070209@gmail.com>
In-Reply-To: <52E1B176.9070209@gmail.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.111.98.139]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
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 05:53:41 -0000

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