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

From: Jari Arkko <[email-masked]>
Date: Tue, 3 Dec 2013 07:50:19 +0200

Thank you Dan for the review and Charles for addressing the concerns. I have placed a no-obj position for this document on this week's IESG telechat.

Jari

On Nov 25, 2013, at 11:39 AM, charles newyork <[email-masked]> wrote:

> That's great, I will keep it as in the current 11 version then. Again thank you so much for the careful review!
> 
> 
> 
> Charles 
> 
> —
> Sent from Mailbox for iPhone
> 
> On 周一, 11月 25, 2013 at 5:32 下午, Romascanu, Dan (Dan) <[email-masked]="mailto:[email-masked]">> wrote:
> Hi Charles,
> 
> 
> 
> 
>  
> 
> No, this is not a strong comment. Actually all my comments were listed as ‘minor’ thus non-blocking vs. a document I appreciate as of good quality. Thank you for the dialog and for considering my comments.
> 
> 
> 
> 
>  
> 
> Regards,
> 
> 
> 
> 
>  
> 
> Dan
> 
> 
> 
> 
>  
> 
> 
>  
> 
> 
>  
> 
> 
>  
> 
> 
>  
> 
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Charles Shen
> Sent: Monday, November 25, 2013 11:06 AM
> To: Romascanu, Dan (Dan)
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: Gen-ART review for draft-ietf-soc-load-control-event-package-10.txt
> 
> 
> 
> 
>  
> Hi Dan,
> 
> 
> 
>  
> On Mon, Nov 25, 2013 at 1:09 AM, Romascanu, Dan (Dan) <[email-masked]> 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), and that the
> 
>    subscription needs to be refreshed periodically to make it
> 
>    persistent, as described in Section 4.1 and Section 4.2 of [RFC6665].
> 
>  
> 
> 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 
> 
> 
> 
>  
> 
>  
> 
>  
> _______________________________________________
> Gen-art mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/gen-art