[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