From cs4303@att.com Mon Nov 7 11:24:18 2011 Return-Path: X-Original-To: sip-overload@ietfa.amsl.com Delivered-To: sip-overload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE5B511E80A0 for ; Mon, 7 Nov 2011 11:24:18 -0800 (PST) X-Quarantine-ID: <1D0jhwYVlzwd> X-Amavis-Modified: Mail body modified (defanged) by ietfa.amsl.com X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BANNED, message contains part: multipart/mixed | application/ms-tnef,.tnef,winmail.dat X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1D0jhwYVlzwd for ; Mon, 7 Nov 2011 11:24:17 -0800 (PST) Content-Type: multipart/mixed; boundary="----------=_1320693858-26395-0" Content-Transfer-Encoding: binary MIME-Version: 1.0 Received: from mail120.messagelabs.com (mail120.messagelabs.com [216.82.250.83]) by ietfa.amsl.com (Postfix) with ESMTP id B9D8421F8573 for ; Mon, 7 Nov 2011 11:24:17 -0800 (PST) Received: (qmail 17076 invoked from network); 7 Nov 2011 19:24:16 -0000 Received: from sbcsmtp6.sbc.com (HELO mlpd192.enaf.sfdc.sbc.com) (144.160.20.145) by server-12.tower-120.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 7 Nov 2011 19:24:16 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id pA7JNgbn022502 for ; Mon, 7 Nov 2011 14:23:43 -0500 Received: from MISOUT7MSGHUB9C.ITServices.sbc.com (misout7msghub9c.itservices.sbc.com [144.151.223.82]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id pA7JNfCd022495 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 7 Nov 2011 14:23:41 -0500 Received: from MISOUT7MSGUSR9A.ITServices.sbc.com ([169.254.1.121]) by MISOUT7MSGHUB9C.ITServices.sbc.com ([144.151.223.82]) with mapi id 14.01.0339.001; Mon, 7 Nov 2011 14:23:13 -0500 From: "SHEN, CHARLES" To: Shida Schubert Date: Mon, 7 Nov 2011 19:23:12 +0000 Message-ID: <9EC99DA9F107DF4A8AD7B332FB5FC5CD016280FD@MISOUT7MSGUSR9A.ITServices.sbc.com> References: <15724199-7C27-4577-ADB3-3CB8A484C030@ntt-at.com> In-Reply-To: <15724199-7C27-4577-ADB3-3CB8A484C030@ntt-at.com> Cc: "sip-overload@ietf.org" , Arata Koike , Henning Schulzrinne Subject: Re: [sip-overload] Comments on draft-ietf-soc-load-control-event-package-01 X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2011 19:24:18 -0000 This is a multi-part message in MIME format... ------------=_1320693858-26395-0 Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 7bit WARNING: contains banned part ------------=_1320693858-26395-0 Content-Type: message/rfc822; x-spam-type=original; name="message" Content-Disposition: attachment; filename="message" Content-Transfer-Encoding: 7bit Content-Description: Original message Return-Path: Received: from mail120.messagelabs.com (mail120.messagelabs.com [216.82.250.83]) by ietfa.amsl.com (Postfix) with ESMTP id B9D8421F8573 for ; Mon, 7 Nov 2011 11:24:17 -0800 (PST) X-Env-Sender: cs4303@att.com X-Msg-Ref: server-12.tower-120.messagelabs.com!1320693855!48103613!1 X-Originating-IP: [144.160.20.145] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17076 invoked from network); 7 Nov 2011 19:24:16 -0000 Received: from sbcsmtp6.sbc.com (HELO mlpd192.enaf.sfdc.sbc.com) (144.160.20.145) by server-12.tower-120.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 7 Nov 2011 19:24:16 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id pA7JNgbn022502 for ; Mon, 7 Nov 2011 14:23:43 -0500 Received: from MISOUT7MSGHUB9C.ITServices.sbc.com (misout7msghub9c.itservices.sbc.com [144.151.223.82]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id pA7JNfCd022495 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 7 Nov 2011 14:23:41 -0500 Received: from MISOUT7MSGUSR9A.ITServices.sbc.com ([169.254.1.121]) by MISOUT7MSGHUB9C.ITServices.sbc.com ([144.151.223.82]) with mapi id 14.01.0339.001; Mon, 7 Nov 2011 14:23:13 -0500 Content-Type: multipart/mixed; boundary="_000_9EC99DA9F107DF4A8AD7B332FB5FC5CD016280FDMISOUT7MSGUSR9A_" From: "SHEN, CHARLES" To: Shida Schubert CC: "sip-overload@ietf.org" , Arata Koike , Henning Schulzrinne Subject: RE: [sip-overload] Comments on draft-ietf-soc-load-control-event-package-01 Thread-Topic: [sip-overload] Comments on draft-ietf-soc-load-control-event-package-01 Thread-Index: AQHMnYKx00yRjKeN5UGh4XXPiWx5UQ== Date: Mon, 7 Nov 2011 19:23:12 +0000 Message-ID: <9EC99DA9F107DF4A8AD7B332FB5FC5CD016280FD@MISOUT7MSGUSR9A.ITServices.sbc.com> References: <15724199-7C27-4577-ADB3-3CB8A484C030@ntt-at.com> In-Reply-To: <15724199-7C27-4577-ADB3-3CB8A484C030@ntt-at.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: <9EC99DA9F107DF4A8AD7B332FB5FC5CD016280FD@MISOUT7MSGUSR9A.ITServices.sbc.com> x-originating-ip: [151.109.8.243] MIME-Version: 1.0 --_000_9EC99DA9F107DF4A8AD7B332FB5FC5CD016280FDMISOUT7MSGUSR9A_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Shida, Thank you very much for your review and I apologize for the late reply. Ple= ase find my comments inline.=20 > -----Original Message----- > From: sip-overload-bounces@ietf.org [mailto:sip-overload- > bounces@ietf.org] On Behalf Of Shida Schubert > Sent: Monday, October 03, 2011 10:48 AM > To: sip-overload@ietf.org > Subject: [sip-overload] Comments on draft-ietf-soc-load-control-event- > package-01 >=20 >=20 > I recently reviewed the draft and below are some comments. >=20 > A: Terminology >=20 > First of all, I find that the document is rather hard to read > because; 1. it uses different terminology for what I believe is > the same thing. 2. introduce many terminology that > is not defined anywhere and 3. the terminology used should > probably be aligned with that of the other drafts > that define some of these terminologies (RFC6537 etc). We can look at those terms you referred to and improve as appropriate. But = I could not find RFC6537, is it a typo or can you provide a link?=20 >=20 > Here are some examples; >=20 > 1. "load control" - should this be "overload control"? The reason for using load control instead of overload control is that the m= echanism is more generically applicable. Although the motivation is driven = by overload control, it could also be used for load control purely determin= ed by QoS/service level agreements, for example. I am open to either terms = depending on what the majority thinks.=20 > 2. What is "user load control information"? Load control information is associated with user's identities, e.g., phone = numbers, SIP addresses, which is mentioned in the abstract. But I can remov= e the word "user" there if that sounds clearer to you.=20 > 3. "edge server" - edge of what? At the edge of domain? SIP servers in the edge networks (as opposed to SIP servers in the core net= works), would that sound better or do you have other suggestions?=20 > 4. load document, load control document and load filter, are they the > same thing? Load document probably should be load control document. A load control docu= ment is (specifically) an XML document that inherits and enhances the commo= n policy document defined in RFC4745 (Sec. 6.1). Load filter is a more gene= ric term associated with the (filtering) mechanism. Any suggestion? =20 > 5. load filtering mechanism and load filter control the same thing? They are, and they should probably be consolidated. > 6. What is a dynamic filter? Meaning the filtering contents are dynamically computed based on current ne= twork status. This is mentioned in Section 4.2 but could be made more expli= cit. =20 > 7. What is a load control policy maker? The party that determines the policy for load control.=20 > 8. What is a policy entry point? The entity through which the policy is first injected (into the network). = =20 > 9. What is a filter computation decision maker? The party which determines the filter contents (e.g., through some algorith= m).=20 > 10. Is load control policy, load control information and load control > rule the same thing? I consider policy a type of information expressed in a set of rules here. I= am open to the possibility of consolidating these terms if the meaning is = clear. =20 > 11. What is load control filter content definition? >=20 Load control filter content refers to the set of rules (including condition= s and actions) specified for the filtering. =20 > Also some terminology can be changed to common terminology used in SIP > related RFCs >=20 > e.g. SIP entity subscribers > SIP subscribers or subscribers > e.g. local format/global format > local number / global number > [RFC3966] >=20 > I can change them accordingly. =20 =20 > B: Requirements >=20 > The draft does a really nice job evaluating whether the > document meets the requirements set forth by RFC 5390 in > section section 9. but the draft also has design requirements > in section 3. This seems reasonable thing to have but shouldn't > these requirements expressed with RFC2119 language? >=20 I can do that.=20 >=20 > C: Behavior of Notifier and Subscriber is mixed in section 5.6 > - I think followings should be described as Subscribers' behavior. >=20 > "SIP entity subscribers SHOULD try to subscribe to all those SIP entity > notifiers with which they have regular signaling exchanges, although > not all such SIP notifiers may permit such a subscription" >=20 I will move that sentence as suggested. > D: Technical questions >=20 > 1. section 5.7. > - "Following the [RFC3265] specification, a notifier MUST send a > NOTIFY > with its current load control policy to the subscriber upon > successfully accepting or refreshing a subscription. The NOTIFY > request MAY include a body. " >=20 > - So it says MUST send a NOTIFY but it is followed by MAY include a > body. > If load control policy is carried in a body, I don't know there is > a MAY following > the first paragraph. >=20 > - If what you want to say is to include the control policy in the > body when > there is an active policy to be MUST and otherwise a MAY, this > should be > clarified. >=20 > 2. section 5.8. > - "Upon receipt of a NOTIFY request with a Subscription-State header > field containing the value "terminated", the subscriber MUST remove > all previously received load control information and process all > calls without applying any restriction" >=20 > - This should be clarified that this applies only to the relevant > filter and > not to all the policy that may be active at the time of receiving > this NOTIFY. >=20 You are right in both. I will add clarification accordingly.=20 Thanks again. Charles > Regards > Shida >=20 >=20 > _______________________________________________ > sip-overload mailing list > sip-overload@ietf.org > https://www.ietf.org/mailman/listinfo/sip-overload --_000_9EC99DA9F107DF4A8AD7B332FB5FC5CD016280FDMISOUT7MSGUSR9A_ Content-Disposition: attachment; filename="winmail.dat" Content-Transfer-Encoding: base64 Content-Type: application/ms-tnef; name="winmail.dat" eJ8+IlAbAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEJgAEAIQAAADYxMEE2NTgx MDA5NTZBNDA5RkZDMDZCM0Y0NEVFNjlEACMHAQ2ABAACAAAAAgACAAEFgAMADgAAANsHCwAHABMA FwAMAAEAKwEBIIADAA4AAADbBwsABwATABcADAABACsBAQiABwAYAAAASVBNLk1pY3Jvc29mdCBN YWlsLk5vdGUAMQgBBIABAEwAAABSRTogW3NpcC1vdmVybG9hZF0gQ29tbWVudHMgb24gZHJhZnQt aWV0Zi1zb2MtbG9hZC1jb250cm9sLWV2ZW50LXBhY2thZ2UtMDEAKhsBA5AGADgbAABOAAAAAgF/ AAEAAABOAAAAPDlFQzk5REE5RjEwN0RGNEE4QUQ3QjMzMkZCNUZDNUNEMDE2MjgwRkRATUlTT1VU N01TR1VTUjlBLklUU2VydmljZXMuc2JjLmNvbT4AAAALAB8OAQAAAAIBCRABAAAAUw0AAE8NAACt GwAATFpGdQkZMF1hAApmYmlkBAAAY2PAcGcxMjUyAP4DQ/B0ZXh0AfcCpAPjAgAEY2gKwHNldDAg 7wdtAoMAUBFNMgqABrQCgJZ9CoAIyDsJYjE5DsC/CcMWcgoyFnECgBViKgmwcwnwBJBhdAWyDlAD YHOibwGAIEV4EcFuGDBdBlJ2BJAXtgIQcgDAdH0IUG4aMRAgBcAFoBtkZJogA1IgECIXslx2CJDk d2sLgGQ1HVME8AdADRdwMApxF/Jia21rBnMBkAAgIEJNX0LgRUdJTn0K/AHxC/EoIEhpBgBoDdBh LLRcbAuAZQqBIkRUGaEoayB5CGAgGjF5IPxtdRHAHHAFsSNxBcAJcK0dYiAAcBxgSSVAcAjxmGdp ehngJFJ0aBngDwtgECAk0QtQeS4gUP0ecGESABxwHbEj8CPgBaD+bQeAAjAEIAuAIkIncCI8aD4g LSqSTwUQJgBu5wdABdAHkHNhGDAqkyoHEkYDYTogAJBwLW8jGjEJAGFkLQbgdW5aYweQQAiQADAu BbBn3CBbAMADEBiQOi0rKgeRLf5dIE8DoEJlEdB8bGYx8DKAIdMGABHAdb5iG4EqBwZgAjAtAE0C IGkiAHksMfBjGJAzcSCMMDM1AAHQMTEgHpBAOjQ4IEFNKgdU3y9gLRsuZzO4M2BqBZA0cT5bLSox 4AhQKKUCICBkKxhwAYAtLnItGSBjLcstoxvhdANgbC0k8CjB8ywoCrBjayuyNfAqBz7//iAlgQlw LjACMCdQJNUcUf8mkjujJUMzcAkAJTEJcC0QdwNwGeAohi4/jzaALQBUbQSQbQuAJdJ5RF9AkEae aRHwBUAZMCVAbGw1AL8lkCgDJpAYgEHkPGB1KLJ/KQAEIBhxJqAFwBHRQdFvTyTRLcAwWAWQYXUS ADv7NiAncGkFQEwhBCAN4AEg3wSQSbIboUXWJEN3SOIlkP9C0QiQGjBJ4SoHJpIroEORayaQC4Bn J3AyTIE9AmT/JBAZ4AOBI+BNykjSKgdJ8f9F8AVAAQEiURxgUkFOwE1hfSVDMydwJpJNykwhHGBz qmgIYGxLSHADYGIBoP9BMTNwSAErAFTCA/AmkEjE/0fhJpJUUEpSO6NPykjxVIQ/Q2RaJCfRTcgI kAQgKFKARkM2NTM3IBIQ7GMpREYiNVdDoQORCQD+byNQSPMZEFYkBCAjcglw/01RCXFK0iVSB3BY QU+BJ8A/JaFYQVhABzAQICdwQnX/TvIFoFeBVDMoA151NQBJ8fNMoTMQdHklwDtgG8EDkT8jcmMy DdBVcSbAC4BrP/spj0AYSFVTQ0YQMFCwC1DvB5AWIGl/TGIiLaIb0j0SviIqgFdFUOIEIFjRIi1m /W23PyI+JwInwDtxJFJMIP9REWCBbZgpAR9gSyFH0m9+/0niSNcHgBmSBAAcsEnxBGD/Q0EYMw5Q SBEj4GPBIkAeUNsCYClhQS9AV2FnWbJSEelUUGl2GIBpO3FJ8Tug/3mwCfAw0CPgb35mUQVAZPS/ B0AZIFjCVwMkUnLLcAhwP0LgI+ABAE3EHFF60VFv/FMvEgAaIA5QJrE9YQMg/yuwCdEoszUAJFJr dSdwJZHvHLBkAHqhSuFlWZEbsWF0fwEAgvEN4HKRO3FOw3XTYf5qBbBMoFMiaKFEMGjvUVL2V0ji SfEiTCF9rQuAGuT7efFwfkyI34nkSeInwDxR92QyWWWIcico8QEAAjBMoN9eITUAKWBRMDUAcFdg XHGObkmQM3GBkVNJUCVA/mQ7oCuBjvJOwA5QJDB2sv+Oko+xYvGDESahAaAfYBhwfzUwZHcDkQlw BGBPgSaSd/8FsBxgiGNuMEpCT5FaMkjx6xkgLhBkBCBjJ6EJcCZx30rwI3GGj0CQVdEiCYAZ0X+A IpWCblCZY0fhTsJo0EHvSQSaVklgLxFucI2Qgpm09yjym1gYUHSVAR9QXlBjkf9kACXAVxJK4Z1/ Q6JDQZ72/imRUW6VlnZCwQJAG7EFsd9JYCNjEdBPgVqUc3kAGDDbH2B58XNo30CQNCdwbXP/SWY1 AHLLSWclUm1zKAAvQN8EkDUAQzImkVMiZSoHUKj/il+nqVg4bnVY0ah/KLJ4kfOvz0mXKHOC8I1A KAB3k8IpJUEgWE1MSVhI0/8LgEpRTKBjoSVhCfAZoS4x/6FVKKA7cSXBDlB+4Ul2VIbDkqFecTQ3 NDVeUAZgomMncDYuMV8gIItDv6pkjMN2202zjP8mkiiqZP9REbPAdhd4kVJRpXimIKY//CA1p2W9 t3YJqd1zB1Bs/3CPq0FDMarBSKOrQW51WEr/G+EZICJAIgAcQV89QIG50POH1zMQZHkrMEXQu/Cq ZP/FXStwdlFykSaSwbg84ijD/0Myy1V3oyiBfpAcQlhwVxJ/O3FJgGJRScGe9S0QAZB0/0wgJ3Aj EGZyke25gXnjp1D+MjDQZKFk9FjRAMBoQXbjvxAweBJMoCdwwA9AkDfKmvd9zLdUAMBrzB9xcgqx hfN/XAN/JbZ0t0V9jpf/QJA4/8qat0UowSPRJcBRkdpva1H/jqJTIgNgeQKRdNz5SfEoAO9HoguA OZIcUShRkUrwJpLnnvW6Ad6/IDnKmsOH0DL/edQFgQQAefLaH9srkXTcTXvDiSjDKI8042ZDcwdA Z/mFwmhtugEpnh6QgnEEIH/Y37eAqF2MGqnXPOUqB3L/V4CUpMS/IpZk0gCBBIG3Nv9m01zTjBrW MZDzkoMzEBIBf0fS9xIEIFVCgn3c9AQQaf8NwCJAhfFH4ciozWVhR5Yj/3XyzURJ8ZcT1r/yAkxx h+b/csvuPFR0jsG/0WwOit8Fj79iBHVh5lT8q+YRlxB1hIP/G+FNIKXTJUOTYaXis8CzBf99Vc2r 5z9AgXiwfNFDc03K/2BSyHIZo0rDttVWT9PSkJD/9ohC4I1jXnFbSGyYjzKQc7fi9aVwkyBj8LCQ IiA0If+gghlJZ0EZORedQvAeUSRC+YnhL2dC8FhwHSYZ4RzkeY/0IC+7gB3Ej/Rsl1vBXnEzOTY2 XRcP+F/vYGETJCaCwtFjoaGEgidSC2yGbIhCNIBSZXF1/+UwgUQhnwLwcXJCNKRQTPG/MxBLEXey zVBSAYWwYl7g/3nADHAAVFUxg4SriUln8ED/XvC2dIEgJuj8k4HBWaF60fdeccEgIUAwc4GrqNQV MMb/6HHUwkH5fMJO0IQS/xBZMP8t21OIMSiZIdKzXVCBQEoBf3HDeFJQ5ErSpMPUwq80bn4nU3hd JC3r+7hZg15xMv0EIDmAkBNBKwC7kAdPIxsvpFFI0vEfbIhDJqBCZe+kwXnwpAFH8E55kQ6xZ1DN DZJTGUd2o2l4uJQwxv3BMDZsmJowTxCGIx4RSCD+b1mAE1Auka9HM2EZc1Th88sQQohzJ6OhQRTJ Zif5BiIYjxmUU0hPVUz+RFvQ4UGgQRk3YpNGAGEF/0qYbJgC8FRBQePLEFmD4+f/f8Ckw4EgPHAW YBshWSFZAf9ykYIAEySBkfBweNRO/U2j/6VwkaGQgk+41ZDhURRSloH3VUL8gRlEcIoDPN/41r0Q /03BlHWjIi5hhGCAcWORpXXryU9tAEQmoFTCYSoxHfH/M/CltUlvbRND+NgATvqaMF1tUEZF9oVD IQMyZhBdHw5WeEB54qrBT6cgTVUcU1RawkexbJdOT1T4SUZZTvq9E7WC0Tbyr/e3gQr2Qph1n+Aw KALxVTH5tlFzZjiwd8JrwVfxhKL/6ZAKgZDxN3NXbALhKLJmH+ct06WxZMBBWXOBDGKS8b3UsG/L UJkxXp9hNFMRgP9W4lZwyxBk2W811LN8IeTyf0Xzf4Rw618nccNO+gLwSf//sGhP5MQdANFQDsL8 U3HCT5BggpCkUDjhIGsSQHf/lbYb6MswcOJF53iczaTlQv/bkTyQKQCPkElfYSJFQZq0/aRzd5Qg MhERgVZxNiGgQf9xJqFkehySs3e7K2Jq23/T/31Ds9IN0qThaRgS8WTTDZL/pRO9EADhfiPvgn15 rzd4nN8CkFHwDqOBL1+RMl/a39D5gcsiVWqxCnG2UFfh/5I/dPdwZr0TyzBChVfzLVP/6gHwUAGw 1aEgaALxDrHHsd/eMpxRzWYq0vBQIhREFnL+IowCadtk0zpRWkFO+k2y//vRQTEVAMhBklOg4PWs 9L//x+Fr0lTiTvrPslA079Cpsfpw1lB5bbO/IW1xqPD6EP9YD0TXNgSvR45n2+SMIqFT+w7AGvFu yEHmRRZBKsEucP9fJ7qFDZF4m1SyTYeJmNwC31ZiEvGJRaXz99Fp8EELor+cw37qpiNvRI7/XyVZ gyH/zxLwsOOwtRKHAb0w/bJZ43/VoN4RjnRjpCSc625CQGutyxFnl3FcLUPcAHIL8f/rbF8oJsC2 MCTgG+nT8PgA98kQov9fGF+8f72PvlowOP1X4C1aQbeQCNLVkP9BwiEv63DSML9v3eJADsB0Zg4u 9PB/CLGwdHBzOqgvL3fEcC7C5i/AwtnVkG4vwUL0wi+/+l8lDH19X3DHwAAfAEIAAQAAABwAAABT AEgARQBOACwAIABDAEgAQQBSAEwARQBTAAAAHwBlAAEAAAAeAAAAYwBzADQAMwAwADMAQABhAHQA dAAuAGMAbwBtAAAAAAAfAGQAAQAAAAoAAABTAE0AVABQAAAAAAACAUEAAQAAAFwAAAAAAAAAgSsf pL6jEBmdbgDdAQ9UAgAAAIBTAEgARQBOACwAIABDAEgAQQBSAEwARQBTAAAAUwBNAFQAUAAAAGMA cwA0ADMAMAAzAEAAYQB0AHQALgBjAG8AbQAAAB8AAl0BAAAAHgAAAGMAcwA0ADMAMAAzAEAAYQB0 AHQALgBjAG8AbQAAAAAAHwDlXwEAAAAEAAAAIAAAAB8AGgwBAAAAHAAAAFMASABFAE4ALAAgAEMA SABBAFIATABFAFMAAAAfAB8MAQAAAB4AAABjAHMANAAzADAAMwBAAGEAdAB0AC4AYwBvAG0AAAAA AB8AHgwBAAAACgAAAFMATQBUAFAAAAAAAAIBGQwBAAAAXAAAAAAAAACBKx+kvqMQGZ1uAN0BD1QC AAAAgFMASABFAE4ALAAgAEMASABBAFIATABFAFMAAABTAE0AVABQAAAAYwBzADQAMwAwADMAQABh AHQAdAAuAGMAbwBtAAAAHwABXQEAAAAeAAAAYwBzADQAMwAwADMAQABhAHQAdAAuAGMAbwBtAAAA AAAfAPg/AQAAABwAAABTAEgARQBOACwAIABDAEgAQQBSAEwARQBTAAAAHwAjQAEAAAAeAAAAYwBz ADQAMwAwADMAQABhAHQAdAAuAGMAbwBtAAAAAAAfACJAAQAAAAoAAABTAE0AVABQAAAAAAACAfk/ AQAAAFwAAAAAAAAAgSsfpL6jEBmdbgDdAQ9UAgAAAIBTAEgARQBOACwAIABDAEgAQQBSAEwARQBT AAAAUwBNAFQAUAAAAGMAcwA0ADMAMAAzAEAAYQB0AHQALgBjAG8AbQAAAB8ACV0BAAAAHgAAAGMA cwA0ADMAMAAzAEAAYQB0AHQALgBjAG8AbQAAAAAACwBAOgEAAAAfABoAAQAAABIAAABJAFAATQAu AE4AbwB0AGUAAAAAAAMA8T8JBAAACwBAOgEAAAADAP0/5AQAAAIBCzABAAAAEAAAAGEKZYEAlWpA n/wGs/RO5p0DABcAAQAAAEAAOQAAUImwgp3MAUAACDCzBwWxgp3MAQsAKQAAAAAACwAjAAAAAAAf AACAhgMCAAAAAADAAAAAAAAARgEAAAAeAAAAYQBjAGMAZQBwAHQAbABhAG4AZwB1AGEAZwBlAAAA AAABAAAADAAAAGUAbgAtAFUAUwAAAAsAAIAIIAYAAAAAAMAAAAAAAABGAAAAAAaFAAAAAAAAHwA3 AAEAAACYAAAAUgBFADoAIABbAHMAaQBwAC0AbwB2AGUAcgBsAG8AYQBkAF0AIABDAG8AbQBtAGUA bgB0AHMAIABvAG4AIABkAHIAYQBmAHQALQBpAGUAdABmAC0AcwBvAGMALQBsAG8AYQBkAC0AYwBv AG4AdAByAG8AbAAtAGUAdgBlAG4AdAAtAHAAYQBjAGsAYQBnAGUALQAwADEAAAAfAD0AAQAAAAoA AABSAEUAOgAgAAAAAAADADYAAAAAAAMALgAAAAAAHwBCEAEAAABkAAAAPAAxADUANwAyADQAMQA5 ADkALQA3AEMAMgA3AC0ANAA1ADcANwAtAEEARABCADMALQAzAEMAQgA4AEEANAA4ADQAQwAwADMA MABAAG4AdAB0AC0AYQB0AC4AYwBvAG0APgAAAAIBcQABAAAAFgAAAAEBzJ2CsdNMkYynjeVBoeF1 z4lseVEAAB8AcAABAAAAkAAAAFsAcwBpAHAALQBvAHYAZQByAGwAbwBhAGQAXQAgAEMAbwBtAG0A ZQBuAHQAcwAgAG8AbgAgAGQAcgBhAGYAdAAtAGkAZQB0AGYALQBzAG8AYwAtAGwAbwBhAGQALQBj AG8AbgB0AHIAbwBsAC0AZQB2AGUAbgB0AC0AcABhAGMAawBhAGcAZQAtADAAMQAAAB8ANRABAAAA nAAAADwAOQBFAEMAOQA5AEQAQQA5AEYAMQAwADcARABGADQAQQA4AEEARAA3AEIAMwAzADIARgBC ADUARgBDADUAQwBEADAAMQA2ADIAOAAwAEYARABAAE0ASQBTAE8AVQBUADcATQBTAEcAVQBTAFIA OQBBAC4ASQBUAFMAZQByAHYAaQBjAGUAcwAuAHMAYgBjAC4AYwBvAG0APgAAAB8AORABAAAAZAAA ADwAMQA1ADcAMgA0ADEAOQA5AC0ANwBDADIANwAtADQANQA3ADcALQBBAEQAQgAzAC0AMwBDAEIA OABBADQAOAA0AEMAMAAzADAAQABuAHQAdAAtAGEAdAAuAGMAbwBtAD4AAAADAN4/n04AAAsAAIAI IAYAAAAAAMAAAAAAAABGAAAAAAOFAAAAAAAAAwAAgAggBgAAAAAAwAAAAAAAAEYAAAAAAYUAAAAA AAADAACAAyAGAAAAAADAAAAAAAAARgAAAAABgQAAAAAAAAMAgBD/////BQAAgAMgBgAAAAAAwAAA AAAAAEYAAAAAAoEAAAAAAAAAAAAACwAAgAMgBgAAAAAAwAAAAAAAAEYAAAAAHIEAAAAAAABAAAcw iNjqsIKdzAELAAIAAQAAAAMAJgAAAAAACwArAAAAAAACAUcAAQAAADIAAABjPVVTO2E9IDtwPXNi YztsPU1JU09VVDdNU0dVUy0xMTExMDcxOTIzMTJaLTg0NTA3AAAAAgEQMAEAAABGAAAAAAAAAKuZ 70F9nohKi69vsKkRznAHABFEYQkAunJLo5wCs5BIyhUAAAeoCjoAALfNsUziYpBMl/W2/OlSZiEA AwwCajwAAAAAHwD6PwEAAAAcAAAAUwBIAEUATgAsACAAQwBIAEEAUgBMAEUAUwAAAAMACVkBAAAA AwAAgAggBgAAAAAAwAAAAAAAAEYAAAAAEIUAAAAAAABAAACACCAGAAAAAADAAAAAAAAARgAAAAC/ hQAAAOIaAoGdzAELAACACCAGAAAAAADAAAAAAAAARgAAAACChQAAAAAAAAMAAIADIAYAAAAAAMAA AAAAAABGAAAAABOBAAABAAAACwAAgAMgBgAAAAAAwAAAAAAAAEYAAAAAJoEAAAAAAAADAACAAyAG AAAAAADAAAAAAAAARgAAAAAQgQAAAAAAAAMAAIADIAYAAAAAAMAAAAAAAABGAAAAABGBAAAAAAAA AwAAgAMgBgAAAAAAwAAAAAAAAEYAAAAAKoEAAAAAAAADAACAAyAGAAAAAADAAAAAAAAARgAAAAAp gQAAAAAAAAsAAIADIAYAAAAAAMAAAAAAAABGAAAAACSBAAAAAAAACwAAgAMgBgAAAAAAwAAAAAAA AEYAAAAALIEAAAAAAAAfAACAAyAGAAAAAADAAAAAAAAARgAAAAAngQAAAQAAAAIAAAAAAAAAAwAA gAMgBgAAAAAAwAAAAAAAAEYAAAAAEoEAAAEAAAAfAACAAyAGAAAAAADAAAAAAAAARgAAAAAhgQAA AQAAAAIAAAAAAAAACwAAgAMgBgAAAAAAwAAAAAAAAEYAAAAAA4EAAAAAAAADAACAAyAGAAAAAADA AAAAAAAARgAAAAAjgQAA////fwsAAIAIIAYAAAAAAMAAAAAAAABGAAAAAA6FAAAAAAAAAwAAgAgg BgAAAAAAwAAAAAAAAEYAAAAAGIUAAAAAAAAfAACAH6TrM6h6LkK+e3nhqY5UswEAAAA4AAAAQwBv AG4AdgBlAHIAcwBhAHQAaQBvAG4ASQBuAGQAZQB4AFQAcgBhAGMAawBpAG4AZwBFAHgAAAABAAAA SgEAAEkASQA9ADAAMQAwADEAQwBDADgAMQBEAEIANwA3ADYANwA2AEYAOQA0ADUANgAzADEANAAz ADAARQA0ADAAOAA0ADIAMgBEADQAMAA1ADEAMwA4ADMAMgA3ADUAQgA5ADUAQQAxAEIAQgAzADAA OQAwADsAUwBCAE0ASQBEAD0AMQA5ADsAUwAxAD0APAAxADUANwAyADQAMQA5ADkALQA3AEMAMgA3 AC0ANAA1ADcANwAtAEEARABCADMALQAzAEMAQgA4AEEANAA4ADQAQwAwADMAMABAAG4AdAB0AC0A YQB0AC4AYwBvAG0APgA7AFYAZQByAHMAaQBvAG4APQBWAGUAcgBzAGkAbwBuACAAMQA0AC4AMQAg ACgAQgB1AGkAbABkACAAMwAzADkALgAwACkALAAgAFMAdABhAGcAZQA9AEgAMwAAAAAAAwANNP0/ AAAfAACAhgMCAAAAAADAAAAAAAAARgEAAAAgAAAAeAAtAG0AcwAtAGgAYQBzAC0AYQB0AHQAYQBj AGgAAAABAAAAAgAAAAAAAAAfAACAhgMCAAAAAADAAAAAAAAARgEAAAAiAAAAeAAtAG8AcgBpAGcA aQBuAGEAdABpAG4AZwAtAGkAcAAAAAAAAQAAACAAAABbADEANQAxAC4AMQAwADkALgA4AC4AMgA0 ADMAXQAAAFt6 --_000_9EC99DA9F107DF4A8AD7B332FB5FC5CD016280FDMISOUT7MSGUSR9A_-- ------------=_1320693858-26395-0-- From cs4303@att.com Mon Nov 7 12:07:34 2011 Return-Path: X-Original-To: sip-overload@ietfa.amsl.com Delivered-To: sip-overload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD33A11E80B4 for ; Mon, 7 Nov 2011 12:07:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NRdsvfOLRZtg for ; Mon, 7 Nov 2011 12:07:31 -0800 (PST) Received: from mail120.messagelabs.com (mail120.messagelabs.com [216.82.250.83]) by ietfa.amsl.com (Postfix) with ESMTP id 6F72F11E80B0 for ; Mon, 7 Nov 2011 12:07:31 -0800 (PST) X-Env-Sender: cs4303@att.com X-Msg-Ref: server-10.tower-120.messagelabs.com!1320696449!48091549!1 X-Originating-IP: [144.160.20.145] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24029 invoked from network); 7 Nov 2011 20:07:29 -0000 Received: from sbcsmtp6.sbc.com (HELO mlpd192.enaf.sfdc.sbc.com) (144.160.20.145) by server-10.tower-120.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 7 Nov 2011 20:07:29 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id pA7K7tJQ000829; Mon, 7 Nov 2011 15:07:56 -0500 Received: from MISOUT7MSGHUB9C.ITServices.sbc.com (misout7msghub9c.itservices.sbc.com [144.151.223.82]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id pA7K7bcI032669 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 7 Nov 2011 15:07:51 -0500 Received: from MISOUT7MSGUSR9A.ITServices.sbc.com ([169.254.1.121]) by MISOUT7MSGHUB9C.ITServices.sbc.com ([144.151.223.82]) with mapi id 14.01.0339.001; Mon, 7 Nov 2011 15:07:12 -0500 From: "SHEN, CHARLES" To: "sip-overload@ietf.org" Thread-Topic: [sip-overload] Enhancement to Load Control Event Package to support partial updates to control restriction parameters and validity Thread-Index: Acxhq768aXwRR+/ZR8icaOn+l4FJjQ73KJqQ Date: Mon, 7 Nov 2011 20:07:12 +0000 Message-ID: <9EC99DA9F107DF4A8AD7B332FB5FC5CD01628134@MISOUT7MSGUSR9A.ITServices.sbc.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [151.109.8.243] Content-Type: multipart/alternative; boundary="_000_9EC99DA9F107DF4A8AD7B332FB5FC5CD01628134MISOUT7MSGUSR9A_" MIME-Version: 1.0 Subject: Re: [sip-overload] Enhancement to Load Control Event Package to support partial updates to control restriction parameters and validity X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2011 20:07:34 -0000 --_000_9EC99DA9F107DF4A8AD7B332FB5FC5CD01628134MISOUT7MSGUSR9A_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all: I am in the process of producing an updated version of the "Load Co= ntrol Event Package" document. I would like to seek the group's opinion on = the following proposal from Phil earlier. Thanks Charles From: sip-overload-bounces@ietf.org [mailto:sip-overload-bounces@ietf.org] = On Behalf Of phil.m.williams@bt.com Sent: Tuesday, August 23, 2011 11:46 AM To: sip-overload@ietf.org Subject: [sip-overload] Enhancement to Load Control Event Package to suppor= t partial updates to control restriction parameters and validity Folks, I have proposed to the authors of draft-ietf-soc-load-control-event-package= -01 that Notifications of partial updates to control restriction parameters= and validity (only) should be supported. Currently the spec explicitly sta= tes that they are not, in 5.7.(Notifier Generation of NOTIFY Requests): ...This event package does not support notifications that contain deltas to= previous information or partial information. This proposal is fine with Charles Shen, so we agreed to open it up for gen= eral views. My reasoning follows. It would be common practice for updates to specific load control events to = be made frequently by changing the control restriction parameter informatio= n only (e.g. rate, percent), but not other rule elements, such as call-iden= tity. This will typically be because the utilisation of a resource subject = to overload depends upon dynamic unknowns such as holding time and the rela= tive distribution of offered load over subscribing SIP entities. The update= s could originate manually or be determined automatically. The latter is re= ferred to already in 4.2.(Filter Computation): ...it may be preferable to employ a dynamic load computation algorithm whic= h adapts to current network status, rather than using a purely static mecha= nism. The filter content computation algorithm is out of scope of this doc= ument. [Note: A rate-based control would generally need a lower frequency of updat= es even when adaptive than say a loss-based method because of the dependenc= e of the proportional method upon offered rates]. Another factor usually not known precisely or computed automatically is the= duration of the load control event. Therefore it would also be common for = the validity to change frequently. Not allowing partial updates could be a significant limitation to performan= ce when realised, since it makes such updates unnecessarily verbose. It wou= ld be a small enhancement to allow deltas which change the rate, win, or pe= rcent values of the action element, and the validity. They can be associate= d to the complete rule through the rule id. Regards, Phil Williams --_000_9EC99DA9F107DF4A8AD7B332FB5FC5CD01628134MISOUT7MSGUSR9A_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all: I am in the proce= ss of producing an updated version of the “Load Control Event Package= ” document. I would like to seek the group’s opinion on the fol= lowing proposal from Phil earlier.

 <= /p>

Thanks<= /p>

 <= /p>

Charles=

 <= /p>

From: sip-over= load-bounces@ietf.org [mailto:sip-overload-bounces@ietf.org] On Behalf Of phil.m.williams@bt.com
Sent: Tuesday, August 23, 2011 11:46 AM
To: sip-overload@ietf.org
Subject: [sip-overload] Enhancement to Load Control Event Package to= support partial updates to control restriction parameters and validity

 

Folks,

 

I have proposed to the authors of draft-i= etf-soc-load-control-event-package-01 that Notifications of partial updates= to control restriction parameters and validity (only) should be supported. Currently the spec explicitly states that they are not, in 5= .7.(Notifier Generation of NOTIFY Requests):

 

...This event package does not support no= tifications that contain deltas to previous information or partial informat= ion.

 

This proposal is fine with Charles Shen, = so we agreed to open it up for general views. My reasoning follows.

 

It would be common practice for updates t= o specific load control events to be made frequently by changing the contro= l restriction parameter information only (e.g. rate, percent), but not other rule elements, such as call-identity. This will typically be= because the utilisation of a resource subject to overload depends upon dyn= amic unknowns such as holding time and the relative distribution of offered= load over subscribing SIP entities. The updates could originate manually or be determined automatically. The l= atter is referred to already in 4.2.(Filter Computation):=

 

...it may be preferable to employ a dynam= ic load computation algorithm which adapts to current network status, rathe= r than using a purely static mechanism.  The filter content computation algorithm is out of scope of this document.<= /p>

 

[Note: A rate-based control would general= ly need a lower frequency of updates even when adaptive than say a loss-bas= ed method because of the dependence of the proportional method upon offered rates].

 

Another factor usually not known precisel= y or computed automatically is the duration of the load control event. Ther= efore it would also be common for the validity to change frequently.

 

Not allowing partial updates could be a s= ignificant limitation to performance when realised, since it makes such upd= ates unnecessarily verbose. It would be a small enhancement to allow deltas which change the rate, win, or percent values of the actio= n element, and the validity. They can be associated to the complete rule th= rough the rule id.

 

Regards,

 

Phil Williams

 

--_000_9EC99DA9F107DF4A8AD7B332FB5FC5CD01628134MISOUT7MSGUSR9A_-- From shida@ntt-at.com Mon Nov 7 18:30:03 2011 Return-Path: X-Original-To: sip-overload@ietfa.amsl.com Delivered-To: sip-overload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 535291F0C59 for ; Mon, 7 Nov 2011 18:30:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Hoo0qhmdgbk for ; Mon, 7 Nov 2011 18:30:02 -0800 (PST) Received: from gator465.hostgator.com (gator465.hostgator.com [69.56.174.130]) by ietfa.amsl.com (Postfix) with ESMTP id 7BE3E1F0C5B for ; Mon, 7 Nov 2011 18:30:02 -0800 (PST) Received: from [122.133.87.237] (port=63248 helo=[192.168.1.14]) by gator465.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1RNbRm-0003ds-Ai; Mon, 07 Nov 2011 20:29:58 -0600 Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Shida Schubert In-Reply-To: <9EC99DA9F107DF4A8AD7B332FB5FC5CD016280FD@MISOUT7MSGUSR9A.ITServices.sbc.com> Date: Tue, 8 Nov 2011 11:29:56 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <56066F7D-EA77-43B9-8959-53907A8C4020@ntt-at.com> References: <15724199-7C27-4577-ADB3-3CB8A484C030@ntt-at.com> <9EC99DA9F107DF4A8AD7B332FB5FC5CD016280FD@MISOUT7MSGUSR9A.ITServices.sbc.com> To: "SHEN, CHARLES" X-Mailer: Apple Mail (2.1251.1) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator465.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ntt-at.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: fl1-122-133-87-237.tky.mesh.ad.jp ([192.168.1.14]) [122.133.87.237]:63248 X-Source-Auth: shida@agnada.com X-Email-Count: 3 X-Source-Cap: c3NoaWRhO3NzaGlkYTtnYXRvcjQ2NS5ob3N0Z2F0b3IuY29t Cc: "sip-overload@ietf.org" , Arata Koike , Henning Schulzrinne Subject: Re: [sip-overload] Comments on draft-ietf-soc-load-control-event-package-01 X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2011 02:30:03 -0000 Hi Charles; My comments inline.. Overall it may be worthwhile adding a terminology=20 section, if not I think all the explicit text describing the=20 term should probably added where the term=20 appears for the first time.=20 On Nov 8, 2011, at 4:23 AM, SHEN, CHARLES wrote: > Hi Shida, >=20 > Thank you very much for your review and I apologize for the late = reply. Please find my comments inline.=20 >=20 >> -----Original Message----- >> From: sip-overload-bounces@ietf.org [mailto:sip-overload- >> bounces@ietf.org] On Behalf Of Shida Schubert >> Sent: Monday, October 03, 2011 10:48 AM >> To: sip-overload@ietf.org >> Subject: [sip-overload] Comments on = draft-ietf-soc-load-control-event- >> package-01 >>=20 >>=20 >> I recently reviewed the draft and below are some comments. >>=20 >> A: Terminology >>=20 >> First of all, I find that the document is rather hard to read >> because; 1. it uses different terminology for what I believe is >> the same thing. 2. introduce many terminology that >> is not defined anywhere and 3. the terminology used should >> probably be aligned with that of the other drafts >> that define some of these terminologies (RFC6537 etc). >=20 > We can look at those terms you referred to and improve as appropriate. = But I could not find RFC6537, is it a typo or can you provide a link?=20 >=20 I for some reason thought the req draft would have some terminology = section=20 but it didn't. I do think we should probably have consistent terminology = uses=20 across all the drafts published under SOC WG if possible.=20 >>=20 >> Here are some examples; >>=20 >> 1. "load control" - should this be "overload control"? >=20 > The reason for using load control instead of overload control is that = the mechanism is more generically applicable. Although the motivation is = driven by overload control, it could also be used for load control = purely determined by QoS/service level agreements, for example. I am = open to either terms depending on what the majority thinks.=20 Okay. This makes sense.=20 >=20 >> 2. What is "user load control information"? >=20 > Load control information is associated with user's identities, e.g., = phone numbers, SIP addresses, which is mentioned in the abstract. But I = can remove the word "user" there if that sounds clearer to you.=20 Well, we can leave it as is but may be some=20 explanation such as the one you provided above=20 if the term is used will be useful.=20 >=20 >> 3. "edge server" - edge of what? At the edge of domain? >=20 > SIP servers in the edge networks (as opposed to SIP servers in the = core networks), would that sound better or do you have other = suggestions?=20 Sounds good.=20 >=20 >> 4. load document, load control document and load filter, are they the >> same thing? >=20 > Load document probably should be load control document. A load control = document is (specifically) an XML document that inherits and enhances = the common policy document defined in RFC4745 (Sec. 6.1). Load filter is = a more generic term associated with the (filtering) mechanism. Any = suggestion? =20 I just think we should use consistent terminology, I don't really=20 care what term is picked as long as it is consistent across the = document.=20 >=20 >> 5. load filtering mechanism and load filter control the same thing? >=20 > They are, and they should probably be consolidated. Sounds good.=20 >=20 >> 6. What is a dynamic filter? >=20 > Meaning the filtering contents are dynamically computed based on = current network status. This is mentioned in Section 4.2 but could be = made more explicit. =20 >=20 Sounds good.=20 >> 7. What is a load control policy maker? >=20 > The party that determines the policy for load control.=20 With all the terminology used through out the document,=20 one can probably imagine what the entity do but I think=20 it is better to clarify so there is little misunderstandings. >=20 >> 8. What is a policy entry point? >=20 > The entity through which the policy is first injected (into the = network). =20 Same comment applies as above.=20 >=20 >> 9. What is a filter computation decision maker? >=20 > The party which determines the filter contents (e.g., through some = algorithm).=20 Same comment applies as above.=20 >=20 >> 10. Is load control policy, load control information and load control >> rule the same thing? >=20 > I consider policy a type of information expressed in a set of rules = here. I am open to the possibility of consolidating these terms if the = meaning is clear. =20 >=20 >> 11. What is load control filter content definition? >>=20 >=20 > Load control filter content refers to the set of rules (including = conditions and actions) specified for the filtering. =20 Is the load control filter content different from load control filter = content definition? =20 The rest sounds good.=20 Regards Shida >=20 >> Also some terminology can be changed to common terminology used in = SIP >> related RFCs >>=20 >> e.g. SIP entity subscribers > SIP subscribers or subscribers >> e.g. local format/global format > local number / global number >> [RFC3966] >>=20 >>=20 >=20 > I can change them accordingly. =20 >=20 >> B: Requirements >>=20 >> The draft does a really nice job evaluating whether the >> document meets the requirements set forth by RFC 5390 in >> section section 9. but the draft also has design requirements >> in section 3. This seems reasonable thing to have but shouldn't >> these requirements expressed with RFC2119 language? >>=20 >=20 > I can do that.=20 >=20 >>=20 >> C: Behavior of Notifier and Subscriber is mixed in section 5.6 >> - I think followings should be described as Subscribers' behavior. >>=20 >> "SIP entity subscribers SHOULD try to subscribe to all those SIP = entity >> notifiers with which they have regular signaling exchanges, = although >> not all such SIP notifiers may permit such a subscription" >>=20 >=20 > I will move that sentence as suggested. >=20 >> D: Technical questions >>=20 >> 1. section 5.7. >> - "Following the [RFC3265] specification, a notifier MUST send a >> NOTIFY >> with its current load control policy to the subscriber upon >> successfully accepting or refreshing a subscription. The NOTIFY >> request MAY include a body. " >>=20 >> - So it says MUST send a NOTIFY but it is followed by MAY include a >> body. >> If load control policy is carried in a body, I don't know there = is >> a MAY following >> the first paragraph. >>=20 >> - If what you want to say is to include the control policy in the >> body when >> there is an active policy to be MUST and otherwise a MAY, this >> should be >> clarified. >>=20 >> 2. section 5.8. >> - "Upon receipt of a NOTIFY request with a Subscription-State header >> field containing the value "terminated", the subscriber MUST remove >> all previously received load control information and process all >> calls without applying any restriction" >>=20 >> - This should be clarified that this applies only to the relevant >> filter and >> not to all the policy that may be active at the time of receiving >> this NOTIFY. >>=20 >=20 > You are right in both. I will add clarification accordingly.=20 >=20 > Thanks again. >=20 > Charles >=20 >=20 >> Regards >> Shida >>=20 >>=20 >> _______________________________________________ >> sip-overload mailing list >> sip-overload@ietf.org >> https://www.ietf.org/mailman/listinfo/sip-overload From bruno.chatras@orange.com Tue Nov 8 00:35:31 2011 Return-Path: X-Original-To: sip-overload@ietfa.amsl.com Delivered-To: sip-overload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C04D21F8B85 for ; Tue, 8 Nov 2011 00:35:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HRdYwzEdhwDM for ; Tue, 8 Nov 2011 00:35:29 -0800 (PST) Received: from r-mail2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by ietfa.amsl.com (Postfix) with ESMTP id 5935B21F8B7E for ; Tue, 8 Nov 2011 00:35:28 -0800 (PST) Received: from r-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id CF34D140010; Tue, 8 Nov 2011 09:35:25 +0100 (CET) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by r-mail2.rd.francetelecom.com (Postfix) with ESMTP id BE4B5FCC002; Tue, 8 Nov 2011 09:35:25 +0100 (CET) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Tue, 8 Nov 2011 09:35:25 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC9DF1.5C73B710" Date: Tue, 8 Nov 2011 09:35:24 +0100 Message-ID: <9ECCF01B52E7AB408A7EB8535264214103746E39@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <9EC99DA9F107DF4A8AD7B332FB5FC5CD01628134@MISOUT7MSGUSR9A.ITServices.sbc.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sip-overload] Enhancement to Load Control Event Package to support partial updates to control restriction parameters and validity Thread-Index: Acxhq768aXwRR+/ZR8icaOn+l4FJjQ73KJqQABoJA2A= References: <9EC99DA9F107DF4A8AD7B332FB5FC5CD01628134@MISOUT7MSGUSR9A.ITServices.sbc.com> From: To: , X-OriginalArrivalTime: 08 Nov 2011 08:35:25.0726 (UTC) FILETIME=[5CD84BE0:01CC9DF1] X-Mailman-Approved-At: Tue, 08 Nov 2011 03:51:18 -0800 Subject: Re: [sip-overload] Enhancement to Load Control Event Package to support partial updates to control restriction parameters and validity X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2011 08:35:31 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC9DF1.5C73B710 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I tend to agree that some rule elements will have to be updated more = frequently than others. However, I'm not sure that partial updates will = bring a significant gain as in practice rule descriptions will not that = verbose... Having said that, I'm not against adding this feature to the = draft...=20 BC =20 De : sip-overload-bounces@ietf.org = [mailto:sip-overload-bounces@ietf.org] De la part de SHEN, CHARLES Envoy=E9 : lundi 7 novembre 2011 21:07 =C0 : sip-overload@ietf.org Objet : Re: [sip-overload] Enhancement to Load Control Event Package to = support partial updates to control restriction parameters and validity =20 Hi all: I am in the process of producing an updated version of the "Load = Control Event Package" document. I would like to seek the group's = opinion on the following proposal from Phil earlier.=20 =20 Thanks =20 Charles =20 From: sip-overload-bounces@ietf.org = [mailto:sip-overload-bounces@ietf.org] On Behalf Of = phil.m.williams@bt.com Sent: Tuesday, August 23, 2011 11:46 AM To: sip-overload@ietf.org Subject: [sip-overload] Enhancement to Load Control Event Package to = support partial updates to control restriction parameters and validity =20 Folks, =20 I have proposed to the authors of = draft-ietf-soc-load-control-event-package-01 that Notifications of = partial updates to control restriction parameters and validity (only) = should be supported. Currently the spec explicitly states that they are = not, in 5.7.(Notifier Generation of NOTIFY Requests):=20 =20 ...This event package does not support notifications that contain deltas = to previous information or partial information. =20 This proposal is fine with Charles Shen, so we agreed to open it up for = general views. My reasoning follows. =20 It would be common practice for updates to specific load control events = to be made frequently by changing the control restriction parameter = information only (e.g. rate, percent), but not other rule elements, such = as call-identity. This will typically be because the utilisation of a = resource subject to overload depends upon dynamic unknowns such as = holding time and the relative distribution of offered load over = subscribing SIP entities. The updates could originate manually or be = determined automatically. The latter is referred to already in = 4.2.(Filter Computation): =20 ...it may be preferable to employ a dynamic load computation algorithm = which adapts to current network status, rather than using a purely = static mechanism. The filter content computation algorithm is out of = scope of this document. =20 [Note: A rate-based control would generally need a lower frequency of = updates even when adaptive than say a loss-based method because of the = dependence of the proportional method upon offered rates]. =20 Another factor usually not known precisely or computed automatically is = the duration of the load control event. Therefore it would also be = common for the validity to change frequently. =20 Not allowing partial updates could be a significant limitation to = performance when realised, since it makes such updates unnecessarily = verbose. It would be a small enhancement to allow deltas which change = the rate, win, or percent values of the action element, and the = validity. They can be associated to the complete rule through the rule = id. =20 Regards, =20 Phil Williams =20 ------_=_NextPart_001_01CC9DF1.5C73B710 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I tend to agree that some rule elements will have to be = updated more frequently than others. However, I’m not sure that partial = updates will bring a significant gain as in practice rule descriptions will not that = verbose… =A0Having said that, I’m not against adding this feature to the = draft…

BC

 

De : = sip-overload-bounces@ietf.org [mailto:sip-overload-bounces@ietf.org] De la part de SHEN, = CHARLES
Envoy=E9 : lundi 7 novembre 2011 21:07
=C0 : sip-overload@ietf.org
Objet : Re: [sip-overload] Enhancement to Load Control Event Package to support partial updates to control restriction parameters and validity

 

Hi all: I am in the process of producing an updated = version of the “Load Control Event Package” document. I would like to seek = the group’s opinion on the following proposal from Phil earlier.

 

Thanks

 

Charles

 

From: sip-overload-bounces@ietf.org [mailto:sip-overload-bounces@ietf.org] On Behalf Of = phil.m.williams@bt.com
Sent: Tuesday, August 23, 2011 11:46 AM
To: sip-overload@ietf.org
Subject: [sip-overload] Enhancement to Load Control Event Package = to support partial updates to control restriction parameters and = validity

 

Folks,

 

I have proposed to the authors of = draft-ietf-soc-load-control-event-package-01 that Notifications of partial updates to control restriction parameters = and validity (only) should be supported. Currently the spec explicitly = states that they are not, in 5.7.(Notifier Generation of NOTIFY Requests): =

 

...This event package does not support notifications that contain deltas to = previous information or partial information.

 

This proposal is fine with Charles Shen, so we agreed to open it up for = general views. My reasoning follows.

 

It would be common practice for updates to specific load control events to = be made frequently by changing the control restriction parameter information = only (e.g. rate, percent), but not other rule elements, such as call-identity. This = will typically be because the utilisation of a resource subject to overload = depends upon dynamic unknowns such as holding time and the relative distribution = of offered load over subscribing SIP entities. The updates could originate manually or be determined automatically. The latter is referred to = already in 4.2.(Filter Computation):

 

...it may be preferable to employ a dynamic load computation algorithm which = adapts to current network status, rather than using a purely static = mechanism.  The filter content computation algorithm is out of scope of this = document.

 

[Note: A rate-based control would generally need a lower frequency of updates = even when adaptive than say a loss-based method because of the dependence of = the proportional method upon offered rates].

 

Another factor usually not known precisely or computed automatically is the = duration of the load control event. Therefore it would also be common for the = validity to change frequently.

 

Not allowing partial updates could be a significant limitation to = performance when realised, since it makes such updates unnecessarily verbose. It would be = a small enhancement to allow deltas which change the rate, win, or percent = values of the action element, and the validity. They can be associated to the = complete rule through the rule id.

 

Regards,=

 

Phil Williams

 

------_=_NextPart_001_01CC9DF1.5C73B710-- From cs4303@att.com Tue Nov 8 17:34:23 2011 Return-Path: X-Original-To: sip-overload@ietfa.amsl.com Delivered-To: sip-overload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 212E811E8097 for ; Tue, 8 Nov 2011 17:34:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hvhankr9F+ty for ; Tue, 8 Nov 2011 17:34:22 -0800 (PST) Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.195]) by ietfa.amsl.com (Postfix) with ESMTP id D00E711E8095 for ; Tue, 8 Nov 2011 17:34:21 -0800 (PST) X-Env-Sender: cs4303@att.com X-Msg-Ref: server-4.tower-119.messagelabs.com!1320802459!234874!1 X-Originating-IP: [144.160.20.145] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30133 invoked from network); 9 Nov 2011 01:34:19 -0000 Received: from sbcsmtp6.sbc.com (HELO mlpd192.enaf.sfdc.sbc.com) (144.160.20.145) by server-4.tower-119.messagelabs.com with AES256-SHA encrypted SMTP; 9 Nov 2011 01:34:19 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id pA91Yk3U011224; Tue, 8 Nov 2011 20:34:46 -0500 Received: from MISOUT7MSGHUB9C.ITServices.sbc.com (misout7msghub9c.itservices.sbc.com [144.151.223.82]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id pA91YeE4011138 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 8 Nov 2011 20:34:41 -0500 Received: from MISOUT7MSGUSR9A.ITServices.sbc.com ([169.254.1.121]) by MISOUT7MSGHUB9C.ITServices.sbc.com ([144.151.223.82]) with mapi id 14.01.0339.001; Tue, 8 Nov 2011 20:34:12 -0500 From: "SHEN, CHARLES" To: Shida Schubert Thread-Topic: [sip-overload] Comments on draft-ietf-soc-load-control-event-package-01 Thread-Index: AQHMnYKx00yRjKeN5UGh4XXPiWx5UZWilWcAgAEn0Mc= Date: Wed, 9 Nov 2011 01:34:12 +0000 Message-ID: <9EC99DA9F107DF4A8AD7B332FB5FC5CD016289E1@MISOUT7MSGUSR9A.ITServices.sbc.com> References: <15724199-7C27-4577-ADB3-3CB8A484C030@ntt-at.com> <9EC99DA9F107DF4A8AD7B332FB5FC5CD016280FD@MISOUT7MSGUSR9A.ITServices.sbc.com>, <56066F7D-EA77-43B9-8959-53907A8C4020@ntt-at.com> In-Reply-To: <56066F7D-EA77-43B9-8959-53907A8C4020@ntt-at.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.188.11.69] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sip-overload@ietf.org" , Arata Koike , Henning Schulzrinne Subject: Re: [sip-overload] Comments on draft-ietf-soc-load-control-event-package-01 X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2011 01:34:23 -0000 Hi Shida,=0A= =0A= [Shida] Overall it may be worthwhile adding a terminology=0A= section, if not I think all the explicit text describing the=0A= term should probably added where the term=0A= appears for the first time.=0A= =0A= [Shida] I for some reason thought the req draft would have some terminology= section=0A= but it didn't. I do think we should probably have consistent terminology us= es=0A= across all the drafts published under SOC WG if possible.=0A= =0A= [CS] I agree. I have also been pondering on adding a terminology section = for this document. But for now, I think will probably add some description = to the terms you mentioned where they first appear, and consolidate some of= them as appropriate. If we still see a strong need for a terminology secti= on after that, I am certainly open to add it. =0A= =0A= [Shida] Is the load control filter content different from load control fil= ter content definition?=0A= =0A= [CS] The "definition" here probably more meant to be "format". I can rephra= se them. =0A= =0A= [CS] I generally agree with all other comments. =0A= =0A= Thanks!=0A= =0A= Charles=0A= =0A= =0A= =0A= On Nov 8, 2011, at 4:23 AM, SHEN, CHARLES wrote:=0A= =0A= > Hi Shida,=0A= >=0A= > Thank you very much for your review and I apologize for the late reply. P= lease find my comments inline.=0A= >=0A= >> -----Original Message-----=0A= >> From: sip-overload-bounces@ietf.org [mailto:sip-overload-=0A= >> bounces@ietf.org] On Behalf Of Shida Schubert=0A= >> Sent: Monday, October 03, 2011 10:48 AM=0A= >> To: sip-overload@ietf.org=0A= >> Subject: [sip-overload] Comments on draft-ietf-soc-load-control-event-= =0A= >> package-01=0A= >>=0A= >>=0A= >> I recently reviewed the draft and below are some comments.=0A= >>=0A= >> A: Terminology=0A= >>=0A= >> First of all, I find that the document is rather hard to read=0A= >> because; 1. it uses different terminology for what I believe is=0A= >> the same thing. 2. introduce many terminology that=0A= >> is not defined anywhere and 3. the terminology used should=0A= >> probably be aligned with that of the other drafts=0A= >> that define some of these terminologies (RFC6537 etc).=0A= >=0A= > We can look at those terms you referred to and improve as appropriate. Bu= t I could not find RFC6537, is it a typo or can you provide a link?=0A= >=0A= =0A= I for some reason thought the req draft would have some terminology sectio= n=0A= but it didn't. I do think we should probably have consistent terminology us= es=0A= across all the drafts published under SOC WG if possible.=0A= =0A= >>=0A= >> Here are some examples;=0A= >>=0A= >> 1. "load control" - should this be "overload control"?=0A= >=0A= > The reason for using load control instead of overload control is that the= mechanism is more generically applicable. Although the motivation is drive= n by overload control, it could also be used for load control purely determ= ined by QoS/service level agreements, for example. I am open to either term= s depending on what the majority thinks.=0A= =0A= Okay. This makes sense.=0A= =0A= >=0A= >> 2. What is "user load control information"?=0A= >=0A= > Load control information is associated with user's identities, e.g., phon= e numbers, SIP addresses, which is mentioned in the abstract. But I can rem= ove the word "user" there if that sounds clearer to you.=0A= =0A= Well, we can leave it as is but may be some=0A= explanation such as the one you provided above=0A= if the term is used will be useful.=0A= =0A= >=0A= >> 3. "edge server" - edge of what? At the edge of domain?=0A= >=0A= > SIP servers in the edge networks (as opposed to SIP servers in the core n= etworks), would that sound better or do you have other suggestions?=0A= =0A= Sounds good.=0A= =0A= >=0A= >> 4. load document, load control document and load filter, are they the=0A= >> same thing?=0A= >=0A= > Load document probably should be load control document. A load control do= cument is (specifically) an XML document that inherits and enhances the com= mon policy document defined in RFC4745 (Sec. 6.1). Load filter is a more ge= neric term associated with the (filtering) mechanism. Any suggestion?=0A= =0A= I just think we should use consistent terminology, I don't really=0A= care what term is picked as long as it is consistent across the document.= =0A= =0A= >=0A= >> 5. load filtering mechanism and load filter control the same thing?=0A= >=0A= > They are, and they should probably be consolidated.=0A= =0A= Sounds good.=0A= =0A= >=0A= >> 6. What is a dynamic filter?=0A= >=0A= > Meaning the filtering contents are dynamically computed based on current = network status. This is mentioned in Section 4.2 but could be made more exp= licit.=0A= >=0A= =0A= Sounds good.=0A= =0A= >> 7. What is a load control policy maker?=0A= >=0A= > The party that determines the policy for load control.=0A= =0A= With all the terminology used through out the document,=0A= one can probably imagine what the entity do but I think=0A= it is better to clarify so there is little misunderstandings.=0A= =0A= >=0A= >> 8. What is a policy entry point?=0A= >=0A= > The entity through which the policy is first injected (into the network).= =0A= =0A= Same comment applies as above.=0A= =0A= >=0A= >> 9. What is a filter computation decision maker?=0A= >=0A= > The party which determines the filter contents (e.g., through some algori= thm).=0A= =0A= Same comment applies as above.=0A= =0A= >=0A= >> 10. Is load control policy, load control information and load control=0A= >> rule the same thing?=0A= >=0A= > I consider policy a type of information expressed in a set of rules here.= I am open to the possibility of consolidating these terms if the meaning i= s clear.=0A= >=0A= >> 11. What is load control filter content definition?=0A= >>=0A= >=0A= > Load control filter content refers to the set of rules (including conditi= ons and actions) specified for the filtering.=0A= =0A= Is the load control filter content different from load control filter cont= ent definition?=0A= =0A= The rest sounds good.=0A= =0A= Regards=0A= Shida=0A= =0A= >=0A= >> Also some terminology can be changed to common terminology used in SIP= =0A= >> related RFCs=0A= >>=0A= >> e.g. SIP entity subscribers > SIP subscribers or subscribers=0A= >> e.g. local format/global format > local number / global number=0A= >> [RFC3966]=0A= >>=0A= >>=0A= >=0A= > I can change them accordingly.=0A= >=0A= >> B: Requirements=0A= >>=0A= >> The draft does a really nice job evaluating whether the=0A= >> document meets the requirements set forth by RFC 5390 in=0A= >> section section 9. but the draft also has design requirements=0A= >> in section 3. This seems reasonable thing to have but shouldn't=0A= >> these requirements expressed with RFC2119 language?=0A= >>=0A= >=0A= > I can do that.=0A= >=0A= >>=0A= >> C: Behavior of Notifier and Subscriber is mixed in section 5.6=0A= >> - I think followings should be described as Subscribers' behavior.=0A= >>=0A= >> "SIP entity subscribers SHOULD try to subscribe to all those SIP entity= =0A= >> notifiers with which they have regular signaling exchanges, although= =0A= >> not all such SIP notifiers may permit such a subscription"=0A= >>=0A= >=0A= > I will move that sentence as suggested.=0A= >=0A= >> D: Technical questions=0A= >>=0A= >> 1. section 5.7.=0A= >> - "Following the [RFC3265] specification, a notifier MUST send a=0A= >> NOTIFY=0A= >> with its current load control policy to the subscriber upon=0A= >> successfully accepting or refreshing a subscription. The NOTIFY=0A= >> request MAY include a body. "=0A= >>=0A= >> - So it says MUST send a NOTIFY but it is followed by MAY include a=0A= >> body.=0A= >> If load control policy is carried in a body, I don't know there is= =0A= >> a MAY following=0A= >> the first paragraph.=0A= >>=0A= >> - If what you want to say is to include the control policy in the=0A= >> body when=0A= >> there is an active policy to be MUST and otherwise a MAY, this=0A= >> should be=0A= >> clarified.=0A= >>=0A= >> 2. section 5.8.=0A= >> - "Upon receipt of a NOTIFY request with a Subscription-State header=0A= >> field containing the value "terminated", the subscriber MUST remove=0A= >> all previously received load control information and process all=0A= >> calls without applying any restriction"=0A= >>=0A= >> - This should be clarified that this applies only to the relevant=0A= >> filter and=0A= >> not to all the policy that may be active at the time of receiving=0A= >> this NOTIFY.=0A= >>=0A= >=0A= > You are right in both. I will add clarification accordingly.=0A= >=0A= > Thanks again.=0A= >=0A= > Charles=0A= >=0A= >=0A= >> Regards=0A= >> Shida=0A= >>=0A= >>=0A= >> _______________________________________________=0A= >> sip-overload mailing list=0A= >> sip-overload@ietf.org=0A= >> https://www.ietf.org/mailman/listinfo/sip-overload=0A= =0A=