Subject: Re: [Dime] WGLC for draft-ietf-dime-overload-reqs-03

From: Jouni Korhonen <[email-masked]>
Date: Thu, 7 Feb 2013 11:38:13 +0200

Folks,

The WGLC for this I-D has completed. There was a fair amount of comments and
I expect the authors to produce an update of the I-D. The sooner the better
regarding the next steps in the publication process. There were few comments
that seem to be still left open so those need to be hashes out first. Just as 
a comment I am not too keen on adding new requirements at this point unless
there is a wide support for one (wide means more than the individual who
proposed it).

- Jouni

On Jan 22, 2013, at 2:29 PM, Jouni Korhonen <[email-masked]> wrote:

> Folks,
> 
> The authors of draft-ietf-dime-overload-reqs have requested for a WGLC
> and I think the document is stable enough for it.
> 
> This email starts a two week WGLC for draft-ietf-dime-overload-reqs-03.
> The WGLC ends Tuesday 5th February 2013. Post your comments to the 
> mailing list and if you think something needs to be changed, put that
> also into the Issue Tracker. 
> 
> - Jouni & Lionel
> 
> 
>

---

From: Eric McMurry <[email-masked]>
Date: Sat, 16 Feb 2013 16:02:12 -0600

There are several minor changes needed based on list discussions.  There are also a few open issues.  An analysis of the requirements by 3GPP CT4 is also in progress and comments may result from that.  I've listed the open and closed issues below.  People involved in the discussions should have a look to make sure I haven't missed something.

I will update the draft with the comments that have been settled, and I can wait a bit for open issues.  We have until the 25th to submit this for consideration in Orlando.  Can the dime chairs please provide guidance on the open issues and the upcoming CT4 review, considering that WGLC has competed?

Thanks,

Eric

---Open Issues------------------

Req 2:  request to add language requiring that Diameter applications be allowed to be aware of overload situations.  There seem to still be multiple interpretations of what this means and it is not clear.  Discussion is needed.

Req 21: clarification of "proper function" needed?  new req wording proposed.  comments needed.

Req 29: removing this is proposed.  comments needed.

Req 33: proposed wording change to clarify that infinite complexity not be used.  comments needed.

Req 26: ongoing discussion on emergency services example.  conclusion needed.

---Agreed Changes----------------

Req 9:  fix "above" reference

Req 33: make extensibility for scopes MUST level

Req 33: remove requirement for session scope

Req xx: add explicit requirement for default algorithm

On Feb 7, 2013, at 3:38 , Jouni Korhonen <[email-masked]> wrote:

> _______________________________________________
> DiME mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dime

---

From: Marco Liebsch <[email-masked]>
Date: Mon, 18 Feb 2013 15:59:55 +0000

Hi Eric, all,

the DIME WG has a work item and associated draft on Diameter group signaling
to reduce in particular load in the network caused by Diameter. I propose
cross-referencing the two drafts, draft-ietf-dime-overload-reqs-03 and
draft-ietf-dime-group-signaling.

The overload requirements draft has a dedicated section 1.3 to clarify the
difference between load on Diameter nodes and network load due to
Diameter traffic. I think this is very important. What do you think about
pointing to the complementary work item and draft about bulk signaling
In Sec. 1.3?

marco

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On Behalf Of Eric
>McMurry
>Sent: Samstag, 16. Februar 2013 23:02
>To: [email-masked]
>Cc: [email-masked]
>Subject: Re: [Dime] WGLC for draft-ietf-dime-overload-reqs-03
>
>There are several minor changes needed based on list discussions.  There are
>also a few open issues.  An analysis of the requirements by 3GPP CT4 is also in
>progress and comments may result from that.  I've listed the open and closed
>issues below.  People involved in the discussions should have a look to make sure
>I haven't missed something.
>
>I will update the draft with the comments that have been settled, and I can wait
>a bit for open issues.  We have until the 25th to submit this for consideration in
>Orlando.  Can the dime chairs please provide guidance on the open issues and
>the upcoming CT4 review, considering that WGLC has competed?
>
>Thanks,
>
>Eric
>
>Req 2:  request to add language requiring that Diameter applications be allowed
>to be aware of overload situations.  There seem to still be multiple
>interpretations of what this means and it is not clear.  Discussion is needed.
>
>> The WGLC for this I-D has completed. There was a fair amount of
>> comments and I expect the authors to produce an update of the I-D. The
>> sooner the better regarding the next steps in the publication process.
>> There were few comments that seem to be still left open so those need
>> to be hashes out first. Just as a comment I am not too keen on adding
>> new requirements at this point unless there is a wide support for one
>> (wide means more than the individual who proposed it).
>>
>> - Jouni
>>
>>
>>
>>> The authors of draft-ietf-dime-overload-reqs have requested for a
>>> WGLC and I think the document is stable enough for it.
>>>

