Re: [sip-overload] Gen-ART review for draft-ietf-soc-load-control-event-package-10.txt

[Charles Shen <[e-mail]>]

Hi Dan,

On Mon, Nov 25, 2013 at 1:09 AM, Romascanu, Dan (Dan) <[e-mail]>wrote:

>
>
> Also, in the same list of requirements I miss an explicit requirement on
> persistency.
>
>
>
>
>
> This part I am not sure if I understand clearly, could you please
> elaborate a bit?
>
>
>
>  *[[DR]] *In section 5.3, second paragraph there are a couple of
> references to the persistency of subscriptions of neighboring SIP entities
> and periodic refresh. Should not this be mentioned explicitly in the list
> in Section 4?
>

I see what you mean. In fact I tend to think of this as one of those
micro-aspects that have been covered by existing macro-clauses.
Specifically, as Section 5.3 says:

 Key to this is the fact that following initial
   subscription, the notifier sends a notification without a body if no
   load filtering policy is defined (Section 6.7
<http://tools.ietf.org/html/draft-ietf-soc-load-control-event-package-11#section-6.7>),
and that the
   subscription needs to be refreshed periodically to make it
   persistent, as described in Section 4.1
<http://tools.ietf.org/html/draft-ietf-soc-load-control-event-package-11#section-4.1>
and Section 4.2 of [RFC6665]
<http://tools.ietf.org/html/rfc6665#section-4.2>.


The behavior of notifier sending a notification following initial
subscription is mandated in Section 6.7 of this document. And the behavior
of periodic refresh is specified in Section 4.1 and Section 4.2 of RFC
6665.

Both this document and RFC 6665 have already been explicitly listed in
Section 4 of this document. So they seem to have covered the persistency
issue.

That said, I am open to add another explicit clause for this aspect if you
really feel strongly about it. Please let me know. Thanks again!

Charles