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 protected]> 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 protected]="mailto:[email protected]";>> 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 protected] [mailto:[email protected]] On Behalf > Of Charles Shen > Sent: Monday, November 25, 2013 11:06 AM > To: Romascanu, Dan (Dan) > Cc: [email protected]; > [email protected]; > [email protected] > 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 protected]> > 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 protected] > https://www.ietf.org/mailman/listinfo/gen-art _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
