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

[Ben Campbell <[e-mail]>]

On Dec 19, 2012, at 2:38 PM, "Mark Jones" <[e-mail]> wrote:

> Hi Eric,
> 
>> There wasn't a mention of basic and refined before, but I think Tom's
>> comment was close to what the requirement was trying to get at.  It goes
>> beyond not changing the application id.  
> 
> If I've understood correctly, REQ2 was originally intended to capture the
> requirement for an application-neutral overload control mechanism. The
> support for application-specific extensions for overload control is a new
> requirement that has come out of discussions of the original REQ2 text. Just
> to be clear, I'm not arguing against either requirement. I just couldn't
> derive the new requirement from reading revision -02.

Basically, yes. The extensibility requirement was intended, but not well documented. It's mentioned in the motivating text, but not so much in the requirements. That's why I think we should make it explicit in Req2.

> 
>> It is entirely possible to design a
>> mechanism that requires no action from 3GPP and the requirement was
>> intended to ensure that the resulting mechanism is designed that way.
>> 
> 
> I understand the design goal but I think you missed the point of my 3GPP
> example. You can certainly design the mechanism and publish an RFC with "no
> action from 3GPP". However, until 3GPP updates and ratifies their technical
> specification (TS) to state that your RFC MUST be supported on a given
> reference point, an operator cannot assume multi-vendor interoperability of
> your RFC on that 3GPP reference point. 

Customers often create MUSTs that don't show up in the standards :-) That is, there may well be market pressure to implement OC whether or not the 3GPP normatively requires it. The real issue there is what happens when some vendors implement it and some don't. Req 16 talks about that. 

So far, all the proposed mechanisms require negotiation of support, so there's no interop problem introduced. That is, if one peer supports it and the other doesn't, nothing should break, although you won't get the benefit of the mechanism. I don't think we have an explicit requirement for negotiation, but I think it's pretty clearly implied by Reqs 6 and 16.

> 
> /Mark
> 
>> Thanks,
>> 
>> Eric
>> 
>> 
>> On Dec 19, 2012, at 18:23 , Mark Jones <[e-mail]> 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?
>>> 
>>> 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?
>>> 
>>> /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
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/dime
>>> 
>>> _______________________________________________
>>> DiME mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/dime
> 
> 
> _______________________________________________
> DiME mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dime