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

["Mark Jones" <[e-mail]>]

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.

> 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. 

/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