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

"charles newyork" <qs2005@columbia.edu> Mon, 25 November 2013 09:39 UTC

Return-Path: <charles.newyork@gmail.com>
X-Original-To: sip-overload@ietfa.amsl.com
Delivered-To: sip-overload@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60C531AD66E; Mon, 25 Nov 2013 01:39:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5m0qEFD9WSQk; Mon, 25 Nov 2013 01:39:44 -0800 (PST)
Received: from mail-qa0-x22c.google.com (mail-qa0-x22c.google.com [IPv6:2607:f8b0:400d:c00::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 82A3F1ACCDF; Mon, 25 Nov 2013 01:39:44 -0800 (PST)
Received: by mail-qa0-f44.google.com with SMTP id i13so2804230qae.10 for <multiple recipients>; Mon, 25 Nov 2013 01:39:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:mime-version:date:message-id:in-reply-to:references:from:to :cc:subject:content-type; bh=dFJvV4rv2lha/c3tYgAaeSYEiR6e2Uj+EZN5ta2dL4c=; b=sdd4vI7ud2ZR0xSKBBfT8xhUDIUTIuMtWv8Bnx7boBSE3VxTvfrz0+kfPmnuyc3tRc JkmrUiK11ne9eTBGIlA3NzcKQrNHCLusoIg0tTV87Y/F2PolHgnTGznA/ckhK/G9TC/3 jlKnYHEnJ4PNtwLYp7wcnFny1FaISmO5rLknYyqWRHAnbjpa1g7WBM8VzYfhEL9zmznD NRkJPeSIwtYHBLy87lZJyZIFyL3aKXe+aPIDx2a64EfVa639CLQtIHAhtwpBJledXo2t XJQ0NgbPtUqn1yzJIRs7tKMPNU0PZdGzEImT1cHBjr8A61qy4odNB7kKQiUxLWsRNtKk TsqA==
X-Received: by 10.229.101.74 with SMTP id b10mr43775072qco.8.1385372384611; Mon, 25 Nov 2013 01:39:44 -0800 (PST)
Received: from [127.0.0.1] (ec2-54-235-159-165.compute-1.amazonaws.com. [54.235.159.165]) by mx.google.com with ESMTPSA id a9sm112856719qed.6.2013.11.25.01.39.43 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 25 Nov 2013 01:39:44 -0800 (PST)
Sender: Charles Newyork <charles.newyork@gmail.com>
MIME-Version: 1.0
X-Mailer: Nodemailer (0.5.0; +http://www.nodemailer.com/)
Date: Mon, 25 Nov 2013 01:39:44 -0800 (PST)
Message-Id: <1385372383632.075e6c61@Nodemailer>
In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA129486F7@AZ-FFEXMB04.global.avaya.com>
References: <9904FB1B0159DA42B0B887B7FA8119CA129486F7@AZ-FFEXMB04.global.avaya.com>
X-Orchestra-Oid: 0F8280C0-452D-4087-B782-64F773D5C3CE
X-Orchestra-Sig: 65460c6d5fc9a7d02991d1d63b47d93495acc374
X-Orchestra-Thrid: T99E1D951-B6E2-4D22-9956-867CFD5FBE91_1452143342138422648
X-Orchestra-Thrid-Sig: b38a9318078230b48c1c0d3e0a23c29f296e7d0f
X-Orchestra-Account: da7bf23ac1b135494c30f019d454d69698f5dd5d
From: "charles newyork" <qs2005@columbia.edu>
To: "Dan (Dan) Romascanu" <dromasca@avaya.com>
Content-Type: multipart/alternative; boundary="----Nodemailer-0.5.0-?=_1-1385372384007"
Cc: gen-art@ietf.org, sip-overload@ietf.org, draft-ietf-soc-load-control-event-package.all@tools.ietf.org
Subject: Re: [sip-overload] Gen-ART review for draft-ietf-soc-load-control-event-package-10.txt
X-BeenThere: sip-overload@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: SIP Overload <sip-overload.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sip-overload>, <mailto:sip-overload-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sip-overload/>
List-Post: <mailto:sip-overload@ietf.org>
List-Help: <mailto:sip-overload-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sip-overload>, <mailto:sip-overload-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 25 Nov 2013 09:39:48 -0000

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) <dromasca@avaya.com="mailto:dromasca@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.newyork@gmail.com [mailto:charles.newyork@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.all@tools.ietf.org; sip-overload@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) <dromasca@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