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