Re: [sip-overload] draft minutes IETF83

[Volker Hilt <[e-mail]>]

Vijay,
>>
>> 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?
>
This discussion is specific to the mechanism proposed in this draft and 
it was felt that it is better to keep it there.

> 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.
>
Works fine for me.

Thanks,

Volker [as individual]