Re: [Dime] DOIC #54: OC-Report-Type as mandatory AVP

Ben Campbell <ben@nostrum.com> Wed, 16 July 2014 14:18 UTC

Return-Path: <ben@nostrum.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 E1F4D1B288D for <dime@ietfa.amsl.com>; Wed, 16 Jul 2014 07:18:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.551
X-Spam-Level:
X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] 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 myNjX6hTaKBh for <dime@ietfa.amsl.com>; Wed, 16 Jul 2014 07:18:50 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 A0A3E1B287B for <dime@ietf.org>; Wed, 16 Jul 2014 07:18:50 -0700 (PDT)
Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s6GEImCw013923 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 16 Jul 2014 09:18:49 -0500 (CDT) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23]
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Ben Campbell <ben@nostrum.com>
In-Reply-To: <53C6754B.5020600@usdonovans.com>
Date: Wed, 16 Jul 2014 09:18:47 -0500
X-Mao-Original-Outgoing-Id: 427213127.2936-b9228952ea58e58a8da095d23426682b
Content-Transfer-Encoding: quoted-printable
Message-Id: <E7E477E9-DB14-4877-8288-7210BAB49427@nostrum.com>
References: <53C6754B.5020600@usdonovans.com>
To: Steve Donovan <srdonovan@usdonovans.com>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/Y15pzBucLSe407B_5TORySelEKI
Cc: "dime@ietf.org" <dime@ietf.org>
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: Wed, 16 Jul 2014 14:18:52 -0000

I thought our chairs had declared a rough consensus on this. Do I have that confused with another issue?

On Jul 16, 2014, at 7:51 AM, Steve Donovan <srdonovan@usdonovans.com> wrote:

> 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 mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime