Return-Path: 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 ; 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 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 25 Nov 2013 01:39:44 -0800 (PST) Sender: Charles Newyork 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" To: "Dan (Dan) Romascanu" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Nov 2013 09:39:48 -0000 ------Nodemailer-0.5.0-?=_1-1385372384007 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable That's great, I will keep it as in the current 11 version then. Again thank= you so much for the careful review! Charles=20 =E2=80=94 Sent from Mailbox for iPhone On =E5=91=A8=E4=B8=80, 11=E6=9C=88 25, 2013 at 5:32 =E4=B8=8B=E5=8D=88, = Romascanu, Dan (Dan) > wrote: Hi Charles, =C2=A0 No, this is not a strong comment. Actually all my comments were listed as = =E2=80=98minor=E2=80=99 thus non-blocking vs. a document I appreciate as of= good quality. Thank you for the dialog and for considering my comments.=20 =C2=A0 Regards, =C2=A0 Dan =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 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-1= 0.txt =C2=A0 Hi Dan, =C2=A0 On Mon, Nov 25, 2013 at 1:09 AM, Romascanu, Dan (Dan) = wrote: Also, in the same list of requirements I miss an explicit requirement on = persistency. =C2=A0 =C2=A0 This part I am not sure if I understand clearly, could you please elaborate= a bit=3F=C2=A0 =C2=A0 =C2=A0[[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=3F =C2=A0 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: =C2=A0 Key to this is the fact that following initial =C2=A0=C2=A0 subscription, the notifier sends a notification without a body= if no =C2=A0=C2=A0 load filtering policy is defined (Section 6.7), and that the =C2=A0=C2=A0 subscription needs to be refreshed periodically to make it =C2=A0=C2=A0 persistent, as described in Section 4.1 and Section=C2=A04.2 = of [RFC6665]. =C2=A0 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= .=C2=A0 =C2=A0 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. =C2=A0 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! =C2=A0 Charles ------Nodemailer-0.5.0-?=_1-1385372384007 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

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=3D=22mailto:dromasca@avay= a.com=22>> 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=3F

[[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=3F

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

------Nodemailer-0.5.0-?=_1-1385372384007--