Re: [Dime] DOIC #54: OC-Report-Type as mandatory AVP
"Wiehe, Ulrich (NSN - DE/Munich)" <ulrich.wiehe@nsn.com> Sat, 19 July 2014 08:19 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 5C05F1B27D5 for <dime@ietfa.amsl.com>; Sat, 19 Jul 2014 01:19:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level:
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 vT2tnvFqtDSa for <dime@ietfa.amsl.com>; Sat, 19 Jul 2014 01:19:35 -0700 (PDT)
Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FC3B1B27F2 for <dime@ietf.org>; Sat, 19 Jul 2014 01:19:29 -0700 (PDT)
Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.14.3/8.14.3) with ESMTP id s6J8JRio021281 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sat, 19 Jul 2014 08:19:27 GMT
Received: from DEMUHTC002.nsn-intra.net ([10.159.42.33]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s6J8JRdx004816 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 19 Jul 2014 10:19:27 +0200
Received: from DEMUHTC005.nsn-intra.net (10.159.42.36) by DEMUHTC002.nsn-intra.net (10.159.42.33) with Microsoft SMTP Server (TLS) id 14.3.181.6; Sat, 19 Jul 2014 10:19:27 +0200
Received: from DEMUMBX014.nsn-intra.net ([169.254.14.93]) by DEMUHTC005.nsn-intra.net ([10.159.42.36]) with mapi id 14.03.0181.006; Sat, 19 Jul 2014 10:19:27 +0200
From: "Wiehe, Ulrich (NSN - DE/Munich)" <ulrich.wiehe@nsn.com>
To: ext Steve Donovan <srdonovan@usdonovans.com>, "dime@ietf.org" <dime@ietf.org>
Thread-Topic: [Dime] DOIC #54: OC-Report-Type as mandatory AVP
Thread-Index: AQHPoPSxIgC83ZHZCE+YBFS0xo8a4ZunCeZg
Date: Sat, 19 Jul 2014 08:19:26 +0000
Message-ID: <5BCBA1FC2B7F0B4C9D935572D9000668151FE382@DEMUMBX014.nsn-intra.net>
References: <53C6754B.5020600@usdonovans.com>
In-Reply-To: <53C6754B.5020600@usdonovans.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.159.42.122]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
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: 3015
X-purgate-ID: 151667::1405757967-00007A71-4936938F/0/0
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/hMFETZVSGVt1M_pfjvtE47keW_4
Subject: Re: [Dime] DOIC #54: OC-Report-Type as mandatory AVP
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: Sat, 19 Jul 2014 08:19:37 -0000
Steve, please see inline. Regards Ulrich -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan Sent: Wednesday, July 16, 2014 2:51 PM To: dime@ietf.org Subject: [Dime] DOIC #54: OC-Report-Type as mandatory AVP All, Now that the restructure of the DOIC specification is complete [Wiehe, Ulrich (NSN - DE/Munich)] I don't think the restructuring is complete. I did send comments and identified issues which in my understanding are not resolved yet. we need to start resolving open issues. Those that entered the issues are encouraged to work to get them closed. I'll start on #54 in this email. The question is whether the OC-Report-Type AVP is required any time that an OC-OLR AVP is sent. The current version of the draft is the same as the -02 version, showing the AVP as being required. This was based on an earlier attempt to close the issue prior to -02 being published. Susan has stated that she does not think it should be required. If I understand correctly this is based on the assumption that an HSS would never send an OLR with report-type of any value but host. Susan, please correct me if I'm mistaken. I don't believe this is a correct assumption. It is reasonable for an HSS to send an OLR with report-type of realm. [Wiehe, Ulrich (NSN - DE/Munich)] I do not agree This might happen in a non agent based deployment or in a deployment where the HSS (or more generically, server) has knowledge of the status of all servers for the application.[Wiehe, Ulrich (NSN - DE/Munich)] How would the HSS get that knowledge? It is the task of the node that selects the server to aggregate and to convert received host-reports into a realm-report. If we want the server to do that we need to describe how overload information is exchanged from one reporting node to another reporting node (ensuring exact synchronization). The agreed concept of DOIC associations between reacting node and reporting node does not cover this. Based on this, I propose that the text be kept as is and that this issue be closed without changes to the specification. The threshold for changing what is currently in the DOIC specification is rough consensus in the group that it should be changed. Anyone with an opinion is encouraged to state it now. [Wiehe, Ulrich (NSN - DE/Munich)] I can accept to keep text as it is (although my preference is in favour of Susan's approach), as it allows the HSS to send host-reports and does not force it to send realm-reports. This is not a vote (we don't vote in the IETF...) but an attempt to see if we have consensus to either close the issue without a change in the specification or if we have consensus to change the specification. Regards, Steve _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime
- [Dime] DOIC #54: OC-Report-Type as mandatory AVP Steve Donovan
- Re: [Dime] DOIC #54: OC-Report-Type as mandatory … Ben Campbell
- Re: [Dime] DOIC #54: OC-Report-Type as mandatory … Steve Donovan
- Re: [Dime] DOIC #54: OC-Report-Type as mandatory … Jouni Korhonen
- Re: [Dime] DOIC #54: OC-Report-Type as mandatory … Steve Donovan
- Re: [Dime] DOIC #54: OC-Report-Type as mandatory … Wiehe, Ulrich (NSN - DE/Munich)
- Re: [Dime] DOIC #54: OC-Report-Type as mandatory … Shishufeng (Susan)
- Re: [Dime] DOIC #54: OC-Report-Type as mandatory … Steve Donovan
- Re: [Dime] DOIC #54: OC-Report-Type as mandatory … Shishufeng (Susan)