IETF Logo Mail Archive

[Dime] Issue#30 status

"Wiehe, Ulrich (NSN - DE/Munich)" <ulrich.wiehe@nsn.com> Wed, 19 February 2014 09:57 UTC

Return-Path: <ulrich.wiehe@nsn.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 2E8031A0396 for <dime@ietfa.amsl.com>; Wed, 19 Feb 2014 01:57:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.899
X-Spam-Level:
X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-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 2GCCUq0TTiFj for <dime@ietfa.amsl.com>; Wed, 19 Feb 2014 01:57:45 -0800 (PST)
Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 5805E1A00B7 for <dime@ietf.org>; Wed, 19 Feb 2014 01:57:45 -0800 (PST)
Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id s1J9vfgJ014283 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <dime@ietf.org>; Wed, 19 Feb 2014 10:57:41 +0100
Received: from DEMUHTC001.nsn-intra.net ([10.159.42.32]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s1J9veaa017287 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <dime@ietf.org>; Wed, 19 Feb 2014 10:57:40 +0100
Received: from DEMUHTC014.nsn-intra.net (10.159.42.45) by DEMUHTC001.nsn-intra.net (10.159.42.32) with Microsoft SMTP Server (TLS) id 14.3.123.3; Wed, 19 Feb 2014 10:57:40 +0100
Received: from DEMUMBX014.nsn-intra.net ([169.254.14.242]) by DEMUHTC014.nsn-intra.net ([10.159.42.45]) with mapi id 14.03.0123.003; Wed, 19 Feb 2014 10:57:40 +0100
From: "Wiehe, Ulrich (NSN - DE/Munich)" <ulrich.wiehe@nsn.com>
To: "dime@ietf.org list" <dime@ietf.org>
Thread-Topic: Issue#30 status
Thread-Index: Ac8tWQX7CYmMbh1xRs+Dq0AnmWwb3g==
Date: Wed, 19 Feb 2014 09:57:39 +0000
Message-ID: <5BCBA1FC2B7F0B4C9D935572D9000668151B3BCF@DEMUMBX014.nsn-intra.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.159.42.126]
Content-Type: multipart/alternative; boundary="_000_5BCBA1FC2B7F0B4C9D935572D9000668151B3BCFDEMUMBX014nsnin_"
MIME-Version: 1.0
X-purgate-type: clean
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-size: 3013
X-purgate-ID: 151667::1392803861-00005322-CBAD230C/0-0/0-0
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/DA2CWGbOIfkkHd7uWXhhf0jILrg
Subject: [Dime] Issue#30 status
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: Wed, 19 Feb 2014 09:57:48 -0000

#30: OC-Supported-Features AVP in answer messages

Dear all,

It may be too early to finaly conclude on this one.

It seems we have consensus in the following: Absence of Supported-Features-AVP from an answer message MUST not result in reacting nodes to cease sending of any DOIC related AVPs in subsequent requests.

It is still open whether we can remove OC-Supported-Features from answer messages. However we seem to agree that the meaning of OC-OLR AVP is not dependent from any OC-Supported-Features AVP within the same answer.

The open question seems to be whether it is required for reacting nodes to do different throttlings based on implicit signals towards a) non-supporting destinations  and b) supporting but not traffic-reduction-requesting destinations. If required it seems also be clear that an additional indication is needed to indicate whether the OC-Supported-Feature AVP was inserted by the server (host) or by an agent (realm).

Ulrich

v2.23.0 | Report a Bug | By Email