[Dime] DOIC #54: OC-Report-Type as mandatory AVP
Steve Donovan <srdonovan@usdonovans.com> Wed, 16 July 2014 12:51 UTC
Return-Path: <srdonovan@usdonovans.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 681E41B2872 for <dime@ietfa.amsl.com>; Wed, 16 Jul 2014 05:51:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.579
X-Spam-Level: *
X-Spam-Status: No, score=1.579 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_NEUTRAL=0.779] autolearn=no
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 1w4AlTPM36yl for <dime@ietfa.amsl.com>; Wed, 16 Jul 2014 05:51:32 -0700 (PDT)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [66.117.4.208]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63B411B2863 for <dime@ietf.org>; Wed, 16 Jul 2014 05:51:32 -0700 (PDT)
Received: from [41.0.92.142] (port=51712 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from <srdonovan@usdonovans.com>) id 1X7OgE-0001Q4-6u for dime@ietf.org; Wed, 16 Jul 2014 05:51:31 -0700
Message-ID: <53C6754B.5020600@usdonovans.com>
Date: Wed, 16 Jul 2014 14:51:23 +0200
From: Steve Donovan <srdonovan@usdonovans.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: "dime@ietf.org" <dime@ietf.org>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-OutGoing-Spam-Status: No, score=-2.9
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - usdonovans.com
X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srd+usdonovans.com/only user confirmed/virtual account not confirmed
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/btmgJwk5fVf9JSxWIQ_xnhvaH3s
Subject: [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: Wed, 16 Jul 2014 12:51:33 -0000
All, Now that the restructure of the DOIC specification is complete 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. 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. 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. 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] 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)