Re: [Dime] Issue#35 conclusion

Ben Campbell <ben@nostrum.com> Thu, 20 February 2014 22:54 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 BD7A31A030D for <dime@ietfa.amsl.com>; Thu, 20 Feb 2014 14:54:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.036
X-Spam-Level:
X-Spam-Status: No, score=-1.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] 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 o6YCVzPgXo1S for <dime@ietfa.amsl.com>; Thu, 20 Feb 2014 14:54:55 -0800 (PST)
Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id E5EC71A0328 for <dime@ietf.org>; Thu, 20 Feb 2014 14:54:53 -0800 (PST)
Received: from [10.0.1.29] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id s1KMsmEi009151 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 20 Feb 2014 16:54:49 -0600 (CST) (envelope-from ben@nostrum.com)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Ben Campbell <ben@nostrum.com>
In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D9000668151B3F63@DEMUMBX014.nsn-intra.net>
Date: Thu, 20 Feb 2014 16:54:49 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <77A3D88E-DDC7-494A-8357-C0F8594A6310@nostrum.com>
References: <5BCBA1FC2B7F0B4C9D935572D9000668151B3F63@DEMUMBX014.nsn-intra.net>
To: "Wiehe, Ulrich (NSN - DE/Munich)" <ulrich.wiehe@nsn.com>
X-Mailer: Apple Mail (2.1827)
Received-SPF: pass (shaman.nostrum.com: 173.172.146.58 is authenticated by a trusted mechanism)
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/h9uCVOdnIEIhN_8t0XkSiyjV-Eo
Cc: "dime@ietf.org" <dime@ietf.org>
Subject: Re: [Dime] Issue#35 conclusion
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: Thu, 20 Feb 2014 22:54:57 -0000

On Feb 20, 2014, at 6:41 AM, Wiehe, Ulrich (NSN - DE/Munich) <ulrich.wiehe@nsn.com> wrote:

> #35: additional report types are proposed
>  
> Dear all,
>  
> I believe we can conclude, not to add additional report types. However, we agreed to add clarifying text to clause 5.5 as follows:
>  
> When an agent received an OLR in response to a request initiated by a client not supporting DOIC, this agent needs to bind the received OLR to the origin-host of the client.

I do not agree.

You proposal implies that the server's OLR only applies to that client. If there's an intervening DOIC agent, then the agent, not the client, is the reacting node from the server's perspective. But, short of adding an origin-host type, nothing binds the OLR to a particular client, regardless of DOIC support at the clients.

 Whether or not the client also supports DOIC doesn't change that. For DOIC-supporting clients, the agent has the additional option of reducing traffic by asking the clients to reduce traffic (making them reacting nodes from the perspective of the _agent_, but not the server.)  It doesn't have that option for non-DOIC clients.