Subject: [sip-overload] draft minutes IETF83

From: Salvatore Loreto <[email-masked]>
Date: Sat, 21 Apr 2012 22:02:34 +0300

Hi there,

I have just uploaded the draft of the minutes for the SoC session at 
IETF83 in Paris.

Here the link:
http://www.ietf.org/proceedings/83/minutes/minutes-83-soc.txt

please review it and eventually send your comments.

best regards
Salvatore

-- 
Salvatore Loreto, PhD
www.sloreto.com

---

From: "Ravindran, Parthasarathi" <[email-masked]>
Date: Sun, 22 Apr 2012 01:21:46 +0000

Salvatore,

I have provided the comment on ietf-soc-overload-control-08 that subscribe/notify mechanism mentioned in the draft has to updated with proper detail mechanism or the section to be removed and Vijay agrees to update the draft with the proper text in the next revision. Please update in the minutes.

Thanks
Partha

>-----Original Message-----
>From: [email-masked] [mailto:sip-overload-
>[email-masked]] On Behalf Of Salvatore Loreto
>Sent: Sunday, April 22, 2012 12:33 AM
>To: [email-masked]
>Cc: Volker Hilt
>Subject: [sip-overload] draft minutes IETF83
>
>Hi there,
>
>_______________________________________________
>sip-overload mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/sip-overload

---

From: Salvatore Loreto <[email-masked]>
Date: Sun, 22 Apr 2012 19:28:51 +0300

Hi Partha,

I have updated the minutes to include your comments

thanks a lot for reviewing the minutes

cheers
Salvatore

-- 
Salvatore Loreto, PhD
www.sloreto.com

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Mon, 23 Apr 2012 10:05:44 -0500

On 04/21/2012 08:21 PM, Ravindran, Parthasarathi wrote:
> Salvatore,
>
> I have provided the comment on ietf-soc-overload-control-08 that
> subscribe/notify mechanism mentioned in the draft has to updated with
> proper detail mechanism or the section to be removed and Vijay agrees
> to update the draft with the proper text in the next revision. Please
> update in the minutes.

Partha: I promised to get back to the list with proposed modifications
to S9.1.2 based on your feedback at the mic during the meeting.  So,
here goes.

I believe you are pointing out an incongruity in the text in S9, which
discusses two alternatives to providing overload control --- one is by
sending the feedback in the Via header (the chosen means) and the second
is through a subs/not event package.  The incongruity occurs because the
phrasing of the text in the subs/not alternative appears to imply that
subs/not is supported mechanism as well, which clearly it is not.

To remedy this, I propose that we simply remove Section 9 in its 
entirety.  The justification for choosing the Via header is already
provided in Section 3, as such Section 9 does not contribute much.
The subs/not package is used in a different scenario (as described
by Shen et al. [1]).  Having the discussion on subs/not in the
overload-control document may simply be distracting.

Let me know if that is okay with you and I will remove Section 9 in
the next revision.

[1] 
http://datatracker.ietf.org/doc/draft-ietf-soc-load-control-event-package/

Thanks,

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg@{bell-labs.com,acm.org} / [email-masked]
Web:   http://ect.bell-labs.com/who/vkg/

---

From: <[email-masked]>
Date: Mon, 23 Apr 2012 17:16:21 +0200

I support removing Section 9. I think I made this comment on the list in 2010 actually.
BC

> -----Message d'origine-----
> De : [email-masked] [mailto:sip-overload-
> [email-masked]] De la part de Vijay K. Gurbani
> Envoyé : lundi 23 avril 2012 17:06
> À : Ravindran, Parthasarathi
> Cc : [email-masked]
> Objet : Re: [sip-overload] draft minutes IETF83
>

---

From: Volker Hilt <[email-masked]>
Date: Mon, 23 Apr 2012 17:20:10 +0200

Vijay, Partha,

I think section 9 provides useful background on the discussions that 
lead to the current solution. For this reason, it would be good to keep 
this section in the draft.

Section 9 does not refer to a specific event packet. Rather, explains 
general design considerations. I'd suggest the following change to 
Section 9.1 to point this out more clearly.

9.1.  SIP Mechanism

    A SIP mechanism is needed to convey overload feedback from the
    receiving to the sending SIP entity.  Developing his feedback 
mechanisms involves a number of fundamental design choices that are 
discussed in this section.

Thanks,

Volker

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Mon, 23 Apr 2012 10:49:32 -0500

On 04/23/2012 10:20 AM, Volker Hilt wrote:
> general design considerations.

Volker: Indeed, I thought of that as well.  But then, I wonder why we
did not put this in rfc6357?

Regardless, if it is desirable to maintain this section, then I'd be a
bit more pro-active in the wording to make sure there is no ambiguity.
Something along these lines is what I would suggest if we want to
maintain S9:

OLD:
9.1. SIP Mechanism

    A SIP mechanism is needed to convey overload feedback from the
    receiving to the sending SIP entity.  A number of different
    alternatives exist to implement such a mechanism.

NEW:
9.1. SIP Mechanism

    A SIP mechanism is needed to convey overload feedback from the
    receiving to the sending SIP entity.  Different alternatives exist
    to implement such a mechanism, and the fundamental design choices
    related to each are discussed below.  This document uses the SIP
    response headers (Section 9.1.1) to achieve overload control;
    the design choices related to SIP event package (Section 9.1.2) are
    provided for the sake of completeness.

Thanks,

- vijay

---

From: Volker Hilt <[email-masked]>
Date: Mon, 23 Apr 2012 17:50:40 +0200

Vijay,
> did not put this in rfc6357?
This discussion is specific to the mechanism proposed in this draft and 
it was felt that it is better to keep it there.

>      provided for the sake of completeness.
Works fine for me.

Thanks,

Volker [as individual]

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Mon, 23 Apr 2012 11:33:31 -0500

> it was felt that it is better to keep it there.

Hmmm ... OK.

>> provided for the sake of completeness.

Unless someone objects to this, I will update the draft as outlined
above.

Thanks,

- vijay

---

From: "Ravindran, Parthasarathi" <[email-masked]>
Date: Tue, 24 Apr 2012 01:04:18 +0000

Vijay,

It will be good idea to remove Sec 9 from this draft in the next revision. I agree with your proposal.

Thanks
Partha

>From: [email-masked] [mailto:[email-masked]]
>Sent: Monday, April 23, 2012 8:46 PM
>To: [email-masked]; Ravindran, Parthasarathi
>Cc: [email-masked]
>Subject: RE: [sip-overload] draft minutes IETF83
>
>> [email-masked]] De la part de Vijay K. Gurbani Envoyé : lundi 23
>> avril 2012 17:06 À : Ravindran, Parthasarathi Cc :
>> [email-masked] Objet : Re: [sip-overload] draft minutes IETF83
>>
>> > subscribe/notify mechanism mentioned in the draft has to updated
>> > with proper detail mechanism or the section to be removed and Vijay
>> > agrees to update the draft with the proper text in the next
>> > revision. Please update in the minutes.
>>
>> sending the feedback in the Via header (the chosen means) and the
>> second is through a subs/not event package.  The incongruity occurs
>> because the phrasing of the text in the subs/not alternative appears
>> to imply that subs/not is supported mechanism as well, which clearly
>> it is not.
>>
>> The subs/not package is used in a different scenario (as described by
>> Shen et al. [1]).  Having the discussion on subs/not in the

---

From: "Ravindran, Parthasarathi" <[email-masked]>
Date: Tue, 24 Apr 2012 01:24:07 +0000

Vijay/Volker,

I'm reading this mail after replied to your initial proposal as this mail is not in my "To me" folder :-)

I have difference of opinion about the content of sub/not in Sec 9 as it is not fully analyzed after deep-dive into "OC" parameters in "via" header based mechanism. My opinion comes from the Session Initiation Protocol (SIP) Resource availability Event package draft (http://tools.ietf.org/html/draft-partha-soc-overload-resource-availability-00).  I personally feel that it is not worthy to discuss about SUB/NOT mechanism's merits/demerits within this draft at this moment. In case you wish to discuss, I'll continue the merit/demerit as part of this mail thread.

Thanks
Partha

>[email-masked]] On Behalf Of Vijay K. Gurbani
>Sent: Monday, April 23, 2012 10:04 PM
>To: Volker Hilt
>Subject: Re: [sip-overload] draft minutes IETF83
>
>> This discussion is specific to the mechanism proposed in this draft
>> and it was felt that it is better to keep it there.
>
>Hmmm ... OK.
>
>>> OLD:
>>> 9.1. SIP Mechanism
>>>
>>> receiving to the sending SIP entity. Different alternatives exist to
>>> implement such a mechanism, and the fundamental design choices
>>> response headers (Section 9.1.1) to achieve overload control; the
>>> design choices related to SIP event package (Section 9.1.2) are

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Tue, 24 Apr 2012 16:20:26 -0500

On 04/23/2012 08:24 PM, Ravindran, Parthasarathi wrote:
> I have difference of opinion about the content of sub/not in Sec 9 as
> it is not fully analyzed after deep-dive into "OC" parameters in
> "via" header based mechanism. My opinion comes from the Session
> Initiation Protocol (SIP) Resource availability Event package draft
> (http://tools.ietf.org/html/draft-partha-soc-overload-resource-availability-00).
> I personally feel that it is not worthy to discuss about SUB/NOT
> mechanism's merits/demerits within this draft at this moment. In case
> you wish to discuss, I'll continue the merit/demerit as part of this
> mail thread.

Initially, I was of the opinion that removing S9 may be the expedient
way forward, as my earlier email [1] indicated.  However, Volker has
made a case that we should maintain S9 as background information to
demonstrate the discussions that lead to the choice of the current
solution.

Having been through a rather brutal IESG review of sipclf where similar
justification was asked for, I am sympathetic to providing background
information precisely for the purpose of completeness.

I gather that you would rather see S9 excised completely.

We have to converge at a middle point somewhere.

If you are not comfortable with the suggested text of [2], then can I
kindly ask you to read S9.1.2 and send me some suggested text that gets
your point across?  I will be more than happy to put that into the
draft and move forward.

Please send me the text at your earliest convenience (or post on the
list) and we can iterate through it to include it in the next
revision.

[1] http://www.ietf.org/mail-archive/web/sip-overload/current/msg00773.html
[2] http://www.ietf.org/mail-archive/web/sip-overload/current/msg00778.html

Thanks,

- vijay