[Dime] DOIC: Multiple instance of OC-OLR AVP (of the same type) within a response message

"Nirav Salot (nsalot)" <nsalot@cisco.com> Thu, 28 November 2013 09:33 UTC

Return-Path: <nsalot@cisco.com>
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 844D31ADBD5 for <dime@ietfa.amsl.com>; Thu, 28 Nov 2013 01:33:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level:
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 sczfhwjwzJhZ for <dime@ietfa.amsl.com>; Thu, 28 Nov 2013 01:33:19 -0800 (PST)
Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 0D5A81ADBD2 for <dime@ietf.org>; Thu, 28 Nov 2013 01:33:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8656; q=dns/txt; s=iport; t=1385631198; x=1386840798; h=from:to:subject:date:message-id:mime-version; bh=p+4O5WlctR+igC4Y5qbEHh60jvDk8CfNFbZySe9ceuc=; b=YQplRzb4DRPpjNLUBLgywr7MTmIBsxcuz0hqizH7WjXoyU9DFLLGQmw4 pARFSil8SQc3Avvk1+i3oPC6Uq5DgeaDjCum93jBnUmvPlj7w2md6sr1j IRe/OmZQZl6qY34NibqT/MEIvKPUGuvy/Z/H1f4iVYcOAtndKVkhGhh9P M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ar0FAEkNl1KtJXG//2dsb2JhbABZgkNEOFO4RYEfFm0HgicBBC1eASpWJgEEGxOHZqAwn3wXjlaDWIETA6ongWuBPoIq
X-IronPort-AV: E=Sophos; i="4.93,789,1378857600"; d="scan'208,217"; a="287903573"
Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-1.cisco.com with ESMTP; 28 Nov 2013 09:33:18 +0000
Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id rAS9XHCS010148 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <dime@ietf.org>; Thu, 28 Nov 2013 09:33:18 GMT
Received: from xmb-rcd-x10.cisco.com ([169.254.15.250]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.03.0123.003; Thu, 28 Nov 2013 03:33:17 -0600
From: "Nirav Salot (nsalot)" <nsalot@cisco.com>
To: "dime@ietf.org" <dime@ietf.org>
Thread-Topic: DOIC: Multiple instance of OC-OLR AVP (of the same type) within a response message
Thread-Index: Ac7sHN1kcwdoL1xIRoywlc8N1o+kQQ==
Date: Thu, 28 Nov 2013 09:33:17 +0000
Message-ID: <A9CA33BB78081F478946E4F34BF9AAA014D1EC79@xmb-rcd-x10.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.142.140.76]
Content-Type: multipart/alternative; boundary="_000_A9CA33BB78081F478946E4F34BF9AAA014D1EC79xmbrcdx10ciscoc_"
MIME-Version: 1.0
Subject: [Dime] DOIC: Multiple instance of OC-OLR AVP (of the same type) within a response message
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dime>, <mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dime/>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dime>, <mailto:dime-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 28 Nov 2013 09:33:21 -0000

Hi,

As I understand IETF will define the base overload control solution as part of DOIC. Then 3GPP would adopt the defined solution for each of its application.
When that happens, 3GPP might want to add 3GPP specific AVP within OC-OLR AVP. Based on the current definition of the OC-OLR AVP this should be allowed since it contains "* [AVP]" in its definition.
e.g. for a given application 3GPP decides to add information into OC-OLR which changes the scope of the OC-OLR from application level to the provided information level.
Additionally, the reporting may want to advertise the OC-OLR at the application level scope - i.e. the OC-OLR without any 3GPP specific info.

So if the above is allowed, we will have the possibility of the reporting node wanting to include two instances of OC-OLR with the Report-Type="host".
And then we need to define the handling of multiple instances of OC-OLR in the DOIC draft.

So the questions are,

-          Is 3GPP (or any other SDO) allowed to extend the definition of OC-OLR by adding information into it?

-          If no, can we guarantee that application level scope of OC-OLR (which is what we have defined currently) is sufficient (and not restricting) to all the applications of 3GPP?

Regards,
Nirav.