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

Steve Donovan <srdonovan@usdonovans.com> Wed, 08 June 2016 18:23 UTC

Return-Path: <srdonovan@usdonovans.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 1968212B01A for <dime@ietfa.amsl.com>; Wed, 8 Jun 2016 11:23:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.121
X-Spam-Level:
X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NEUTRAL=0.779] autolearn=no 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 2Ku-R5ZFyhKu for <dime@ietfa.amsl.com>; Wed, 8 Jun 2016 11:23:47 -0700 (PDT)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [74.124.197.190]) (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 C6FC91200A0 for <dime@ietf.org>; Wed, 8 Jun 2016 11:23:47 -0700 (PDT)
Received: from inet-141-146-6-188.oracle.com ([137.254.4.60]:53826 helo=Steves-MacBook-Air.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1.2:DHE-RSA-AES256-SHA:256) (Exim 4.86_1) (envelope-from <srdonovan@usdonovans.com>) id 1bAi8n-002MNB-ML; Wed, 08 Jun 2016 11:23:47 -0700
To: "A. Jean Mahoney" <mahoney@nostrum.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> <ae3e2321-abbb-53aa-6e97-9db804c1bb73@nostrum.com>
From: Steve Donovan <srdonovan@usdonovans.com>
Message-ID: <6494a6a0-46d6-7b03-b126-8b0e90826189@usdonovans.com>
Date: Wed, 08 Jun 2016 13:23:45 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.1.1
MIME-Version: 1.0
In-Reply-To: <ae3e2321-abbb-53aa-6e97-9db804c1bb73@nostrum.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
X-OutGoing-Spam-Status: No, score=-1.0
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: srdonovan@usdonovans.com
X-Authenticated-Sender: biz131.inmotionhosting.com: srdonovan@usdonovans.com
X-Source:
X-Source-Args:
X-Source-Dir:
Archived-At: <https://mailarchive.ietf.org/arch/msg/dime/9mXd5IuI-2vRrYzpZNeCyisdGvA>
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: Wed, 08 Jun 2016 18:23:49 -0000


On 6/6/16 2:10 PM, A. Jean Mahoney wrote:
> 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.
SRD> Actually, I would rather change the requirement to refer to a DOIC 
node instead of a reporting node as follows:

    When sending *or relaying* an answer message, a DOIC 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.
>
>
> Thanks,
>
> Jean