---

From: Eric McMurry <[email-masked]>
Date: Mon, 18 Feb 2013 11:31:56 -0600

Hi Marco,

Thanks for the suggestion.  I could see overload control mechanisms possibly leveraging (and referencing) this work, for example with group oriented scoping of overload information.

The requirements are not referencing any mechanisms though.  They are intended to place as few constraints on the designers of overload control mechanisms as possible, so we avoided that.

Thanks,

Eric

---

From: Marco Liebsch <[email-masked]>
Date: Tue, 19 Feb 2013 08:34:49 +0000

Hi Eric,

true, a pointer to a solution for group signaling may be misplaced in a
requirements document. I just thought about a reference to the work
that's being done in DIME, simply to not strictly scope out solving the network load
issue in 3.1. But I got your point.
Thanks,
marco

>From: Eric McMurry [mailto:[email-masked]]
>Sent: Montag, 18. Februar 2013 18:32
>To: Marco Liebsch
>Cc: [email-masked]
>Thanks for the suggestion.  I could see overload control mechanisms possibly
>leveraging (and referencing) this work, for example with group oriented scoping
>of overload information.
>
>The requirements are not referencing any mechanisms though.  They are
>intended to place as few constraints on the designers of overload control
>mechanisms as possible, so we avoided that.
>
>Thanks,
>
>Eric
>
>
>> the DIME WG has a work item and associated draft on Diameter group
>> signaling to reduce in particular load in the network caused by
>> Diameter. I propose cross-referencing the two drafts,
>> draft-ietf-dime-overload-reqs-03 and draft-ietf-dime-group-signaling.
>>
>> The overload requirements draft has a dedicated section 1.3 to clarify
>> the difference between load on Diameter nodes and network load due to
>> Diameter traffic. I think this is very important. What do you think
>> about pointing to the complementary work item and draft about bulk
>> signaling In Sec. 1.3?
>>
>> marco
>>
>>
>>> From: [email-masked] [mailto:[email-masked]] On Behalf
>>> Of Eric McMurry
>>> There are several minor changes needed based on list discussions.
>>> There are also a few open issues.  An analysis of the requirements by
>>> 3GPP CT4 is also in progress and comments may result from that.  I've
>>> listed the open and closed issues below.  People involved in the
>>> discussions should have a look to make sure I haven't missed something.
>>>
>>> I will update the draft with the comments that have been settled, and
>>> I can wait a bit for open issues.  We have until the 25th to submit
>>> this for consideration in Orlando.  Can the dime chairs please
>>> provide guidance on the open issues and the upcoming CT4 review,
>considering that WGLC has competed?
>>>
>>> Thanks,
>>>
>>> Eric
>>>
>>> Req 2:  request to add language requiring that Diameter applications
>>> be allowed to be aware of overload situations.  There seem to still
>>> be multiple interpretations of what this means and it is not clear.  Discussion
>is needed.
>>>
>>> Req 21: clarification of "proper function" needed?  new req wording
>proposed.
>>> comments needed.
>>>
>>> Req 33: proposed wording change to clarify that infinite complexity not be
>used.
>>> comments needed.
>>>
>>>> comments and I expect the authors to produce an update of the I-D.
>>>> The sooner the better regarding the next steps in the publication process.
>>>> There were few comments that seem to be still left open so those
>>>> need to be hashes out first. Just as a comment I am not too keen on
>>>> adding new requirements at this point unless there is a wide support
>>>> for one (wide means more than the individual who proposed it).
>>>>
>>>> - Jouni
>>>>
>>>>
>>>>
>>>>> mailing list and if you think something needs to be changed, put
>>>>> that also into the Issue Tracker.
>>>>>
>>>>> - Jouni & Lionel
>>>>>
>>>>>
>>>>>
>>>>