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)
<droma...@avaya.com="mailto:droma...@avaya.com";>> 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: charles.newy...@gmail.com [mailto:charles.newy...@gmail.com]
On Behalf Of Charles Shen
Sent: Monday, November 25, 2013 11:06 AM
To: Romascanu, Dan (Dan)
Cc: gen-art@ietf.org;
draft-ietf-soc-load-control-event-package....@tools.ietf.org;
sip-overl...@ietf.org
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) <droma...@avaya.com>
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
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
