Re: [Dime] New Version Notification for draft-ietf-dime-overload-reqs-02.txt

Ben Campbell <ben@nostrum.com> Wed, 19 December 2012 18:40 UTC

Return-Path: <ben@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 BD23821F862D for <dime@ietfa.amsl.com>; Wed, 19 Dec 2012 10:40:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.308
X-Spam-Level:
X-Spam-Status: No, score=-102.308 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227, SPF_PASS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nnixO+z9xim8 for <dime@ietfa.amsl.com>; Wed, 19 Dec 2012 10:40: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 EB67521F8609 for <dime@ietf.org>; Wed, 19 Dec 2012 10:40:53 -0800 (PST)
Received: from [10.12.11.37] ([4.30.77.1]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id qBJIem1c085232 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 19 Dec 2012 12:40:49 -0600 (CST) (envelope-from ben@nostrum.com)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: Ben Campbell <ben@nostrum.com>
In-Reply-To: <000601cdde0d$80d24f20$8276ed60$@azu.ca>
Date: Wed, 19 Dec 2012 12:40:49 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <B0D2E15D-28B5-4BAF-B40B-A976394D9628@nostrum.com>
References: <20121218231927.31153.89871.idtracker@ietfa.amsl.com> <02FF8071-81D1-4CD2-9D97-E906BAA45FC8@nostrum.com> <8B064DAA-E5D5-4B20-BFBA-225DE9576D70@gmail.com> <50D1E5A3.2030005@gmail.com> <000601cdde0d$80d24f20$8276ed60$@azu.ca>
To: Mark Jones <mark@azu.ca>
X-Mailer: Apple Mail (2.1499)
Received-SPF: pass (nostrum.com: 4.30.77.1 is authenticated by a trusted mechanism)
Cc: dime@ietf.org
Subject: Re: [Dime] New Version Notification for draft-ietf-dime-overload-reqs-02.txt
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.12
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, 19 Dec 2012 18:40:56 -0000

Hi Mark, see comments inline:

Thanks!

Ben.

On Dec 19, 2012, at 11:23 AM, "Mark Jones" <mark@azu.ca> wrote:

>> I think the requirement is trying to say the following:
>> 
>> "Basic support for overload controls MUST be independent of what
>> applications a given Diameter node supports. Individual applications MAY
>> provide more refined support for overload controls."
>> 
> 
> I'm not reading a requirement for basic vs. refined support from the current
> REQ 2 text.  I understand that REQ 2 is trying to establish the bounds of
> acceptable impacts on existing Diameter applications. IMHO it should read
> something like "the addition of the Diameter overload control mechanism to
> an existing Diameter application MUST NOT require the allocation of a new
> application id". Do we need to constrain the solution any further?
> 

The original Req 2 language clearly created confusion about it's original intent. This really is about application-independence.  I think that not forcing new application IDs is an implication of that intent, but does not capture it entirely. Please see my separate response to Tom's email.


> I don't understand the motivation for requiring that it "MUST NOT require
> specification changes for existing Diameter applications". If 3GPP decides
> that Diameter overload control must be supported on an existing reference
> point, I would expect the 3GPP TS for that release to be updated to state
> just that. This is a "specification change" and I don't see how else a
> vendor would know that they had to update their implementation. What am I
> missing here?

The idea is that an implementor would not have to wait for 3GPP in order to implement whatever RFC we come up with in DIME. 3GPP could certainly require support, and specify application-specific refinements. Those would require updates to the relevant specs. But even if they didn't do that, people could still choose to support some level of overload control.

> 
> /Mark
> 
>> On 19/12/2012 3:47 AM, Jouni Korhonen wrote:
>>> 
>>> Hi Ben,
>>> 
>>> Thanks for the update. Now that the new revision is out I would
>>> encourage the WG to sort out the language in REQ 2 asap. As long as it
>>> is in flux the document cannot proceed to WGLC.
>>> 
>>> - jouni
>>> 
>> ...
>> _______________________________________________
>> DiME mailing list
>> DiME@ietf.org
>> https://www.ietf.org/mailman/listinfo/dime
> 
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime