Re: [sip-overload] draft minutes IETF83

["Vijay K. Gurbani" <[e-mail]>]

On 04/23/2012 10:20 AM, Volker Hilt wrote:
> 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.

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
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg@{bell-labs.com,acm.org} / [e-mail]
Web:   http://ect.bell-labs.com/who/vkg/