Re: [Dime] WGLC #1 for draft-ietf-dime-agent-overload-05

"A. Jean Mahoney" <mahoney@nostrum.com> Mon, 06 June 2016 19:10 UTC

Return-Path: <mahoney@nostrum.com>
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7301112D8D8 for <dime@ietfa.amsl.com>; Mon, 6 Jun 2016 12:10:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.326
X-Spam-Level:
X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=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 0PNsUv2KitCC for <dime@ietfa.amsl.com>; Mon, 6 Jun 2016 12:10:15 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4232612D105 for <dime@ietf.org>; Mon, 6 Jun 2016 12:10:15 -0700 (PDT)
Received: from mutabilis-2.local ([108.19.241.180]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id u56JACdv032273 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 6 Jun 2016 14:10:12 -0500 (CDT) (envelope-from mahoney@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host [108.19.241.180] claimed to be mutabilis-2.local
To: Steve Donovan <srdonovan@usdonovans.com>, jouni.nospam@gmail.com, "dime@ietf.org" <dime@ietf.org>, "Lionel.morand@orange.com" <Lionel.morand@orange.com>
References: <5bba2470-8921-f7db-0f1b-aad280eae684@gmail.com> <9cf5ab38-2e42-c747-98ba-52b61aa959f8@nostrum.com> <3c01a953-9308-f48a-2ecf-e450c46a3320@usdonovans.com>
From: "A. Jean Mahoney" <mahoney@nostrum.com>
Message-ID: <ae3e2321-abbb-53aa-6e97-9db804c1bb73@nostrum.com>
Date: Mon, 6 Jun 2016 14:10:12 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.1.1
MIME-Version: 1.0
In-Reply-To: <3c01a953-9308-f48a-2ecf-e450c46a3320@usdonovans.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dime/5GoI55LswbFcDwPaXkglxd6UWNM>
Subject: Re: [Dime] WGLC #1 for draft-ietf-dime-agent-overload-05
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.17
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: <https://mailarchive.ietf.org/arch/browse/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: Mon, 06 Jun 2016 19:10:16 -0000

Hi Steve,

Thanks for taking care of my comments. I've trimmed the closed issues 
below. I'm still confused on section 5.1.2. though. Comments below -

On 6/5/16 8:58 PM, Steve Donovan wrote:
>
> On 6/1/16 6:11 PM, A. Jean Mahoney wrote:
>>
>> Section 5.1.2
>>
>> "When relaying an answer message, a reporting node that supports
>> the OC_PEER_REPORT feature MUST strip any SourceID AVP from the
>> OC- Supported-Features AVP."
>>
>> And replace it with a SourceID AVP containing its own Diameter
>> identity? Or does an answer with an OC-Supported-Features AVP that
>> does not have a SourceID AVP mean the peer is an agent? Section 5
>> doesn't cover how to interpret an OC-Supported-Features AVP without
>> a SourceID, only when a SourceID doesn't match the peer.
> SRD> The next two paragraphs address when the SourceID is included.
> Maybe I need to change the next paragraph to the following:
>
> From:
>
> When sending an answer message, a reporting node that supports the
> OC_PEER_REPORT feature MUST determine if the peer to which the
> answer is to be sent supports the OC_PEER_REPORT feature.
>
> To:
>
> When sending *or relaying* an answer message, a reporting node that
> supports the OC_PEER_REPORT feature MUST determine if the peer to
> which the answer is to be sent supports the OC_PEER_REPORT feature.


Are agents and servers equivalent then? Should the definition of 
reporting node be updated?

From:

       A DOIC Node that sends an overload report in a Diameter answer
       message.

To:

       A DOIC Node that sends *or relays* an overload report in a
       Diameter answer message.


Thanks,

Jean