From nsis-bounces@ietf.org Thu Feb 01 10:39:47 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCe1I-0002Xh-2k; Thu, 01 Feb 2007 10:38:40 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCe1H-0002X4-5Z; Thu, 01 Feb 2007 10:38:39 -0500 Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HCe1D-0000TN-HN; Thu, 01 Feb 2007 10:38:39 -0500 Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5]) by iramx2.ira.uni-karlsruhe.de with esmtps id 1HCe19-0000ax-OY; Thu, 01 Feb 2007 16:38:34 +0100 Received: from i72ms1.tm.uni-karlsruhe.de ([141.3.70.16] helo=smtp.ipv6.tm.uni-karlsruhe.de) by irams1.ira.uni-karlsruhe.de with esmtps id 1HCe19-0006bK-FM; Thu, 01 Feb 2007 16:38:31 +0100 Received: from vorta.ipv6.tm.uni-karlsruhe.de (i72vorta.tm.uni-karlsruhe.de [141.3.71.26]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id A4EA667822; Thu, 1 Feb 2007 16:38:30 +0100 (CET) Received: from localhost ([127.0.0.1]) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.44) id 1HCe18-0007s0-7j; Thu, 01 Feb 2007 16:38:30 +0100 Message-ID: <45C20975.9080506@tm.uka.de> Date: Thu, 01 Feb 2007 16:38:29 +0100 From: Roland Bless Organization: Institute of Telematics, University of Karlsruhe User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060111 Thunderbird/1.5 Mnenhy/0.7.3.0 MIME-Version: 1.0 To: nsis-imp@ietf.org, NSIS Group Subject: Re: [NSIS] RE: [Nsis-imp] Next Interop References: <113091BD57179D4491C19DA7E10CD696983904@mx1.office> In-Reply-To: <113091BD57179D4491C19DA7E10CD696983904@mx1.office> X-Enigmail-Version: 0.94.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: -4.1 (----) X-Spam-Status: No X-Spam-Report: -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] 0.3 AWL AWL: From: address is in the auto white-list X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: Martin Stiemerling X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi all, Martin Stiemerling wrote: > Thanks to Roland for organizing this. > > Before talking about the date of the interop, I would like to get a poll > on: > - How many implementations we still have > - How many implementators are willing to come this interop. Sorry for the very late mail, but I was quite busy with some other stuff. Feedback for participation was somehow confusing (e.g. different opinions about proposed dates from the same team, different preferences, etc.) and we have a circular dependency that participants can only commit to certain dates. Now, it's obvious too late to uphold the February meeting date. I would now propose to do it in *April* after easter somewhere in the weeks from * 16.4.--27.4.2007 *. This will also allow for better preparation of the test cases that we want to test. If I collect the answer from a previous poll, we have the following parties that expressed general interest in the next interop: * Univ. of Coimbra (pt): - GIST, QoS-NSLP, NAT/FW, HyPath * Univ. of Göttingen (de): - GIST, NAT/FW NSLP, QoS NSLP, ping/diagnostics * Siemens Roke Manor Research (UK) - GIST * Univ. of Karlsruhe (de): - GIST, QoS-NSLP, NAT/FW Anyone missing? Action item: Interested parties should state their preferences w.r.t the above date or suggestion an alternative. Best regards, Roland _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Feb 01 11:02:05 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCeN7-0001Ts-4a; Thu, 01 Feb 2007 11:01:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCeN6-0001Ti-3c; Thu, 01 Feb 2007 11:01:12 -0500 Received: from smtp.dei.uc.pt ([193.137.203.228] helo=smtp2.dei.uc.pt) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCeN0-0005J5-1O; Thu, 01 Feb 2007 11:01:12 -0500 Received: from [193.136.207.128] (dhcp-eucpii-128.ci.uc.pt [193.136.207.128]) (authenticated bits=0) by smtp2.dei.uc.pt (8.13.8/8.13.8) with ESMTP id l11FqMnV021384 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 1 Feb 2007 15:52:22 GMT Message-ID: <45C20CB0.90402@dei.uc.pt> Date: Thu, 01 Feb 2007 15:52:16 +0000 From: =?ISO-8859-1?Q?Lu=EDs_Cordeiro?= User-Agent: Thunderbird 2.0b2 (Windows/20070116) MIME-Version: 1.0 To: Roland Bless Subject: Re: [NSIS] RE: [Nsis-imp] Next Interop References: <113091BD57179D4491C19DA7E10CD696983904@mx1.office> <45C20975.9080506@tm.uka.de> In-Reply-To: <45C20975.9080506@tm.uka.de> X-FCTUC-DEI-SIC-MailScanner-Information: Please contact helpdesk@dei.uc.pt for more information X-FCTUC-DEI-SIC-MailScanner: Found to be clean X-FCTUC-DEI-SIC-MailScanner-SpamCheck: not spam (whitelisted), SpamAssassin (not cached, score=-43.801, required 3, autolearn=not spam, ALL_TRUSTED -1.80, AWL 8.00, HTML_MESSAGE 0.00, L_SMTP_AUTH -50.00, MIME_HTML_ONLY 0.00) X-FCTUC-DEI-SIC-MailScanner-From: cordeiro@dei.uc.pt X-Spam-Status: No X-Spam-Score: 1.7 (+) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: Martin Stiemerling , nsis-imp@ietf.org, NSIS Group X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1330288413==" Errors-To: nsis-bounces@ietf.org --===============1330288413== Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Roland,

My proposal is 16, 17 and 18 of April.

BR,
Luís Cordeiro

Roland Bless wrote: 
Hi all,

Martin Stiemerling wrote:
  
Thanks to Roland for organizing this. 

Before talking about the date of the interop, I would like to get a poll
on:
- How many implementations we still have
- How many implementators are willing to come this interop.
    

Sorry for the very late mail, but I was quite busy
with some other stuff. Feedback for participation was somehow
confusing (e.g. different opinions about proposed dates
from the same team, different preferences, etc.)
and we have a circular dependency that participants can only
commit to certain dates.

Now, it's obvious too late to uphold the February
meeting date. I would now propose to do it in *April* after easter
somewhere in the weeks from * 16.4.--27.4.2007 *. This will also
allow for better preparation of the test cases that we want to test.

If I collect the answer from a previous poll, we have the
following parties that expressed general interest in the
next interop:
* Univ. of Coimbra (pt):
  - GIST, QoS-NSLP, NAT/FW, HyPath
* Univ. of Göttingen (de):
  - GIST, NAT/FW NSLP, QoS NSLP, ping/diagnostics
* Siemens Roke Manor Research (UK)
  - GIST
* Univ. of Karlsruhe (de):
  - GIST, QoS-NSLP, NAT/FW

Anyone missing?

Action item: Interested parties should
state their preferences w.r.t the above date
or suggestion an alternative.

Best regards,
 Roland

_______________________________________________
NSIS-imp mailing list
NSIS-imp@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/nsis-imp
--===============1330288413== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis --===============1330288413==-- From nsis-bounces@ietf.org Thu Feb 01 11:05:54 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCeR2-00033V-IS; Thu, 01 Feb 2007 11:05:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCeR1-00033A-Mg for nsis@ietf.org; Thu, 01 Feb 2007 11:05:15 -0500 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCeQx-0006CO-AP for nsis@ietf.org; Thu, 01 Feb 2007 11:05:15 -0500 Received: from [10.1.1.109] (mito.netlab.nec.de [195.37.70.39]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 0B61213CF81 for ; Thu, 1 Feb 2007 17:05:41 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: nsis From: Martin Stiemerling Date: Thu, 1 Feb 2007 17:05:09 +0100 X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Subject: [NSIS] Summary of QSPEC call X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Dear all, Here is the short summary of the QSPEC phone conference call of January 31st. The call had been announced on the NSIS mailing list on January 23 (http://www1.ietf.org/mail-archive/web/nsis/current/msg07527.html). The participants of the call were: Georgios Karagiannis, Lars Westberg, Attila Bader, Magnus Westerlund, Jerry Ash, Bernd Schloer, Hannes Tschofenig , Cornelia Kappler, John Loughney, Andrew McDonald Jukka Manner Luis Cordeiro Lars Eggert Tom Phelan Martin Stiemerling After all we agreed to these points that need to be changed in QSPEC or QoS NSLP document: - There is text required in the QoS NSLP about the relationship between the QoS NSLP and the RMF, i.e., how can the RMF trigger actions of the QoS NSLP. For instance, that the RMF can trigger a RESERVE. - The text in Section 4.1 "QoS Models", 2nd paragraph of the QSPEC draft needs to be changed so that "state machine" clearly references to "QoS NSLP state machine" - The QSPEC draft needs an informational section describing the API between QSPEC and QoS NSLP. This informational section should be in the spirit of the API description in GIST, i.e., giving guidance to implementers. Please confirm the points or send your objection with a reason to the NSIS working group list. Thanks, Martin _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Feb 01 13:08:16 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCgLE-0005B0-95; Thu, 01 Feb 2007 13:07:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCgLD-0005Aq-Gw for nsis@ietf.org; Thu, 01 Feb 2007 13:07:23 -0500 Received: from mail120.messagelabs.com ([216.82.250.83]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HCgLA-0003f5-2x for nsis@ietf.org; Thu, 01 Feb 2007 13:07:23 -0500 X-VirusChecked: Checked X-Env-Sender: gash@att.com X-Msg-Ref: server-9.tower-120.messagelabs.com!1170353238!21538203!1 X-StarScan-Version: 5.5.10.7.1; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 9980 invoked from network); 1 Feb 2007 18:07:18 -0000 Received: from unknown (HELO attrh3i.attrh.att.com) (134.24.146.4) by server-9.tower-120.messagelabs.com with SMTP; 1 Feb 2007 18:07:18 -0000 Received: from attrh.att.com (localhost [127.0.0.1]) by attrh3i.attrh.att.com (8.13.7/8.13.7) with ESMTP id l11I7IC7023532; Thu, 1 Feb 2007 13:07:18 -0500 (EST) Received: from kcclust06evs1.ugd.att.com (kcst12.ugd.att.com [135.38.164.89]) by attrh3i.attrh.att.com (8.13.7/8.13.7) with ESMTP id l11I7CFf023490; Thu, 1 Feb 2007 13:07:13 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] Summary of QSPEC call Date: Thu, 1 Feb 2007 12:07:12 -0600 Message-ID: <9473683187ADC049A855ED2DA739ABCA0DDC8172@KCCLUST06EVS1.ugd.att.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] Summary of QSPEC call Thread-Index: AcdGGvxgF87jgxlHSYejsyQ9UXg8lAAB8xSQ From: "ASH, GERALD R \(JERRY\), SBCLABS" To: "Martin Stiemerling" , "nsis" X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: "ASH, GERALD R \(JERRY\), SBCLABS" X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Martin,=20 Thanks a lot for the summary. Please see below. > -----Original Message----- > From: Martin Stiemerling [mailto:stiemerling@netlab.nec.de]=20 > Sent: Thursday, February 01, 2007 11:05 AM > To: nsis > Subject: [NSIS] Summary of QSPEC call >=20 > Dear all, >=20 > Here is the short summary of the QSPEC phone conference call of =20 > January 31st. The call had been announced on the NSIS mailing=20 > list on =20 > January 23 > (http://www1.ietf.org/mail-archive/web/nsis/current/msg07527.html). >=20 > The participants of the call were: > Georgios Karagiannis, > Lars Westberg, > Attila Bader, > Magnus Westerlund, > Jerry Ash, > Bernd Schloer, > Hannes Tschofenig , > Cornelia Kappler, > John Loughney, > Andrew McDonald > Jukka Manner > Luis Cordeiro > Lars Eggert > Tom Phelan > Martin Stiemerling >=20 > After all we agreed to these points that need to be changed in QSPEC =20 > or QoS NSLP document: >=20 > - There is text required in the QoS NSLP about the relationship =20 > between the QoS NSLP and the RMF, i.e., how can the RMF trigger =20 > actions of the QoS NSLP. For instance, that the RMF can trigger a =20 > RESERVE. OK. > - The text in Section 4.1 "QoS Models", 2nd paragraph of the QSPEC =20 > draft needs to be changed so that "state machine" clearly references =20 > to "QoS NSLP state machine" OK. > - The QSPEC draft needs an informational section describing the API =20 > between QSPEC and QoS NSLP. This informational section should be in =20 > the spirit of the API description in GIST, i.e., giving guidance to =20 > implementers. Regarding the informational appendix on QoS-NSLP <--> QSPEC/RMF API, I had not understood that this was agreed to be added to the QSPEC document. IMO this belongs in the QoS NSLP document since it is primarily signaling related and analogous to the GIST Appendix B ("API between GIST and Signaling Applications"). Note that the GIST Appendix B describes several (signaling) primitives (SendMessage, RecvMessage, MessageStatus, NetworkNotification, SetStateLifetime, InvalidateRoutingState), analogous signaling primitives would better be illustrated in QoS NSLP. Thanks, Jerry >=20 > Please confirm the points or send your objection with a=20 > reason to the =20 > NSIS working group list. >=20 > Thanks, >=20 > Martin > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Feb 01 16:58:31 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCjvw-0003x3-2P; Thu, 01 Feb 2007 16:57:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCjvt-0003wy-Vv for nsis@ietf.org; Thu, 01 Feb 2007 16:57:29 -0500 Received: from rsys002x.roke.co.uk ([193.118.201.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCjvq-000064-C1 for nsis@ietf.org; Thu, 01 Feb 2007 16:57:29 -0500 Received: from rsys005a.comm.ad.roke.co.uk (rsys005a [193.118.193.85]) by rsys002x.roke.co.uk (8.13.1/8.13.1) with ESMTP id l11LvACl005126; Thu, 1 Feb 2007 21:57:11 GMT Received: from [127.0.0.1] ([193.118.192.66]) by rsys005a.comm.ad.roke.co.uk with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Feb 2007 21:57:10 +0000 Message-ID: <45C26236.2060206@roke.co.uk> Date: Thu, 01 Feb 2007 21:57:10 +0000 From: Andrew McDonald User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: "ASH, GERALD R \(JERRY\), SBCLABS" , Martin Stiemerling Subject: Re: [NSIS] Summary of QSPEC call References: <9473683187ADC049A855ED2DA739ABCA0DDC8172@KCCLUST06EVS1.ugd.att.com> In-Reply-To: <9473683187ADC049A855ED2DA739ABCA0DDC8172@KCCLUST06EVS1.ugd.att.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Feb 2007 21:57:10.0866 (UTC) FILETIME=[EC8F6320:01C7464B] X-MailScanner-roke-co-uk: Found to be clean X-MailScanner-roke-co-uk-SpamCheck: X-MailScanner-From: andrew.mcdonald@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: nsis X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi, ASH, GERALD R (JERRY), SBCLABS wrote: >> - The QSPEC draft needs an informational section describing the API >> between QSPEC and QoS NSLP. This informational section should be in >> the spirit of the API description in GIST, i.e., giving guidance to >> implementers. > > Regarding the informational appendix on QoS-NSLP <--> QSPEC/RMF API, I > had not understood that this was agreed to be added to the QSPEC > document. IMO this belongs in the QoS NSLP document since it is > primarily signaling related and analogous to the GIST Appendix B ("API > between GIST and Signaling Applications"). Note that the GIST Appendix > B describes several (signaling) primitives (SendMessage, RecvMessage, > MessageStatus, NetworkNotification, SetStateLifetime, > InvalidateRoutingState), analogous signaling primitives would better be > illustrated in QoS NSLP. I'm in agreement with Jerry here - I believe the discussion was about this going in to the QoS NSLP document. Andrew _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Feb 02 01:59:41 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCsO5-0005Cf-QG; Fri, 02 Feb 2007 01:59:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCsO4-0005Ca-Rm for nsis@ietf.org; Fri, 02 Feb 2007 01:59:08 -0500 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCsO0-0008RD-Bl for nsis@ietf.org; Fri, 02 Feb 2007 01:59:08 -0500 Received: from [192.168.1.3] (pD9E35015.dip.t-dialin.net [217.227.80.21]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 49BDB13CF81; Fri, 2 Feb 2007 07:59:33 +0100 (CET) In-Reply-To: <45C26236.2060206@roke.co.uk> References: <9473683187ADC049A855ED2DA739ABCA0DDC8172@KCCLUST06EVS1.ugd.att.com> <45C26236.2060206@roke.co.uk> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Martin Stiemerling Subject: Re: [NSIS] Summary of QSPEC call Date: Fri, 2 Feb 2007 07:58:58 +0100 To: Andrew McDonald X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: "ASH, GERALD R \(JERRY\), SBCLABS" , nsis X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi all, Am 01.02.2007 um 22:57 schrieb Andrew McDonald: > Hi, > > ASH, GERALD R (JERRY), SBCLABS wrote: >>> - The QSPEC draft needs an informational section describing the >>> API between QSPEC and QoS NSLP. This informational section >>> should be in the spirit of the API description in GIST, i.e., >>> giving guidance to implementers. >> Regarding the informational appendix on QoS-NSLP <--> QSPEC/RMF >> API, I >> had not understood that this was agreed to be added to the QSPEC >> document. IMO this belongs in the QoS NSLP document since it is >> primarily signaling related and analogous to the GIST Appendix B >> ("API >> between GIST and Signaling Applications"). Note that the GIST >> Appendix >> B describes several (signaling) primitives (SendMessage, RecvMessage, >> MessageStatus, NetworkNotification, SetStateLifetime, >> InvalidateRoutingState), analogous signaling primitives would >> better be >> illustrated in QoS NSLP. > > I'm in agreement with Jerry here - I believe the discussion was > about this going in to the QoS NSLP document. Yes, Jerry and you are right. I actually thought the same after pressing the send button... Thanks, Martin > > > Andrew stiemerling@netlab.nec.de NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Feb 02 07:40:18 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCxhV-00021E-He; Fri, 02 Feb 2007 07:39:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCxhU-000218-Nl for nsis@ietf.org; Fri, 02 Feb 2007 07:39:32 -0500 Received: from rotterdam.ewi.utwente.nl ([130.89.10.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCxhT-0005qw-7q for nsis@ietf.org; Fri, 02 Feb 2007 07:39:32 -0500 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by rotterdam.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id l12CctKv025504; Fri, 2 Feb 2007 13:39:09 +0100 (MET) From: "Georgios Karagiannis" To: "'Martin Stiemerling'" , "'nsis'" References: Subject: RE: [NSIS] Summary of QSPEC call Date: Fri, 2 Feb 2007 13:39:10 +0100 Message-ID: <000c01c746c7$2900e830$4c0d5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcdGGryQhgw+OPkFRhCptURzmnnffQAq5hKA X-Spam-Score: 0.234 () AWL,FVGT_s_OBFU_Q1 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (rotterdam.ewi.utwente.nl [130.89.10.5]); Fri, 02 Feb 2007 13:39:09 +0100 (MET) X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Martin In big lines I agree with the listed outcomes, but I thought that I also proposed to include a sentence that is associated with what we mean by QoS-NSLP protocol state machine. In particular, I proposed to add something like: "Note that the reactions of the QOS-NSLP to triggers from a QOSM are not considered to be a part of the QoS-NSLP state machine." Thus I would also like to see the following modification on the QSPEC template draft: Modify the following sentence in all sections of the QSPEC template draft: FROM: "QOSMs all utilize the common data, state machines, and APIs of the underlying NSIS protocols and are not expected to re-define or extend these in any way." INTO: "QOSMs all utilize the state machines of the underlying NSIS protocols and are not expected to re-define or extend these in any way. Note that the reactions of the QOS-NSLP to triggers from a QOSM are not considered to be a part of the QoS-NSLP state machine." Note that common data and API are internal features that cannot be standardised and therefore must be Removed. The note that I have added is required to clarify what we mean by QOS-NSLP state machine! Regarding the control information, we did not have to discuss them, but: I hope that the old semantics of control information will be reincluded in the next version of QSPEC template draft. Best Regards, Georgios > -----Original Message----- > From: Martin Stiemerling [mailto:stiemerling@netlab.nec.de] > Sent: donderdag 1 februari 2007 17:05 > To: nsis > Subject: [NSIS] Summary of QSPEC call > > Dear all, > > Here is the short summary of the QSPEC phone conference call > of January 31st. The call had been announced on the NSIS > mailing list on January 23 > (http://www1.ietf.org/mail-archive/web/nsis/current/msg07527.html). > > The participants of the call were: > Georgios Karagiannis, > Lars Westberg, > Attila Bader, > Magnus Westerlund, > Jerry Ash, > Bernd Schloer, > Hannes Tschofenig , Cornelia > Kappler, John Loughney, Andrew McDonald Jukka Manner Luis > Cordeiro Lars Eggert Tom Phelan Martin Stiemerling > > After all we agreed to these points that need to be changed > in QSPEC or QoS NSLP document: > > - There is text required in the QoS NSLP about the > relationship between the QoS NSLP and the RMF, i.e., how can > the RMF trigger actions of the QoS NSLP. For instance, that > the RMF can trigger a RESERVE. > - The text in Section 4.1 "QoS Models", 2nd paragraph of the > QSPEC draft needs to be changed so that "state machine" > clearly references to "QoS NSLP state machine" > - The QSPEC draft needs an informational section describing > the API between QSPEC and QoS NSLP. This informational > section should be in the spirit of the API description in > GIST, i.e., giving guidance to implementers. > > Please confirm the points or send your objection with a > reason to the NSIS working group list. > > Thanks, > > Martin > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Feb 02 08:33:52 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCyXP-0006YE-1P; Fri, 02 Feb 2007 08:33:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCyXO-0006Y7-5L for nsis@ietf.org; Fri, 02 Feb 2007 08:33:10 -0500 Received: from rotterdam.ewi.utwente.nl ([130.89.10.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCyXM-000142-Nv for nsis@ietf.org; Fri, 02 Feb 2007 08:33:10 -0500 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by rotterdam.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id l12DWLEJ028009; Fri, 2 Feb 2007 14:32:38 +0100 (MET) From: "Georgios Karagiannis" To: "'Martin Stiemerling'" , "'Andrew McDonald'" References: <9473683187ADC049A855ED2DA739ABCA0DDC8172@KCCLUST06EVS1.ugd.att.com><45C26236.2060206@roke.co.uk> Subject: RE: [NSIS] Summary of QSPEC call Date: Fri, 2 Feb 2007 14:32:37 +0100 Message-ID: <001601c746ce$a3f41c40$4c0d5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcdGl+id3hPeefjrQG+cRmmWF2gi8gANa6qQ X-Spam-Score: 0.233 () AWL,FVGT_s_OBFU_Q1 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (rotterdam.ewi.utwente.nl [130.89.10.5]); Fri, 02 Feb 2007 14:32:38 +0100 (MET) X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: "'ASH, GERALD R \(JERRY\), SBCLABS'" , 'nsis' X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi all I also agree with Jerry here! However, I had a comment on some paragraphs that are currently included in the QSPEC draft and refer to the API and common data, please see my previous e-mail that has been sent as reply to Martin's e-mail! Regarding the QSPEC control information please reintroduce the old semantics in the next QSPEC version. Best Regards, Georgios > -----Original Message----- > From: Martin Stiemerling [mailto:stiemerling@netlab.nec.de] > Sent: vrijdag 2 februari 2007 7:59 > To: Andrew McDonald > Cc: ASH, GERALD R (JERRY), SBCLABS; nsis > Subject: Re: [NSIS] Summary of QSPEC call > > Hi all, > > Am 01.02.2007 um 22:57 schrieb Andrew McDonald: > > > Hi, > > > > ASH, GERALD R (JERRY), SBCLABS wrote: > >>> - The QSPEC draft needs an informational section > describing the API > >>> between QSPEC and QoS NSLP. This informational section > should be in > >>> the spirit of the API description in GIST, i.e., giving > guidance to > >>> implementers. > >> Regarding the informational appendix on QoS-NSLP <--> > QSPEC/RMF API, > >> I had not understood that this was agreed to be added to the QSPEC > >> document. IMO this belongs in the QoS NSLP document since it is > >> primarily signaling related and analogous to the GIST Appendix B > >> ("API between GIST and Signaling Applications"). Note > that the GIST > >> Appendix B describes several (signaling) primitives (SendMessage, > >> RecvMessage, MessageStatus, NetworkNotification, SetStateLifetime, > >> InvalidateRoutingState), analogous signaling primitives > would better > >> be illustrated in QoS NSLP. > > > > I'm in agreement with Jerry here - I believe the discussion > was about > > this going in to the QoS NSLP document. > > Yes, Jerry and you are right. I actually thought the same > after pressing the send button... > > Thanks, > > Martin > > > > > > > Andrew > > > > stiemerling@netlab.nec.de > NEC Europe Limited | > Registered Office: NEC House, 1 Victoria Road, London W3 6BL > | Registered in England 2832014 > > > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Feb 02 09:23:12 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCzJ9-0003qL-CU; Fri, 02 Feb 2007 09:22:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCzJ8-0003qF-QR for nsis@ietf.org; Fri, 02 Feb 2007 09:22:30 -0500 Received: from david.siemens.de ([192.35.17.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCzJ4-00033K-7Y for nsis@ietf.org; Fri, 02 Feb 2007 09:22:30 -0500 Received: from mail3.siemens.de (localhost [127.0.0.1]) by david.siemens.de (8.12.6/8.12.6) with ESMTP id l12EMIhP000871; Fri, 2 Feb 2007 15:22:18 +0100 Received: from mchp7wta.ww002.siemens.net (mchp7wta.ww002.siemens.net [139.25.131.193]) by mail3.siemens.de (8.12.6/8.12.6) with ESMTP id l12EMILm029841; Fri, 2 Feb 2007 15:22:18 +0100 Received: from blns00fa.ww002.siemens.net ([147.54.45.102]) by mchp7wta.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 2 Feb 2007 15:22:17 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: AW: [NSIS] Summary of QSPEC call Date: Fri, 2 Feb 2007 15:22:16 +0100 Message-ID: In-Reply-To: <000c01c746c7$2900e830$4c0d5982@dynamic.ewi.utwente.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] Summary of QSPEC call Thread-Index: AcdGGryQhgw+OPkFRhCptURzmnnffQAq5hKAAAO2KIA= From: "Kappler, Cornelia" To: "Georgios Karagiannis" , "Martin Stiemerling" , "nsis" X-OriginalArrivalTime: 02 Feb 2007 14:22:17.0997 (UTC) FILETIME=[8B27D3D0:01C746D5] X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Georgios,=20 obviously, the reaction of QoS NSLP to triggers from QOSM would = influence the QoS NSLP statemachine. Furthermore, the reactions are part = of what QoS NSLP does. So how should I interpret the meaning of "they = are not part of the QoS NSLP state machine"?=20 Cornelia > -----Urspr=FCngliche Nachricht----- > Von: Georgios Karagiannis [mailto:karagian@cs.utwente.nl]=20 > Gesendet: Freitag, 2. Februar 2007 13:39 > An: 'Martin Stiemerling'; 'nsis' > Betreff: RE: [NSIS] Summary of QSPEC call >=20 > Hi Martin >=20 > In big lines I agree with the listed outcomes, but I thought=20 > that I also proposed to include a sentence that is associated=20 > with what we mean by QoS-NSLP protocol state machine. > In particular, I proposed to add something like: > "Note that the reactions of the QOS-NSLP to triggers from a QOSM are=20 > not considered to be a part of the QoS-NSLP state machine." >=20 > Thus I would also like to see the following modification on the QSPEC > template draft: > Modify the following sentence in all sections of the QSPEC=20 > template draft: >=20 > FROM: > "QOSMs all utilize the common > data, state machines, and APIs of the underlying NSIS protocols and > are not expected to re-define or extend these in any way." >=20 > INTO: > "QOSMs all utilize the > state machines of the underlying NSIS protocols and are not expected=20 > to re-define or extend these in any way. > Note that the reactions of the QOS-NSLP to triggers from a QOSM are=20 > not considered to be a part of the QoS-NSLP state machine." >=20 >=20 > Note that common data and API are internal features that cannot be=20 > standardised and therefore must be Removed. The note that I=20 > have added=20 > is required to clarify what we mean by QOS-NSLP state machine!=20 >=20 > Regarding the control information, we did not have to discuss=20 > them, but: > I hope that the old=20 > semantics of control information will be reincluded in the next=20 > version of QSPEC template draft. >=20 > Best Regards, > Georgios >=20 > > -----Original Message----- > > From: Martin Stiemerling [mailto:stiemerling@netlab.nec.de]=20 > > Sent: donderdag 1 februari 2007 17:05 > > To: nsis > > Subject: [NSIS] Summary of QSPEC call > >=20 > > Dear all, > >=20 > > Here is the short summary of the QSPEC phone conference call=20 > > of January 31st. The call had been announced on the NSIS=20 > > mailing list on January 23=20 > > (http://www1.ietf.org/mail-archive/web/nsis/current/msg07527.html). > >=20 > > The participants of the call were: > > Georgios Karagiannis, > > Lars Westberg, > > Attila Bader, > > Magnus Westerlund, > > Jerry Ash, > > Bernd Schloer, > > Hannes Tschofenig , Cornelia=20 > > Kappler, John Loughney, Andrew McDonald Jukka Manner Luis=20 > > Cordeiro Lars Eggert Tom Phelan Martin Stiemerling > >=20 > > After all we agreed to these points that need to be changed=20 > > in QSPEC or QoS NSLP document: > >=20 > > - There is text required in the QoS NSLP about the=20 > > relationship between the QoS NSLP and the RMF, i.e., how can=20 > > the RMF trigger actions of the QoS NSLP. For instance, that=20 > > the RMF can trigger a RESERVE. > > - The text in Section 4.1 "QoS Models", 2nd paragraph of the=20 > > QSPEC draft needs to be changed so that "state machine"=20 > > clearly references to "QoS NSLP state machine" > > - The QSPEC draft needs an informational section describing=20 > > the API between QSPEC and QoS NSLP. This informational=20 > > section should be in the spirit of the API description in=20 > > GIST, i.e., giving guidance to implementers. > >=20 > > Please confirm the points or send your objection with a=20 > > reason to the NSIS working group list. > >=20 > > Thanks, > >=20 > > Martin > >=20 > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > >=20 >=20 >=20 >=20 > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Feb 02 09:37:10 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCzWR-0000pV-C3; Fri, 02 Feb 2007 09:36:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCzWP-0000pI-W5 for nsis@ietf.org; Fri, 02 Feb 2007 09:36:13 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCzWO-0005zq-HG for nsis@ietf.org; Fri, 02 Feb 2007 09:36:13 -0500 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-4.cisco.com with ESMTP; 02 Feb 2007 06:36:12 -0800 X-IronPort-AV: i="4.13,273,1167638400"; d="scan'208"; a="36904799:sNHT59355675" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id l12Ea8ok030347; Fri, 2 Feb 2007 06:36:08 -0800 Received: from [10.32.245.158] (stealth-10-32-245-158.cisco.com [10.32.245.158]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l12Ea2nF027917; Fri, 2 Feb 2007 06:36:09 -0800 (PST) In-Reply-To: <000c01c746c7$2900e830$4c0d5982@dynamic.ewi.utwente.nl> References: <000c01c746c7$2900e830$4c0d5982@dynamic.ewi.utwente.nl> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9CB9B724-4F35-43A5-B7FB-DB5C5222235E@cisco.com> Content-Transfer-Encoding: 7bit From: David R Oran Subject: Re: [NSIS] Summary of QSPEC call Date: Fri, 2 Feb 2007 09:35:56 -0500 To: "Georgios Karagiannis" X-Mailer: Apple Mail (2.752.2) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3955; t=1170426968; x=1171290968; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=oran@cisco.com; z=From:=20David=20R=20Oran=20 |Subject:=20Re=3A=20[NSIS]=20Summary=20of=20QSPEC=20call |Sender:=20; bh=tLMuGGeZcm0GlEO60Drv8Ku7f90G4e2QixplFDH+UJA=; b=d4h+G0agM4YkF7OkCnjvbGlyb7UgSjQU/KV8c6/2naBBxn3AZv1XWQuysPGxJrzdl0jcR+Dr 44mHpV0apiHMbxU6p6nOsR44+O9D2+5qgdscmDBy+91sDye292HxiJj6; Authentication-Results: sj-dkim-5; header.From=oran@cisco.com; dkim=pass (si g from cisco.com/sjdkim5002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Cc: 'Martin Stiemerling' , 'nsis' X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org On Feb 2, 2007, at 7:39 AM, Georgios Karagiannis wrote: > Hi Martin > > In big lines I agree with the listed outcomes, but I thought > that I also proposed to include a sentence that is associated > with what we mean by QoS-NSLP protocol state machine. > In particular, I proposed to add something like: > "Note that the reactions of the QOS-NSLP to triggers from a QOSM are > not considered to be a part of the QoS-NSLP state machine." > I think there's a language problem here. If by "triggers from a QOSM" you mean "event inputs to from RMF to QOS-NSLP protocol machine", and by "not considered part of the state machine" you mean "such inputs do not appear in the global FSM for QOS-NSLP", then if I suggested such in CS301 on finite autonoma I would have been flunked from the course. Could you take another crack at what you mean here? Thanks, Dave. > Thus I would also like to see the following modification on the QSPEC > template draft: > Modify the following sentence in all sections of the QSPEC template > draft: > > FROM: > "QOSMs all utilize the common > data, state machines, and APIs of the underlying NSIS protocols and > are not expected to re-define or extend these in any way." > > INTO: > "QOSMs all utilize the > state machines of the underlying NSIS protocols and are not expected > to re-define or extend these in any way. > Note that the reactions of the QOS-NSLP to triggers from a QOSM are > not considered to be a part of the QoS-NSLP state machine." > > > Note that common data and API are internal features that cannot be > standardised and therefore must be Removed. The note that I have added > is required to clarify what we mean by QOS-NSLP state machine! > > Regarding the control information, we did not have to discuss them, > but: > I hope that the old > semantics of control information will be reincluded in the next > version of QSPEC template draft. > > Best Regards, > Georgios > >> -----Original Message----- >> From: Martin Stiemerling [mailto:stiemerling@netlab.nec.de] >> Sent: donderdag 1 februari 2007 17:05 >> To: nsis >> Subject: [NSIS] Summary of QSPEC call >> >> Dear all, >> >> Here is the short summary of the QSPEC phone conference call >> of January 31st. The call had been announced on the NSIS >> mailing list on January 23 >> (http://www1.ietf.org/mail-archive/web/nsis/current/msg07527.html). >> >> The participants of the call were: >> Georgios Karagiannis, >> Lars Westberg, >> Attila Bader, >> Magnus Westerlund, >> Jerry Ash, >> Bernd Schloer, >> Hannes Tschofenig , Cornelia >> Kappler, John Loughney, Andrew McDonald Jukka Manner Luis >> Cordeiro Lars Eggert Tom Phelan Martin Stiemerling >> >> After all we agreed to these points that need to be changed >> in QSPEC or QoS NSLP document: >> >> - There is text required in the QoS NSLP about the >> relationship between the QoS NSLP and the RMF, i.e., how can >> the RMF trigger actions of the QoS NSLP. For instance, that >> the RMF can trigger a RESERVE. >> - The text in Section 4.1 "QoS Models", 2nd paragraph of the >> QSPEC draft needs to be changed so that "state machine" >> clearly references to "QoS NSLP state machine" >> - The QSPEC draft needs an informational section describing >> the API between QSPEC and QoS NSLP. This informational >> section should be in the spirit of the API description in >> GIST, i.e., giving guidance to implementers. >> >> Please confirm the points or send your objection with a >> reason to the NSIS working group list. >> >> Thanks, >> >> Martin >> >> _______________________________________________ >> nsis mailing list >> nsis@ietf.org >> https://www1.ietf.org/mailman/listinfo/nsis >> > > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Feb 02 10:23:00 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HD0Ex-00067s-Lw; Fri, 02 Feb 2007 10:22:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HD0Ew-00067Z-Bt for nsis@ietf.org; Fri, 02 Feb 2007 10:22:14 -0500 Received: from rotterdam.ewi.utwente.nl ([130.89.10.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HD0Ej-0006jP-5g for nsis@ietf.org; Fri, 02 Feb 2007 10:22:14 -0500 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by rotterdam.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id l12FLP23003401; Fri, 2 Feb 2007 16:21:30 +0100 (MET) From: "Georgios Karagiannis" To: "'Kappler, Cornelia'" , References: <000c01c746c7$2900e830$4c0d5982@dynamic.ewi.utwente.nl> Subject: RE: [NSIS] Summary of QSPEC call Date: Fri, 2 Feb 2007 16:21:41 +0100 Message-ID: <003201c746dd$da2716a0$4c0d5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcdGGryQhgw+OPkFRhCptURzmnnffQAq5hKAAAO2KIAAAc6SoA== X-Spam-Score: 0.234 () AWL,FVGT_s_OBFU_Q1 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (rotterdam.ewi.utwente.nl [130.89.10.5]); Fri, 02 Feb 2007 16:21:31 +0100 (MET) X-Spam-Score: 0.0 (/) X-Scan-Signature: 225414c974e0d6437992164e91287a51 Cc: 'nsis' X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Cornelia and Dave Agree that the last added sentence is a bit vague! What I am trying to say is that a QOSM is allowed to define new=20 RMF triggers that could influence the reaction of the QOS-NSLP. Maybe the following changed paragraph is more clear: "QOSMs all utilize the state machines of the underlying NSIS protocols and are not=20 expected to re-define or extend these in any way. Note that a QOSM can however, extend the RMF triggers=20 to/from the QOS-NSLP functionality, which might affect the QoS-NSLP state machine." Best Regards, Georgios > -----Original Message----- > From: Kappler, Cornelia [mailto:cornelia.kappler@siemens.com]=20 > Sent: vrijdag 2 februari 2007 15:22 > To: Georgios Karagiannis; Martin Stiemerling; nsis > Subject: AW: [NSIS] Summary of QSPEC call >=20 > Hi Georgios,=20 >=20 > obviously, the reaction of QoS NSLP to triggers from QOSM=20 > would influence the QoS NSLP statemachine. Furthermore, the=20 > reactions are part of what QoS NSLP does. So how should I=20 > interpret the meaning of "they are not part of the QoS NSLP=20 > state machine"?=20 >=20 > Cornelia >=20 > > -----Urspr=FCngliche Nachricht----- > > Von: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > > Gesendet: Freitag, 2. Februar 2007 13:39 > > An: 'Martin Stiemerling'; 'nsis' > > Betreff: RE: [NSIS] Summary of QSPEC call > >=20 > > Hi Martin > >=20 > > In big lines I agree with the listed outcomes, but I thought that I=20 > > also proposed to include a sentence that is associated with what we=20 > > mean by QoS-NSLP protocol state machine. > > In particular, I proposed to add something like: > > "Note that the reactions of the QOS-NSLP to triggers from a=20 > QOSM are=20 > > not considered to be a part of the QoS-NSLP state machine." > >=20 > > Thus I would also like to see the following modification on=20 > the QSPEC=20 > > template draft: > > Modify the following sentence in all sections of the QSPEC template=20 > > draft: > >=20 > > FROM: > > "QOSMs all utilize the common > > data, state machines, and APIs of the underlying NSIS protocols and=20 > > are not expected to re-define or extend these in any way." > >=20 > > INTO: > > "QOSMs all utilize the > > state machines of the underlying NSIS protocols and are not=20 > expected=20 > > to re-define or extend these in any way. > > Note that the reactions of the QOS-NSLP to triggers from a QOSM are=20 > > not considered to be a part of the QoS-NSLP state machine." > >=20 > >=20 > > Note that common data and API are internal features that cannot be=20 > > standardised and therefore must be Removed. The note that I=20 > have added=20 > > is required to clarify what we mean by QOS-NSLP state machine! > >=20 > > Regarding the control information, we did not have to discuss them,=20 > > but: > > I hope that the old > > semantics of control information will be reincluded in the next=20 > > version of QSPEC template draft. > >=20 > > Best Regards, > > Georgios > >=20 > > > -----Original Message----- > > > From: Martin Stiemerling [mailto:stiemerling@netlab.nec.de] > > > Sent: donderdag 1 februari 2007 17:05 > > > To: nsis > > > Subject: [NSIS] Summary of QSPEC call > > >=20 > > > Dear all, > > >=20 > > > Here is the short summary of the QSPEC phone conference call of=20 > > > January 31st. The call had been announced on the NSIS=20 > mailing list=20 > > > on January 23=20 > > >=20 > (http://www1.ietf.org/mail-archive/web/nsis/current/msg07527.html). > > >=20 > > > The participants of the call were: > > > Georgios Karagiannis, > > > Lars Westberg, > > > Attila Bader, > > > Magnus Westerlund, > > > Jerry Ash, > > > Bernd Schloer, > > > Hannes Tschofenig ,=20 > Cornelia Kappler,=20 > > > John Loughney, Andrew McDonald Jukka Manner Luis Cordeiro Lars=20 > > > Eggert Tom Phelan Martin Stiemerling > > >=20 > > > After all we agreed to these points that need to be=20 > changed in QSPEC=20 > > > or QoS NSLP document: > > >=20 > > > - There is text required in the QoS NSLP about the relationship=20 > > > between the QoS NSLP and the RMF, i.e., how can the RMF trigger=20 > > > actions of the QoS NSLP. For instance, that the RMF can trigger a=20 > > > RESERVE. > > > - The text in Section 4.1 "QoS Models", 2nd paragraph of=20 > the QSPEC=20 > > > draft needs to be changed so that "state machine" > > > clearly references to "QoS NSLP state machine" > > > - The QSPEC draft needs an informational section=20 > describing the API=20 > > > between QSPEC and QoS NSLP. This informational section=20 > should be in=20 > > > the spirit of the API description in GIST, i.e., giving=20 > guidance to=20 > > > implementers. > > >=20 > > > Please confirm the points or send your objection with a reason to=20 > > > the NSIS working group list. > > >=20 > > > Thanks, > > >=20 > > > Martin > > >=20 > > > _______________________________________________ > > > nsis mailing list > > > nsis@ietf.org > > > https://www1.ietf.org/mailman/listinfo/nsis > > >=20 > >=20 > >=20 > >=20 > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > >=20 >=20 > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Feb 02 11:27:15 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HD1Eh-0004LB-Q8; Fri, 02 Feb 2007 11:26:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HD1Eh-0004IV-0z for nsis@ietf.org; Fri, 02 Feb 2007 11:26:03 -0500 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HD1Ef-0002X5-5L for nsis@ietf.org; Fri, 02 Feb 2007 11:26:03 -0500 Received: (qmail invoked by alias); 02 Feb 2007 16:25:59 -0000 Received: from unknown (EHLO [192.168.157.14]) [207.203.89.1] by mail.gmx.net (mp019) with SMTP; 02 Feb 2007 17:25:59 +0100 X-Authenticated: #29516787 Message-ID: <45C36614.1020102@gmx.net> Date: Fri, 02 Feb 2007 11:25:56 -0500 From: Hannes Tschofenig User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: "Kappler, Cornelia" Subject: State Machines .... was [NSIS] Summary of QSPEC call References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: Martin Stiemerling , Georgios Karagiannis , nsis X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi all, let me repeat again what I said during the phone conference call. The QoS NSLP implicitly contains a state machine and an explicit description of the QoS NSLP state machine can be found in: http://tools.ietf.org/wg/nsis/draft-fu-nsis-qos-nslp-statemachine-05.txt http://www.ietf.org/internet-drafts/draft-fu-nsis-qos-nslp-statemachine-05.pdf The QoS NSLP alone is not useful. In order todo something it needs to (a) carry some QoS parameters with the corresponding meaning and (b) the state transitions need to be triggered. These triggers might come from various sources. Some of the triggers have been discussed in the context of RMD when an edge node of an RMD domain receives an end-to-end signaling message. Some actions might have to be taken within the RMD domain based on this incoming message. The type of message, the content of the QoS parameters, security parameters, the reservation state within the RMD domain, etc. influence the decision making process. The QoSM has its own state machine and it interacts with the QoS NSLP whereby these actions have to fit to the QoS NSLP state machine but there is a lot of freedom since the QoS NSLP just defines basic message patterns. Hence, when someone says that the QoSM MUST NOT modify the QoS NSLP state machine it would be good to be very explicit what that actually means. This procdure of interworking between different state machines at different components is nothing new. Diameter (RFC 3588 and the applications) and EAP - EAP methods do the same. Ciao Hannes _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Feb 02 12:03:01 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HD1nu-0000dH-Rm; Fri, 02 Feb 2007 12:02:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HD1nt-0000cv-JD for nsis@ietf.org; Fri, 02 Feb 2007 12:02:25 -0500 Received: from rotterdam.ewi.utwente.nl ([130.89.10.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HD1nr-0008Qd-Nd for nsis@ietf.org; Fri, 02 Feb 2007 12:02:25 -0500 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by rotterdam.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id l12H1wZO007251; Fri, 2 Feb 2007 18:02:01 +0100 (MET) From: "Georgios Karagiannis" To: "'Hannes Tschofenig'" , "'Kappler, Cornelia'" References: <45C36614.1020102@gmx.net> Subject: RE: State Machines .... was [NSIS] Summary of QSPEC call Date: Fri, 2 Feb 2007 18:02:13 +0100 Message-ID: <004c01c746eb$e5a80080$4c0d5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <45C36614.1020102@gmx.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcdG5soSAk6xbee0QN+m/Zu12JPypAABJy7Q X-Spam-Score: 0.834 () AWL, FVGT_s_MIXCASEWORDS, FVGT_s_OBFU_ODD06, FVGT_s_OBFU_Q1, FVGT_u_HAS_2LETTERFLDR X-Scanned-By: MIMEDefang 2.52 on 130.89.10.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (rotterdam.ewi.utwente.nl [130.89.10.5]); Fri, 02 Feb 2007 18:02:02 +0100 (MET) X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: 'Martin Stiemerling' , 'nsis' X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Hannes Thank you for the clarification! I totally agtree with the below statements! > The QoSM has its own state machine and it interacts with the > QoS NSLP whereby these actions have to fit to the QoS NSLP > state machine but there is a lot of freedom since the QoS > NSLP just defines basic message patterns. > Hence, when someone says that the QoSM MUST NOT modify the > QoS NSLP state machine it would be good to be very explicit > what that actually means. That is why I tried to emphasize that an existing or future QOSM is allowed to extend the RMF triggers that can affect the QoS-NSLP state machine. Best Regards, Georgios > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > Sent: vrijdag 2 februari 2007 17:26 > To: Kappler, Cornelia > Cc: Georgios Karagiannis; Martin Stiemerling; nsis > Subject: State Machines .... was [NSIS] Summary of QSPEC call > > Hi all, > > let me repeat again what I said during the phone conference call. > > The QoS NSLP implicitly contains a state machine and an > explicit description of the QoS NSLP state machine can be found in: > http://tools.ietf.org/wg/nsis/draft-fu-nsis-qos-nslp-statemach > ine-05.txt > http://www.ietf.org/internet-drafts/draft-fu-nsis-qos-nslp-sta > temachine-05.pdf > > The QoS NSLP alone is not useful. In order todo something it needs to > (a) carry some QoS parameters with the corresponding meaning > and (b) the state transitions need to be triggered. These > triggers might come from various sources. Some of the > triggers have been discussed in the context of RMD when an > edge node of an RMD domain receives an end-to-end signaling > message. Some actions might have to be taken within the RMD > domain based on this incoming message. The type of message, > the content of the QoS parameters, security parameters, the > reservation state within the RMD domain, etc. influence the > decision making process. > > The QoSM has its own state machine and it interacts with the > QoS NSLP whereby these actions have to fit to the QoS NSLP > state machine but there is a lot of freedom since the QoS > NSLP just defines basic message patterns. > > Hence, when someone says that the QoSM MUST NOT modify the > QoS NSLP state machine it would be good to be very explicit > what that actually means. > > This procdure of interworking between different state > machines at different components is nothing new. Diameter > (RFC 3588 and the > applications) and EAP - EAP methods do the same. > > Ciao > Hannes > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Feb 02 16:48:07 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HD6Fb-0007nY-5i; Fri, 02 Feb 2007 16:47:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HD6FZ-0007iE-8B for nsis@ietf.org; Fri, 02 Feb 2007 16:47:17 -0500 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HD6FX-0004qD-MZ for nsis@ietf.org; Fri, 02 Feb 2007 16:47:17 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l12LiA5K014801; Fri, 2 Feb 2007 23:44:12 +0200 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 2 Feb 2007 23:46:50 +0200 Received: from daebe103.NOE.Nokia.com ([10.241.35.24]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 2 Feb 2007 15:46:47 -0600 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: State Machines .... was [NSIS] Summary of QSPEC call Date: Fri, 2 Feb 2007 15:46:46 -0600 Message-ID: <071568CA7B789D4AA170CEF8C9613B4F20B508@daebe103.NOE.Nokia.com> In-Reply-To: <45C36614.1020102@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: State Machines .... was [NSIS] Summary of QSPEC call Thread-Index: AcdG5zF6DBwT6QRpSBuS5xvj4YwwRwAK9UJw References: <45C36614.1020102@gmx.net> From: To: , X-OriginalArrivalTime: 02 Feb 2007 21:46:47.0985 (UTC) FILETIME=[A3B50A10:01C74713] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070202234412-39A0BBB0-08008702/0-0/0-0 X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: stiemerling@netlab.nec.de, karagian@cs.utwente.nl, nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hannes, The issue is that if any QoSM deviates (for example having some signaling optimizations within the QoSM) from the defined QoS NSLP State Machine,=20 then those MUST be optional, and the QoSM needs to describe how the QoSM falls back to the standard State Machine. If the QOSM has a different state machine, then that QoSM MUST be a Standards Track document that extends the QoS NSLP. All QoSM must be able to handle 'standard' QoS NSLP messaging flows. If they modify (or introduce) new messaging flows, these flows should be optimizations (which are optional) and need to discuss how to fall back to standard messaging sequences. I believe we discussed this on the call and people seemed to agree. John >-----Original Message----- >From: ext Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 >Sent: 02 February, 2007 08:26 >To: Kappler, Cornelia >Cc: Martin Stiemerling; Georgios Karagiannis; nsis >Subject: State Machines .... was [NSIS] Summary of QSPEC call > >Hi all, > >let me repeat again what I said during the phone conference call. > >The QoS NSLP implicitly contains a state machine and an=20 >explicit description of the QoS NSLP state machine can be found in: >http://tools.ietf.org/wg/nsis/draft-fu-nsis-qos-nslp-statemachi >ne-05.txt >http://www.ietf.org/internet-drafts/draft-fu-nsis-qos-nslp-stat >emachine-05.pdf > >The QoS NSLP alone is not useful. In order todo something it needs to >(a) carry some QoS parameters with the corresponding meaning=20 >and (b) the state transitions need to be triggered. These=20 >triggers might come from various sources. Some of the triggers=20 >have been discussed in the context of RMD when an edge node of=20 >an RMD domain receives an end-to-end signaling message. Some=20 >actions might have to be taken within the RMD domain based on=20 >this incoming message. The type of message, the content of the=20 >QoS parameters, security parameters, the reservation state=20 >within the RMD domain, etc. influence the decision making process. > >The QoSM has its own state machine and it interacts with the=20 >QoS NSLP whereby these actions have to fit to the QoS NSLP=20 >state machine but there is a lot of freedom since the QoS NSLP=20 >just defines basic message patterns. > >Hence, when someone says that the QoSM MUST NOT modify the QoS=20 >NSLP state machine it would be good to be very explicit what=20 >that actually means. > >This procdure of interworking between different state machines=20 >at different components is nothing new. Diameter (RFC 3588 and the >applications) and EAP - EAP methods do the same. > >Ciao >Hannes > > >_______________________________________________ >nsis mailing list >nsis@ietf.org >https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Feb 02 17:43:50 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HD77Q-0007Gy-SN; Fri, 02 Feb 2007 17:42:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HD77P-0007Fk-Pg for nsis@ietf.org; Fri, 02 Feb 2007 17:42:55 -0500 Received: from smtp.dei.uc.pt ([193.137.203.228] helo=smtp2.dei.uc.pt) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HD75J-0004H5-Vy for nsis@ietf.org; Fri, 02 Feb 2007 17:40:47 -0500 Received: from kanito (bl5-40-117.dsl.telepac.pt [82.154.40.117]) (authenticated bits=0) by smtp2.dei.uc.pt (8.13.8/8.13.8) with ESMTP id l12MeHob006378; Fri, 2 Feb 2007 22:40:22 GMT Message-Id: <200702022240.l12MeHob006378@smtp2.dei.uc.pt> From: "David Palma" To: Date: Fri, 2 Feb 2007 22:40:15 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcdHGxtPD4UOGWp+QUSWXs/TDBuS7Q== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-FCTUC-DEI-SIC-MailScanner-Information: Please contact helpdesk@dei.uc.pt for more information X-FCTUC-DEI-SIC-MailScanner: Found to be clean X-FCTUC-DEI-SIC-MailScanner-SpamCheck: not spam (whitelisted), SpamAssassin (not cached, score=-27.387, required 3, autolearn=not spam, ALL_TRUSTED -1.80, AWL 24.41, BAYES_50 0.00, L_SMTP_AUTH -50.00) X-FCTUC-DEI-SIC-MailScanner-From: palma@student.dei.uc.pt X-Spam-Status: No X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: giuseppe.martufi@datamat.it Subject: [NSIS] NSLP AUTH Questions X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi all, I'm from the University of Coimbra and I've been working on QoS NSLP and recently on the NSLP AUTH extension objects to allow external authorization on QoS NSLP. Regarding the AUTH draft I have some questions about the parsing of the proposed objects. Is this parsing done inside QoS NSLP or, like QSPEC with RMF, done in an Authorization model? Are the AUTH objects opaque like the QSPEC? Another question is concerns the length of the Authorizing Entity Identifier (page 9) object, where it says: "...Length of the attribute, which MUST be > 4". If the octet string could be an IPv4 address, shouldn't we read "...MUST be >= 4"? Another issue is on the length of Source Address object, where the octet string could be a 16 bit port and consequently the length should be >= 2. Can anybody help me with these questions? Thank you in advance, David Palma -- Checked by AVG Free Edition. Version: 7.1.411 / Virus Database: 268.17.19/663 - Release Date: 01-02-2007 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Feb 02 19:38:21 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HD8uW-00005w-9d; Fri, 02 Feb 2007 19:37:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HD8uU-0008VB-Nf for nsis@ietf.org; Fri, 02 Feb 2007 19:37:42 -0500 Received: from mail121.messagelabs.com ([216.82.241.195]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HD8uT-0005B1-9H for nsis@ietf.org; Fri, 02 Feb 2007 19:37:42 -0500 X-VirusChecked: Checked X-Env-Sender: gash@att.com X-Msg-Ref: server-15.tower-121.messagelabs.com!1170463059!11291819!1 X-StarScan-Version: 5.5.10.7.1; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 16228 invoked from network); 3 Feb 2007 00:37:40 -0000 Received: from unknown (HELO attrh3i.attrh.att.com) (134.24.146.4) by server-15.tower-121.messagelabs.com with SMTP; 3 Feb 2007 00:37:40 -0000 Received: from attrh.att.com (localhost [127.0.0.1]) by attrh3i.attrh.att.com (8.13.7/8.13.7) with ESMTP id l130bde6018698; Fri, 2 Feb 2007 19:37:39 -0500 (EST) Received: from kcclust06evs1.ugd.att.com (kcst12.ugd.att.com [135.38.164.89]) by attrh3i.attrh.att.com (8.13.7/8.13.7) with ESMTP id l130baiU018686; Fri, 2 Feb 2007 19:37:36 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C7472B.801EAF70" Subject: RE: State Machines .... was [NSIS] Summary of QSPEC call Date: Fri, 2 Feb 2007 18:37:36 -0600 Message-ID: <9473683187ADC049A855ED2DA739ABCA0DDC818C@KCCLUST06EVS1.ugd.att.com> In-Reply-To: <9473683187ADC049A855ED2DA739ABCA0DDC818B@KCCLUST06EVS1.ugd.att.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: State Machines .... was [NSIS] Summary of QSPEC call Thread-Index: AcdG52ID3k5BeYFGQcSKMpuMyZMTRwAECO3QAAm62HAAAztwsA== From: "ASH, GERALD R \(JERRY\), SBCLABS" To: "Hannes Tschofenig" , "nsis" X-Spam-Score: 0.0 (/) X-Scan-Signature: 07d4bcb4600b627a0786c2557bc62e06 Cc: "ASH, GERALD R \(JERRY\), SBCLABS" X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C7472B.801EAF70 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Certainly this ID is very relevant to the discussion. According to the ID, the QoS NSLP state machine only receives 2 types of information from the RMF: RMF():Performs Resource Management Function and returns the following values{AVAIL, NO_AVAIL}.=20 Therefore it is not possible to trigger different QoS NSLP message responses when the QoS NSLP is in a particular state, based on input from the RMF that is dependent on the particular QOSM being used by the RMF. =20 As illustrated in Cornelia's slide 2 (3rd bullet) example in the attached, what RMD is doing would appear to be precluded by the current QoS NSLP state machine, i.e.: "This is a tearing RESERVE and the RMF tells me that the RMD control info says to not generate a new message" -> needed by RMD for partial resv. Release Since this behavior deviates from the defined QoS NSLP State Machine, as John says, "If the QOSM has a different state machine, then that QoSM MUST be a Standards Track document that extends the QoS NSLP." Thanks, Jerry -----Original Message----- From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 Sent: Friday, February 02, 2007 11:26 AM To: Kappler, Cornelia Cc: Martin Stiemerling; Georgios Karagiannis; nsis Subject: State Machines .... was [NSIS] Summary of QSPEC call Hi all, let me repeat again what I said during the phone conference call. The QoS NSLP implicitly contains a state machine and an explicit=20 description of the QoS NSLP state machine can be found in: http://tools.ietf.org/wg/nsis/draft-fu-nsis-qos-nslp-statemachine-05.txt http://www.ietf.org/internet-drafts/draft-fu-nsis-qos-nslp-statemachine- 05.pdf The QoS NSLP alone is not useful. In order todo something it needs to=20 (a) carry some QoS parameters with the corresponding meaning and (b) the state transitions need to be triggered. These triggers might come from=20 various sources. Some of the triggers have been discussed in the context of RMD when an edge node of an RMD domain receives an end-to-end=20 signaling message. Some actions might have to be taken within the RMD=20 domain based on this incoming message. The type of message, the content=20 of the QoS parameters, security parameters, the reservation state within the RMD domain, etc. influence the decision making process. The QoSM has its own state machine and it interacts with the QoS NSLP=20 whereby these actions have to fit to the QoS NSLP state machine but=20 there is a lot of freedom since the QoS NSLP just defines basic message=20 patterns. Hence, when someone says that the QoSM MUST NOT modify the QoS NSLP=20 state machine it would be good to be very explicit what that actually=20 means. This procdure of interworking between different state machines at=20 different components is nothing new. Diameter (RFC 3588 and the=20 applications) and EAP - EAP methods do the same. Ciao Hannes _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis ------_=_NextPart_001_01C7472B.801EAF70 Content-Type: application/octet-stream; name="vgs.qspec.open issues.CK.013107.pdf" Content-Transfer-Encoding: base64 Content-Description: vgs.qspec.open issues.CK.013107.pdf Content-Disposition: attachment; filename="vgs.qspec.open issues.CK.013107.pdf" JVBERi0xLjMKJcfsj6IKNSAwIG9iago8PC9MZW5ndGggNiAwIFIvRmlsdGVyIC9GbGF0ZURlY29k ZT4+CnN0cmVhbQp4nM1Z224bRxJ9n6+YzcNiJggnfb88Gbah3UVgO5Ii7D4kQaClKFIGKTqkZCU/ ku9NVU9fajhDSY69wDpAVDNd3V1ddepU9fDXmnVc1Az/S8J8U317buvlvgqv6/N/RmG3rH6tXCfx X3hB5fmmfnUBE33tO2/qi2uYxOsZhyGtfGdq43xnYWBTNby9eF+dXFRnuHAnvfXKg3K/UXl+1n6c 18Ie7mhkJ6TXNfe6cwr3/LH5V8tAzVstmm07E52V0urmoeUdt9ropm5noGCZsKa5KgpbUNDa8WbR zgysyqVu9u2Mdx42GEw6y0vlOT+AYI1UdqD4rp3JTgquLVF4E+Z4rpvTyUnRZmV98yGoWqaTTUI1 OzSpf3kZrFNM6+YORWsUnHlR3r7I8+tWWPfzxXc5GJ8cbi5r7ga+54x1rlay4x4iEFw/g725wdMy XEKAOWCZAEtFZ4xR8XGRH2t83ODpQd1onzSdbOarLN60ornNT3BABZHRjOGBpKlnwnWivrjqDfAi LAZRgqW/x/9Fa3D5t2QrCK5wrJmXLW8npG2W0HQnADLFkCAx0VzjNsRKFsIgrA2WDF5yBrKVgMeZ MArlZg8rO9Tw+fwseyqvMuEl0EpeYml/8E2xKx5xi293QR4tRZT3Zdnl1DmuA7K8s826jcKWHgjP oKUtsZnF4DCXoxPgkaIgNMVC3h9cu6TRTvt/yC/hLJZEZo7ZASIsvcgv9/shbJZloT+SqJoVumY7 GZYbGMK5UiU/hpCsngpxkn5rk1EROUfcXox/KgBXE7vQhILHXb+HYJLjfqYP002K1wE+4oJgz4uW JBOJ1yCbisdJSoUUftcO0uxNVjw9UNyNfYABLCIG7eMIwccRC+ehvtLa4EFCuej5ShgoDUBX4UQv WyEKGRJW47YzKmn91Exu1+EBltll4TEc6hxsPikHJY44wRCAzHhQ+jcdyeJPbQtSxxgPSSOc7JR6 jNW+QByKwwcwTTS0m6bkALYYkrMDaj2dPNvrNvqoQPv2EH4sqnzIj5ckxCMsIEJiRt0RbzASDErz /8B6CrJ3OB7z4C5L28mUI9kV9VYTo5lSBWG/nGt3IaU0953K+FuVZN6XnTckaUm6X0446mNhi8hP 1lvMnwj8mUL0uMM0Rn0SlSNIDtG3HHsljap2wpqefUl2TCjUBUhnCZXnzwZCsuL3DMziqXv0uBrQ wX3BR0TFVCCnCHoC5LTuwj6X1K4Y1rMJ6PRpEOJ3nsJPcDtNzx9DI3NVHFjW+2+W3o+Xm0dgQefl MmV9BXq9s77J9gWey7SirUf9I/x+LGu47aNGC/K4SVpMYqMAIvk0V9IBVsTxDkm7x3kms+vn88yo h6CMkzuBR4jnCWAUBL1LMSWjb/KU0xb+wrjHqPU14E118fX/pAoM2iz13ICOu45hVJNDjkbV8r/Q ho4rO6ATC2XIgOYVXjVpQXdPV/NEUo/X9BAfEqrTIn7/aEzJdCjxM4qEVCwi0wpaNUrFIe1laNvG XaojqJs2kRjxup0kBgm3dkWJAZDW+1KnFkp02iR3/geZocdGuaFtR03qAERzrNlXpPfE/rzHzEPJ rbIcZY7Sq9kUWi06dhh3PYo77rl/McpRMUrPpxInJGV+ebDiI+3GQDNVtVdlpe0wnVakGS8TSaQI umdcA1sd9IjIXZPRGRKx66+KpJsqeV+uWPeHc6Yo7/iF6GU55rqliVxWoMySejqy2AbveP21JCIz 0yAe9EtR4BXF8MTd+XbC8uiR+f3kWSauOINqFM65LrD/Hb0m+54w3GfIiwOfxLhpw9ANfe+pSLdw f2hi7pUx832zX02cpkzK1/qrSDXg57+15bNRZ71xVtdjYbeseH1TKcFYLbhmtQaBexB2i+r66/h1 qX6oXP0WNL87ovnDp32ABO48/AIpoclxdX/nC5+kziDe3CttHQZYdlZ7BcjAEHnmPQKZdw6b6HdF k47j9zpvsUycphoUvKEk7O2AOz383fSPggNO15VSQE9UTmrragWK4C8YZDhJJS+goojv19X1Mz/I KeTBwfk177ipOfPIC3j+t63Er4HcABYZ8LxShgOGVAcQCx84o3QJFxjvubKQq1nvoOqm7QzEXUT+ fVnqbhrmsjPj6utCsWKdgH+loDqhUrVC8aSIr8FGprmw8X78TBhKqaNLUSAQnB74bMQpIKch4s6R grmFxHyLH3jhLByqwgA6Afwi4EZaJXp5HWUJXlxHnV5ewQgaL+CIOKMfYWEGvpeAnM8AjQKyAdAI l0HTx4nz3FWE6J0W8aSIr1srBB6NGwx7ZOm/F4UaMcY0WAkgy9C6KuLHlovOCaax0caNpbAKP+pF aC6GzuMa3O2j89AVPjoPZPBKcB7qRHmFTzgi0HnBrTDCei2cbb+E8yT8+UvOQ9cwIZtfij9uaQJm 8eET/LwjOUeWeA85LgWgDF6mbC9uxjphfAeXqW/LSjUYqLwy/kjsNkgvQH0KYpcWv+vbAK3tEfM2 GHDlDP7YgSsJ/P1laDOY57zEHiorvCAvtdZYqQoowJhaJVIFGRR69tVqIKueYFc93cJIPwPrkOlB oWx8/1k0bBEUmukBDQc/LcqJjtFwOOSy6C3oeUdUbMY3IMLEXjzCxI+CFHmNuYRRjNsvxaRbal0W HzCw2nuJnJ2Dw/sfHaEB0eG3PoXcJV2fj0GGO00NdRFyFh0fQhCkeQXlWMS3RifNIOF8GA+yt7YO miG8YX6Q5lVYtX8bdgqaef85FgbOQk/y/v/KrtWnVSbup1CoBKIQKxSLv42+zHyzLum4TDDcZhiG ZIwpfpMp4I4AaEU5wJHyfFb9CQvOSXVlbmRzdHJlYW0KZW5kb2JqCjYgMCBvYmoKMjEyMQplbmRv YmoKMjMgMCBvYmoKPDwvTGVuZ3RoIDI0IDAgUi9GaWx0ZXIgL0ZsYXRlRGVjb2RlPj4Kc3RyZWFt CnicvVnbbttGEEX7qK/gI1mELLlccrkvNVrUbRPkZltIH4I+KJIsp7Asx5LT5Dva5ns7e59djhQ5 RZsAxnLvM3tm5szoXVZXDctq9d815uvJt+ciW20nujs7/9k27laTd5OhatU/3YHb83X2wxQWykxW ss+ml7CoycoGhjouqz7rB1kJGFhPclZMf5+cTidnauOqlUJyCZPNQeH7qPOaJmMiPbGp64rzbKgr JmSnznyd/1LUlRR13fB8U5SsEi2vm/yPoqka0Tciz4oSJvRSdCzfFmVTSV7XbX5l5raic8tU8x6W dd3Qs/waLVuY3sbuJWom+vysKNuqaWDqxg1fQEP0LRfRxOf6gk3LWpgAJ3VsaEX+1C16SS7yRy6L sq9Y27RdPte3b2WXv90z0w7jjZxOhMxv9ExRxxNC79Jqp+vyD2avgff5TjVFz0EPeNkapOqGYRD+ iowr/YaW22sWmit8lp15UvRN89v0iQfOg6HJ+qwZYpxwUQmWcXggaXCSf6WwCbBq7VwmYN50AQCa FqUENbGq73uuhWRw5+jzuvBdQ5vfKTXAJfpOgkSud+lbekn4/FD0qtULpUo1UHJQuhoFrZo+veJM /dn4ZReFOoTVbWOGn8MdTJ8++KmZWDMAkO/UExd+ZOlPmb8t1ACcvPSjWyxpbYTchMuZDbquV2+D lCyzkjVKu6C8/OtUqwDv3in2T6snBtB57MUMelwjPSZDN7Ey1e1D14p8iaBwjUKjcSNjWLrxoqVa Ui09eYeeoY7v7D7P4TrPilLkP0I/eB5jcnjPsB4LGbYBA+aq2WJtV15HQVv6Nvd+yg3RWkYvqFbZ O2nLlXIQ4OzCwbYLNKMeljP/XH4obD0PmhxJpJFp5RASrzLvI5n2aHbPc7f5aYC1QzhYGer1M1+F vtPIFgbYvQMXOiOUsUAvxcSgNKHELJWcZSOqpjfCrryBL30rwGSJESYQLnexaSeoTcCmLR0CUQd3 5527eS/l2Mx0CxDyV5FYW2ks6n8wueCDlKc5L0Zrg2AL71f0FMIKa2wz810M58S4dN8VAefU9NVW tGGR5rQaG+1pcJUXCtrQrhvcqya9Cp8x7iwu36jH+1g0rQ5FaGAV+1f8vtrU+sE90x0yoaCnYK+J KSpTiqSxozOi7zOG9tKIzeHtXvg1z92ai7HJwZoxKDvWa1RCgDWg3B9dbchSgAwxdo1gGuxv5957 Tbt1HCVB02ZnzkV7KEDCwpdJJKVcZ2gFD4LiiIOi9axhh1vfusfvaDF3mZoHDd8jzMCGHL/kJ8ea RpG5/7yX+FXFCKObK8LnJcEXX2zMc/aEYO37HMwH8H7vEyf6tsCO4CaW9jIOumquim3bRyRZqt27 A7PuH0iWtpS9aqKU0iP7DPutq20w0o6zrsixzLyxXxuHIUU1eJ9BRfMNgT7tha7wtSOn0nFMDNJR QwzKERHYYHCP1lJXw/iNArERSsViNhjJUNARjO0PgEcgG3mbgNjAqe996zpEjEUM6LGlgbFAu7Fe 4NZPn/kwiI3Ao1tz7uAfIj9PhDkigo3ofGmZ/Pag9STsQr2ToiDAmCwZaemH2gWCQg3fkR5rQyBt hsA4buHgZyMjZ5Vk7g1XtMoc6wsXeoSh6IatiJ3O8HksnXPfB6RLTDIgm5KTZL/ekIhwTsX65UEF JsZjFIWN540PnybFc+BUX5q8Bqc8Tx2v9vWgpOCaXQaRuHXlDiNO7MfeJ7A+CMz4MfL5SSymEhFY FefB2l/nn+BwzlWmhW4d5XpsqMcxqmRCqDvuNWc5OGNBCICt9CIyugTgf3EqriksSsX9LSlejDL1 XRyKNAO9Lkae+ypsSFHDgDk6oYzMxW+PH8lbWYhuXmvqWuoFO3i7mjtjpgLHlU93TsbMUrZq9THM EkGCIy/Xei/XIm6Z5DJRCQHbSMJuLK68jcQVmwczIyItOmAwIVt0R18e5j//CqEbAqtR+SSlAaj0 YR8Ww934dXBdnsDcotEoQC1SrHac79PJQcbh0X/mhwNQEft6hnz9CVHiAvRJdfEvybp1NTFgQkdr n8huExgGFAXs0HVGqgLmE/CEldr8Nsli9+e3Dg0Ob/vrKv7EhyYrsc9NCNC1o/d60CZGmstTsZF6 eiqu4hUGjB0C41UMRiJ/NgKwQYgeXM1o0zkFUGQVmE9skKgE8SZIxOVB3rGdxSWIbcoStKS43IXj i/OGo6qoS830KFXY3lMgS+uboU5W8kMlMqP8plbSK6/N7NFr5JKVE9piPhmClC6X2eDD8xLd4zub 39ZsfN64RQXpRQxoW/KJqgEI5PqRCYxQr0jzTJwmmFpRVzFOlYt2FHBmhwAW822v1fcVYSoe/QQR WCKqGFdHqJ8JSj5Aone0C33s0v7BeEoFoEE5JGGAoXManL5pDhXRp4j+qfhiL7WPUuoQ+kL9Qb7y WZrkaLdtSOY+gxnU9aRScT+QCd8737o/gvd9eWgHbSmBjaRPJ9NvYlnT35Y+t6cvnYWJn44n1t+H pWiXUJR2ihVtoNwvCpcEE0/CAQbYyre3hOFqdn3pU/Ciq2ulkv9AFWmh8taQcnwZoo45ChdpXQAV AqgIY6E4Q+U1l6Mh8rMf18cqceTBfJfXadtjo/ob3EFXa/VR4YQKHXOUxiEfrxm5Kfl5VXwMQIl/ EEiohF4b9EYJh3/R0blUcHT+OO/Q9G/SZ5N/ADRn8J1lbmRzdHJlYW0KZW5kb2JqCjI0IDAgb2Jq CjIwMjYKZW5kb2JqCjQgMCBvYmoKPDwvVHlwZS9QYWdlL01lZGlhQm94IFswIDAgNjEyIDc5Ml0K L1JvdGF0ZSA5MC9QYXJlbnQgMyAwIFIKL1Jlc291cmNlczw8L1Byb2NTZXRbL1BERiAvVGV4dF0K L0V4dEdTdGF0ZSAyMCAwIFIKL0ZvbnQgMjEgMCBSCj4+Ci9Db250ZW50cyA1IDAgUgo+PgplbmRv YmoKMjIgMCBvYmoKPDwvVHlwZS9QYWdlL01lZGlhQm94IFswIDAgNjEyIDc5Ml0KL1JvdGF0ZSA5 MC9QYXJlbnQgMyAwIFIKL1Jlc291cmNlczw8L1Byb2NTZXRbL1BERiAvVGV4dF0KL0V4dEdTdGF0 ZSAyNyAwIFIKL0ZvbnQgMjggMCBSCj4+Ci9Db250ZW50cyAyMyAwIFIKPj4KZW5kb2JqCjMgMCBv YmoKPDwgL1R5cGUgL1BhZ2VzIC9LaWRzIFsKNCAwIFIKMjIgMCBSCl0gL0NvdW50IDIKL1JvdGF0 ZSA5MD4+CmVuZG9iagoxIDAgb2JqCjw8L1R5cGUgL0NhdGFsb2cgL1BhZ2VzIDMgMCBSCj4+CmVu ZG9iago3IDAgb2JqCjw8L1R5cGUvRXh0R1N0YXRlCi9PUE0gMT4+ZW5kb2JqCjIwIDAgb2JqCjw8 L1I3CjcgMCBSPj4KZW5kb2JqCjIxIDAgb2JqCjw8L1IxMQoxMSAwIFIvUjEzCjEzIDAgUi9SMTUK MTUgMCBSL1IxOQoxOSAwIFIvUjE3CjE3IDAgUi9SOQo5IDAgUj4+CmVuZG9iagoyNyAwIG9iago8 PC9SNwo3IDAgUj4+CmVuZG9iagoyOCAwIG9iago8PC9SMjYKMjYgMCBSL1IxMQoxMSAwIFIvUjEz CjEzIDAgUi9SOQo5IDAgUj4+CmVuZG9iagoyOSAwIG9iago8PC9MZW5ndGgxIDU2NTIvRmlsdGVy L0ZsYXRlRGVjb2RlL0xlbmd0aCAzMCAwIFI+PnN0cmVhbQp4nO1Yf3xU1ZU/59777nuTmWQmIUkD w483vBAxk5gA4Wf4MZBMIGRbAwSdSaBMfmHSCAaYIpBKo8WKE9TRIpVG1KpFWbfsS4gQRNeo2eKn tJ9qN+6WH1prpasfy5p1F/cHkOx5bwJLtq3tH/vP/rgn33fvPefce88999w35wUQAJKhHThU3ryq YDrYZcxletxSv6G2NdFPexwAF9Zvjeo3pyw7TYxzAEp0fettGx567uP7AWQlgDBuu337+oR+chEA /3FTY21Dd83u9wAySB9mNREjZaFaBZAUpX5204botoR+OvGw6fY76msT/VQCPr6hdlsrz1WTSf8x Yugbazc0jthnzTep9Y4t0UQ/42VL3rq5sXXj7h+GSb8XgO1QHiYrXyN4oVo5AgJg+ENLGzOGPrFq S2YVi6s8C19Yhv9A+eJR/znSbk7/g0rT4VG2H8pgKSoQgDuhBKbCYvDDb2Au7IYCuAF66IRuhHzY gUtB4F6oU/rgL6Cf7WdHYTVU0+ipsARisB++T+eZC0thI7QqPTALFlB7KQzh/fgsfsSWs42ggBuy SScX9sBjYMJp+ATn4gLcjA/jY/g0DtLck2hksT1yBeyAV+F1OM8WggYpkEmUQ/xNcIRG/hZvw934 Jn5MdsyC+WT1V2jELVBNdj8KB6Cbxr4BJ+FN+DtU8UasINpEtjzCMlmYqJptYceUQZpzLBi0Q8uq aTTPIpplBe2sBqKwFbZThH4XnoHX4McUe4PowBvQTzQDq7CF6GF8AX+Ev2LZLJctZnewbeyw/BKF 0Q3kw2k012qohTpogma4A7bAN4nuhl3wbXiEZv0eWfkk0QtwGF6Bn8HP4V34R/gMk3EKzT8H12AT foMsfhwP4DN4FN/Cs0SXmYOVsEf4QfG8kqHsk5PlMflzWlGns5xvk+X31eSJW8kXNbCGaBOtHYWv 036+Qfu5Bx6AJ6CLPGTRMegneps8eo7W/xQ+g4vwOSJylOQ3J3owk/Z8E1lUjMvxK7gCV2MNrsUG bCZ/bsY40V7cTxYeJHoOu/AI0XE8QX45SedzBj9j49gkNpPNZgtYOVtFVM/uZN9i32YPs302/YS9 xd5mA+zv2WXu4FP5LF7MG3iUP8NPidlirnhKvCPOiHM2fSyGlInKHCWk3K3sU36hvCvHyAb5tDwq /1b+Un4k/129j+IwmyKZopNicTPcRdHZAQ+Rxw/CIThKZO35Z/A3cAbOwnmiT+AfaKcZOB51LLOp HMNYjRtof1/HrbiTzvkROgdrf4fwNXwD/xrfw1/ir/Az/Cf8N7yCVxiwDIqssbTXibTbyayAFREt YMso0qrZWtbANlJ03E20m8XZQfY8e4G9yt5g/ewUO8feZ4PsEndyN8/hfl7EZ/I1fDPv4A/wJ/hT /Fn+Q/4j/jbRaX5JgKgUO8SD4rQCClIMzFLWKfcoTyvHld8on0qnzJDj5AQ5TZbL5XK1bJE75Xfl m/JzlauZap5art6nniRvHKAoGF02w5fhOViDnXSj/YAwGY6LGmjkE9m9GIbX+WUbnTgVdsIrmCZm QwUcQj/sxHX4GCyHW+n2HsAGunNnKM4WQDe+ChN5Ds6DXwCjN8hpeBTHw6tMZYeVB/EQ3E+x+q8U qzNhI3+Fv8NPsBC00B07TO+i2TjA1+BGPMmTWB355gz15tDJf2q9OzEL5rMLrBteBJ19h31V3MVv CswsmjF9WmHBTfl5/twbp96QMyXbmOzTJ02cMN47bmzWlzIz0sekpXrcKckuZ5JDU6UiOEPICxpl Ed3MiZgix1i2LN/qG7XEqL2OETF1YpWN1jH1iK2mj9YMkOb6/6IZSGgGrmmiR6eLmp+nBw3d/Gmp ofdi9YoQtR8oNcK6ecFuf9luixy7k0wdn49G6MGsplLdxIgeNMu2NsWCkVKar8uZVGKUNCbl50FX kpOaTmqZZUZrF5YtRLvByoLzuhhoyWSVudwoDZrlRqllgsmnBGsbzMoVoWCp1+cL5+eZWFJv1Jlg LDHdflsFSuxlTFliqvYyerO1HejQu/L6Ynt6PVAX8bsajIbaNSGT14atNVL95lKj1Fy648Os/Lxe PFgVMh0lvQhVoeOwfLi9q7y9tDRMmjEejMXuG62en1exMuQje4zgHt0ycGXIto3UMauAlrd41gYS W2k0ghYn8jXddBhLjKbY1yJ0DONiJqzc7usetzxwfPh9WB7UY1Uhw2cu8hrh2tLxXekQW7n9SHlA Lx8tyc/r8qQmfNiV4h5puJKvbzRek9ktW91qkdVXnYiWRUY5Hb6p1+tkScgw2ZQ51qNxDsTq55Aa lTCSr5rJM5GYZ57lYmWKx9BjF4GO2Ljw29Gc2hGOnOK5CFbTCoRrwUTyq23T7zdzc60YUEvo0Miy hXZ/Zn7eVrPCaPXoZgW5DCpDNCg8r4Bc7vNZ59fRG4A66pjtK0KJvg513m4IFPjDJotYkr6rkozV lqT9quTa8IhBgdoDVoKXYWo51/7cnswxwaZ5JmZ+gbgxIaeLEdS7hDIlVhnKqY11eHMisT1hOpoy umSxWJmhl8Uisdre4fY6Q/cYsa6KilhrMHJ1S73DfR1eM7An3ITkVHOG7Q2w1pTNQ5TLaT4rM1IH bCuuL9U256e4Ejx2n1E9BubQ0CEaIQEXZ9E7Zz8UEgKESoIAHX8AhYQAoZLQSlCgnW0Bk20JJDMo K6O50lK1wDK66jxw87Lp+nuEc4QzhNOEw4TvE54kPET4FmEnoYnQQIgQ1hG+SlhLqCGECasJvfh6 t129lqgCiWpholqQqESiYoFHqX6XcNbqE54mPEWIEx4k3EvYRbiHcBdhG+FOQjOhkVBHCC2bnupI dcS/p8b3qfHvqPH71HibGt+qxjer8RY1vl6NV6vxW9X4LWq2NlnTtYnaeG2clqVlaulamubRUjSX lqRpmtSExjTK77DC7KuHijrd/HyV0YtJK6pNxViCZloFVFQtOQ6o9t37QKb/d0vW9R2sqNx+HCbh 20fVSf3qpFaVeBWriBW3WPF+NW6zsrC7EqZX1HZEJsDvmTIx1e9lBptXLaFFQl0aLAmXrEnUR5gz Ka0kFPH6wksyPa0LTeocL/Zl7fS+JACfByddERe9TZMJlih/cf5iS0RfBpYoxXrRjoiydhb7vC/h 8yMiD7FTyQ1btmyxotEKTvrVp48cUCH3RREHNY69rKgbksRf0Q8tSenJWQFAwdB5z3lYZD2nFfpS falT6IG05GWd910OKHAJdNFnRTgpKx8ox2haB9x8BFWh9eL6QApXX1YkT+Lg0F4Wjl68LTCB3Q3C I3RRKAKiVbQLUwwKx1vifaq4KFi76coFz5XUuXNh0aILngtzU+dOK0SFFk1VaGnxE8y8tG3oHXHg Uo/4M+XY5UtB9IjnVlz6c/qEg/Lhj5QrSqe9Lye42f6A7mWdjKVTZl1MuVOU7WKyhrWwNtZDCdNZ JlkvNgd86OWdnKXz7JGMcReXNbyFt/Eefoqf5ZKT1pF1dKl72aHAZEWka3s15tX8WpHWorVpHZqs 0hq0qHZC69cGKBitSQ0lSaaLvYJ5hV8UiRbRJjqErBINIipOiH4xIKSw9HSv7JQsXWbLYspAo3KX lDWUbrXJHnlKnpVSktJRh+pcR1mavXxKcrprr4t5XX5XkavF1ebqcMkqV4Mr6jrh6ncNuKTLnjbd vdfNvG6/u8jd4m5zd7hllbvBHXWfcPe7B9zSbSnlpCQlo5unU+rNvPQ9UkTfIm3YgbKKEvMoJd/9 OEAJfMLMP+6igI95nZ1Olu7MdhY7G5xR5y6nrHG2ONucPc5TzrNO6bS1krxap8bStWyt2HbbLk3W 2I7s0U5pZ0f853OkK3sV5lX8SpHSorQpHYqsUhqUqHJC6VcGFKnYWn+Kj19U9XUOdFjec7iAsZR1 LnRZvbEeNaJ+qvICtZIa7WpcNdU+9X1VUykMx/7z2vnzPfM9H64d57mydtPm+RfocV3LetgNUoKs RWMtyXlL6rEG2jrnE+KLI1x7rMWbVujgqkOqDsYNnDj0wdAHTyQqsW9UV+mk569xwhNDvx76ACfi hET9ZKJK/Nbk/g+h268Snv+/QfbvfiIzSKc3EhUcR5DUqAr/8X+8/G8ugr6sraew/DPIrCxqEO3/ Mlk/LeQfSDgIIY18yKgl6WscqqqC02aUlc2eURgtLLTzMIxbP2N/YtFGdwdhcPT/v0ayOErP/h// nUiDgt9BGZQn7sQXFEygy/zLl9a5518Eb+IAf1B/8rBd/8uddcPDQ43qgGymrvPqsP8AB9Pcwgpl bmRzdHJlYW0KZW5kb2JqCjMwIDAgb2JqCjMyMTIKZW5kb2JqCjMxIDAgb2JqCjw8L1N1YnR5cGUv VHlwZTFDL0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggMzIgMCBSPj5zdHJlYW0KeJxVVmlUFFcW rgK6ukRAm7ZARLsLERQEcUcQj4LQIKCguEJAkR17IdIgEGNAjY4+3HDBI4ZGxQ0jtgfR1kYEl3DA sCWeqBF1nJxRdGJEx3CLeTpnXjUnZvKj+ry69er2/b773e8VTdlYUTRND4tIU+en6bNSkn1DdOpU MeQjuNLCaCthjDXC2oHvBzZKxlDRR3vtkZ01srM5NXrIr47QLYPDw6BoOGVN0wU7y+frcgrXZ2Vk 6vkJy5as8Jo40efPyJSAgAB+beEfT/jQtNysDC3vSRb5aWpdjiZNq5/Nzye71eqsFD5DXZiTmcsn p6ampYqvLU9Wp63jVVnqrJwcXT4/Yb4XP3Xy5Cm+5GfqoizN2rxcPi5Zm8tH82L9f4lQFDU6Olib EqJLXZSTFrs+Y3Fupj4rLiJvgzq5QMPPpShfaiwVQ4VS7lQsFUb5UYspFTWFiqMiqKnUUmoBtYyK pKZTXtRyaiW1kAqhVlGLKJriqTGEO8qGvJxAVVJ9dCp93srOyt/qgNWAdZB1oXW/jcZmQBIuKZac YlyZaGY3c4d5ItVLa1h7djj7OdQ4CIBAJvQY6EfgbQ1FAxoOe3/UCNtBht8yDgPpqAocyYYFBlrY AeM5Mx4vgUkM3jugkeBABpd/1EjAl2kAEt4IMg4vYV7BRYmYtkrwhaFag2Mb8LAaeGe5qU0wch+M 5PaBVP7grqm+s+VsdpQCPyOR/0ph6IJOLA2Jz4lJUchND6UOQpMeJPAbSOjzwFsLlfCcK4GR037G rojFM3zdcDRW9brDdHB+3gPcYSUexRSG6XKWITZ0zd33jQfNR88pK87WVNSh2+hUTkUoK6IBGSwm VwDIHB+DNxwDd+wA45zl7x87QQ/zFN2quGK8Yjzdiu6gH1NvB5h/vHq6HrWi6+ub1l5YY1xZMYf8 90MGvLGMA39GLnQZtcuWp2tVSuzPYJkNhDPy9/cuZi9clJYdosThDCHiDxS1BGYZQQLNwlUOB3hi GodhVR+mIBBmvQMagiFqQj+eoyzFEu7BdZWb54qweXNXdr9719h9X2lJNMS3SvCDITDd4HiGZCsW Wd0oeDkBP6DBPC5nMps/q44gJXJeeDj2DzkWfGGFUt6wwtie1e7aga5V1zax2Faw5364phrnlRAe FpbQ9dsbc3e30tLpgVAD3UlYuUqkIOx3Am+S1fvDVgbXC1sleNJHDXgLpSKkXFLDCxhCmnvnjzJM EE+6i/mPO0mkljkfY9Z1Ihac/gUOMOt+3v2M60r5g8aMiPORruEoQZsVw4KtbrCOeJUqLKGzr8/c ReogXe+Hsb0wrJ8WqiCfKy1He1EZat5yfdPFjNfTv8M0gefng23wAhz80g18wf511+81Sqxgitak rl+JUtC6oxvObjJsO7Gjkd3Vyx14XHupFdWic0UG3eEN+/J3pxMh+BFZbyE60IGMvk8QHxTFnw+H OYhhYNSzVzABPGc9wj5K/JOImhE4G7KXlz4yZs4LTs+cTep0IQJ3AeWgwJ3lxk/irpPKux5fuvT4 yMGdf6tUwFjpltJtaDuKQnHJmhBWbvydSBuw9p/vCYnPLSQSfcMmcHGW9wg+JMssqfzXu8mJpxe6 4hETsQzPxkG/YBtwabtY+d0NZYg0Mj4pbHnmsUvFCuzBlCZXaC9oLme2FD0hdPu/vAdyJclzk+TA +zDFdd8IGe+1MiJkQWLH67dXf+gkna7UwwhhL4ygL5N+ehLkA77vuIaWmjfoNepPexfVFd0Z8K07 ckcB2dHhUaq0cYiQjumL4+6q2sKfZL9DP6FbR+7Uss8C7/dI8Dewh5sb+CBE/1X21nXIBdvN7iNN 8X3UB/bg8PN47BdTvCxvtaWxYAXvwcrRTOBGgiuWibz1CbsEK24HMNO6sAdp7ZiZKmydcUhdma+s LDi6+UYRzF4xUt5bW1xenDcqO3VDZIa2rLxQsfHQ14e+PkO2M3uw7T8WwixS1O2KunN1505cR02o O9MUWoXDGkemlpfsR8fYs+cMDQp5Xwf6Nrc0nv3kTmSQ6A5SzXIylh3E+kivRXNqNV1pO3uiOK9C UV6450uUyeInFotCHYXm9Br1yaQjSUiFVulSY1kwSB3gmRDRSz8ZHO2T3BzwILPooZrUhf/OzDQl v6ip3r2/WvFa+uWOLTtLEJu++ZBZCdeIw0ENKWO74S4RYYf4doplgkQRMQMaG5KEMEQ82E8PdmQW 7GgTuEMzuFsL/xb2cKhj45WMuvjmwDNjCW3zPQPwWCy5vRQm6JRvN7wpMOpQrMuiuPTJHksuP9ym wJ7MATy5fyYsIiqJBetfiMKli1uw60klZo7xVeoq1ORys6H2waumlOC9ikHjbyMTsm/QEupFS9gD Tzn81GILE/FJfAlOimcFefpUarGnoRNFOBZPsBh+gXDRSTASHM+lclNUUnJ4jObc9wp4QzDaSfHQ 9nCQ3ms41VKnkBdESYkuLWzQwoAT+ApGCRF3wAeHQMFBgnlxNUNceTDg88EogXHMM0HW80EmsZAo Gtcgg+L5xYttZAbPjylVwjSQOJ4mJcXAGLGkqqPc+uNbj6DTLDRJwWreLeyJPecuxLLNCnBlym4d /6YLsc2nCjMKN3+xcYuyoAQhVXFcyUi+cMVS5I0SD6dV57By07qaawVm1xZ082RDIysvQLrdJYe/ YMGHwXNAw8lNgSmJoZ9pq+vqjxnulCvMB4xl+3ZV7HchVQ2iBIBqDkKhSoKDmOnYfxr4iysIxVU4 AldLIIh5AUHPcZC4cviP/afjtIVAmTd4OcsbWv7vSO1pv1DXcu1MzhoF/mCJ/OVecJS+j2rFVHhC blyy4vPGZWci0EKUkp+4lJU3dIhitHwLeAp6sKXvwmgTDL8KbtaCBBI51F52qKW+t/3UFfSUhdEe L/H4GRGa2DWK7NWbEnYGkNAuZnuPubUdsS2mVZFJXxXEJiiDwvVJu2eywC8lnxSY+AzjoD8uGA0w x5BwnAFbW3AbCrYH7OzA7aCdPUX9D/r74FcKZW5kc3RyZWFtCmVuZG9iagozMiAwIG9iagoyMjU4 CmVuZG9iagozMyAwIG9iago8PC9TdWJ0eXBlL1R5cGUxQy9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVu Z3RoIDM0IDAgUj4+c3RyZWFtCnicZVcJWBRXtq626apSGlB6CkS0uwVUVBQEHFEWlVUREEFQcEVZ FRpkh4D7mMjFuEQSBg0gKqIjigtqFAXFfZAlIgG1QWkwbUImZnDmVM9t3rxbmJc8Zz66u27dqnvv Of//nwURZTCCEolEoxbFJGbGpCdsjBLu7HhLET9+BD9BnIFV/5qty5FMoAKOvjFCUjGSGlSMHx1i yk8dA5dNIHs0JRaJsveVeCWn5KQmxMWnK23DQlZMnT7d7veZWXPnzlVuyPm/J0rvmLSEOJVyMhlk xiQmpyTFqNJdlV7k7cTEhI3KuMSclPg0ZVR0dEy0sCw8KjFms9I3ITEhJSU5U2nrNVXp6OAwawb5 cQxKSNqQkaYMjVKlKQOUITFxGYlRqR9NUhQ1L2BhjmpjYHJ0kFdKzFLvLbHBPqlxy3zT4kPSE0Iz Ni1fnJmVGBWenbRhxVSl3cQZVjPtJ9se/nJd0Rce8ylqBmVFRVJLKW9qJhVM+VD2lA21jPKlHKhJ VAjlR82iJlOh1CLKkZpCLacWU05UGOVPOVPh1BJqNjWNWkGtpAIpT2oOFUEFUV6UCzWKElFG1AjK mBJTJtRoiqFGUllUMrWASqcSKAWlpFwJJ5QBJScbHqFeiKaIVouOjaBGTB9xcMSAeIm4Utxn4GqQ YXDdoFdiLaml5bQnXU3/xKxmiphadiGbx9ayT9m3I6Uj548MG/m3UWNG+Y2qGKUzdDRMMEw0PGB4 1fCRIZZKpZOld6XYyNNouVGs0Taju0YaYy84Y8w3ILWOKRO90IphoS6JmzmUxEeosZ421tmjcojs 4h3KRLwKkrkOnCwZpPFhXZIES2lcPJQk+RvdCckS+KKLw3k0SOGVxJj/DKvUuj+QNWP5cg5P0tvh cbydxJEGH33FZpetsdn58chiG8rfl7OfXcAc3Xn002OoElUdPnbkZGnJsSO1kK8zHiuYVc4va48v M23r9OiBz7vNZZfbyIays/ryHqhlZO3/bGx7/aR2Y4Ac/7ubVzK9/o2T3SOSPNfIZZc1DDEjvZO3 6xSd6RXzm+Ed9+mt7WezquLqAqo8EYsn2mMD7Ind+5VgBWOed8AfihRz6Pw566O8EWu/vANGg/nt rjdtVzd4FimMdc9Quc67TNSh4Q9pxHy8GUTxINGDRpeEOQbHD5ngRJ2JBHNDSRoeaNioB4JDwwcD zvdCQ68YTvDnOTzF0Qp7Y2+NFUyFKf3vYQEsdh7E0xWFHtzbRg9shk2WudvPDOkEGZje7dIqhE26 lpfzAV3gUWZ6shfqCQx5/C5Ckws+Tsc3hJ7yId6Md8Qi7KqQ1WGfXiyCiU9vVjZdk8vyfJ8xOJeP 4vrvuuIxwmOjZa5O9kEvwRiMH758IzfWxX5w7DsNL9eIdePIvk56La0fw2slkwVnNDRvpNdI3hMx xKar+QG16IZWrJvGI04FzvZd2BlNRW6JYUsXe8VZIzwKYWmNTat347KnKT8g8EU//3gMwtjp9K6I HQl5qqSlgQnuxNxJ9sCCPyzVAAMT79/JST6tqEwtSfwyjB32l5/WRVi/LbB+q9dcdvY2VnE9cJK+ GlaX1oJYsOwDERBv28F7NozACu+QzYHRhPTnHoysCXIDuO8fzMNjsGHQPAenZS/ABEzuvdAMQ9kJ i1rAuVN0+bWYL4KtHHrxpxt5FxNeu9ZPJWZNnkE0sQAveDMRpoC0uwXocqKJdN/VcYtQOFp7PPlq 1undpwvq2X0t3KGB+497EKt+7Dd7L9pbsJdopPQDPhe0fIlWzFvocjgcg63wTJyNs4FcIVbzvPLm fcXz5usgQWDIwjasgBl4k3yuATj+gqU4AHtbkctMbG9NQmkRLBokl5kKgSU1/0gt6tPy47XiPjOo piEAJCCHLMjEBiDHgQpcTWuHLDn+ESxgwOa7aTgIB8yfim0U/w/SX/XTye8iiMqu6XIX+jCyzjvR wad9LbF8FpaQiPB4bQXy9psn715U4DMMnqxz5fqIekyx9DfpGD1Uf68whjMkPv1awLJdpOkWw5ck NJ3V9Lmyry8c+hwVlMpbmez92wtzEeuxZt0ChaOPX5t+dTe/upf5kFYuq+GwWvRGC30DYuLMIw5y 6Lvo2tGL565eKr2OmlmYMK8T28jx7aEkLc1bGsBhCGf6Gla5uoavclQIm6jhczXkq0X9JHEtgVcc P1Gtnwj5vINav4/ksDK13pM2htfETE8N8b6VCMpcVtMq5JAqIYecYFBHad2lKlbWerL0xMF7hewr Jn/f7sLtKAxt2LzKnZXV/EDySANWtcEYIZTJJlW9cJns8pJ3INvMZ2QDj6JWVi2yxBazMIs9Zlf4 XIlQXFzXuOUOeoK+OXX9CZvCIO+d6zNVGYnrc1aiGJRQlP51dsmuP+85w/6RPmzbGQwmqAs1n6iu vXSj5AkCE5Zs7k82xtmBXH/DfGyOx4TNd3JYPpwTGrv6/lNpui0F3IzO1u+q3yJgLIgerGAmjiV/ H0nv6YMj5+7L3ztLcBQc5daEPgtcn7Vp1zpkge1tfteaPdgPEgH6zUj1DAsiygFC1F8/whjeqfE7 grFSrc8XiPktzV7vhZ0k0/rzxlzB3/3uYSMSUMZuAdPm1kbD6CRFV/a9/IpMFGMRGbnJc21M8bFM +daSP5XsqWGd6P3YqGUZTCCRPban6V3XuivWJxSupX5HVMdQjcWNK2dams+rlu+T/1oRnsL8MlFb NykI4jaSroaSukkxEEpBZeXOvDL58dyiVBTLfigJmoA7kxauTV8SKYfTzHCyg2/UsF9tqtUC7p83 YC57D0HQzMFuurtm4yyFjC/wR2u/WFecZAGSCjr++O6TewcKQJp93q2alb1XXzp7q3scmLq1Yms5 7hsWptIA9kMGU49O76rIOpFZvAmtY2evi7aVkwBJb+entYhekeg4RNQyG2xcsI2337d6JR1+Pqmp rGzfgVPyNmb7Z1sLPkFs3I6iGgXg14wxpBI/s8ogsEzUTNZOI2td9OXdtC7JYI5Vj1CWCf/vukxv aBZr4SeNn1YIaS3/FVcA1lO7sRtB3tl2Lh7reD30x1QFLF4lkfV9n1YbGzIORWduTMxQZa3ZHozc UFhpfG3KX7adK7xGSChcVLyuauNNv544EKNe9G3Z9fN1F880oceoP/SJbSVeUjdW1ul0fPOpxnHP mup+ArYp3K5Q4CS9PUKw1rSpG/aT5JLNZ5rx5S74JiO7pgz1cV4cdemxnGdc9LaMc1PoL511la11 clm2p+AmVj3TjR/2s42QSdzUDzArcnNXfoZQYa7cmynae6CgGLFv6y58q9AZMRBl4GLVTQ/LUker RfBnIsp/6iw52KXWt86F3UOWRJBCXhJK2s9vxRBOBDJjKOmtINNhTEVwwQzW8OWSGTS21btjJe9O hhCgL5cMy0N4hb9lBjOHX7HW29mQzmUSPUVvpyQDexrsyJtv6Xe8/T/09pJhpoSzWnrEYEfOmjOU RPghmLT5tPMOnaa1vVA8jMlf6ki+3bvzU7THUvVJyUkFPGS0fjcxNz8gIzpenpayI2nvCraHPvTX C1VdiO2oTY5QZDAoPjNv8S48Ki/n081bg1ITVyM/VpZt92TpP540VNy+Lz8YfjLtNjqKivdVHiLV C/w4lLwrNzU9IXHDJ5GI9Y8503Cn5lRfsULz1df7TxWzw4lXMJcfbwYHSRNnS+O1+iG8iR+STKGh hLRzv+N0DY5z4A0HBaRMcQg2hRCJHQ1euAgH4jLJDzRYwBowx2skA/Rwf/Rrr9YDKcLHXFY3TChJ s2pG9vK7Ow9bHp2LWSTHQ8KEcPvwfPRi4ZafwLwNq5/qE5UZHClPbIw67od80JotawNYWd0z5uMG 6HY31JOOIO/2cOB3NDOyuqBLDap2S5D3k3roCR6z32O518qU4GgFVDEwGZdz2g/NQODHzcC/vD9A ocszg0AChTWNx+n78Dy+j0CB/0iGE8jQmoalBJVfaJjD/whu+h8J5a91EQQer5diLY7nfgbzx+CP YBYCxwDwnwLm7HJag63rSBSS3gg7RWJ3J2zFElWSD55yoa9M1Pte3DvIWT/IYZDv1qzVe9kYpu3c tdcKkDK/iRdGE0VFD3d5b+hjOE1ykT4GaRJ8yWCOdY9Q1GD3UxHUQBOHd3rBTjIDOp8yUb22WSuu 10VwWMxU4nFkVSWMk4CYaTb7zxnhqEFR76AYQokx1oNC4GSV61aSs3PIuXjH0A7JHRp26HZIhIQj cPA/bab1PZ+pYeHzky/MZbH8DujlCuO2rcqKxxYwZ+zg/eor6Cn7vV+TnVymspvv67S6NOaRu0J2 BY/2iolwGIelajcwqbteXHFeXl78dcmFGlameuQuARGNjWF6zd3yJ+iBBb48wAW17TyKzrH11dX1 N2viItemqtxJCrfA1znZleDQ9ekrLL2C77U1nrn05p7iV0baX4phOzF8CjYPwP4Iz0LY8TH2/xmb s3doJ7COBDcEzgic6sBdAwIjrwlipnXatVdbyNdc9qqO4GbNyF7doAuX5afE7yG8PDhw9hv0gn3H yIqbzaxvMP/9gOhToIK/R6jQP/biHwvhj71vivgObEryWQRPwgP+Dl78Js43NNTXtzG0teVuY/O3 yxt9BNNvXFurbSJfc1kDTOS3cIOMrGEVXXC35FT1AfYCs3TPptXIjZ3MyBxgv9ngKua/nxjzL/nz UMbp82GjxI3h5dhFL8ezhaEwM1w1dWZdos5XXf19/WLohlXcdQZd/fJoy+OOlhPX0BMWRrp0kP89 bBa44pnyVzT65sCpr46X1lwqb0Bs5601fmsyosNXK4LDEcpNz0zenY7i2OVMvx03y7qfNk6v4MuF HB5QQXeN6jbsOiCVvjosNaKo/wV5QB+QCmVuZHN0cmVhbQplbmRvYmoKMzQgMCBvYmoKMzY1Mwpl bmRvYmoKMzUgMCBvYmoKPDwvU3VidHlwZS9UeXBlMUMvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0 aCAzNiAwIFI+PnN0cmVhbQp4nFVVCVBURxp+j+E9XlaWTZiMCMaZKUOtccEDtCRClEQJhQkQDjkE Vp2BAQaGYYABhxsRL3oEUc4ZjgHCfQblBkW0iIKiBlggiBd4jmvUrNVv8kjV9kjM1lZXveru/3/d //F9X+OYoQGG47ipi0iSIJKLgwUbvhNKxDHxIv2uFb0apz8xoNewgMdvt3SJxBrMtfTFX4ExCxgb ln/yQYApHPsIlv8NHvsQY+G4Ir9yd7QsMVYcFi7nf+bj5bfeysr6fzs227dv5wsT31v4TqI4cZiU /3c0SRBJomVRIqncgb8beUsk4mB+mCRRFh7HF4SEiEL0v/kKJKJIvrNYIpbJohP4n+1ez7fdvNlm A/rYuoujhPFxfG+BNI7vyvcShcVLBLH8PXIBOuj/bBiGrXQNdtsVHeIu8vB0jgv3kou9Dwn8+I4Y tgFzwjZin2Ie2NfYJswZs8FssXXYXmwPtgXzwb7BtmL+2C7scwzH+JgZqhpmiK3FCrBx3APvNlhn sNdgmMVm5bOGDfcbthB7CBUxRMrJBqMgozyjfKPXsNGEHgLzOqMKHM7rojgbSGbT71EEHUCWzhPM EmlCn5DP0NYz+PQCvPKARffDVxylCo1CkGMOmhPPxdRKmoQqL2AD7EW+zkHuYgYHm0CQOqAuvOVg j2IMzINb9b2XahrULerLlB0ZtX3vgd2Acj4wMDummW6+yGsfGWy4CqjRjnCvoyArO5NnopsCGp1T BU6HrYQP6dcMZ+k1sUjCTboogjEjmZe/GznojAiGsxwqsnDo1zPIx0S3CczD3HmYMm9KT2q9tGbs pz+vhHfJeTBaNzRCsV919VWOXLcAV2WtXzdQ7KcPOwYmFi3ADxn1sbXiNoHKGVDMAFnLjHMGYQoB Xcj7HTKP0NTQuBheVGRw6h5kzmUecC7BXAImkOxXt9ojPUTp4fFRPEmwKMkbUKiWy9WaW4CTCyz6 Y7qNsxFsF/h/tf/bCMYAbKMY1owjNNROd8xc5vaONkMcPARDhy6Et4ib96s9AZW2kzPVFWjvkfSN bB9P5OwThmJyOjA4d6X0Ru0gr/3m5fYbf1zjo6HdZuDOCtPJBTO2QsdFzbMjv2NaIq8H1zgBc8ae +ZCxZcJ47B7mg3HHX7t6S6rPcRvKilUldRRbkexI3CEZPi3kTHXv2+aR7B7lhzxdQgLE7qu/Ojj4 4HLpWO0F3g+3+pvG0H260OWO6DrRLbYkw156zuTQz4lP/2yBKb0ATy0tEG/Jd8FBlwm4eQa/t1yG H2EaJ6c0v/90J6g1137+Lwbbaid02ccNcg1lSGAPfKr2doS2iruTrwBoDN5MNUIMISXM2TfMBVBf 7B+4r1EW5Kp4ZROcmidTY3cA9VNP4JeHs7NOJvP0PdfA8/Mwfx7XffScBXPhNQ5UkKOgT93TNjrY Ng3uUG9dhxkTLjO8HO0z8i69mjMM8wnoS852il3D0yPkUbwIwUHFt/pcy+V36Jd38F+1dL2WpYvJ 5uyYgQYvR+EaAC3NwV3Z7D/7Avvt622BLdgR4+zPrLDdwdgCZgPFuLzlQ5eZ3qKOSe7DrQSzHpZy PL2vuQXES7OEqCNmO+agxeOmfw9N8K7MLfY9AzfBqKx1f214SSDwAMyKIIa11Q41F6KMxuZh6jwO z8L7HPjLOy7+Qg7CVILm6RdLqe9Tec9P06tPJQvQd8Ft0Yw9SRfSJpzTGmU+KKZuu/T/w8k9IUTI DQuP8wNBwL1V+kY2pVjVnKk6mp+BWHAmMy8l0wIkJkuS02ITDqYdROwMqR3MU+YrC3i25DF5djpI phxuB0IKrn8xA1dcjWjaUsl1LCfYk94l0ooaC1BR9H1ZaXVVQ0E3oEaa5SFZiMhHeHpl0dBeEwik OJ24yILxCD3v4r5HXoWd1dDg9s3HwPxCi9g/HYCjMt4uRotMc7RxTrGyCBSZ/+zfZ/dlQIKHK/cK rCLeoRD26hluSo+8ctYmP0cEh2fgOAceIa+3xQQknUg4Fs9jv4pbB0CkBUhRZuQkUJAgT1elFR0p B5XmoOhUaa4G5Vx88+zFMgvQnaYJauyoVBeWqc+1146Da9Rbz37mYy6z+L6+92j+Mt+TyCFQk1We QLEXi1PPyuMsQGjKgfhoaZggSY8a2CifoK3H8RdIIw1oDSJJI7Qk7EgJY0k4kakuxE/kF0vkycPZ GeCweUBL1HBFY05uCVc9Kck6huprHp9aqM5Rnlbm8WZpFiKUCYxFtTtUAd2QMJegA+1IhrWkQeXR 6yBaxVuiOUL/O7CaLj45oYUXtUFPUPd1vnQRJ6/uVDFQga6E3oh6YZuvegewBPZSH2+hQOIE/IFr t++4AjoGrmI/nZM3SwMtgEQhio4RhnooHJDKEX6dj4uV+TnlvK1kVszJZJBAMcaPdkOr/yzUD49w L/S1TYLLoCazLqU6vlVaEVTMfDmwij25szKuotsCtKoa62vbmwfUN5BTZ0blofKk4kggBZnZWScO LYsJygynh1bCUlpDbCYZ/yXrDNqaWEsynkvWCjTbTJ5DyWpJ6EdvK1raRuhFZYK2mcavL8DZRyx6 4AIn8+RxcBxQMen5FbkgR5nDG4OX8moBAAXmN5171jK8bR4MS8G9R+bXnSkpKams7FR1AerHXlno 8Ww9Ok8kZgoVGbuyzBmLdMHhAIlfRJQv8KQcLgU+au08U9zGbSpUFZxvo7KMjhsJ62L7C3NA3vfc U8o8NCgGg86cNLctvlsA5RVZ3dlc3txQxqtWNZwdOPOs+KyyW0WZ/Ob0h2imrIRP0duFxFK9tCik Fwkrkjm/tJiCZuvIJgSz1yTsohfRFmGy/B5rdGbTON2oZdFGMJBT0FcyqC6fGjZ/M9t5HcyAnvju sDpplaDQDzCWwMZBwmyk7pOVEO/vX0APaXe4v1e0YKcbj2+Xkpjqnr531W0rjo0eMI9IE3kVrdGD yrWKnP3LworZ08bGGPZftW+RagplbmRzdHJlYW0KZW5kb2JqCjM2IDAgb2JqCjIyMjUKZW5kb2Jq CjM3IDAgb2JqCjw8L1N1YnR5cGUvVHlwZTFDL0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggMzgg MCBSPj5zdHJlYW0KeJxlkllMG0cYx2cxeLfguC2WC4TDK9okRBwNqaJCEyq15KRAuAKKwhEfa3up jbc24BCK7RgSSIaEI1zlsMELtaCGEkiB8FAgSh7SShHqgVClVErTh9JIVatUnbWWh+6Coj70ZTU7 8//+32/+32AgNARgGBZRQpspW+qHFpNO/E3hYjEuLoSLl0BeE7wfPBUWD3JHwvZAmQTKQn1xoRuR aPR1dPNV5H4NSDDsUhebbWEarLTBWEsmnSsqO5icnPLfTnpmZiapaXh5Qh6nbLShhtwvLOopk4Ux UzW1R8lsQW0y0VrSYGpgjDZSrdNROrGsVG2iPiZP0iaaYSz1ZFL2QfLwoUPpqcLncD5t1tTZyCKL WV1D5lsyyVwyj9LRdeb/HwAAXvnAYhWAaJMZgERQAIrBaXAGnAM5IA/kg3AhChAKmsADTIU9CckN uR7ygwSXzKFb8qAejlv9KGuOO+mNVMwGT4wrW6U62Dh6HoXzNs4XbZHy1u0lKs356QV3jIKxoipc MTuOF3TU9sEJOHB7fHRtcC4a1Umns/oNsI5QMLDeccV4nVDMXoOOG03CgrEKJWhTut2GXMot1Pon 3xom59qaprisKWwcHUDp6IAEdXBmJa9ISuTj+Dd/fwtFIeXzF0iFyOQXvFLVblI+9JTwGXyavayw wP412o+Oj6w8Usm5AsiiB2ifgY38GamihD41nFrJF9qkC1f7HFBL8Ms41FxxVTUTNuRh8fwO5wB8 RKBCfMW/ELjd09LYl6BYZzyD7onY2Qn/3BIdKD9PMafLBes2XvMFkiPZL58j06p7KtL/7BiKR9Eo Vv9TlOIvwNVzicpV/g1c8RwMVVm6tLF8xLtnUuiBap9FNWbzOJbtxxgtBcugZqTh21pC8bcr111t 1ewt3KBRJHrv2cofm3n39iXkSI/au/2T/rF51dKNZTjeNe2NEeyXJnx3V/fCeeekxU+8v12qFOrX Ji5XV5R8kvROhW9xtLvP71MJvX/l3MplD5WWdslQfqHhy9+2PLPLAv0qZIMyL7YuZJiAVBKkC2Yo +RKb9J67uxlqiO1uHKqb3ZVuIZerLK7vdA7CWQJ5cdjR3dvbM+Zj+32QmBlmilX8NRzqHY10qyB1 srjhlmMQfkWgdvxp6f3MUr29sCxBjp5yRxax78VGD4UBpKIsqzT/iLYyp4RgVvhNPGdBu/54fvLJ 3QRrn51qbKqHMRbX8LwKrW3hcjQFR7kM7wZ6W8QVUMURCqiL7h63gLozwpbmCpfQv5nFjZ3Oz+Ad 4gT3j/Ki0aiuDFQvLk4HFhfomYsq0YoNEiz2WPTRiFcuskln2oYaoH7nyvrLdrpt16e6vdED5wl5 8EfIcuks9t1uUrtpaUWEYgHhap/zJYJr9xW1iAguEUFMq2vIM9A7OjTcPQyJucHasztpaVwOvdjF IUg7hGB3pZ2idGx4R3pn0FawI1W7nJQodbO47qarHy4QqGMn2CKq9qOyBPM3RjYX5sIKhjpLyO1e Tu1FZV5pIByREYGATIZIn2wPAP8CVc8yCwplbmRzdHJlYW0KZW5kb2JqCjM4IDAgb2JqCjExNTMK ZW5kb2JqCjM5IDAgb2JqCjw8L1N1YnR5cGUvVHlwZTFDL0ZpbHRlci9GbGF0ZURlY29kZS9MZW5n dGggNDAgMCBSPj5zdHJlYW0KeJxjZGBhYmBkZBTzSM0pSy3JTE7UdcrPSfFPysksLE0FyWj9kGb8 IcP0Q5a5u/tn389cVlkGnznveLt5mLt5WBb+kBH63iP4vZP/e5sAAzMjY8XEec75BZVFmekZJQoa oUHhmtraOggRQ0tLS4WkSpiMgktqcWZ6noIakFGWmpNfkJuaV2Kt4AxUnZOTmayQnlNZkFGskJiS kpoC0haWmJOareCWmZNZUJBfpqDhrKlgZGBgqAskjPwyc5NKixWCE/OKFXwUQJ5Q8CxJBJqCIsHA wMDoxMCgzMDEyMjS/X0V38+07u+C3wOB2PK7oNCPM981VL5rigu/uCv2/Q7b++4Liw8f5BD+sGf3 6ovHpLoPlW+M2Mwh/OL63i2nL0h1b6rZVLgsY33kHMdujt832R7/3ia67rsl63cLtpPLKhKKGgqq KuRLi0pbwoHSVb/PiW7+Hsj63Y1N+MPJFaUxRU35tWXyJZn59UHdHHwli35smP/ddn70IrbvrFzf Vbm/s87k4WFgAABrKKC9CmVuZHN0cmVhbQplbmRvYmoKNDAgMCBvYmoKMzk2CmVuZG9iago0MSAw IG9iago8PC9TdWJ0eXBlL1R5cGUxQy9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDQyIDAgUj4+ c3RyZWFtCnicbVRrUFNHFL7XJPfetpDWpClaMdyp+EBEeWgFoerwsM4UKALVQUQJEkIkDx4BE0jC SwVdIKCghIaAD15FgRggiDpWW3yMtVYsvkZHnVHHUaxi7exNNz96U/v40c7O7OzuOec73/n27OIY dxqG47hHslwpLQhIVCslKvd+ETMLZ7ynMbM5AK1x/uoM5c3GYls5nsCDAzy47d5EiAA+mg4vvw9P f4BxcNx2+V6UOleXL5dla+gFXyVu8PP3X/TvSVBYWBidofvbQkdLC+QyFT2PXRRJFepcpVSlCaej WG+FQr6Vlil0udkFtCQzU5rpDlsvUUhz6DVyhTw3V11EL4jyo4MDA4MC2Ck4nI4vVErz1YtouSpL rpJrdLRElUl/qZTKJLRSkil1A0Qr5Zp8Hb00UK76JzperswoLKD/LJmOV4fRsXSiVFaokOT/14Jh mEdsnDo+Yd2axCQ6KBjDArDFWAK2BAvCgrH5WAi2FMMxASbEPFk5MS62EbuAC/EK3DmtdpqLU8Wd x/XjqrljsI7PQGDVHmdeWQW/THkJc5lrMFJULDVo9MXZmcm6UECtJSKNDX0+jJIE42bznXrKivq0 5MTOZgOIoVwJpHAAxBj0kbsoLcmG9xEnYSSP/7snsDq5VhziDqZ1iuP8lLkmcqWQILTUGMF6wqNW MrLeYAbjFJPA4jY3TzSwuKkkynPVohKmloc2aol7u5pLQSTlWkgCX4M2dCcbV2olV5qKD4FXFDOf hCbXKM9M8Jnq8i4muAvvfgzNjzmwjkkXoY8C/ZEYzXo6Dwqg4PlvUAy9ljxDH/oY1aL75/3RbMTb /PnqzKzD9iIf9ZmSayyRZ6OXxsV8Z1ZZe7mbusBNPcThJRxhmDIRc4gEF5oGrM3mJrPJZmK5lmpJ W7W5qqWizdAoA3EUeky6RIyWh1ZpiWFgrrRvolxxpFD7f9S9SRY1niXPZ74FVnjQDk8PaK2Cl1Ow BOJewkm4GTpEHbstezrAbXC2afjwhd7+i+AKGDLYcru3OpZ2BQBKeBdZtMREZVM5iKJcMSRYXlm+ asdbaSPq9GbwM8UUcYWTnXv3dsJZlzb5LkxIQeR2Q02txl0liml12vvxY5BgVkKC41yHQkSIqAt3 rHhztbnfcsI+ccX2BEAOBdOQN/RFSezwRr5oi19P2PkvxMclvdvHC0aTZ1yNgJ7pMAS0gEawv4Zq INBj55hoGJzQ9inOpvb6A8QDC1Rzt6ZlZWzQJINUsMUi610/mvMSwHfA8+4XgycGHaPtY4B6K8XF wRttcJlN+7Yb3zAFsEQE9RqyNFynDwcUmgvzia76hk4x9CYgDxzUW4KoI4RwshrO4bm6WD3+aktW j9Ay46q/Wm2liW216xRUwbnkXWDRH1hB8Z1LgJV57ZZ9agoa3bKPOOdbRdK67U2qYygDNsz4sbnn wNHO3g7rEBgFw8aBvG5KeGtQGtoRMEs4grq1xI3KpjIQ/TZZeelq9yX3sMnqjc3uZCnkd7WwAl3k wWWEK5V5KBLe6tq/zw6nj6UHpBRJZFpxWl72Tv/d7sqN7UV9TFw79B8UjD+EhldewlNMkjNUVERU acrKikE5KDYV78syZ+3LAelgS/E2VbZCJwEbQLgjCXITrkvPZByRNhrri0ABJdSvTUmLDI49B/kp Yg0hPNWDsnkHiRrrAXML2A8sVdYdNr290g4oSD668/pe8g9oxrjPJ2MSBzhLnRuyXRoZ0sr6xN/k mPO+TmDF5bs/iWrQgkP5Qw50sKzQ2kCegTxQv99kqm3dazE1Aaq9UZ/j437g2yo1JRX6CkO1ZA+l h90tZERNSRM4STGTpBvlJnNoAodPHnIYNZwtMtZnJRorNoOZqJKAETD60dPjN8HtmS9X3JqTvKFw a5Y4R67PKY5u3zXD/qK/9ydA3f8+cflnaYuXB/ugNWgdr5T5mORvb2PWt8HkNqLn3Qfv9ezz8HjQ 6uGJYX8AGW3eyQplbmRzdHJlYW0KZW5kb2JqCjQyIDAgb2JqCjE0ODUKZW5kb2JqCjI2IDAgb2Jq Cjw8L0Jhc2VGb250L01VSE9TWStUVEUxM0ZGNzMwdDAwL0ZvbnREZXNjcmlwdG9yIDI1IDAgUi9U eXBlL0ZvbnQKL0ZpcnN0Q2hhciAxL0xhc3RDaGFyIDIvV2lkdGhzWyA3NTkgNzg0XQovRW5jb2Rp bmcgNDMgMCBSL1N1YnR5cGUvVHJ1ZVR5cGU+PgplbmRvYmoKNDMgMCBvYmoKPDwvVHlwZS9FbmNv ZGluZy9CYXNlRW5jb2RpbmcvV2luQW5zaUVuY29kaW5nL0RpZmZlcmVuY2VzWwoxL2E3NS9hNzld Pj4KZW5kb2JqCjExIDAgb2JqCjw8L0Jhc2VGb250L0JZWVZUSitIZWx2ZXRpY2EtQm9sZC9Gb250 RGVzY3JpcHRvciAxMCAwIFIvVHlwZS9Gb250Ci9GaXJzdENoYXIgMzIvTGFzdENoYXIgMTIwL1dp ZHRoc1sKMjc4IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwCjAgMCAwIDAgMCAwIDAgMCAw IDAgMCAwIDAgMCAwIDYxMQowIDcyMiA3MjIgMCAwIDAgMCAwIDcyMiAwIDAgMCA2MTEgMCA3MjIg MAo2NjcgNzc4IDAgNjY3IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwCjAgNTU2IDAgNTU2IDYxMSA1 NTYgMCA2MTEgNjExIDI3OCAwIDAgMjc4IDg4OSA2MTEgNjExCjYxMSAwIDM4OSA1NTYgMzMzIDYx MSAwIDc3OCA1NTZdCi9FbmNvZGluZy9XaW5BbnNpRW5jb2RpbmcvU3VidHlwZS9UeXBlMT4+CmVu ZG9iagoxMyAwIG9iago8PC9CYXNlRm9udC9CVEJOV08rSGVsdmV0aWNhL0ZvbnREZXNjcmlwdG9y IDEyIDAgUi9UeXBlL0ZvbnQKL0ZpcnN0Q2hhciAzMi9MYXN0Q2hhciAxNTAvV2lkdGhzWwoyNzgg Mjc4IDM1NSAwIDAgMCA2NjcgMCAzMzMgMzMzIDAgMCAyNzggMzMzIDI3OCAyNzgKMCAwIDAgMCAw IDAgMCAwIDAgMCAwIDAgMCAwIDU4NCA1NTYKMCA2NjcgMCA3MjIgNzIyIDY2NyA2MTEgMCAwIDI3 OCAwIDAgNTU2IDgzMyA3MjIgNzc4CjY2NyA3NzggNzIyIDY2NyA2MTEgMCA2NjcgOTQ0IDAgMCAw IDAgMCAwIDAgNTU2CjAgNTU2IDU1NiA1MDAgNTU2IDU1NiAyNzggNTU2IDU1NiAyMjIgMjIyIDAg MjIyIDgzMyA1NTYgNTU2CjU1NiA1NTYgMzMzIDUwMCAyNzggNTU2IDUwMCA3MjIgNTAwIDUwMCAw IDAgMCAwIDAgMAowIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwCjAgMCAwIDMzMyAzMzMg MzUwIDU1Nl0KL0VuY29kaW5nL1dpbkFuc2lFbmNvZGluZy9TdWJ0eXBlL1R5cGUxPj4KZW5kb2Jq CjE1IDAgb2JqCjw8L0Jhc2VGb250L0lGTFRYSStIZWx2ZXRpY2EtT2JsaXF1ZS9Gb250RGVzY3Jp cHRvciAxNCAwIFIvVHlwZS9Gb250Ci9GaXJzdENoYXIgMzIvTGFzdENoYXIgMTE5L1dpZHRoc1sK Mjc4IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwCjAgMCAwIDAgMCAwIDAgMCAwIDAgMCAw IDAgMCAwIDU1NgowIDAgNjY3IDAgMCAwIDYxMSAwIDAgMCAwIDAgNTU2IDgzMyA3MjIgMAo2Njcg Nzc4IDcyMiA2NjcgMCAwIDAgOTQ0IDAgMCAwIDAgMCAwIDAgMAowIDU1NiAwIDUwMCA1NTYgNTU2 IDAgMCA1NTYgMjIyIDAgMCAwIDAgMCA1NTYKMCAwIDAgNTAwIDI3OCAwIDAgNzIyXQovRW5jb2Rp bmcvV2luQW5zaUVuY29kaW5nL1N1YnR5cGUvVHlwZTE+PgplbmRvYmoKMTkgMCBvYmoKPDwvQmFz ZUZvbnQvTFZRRVBEK1RpbWVzLUJvbGQvRm9udERlc2NyaXB0b3IgMTggMCBSL1R5cGUvRm9udAov Rmlyc3RDaGFyIDY1L0xhc3RDaGFyIDExNi9XaWR0aHNbIDcyMiAwIDAgMCAwIDAgMCAwIDAgMCAw IDAgMCAwIDAKMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMAowIDAgMCAwIDAgMCAwIDUw MCA1NTYgMjc4IDAgMCAyNzggODMzIDAgNTAwCjAgMCA0NDQgMCAzMzNdCi9FbmNvZGluZy9XaW5B bnNpRW5jb2RpbmcvU3VidHlwZS9UeXBlMT4+CmVuZG9iagoxNyAwIG9iago8PC9CYXNlRm9udC9J R1BZTVIrSGVsdmV0aWNhLUJvbGRPYmxpcXVlL0ZvbnREZXNjcmlwdG9yIDE2IDAgUi9UeXBlL0Zv bnQKL0ZpcnN0Q2hhciA2Ni9MYXN0Q2hhciA2Ni9XaWR0aHNbIDcyMl0KL0VuY29kaW5nL1dpbkFu c2lFbmNvZGluZy9TdWJ0eXBlL1R5cGUxPj4KZW5kb2JqCjkgMCBvYmoKPDwvQmFzZUZvbnQvT0lQ VkJCK1RpbWVzLVJvbWFuL0ZvbnREZXNjcmlwdG9yIDggMCBSL1R5cGUvRm9udAovRmlyc3RDaGFy IDMyL0xhc3RDaGFyIDExMS9XaWR0aHNbCjI1MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAg MAowIDUwMCA1MDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMAowIDAgMCAwIDAgMCA1NTYgMCAw IDAgMCAwIDYxMSA4ODkgNzIyIDAKNTU2IDcyMiA2NjcgNTU2IDAgMCAwIDAgMCAwIDAgMCAwIDAg MCAwCjAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDUwMF0KL0VuY29kaW5nL1dpbkFuc2lF bmNvZGluZy9TdWJ0eXBlL1R5cGUxPj4KZW5kb2JqCjI1IDAgb2JqCjw8L1R5cGUvRm9udERlc2Ny aXB0b3IvRm9udE5hbWUvTVVIT1NZK1RURTEzRkY3MzB0MDAvRm9udEJCb3hbMjIgLTExIDc0OSA3 MTRdL0ZsYWdzIDQKL0FzY2VudCA3MTQKL0NhcEhlaWdodCA3MTQKL0Rlc2NlbnQgLTExCi9JdGFs aWNBbmdsZSAwCi9TdGVtViAxMTIKL01pc3NpbmdXaWR0aCA3NTAKL0ZvbnRGaWxlMiAyOSAwIFI+ PgplbmRvYmoKMTAgMCBvYmoKPDwvVHlwZS9Gb250RGVzY3JpcHRvci9Gb250TmFtZS9CWVlWVEor SGVsdmV0aWNhLUJvbGQvRm9udEJCb3hbMCAtMjE4IDgyNCA3NDRdL0ZsYWdzIDQKL0FzY2VudCA3 NDQKL0NhcEhlaWdodCA3NDQKL0Rlc2NlbnQgLTIxOAovSXRhbGljQW5nbGUgMAovU3RlbVYgMTIz Ci9NaXNzaW5nV2lkdGggMjc4Ci9DaGFyU2V0KC9ML0Evbi9jL0Ivby9kL04vcC9lL1Avci9nL1Ev cy9oL3QvaS9TL0gvdS93L2wvYS94L20vcXVlc3Rpb24vc3BhY2UpL0ZvbnRGaWxlMyAzMSAwIFI+ PgplbmRvYmoKMTIgMCBvYmoKPDwvVHlwZS9Gb250RGVzY3JpcHRvci9Gb250TmFtZS9CVEJOV08r SGVsdmV0aWNhL0ZvbnRCQm94Wy0yMiAtMjE4IDkyOSA3NDFdL0ZsYWdzIDQKL0FzY2VudCA3NDEK L0NhcEhlaWdodCA3NDEKL0Rlc2NlbnQgLTIxOAovSXRhbGljQW5nbGUgMAovU3RlbVYgMTM5Ci9N aXNzaW5nV2lkdGggMjc4Ci9DaGFyU2V0KC9ML0EveS9uL2MvTS9xdW90ZWRibHJpZ2h0L28vZC9O L0MvcC9lL08vRC9xL2YvUC9FL2VuZGFzaC9yL2cvUS9GL3MvaC91bmRlcnNjb3JlL1IvdC9pL1Mv dS9qL1QvSS92L2J1bGxldC93L3F1b3RlZGJsbGVmdC9sL2EvZ3JlYXRlci9WL3gvbS9iL3F1ZXN0 aW9uL1cvcGFyZW5yaWdodC9zcGFjZS9jb21tYS9leGNsYW0vaHlwaGVuL3F1b3RlZGJsL3Blcmlv ZC9zbGFzaC9hbXBlcnNhbmQvcGFyZW5sZWZ0KS9Gb250RmlsZTMgMzMgMCBSPj4KZW5kb2JqCjE0 IDAgb2JqCjw8L1R5cGUvRm9udERlc2NyaXB0b3IvRm9udE5hbWUvSUZMVFhJK0hlbHZldGljYS1P YmxpcXVlL0ZvbnRCQm94WzAgLTU5IDEwODQgNzQxXS9GbGFncyA0Ci9Bc2NlbnQgNzQxCi9DYXBI ZWlnaHQgNzQxCi9EZXNjZW50IC01OQovSXRhbGljQW5nbGUgMAovU3RlbVYgMTYyCi9NaXNzaW5n V2lkdGggMjc4Ci9DaGFyU2V0KC9ML2MvTS9CL28vZC9OL2UvUC9RL0Yvcy9oL1IvdC9pL1Mvdy9h L3F1ZXN0aW9uL1cvc3BhY2UpL0ZvbnRGaWxlMyAzNSAwIFI+PgplbmRvYmoKMTggMCBvYmoKPDwv VHlwZS9Gb250RGVzY3JpcHRvci9Gb250TmFtZS9MVlFFUEQrVGltZXMtQm9sZC9Gb250QkJveFsw IC0yMDYgODE0IDY5MV0vRmxhZ3MgNAovQXNjZW50IDY5MQovQ2FwSGVpZ2h0IDY5MQovRGVzY2Vu dCAtMjA2Ci9JdGFsaWNBbmdsZSAwCi9TdGVtViAxMjIKL01pc3NpbmdXaWR0aCAyNTAKL0NoYXJT ZXQoL0Evby9yL2cvaC90L2kvbC9tKS9Gb250RmlsZTMgMzcgMCBSPj4KZW5kb2JqCjE2IDAgb2Jq Cjw8L1R5cGUvRm9udERlc2NyaXB0b3IvRm9udE5hbWUvSUdQWU1SK0hlbHZldGljYS1Cb2xkT2Js aXF1ZS9Gb250QkJveFswIDAgNzYyIDcyOV0vRmxhZ3MgNAovQXNjZW50IDcyOQovQ2FwSGVpZ2h0 IDcyOQovRGVzY2VudCAwCi9JdGFsaWNBbmdsZSAwCi9TdGVtViAxMTQKL01pc3NpbmdXaWR0aCAy NzgKL0NoYXJTZXQoL0IpL0ZvbnRGaWxlMyAzOSAwIFI+PgplbmRvYmoKOCAwIG9iago8PC9UeXBl L0ZvbnREZXNjcmlwdG9yL0ZvbnROYW1lL09JUFZCQitUaW1lcy1Sb21hbi9Gb250QkJveFswIC0x NzggODYzIDY3Nl0vRmxhZ3MgNAovQXNjZW50IDY3NgovQ2FwSGVpZ2h0IDY3NgovRGVzY2VudCAt MTc4Ci9JdGFsaWNBbmdsZSAwCi9TdGVtViAxMjkKL01pc3NpbmdXaWR0aCAyNTAKL0NoYXJTZXQo L0wvTS9vL04vUC9RL0YvUi9TL3NwYWNlL29uZS90d28pL0ZvbnRGaWxlMyA0MSAwIFI+PgplbmRv YmoKMiAwIG9iago8PC9Qcm9kdWNlcihHUEwgR2hvc3RzY3JpcHQgOC4xNSkKL0NyZWF0aW9uRGF0 ZShEOjIwMDcwMjAyMTkzNTQ0KQovTW9kRGF0ZShEOjIwMDcwMjAyMTkzNTQ0KQovVGl0bGUoTWlj cm9zb2Z0IFBvd2VyUG9pbnQgLSBRU1BFQyBvcGVuIGlzc3VlcyBDSyAwMTMxMDcpCi9DcmVhdG9y KFBTY3JpcHQ1LmRsbCBWZXJzaW9uIDUuMikKL0F1dGhvcihnYXNoKT4+ZW5kb2JqCnhyZWYKMCA0 NAowMDAwMDAwMDAwIDY1NTM1IGYgCjAwMDAwMDQ3NDUgMDAwMDAgbiAKMDAwMDAyNDM5OSAwMDAw MCBuIAowMDAwMDA0NjY5IDAwMDAwIG4gCjAwMDAwMDQzNDUgMDAwMDAgbiAKMDAwMDAwMDAxNSAw MDAwMCBuIAowMDAwMDAyMjA2IDAwMDAwIG4gCjAwMDAwMDQ3OTMgMDAwMDAgbiAKMDAwMDAyNDE1 MyAwMDAwMCBuIAowMDAwMDIyMTUwIDAwMDAwIG4gCjAwMDAwMjI2OTUgMDAwMDAgbiAKMDAwMDAy MDQxNiAwMDAwMCBuIAowMDAwMDIyOTgwIDAwMDAwIG4gCjAwMDAwMjA4MTAgMDAwMDAgbiAKMDAw MDAyMzQyNSAwMDAwMCBuIAowMDAwMDIxMzE5IDAwMDAwIG4gCjAwMDAwMjM5MzIgMDAwMDAgbiAK MDAwMDAyMTk4MCAwMDAwMCBuIAowMDAwMDIzNzAwIDAwMDAwIG4gCjAwMDAwMjE3MDIgMDAwMDAg biAKMDAwMDAwNDgzNCAwMDAwMCBuIAowMDAwMDA0ODY0IDAwMDAwIG4gCjAwMDAwMDQ1MDYgMDAw MDAgbiAKMDAwMDAwMjIyNiAwMDAwMCBuIAowMDAwMDA0MzI0IDAwMDAwIG4gCjAwMDAwMjI0ODkg MDAwMDAgbiAKMDAwMDAyMDE3MCAwMDAwMCBuIAowMDAwMDA0OTQ5IDAwMDAwIG4gCjAwMDAwMDQ5 NzkgMDAwMDAgbiAKMDAwMDAwNTA0MiAwMDAwMCBuIAowMDAwMDA4MzM4IDAwMDAwIG4gCjAwMDAw MDgzNTkgMDAwMDAgbiAKMDAwMDAxMDcwMyAwMDAwMCBuIAowMDAwMDEwNzI0IDAwMDAwIG4gCjAw MDAwMTQ0NjMgMDAwMDAgbiAKMDAwMDAxNDQ4NCAwMDAwMCBuIAowMDAwMDE2Nzk1IDAwMDAwIG4g CjAwMDAwMTY4MTYgMDAwMDAgbiAKMDAwMDAxODA1NSAwMDAwMCBuIAowMDAwMDE4MDc2IDAwMDAw IG4gCjAwMDAwMTg1NTggMDAwMDAgbiAKMDAwMDAxODU3OCAwMDAwMCBuIAowMDAwMDIwMTQ5IDAw MDAwIG4gCjAwMDAwMjAzMjggMDAwMDAgbiAKdHJhaWxlcgo8PCAvU2l6ZSA0NCAvUm9vdCAxIDAg UiAvSW5mbyAyIDAgUgovSUQgWygWpMckP3JqF4CAKlOfQj0JKSgWpMckP3JqF4CAKlOfQj0JKV0K Pj4Kc3RhcnR4cmVmCjI0NjE2CiUlRU9GCg== ------_=_NextPart_001_01C7472B.801EAF70 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis ------_=_NextPart_001_01C7472B.801EAF70-- From nsis-bounces@ietf.org Sat Feb 03 14:43:39 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDQma-0007tK-4y; Sat, 03 Feb 2007 14:42:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDQmY-0007tC-NR for nsis@ietf.org; Sat, 03 Feb 2007 14:42:42 -0500 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HDQmV-0001Ih-2T for nsis@ietf.org; Sat, 03 Feb 2007 14:42:42 -0500 Received: (qmail invoked by alias); 03 Feb 2007 19:42:37 -0000 Received: from p54984A30.dip.t-dialin.net (EHLO [192.168.178.21]) [84.152.74.48] by mail.gmx.net (mp007) with SMTP; 03 Feb 2007 20:42:37 +0100 X-Authenticated: #29516787 Message-ID: <45C4E5AC.90904@gmx.net> Date: Sat, 03 Feb 2007 14:42:36 -0500 From: Hannes Tschofenig User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: "ASH, GERALD R \(JERRY\), SBCLABS" Subject: Re: State Machines .... was [NSIS] Summary of QSPEC call References: <9473683187ADC049A855ED2DA739ABCA0DDC818B@KCCLUST06EVS1.ugd.att.com> In-Reply-To: <9473683187ADC049A855ED2DA739ABCA0DDC818B@KCCLUST06EVS1.ugd.att.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: nsis X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Jerry, draft-fu-nsis-qos-nslp-statemachine-05.txt is an informational proposal. Node internal interactions haven't received a lot of attention given that the QoS NSLP also just hints the API in the appendix as informational. The current state machine document does not go into lot of details with any local node dependent functions, including security and AAA interactions. I will, however, investigate Cornelia's thoughts to determine whether there is a problem. Ciao Hannes ASH, GERALD R (JERRY), SBCLABS wrote: > Certainly this ID is very relevant to the discussion. According to the > ID, the QoS NSLP state machine only receives 2 types of information from > the RMF: > > RMF():Performs Resource Management Function and returns the following > values{AVAIL, NO_AVAIL}. > > Therefore it is not possible to trigger different QoS NSLP message > responses when the QoS NSLP is in a particular state, based on input > >from the RMF that is dependent on the particular QOSM being used by the > RMF. > > As illustrated in Cornelia's slide 2 (3rd bullet) example in the > attached, what RMD is doing would appear to be precluded by the current > QoS NSLP state machine, i.e.: > > "This is a tearing RESERVE and the RMF tells me that the RMD control > info says to not generate a new message" -> needed by RMD for partial > resv. Release > > Since this behavior deviates from the defined QoS NSLP State Machine, as > John says, "If the QOSM has a different state machine, then that QoSM > MUST be a Standards Track document that extends the QoS NSLP." > > Thanks, > Jerry > > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > Sent: Friday, February 02, 2007 11:26 AM > To: Kappler, Cornelia > Cc: Martin Stiemerling; Georgios Karagiannis; nsis > Subject: State Machines .... was [NSIS] Summary of QSPEC call > > Hi all, > > let me repeat again what I said during the phone conference call. > > The QoS NSLP implicitly contains a state machine and an explicit > description of the QoS NSLP state machine can be found in: > http://tools.ietf.org/wg/nsis/draft-fu-nsis-qos-nslp-statemachine-05.txt > http://www.ietf.org/internet-drafts/draft-fu-nsis-qos-nslp-statemachine- > 05.pdf > > The QoS NSLP alone is not useful. In order todo something it needs to > (a) carry some QoS parameters with the corresponding meaning and (b) the > > state transitions need to be triggered. These triggers might come from > various sources. Some of the triggers have been discussed in the context > > of RMD when an edge node of an RMD domain receives an end-to-end > signaling message. Some actions might have to be taken within the RMD > domain based on this incoming message. The type of message, the content > of the QoS parameters, security parameters, the reservation state within > > the RMD domain, etc. influence the decision making process. > > The QoSM has its own state machine and it interacts with the QoS NSLP > whereby these actions have to fit to the QoS NSLP state machine but > there is a lot of freedom since the QoS NSLP just defines basic message > patterns. > > Hence, when someone says that the QoSM MUST NOT modify the QoS NSLP > state machine it would be good to be very explicit what that actually > means. > > This procdure of interworking between different state machines at > different components is nothing new. Diameter (RFC 3588 and the > applications) and EAP - EAP methods do the same. > > Ciao > Hannes > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Feb 05 04:41:36 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HE0LG-0000rR-D1; Mon, 05 Feb 2007 04:40:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HE0LE-0000qy-EA for nsis@ietf.org; Mon, 05 Feb 2007 04:40:52 -0500 Received: from rotterdam.ewi.utwente.nl ([130.89.10.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HE0LC-0000yv-St for nsis@ietf.org; Mon, 05 Feb 2007 04:40:52 -0500 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by rotterdam.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id l159eESK016538; Mon, 5 Feb 2007 10:40:24 +0100 (MET) From: "Georgios Karagiannis" To: References: <45C36614.1020102@gmx.net> <071568CA7B789D4AA170CEF8C9613B4F20B508@daebe103.NOE.Nokia.com> Subject: RE: State Machines .... was [NSIS] Summary of QSPEC call Date: Mon, 5 Feb 2007 10:40:31 +0100 Message-ID: <001a01c74909$b0d45ff0$4c0d5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcdG5zF6DBwT6QRpSBuS5xvj4YwwRwAK9UJwAH1k8GA= In-Reply-To: <071568CA7B789D4AA170CEF8C9613B4F20B508@daebe103.NOE.Nokia.com> X-Spam-Score: 1.5 (*) FVGT_s_MIXCASEWORDS, FVGT_s_OBFU_ODD06, FVGT_s_OBFU_Q1, FVGT_u_HAS_2LETTERFLDR X-Scanned-By: MIMEDefang 2.52 on 130.89.10.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (rotterdam.ewi.utwente.nl [130.89.10.5]); Mon, 05 Feb 2007 10:40:24 +0100 (MET) X-Spam-Score: 0.0 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Cc: stiemerling@netlab.nec.de, nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi John But any QOSM describes the functionality of RMF, thus it uses a different QOSM state machine that is different than the QoS-NSLP state machine. Thus I do not understand what you want to say in your e-mail! Furthermore, as Hannes emphasized in his e-mails the current QoS-NSLP state machine document is an Informational RFC and it does not go into lot of details with any local node dependent functions, including QOSM, security and AAA interactions. Note that what we have decided in the meeting is to emphasize that: QOSMs all utilize the state machines of the underlying NSIS protocols and are not expected to re-define or extend these. Note that a QOSM can however, extend the RMF triggers to/from the QOS-NSLP functionality, which might affect the QoS-NSLP state machine. Maybe the last sentence is not exactly the same as the words that I have proposed during the meeting, but the semantics are. Best regards, Georgios > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > Sent: vrijdag 2 februari 2007 22:47 > To: Hannes.Tschofenig@gmx.net; cornelia.kappler@siemens.com > Cc: stiemerling@netlab.nec.de; karagian@cs.utwente.nl; nsis@ietf.org > Subject: RE: State Machines .... was [NSIS] Summary of QSPEC call > > Hannes, > > The issue is that if any QoSM deviates (for example having > some signaling optimizations within the QoSM) from the > defined QoS NSLP State Machine, then those MUST be optional, > and the QoSM needs to describe how the QoSM falls back to the > standard State Machine. If the QOSM has a different state > machine, then that QoSM MUST be a Standards Track document > that extends the QoS NSLP. > > All QoSM must be able to handle 'standard' QoS NSLP messaging > flows. If they modify (or introduce) new messaging flows, > these flows should be optimizations (which are optional) and > need to discuss how to fall back to standard messaging sequences. > > I believe we discussed this on the call and people seemed to agree. > > John > > >-----Original Message----- > >From: ext Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > >Sent: 02 February, 2007 08:26 > >To: Kappler, Cornelia > >Cc: Martin Stiemerling; Georgios Karagiannis; nsis > >Subject: State Machines .... was [NSIS] Summary of QSPEC call > > > >Hi all, > > > >let me repeat again what I said during the phone conference call. > > > >The QoS NSLP implicitly contains a state machine and an explicit > >description of the QoS NSLP state machine can be found in: > >http://tools.ietf.org/wg/nsis/draft-fu-nsis-qos-nslp-statemachi > >ne-05.txt > >http://www.ietf.org/internet-drafts/draft-fu-nsis-qos-nslp-stat > >emachine-05.pdf > > > >The QoS NSLP alone is not useful. In order todo something it needs to > >(a) carry some QoS parameters with the corresponding meaning and (b) > >the state transitions need to be triggered. These triggers > might come > >from various sources. Some of the triggers have been > discussed in the > >context of RMD when an edge node of an RMD domain receives an > >end-to-end signaling message. Some actions might have to be taken > >within the RMD domain based on this incoming message. The type of > >message, the content of the QoS parameters, security parameters, the > >reservation state within the RMD domain, etc. influence the decision > >making process. > > > >The QoSM has its own state machine and it interacts with the > QoS NSLP > >whereby these actions have to fit to the QoS NSLP state machine but > >there is a lot of freedom since the QoS NSLP just defines > basic message > >patterns. > > > >Hence, when someone says that the QoSM MUST NOT modify the QoS NSLP > >state machine it would be good to be very explicit what that > actually > >means. > > > >This procdure of interworking between different state machines at > >different components is nothing new. Diameter (RFC 3588 and the > >applications) and EAP - EAP methods do the same. > > > >Ciao > >Hannes > > > > > >_______________________________________________ > >nsis mailing list > >nsis@ietf.org > >https://www1.ietf.org/mailman/listinfo/nsis > > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Feb 05 05:09:02 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HE0lr-0001OC-Rl; Mon, 05 Feb 2007 05:08:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HE0lq-0001O7-MY for nsis@ietf.org; Mon, 05 Feb 2007 05:08:22 -0500 Received: from rotterdam.ewi.utwente.nl ([130.89.10.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HE0lo-00062l-S9 for nsis@ietf.org; Mon, 05 Feb 2007 05:08:22 -0500 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by rotterdam.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id l15A7pQW018283; Mon, 5 Feb 2007 11:07:55 +0100 (MET) From: "Georgios Karagiannis" To: "'ASH, GERALD R \(JERRY\), SBCLABS'" , "'Hannes Tschofenig'" , "'nsis'" References: <9473683187ADC049A855ED2DA739ABCA0DDC818B@KCCLUST06EVS1.ugd.att.com> <9473683187ADC049A855ED2DA739ABCA0DDC818C@KCCLUST06EVS1.ugd.att.com> Subject: RE: State Machines .... was [NSIS] Summary of QSPEC call Date: Mon, 5 Feb 2007 11:08:08 +0100 Message-ID: <002f01c7490d$8c2e8550$4c0d5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcdG52ID3k5BeYFGQcSKMpuMyZMTRwAECO3QAAm62HAAAztwsAB4XniQ In-Reply-To: <9473683187ADC049A855ED2DA739ABCA0DDC818C@KCCLUST06EVS1.ugd.att.com> X-Spam-Score: 2.1 (**) FVGT_s_MIXCASEWORDS, FVGT_s_OBFU_ODD06, FVGT_s_OBFU_Q1, FVGT_u_HAS_2LETTERFLDR, J_CHICKENPOX_65 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (rotterdam.ewi.utwente.nl [130.89.10.5]); Mon, 05 Feb 2007 11:07:56 +0100 (MET) X-Spam-Score: 0.0 (/) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Jerry Please note that any QOSM describes the functionality of RMF, thus it uses a different QOSM state machine that is different than the QoS-NSLP state machine. Furthermore, as Hannes emphasized in his e-mails the current QoS-NSLP state machine document is an Informational RFC and it does not go into lot of details with any local node dependent functions, including QOSM, security and AAA interactions. Regarding the following paragraph, as I mentioned during the telephone conference meeting, the following RMD feature can be questionable and therefore we will change it. > As illustrated in Cornelia's slide 2 (3rd bullet) example in > the attached, what RMD is doing would appear to be precluded > by the current QoS NSLP state machine, i.e.: > > "This is a tearing RESERVE and the RMF tells me that the RMD > control info says to not generate a new message" -> needed by > RMD for partial resv. Release However, all other features included in the RMD-QOSM and in all other existing QOSMs can be and should be supported by the current QoS-NSLP functionality. Best Regards, Georgios > -----Original Message----- > From: ASH, GERALD R (JERRY), SBCLABS [mailto:gash@att.com] > Sent: zaterdag 3 februari 2007 1:38 > To: Hannes Tschofenig; nsis > Cc: ASH, GERALD R (JERRY), SBCLABS > Subject: RE: State Machines .... was [NSIS] Summary of QSPEC call > > Certainly this ID is very relevant to the discussion. > According to the ID, the QoS NSLP state machine only receives > 2 types of information from the RMF: > > RMF():Performs Resource Management Function and returns the following > values{AVAIL, NO_AVAIL}. > > Therefore it is not possible to trigger different QoS NSLP > message responses when the QoS NSLP is in a particular state, > based on input from the RMF that is dependent on the > particular QOSM being used by the RMF. > > As illustrated in Cornelia's slide 2 (3rd bullet) example in > the attached, what RMD is doing would appear to be precluded > by the current QoS NSLP state machine, i.e.: > > "This is a tearing RESERVE and the RMF tells me that the RMD > control info says to not generate a new message" -> needed by > RMD for partial resv. Release > > Since this behavior deviates from the defined QoS NSLP State > Machine, as John says, "If the QOSM has a different state > machine, then that QoSM MUST be a Standards Track document > that extends the QoS NSLP." > > Thanks, > Jerry > > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > Sent: Friday, February 02, 2007 11:26 AM > To: Kappler, Cornelia > Cc: Martin Stiemerling; Georgios Karagiannis; nsis > Subject: State Machines .... was [NSIS] Summary of QSPEC call > > Hi all, > > let me repeat again what I said during the phone conference call. > > The QoS NSLP implicitly contains a state machine and an > explicit description of the QoS NSLP state machine can be found in: > http://tools.ietf.org/wg/nsis/draft-fu-nsis-qos-nslp-statemach > ine-05.txt > http://www.ietf.org/internet-drafts/draft-fu-nsis-qos-nslp-sta > temachine- > 05.pdf > > The QoS NSLP alone is not useful. In order todo something it needs to > (a) carry some QoS parameters with the corresponding meaning > and (b) the > > state transitions need to be triggered. These triggers might > come from various sources. Some of the triggers have been > discussed in the context > > of RMD when an edge node of an RMD domain receives an > end-to-end signaling message. Some actions might have to be > taken within the RMD domain based on this incoming message. > The type of message, the content of the QoS parameters, > security parameters, the reservation state within > > the RMD domain, etc. influence the decision making process. > > The QoSM has its own state machine and it interacts with the > QoS NSLP whereby these actions have to fit to the QoS NSLP > state machine but there is a lot of freedom since the QoS > NSLP just defines basic message patterns. > > Hence, when someone says that the QoSM MUST NOT modify the > QoS NSLP state machine it would be good to be very explicit > what that actually means. > > This procdure of interworking between different state > machines at different components is nothing new. Diameter > (RFC 3588 and the > applications) and EAP - EAP methods do the same. > > Ciao > Hannes > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Feb 05 11:46:21 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HE6yL-0001OD-L2; Mon, 05 Feb 2007 11:45:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HE6yK-0001O7-8H for nsis@ietf.org; Mon, 05 Feb 2007 11:45:40 -0500 Received: from mail120.messagelabs.com ([216.82.250.83]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HE6yF-00074S-MD for nsis@ietf.org; Mon, 05 Feb 2007 11:45:40 -0500 X-VirusChecked: Checked X-Env-Sender: gash@att.com X-Msg-Ref: server-4.tower-120.messagelabs.com!1170693934!20762911!1 X-StarScan-Version: 5.5.10.7.1; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 28258 invoked from network); 5 Feb 2007 16:45:34 -0000 Received: from unknown (HELO attrh3i.attrh.att.com) (134.24.146.4) by server-4.tower-120.messagelabs.com with SMTP; 5 Feb 2007 16:45:34 -0000 Received: from attrh.att.com (localhost [127.0.0.1]) by attrh3i.attrh.att.com (8.13.7/8.13.7) with ESMTP id l15GjYcu016119; Mon, 5 Feb 2007 11:45:34 -0500 (EST) Received: from kcclust06evs1.ugd.att.com ([135.38.164.89]) by attrh3i.attrh.att.com (8.13.7/8.13.7) with ESMTP id l15Gj3Vb015788; Mon, 5 Feb 2007 11:45:31 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: State Machines .... was [NSIS] Summary of QSPEC call Date: Mon, 5 Feb 2007 10:45:24 -0600 Message-ID: <9473683187ADC049A855ED2DA739ABCA0DDC8198@KCCLUST06EVS1.ugd.att.com> In-Reply-To: <001a01c74909$b0d45ff0$4c0d5982@dynamic.ewi.utwente.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: State Machines .... was [NSIS] Summary of QSPEC call Thread-Index: AcdG5zF6DBwT6QRpSBuS5xvj4YwwRwAK9UJwAH1k8GAADar3kA== From: "ASH, GERALD R \(JERRY\), ATTLABS" To: "Georgios Karagiannis" X-Spam-Score: 0.0 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c Cc: "ASH, GERALD R \(JERRY\), ATTLABS" , nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Georgios,=20 > -----Original Message----- > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl]=20 > Sent: Monday, February 05, 2007 4:41 AM > To: john.loughney@nokia.com > Cc: stiemerling@netlab.nec.de; nsis@ietf.org > Subject: RE: State Machines .... was [NSIS] Summary of QSPEC call >=20 > Hi John >=20 > But any QOSM describes the functionality of RMF, thus it uses=20 > a different QOSM state machine=20 > that is different than the QoS-NSLP state machine. Thus I do=20 > not understand what you want to say in your e-mail! >=20 > Furthermore, as Hannes emphasized in his e-mails the current QoS-NSLP=20 > state machine document is an Informational RFC and it does=20 > not go into lot of details=20 > with any local node dependent functions, including QOSM,=20 > security and AAA interactions. =20 >=20 > Note that what we have decided in the meeting is to emphasize that: >=20 > QOSMs all utilize the > state machines of the underlying NSIS protocols and are not expected =20 > to re-define or extend these. Note that a QOSM can however,=20 > extend the RMF triggers to/from the QOS-NSLP functionality, which=20 > might affect the QoS-NSLP state machine. The 2 sentences are diametrically opposite. In the conference call most agreed that the QoS-NSLP state machine should *not* be dependent on which QOSM is in use by the RMF (as detailed in Cornelia's slide 2, last bullet, in the post I sent out in http://www1.ietf.org/mail-archive/web/nsis/current/msg07561.html). =20 See also Martin's notes on the QSPEC conference call http://www1.ietf.org/mail-archive/web/nsis/current/msg07548.html. There it says that we agreed that text is required in the QoS NSLP about the relationship between the QoS NSLP and the RMF, i.e., how can the RMF trigger actions of the QoS NSLP. That is what was 'decided' regarding clarifying text related to the QoS NSLP state machine. Jerry >=20 > Maybe the last sentence is not exactly the same as the words that=20 > I have proposed during the meeting, but the semantics are. >=20 >=20 > Best regards, > Georgios >=20 > > -----Original Message----- > > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com]=20 > > Sent: vrijdag 2 februari 2007 22:47 > > To: Hannes.Tschofenig@gmx.net; cornelia.kappler@siemens.com > > Cc: stiemerling@netlab.nec.de; karagian@cs.utwente.nl; nsis@ietf.org > > Subject: RE: State Machines .... was [NSIS] Summary of QSPEC call > >=20 > > Hannes, > >=20 > > The issue is that if any QoSM deviates (for example having=20 > > some signaling optimizations within the QoSM) from the=20 > > defined QoS NSLP State Machine, then those MUST be optional,=20 > > and the QoSM needs to describe how the QoSM falls back to the=20 > > standard State Machine. If the QOSM has a different state=20 > > machine, then that QoSM MUST be a Standards Track document=20 > > that extends the QoS NSLP. > >=20 > > All QoSM must be able to handle 'standard' QoS NSLP messaging=20 > > flows. If they modify (or introduce) new messaging flows,=20 > > these flows should be optimizations (which are optional) and=20 > > need to discuss how to fall back to standard messaging sequences. > >=20 > > I believe we discussed this on the call and people seemed to agree. > >=20 > > John > >=20 > > >-----Original Message----- > > >From: ext Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > > >Sent: 02 February, 2007 08:26 > > >To: Kappler, Cornelia > > >Cc: Martin Stiemerling; Georgios Karagiannis; nsis > > >Subject: State Machines .... was [NSIS] Summary of QSPEC call > > > > > >Hi all, > > > > > >let me repeat again what I said during the phone conference call. > > > > > >The QoS NSLP implicitly contains a state machine and an explicit=20 > > >description of the QoS NSLP state machine can be found in: > > >http://tools.ietf.org/wg/nsis/draft-fu-nsis-qos-nslp-statemachi > > >ne-05.txt > > >http://www.ietf.org/internet-drafts/draft-fu-nsis-qos-nslp-stat > > >emachine-05.pdf > > > > > >The QoS NSLP alone is not useful. In order todo something=20 > > >it needs to > > >(a) carry some QoS parameters with the corresponding=20 > > >meaning and (b)=20 > > >the state transitions need to be triggered. These triggers=20 > > >might come=20 > > >from various sources. Some of the triggers have been=20 > > >discussed in the=20 > > >context of RMD when an edge node of an RMD domain receives an=20 > > >end-to-end signaling message. Some actions might have to be taken=20 > > >within the RMD domain based on this incoming message. The type of=20 > > >message, the content of the QoS parameters, security=20 > > >parameters, the=20 > > >reservation state within the RMD domain, etc. influence=20 > > >the decision=20 > > >making process. > > > > > >The QoSM has its own state machine and it interacts with the=20 > > QoS NSLP=20 > > >whereby these actions have to fit to the QoS NSLP state=20 > > >machine but=20 > > >there is a lot of freedom since the QoS NSLP just defines=20 > > basic message=20 > > >patterns. > > > > > >Hence, when someone says that the QoSM MUST NOT modify the=20 > > >QoS NSLP=20 > > >state machine it would be good to be very explicit what that=20 > > actually=20 > > >means. > > > > > >This procdure of interworking between different state machines at=20 > > >different components is nothing new. Diameter (RFC 3588 and the > > >applications) and EAP - EAP methods do the same. > > > > > >Ciao > > >Hannes _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Feb 05 12:18:52 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HE7Tj-0000PO-Ec; Mon, 05 Feb 2007 12:18:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HE7Ti-0000PF-SY for nsis@ietf.org; Mon, 05 Feb 2007 12:18:06 -0500 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HE7Th-0004TC-EA for nsis@ietf.org; Mon, 05 Feb 2007 12:18:06 -0500 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l15HEfdZ008302; Mon, 5 Feb 2007 19:14:52 +0200 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Feb 2007 19:16:37 +0200 Received: from daebe103.NOE.Nokia.com ([10.241.35.24]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Feb 2007 11:16:35 -0600 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: State Machines .... was [NSIS] Summary of QSPEC call Date: Mon, 5 Feb 2007 11:16:34 -0600 Message-ID: <071568CA7B789D4AA170CEF8C9613B4F20BA8A@daebe103.NOE.Nokia.com> In-Reply-To: <002f01c7490d$8c2e8550$4c0d5982@dynamic.ewi.utwente.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: State Machines .... was [NSIS] Summary of QSPEC call Thread-Index: AcdG52ID3k5BeYFGQcSKMpuMyZMTRwAECO3QAAm62HAAAztwsAB4XniQAA7xJLA= References: <9473683187ADC049A855ED2DA739ABCA0DDC818B@KCCLUST06EVS1.ugd.att.com><9473683187ADC049A855ED2DA739ABCA0DDC818C@KCCLUST06EVS1.ugd.att.com> <002f01c7490d$8c2e8550$4c0d5982@dynamic.ewi.utwente.nl> From: To: , , , X-OriginalArrivalTime: 05 Feb 2007 17:16:35.0695 (UTC) FILETIME=[63AB27F0:01C74949] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Georgios, >Please note that any QOSM describes the functionality of RMF,=20 >thus it uses a different QOSM state machine that is different=20 >than the QoS-NSLP state machine.=20 I disagree. All QoSM need to use the state machine as defined in the QoS NSLP. If a QoSM changes the state machine of the QoS NSLP, then it must do so via a Standards Track RFC which extends the QoS NLSP. The RMF will have its own state machine, based upon which QoSM it is using, but the RMF functionality should be defined upon in the QoSM which is specifying it. Overall, QoSM are not assumed to change the General Processing rules as defined in section 5.2. If it does, then the QoSM is extending the QoS NSLP. =20 John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Feb 06 04:11:10 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEMLK-0000bE-R7; Tue, 06 Feb 2007 04:10:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEMLJ-0000b7-SI for nsis@ietf.org; Tue, 06 Feb 2007 04:10:25 -0500 Received: from goliath.siemens.de ([192.35.17.28]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HEMLF-0001mM-AQ for nsis@ietf.org; Tue, 06 Feb 2007 04:10:25 -0500 Received: from mail2.siemens.de (localhost [127.0.0.1]) by goliath.siemens.de (8.12.6/8.12.6) with ESMTP id l169AHMb018322; Tue, 6 Feb 2007 10:10:18 +0100 Received: from mchp771a.ww002.siemens.net (mchp771a.ww002.siemens.net [139.25.131.189]) by mail2.siemens.de (8.12.6/8.12.6) with ESMTP id l169AHYq004278; Tue, 6 Feb 2007 10:10:17 +0100 Received: from MCHP7R6A.ww002.siemens.net ([139.25.131.164]) by mchp771a.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 6 Feb 2007 10:10:17 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: AW: State Machines .... was [NSIS] Summary of QSPEC call Date: Tue, 6 Feb 2007 10:10:16 +0100 Message-ID: <8F6CBC7005099442AECDB784C9E9D7E70177B4F8@MCHP7R6A.ww002.siemens.net> In-Reply-To: <071568CA7B789D4AA170CEF8C9613B4F20BA8A@daebe103.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: State Machines .... was [NSIS] Summary of QSPEC call Thread-Index: AcdG52ID3k5BeYFGQcSKMpuMyZMTRwAECO3QAAm62HAAAztwsAB4XniQAA7xJLAAIMYqEA== From: "Tschofenig, Hannes" To: , , , , X-OriginalArrivalTime: 06 Feb 2007 09:10:17.0293 (UTC) FILETIME=[9E6617D0:01C749CE] X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi John,=20 I think Georgios is saying that the state machine of the QoS NSLP and = the QoSM are different but they need to work together.=20 Let me compare this with EAP and EAP methods: EAP has a state machine and the same is true for EAP methods. RFC 4137 = even describes the EAP state machine. Both, the EAP and the EAP method state machine, need to work together = and the EAP method state machine cannot trigger messages that are not = allowed in the EAP state machine. For example, an EAP method cannot force an EAP peer to send a = EAP-Failure towards the EAP server since the EAP state machine only = allows the message to be sent from the EAP server to the EAP client.=20 Ciao Hannes > -----Urspr=FCngliche Nachricht----- > Von: john.loughney@nokia.com [mailto:john.loughney@nokia.com]=20 > Gesendet: Montag, 5. Februar 2007 18:17 > An: karagian@cs.utwente.nl; gash@att.com;=20 > Hannes.Tschofenig@gmx.net; nsis@ietf.org > Betreff: RE: State Machines .... was [NSIS] Summary of QSPEC call >=20 > Georgios, >=20 > >Please note that any QOSM describes the functionality of RMF,=20 > >thus it uses a different QOSM state machine that is different=20 > >than the QoS-NSLP state machine.=20 >=20 > I disagree. All QoSM need to use the state machine as defined in > the QoS NSLP. If a QoSM changes the state machine of the QoS NSLP, > then it must do so via a Standards Track RFC which extends the > QoS NLSP. >=20 > The RMF will have its own state machine, based upon which QoSM it > is using, but the RMF functionality should be defined upon in the > QoSM which is specifying it. >=20 > Overall, QoSM are not assumed to change the General Processing rules > as defined in section 5.2. If it does, then the QoSM is extending > the QoS NSLP. =20 >=20 > John >=20 > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Feb 06 04:19:27 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEMTP-0004gs-EI; Tue, 06 Feb 2007 04:18:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEMTO-0004gn-Tp for nsis@ietf.org; Tue, 06 Feb 2007 04:18:46 -0500 Received: from rotterdam.ewi.utwente.nl ([130.89.10.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HEMTM-0004U7-69 for nsis@ietf.org; Tue, 06 Feb 2007 04:18:46 -0500 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by rotterdam.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id l169I6mS009920; Tue, 6 Feb 2007 10:18:17 +0100 (MET) From: "Georgios Karagiannis" To: , , , References: <9473683187ADC049A855ED2DA739ABCA0DDC818B@KCCLUST06EVS1.ugd.att.com><9473683187ADC049A855ED2DA739ABCA0DDC818C@KCCLUST06EVS1.ugd.att.com> <002f01c7490d$8c2e8550$4c0d5982@dynamic.ewi.utwente.nl> <071568CA7B789D4AA170CEF8C9613B4F20BA8A@daebe103.NOE.Nokia.com> Subject: RE: State Machines .... was [NSIS] Summary of QSPEC call Date: Tue, 6 Feb 2007 10:18:24 +0100 Message-ID: <000001c749cf$c4e37f50$4c0d5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcdG52ID3k5BeYFGQcSKMpuMyZMTRwAECO3QAAm62HAAAztwsAB4XniQAA7xJLAAIPgqIA== In-Reply-To: <071568CA7B789D4AA170CEF8C9613B4F20BA8A@daebe103.NOE.Nokia.com> X-Spam-Score: 1.4 (*) FVGT_s_MIXCASEWORDS,FVGT_s_OBFU_ODD06,FVGT_s_OBFU_Q1 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (rotterdam.ewi.utwente.nl [130.89.10.5]); Tue, 06 Feb 2007 10:18:18 +0100 (MET) X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi John > [Georgios] Please note that any QOSM describes the functionality of > RMF, thus it > >uses a different QOSM state machine that is different than > the QoS-NSLP > >state machine. > > [John] I disagree. All QoSM need to use the state machine as > defined in the QoS NSLP. If a QoSM changes the state machine > of the QoS NSLP, then it must do so via a Standards Track RFC > which extends the QoS NLSP. Do you agree that the QOSM and the QOS-NSLP are supporting two different functionalities. Thus the QOSM has its own state machine and the QOS-NSLP has its own state machine. Have we followed a different telephone conference meeting? During the telephone conference meeting we have agreed that the RMF triggers can change the reaction of the QOS-NSLP. We have also agreed that QOSMs all utilize the state machines of the underlying NSIS protocols and are not expected to re-define or extend these. Note that a QOSM can however, extend the RMF triggers to/from the QOS-NSLP functionality, which might affect the QoS-NSLP state machine. Maybe the last sentence is not exactly the same as the words that I have proposed during the meeting, but the semantics are. > [John] Overall, QoSM are not assumed to change the General > Processing rules as defined in section 5.2. If it does, then > the QoSM is extending the QoS NSLP. Now regarding the above, I agree, but I think that this is something different than saying that the QOS-NSLP state machine should not be changed. Please note that the unidirectional/bidirectional and sender/receiver reservation intiation, refresh, tear, modification of the following scenarios are not described in the QOS-NSLP: bound and parallel end-to-end and end-to-end sessions bound and parallel end-to-end and edge-to-edge sessions bound and parallel end-to-end and end-to-edge sessions * Examples of QOSMs that support end-to-end sessions can be: Intserv like Controlled Load QOSM Intserv like Guaranteed Service QOSM * Examples of QOSMs that can support edge-to-edge sessions can be: RSVP aggregation like QOSM RMD-QOSM interdomain and intra-domain ITU-T RACF QoS model PCN like congestion notifictaion and preemption QoS model. RSVP-TE like QOSM * Examples of QOSMs that can support end-to-edge sessions: IEEE 802.16 The reason of this is that the QOS-NSLP does not go into lot of details with any local node dependent functions, including QOSM functionality, security and AAA interactions. Best regards, Georgios > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > Sent: maandag 5 februari 2007 18:17 > To: karagian@cs.utwente.nl; gash@att.com; > Hannes.Tschofenig@gmx.net; nsis@ietf.org > Subject: RE: State Machines .... was [NSIS] Summary of QSPEC call > > Georgios, > > >Please note that any QOSM describes the functionality of > RMF, thus it > >uses a different QOSM state machine that is different than > the QoS-NSLP > >state machine. > > I disagree. All QoSM need to use the state machine as > defined in the QoS NSLP. If a QoSM changes the state machine > of the QoS NSLP, then it must do so via a Standards Track RFC > which extends the QoS NLSP. > > The RMF will have its own state machine, based upon which > QoSM it is using, but the RMF functionality should be defined > upon in the QoSM which is specifying it. > > Overall, QoSM are not assumed to change the General > Processing rules as defined in section 5.2. If it does, then > the QoSM is extending the QoS NSLP. > > John > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Feb 06 04:57:15 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEN3m-0005At-4L; Tue, 06 Feb 2007 04:56:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEN3k-00055q-VJ for nsis@ietf.org; Tue, 06 Feb 2007 04:56:20 -0500 Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HEN3h-00044W-EQ for nsis@ietf.org; Tue, 06 Feb 2007 04:56:20 -0500 Received: from [141.3.70.5] (helo=smtp.ipv6.tm.uni-karlsruhe.de) by iramx2.ira.uni-karlsruhe.de with esmtps id 1HEN3e-0001KF-QA; Tue, 06 Feb 2007 10:56:16 +0100 Received: from vorta.ipv6.tm.uni-karlsruhe.de (vorta.ipv6.tm.uni-karlsruhe.de [IPv6:2001:638:204:6:207:e9ff:fe0c:5e44]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id A09D0676C6; Tue, 6 Feb 2007 10:56:14 +0100 (CET) Received: from localhost ([127.0.0.1]) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.44) id 1HEN3e-0000Dd-AN; Tue, 06 Feb 2007 10:56:14 +0100 Message-ID: <45C850BD.4060401@tm.uka.de> Date: Tue, 06 Feb 2007 10:56:13 +0100 From: Roland Bless Organization: Institute of Telematics, University of Karlsruhe User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060111 Thunderbird/1.5 Mnenhy/0.7.3.0 MIME-Version: 1.0 To: David Palma Subject: Re: [NSIS] NSLP AUTH Questions References: <200702022240.l12MeHob006378@smtp2.dei.uc.pt> In-Reply-To: <200702022240.l12MeHob006378@smtp2.dei.uc.pt> X-Enigmail-Version: 0.94.1.1 Content-Type: text/plain; charset=windows-1250 Content-Transfer-Encoding: 7bit X-Spam-Status: No X-Spam-Score: -2.6 (--) X-Spam-Report: -1.4 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.2 AWL AWL: From: address is in the auto white-list X-ATIS-Checksum: v3zoCAcc32ckk X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: giuseppe.martufi@datamat.it, nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi David, David Palma wrote: > Regarding the AUTH draft I have some questions about the parsing of the > proposed objects. Is this parsing done inside QoS NSLP or, like QSPEC with > RMF, done in an Authorization model? Are the AUTH objects opaque like the > QSPEC? Yes and no. We've considered the AUTH session object lately for its use in NAT/FW traversal. What you want to do is basically the following: - When a message arrives that contains an AUTH_Session object you want to verify the MAC in the AUTHENTICATION_DATA of the AUTH_Session object. This can be done separately and you want to use the same code in NAT/FW or QoS NSLP applications for that (i.e., this may happen outside the QoS NSLP code) - After verifying the integrity of the AUTH_SESSION object you should compare some of the Session authorization attributes with other parts of the QoS NSLP message so that the AUTH_SESSION object is related to the actual QoS NSLP message. This will usually happen in the QoS NSLP code. - In case that any verification above fails, QoS NSLP should simply discard the message and not process it any further. > Another question is concerns the length of the Authorizing Entity Identifier > (page 9) object, where it says: "...Length of the attribute, which MUST be > > 4". If the octet string could be an IPv4 address, shouldn't we read "...MUST > be >= 4"? At beginning of sec. 3.2 (p. 7) the Length description says that it includes all octects of the attribute (except padding bytes), and the attribute header is already 4 octets long. If it contains an IPv4 address, it should be set to 8. > Another issue is on the length of Source Address object, where the octet > string could be a 16 bit port and consequently the length should be >= 2. Length is always >= 4 since it also includes the attribute header. For a port number the attribute length should be set to 6. > Can anybody help me with these questions? Hope it helped. Roland _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Feb 06 08:56:22 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEQnL-0003lw-2I; Tue, 06 Feb 2007 08:55:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEQnJ-0003kw-5s for nsis@ietf.org; Tue, 06 Feb 2007 08:55:37 -0500 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HEQn9-00030B-Jm for nsis@ietf.org; Tue, 06 Feb 2007 08:55:37 -0500 Received: from [10.1.1.109] (mito.netlab.nec.de [195.37.70.39]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 0790E13CF86 for ; Tue, 6 Feb 2007 14:56:18 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: <787619A9-74F7-4154-A617-4F829AF92780@netlab.nec.de> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: nsis From: Martin Stiemerling Date: Tue, 6 Feb 2007 14:55:24 +0100 X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Subject: [NSIS] QSPEC2: State machine text part in QSPEC I-D X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Well, I have not yet seen consensus about this issue. Georgios proposed this text: "QOSMs all utilize the state machines of the underlying NSIS protocols and are not expected to re-define or extend these in any way. Note that a QOSM can however, extend the RMF triggers to/from the QOS-NSLP functionality, which might affect the QoS-NSLP state machine." I personally also see that sentence 1 and 2 are contradicting each other at least partially. The first sentence is not allowing to extend the state machinery of the underlying NSIS protocols, where the second sentence is is opening the door for extending it. However, I don't see any real technical issue here, but more a wording issue. I'm not a good wording expert here, but the base lines seems to be: 1) QOSMs cannot change the semantics (and thus state machine) of the underlying QoS NSLP and GIST. (A standards track document is required for doing so). 2) QOSMs can send triggers to the QoS NSLP. These trigger can cause the QoS NSLP to run its semantics. Basically the " affect the QoS- NSLP state machine." is not very clear to readers. Yes, it affects the state machine, but only by giving a reason for an initial state transition (e.g., send RESERVE). So, I'm now waiting for the big, loud scream of what is wrong here. :-) Martin stiemerling@netlab.nec.de NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Feb 06 08:56:22 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEQnE-0003k4-RV; Tue, 06 Feb 2007 08:55:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEQnD-0003js-Ax for nsis@ietf.org; Tue, 06 Feb 2007 08:55:31 -0500 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HEQn4-0002vF-PH for nsis@ietf.org; Tue, 06 Feb 2007 08:55:31 -0500 Received: from [10.1.1.109] (mito.netlab.nec.de [195.37.70.39]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 2421513CF82 for ; Tue, 6 Feb 2007 14:56:13 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: <51FAE421-FA23-44E9-B990-D4C9A1C8BA78@netlab.nec.de> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: nsis From: Martin Stiemerling Date: Tue, 6 Feb 2007 14:55:21 +0100 X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Subject: [NSIS] QSPEC1: Relationship between the QoS NSLP and the RMF X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Dear all, I'm going to send some emails about QSPEC issues that have or have not reached consensus. I believe we have reached consensus for this item QSPEC1. If not, please object now. - There is text required in the QoS NSLP about the relationship between the QoS NSLP and the RMF, i.e., how can the RMF trigger actions of the QoS NSLP. For instance, that the RMF can trigger a RESERVE. Martin stiemerling@netlab.nec.de NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Feb 06 08:56:22 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEQnL-0003lw-2I; Tue, 06 Feb 2007 08:55:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEQnJ-0003kw-5s for nsis@ietf.org; Tue, 06 Feb 2007 08:55:37 -0500 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HEQn9-00030B-Jm for nsis@ietf.org; Tue, 06 Feb 2007 08:55:37 -0500 Received: from [10.1.1.109] (mito.netlab.nec.de [195.37.70.39]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 0790E13CF86 for ; Tue, 6 Feb 2007 14:56:18 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: <787619A9-74F7-4154-A617-4F829AF92780@netlab.nec.de> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: nsis From: Martin Stiemerling Date: Tue, 6 Feb 2007 14:55:24 +0100 X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Subject: [NSIS] QSPEC2: State machine text part in QSPEC I-D X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Well, I have not yet seen consensus about this issue. Georgios proposed this text: "QOSMs all utilize the state machines of the underlying NSIS protocols and are not expected to re-define or extend these in any way. Note that a QOSM can however, extend the RMF triggers to/from the QOS-NSLP functionality, which might affect the QoS-NSLP state machine." I personally also see that sentence 1 and 2 are contradicting each other at least partially. The first sentence is not allowing to extend the state machinery of the underlying NSIS protocols, where the second sentence is is opening the door for extending it. However, I don't see any real technical issue here, but more a wording issue. I'm not a good wording expert here, but the base lines seems to be: 1) QOSMs cannot change the semantics (and thus state machine) of the underlying QoS NSLP and GIST. (A standards track document is required for doing so). 2) QOSMs can send triggers to the QoS NSLP. These trigger can cause the QoS NSLP to run its semantics. Basically the " affect the QoS- NSLP state machine." is not very clear to readers. Yes, it affects the state machine, but only by giving a reason for an initial state transition (e.g., send RESERVE). So, I'm now waiting for the big, loud scream of what is wrong here. :-) Martin stiemerling@netlab.nec.de NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Feb 06 08:56:22 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEQnE-0003k4-RV; Tue, 06 Feb 2007 08:55:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEQnD-0003js-Ax for nsis@ietf.org; Tue, 06 Feb 2007 08:55:31 -0500 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HEQn4-0002vF-PH for nsis@ietf.org; Tue, 06 Feb 2007 08:55:31 -0500 Received: from [10.1.1.109] (mito.netlab.nec.de [195.37.70.39]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 2421513CF82 for ; Tue, 6 Feb 2007 14:56:13 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: <51FAE421-FA23-44E9-B990-D4C9A1C8BA78@netlab.nec.de> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: nsis From: Martin Stiemerling Date: Tue, 6 Feb 2007 14:55:21 +0100 X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Subject: [NSIS] QSPEC1: Relationship between the QoS NSLP and the RMF X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Dear all, I'm going to send some emails about QSPEC issues that have or have not reached consensus. I believe we have reached consensus for this item QSPEC1. If not, please object now. - There is text required in the QoS NSLP about the relationship between the QoS NSLP and the RMF, i.e., how can the RMF trigger actions of the QoS NSLP. For instance, that the RMF can trigger a RESERVE. Martin stiemerling@netlab.nec.de NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Feb 06 08:56:27 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEQnR-0003mm-9L; Tue, 06 Feb 2007 08:55:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEQnQ-0003mf-SB for nsis@ietf.org; Tue, 06 Feb 2007 08:55:44 -0500 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HEQnG-00035v-0w for nsis@ietf.org; Tue, 06 Feb 2007 08:55:44 -0500 Received: from [10.1.1.109] (mito.netlab.nec.de [195.37.70.39]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 72DDD13CF82 for ; Tue, 6 Feb 2007 14:56:24 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: <232F0B56-161A-4AFD-91BC-F8BAA0463F33@netlab.nec.de> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: nsis From: Martin Stiemerling Date: Tue, 6 Feb 2007 14:55:33 +0100 X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Subject: [NSIS] QSPEC3: Information API in QoS NSLP X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org I believe we have reached consensus for this item QSPEC3. If not, please object now. - The QoS NSLP draft needs an informational section describing the API between QSPEC and QoS NSLP. This informational section should be in the spirit of the API description in GIST, i.e., giving guidance to implementers. Martin stiemerling@netlab.nec.de NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Feb 06 09:35:12 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEROt-00062j-8Y; Tue, 06 Feb 2007 09:34:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEROs-00062c-9B for nsis@ietf.org; Tue, 06 Feb 2007 09:34:26 -0500 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HEROq-0005wF-OA for nsis@ietf.org; Tue, 06 Feb 2007 09:34:26 -0500 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l16EVXAa002561; Tue, 6 Feb 2007 16:31:52 +0200 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 6 Feb 2007 16:34:01 +0200 Received: from daebe103.NOE.Nokia.com ([10.241.35.24]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 6 Feb 2007 08:33:33 -0600 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: State Machines .... was [NSIS] Summary of QSPEC call Date: Tue, 6 Feb 2007 08:33:32 -0600 Message-ID: <071568CA7B789D4AA170CEF8C9613B4F246FE0@daebe103.NOE.Nokia.com> In-Reply-To: <8F6CBC7005099442AECDB784C9E9D7E70177B4F8@MCHP7R6A.ww002.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: State Machines .... was [NSIS] Summary of QSPEC call Thread-Index: AcdG52ID3k5BeYFGQcSKMpuMyZMTRwAECO3QAAm62HAAAztwsAB4XniQAA7xJLAAIMYqEAAL9W7A References: <071568CA7B789D4AA170CEF8C9613B4F20BA8A@daebe103.NOE.Nokia.com> <8F6CBC7005099442AECDB784C9E9D7E70177B4F8@MCHP7R6A.ww002.siemens.net> From: To: , , , , X-OriginalArrivalTime: 06 Feb 2007 14:33:33.0648 (UTC) FILETIME=[C786FD00:01C749FB] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org I agree that the RMD & QoS NSLP are different. I agree they need to work together, but the QoS NSLP should not be changed/modified by the QoS model, otherwise it is extending/modifying the behavior of the QoS NSLP: John >-----Original Message----- >From: ext Tschofenig, Hannes [mailto:hannes.tschofenig@siemens.com]=20 >Sent: 06 February, 2007 01:10 >To: Loughney John (Nokia-NRC/PaloAlto);=20 >karagian@cs.utwente.nl; gash@att.com;=20 >Hannes.Tschofenig@gmx.net; nsis@ietf.org >Subject: AW: State Machines .... was [NSIS] Summary of QSPEC call > >Hi John,=20 > >I think Georgios is saying that the state machine of the QoS=20 >NSLP and the QoSM are different but they need to work together.=20 > >Let me compare this with EAP and EAP methods: > >EAP has a state machine and the same is true for EAP methods.=20 >RFC 4137 even describes the EAP state machine. >Both, the EAP and the EAP method state machine, need to work=20 >together and the EAP method state machine cannot trigger=20 >messages that are not allowed in the EAP state machine. > >For example, an EAP method cannot force an EAP peer to send a=20 >EAP-Failure towards the EAP server since the EAP state machine=20 >only allows the message to be sent from the EAP server to the=20 >EAP client.=20 > >Ciao >Hannes > >> -----Urspr=FCngliche Nachricht----- >> Von: john.loughney@nokia.com [mailto:john.loughney@nokia.com] >> Gesendet: Montag, 5. Februar 2007 18:17 >> An: karagian@cs.utwente.nl; gash@att.com; Hannes.Tschofenig@gmx.net;=20 >> nsis@ietf.org >> Betreff: RE: State Machines .... was [NSIS] Summary of QSPEC call >>=20 >> Georgios, >>=20 >> >Please note that any QOSM describes the functionality of=20 >RMF, thus it=20 >> >uses a different QOSM state machine that is different than the=20 >> >QoS-NSLP state machine. >>=20 >> I disagree. All QoSM need to use the state machine as=20 >defined in the=20 >> QoS NSLP. If a QoSM changes the state machine of the QoS NSLP, then=20 >> it must do so via a Standards Track RFC which extends the QoS NLSP. >>=20 >> The RMF will have its own state machine, based upon which QoSM it is=20 >> using, but the RMF functionality should be defined upon in the QoSM=20 >> which is specifying it. >>=20 >> Overall, QoSM are not assumed to change the General Processing rules=20 >> as defined in section 5.2. If it does, then the QoSM is=20 >extending the=20 >> QoS NSLP. >>=20 >> John >>=20 >> _______________________________________________ >> nsis mailing list >> nsis@ietf.org >> https://www1.ietf.org/mailman/listinfo/nsis >>=20 > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Feb 06 09:39:53 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HERTZ-000808-Ih; Tue, 06 Feb 2007 09:39:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HERTY-0007y2-T6 for nsis@ietf.org; Tue, 06 Feb 2007 09:39:17 -0500 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HERTX-0007HU-EQ for nsis@ietf.org; Tue, 06 Feb 2007 09:39:16 -0500 Received: (qmail invoked by alias); 06 Feb 2007 14:39:14 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp032) with SMTP; 06 Feb 2007 15:39:14 +0100 X-Authenticated: #29516787 Message-ID: <45C89311.4000102@gmx.net> Date: Tue, 06 Feb 2007 15:39:13 +0100 From: Hannes Tschofenig User-Agent: Thunderbird 2.0b2 (Windows/20070116) MIME-Version: 1.0 To: john.loughney@nokia.com Subject: Re: State Machines .... was [NSIS] Summary of QSPEC call References: <071568CA7B789D4AA170CEF8C9613B4F20BA8A@daebe103.NOE.Nokia.com> <8F6CBC7005099442AECDB784C9E9D7E70177B4F8@MCHP7R6A.ww002.siemens.net> <071568CA7B789D4AA170CEF8C9613B4F246FE0@daebe103.NOE.Nokia.com> In-Reply-To: <071568CA7B789D4AA170CEF8C9613B4F246FE0@daebe103.NOE.Nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: gash@att.com, karagian@cs.utwente.nl, nsis@ietf.org, hannes.tschofenig@siemens.com X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi John, john.loughney@nokia.com wrote: > I agree that the RMD & QoS NSLP are different. I agree they need > to work together, but the QoS NSLP should not be changed/modified > by the QoS model, otherwise it is extending/modifying the behavior of > the QoS NSLP: > > That's also my thinking. During the phone conference I recall that Cornelia mentioned that she found something in the RMD specification that extended or modified the behavior of the QoS NSLP state machine. Maybe she could elaborate a bit about this issue. Ciao Hannes > John > > >> -----Original Message----- >> From: ext Tschofenig, Hannes [mailto:hannes.tschofenig@siemens.com] >> Sent: 06 February, 2007 01:10 >> To: Loughney John (Nokia-NRC/PaloAlto); >> karagian@cs.utwente.nl; gash@att.com; >> Hannes.Tschofenig@gmx.net; nsis@ietf.org >> Subject: AW: State Machines .... was [NSIS] Summary of QSPEC call >> >> Hi John, >> >> I think Georgios is saying that the state machine of the QoS >> NSLP and the QoSM are different but they need to work together. >> >> Let me compare this with EAP and EAP methods: >> >> EAP has a state machine and the same is true for EAP methods. >> RFC 4137 even describes the EAP state machine. >> Both, the EAP and the EAP method state machine, need to work >> together and the EAP method state machine cannot trigger >> messages that are not allowed in the EAP state machine. >> >> For example, an EAP method cannot force an EAP peer to send a >> EAP-Failure towards the EAP server since the EAP state machine >> only allows the message to be sent from the EAP server to the >> EAP client. >> >> Ciao >> Hannes >> >> >>> -----Ursprüngliche Nachricht----- >>> Von: john.loughney@nokia.com [mailto:john.loughney@nokia.com] >>> Gesendet: Montag, 5. Februar 2007 18:17 >>> An: karagian@cs.utwente.nl; gash@att.com; Hannes.Tschofenig@gmx.net; >>> nsis@ietf.org >>> Betreff: RE: State Machines .... was [NSIS] Summary of QSPEC call >>> >>> Georgios, >>> >>> >>>> Please note that any QOSM describes the functionality of >>>> >> RMF, thus it >> >>>> uses a different QOSM state machine that is different than the >>>> QoS-NSLP state machine. >>>> >>> I disagree. All QoSM need to use the state machine as >>> >> defined in the >> >>> QoS NSLP. If a QoSM changes the state machine of the QoS NSLP, then >>> it must do so via a Standards Track RFC which extends the QoS NLSP. >>> >>> The RMF will have its own state machine, based upon which QoSM it is >>> using, but the RMF functionality should be defined upon in the QoSM >>> which is specifying it. >>> >>> Overall, QoSM are not assumed to change the General Processing rules >>> as defined in section 5.2. If it does, then the QoSM is >>> >> extending the >> >>> QoS NSLP. >>> >>> John >>> >>> _______________________________________________ >>> nsis mailing list >>> nsis@ietf.org >>> https://www1.ietf.org/mailman/listinfo/nsis >>> >>> _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Feb 06 09:41:28 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HERV6-0000W7-3H; Tue, 06 Feb 2007 09:40:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HERV4-0000Qo-1J for nsis@ietf.org; Tue, 06 Feb 2007 09:40:50 -0500 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HERV2-0007ac-6j for nsis@ietf.org; Tue, 06 Feb 2007 09:40:50 -0500 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l16Ec5Bi005800; Tue, 6 Feb 2007 16:38:29 +0200 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 6 Feb 2007 16:40:38 +0200 Received: from daebe103.NOE.Nokia.com ([10.241.35.24]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 6 Feb 2007 08:40:02 -0600 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: State Machines .... was [NSIS] Summary of QSPEC call Date: Tue, 6 Feb 2007 08:40:00 -0600 Message-ID: <071568CA7B789D4AA170CEF8C9613B4F246FF3@daebe103.NOE.Nokia.com> In-Reply-To: <000001c749cf$c4e37f50$4c0d5982@dynamic.ewi.utwente.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: State Machines .... was [NSIS] Summary of QSPEC call Thread-Index: AcdG52ID3k5BeYFGQcSKMpuMyZMTRwAECO3QAAm62HAAAztwsAB4XniQAA7xJLAAIPgqIAAL1Gdg References: <9473683187ADC049A855ED2DA739ABCA0DDC818B@KCCLUST06EVS1.ugd.att.com><9473683187ADC049A855ED2DA739ABCA0DDC818C@KCCLUST06EVS1.ugd.att.com> <002f01c7490d$8c2e8550$4c0d5982@dynamic.ewi.utwente.nl> <071568CA7B789D4AA170CEF8C9613B4F20BA8A@daebe103.NOE.Nokia.com> <000001c749cf$c4e37f50$4c0d5982@dynamic.ewi.utwente.nl> From: To: , , , X-OriginalArrivalTime: 06 Feb 2007 14:40:02.0284 (UTC) FILETIME=[AF2C22C0:01C749FC] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Georgios, >>=20 >> [John] I disagree. All QoSM need to use the state machine as defined >> in the QoS NSLP. If a QoSM changes the state machine of the QoS NSLP,=20 >> then it must do so via a Standards Track RFC which extends the QoS=20 >> NLSP. > >Do you agree that the QOSM and the QOS-NSLP are supporting two=20 >different functionalities. >Thus the QOSM has its own state machine and the QOS-NSLP has=20 >its own state machine. Exactly. That is what we are talking about. The RMF can have its own state machine, and that can vary from QoSM to QoSM model. The paragraph above is only refering to the QoS NSLP state machine, it is not talking about the RMF state machine at all. The RMF state machine can be defined in the QoSM, not the NSLP. >> [John] Overall, QoSM are not assumed to change the General Processing >> rules as defined in section 5.2. If it does, then the QoSM is=20 >> extending the QoS NSLP. > >Now regarding the above, I agree, but I think that this is=20 >something different than saying that the QOS-NSLP state=20 >machine should not be changed. What exactly do you want? I am not understanding what point you are trying to make.=20 >Please note that the unidirectional/bidirectional and sender/receiver=20 >reservation intiation, refresh, tear, modification of the following=20 >scenarios are not described in the QOS-NSLP: >bound and parallel end-to-end and end-to-end sessions >bound and parallel end-to-end and edge-to-edge sessions >bound and parallel end-to-end and end-to-edge sessions > >* Examples of QOSMs that support end-to-end sessions can be: >Intserv like Controlled Load QOSM >Intserv like Guaranteed Service QOSM > >* Examples of QOSMs that can support edge-to-edge sessions can be: >RSVP aggregation like QOSM RMD-QOSM >interdomain and intra-domain ITU-T RACF QoS model >PCN like congestion notifictaion and preemption QoS model. >RSVP-TE like QOSM > >* Examples of QOSMs that can support end-to-edge sessions: >IEEE 802.16 > >The reason of this is that the QOS-NSLP does not go into lot of details >with any local node dependent functions, including QOSM functionality,=20 >security and AAA interactions.=20 At the end of the day, a standard QoS NSLP node should be able to be re-used with any QoSM and work. If a QoSM makes special optimizations, then it needs to do 1 of 2 things: 1) Make the optimizations optional, and have a fallback to the standard message processing rules defined in the QoS NSLP. 2) The QoSM needs to make a QoS NSLP extension, which is a standards track document. I cannot see how we get any interoperability otherwise. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Feb 06 09:43:04 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HERWd-0000nY-SK; Tue, 06 Feb 2007 09:42:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HERWc-0000nI-S7 for nsis@ietf.org; Tue, 06 Feb 2007 09:42:26 -0500 Received: from rotterdam.ewi.utwente.nl ([130.89.10.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HERWb-00083Q-8G for nsis@ietf.org; Tue, 06 Feb 2007 09:42:26 -0500 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by rotterdam.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id l16EftOI024713; Tue, 6 Feb 2007 15:42:01 +0100 (MET) From: "Georgios Karagiannis" To: "'Martin Stiemerling'" , "'nsis'" References: <51FAE421-FA23-44E9-B990-D4C9A1C8BA78@netlab.nec.de> Subject: RE: [NSIS] QSPEC1: Relationship between the QoS NSLP and the RMF Date: Tue, 6 Feb 2007 15:42:12 +0100 Message-ID: <004501c749fc$ffe2fa40$4c0d5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcdJ9rKR7hwILyPHQF2xM2GQIxTf2gABf/lw In-Reply-To: <51FAE421-FA23-44E9-B990-D4C9A1C8BA78@netlab.nec.de> X-Spam-Score: 0.4 () FVGT_s_MIXCASEWORDS,FVGT_s_OBFU_Q1 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (rotterdam.ewi.utwente.nl [130.89.10.5]); Tue, 06 Feb 2007 15:42:02 +0100 (MET) X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Martin I agree, but these are internal triggers that should not limit the flexibility and extensibility of fhe QOS models. They can be used as guidelines for the QOSM designers. Best Regards, Georgios > -----Original Message----- > From: Martin Stiemerling [mailto:stiemerling@netlab.nec.de] > Sent: dinsdag 6 februari 2007 14:55 > To: nsis > Subject: [NSIS] QSPEC1: Relationship between the QoS NSLP and the RMF > > Dear all, > > I'm going to send some emails about QSPEC issues that have or > have not reached consensus. > > I believe we have reached consensus for this item QSPEC1. If > not, please object now. > > - There is text required in the QoS NSLP about the > relationship between the QoS NSLP and the RMF, i.e., how can > the RMF trigger actions of the QoS NSLP. For instance, that > the RMF can trigger a RESERVE. > > > > Martin > > > stiemerling@netlab.nec.de > NEC Europe Limited | > Registered Office: NEC House, 1 Victoria Road, London W3 6BL > | Registered in England 2832014 > > > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Feb 06 09:44:14 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HERXl-000195-K4; Tue, 06 Feb 2007 09:43:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HERXk-000190-Qd for nsis@ietf.org; Tue, 06 Feb 2007 09:43:36 -0500 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HERXj-0008AL-CP for nsis@ietf.org; Tue, 06 Feb 2007 09:43:36 -0500 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l16Edxti006102; Tue, 6 Feb 2007 16:40:18 +0200 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 6 Feb 2007 16:42:57 +0200 Received: from daebe103.NOE.Nokia.com ([10.241.35.24]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 6 Feb 2007 08:42:44 -0600 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: State Machines .... was [NSIS] Summary of QSPEC call Date: Tue, 6 Feb 2007 08:42:42 -0600 Message-ID: <071568CA7B789D4AA170CEF8C9613B4F247004@daebe103.NOE.Nokia.com> In-Reply-To: <45C89311.4000102@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: State Machines .... was [NSIS] Summary of QSPEC call Thread-Index: AcdJ/K/ThZwQED4sTL6SuSrLvyoYmQAADnug References: <071568CA7B789D4AA170CEF8C9613B4F20BA8A@daebe103.NOE.Nokia.com> <8F6CBC7005099442AECDB784C9E9D7E70177B4F8@MCHP7R6A.ww002.siemens.net> <071568CA7B789D4AA170CEF8C9613B4F246FE0@daebe103.NOE.Nokia.com> <45C89311.4000102@gmx.net> From: To: X-OriginalArrivalTime: 06 Feb 2007 14:42:44.0282 (UTC) FILETIME=[0FBB11A0:01C749FD] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: gash@att.com, karagian@cs.utwente.nl, nsis@ietf.org, hannes.tschofenig@siemens.com X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hannes, >> I agree that the RMD & QoS NSLP are different. I agree they need to=20 >> work together, but the QoS NSLP should not be changed/modified by the >> QoS model, otherwise it is extending/modifying the behavior of the QoS=20 >> NSLP: >> >> =20 >That's also my thinking. Good.=20 >During the phone conference I recall that Cornelia mentioned=20 >that she found something in the RMD specification that=20 >extended or modified the behavior of the QoS NSLP state=20 >machine. Maybe she could elaborate a bit about this issue. If it does, then it should also describe a fall back to 'standard behavior' as defined in the message processing rules defined in the QoS NLSP and everything would be OK. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Feb 06 09:48:33 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HERbi-0004EZ-QJ; Tue, 06 Feb 2007 09:47:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HERbh-0004Cz-RB for nsis@ietf.org; Tue, 06 Feb 2007 09:47:41 -0500 Received: from rotterdam.ewi.utwente.nl ([130.89.10.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HERbf-0000p8-Di for nsis@ietf.org; Tue, 06 Feb 2007 09:47:41 -0500 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by rotterdam.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id l16El7Bi024968; Tue, 6 Feb 2007 15:47:16 +0100 (MET) From: "Georgios Karagiannis" To: "'Martin Stiemerling'" , "'nsis'" References: <232F0B56-161A-4AFD-91BC-F8BAA0463F33@netlab.nec.de> Subject: RE: [NSIS] QSPEC3: Information API in QoS NSLP Date: Tue, 6 Feb 2007 15:47:24 +0100 Message-ID: <004601c749fd$ba21a870$4c0d5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcdJ9rKRmWYVorg5TXijH7UfOcIWDwABn0Iw In-Reply-To: <232F0B56-161A-4AFD-91BC-F8BAA0463F33@netlab.nec.de> X-Spam-Score: 0.3 () FVGT_s_OBFU_Q1 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (rotterdam.ewi.utwente.nl [130.89.10.5]); Tue, 06 Feb 2007 15:47:16 +0100 (MET) X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Martin I agree, but the RMF triggers are internal triggers betweeen QOSM and QOS-NSLP thus they can be considered as API information. Thus your issue QSPEC1 is a part of this issue(QSPEC3). Thus the RMF triggers should be given in the QOS-NSLP, but they should only be giving guidance to implementers and they should not restrict the flexibility and extensibility of the QOSM. Best Regards, Georgios > -----Original Message----- > From: Martin Stiemerling [mailto:stiemerling@netlab.nec.de] > Sent: dinsdag 6 februari 2007 14:56 > To: nsis > Subject: [NSIS] QSPEC3: Information API in QoS NSLP > > I believe we have reached consensus for this item QSPEC3. If > not, please object now. > > - The QoS NSLP draft needs an informational section > describing the API between QSPEC and QoS NSLP. This > informational section should be in the spirit of the API > description in GIST, i.e., giving guidance to implementers. > > Martin > > > > > stiemerling@netlab.nec.de > NEC Europe Limited | > Registered Office: NEC House, 1 Victoria Road, London W3 6BL > | Registered in England 2832014 > > > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Feb 06 10:00:07 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HERmy-0000zX-Kj; Tue, 06 Feb 2007 09:59:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HERmx-0000zR-FY for nsis@ietf.org; Tue, 06 Feb 2007 09:59:19 -0500 Received: from rotterdam.ewi.utwente.nl ([130.89.10.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HERmw-00035C-2f for nsis@ietf.org; Tue, 06 Feb 2007 09:59:19 -0500 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by rotterdam.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id l16EwoZA025481; Tue, 6 Feb 2007 15:58:54 +0100 (MET) From: "Georgios Karagiannis" To: "'Martin Stiemerling'" , "'nsis'" References: <787619A9-74F7-4154-A617-4F829AF92780@netlab.nec.de> Subject: RE: [NSIS] QSPEC2: State machine text part in QSPEC I-D Date: Tue, 6 Feb 2007 15:59:07 +0100 Message-ID: <004701c749ff$5d1f02b0$4c0d5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcdJ9rKRGLk+Tk2vSSusagAwGn8wdgAB1Lig In-Reply-To: <787619A9-74F7-4154-A617-4F829AF92780@netlab.nec.de> X-Spam-Score: 0.3 () FVGT_s_OBFU_Q1 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (rotterdam.ewi.utwente.nl [130.89.10.5]); Tue, 06 Feb 2007 15:58:55 +0100 (MET) X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Martin > -----Original Message----- > From: Martin Stiemerling [mailto:stiemerling@netlab.nec.de] > Sent: dinsdag 6 februari 2007 14:55 > To: nsis > Subject: [NSIS] QSPEC2: State machine text part in QSPEC I-D > > Well, I have not yet seen consensus about this issue. > > Georgios proposed this text: > > "QOSMs all utilize the state machines of the underlying NSIS > protocols and are not expected to re-define or extend these > in any way. Note that a QOSM can however, extend the RMF > triggers to/from the QOS-NSLP functionality, which might > affect the QoS-NSLP state machine." > > I personally also see that sentence 1 and 2 are contradicting > each other at least partially. The first sentence is not > allowing to extend the state machinery of the underlying NSIS > protocols, where the second sentence is is opening the door > for extending it. > > However, I don't see any real technical issue here, but more > a wording issue. > > I'm not a good wording expert here, but the base lines seems to be: > 1) QOSMs cannot change the semantics (and thus state machine) > of the underlying QoS NSLP and GIST. (A standards track > document is required for doing so). > 2) QOSMs can send triggers to the QoS NSLP. These trigger can > cause the QoS NSLP to run its semantics. Basically the " > affect the QoS- NSLP state machine." is not very clear to > readers. Yes, it affects the state machine, but only by > giving a reason for an initial state transition (e.g., send RESERVE). I think that you have emphasized what I was thinking of. However, note that these RMF triggers are internal triggers and according to the NSIS concepts they should be able to initiate and maintain the unidirectional/bidirectional and sender/receiver reservation intiation, refresh, tear, modification of: * bound and parallel end-to-end and end-to-end sessions * bound and parallel end-to-end and edge-to-edge sessions * bound and parallel end-to-end and end-to-edge sessions * Examples of QOSMs that support end-to-end sessions can be: ** Intserv like Controlled Load QOSM ** Intserv like Guaranteed Service QOSM * Examples of QOSMs that can support edge-to-edge sessions can be: ** RSVP aggregation like QOSM ** RMD-QOSM ** interdomain and intra-domain ITU-T RACF QoS model ** PCN like congestion notifictaion and preemption QoS model. ** RSVP-TE like QOSM * Examples of QOSMs that can support end-to-edge sessions: ** IEEE 802.16 Best regards, Georgios _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Feb 06 10:14:27 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HES0p-0000AQ-D4; Tue, 06 Feb 2007 10:13:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HES0o-0000A8-Ej for nsis@ietf.org; Tue, 06 Feb 2007 10:13:38 -0500 Received: from rotterdam.ewi.utwente.nl ([130.89.10.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HES0n-0005ka-19 for nsis@ietf.org; Tue, 06 Feb 2007 10:13:38 -0500 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by rotterdam.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id l16FCfQn026209; Tue, 6 Feb 2007 16:12:50 +0100 (MET) From: "Georgios Karagiannis" To: , , , References: <9473683187ADC049A855ED2DA739ABCA0DDC818B@KCCLUST06EVS1.ugd.att.com><9473683187ADC049A855ED2DA739ABCA0DDC818C@KCCLUST06EVS1.ugd.att.com> <002f01c7490d$8c2e8550$4c0d5982@dynamic.ewi.utwente.nl> <071568CA7B789D4AA170CEF8C9613B4F20BA8A@daebe103.NOE.Nokia.com> <000001c749cf$c4e37f50$4c0d5982@dynamic.ewi.utwente.nl> <071568CA7B789D4AA170CEF8C9613B4F246FF3@daebe103.NOE.Nokia.com> Subject: RE: State Machines .... was [NSIS] Summary of QSPEC call Date: Tue, 6 Feb 2007 16:12:57 +0100 Message-ID: <004901c74a01$4f591790$4c0d5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcdG52ID3k5BeYFGQcSKMpuMyZMTRwAECO3QAAm62HAAAztwsAB4XniQAA7xJLAAIPgqIAAL1GdgAAFQ7PA= In-Reply-To: <071568CA7B789D4AA170CEF8C9613B4F246FF3@daebe103.NOE.Nokia.com> X-Spam-Score: 1.4 (*) FVGT_s_MIXCASEWORDS,FVGT_s_OBFU_ODD06,FVGT_s_OBFU_Q1 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (rotterdam.ewi.utwente.nl [130.89.10.5]); Tue, 06 Feb 2007 16:12:51 +0100 (MET) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi John Regarding the interoperability support, I will resend you the proposal that Jukka has made with some additions of mine. "In order to preserve the end-to-end interoperability the end-to-end semantic and end-to-end QoS NSLP messaging by the QNI, or any peer QNE must be preserved, and within those bounds a QOSM must operate. Furthermore, a QOSM should not change the externally observable operation of the QOS-NSLP protocol." Do you agree? Best regards, Georgios > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > Sent: dinsdag 6 februari 2007 15:40 > To: karagian@cs.utwente.nl; gash@att.com; > Hannes.Tschofenig@gmx.net; nsis@ietf.org > Subject: RE: State Machines .... was [NSIS] Summary of QSPEC call > > Georgios, > > >> > >> [John] I disagree. All QoSM need to use the state machine > as defined > > >> in the QoS NSLP. If a QoSM changes the state machine of the QoS > NSLP, > >> then it must do so via a Standards Track RFC which extends the QoS > >> NLSP. > > > >Do you agree that the QOSM and the QOS-NSLP are supporting two > >different functionalities. > >Thus the QOSM has its own state machine and the QOS-NSLP has its own > >state machine. > > Exactly. That is what we are talking about. The RMF can > have its own state machine, and that can vary from QoSM to QoSM model. > > The paragraph above is only refering to the QoS NSLP state > machine, it is not talking about the RMF state machine at > all. The RMF state machine can be defined in the QoSM, not the NSLP. > > >> [John] Overall, QoSM are not assumed to change the General > Processing > > >> rules as defined in section 5.2. If it does, then the QoSM is > >> extending the QoS NSLP. > > > >Now regarding the above, I agree, but I think that this is something > >different than saying that the QOS-NSLP state machine should not be > >changed. > > What exactly do you want? I am not understanding what point > you are trying to make. > > >Please note that the unidirectional/bidirectional and > sender/receiver > >reservation intiation, refresh, tear, modification of the following > >scenarios are not described in the QOS-NSLP: > >bound and parallel end-to-end and end-to-end sessions bound and > >parallel end-to-end and edge-to-edge sessions bound and parallel > >end-to-end and end-to-edge sessions > > > >* Examples of QOSMs that support end-to-end sessions can be: > >Intserv like Controlled Load QOSM > >Intserv like Guaranteed Service QOSM > > > >* Examples of QOSMs that can support edge-to-edge sessions can be: > >RSVP aggregation like QOSM RMD-QOSM > >interdomain and intra-domain ITU-T RACF QoS model PCN like > congestion > >notifictaion and preemption QoS model. > >RSVP-TE like QOSM > > > >* Examples of QOSMs that can support end-to-edge sessions: > >IEEE 802.16 > > > >The reason of this is that the QOS-NSLP does not go into lot > of details > > >with any local node dependent functions, including QOSM > functionality, > >security and AAA interactions. > > At the end of the day, a standard QoS NSLP node should be > able to be re-used with any QoSM and work. If a QoSM makes > special optimizations, then it needs to do 1 of 2 things: > > 1) Make the optimizations optional, and have a fallback to > the standard > message processing rules defined in the QoS NSLP. > 2) The QoSM needs to make a QoS NSLP extension, which is a > standards track > document. > > I cannot see how we get any interoperability otherwise. > > John > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Feb 06 10:14:31 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HES11-0000GC-N3; Tue, 06 Feb 2007 10:13:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HES10-0000G7-Ji for nsis@ietf.org; Tue, 06 Feb 2007 10:13:50 -0500 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HES0z-0005lL-4Y for nsis@ietf.org; Tue, 06 Feb 2007 10:13:50 -0500 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l16FBLeQ006242; Tue, 6 Feb 2007 17:11:21 +0200 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 6 Feb 2007 17:13:13 +0200 Received: from daebe103.NOE.Nokia.com ([10.241.35.24]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 6 Feb 2007 09:12:59 -0600 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] QSPEC3: Information API in QoS NSLP Date: Tue, 6 Feb 2007 09:12:56 -0600 Message-ID: <071568CA7B789D4AA170CEF8C9613B4F24707D@daebe103.NOE.Nokia.com> In-Reply-To: <004601c749fd$ba21a870$4c0d5982@dynamic.ewi.utwente.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] QSPEC3: Information API in QoS NSLP Thread-Index: AcdJ9rKRmWYVorg5TXijH7UfOcIWDwABn0IwAADuA6A= References: <232F0B56-161A-4AFD-91BC-F8BAA0463F33@netlab.nec.de> <004601c749fd$ba21a870$4c0d5982@dynamic.ewi.utwente.nl> From: To: , , X-OriginalArrivalTime: 06 Feb 2007 15:12:59.0384 (UTC) FILETIME=[499DA780:01C74A01] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070206171126-17F91BB0-27C052C9/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Georgios, Unfortunately, I must disagree. The QoS NSLP is a Standards Track protocol, the QoSM documents are only informational. QoSM MUST use the standard mechanisms defined in the QoS NSLP. The signaling between the RMF and QoS NSLP must follow the message processing rules in the QoS NSLP. If there are changes to the message processing rules in the QoS NLSP, then the QoSM MUST define a fall-back to the rules defined in the QoSM. John >-----Original Message----- >From: ext Georgios Karagiannis [mailto:karagian@cs.utwente.nl]=20 >Sent: 06 February, 2007 06:47 >To: 'Martin Stiemerling'; 'nsis' >Subject: RE: [NSIS] QSPEC3: Information API in QoS NSLP > >Hi Martin > >I agree, but the RMF triggers are internal triggers betweeen=20 >QOSM and QOS-NSLP thus they can be considered as API information.=20 >Thus your issue QSPEC1 is a part of this issue(QSPEC3). >Thus the RMF triggers should be given in the QOS-NSLP, but=20 >they should only be giving guidance to implementers and they=20 >should not restrict the flexibility and extensibility of the QOSM. > > >Best Regards, >Georgios > > >=20 > >> -----Original Message----- >> From: Martin Stiemerling [mailto:stiemerling@netlab.nec.de] >> Sent: dinsdag 6 februari 2007 14:56 >> To: nsis >> Subject: [NSIS] QSPEC3: Information API in QoS NSLP >>=20 >> I believe we have reached consensus for this item QSPEC3. If not,=20 >> please object now. >>=20 >> - The QoS NSLP draft needs an informational section=20 >describing the API=20 >> between QSPEC and QoS NSLP. This informational section should be in=20 >> the spirit of the API description in GIST, i.e., giving guidance to=20 >> implementers. >>=20 >> Martin >>=20 >>=20 >>=20 >>=20 >> stiemerling@netlab.nec.de >> NEC Europe Limited | >> Registered Office: NEC House, 1 Victoria Road, London W3 6BL >> | Registered in England 2832014 >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> nsis mailing list >> nsis@ietf.org >> https://www1.ietf.org/mailman/listinfo/nsis >>=20 > > > >_______________________________________________ >nsis mailing list >nsis@ietf.org >https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Feb 06 10:24:35 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HESAm-0004rL-JB; Tue, 06 Feb 2007 10:23:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HESAj-0004rD-QJ for nsis@ietf.org; Tue, 06 Feb 2007 10:23:54 -0500 Received: from rotterdam.ewi.utwente.nl ([130.89.10.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HESAi-0007Ht-BV for nsis@ietf.org; Tue, 06 Feb 2007 10:23:53 -0500 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by rotterdam.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id l16FNOUC026750; Tue, 6 Feb 2007 16:23:28 +0100 (MET) From: "Georgios Karagiannis" To: , , References: <232F0B56-161A-4AFD-91BC-F8BAA0463F33@netlab.nec.de><004601c749fd$ba21a870$4c0d5982@dynamic.ewi.utwente.nl> <071568CA7B789D4AA170CEF8C9613B4F24707D@daebe103.NOE.Nokia.com> Subject: RE: [NSIS] QSPEC3: Information API in QoS NSLP Date: Tue, 6 Feb 2007 16:23:42 +0100 Message-ID: <004a01c74a02$cbebd990$4c0d5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcdJ9rKRmWYVorg5TXijH7UfOcIWDwABn0IwAADuA6AAAE5SoA== In-Reply-To: <071568CA7B789D4AA170CEF8C9613B4F24707D@daebe103.NOE.Nokia.com> X-Spam-Score: 0.3 () FVGT_s_OBFU_Q1 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (rotterdam.ewi.utwente.nl [130.89.10.5]); Tue, 06 Feb 2007 16:23:29 +0100 (MET) X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi John If you mean externally observable message processing rules, then it is okay! Note that according to the NSIS goals, NSIS should be able to initiate and maintain the unidirectional/bidirectional and sender/receiver reservation intiation, refresh, tear, modification of: * bound and parallel end-to-end and end-to-end sessions * bound and parallel end-to-end and edge-to-edge sessions * bound and parallel end-to-end and end-to-edge sessions * Examples of QOSMs that support end-to-end sessions can be: ** Intserv like Controlled Load QOSM ** Intserv like Guaranteed Service QOSM * Examples of QOSMs that can support edge-to-edge sessions can be: ** RSVP aggregation like QOSM ** RMD-QOSM ** interdomain and intra-domain ITU-T RACF QoS model ** PCN like congestion notifictaion and preemption QoS model. ** RSVP-TE like QOSM * Examples of QOSMs that can support end-to-edge sessions: ** IEEE 802.16 The idea of using the QOSM and thus the specification of the RMF triggers was to support and provide the above scenarios. Do you agree? Best regards, Georgios > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > Sent: dinsdag 6 februari 2007 16:13 > To: karagian@cs.utwente.nl; stiemerling@netlab.nec.de; nsis@ietf.org > Subject: RE: [NSIS] QSPEC3: Information API in QoS NSLP > > Georgios, > > Unfortunately, I must disagree. The QoS NSLP is a Standards > Track protocol, the QoSM documents are only informational. > QoSM MUST use the standard mechanisms defined in the QoS > NSLP. The signaling between the RMF and QoS NSLP must follow > the message processing rules in the QoS NSLP. If there are > changes to the message processing rules in the QoS NLSP, then > the QoSM MUST define a fall-back to the rules defined in the QoSM. > > John > > >-----Original Message----- > >From: ext Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > >Sent: 06 February, 2007 06:47 > >To: 'Martin Stiemerling'; 'nsis' > >Subject: RE: [NSIS] QSPEC3: Information API in QoS NSLP > > > >Hi Martin > > > >I agree, but the RMF triggers are internal triggers betweeen > QOSM and > >QOS-NSLP thus they can be considered as API information. > >Thus your issue QSPEC1 is a part of this issue(QSPEC3). > >Thus the RMF triggers should be given in the QOS-NSLP, but > they should > >only be giving guidance to implementers and they should not restrict > >the flexibility and extensibility of the QOSM. > > > > > >Best Regards, > >Georgios > > > > > > > > > >> -----Original Message----- > >> From: Martin Stiemerling [mailto:stiemerling@netlab.nec.de] > >> Sent: dinsdag 6 februari 2007 14:56 > >> To: nsis > >> Subject: [NSIS] QSPEC3: Information API in QoS NSLP > >> > >> I believe we have reached consensus for this item QSPEC3. If not, > >> please object now. > >> > >> - The QoS NSLP draft needs an informational section > >describing the API > >> between QSPEC and QoS NSLP. This informational section > should be in > >> the spirit of the API description in GIST, i.e., giving > guidance to > >> implementers. > >> > >> Martin > >> > >> > >> > >> > >> stiemerling@netlab.nec.de > >> NEC Europe Limited | > >> Registered Office: NEC House, 1 Victoria Road, London W3 6BL > >> | Registered in England 2832014 > >> > >> > >> > >> > >> _______________________________________________ > >> nsis mailing list > >> nsis@ietf.org > >> https://www1.ietf.org/mailman/listinfo/nsis > >> > > > > > > > >_______________________________________________ > >nsis mailing list > >nsis@ietf.org > >https://www1.ietf.org/mailman/listinfo/nsis > > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Feb 06 11:42:38 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HETOG-0000wV-JF; Tue, 06 Feb 2007 11:41:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HETOE-0000vB-N2 for nsis@ietf.org; Tue, 06 Feb 2007 11:41:54 -0500 Received: from mail146.messagelabs.com ([216.82.245.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HETO0-0005rd-1D for nsis@ietf.org; Tue, 06 Feb 2007 11:41:44 -0500 X-VirusChecked: Checked X-Env-Sender: gash@att.com X-Msg-Ref: server-3.tower-146.messagelabs.com!1170780098!4030437!1 X-StarScan-Version: 5.5.10.7.1; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 8804 invoked from network); 6 Feb 2007 16:41:38 -0000 Received: from unknown (HELO attrh3i.attrh.att.com) (134.24.146.4) by server-3.tower-146.messagelabs.com with SMTP; 6 Feb 2007 16:41:38 -0000 Received: from attrh.att.com (localhost [127.0.0.1]) by attrh3i.attrh.att.com (8.13.7/8.13.7) with ESMTP id l16GfaYa023534; Tue, 6 Feb 2007 11:41:37 -0500 (EST) Received: from kcclust06evs1.ugd.att.com ([135.38.164.88]) by attrh3i.attrh.att.com (8.13.7/8.13.7) with ESMTP id l16GfUY1023427; Tue, 6 Feb 2007 11:41:32 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] QSPEC2: State machine text part in QSPEC I-D Date: Tue, 6 Feb 2007 10:41:31 -0600 Message-ID: <9473683187ADC049A855ED2DA739ABCA0DDC819D@KCCLUST06EVS1.ugd.att.com> In-Reply-To: <787619A9-74F7-4154-A617-4F829AF92780@netlab.nec.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] QSPEC2: State machine text part in QSPEC I-D Thread-Index: AcdJ9rcBvdCriOehRVaR6h7+UByyLwAFkV0A From: "ASH, GERALD R \(JERRY\), ATTLABS" To: "Martin Stiemerling" , "nsis" X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: "ASH, GERALD R \(JERRY\), ATTLABS" X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Martin, I agree with your clarified text, slightly edited here: "RMF/QOSMs cannot change the semantics and thus the state machine of the underlying QoS NSLP and GIST (a standards track document is required for doing so), although RMF/QOSMs can send triggers to the QoS NSLP that cause the QoS NSLP to run its semantics." Thanks, Regards, Jerry=20 -----Original Message----- From: Martin Stiemerling [mailto:stiemerling@netlab.nec.de]=20 Sent: Tuesday, February 06, 2007 8:55 AM To: nsis Subject: [NSIS] QSPEC2: State machine text part in QSPEC I-D Well, I have not yet seen consensus about this issue. Georgios proposed this text: "QOSMs all utilize the state machines of the underlying NSIS =20 protocols and are not expected to re-define or extend these in any =20 way. Note that a QOSM can however, extend the RMF triggers to/from =20 the QOS-NSLP functionality, which might affect the QoS-NSLP state =20 machine." I personally also see that sentence 1 and 2 are contradicting each =20 other at least partially. The first sentence is not allowing to =20 extend the state machinery of the underlying NSIS protocols, where =20 the second sentence is is opening the door for extending it. However, I don't see any real technical issue here, but more a =20 wording issue. I'm not a good wording expert here, but the base lines seems to be: 1) QOSMs cannot change the semantics (and thus state machine) of the =20 underlying QoS NSLP and GIST. (A standards track document is required =20 for doing so). 2) QOSMs can send triggers to the QoS NSLP. These trigger can cause =20 the QoS NSLP to run its semantics. Basically the " affect the QoS-=20 NSLP state machine." is not very clear to readers. Yes, it affects =20 the state machine, but only by giving a reason for an initial state =20 transition (e.g., send RESERVE). So, I'm now waiting for the big, loud scream of what is wrong here. :-) Martin stiemerling@netlab.nec.de NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Feb 06 12:46:41 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEUOC-000842-86; Tue, 06 Feb 2007 12:45:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEUO9-00080e-KK for nsis@ietf.org; Tue, 06 Feb 2007 12:45:53 -0500 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HEUMv-00031W-4v for nsis@ietf.org; Tue, 06 Feb 2007 12:44:38 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l16HfjLo019020; Tue, 6 Feb 2007 19:42:12 +0200 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 6 Feb 2007 19:43:56 +0200 Received: from daebe103.NOE.Nokia.com ([10.241.35.24]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 6 Feb 2007 11:43:52 -0600 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] QSPEC2: State machine text part in QSPEC I-D Date: Tue, 6 Feb 2007 11:43:51 -0600 Message-ID: <071568CA7B789D4AA170CEF8C9613B4F247279@daebe103.NOE.Nokia.com> In-Reply-To: <9473683187ADC049A855ED2DA739ABCA0DDC819D@KCCLUST06EVS1.ugd.att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] QSPEC2: State machine text part in QSPEC I-D Thread-Index: AcdJ9rcBvdCriOehRVaR6h7+UByyLwAFkV0AAAIrkhA= References: <787619A9-74F7-4154-A617-4F829AF92780@netlab.nec.de> <9473683187ADC049A855ED2DA739ABCA0DDC819D@KCCLUST06EVS1.ugd.att.com> From: To: , , X-OriginalArrivalTime: 06 Feb 2007 17:43:52.0268 (UTC) FILETIME=[5D8E20C0:01C74A16] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070206194212-4A056BB0-0B49F26A/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Jerry, I was thinking of text along the lines of the following: QoSMs define the RMF triggers for the underlying QoS NSLP and GIST signaling state. A QoSM works with the messaging=20 processing rules of the QoS NSLP (defined in section 5.2). If the QoSM defines new QoS NSLP processing rules, the QoSM MUST define a fallback to the standard QoS NSLP processing=20 rules. New QoS NSLP message processing rules can only defined in Standards Track extensions to the QoS NSLP. Does this make sense? John >-----Original Message----- >From: ext ASH, GERALD R (JERRY), ATTLABS [mailto:gash@att.com]=20 >Sent: 06 February, 2007 08:42 >To: Martin Stiemerling; nsis >Cc: ASH, GERALD R (JERRY), ATTLABS >Subject: RE: [NSIS] QSPEC2: State machine text part in QSPEC I-D > >Hi Martin, > >I agree with your clarified text, slightly edited here: > >"RMF/QOSMs cannot change the semantics and thus the state=20 >machine of the underlying QoS NSLP and GIST (a standards track=20 >document is required for doing so), although RMF/QOSMs can=20 >send triggers to the QoS NSLP that cause the QoS NSLP to run=20 >its semantics." > >Thanks, >Regards, >Jerry=20 > >-----Original Message----- >From: Martin Stiemerling [mailto:stiemerling@netlab.nec.de] >Sent: Tuesday, February 06, 2007 8:55 AM >To: nsis >Subject: [NSIS] QSPEC2: State machine text part in QSPEC I-D > >Well, I have not yet seen consensus about this issue. > >Georgios proposed this text: > >"QOSMs all utilize the state machines of the underlying NSIS=20 >protocols and are not expected to re-define or extend these=20 >in any way. Note that a QOSM can however, extend the RMF=20 >triggers to/from the QOS-NSLP functionality, which might=20 >affect the QoS-NSLP state machine." > >I personally also see that sentence 1 and 2 are contradicting=20 >each other at least partially. The first sentence is not=20 >allowing to extend the state machinery of the underlying NSIS=20 >protocols, where the second sentence is is opening the door=20 >for extending it. > >However, I don't see any real technical issue here, but more a=20 >wording issue. > >I'm not a good wording expert here, but the base lines seems to be: >1) QOSMs cannot change the semantics (and thus state machine)=20 >of the underlying QoS NSLP and GIST. (A standards track=20 >document is required for doing so). >2) QOSMs can send triggers to the QoS NSLP. These trigger can=20 >cause the QoS NSLP to run its semantics. Basically the "=20 >affect the QoS- NSLP state machine." is not very clear to=20 >readers. Yes, it affects the state machine, but only by giving=20 >a reason for an initial state transition (e.g., send RESERVE). > >So, I'm now waiting for the big, loud scream of what is wrong here. :-) > > Martin > >stiemerling@netlab.nec.de >NEC Europe Limited | >Registered Office: NEC House, 1 Victoria Road, London W3 6BL |=20 >Registered in England 2832014 > > > > >_______________________________________________ >nsis mailing list >nsis@ietf.org >https://www1.ietf.org/mailman/listinfo/nsis > >_______________________________________________ >nsis mailing list >nsis@ietf.org >https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Feb 06 12:46:44 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEUOP-0008Cx-61; Tue, 06 Feb 2007 12:46:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEUOK-000894-BX for nsis@ietf.org; Tue, 06 Feb 2007 12:46:04 -0500 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HEUOI-0003Of-Ro for nsis@ietf.org; Tue, 06 Feb 2007 12:46:04 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l16HgdZP026132; Tue, 6 Feb 2007 19:42:52 +0200 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 6 Feb 2007 19:45:25 +0200 Received: from daebe103.NOE.Nokia.com ([10.241.35.24]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 6 Feb 2007 11:45:20 -0600 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] QSPEC2: State machine text part in QSPEC I-D Date: Tue, 6 Feb 2007 11:45:20 -0600 Message-ID: <071568CA7B789D4AA170CEF8C9613B4F247280@daebe103.NOE.Nokia.com> In-Reply-To: <004701c749ff$5d1f02b0$4c0d5982@dynamic.ewi.utwente.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] QSPEC2: State machine text part in QSPEC I-D Thread-Index: AcdJ9rKRGLk+Tk2vSSusagAwGn8wdgAB1LigAAYXT6A= References: <787619A9-74F7-4154-A617-4F829AF92780@netlab.nec.de> <004701c749ff$5d1f02b0$4c0d5982@dynamic.ewi.utwente.nl> From: To: , , X-OriginalArrivalTime: 06 Feb 2007 17:45:20.0751 (UTC) FILETIME=[924B8FF0:01C74A16] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070206194253-65D1ABB0-2D465CCB/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Georgios, You raise the following points below: >I think that you have emphasized what I was thinking of. >However, note that these RMF triggers are internal triggers=20 >and according to >the NSIS concepts >they should be able to initiate and maintain the >unidirectional/bidirectional and sender/receiver=20 >reservation intiation, refresh, tear, modification of: > * bound and parallel end-to-end and end-to-end sessions=20 > * bound and parallel end-to-end and edge-to-edge sessions=20 > * bound and parallel end-to-end and end-to-edge sessions > >* Examples of QOSMs that support end-to-end sessions can be: > ** Intserv like Controlled Load QOSM > ** Intserv like Guaranteed Service QOSM > >* Examples of QOSMs that can support edge-to-edge sessions can be: > ** RSVP aggregation like QOSM=20 > ** RMD-QOSM > ** interdomain and intra-domain ITU-T RACF QoS model=20 > ** PCN like congestion notifictaion and preemption QoS model. > ** RSVP-TE like QOSM > >* Examples of QOSMs that can support end-to-edge sessions:=20 > ** IEEE 802.16 However, do you feel that the current QoS NSLP currently limits any of the above? If not, then I think we are done. If it does, we need to either fix or extend the QoS NSLP to meet your concerns. The QoSMs are not the place to extend the QoS NSLP. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Feb 06 14:36:48 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEW6n-0001Nc-3i; Tue, 06 Feb 2007 14:36:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEW6l-0001NU-T1 for nsis@ietf.org; Tue, 06 Feb 2007 14:36:03 -0500 Received: from mail146.messagelabs.com ([216.82.245.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HEW6k-00026U-GR for nsis@ietf.org; Tue, 06 Feb 2007 14:36:03 -0500 X-VirusChecked: Checked X-Env-Sender: gash@att.com X-Msg-Ref: server-15.tower-146.messagelabs.com!1170790561!4606994!1 X-StarScan-Version: 5.5.10.7.1; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 23802 invoked from network); 6 Feb 2007 19:36:01 -0000 Received: from unknown (HELO attrh0i.attrh.att.com) (134.24.146.4) by server-15.tower-146.messagelabs.com with SMTP; 6 Feb 2007 19:36:01 -0000 Received: from attrh.att.com (localhost [127.0.0.1]) by attrh0i.attrh.att.com (8.13.7/8.13.7) with ESMTP id l16Ja09f022416; Tue, 6 Feb 2007 14:36:01 -0500 (EST) Received: from kcclust06evs1.ugd.att.com ([135.38.164.88]) by attrh0i.attrh.att.com (8.13.7/8.13.7) with ESMTP id l16JZtqJ022354; Tue, 6 Feb 2007 14:35:56 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] QSPEC2: State machine text part in QSPEC I-D Date: Tue, 6 Feb 2007 13:35:55 -0600 Message-ID: <9473683187ADC049A855ED2DA739ABCA0DDC81A2@KCCLUST06EVS1.ugd.att.com> In-Reply-To: <071568CA7B789D4AA170CEF8C9613B4F247279@daebe103.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] QSPEC2: State machine text part in QSPEC I-D Thread-Index: AcdJ9rcBvdCriOehRVaR6h7+UByyLwAFkV0AAAIrkhAAA/ixIA== From: "ASH, GERALD R \(JERRY\), ATTLABS" To: , , X-Spam-Score: 0.0 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Cc: "ASH, GERALD R \(JERRY\), ATTLABS" X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi John, How about this text: "QOSM specifications may define RMF triggers that cause the QoS NSLP to run semantics within the underlying QoS NSLP signaling state and messaging processing rules, as defined in Section 5.2 of [QoS-SIG]. New QoS NSLP message processing rules can only be defined in Standards Track extensions to the QoS NSLP. If a QOSM specification defines triggers that deviate from existing standard QoS NSLP processing rules (must be standards track in that case), the fallback for QNEs not supporting that QOSM is to use the standard QoS NSLP state transition/message processing rules." Is that consistent with your proposal? Thanks, Jerry=20 -----Original Message----- From: john.loughney@nokia.com [mailto:john.loughney@nokia.com]=20 Sent: Tuesday, February 06, 2007 12:44 PM To: ASH, GERALD R (JERRY), ATTLABS; stiemerling@netlab.nec.de; nsis@ietf.org Subject: RE: [NSIS] QSPEC2: State machine text part in QSPEC I-D Jerry, I was thinking of text along the lines of the following: QoSMs define the RMF triggers for the underlying QoS NSLP and GIST signaling state. A QoSM works with the messaging=20 processing rules of the QoS NSLP (defined in section 5.2). If the QoSM defines new QoS NSLP processing rules, the QoSM MUST define a fallback to the standard QoS NSLP processing=20 rules. New QoS NSLP message processing rules can only defined in Standards Track extensions to the QoS NSLP. Does this make sense? John >-----Original Message----- >From: ext ASH, GERALD R (JERRY), ATTLABS [mailto:gash@att.com]=20 >Sent: 06 February, 2007 08:42 >To: Martin Stiemerling; nsis >Cc: ASH, GERALD R (JERRY), ATTLABS >Subject: RE: [NSIS] QSPEC2: State machine text part in QSPEC I-D > >Hi Martin, > >I agree with your clarified text, slightly edited here: > >"RMF/QOSMs cannot change the semantics and thus the state=20 >machine of the underlying QoS NSLP and GIST (a standards track=20 >document is required for doing so), although RMF/QOSMs can=20 >send triggers to the QoS NSLP that cause the QoS NSLP to run=20 >its semantics." > >Thanks, >Regards, >Jerry=20 > >-----Original Message----- >From: Martin Stiemerling [mailto:stiemerling@netlab.nec.de] >Sent: Tuesday, February 06, 2007 8:55 AM >To: nsis >Subject: [NSIS] QSPEC2: State machine text part in QSPEC I-D > >Well, I have not yet seen consensus about this issue. > >Georgios proposed this text: > >"QOSMs all utilize the state machines of the underlying NSIS=20 >protocols and are not expected to re-define or extend these=20 >in any way. Note that a QOSM can however, extend the RMF=20 >triggers to/from the QOS-NSLP functionality, which might=20 >affect the QoS-NSLP state machine." > >I personally also see that sentence 1 and 2 are contradicting=20 >each other at least partially. The first sentence is not=20 >allowing to extend the state machinery of the underlying NSIS=20 >protocols, where the second sentence is is opening the door=20 >for extending it. > >However, I don't see any real technical issue here, but more a=20 >wording issue. > >I'm not a good wording expert here, but the base lines seems to be: >1) QOSMs cannot change the semantics (and thus state machine)=20 >of the underlying QoS NSLP and GIST. (A standards track=20 >document is required for doing so). >2) QOSMs can send triggers to the QoS NSLP. These trigger can=20 >cause the QoS NSLP to run its semantics. Basically the "=20 >affect the QoS- NSLP state machine." is not very clear to=20 >readers. Yes, it affects the state machine, but only by giving=20 >a reason for an initial state transition (e.g., send RESERVE). > >So, I'm now waiting for the big, loud scream of what is wrong here. :-) > > Martin > >stiemerling@netlab.nec.de >NEC Europe Limited | >Registered Office: NEC House, 1 Victoria Road, London W3 6BL |=20 >Registered in England 2832014 > > > > >_______________________________________________ >nsis mailing list >nsis@ietf.org >https://www1.ietf.org/mailman/listinfo/nsis > >_______________________________________________ >nsis mailing list >nsis@ietf.org >https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Feb 06 15:23:28 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEWps-0007PL-PS; Tue, 06 Feb 2007 15:22:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEWpr-0007PG-Qm for nsis@ietf.org; Tue, 06 Feb 2007 15:22:39 -0500 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HEWpq-0001NN-9M for nsis@ietf.org; Tue, 06 Feb 2007 15:22:39 -0500 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l16KIxIT027970; Tue, 6 Feb 2007 22:19:07 +0200 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 6 Feb 2007 22:22:08 +0200 Received: from daebe103.NOE.Nokia.com ([10.241.35.24]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 6 Feb 2007 14:21:44 -0600 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] QSPEC2: State machine text part in QSPEC I-D Date: Tue, 6 Feb 2007 14:21:41 -0600 Message-ID: <071568CA7B789D4AA170CEF8C9613B4F2474FF@daebe103.NOE.Nokia.com> In-Reply-To: <9473683187ADC049A855ED2DA739ABCA0DDC81A2@KCCLUST06EVS1.ugd.att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] QSPEC2: State machine text part in QSPEC I-D Thread-Index: AcdJ9rcBvdCriOehRVaR6h7+UByyLwAFkV0AAAIrkhAAA/ixIAABtYlA References: <071568CA7B789D4AA170CEF8C9613B4F247279@daebe103.NOE.Nokia.com> <9473683187ADC049A855ED2DA739ABCA0DDC81A2@KCCLUST06EVS1.ugd.att.com> From: To: , , X-OriginalArrivalTime: 06 Feb 2007 20:21:44.0697 (UTC) FILETIME=[6B901690:01C74A2C] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070206221907-6D1DFBB0-5E6CEADD/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172 Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org I think that looks fine. What do others thing about this? John=20 >-----Original Message----- >From: ext ASH, GERALD R (JERRY), ATTLABS [mailto:gash@att.com]=20 >Sent: 06 February, 2007 11:36 >To: Loughney John (Nokia-NRC/PaloAlto);=20 >stiemerling@netlab.nec.de; nsis@ietf.org >Cc: ASH, GERALD R (JERRY), ATTLABS >Subject: RE: [NSIS] QSPEC2: State machine text part in QSPEC I-D > >Hi John, > >How about this text: > >"QOSM specifications may define RMF triggers that cause the=20 >QoS NSLP to run semantics within the underlying QoS NSLP=20 >signaling state and messaging processing rules, as defined in=20 >Section 5.2 of [QoS-SIG]. New QoS NSLP message processing=20 >rules can only be defined in Standards Track extensions to the=20 >QoS NSLP. If a QOSM specification defines triggers that=20 >deviate from existing standard QoS NSLP processing rules (must=20 >be standards track in that case), the fallback for QNEs not=20 >supporting that QOSM is to use the standard QoS NSLP state=20 >transition/message processing rules." > >Is that consistent with your proposal? > >Thanks, >Jerry=20 > >-----Original Message----- >From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] >Sent: Tuesday, February 06, 2007 12:44 PM >To: ASH, GERALD R (JERRY), ATTLABS; stiemerling@netlab.nec.de;=20 >nsis@ietf.org >Subject: RE: [NSIS] QSPEC2: State machine text part in QSPEC I-D > >Jerry, > >I was thinking of text along the lines of the following: > > QoSMs define the RMF triggers for the underlying QoS NSLP and=20 > GIST signaling state. A QoSM works with the messaging =20 >processing rules of the QoS NSLP (defined in section 5.2). > If the QoSM defines new QoS NSLP processing rules, the QoSM =20 >MUST define a fallback to the standard QoS NSLP processing =20 >rules. New QoS NSLP message processing rules can only defined=20 > in Standards Track extensions to the QoS NSLP. > >Does this make sense? > >John > >>-----Original Message----- >>From: ext ASH, GERALD R (JERRY), ATTLABS [mailto:gash@att.com] >>Sent: 06 February, 2007 08:42 >>To: Martin Stiemerling; nsis >>Cc: ASH, GERALD R (JERRY), ATTLABS >>Subject: RE: [NSIS] QSPEC2: State machine text part in QSPEC I-D >> >>Hi Martin, >> >>I agree with your clarified text, slightly edited here: >> >>"RMF/QOSMs cannot change the semantics and thus the state machine of=20 >>the underlying QoS NSLP and GIST (a standards track document is=20 >>required for doing so), although RMF/QOSMs can send triggers=20 >to the QoS=20 >>NSLP that cause the QoS NSLP to run its semantics." >> >>Thanks, >>Regards, >>Jerry >> >>-----Original Message----- >>From: Martin Stiemerling [mailto:stiemerling@netlab.nec.de] >>Sent: Tuesday, February 06, 2007 8:55 AM >>To: nsis >>Subject: [NSIS] QSPEC2: State machine text part in QSPEC I-D >> >>Well, I have not yet seen consensus about this issue. >> >>Georgios proposed this text: >> >>"QOSMs all utilize the state machines of the underlying NSIS=20 >protocols=20 >>and are not expected to re-define or extend these in any way. Note=20 >>that a QOSM can however, extend the RMF triggers to/from the QOS-NSLP=20 >>functionality, which might affect the QoS-NSLP state machine." >> >>I personally also see that sentence 1 and 2 are contradicting each=20 >>other at least partially. The first sentence is not allowing=20 >to extend=20 >>the state machinery of the underlying NSIS protocols, where=20 >the second=20 >>sentence is is opening the door for extending it. >> >>However, I don't see any real technical issue here, but more=20 >a wording=20 >>issue. >> >>I'm not a good wording expert here, but the base lines seems to be: >>1) QOSMs cannot change the semantics (and thus state machine) of the=20 >>underlying QoS NSLP and GIST. (A standards track document is required=20 >>for doing so). >>2) QOSMs can send triggers to the QoS NSLP. These trigger can=20 >cause the=20 >>QoS NSLP to run its semantics. Basically the " >>affect the QoS- NSLP state machine." is not very clear to=20 >readers. Yes,=20 >>it affects the state machine, but only by giving a reason for an=20 >>initial state transition (e.g., send RESERVE). >> >>So, I'm now waiting for the big, loud scream of what is wrong=20 >here. :-) >> >> Martin >> >>stiemerling@netlab.nec.de >>NEC Europe Limited | >>Registered Office: NEC House, 1 Victoria Road, London W3 6BL |=20 >>Registered in England 2832014 >> >> >> >> >>_______________________________________________ >>nsis mailing list >>nsis@ietf.org >>https://www1.ietf.org/mailman/listinfo/nsis >> >>_______________________________________________ >>nsis mailing list >>nsis@ietf.org >>https://www1.ietf.org/mailman/listinfo/nsis >> > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Feb 06 15:23:32 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEWq8-0007R0-1V; Tue, 06 Feb 2007 15:22:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEWq6-0007Qu-Sl for nsis@ietf.org; Tue, 06 Feb 2007 15:22:54 -0500 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HEWq5-0001Z3-D6 for nsis@ietf.org; Tue, 06 Feb 2007 15:22:54 -0500 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l16KJQAY028458; Tue, 6 Feb 2007 22:19:38 +0200 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 6 Feb 2007 22:22:24 +0200 Received: from daebe103.NOE.Nokia.com ([10.241.35.24]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 6 Feb 2007 14:22:15 -0600 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: State Machines .... was [NSIS] Summary of QSPEC call Date: Tue, 6 Feb 2007 14:22:13 -0600 Message-ID: <071568CA7B789D4AA170CEF8C9613B4F247500@daebe103.NOE.Nokia.com> In-Reply-To: <004901c74a01$4f591790$4c0d5982@dynamic.ewi.utwente.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: State Machines .... was [NSIS] Summary of QSPEC call Thread-Index: AcdG52ID3k5BeYFGQcSKMpuMyZMTRwAECO3QAAm62HAAAztwsAB4XniQAA7xJLAAIPgqIAAL1GdgAAFQ7PAACtePUA== References: <9473683187ADC049A855ED2DA739ABCA0DDC818B@KCCLUST06EVS1.ugd.att.com><9473683187ADC049A855ED2DA739ABCA0DDC818C@KCCLUST06EVS1.ugd.att.com> <002f01c7490d$8c2e8550$4c0d5982@dynamic.ewi.utwente.nl> <071568CA7B789D4AA170CEF8C9613B4F20BA8A@daebe103.NOE.Nokia.com> <000001c749cf$c4e37f50$4c0d5982@dynamic.ewi.utwente.nl> <071568CA7B789D4AA170CEF8C9613B4F246FF3@daebe103.NOE.Nokia.com> <004901c74a01$4f591790$4c0d5982@dynamic.ewi.utwente.nl> From: To: , , , X-OriginalArrivalTime: 06 Feb 2007 20:22:15.0978 (UTC) FILETIME=[7E3530A0:01C74A2C] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Honestly, I don't think that it is specific enough. See text that Jerry has just proposed. John=20 >-----Original Message----- >From: ext Georgios Karagiannis [mailto:karagian@cs.utwente.nl]=20 >Sent: 06 February, 2007 07:13 >To: Loughney John (Nokia-NRC/PaloAlto); gash@att.com;=20 >Hannes.Tschofenig@gmx.net; nsis@ietf.org >Subject: RE: State Machines .... was [NSIS] Summary of QSPEC call > >Hi John > >Regarding the interoperability support, I will resend you the=20 >proposal that Jukka has made with some additions of mine. > >"In order to preserve the end-to-end interoperability the=20 >end-to-end semantic and end-to-end QoS NSLP messaging by the=20 >QNI, or any peer QNE must be preserved, and within those=20 >bounds a QOSM must operate. Furthermore, a QOSM should not=20 >change the externally observable operation of the QOS-NSLP protocol."=20 > >Do you agree? > >Best regards, >Georgios > > >> -----Original Message----- >> From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] >> Sent: dinsdag 6 februari 2007 15:40 >> To: karagian@cs.utwente.nl; gash@att.com; Hannes.Tschofenig@gmx.net;=20 >> nsis@ietf.org >> Subject: RE: State Machines .... was [NSIS] Summary of QSPEC call >>=20 >> Georgios, >>=20 >> >>=20 >> >> [John] I disagree. All QoSM need to use the state machine >> as defined >>=20 >> >> in the QoS NSLP. If a QoSM changes the state machine of the QoS >> NSLP, >> >> then it must do so via a Standards Track RFC which=20 >extends the QoS=20 >> >> NLSP. >> > >> >Do you agree that the QOSM and the QOS-NSLP are supporting two=20 >> >different functionalities. >> >Thus the QOSM has its own state machine and the QOS-NSLP=20 >has its own=20 >> >state machine. >>=20 >> Exactly. That is what we are talking about. The RMF can=20 >have its own=20 >> state machine, and that can vary from QoSM to QoSM model. >>=20 >> The paragraph above is only refering to the QoS NSLP state=20 >machine, it=20 >> is not talking about the RMF state machine at all. The RMF state=20 >> machine can be defined in the QoSM, not the NSLP. >>=20 >> >> [John] Overall, QoSM are not assumed to change the General >> Processing >>=20 >> >> rules as defined in section 5.2. If it does, then the QoSM is=20 >> >> extending the QoS NSLP. >> > >> >Now regarding the above, I agree, but I think that this is=20 >something=20 >> >different than saying that the QOS-NSLP state machine should not be=20 >> >changed. >>=20 >> What exactly do you want? I am not understanding what point you are=20 >> trying to make. >>=20 >> >Please note that the unidirectional/bidirectional and >> sender/receiver >> >reservation intiation, refresh, tear, modification of the following=20 >> >scenarios are not described in the QOS-NSLP: >> >bound and parallel end-to-end and end-to-end sessions bound and=20 >> >parallel end-to-end and edge-to-edge sessions bound and parallel=20 >> >end-to-end and end-to-edge sessions >> > >> >* Examples of QOSMs that support end-to-end sessions can be: >> >Intserv like Controlled Load QOSM >> >Intserv like Guaranteed Service QOSM >> > >> >* Examples of QOSMs that can support edge-to-edge sessions can be: >> >RSVP aggregation like QOSM RMD-QOSM >> >interdomain and intra-domain ITU-T RACF QoS model PCN like >> congestion >> >notifictaion and preemption QoS model. >> >RSVP-TE like QOSM >> > >> >* Examples of QOSMs that can support end-to-edge sessions: >> >IEEE 802.16 >> > >> >The reason of this is that the QOS-NSLP does not go into lot >> of details >>=20 >> >with any local node dependent functions, including QOSM >> functionality, >> >security and AAA interactions. >>=20 >> At the end of the day, a standard QoS NSLP node should be able to be=20 >> re-used with any QoSM and work. If a QoSM makes special=20 >optimizations,=20 >> then it needs to do 1 of 2 things: >>=20 >> 1) Make the optimizations optional, and have a fallback to the=20 >> standard >> message processing rules defined in the QoS NSLP. >> 2) The QoSM needs to make a QoS NSLP extension, which is a standards=20 >> track >> document. >>=20 >> I cannot see how we get any interoperability otherwise. >>=20 >> John >>=20 > > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Feb 06 17:39:37 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEYxV-0007N0-UR; Tue, 06 Feb 2007 17:38:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEYxU-0007Mk-M1 for nsis@ietf.org; Tue, 06 Feb 2007 17:38:40 -0500 Received: from mclmx.mail.saic.com ([149.8.64.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HEYxU-0002W5-41 for nsis@ietf.org; Tue, 06 Feb 2007 17:38:40 -0500 Received: from 0015-its-ieg01.mail.saic.com ([149.8.64.21] [149.8.64.21]) by mclmx.mail.saic.com; Tue, 6 Feb 2007 17:38:31 -0500 Received: from 0015-its-exbh02.us.saic.com ([10.43.229.22]) by 0015-its-ieg01.mail.saic.com (SMSSMTP 4.0.5.66) with SMTP id M2007020617383129682 ; Tue, 06 Feb 2007 17:38:31 -0500 Received: from 0591-ITS-EXMP02.us.saic.com ([10.42.81.248]) by 0015-its-exbh02.us.saic.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 6 Feb 2007 17:38:31 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [NSIS] QSPEC2: State machine text part in QSPEC I-D Date: Tue, 6 Feb 2007 17:37:50 -0500 Message-Id: <62D92A9A02BCC845B202323D49A48426E1CFD9@0591-ITS-EXMP02.us.saic.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] QSPEC2: State machine text part in QSPEC I-D Thread-Index: AcdJ9rcBvdCriOehRVaR6h7+UByyLwAFkV0AAAIrkhAAA/ixIAABtYlAAATC2Y4= References: <071568CA7B789D4AA170CEF8C9613B4F247279@daebe103.NOE.Nokia.com><9473683187ADC049A855ED2DA739ABCA0DDC81A2@KCCLUST06EVS1.ugd.att.com> <071568CA7B789D4AA170CEF8C9613B4F2474FF@daebe103.NOE.Nokia.com> From: "Roy, Radhika R." To: , , , X-OriginalArrivalTime: 06 Feb 2007 22:38:31.0977 (UTC) FILETIME=[877BA190:01C74A3F] X-Spam-Score: 0.5 (/) X-Scan-Signature: be922d419820e291bde1362184dc32fd Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0290790239==" Errors-To: nsis-bounces@ietf.org This is a multi-part message in MIME format. --===============0290790239== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C74A3F.8725AF77" This is a multi-part message in MIME format. ------_=_NextPart_001_01C74A3F.8725AF77 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable John: =20 I also agree with Jerry's proposed text. =20 Radhika ________________________________ From: nsis-bounces@ietf.org on behalf of john.loughney@nokia.com Sent: Tue 2/6/2007 3:21 PM To: gash@att.com; stiemerling@netlab.nec.de; nsis@ietf.org Subject: RE: [NSIS] QSPEC2: State machine text part in QSPEC I-D I think that looks fine. What do others thing about this? John >-----Original Message----- >From: ext ASH, GERALD R (JERRY), ATTLABS [mailto:gash@att.com] >Sent: 06 February, 2007 11:36 >To: Loughney John (Nokia-NRC/PaloAlto); >stiemerling@netlab.nec.de; nsis@ietf.org >Cc: ASH, GERALD R (JERRY), ATTLABS >Subject: RE: [NSIS] QSPEC2: State machine text part in QSPEC I-D > >Hi John, > >How about this text: > >"QOSM specifications may define RMF triggers that cause the >QoS NSLP to run semantics within the underlying QoS NSLP >signaling state and messaging processing rules, as defined in >Section 5.2 of [QoS-SIG]. New QoS NSLP message processing >rules can only be defined in Standards Track extensions to the >QoS NSLP. If a QOSM specification defines triggers that >deviate from existing standard QoS NSLP processing rules (must >be standards track in that case), the fallback for QNEs not >supporting that QOSM is to use the standard QoS NSLP state >transition/message processing rules." > >Is that consistent with your proposal? > >Thanks, >Jerry > >-----Original Message----- >From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] >Sent: Tuesday, February 06, 2007 12:44 PM >To: ASH, GERALD R (JERRY), ATTLABS; stiemerling@netlab.nec.de; >nsis@ietf.org >Subject: RE: [NSIS] QSPEC2: State machine text part in QSPEC I-D > >Jerry, > >I was thinking of text along the lines of the following: > > QoSMs define the RMF triggers for the underlying QoS NSLP and > GIST signaling state. A QoSM works with the messaging=20 >processing rules of the QoS NSLP (defined in section 5.2). > If the QoSM defines new QoS NSLP processing rules, the QoSM=20 >MUST define a fallback to the standard QoS NSLP processing=20 >rules. New QoS NSLP message processing rules can only defined > in Standards Track extensions to the QoS NSLP. > >Does this make sense? > >John > >>-----Original Message----- >>From: ext ASH, GERALD R (JERRY), ATTLABS [mailto:gash@att.com] >>Sent: 06 February, 2007 08:42 >>To: Martin Stiemerling; nsis >>Cc: ASH, GERALD R (JERRY), ATTLABS >>Subject: RE: [NSIS] QSPEC2: State machine text part in QSPEC I-D >> >>Hi Martin, >> >>I agree with your clarified text, slightly edited here: >> >>"RMF/QOSMs cannot change the semantics and thus the state machine of >>the underlying QoS NSLP and GIST (a standards track document is >>required for doing so), although RMF/QOSMs can send triggers >to the QoS >>NSLP that cause the QoS NSLP to run its semantics." >> >>Thanks, >>Regards, >>Jerry >> >>-----Original Message----- >>From: Martin Stiemerling [mailto:stiemerling@netlab.nec.de] >>Sent: Tuesday, February 06, 2007 8:55 AM >>To: nsis >>Subject: [NSIS] QSPEC2: State machine text part in QSPEC I-D >> >>Well, I have not yet seen consensus about this issue. >> >>Georgios proposed this text: >> >>"QOSMs all utilize the state machines of the underlying NSIS >protocols >>and are not expected to re-define or extend these in any way. Note >>that a QOSM can however, extend the RMF triggers to/from the QOS-NSLP >>functionality, which might affect the QoS-NSLP state machine." >> >>I personally also see that sentence 1 and 2 are contradicting each >>other at least partially. The first sentence is not allowing >to extend >>the state machinery of the underlying NSIS protocols, where >the second >>sentence is is opening the door for extending it. >> >>However, I don't see any real technical issue here, but more >a wording >>issue. >> >>I'm not a good wording expert here, but the base lines seems to be: >>1) QOSMs cannot change the semantics (and thus state machine) of the >>underlying QoS NSLP and GIST. (A standards track document is required >>for doing so). >>2) QOSMs can send triggers to the QoS NSLP. These trigger can >cause the >>QoS NSLP to run its semantics. Basically the " >>affect the QoS- NSLP state machine." is not very clear to >readers. Yes, >>it affects the state machine, but only by giving a reason for an >>initial state transition (e.g., send RESERVE). >> >>So, I'm now waiting for the big, loud scream of what is wrong >here. :-) >> >> Martin >> >>stiemerling@netlab.nec.de >>NEC Europe Limited | >>Registered Office: NEC House, 1 Victoria Road, London W3 6BL | >>Registered in England 2832014 >> >> >> >> >>_______________________________________________ >>nsis mailing list >>nsis@ietf.org >>https://www1.ietf.org/mailman/listinfo/nsis >> >>_______________________________________________ >>nsis mailing list >>nsis@ietf.org >>https://www1.ietf.org/mailman/listinfo/nsis >> > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis ------_=_NextPart_001_01C74A3F.8725AF77 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [NSIS] QSPEC2: State machine text part = in QSPEC I-D=0A= =0A= =0A= =0A=
=0A=
John:
=0A=
 
=0A=
I also agree with Jerry's = proposed text.
=0A=
 
=0A=
Radhika
=0A=

=0A=
=0A= From: nsis-bounces@ietf.org on = behalf of john.loughney@nokia.com
Sent: Tue 2/6/2007 3:21 = PM
To: gash@att.com; stiemerling@netlab.nec.de; = nsis@ietf.org
Subject: RE: [NSIS] QSPEC2: State machine text = part in QSPEC I-D

=0A=
=0A=

I think that looks fine. What do others thing about = this?

John

>-----Original Message-----
>From: ext = ASH, GERALD R (JERRY), ATTLABS [mailto:gash@att.com]
>Sent: 06 = February, 2007 11:36
>To: Loughney John = (Nokia-NRC/PaloAlto);
>stiemerling@netlab.nec.de; = nsis@ietf.org
>Cc: ASH, GERALD R (JERRY), ATTLABS
>Subject: = RE: [NSIS] QSPEC2: State machine text part in QSPEC = I-D
>
>Hi John,
>
>How about this = text:
>
>"QOSM specifications may define RMF triggers that = cause the
>QoS NSLP to run semantics within the underlying QoS = NSLP
>signaling state and messaging processing rules, as defined = in
>Section 5.2 of [QoS-SIG].  New QoS NSLP message = processing
>rules can only be defined in Standards Track = extensions to the
>QoS NSLP.  If a QOSM specification defines = triggers that
>deviate from existing standard QoS NSLP processing = rules (must
>be standards track in that case), the fallback for = QNEs not
>supporting that QOSM is to use the standard QoS NSLP = state
>transition/message processing rules."
>
>Is = that consistent with your = proposal?
>
>Thanks,
>Jerry
>
>-----Origina= l Message-----
>From: john.loughney@nokia.com [mailto:john.loughney@nokia.com]
>Sent: Tuesday, February 06, 2007 12:44 PM
>To: ASH, = GERALD R (JERRY), ATTLABS; = stiemerling@netlab.nec.de;
>nsis@ietf.org
>Subject: RE: = [NSIS] QSPEC2: State machine text part in QSPEC = I-D
>
>Jerry,
>
>I was thinking of text along = the lines of the following:
>
> QoSMs define the RMF = triggers for the underlying QoS NSLP and
> GIST signaling = state.  A QoSM works with the messaging 
>processing = rules of the QoS NSLP (defined in section 5.2).
> If the QoSM = defines new QoS NSLP processing rules, the QoSM 
>MUST define = a fallback to the standard QoS NSLP processing 
>rules.  = New QoS NSLP message processing rules can only defined
> in = Standards Track extensions to the QoS NSLP.
>
>Does this = make sense?
>
>John
>
>>-----Original = Message-----
>>From: ext ASH, GERALD R (JERRY), ATTLABS [mailto:gash@att.com]
>>Sent: = 06 February, 2007 08:42
>>To: Martin Stiemerling; = nsis
>>Cc: ASH, GERALD R (JERRY), ATTLABS
>>Subject: = RE: [NSIS] QSPEC2: State machine text part in QSPEC = I-D
>>
>>Hi Martin,
>>
>>I agree = with your clarified text, slightly edited = here:
>>
>>"RMF/QOSMs cannot change the semantics and = thus the state machine of
>>the underlying QoS NSLP and GIST (a = standards track document is
>>required for doing so), although = RMF/QOSMs can send triggers
>to the QoS
>>NSLP that cause = the QoS NSLP to run its = semantics."
>>
>>Thanks,
>>Regards,
>>= ;Jerry
>>
>>-----Original = Message-----
>>From: Martin Stiemerling [mailto:stiemerling@netlab.nec.d= e]
>>Sent: Tuesday, February 06, 2007 8:55 = AM
>>To: nsis
>>Subject: [NSIS] QSPEC2: State machine = text part in QSPEC I-D
>>
>>Well, I have not yet seen = consensus about this issue.
>>
>>Georgios proposed = this text:
>>
>>"QOSMs all utilize the state machines = of the underlying NSIS
>protocols
>>and are not  = expected  to re-define or extend these in any way. = Note
>>that a QOSM can however, extend the RMF triggers to/from = the QOS-NSLP
>>functionality, which might affect the QoS-NSLP = state machine."
>>
>>I personally also see that = sentence 1 and 2 are contradicting each
>>other at least = partially. The first sentence is not allowing
>to = extend
>>the state machinery of the underlying NSIS protocols, = where
>the second
>>sentence is is opening the door for = extending it.
>>
>>However, I don't see any real = technical issue here, but more
>a = wording
>>issue.
>>
>>I'm not a good wording = expert here, but the base lines seems to be:
>>1) QOSMs cannot = change the semantics (and thus state machine) of = the
>>underlying QoS NSLP and GIST. (A standards track document = is required
>>for doing so).
>>2) QOSMs can send = triggers to the QoS NSLP. These trigger can
>cause = the
>>QoS NSLP to run its semantics. Basically the = "
>>affect the QoS- NSLP state machine." is not very clear = to
>readers. Yes,
>>it affects the state machine, but = only by giving a reason for an
>>initial state transition = (e.g., send RESERVE).
>>
>>So, I'm now waiting for the = big, loud scream of what is wrong
>here. = :-)
>>
>>   = Martin
>>
>>stiemerling@netlab.nec.de
>>NEC = Europe Limited |
>>Registered Office: NEC House, 1 Victoria = Road, London W3 6BL |
>>Registered in England = 2832014
>>
>>
>>
>>
>>______= _________________________________________
>>nsis mailing = list
>>nsis@ietf.org
>>https://www1.ietf.or= g/mailman/listinfo/nsis
>>
>>______________________= _________________________
>>nsis mailing = list
>>nsis@ietf.org
>>https://www1.ietf.or= g/mailman/listinfo/nsis
>>
>

__________________= _____________________________
nsis mailing = list
nsis@ietf.org
https://www1.ietf.or= g/mailman/listinfo/nsis

------_=_NextPart_001_01C74A3F.8725AF77-- --===============0290790239== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis --===============0290790239==-- From nsis-bounces@ietf.org Wed Feb 07 05:44:47 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEkHS-0008CI-Dd; Wed, 07 Feb 2007 05:44:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEkHR-0008Be-7Z for nsis@ietf.org; Wed, 07 Feb 2007 05:44:01 -0500 Received: from rotterdam.ewi.utwente.nl ([130.89.10.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HEkHP-0006uq-Nq for nsis@ietf.org; Wed, 07 Feb 2007 05:44:01 -0500 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by rotterdam.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id l17AhLof002664; Wed, 7 Feb 2007 11:43:29 +0100 (MET) From: "Georgios Karagiannis" To: , , References: <787619A9-74F7-4154-A617-4F829AF92780@netlab.nec.de> <004701c749ff$5d1f02b0$4c0d5982@dynamic.ewi.utwente.nl> <071568CA7B789D4AA170CEF8C9613B4F247280@daebe103.NOE.Nokia.com> Subject: RE: [NSIS] QSPEC2: State machine text part in QSPEC I-D Date: Wed, 7 Feb 2007 11:43:39 +0100 Message-ID: <000101c74aa4$d858f8f0$4c0d5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: <071568CA7B789D4AA170CEF8C9613B4F247280@daebe103.NOE.Nokia.com> Thread-Index: AcdJ9rKRGLk+Tk2vSSusagAwGn8wdgAB1LigAAYXT6AAIz9ncA== X-Spam-Score: 0.3 () FVGT_s_OBFU_Q1 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (rotterdam.ewi.utwente.nl [130.89.10.5]); Wed, 07 Feb 2007 11:43:29 +0100 (MET) X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi John Please see in line! > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > Sent: dinsdag 6 februari 2007 18:45 > To: karagian@cs.utwente.nl; stiemerling@netlab.nec.de; nsis@ietf.org > Subject: RE: [NSIS] QSPEC2: State machine text part in QSPEC I-D > > Georgios, > > You raise the following points below: > > > >I think that you have emphasized what I was thinking of. > >However, note that these RMF triggers are internal triggers and > >according to the NSIS concepts they should be able to initiate and > >maintain the unidirectional/bidirectional and sender/receiver > >reservation intiation, refresh, tear, modification of: > > * bound and parallel end-to-end and end-to-end sessions > > * bound and parallel end-to-end and edge-to-edge sessions > > * bound and parallel end-to-end and end-to-edge sessions > > > >* Examples of QOSMs that support end-to-end sessions can be: > > ** Intserv like Controlled Load QOSM > > ** Intserv like Guaranteed Service QOSM > > > >* Examples of QOSMs that can support edge-to-edge sessions can be: > > ** RSVP aggregation like QOSM > > ** RMD-QOSM > > ** interdomain and intra-domain ITU-T RACF QoS model > > ** PCN like congestion notifictaion and preemption QoS model. > > ** RSVP-TE like QOSM > > > >* Examples of QOSMs that can support end-to-edge sessions: > > ** IEEE 802.16 > > However, do you feel that the current QoS NSLP currently > limits any of the above? > If not, then I think we are done. If it does, we need to > either fix or extend the QoS NSLP to meet your concerns. The > QoSMs are not the place to extend the QoS NSLP. If you consider that the two following points MUST be satisfied then I I think that not all the NSIS concepts listed above can be supported by the QoS-NSLP state machine: * the reaction of the QOS-NSLP caused by RMF triggers is considered to be a part of the QOS-NSLP state machine * the QOSM is allowed to specify RMD triggers but these RMF triggers should not modify the QoS-NSLP state machine (which includes the reaction of the QoS-NSLP caused by RMF triggers) The reason of this is that has been considered from the beginning that the QOS-NSLP does not go into lot of details with any local node dependent functions, including QOSM functionality and RMF triggers, security and AAA interactions. Best Regards, Georgios > > John > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Feb 07 06:00:45 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEkWu-0006Uk-7a; Wed, 07 Feb 2007 06:00:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEkWt-0006Uf-5g for nsis@ietf.org; Wed, 07 Feb 2007 05:59:59 -0500 Received: from rotterdam.ewi.utwente.nl ([130.89.10.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HEkWr-0005Bm-KD for nsis@ietf.org; Wed, 07 Feb 2007 05:59:59 -0500 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by rotterdam.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id l17AxLS5003441; Wed, 7 Feb 2007 11:59:31 +0100 (MET) From: "Georgios Karagiannis" To: , , , References: <071568CA7B789D4AA170CEF8C9613B4F247279@daebe103.NOE.Nokia.com><9473683187ADC049A855ED2DA739ABCA0DDC81A2@KCCLUST06EVS1.ugd.att.com> <071568CA7B789D4AA170CEF8C9613B4F2474FF@daebe103.NOE.Nokia.com> Subject: RE: [NSIS] QSPEC2: State machine text part in QSPEC I-D Date: Wed, 7 Feb 2007 11:59:39 +0100 Message-ID: <000601c74aa7$16b19880$4c0d5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: <071568CA7B789D4AA170CEF8C9613B4F2474FF@daebe103.NOE.Nokia.com> Thread-Index: AcdJ9rcBvdCriOehRVaR6h7+UByyLwAFkV0AAAIrkhAAA/ixIAABtYlAAB5XezA= X-Spam-Score: 0.3 () FVGT_s_OBFU_Q1 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (rotterdam.ewi.utwente.nl [130.89.10.5]); Wed, 07 Feb 2007 11:59:32 +0100 (MET) X-Spam-Score: 0.0 (/) X-Scan-Signature: 93df555cbdbcdae9621e5b95d44b301e Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi John and Jerry I think that the text looks much better and is acceptable for me if you can guarantee that the RMF triggers that are acceptable to you and are considered by you as being compliant to the QoS-NSLP should be able to initiate and maintain the unidirectional/bidirectional and sender/receiver reservation intiation, refresh, tear, modification of: * bound and parallel end-to-end and end-to-end sessions * bound and parallel end-to-end and edge-to-edge sessions * bound and parallel end-to-end and end-to-edge sessions * Examples of QOSMs that support end-to-end sessions can be: ** Intserv like Controlled Load QOSM ** Intserv like Guaranteed Service QOSM * Examples of QOSMs that can support edge-to-edge sessions can be: ** RSVP aggregation like QOSM ** RMD-QOSM ** interdomain and intra-domain ITU-T RACF QoS model ** PCN like congestion notifictaion and preemption QoS model. ** RSVP-TE like QOSM * Examples of QOSMs that can support end-to-edge sessions: ** IEEE 802.16 Best Regards, Georgios > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > Sent: dinsdag 6 februari 2007 21:22 > To: gash@att.com; stiemerling@netlab.nec.de; nsis@ietf.org > Subject: RE: [NSIS] QSPEC2: State machine text part in QSPEC I-D > > I think that looks fine. What do others thing about this? > > John > > >-----Original Message----- > >From: ext ASH, GERALD R (JERRY), ATTLABS [mailto:gash@att.com] > >Sent: 06 February, 2007 11:36 > >To: Loughney John (Nokia-NRC/PaloAlto); stiemerling@netlab.nec.de; > >nsis@ietf.org > >Cc: ASH, GERALD R (JERRY), ATTLABS > >Subject: RE: [NSIS] QSPEC2: State machine text part in QSPEC I-D > > > >Hi John, > > > >How about this text: > > > >"QOSM specifications may define RMF triggers that cause the > QoS NSLP to > >run semantics within the underlying QoS NSLP signaling state and > >messaging processing rules, as defined in Section 5.2 of [QoS-SIG]. > >New QoS NSLP message processing rules can only be defined in > Standards > >Track extensions to the QoS NSLP. If a QOSM specification defines > >triggers that deviate from existing standard QoS NSLP > processing rules > >(must be standards track in that case), the fallback for QNEs not > >supporting that QOSM is to use the standard QoS NSLP state > >transition/message processing rules." > > > >Is that consistent with your proposal? > > > >Thanks, > >Jerry > > > >-----Original Message----- > >From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > >Sent: Tuesday, February 06, 2007 12:44 PM > >To: ASH, GERALD R (JERRY), ATTLABS; stiemerling@netlab.nec.de; > >nsis@ietf.org > >Subject: RE: [NSIS] QSPEC2: State machine text part in QSPEC I-D > > > >Jerry, > > > >I was thinking of text along the lines of the following: > > > > QoSMs define the RMF triggers for the underlying QoS NSLP and GIST > >signaling state. A QoSM works with the messaging processing > rules of > >the QoS NSLP (defined in section 5.2). > > If the QoSM defines new QoS NSLP processing rules, the QoSM MUST > >define a fallback to the standard QoS NSLP processing rules. > New QoS > >NSLP message processing rules can only defined in Standards Track > >extensions to the QoS NSLP. > > > >Does this make sense? > > > >John > > > >>-----Original Message----- > >>From: ext ASH, GERALD R (JERRY), ATTLABS [mailto:gash@att.com] > >>Sent: 06 February, 2007 08:42 > >>To: Martin Stiemerling; nsis > >>Cc: ASH, GERALD R (JERRY), ATTLABS > >>Subject: RE: [NSIS] QSPEC2: State machine text part in QSPEC I-D > >> > >>Hi Martin, > >> > >>I agree with your clarified text, slightly edited here: > >> > >>"RMF/QOSMs cannot change the semantics and thus the state > machine of > >>the underlying QoS NSLP and GIST (a standards track document is > >>required for doing so), although RMF/QOSMs can send triggers > >to the QoS > >>NSLP that cause the QoS NSLP to run its semantics." > >> > >>Thanks, > >>Regards, > >>Jerry > >> > >>-----Original Message----- > >>From: Martin Stiemerling [mailto:stiemerling@netlab.nec.de] > >>Sent: Tuesday, February 06, 2007 8:55 AM > >>To: nsis > >>Subject: [NSIS] QSPEC2: State machine text part in QSPEC I-D > >> > >>Well, I have not yet seen consensus about this issue. > >> > >>Georgios proposed this text: > >> > >>"QOSMs all utilize the state machines of the underlying NSIS > >protocols > >>and are not expected to re-define or extend these in any > way. Note > >>that a QOSM can however, extend the RMF triggers to/from > the QOS-NSLP > >>functionality, which might affect the QoS-NSLP state machine." > >> > >>I personally also see that sentence 1 and 2 are contradicting each > >>other at least partially. The first sentence is not allowing > >to extend > >>the state machinery of the underlying NSIS protocols, where > >the second > >>sentence is is opening the door for extending it. > >> > >>However, I don't see any real technical issue here, but more > >a wording > >>issue. > >> > >>I'm not a good wording expert here, but the base lines seems to be: > >>1) QOSMs cannot change the semantics (and thus state > machine) of the > >>underlying QoS NSLP and GIST. (A standards track document > is required > >>for doing so). > >>2) QOSMs can send triggers to the QoS NSLP. These trigger can > >cause the > >>QoS NSLP to run its semantics. Basically the " > >>affect the QoS- NSLP state machine." is not very clear to > >readers. Yes, > >>it affects the state machine, but only by giving a reason for an > >>initial state transition (e.g., send RESERVE). > >> > >>So, I'm now waiting for the big, loud scream of what is wrong > >here. :-) > >> > >> Martin > >> > >>stiemerling@netlab.nec.de > >>NEC Europe Limited | > >>Registered Office: NEC House, 1 Victoria Road, London W3 6BL | > >>Registered in England 2832014 > >> > >> > >> > >> > >>_______________________________________________ > >>nsis mailing list > >>nsis@ietf.org > >>https://www1.ietf.org/mailman/listinfo/nsis > >> > >>_______________________________________________ > >>nsis mailing list > >>nsis@ietf.org > >>https://www1.ietf.org/mailman/listinfo/nsis > >> > > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Feb 07 06:07:01 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEkd7-0001Zl-CE; Wed, 07 Feb 2007 06:06:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEkd6-0001Zf-7e for nsis@ietf.org; Wed, 07 Feb 2007 06:06:24 -0500 Received: from rotterdam.ewi.utwente.nl ([130.89.10.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HEkd4-0007QX-PI for nsis@ietf.org; Wed, 07 Feb 2007 06:06:24 -0500 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by rotterdam.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id l17B5twu003801; Wed, 7 Feb 2007 12:05:58 +0100 (MET) From: "Georgios Karagiannis" To: , , References: <787619A9-74F7-4154-A617-4F829AF92780@netlab.nec.de><004701c749ff$5d1f02b0$4c0d5982@dynamic.ewi.utwente.nl><071568CA7B789D4AA170CEF8C9613B4F247280@daebe103.NOE.Nokia.com> <000101c74aa4$d858f8f0$4c0d5982@dynamic.ewi.utwente.nl> Subject: RE: [NSIS] QSPEC2: State machine text part in QSPEC I-D Date: Wed, 7 Feb 2007 12:06:13 +0100 Message-ID: <000801c74aa7$fe106670$4c0d5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: <000101c74aa4$d858f8f0$4c0d5982@dynamic.ewi.utwente.nl> Thread-Index: AcdJ9rKRGLk+Tk2vSSusagAwGn8wdgAB1LigAAYXT6AAIz9ncAABDW5A X-Spam-Score: 0.3 () FVGT_s_OBFU_Q1 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (rotterdam.ewi.utwente.nl [130.89.10.5]); Wed, 07 Feb 2007 12:05:58 +0100 (MET) X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi John This e-mail is a duplication of a previous e-mail that I have sent on this issue, but with a minor change: Instead of : "the QOSM is allowed to specify RMD triggers but these RMF triggers .." It should be: "the QOSM is allowed to specify RMF triggers but these RMF triggers .." Sorry about that! In line you can see the right version of my comments! > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > Sent: dinsdag 6 februari 2007 18:45 > To: karagian@cs.utwente.nl; stiemerling@netlab.nec.de; nsis@ietf.org > Subject: RE: [NSIS] QSPEC2: State machine text part in QSPEC I-D > > Georgios, > > You raise the following points below: > > > >I think that you have emphasized what I was thinking of. > >However, note that these RMF triggers are internal triggers and > >according to the NSIS concepts they should be able to initiate and > >maintain the unidirectional/bidirectional and sender/receiver > >reservation intiation, refresh, tear, modification of: > > * bound and parallel end-to-end and end-to-end sessions > > * bound and parallel end-to-end and edge-to-edge sessions > > * bound and parallel end-to-end and end-to-edge sessions > > > >* Examples of QOSMs that support end-to-end sessions can be: > > ** Intserv like Controlled Load QOSM > > ** Intserv like Guaranteed Service QOSM > > > >* Examples of QOSMs that can support edge-to-edge sessions can be: > > ** RSVP aggregation like QOSM > > ** RMD-QOSM > > ** interdomain and intra-domain ITU-T RACF QoS model > > ** PCN like congestion notifictaion and preemption QoS model. > > ** RSVP-TE like QOSM > > > >* Examples of QOSMs that can support end-to-edge sessions: > > ** IEEE 802.16 > > However, do you feel that the current QoS NSLP currently limits any of > the above? > If not, then I think we are done. If it does, we need to either fix or > extend the QoS NSLP to meet your concerns. The QoSMs are not the > place to extend the QoS NSLP. If you consider that the two following points MUST be satisfied then I I think that not all the NSIS concepts listed above can be supported by the QoS-NSLP state machine: * the reaction of the QOS-NSLP caused by RMF triggers is considered to be a part of the QOS-NSLP state machine * the QOSM is allowed to specify RMF triggers but these RMF triggers should not modify the QoS-NSLP state machine (which includes the reaction of the QoS-NSLP caused by RMF triggers) The reason of this is that has been considered from the beginning that the QOS-NSLP does not go into lot of details with any local node dependent functions, including QOSM functionality and RMF triggers, security and AAA interactions. Best Regards, Georgios _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Feb 07 08:16:24 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEmeC-0002mb-TH; Wed, 07 Feb 2007 08:15:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEmeC-0002mD-J1 for nsis@ietf.org; Wed, 07 Feb 2007 08:15:40 -0500 Received: from mail121.messagelabs.com ([216.82.241.195]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HEme7-0002ZC-4p for nsis@ietf.org; Wed, 07 Feb 2007 08:15:40 -0500 X-VirusChecked: Checked X-Env-Sender: gash@att.com X-Msg-Ref: server-12.tower-121.messagelabs.com!1170854134!14780741!1 X-StarScan-Version: 5.5.10.7.1; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 15017 invoked from network); 7 Feb 2007 13:15:34 -0000 Received: from unknown (HELO attrh3i.attrh.att.com) (134.24.146.4) by server-12.tower-121.messagelabs.com with SMTP; 7 Feb 2007 13:15:34 -0000 Received: from attrh.att.com (localhost [127.0.0.1]) by attrh3i.attrh.att.com (8.13.7/8.13.7) with ESMTP id l17DFVcF027097; Wed, 7 Feb 2007 08:15:34 -0500 (EST) Received: from kcclust06evs1.ugd.att.com ([135.38.164.88]) by attrh3i.attrh.att.com (8.13.7/8.13.7) with ESMTP id l17DFM8i026980; Wed, 7 Feb 2007 08:15:22 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] QSPEC2: State machine text part in QSPEC I-D Date: Wed, 7 Feb 2007 07:15:22 -0600 Message-ID: <9473683187ADC049A855ED2DA739ABCA0DDC81AA@KCCLUST06EVS1.ugd.att.com> In-Reply-To: <000601c74aa7$16b19880$4c0d5982@dynamic.ewi.utwente.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] QSPEC2: State machine text part in QSPEC I-D Thread-Index: AcdJ9rcBvdCriOehRVaR6h7+UByyLwAFkV0AAAIrkhAAA/ixIAABtYlAAB5XezAABAc/4A== From: "ASH, GERALD R \(JERRY\), ATTLABS" To: "Georgios Karagiannis" , , , X-Spam-Score: 0.0 (/) X-Scan-Signature: cdb443e3957ca9b4c5b55e78cfcf4b26 Cc: "ASH, GERALD R \(JERRY\), ATTLABS" X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Georgios, All, > -----Original Message----- > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl]=20 > Sent: Wednesday, February 07, 2007 6:00 AM > To: john.loughney@nokia.com; ASH, GERALD R (JERRY), ATTLABS;=20 > stiemerling@netlab.nec.de; nsis@ietf.org > Subject: RE: [NSIS] QSPEC2: State machine text part in QSPEC I-D >=20 > Hi John and Jerry >=20 > I think that the text looks much better and is acceptable for me > if you can guarantee that the RMF triggers that are acceptable to you > and are considered by you as being compliant to the QoS-NSLP=20 > should be able to initiate and maintain the=20 > unidirectional/bidirectional=20 > and sender/receiver reservation initiation, refresh, tear,=20 > modification of: > * bound and parallel end-to-end and end-to-end sessions > * bound and parallel end-to-end and edge-to-edge sessions > * bound and parallel end-to-end and end-to-edge sessions >=20 > * Examples of QOSMs that support end-to-end sessions can be: > ** Intserv like Controlled Load QOSM > ** Intserv like Guaranteed Service QOSM >=20 > * Examples of QOSMs that can support edge-to-edge sessions can be: > ** RSVP aggregation like QOSM > ** RMD-QOSM > ** interdomain and intra-domain ITU-T RACF QoS model > ** PCN like congestion notification and preemption QoS model. > ** RSVP-TE like QOSM >=20 > * Examples of QOSMs that can support end-to-edge sessions:=20 > ** IEEE 802.16=20 You have said in your previous message: "If you consider that the two following points MUST be satisfied then I think that not all the NSIS concepts listed above can be supported by the QoS-NSLP state machine: * the reaction of the QOS-NSLP caused by RMF triggers is considered to be a part of the QOS-NSLP state machine * the QOSM is allowed to specify RMD triggers but these RMF triggers should not modify the QoS-NSLP state machine (which includes the reaction of the QoS-NSLP caused by RMF triggers)" If that is the case then as John said: "(If) the current QoS NSLP currently limits any of the above..., we need to either fix or extend the QoS NSLP to meet your concerns." I agree with John. The QSPEC draft is not the place to extend the QoS NSLP. Please propose any changes/extensions to the QoS NSLP document you feel are necessary. Jerry >=20 > Best Regards, > Georgios >=20 >=20 > > -----Original Message----- > > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com]=20 > > Sent: dinsdag 6 februari 2007 21:22 > > To: gash@att.com; stiemerling@netlab.nec.de; nsis@ietf.org > > Subject: RE: [NSIS] QSPEC2: State machine text part in QSPEC I-D > >=20 > > I think that looks fine. What do others thing about this? > >=20 > > John=20 > >=20 > > >-----Original Message----- > > >From: ext ASH, GERALD R (JERRY), ATTLABS [mailto:gash@att.com] > > >Sent: 06 February, 2007 11:36 > > >To: Loughney John (Nokia-NRC/PaloAlto); stiemerling@netlab.nec.de;=20 > > >nsis@ietf.org > > >Cc: ASH, GERALD R (JERRY), ATTLABS > > >Subject: RE: [NSIS] QSPEC2: State machine text part in QSPEC I-D > > > > > >Hi John, > > > > > >How about this text: > > > > > >"QOSM specifications may define RMF triggers that cause the=20 > > QoS NSLP to=20 > > >run semantics within the underlying QoS NSLP signaling state and=20 > > >messaging processing rules, as defined in Section 5.2 of=20 > > >[QoS-SIG]. =20 > > >New QoS NSLP message processing rules can only be defined in=20 > > Standards=20 > > >Track extensions to the QoS NSLP. If a QOSM specification defines=20 > > >triggers that deviate from existing standard QoS NSLP=20 > > processing rules=20 > > >(must be standards track in that case), the fallback for QNEs not=20 > > >supporting that QOSM is to use the standard QoS NSLP state=20 > > >transition/message processing rules." > > > > > >Is that consistent with your proposal? > > > > > >Thanks, > > >Jerry > > > > > >-----Original Message----- > > >From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > > >Sent: Tuesday, February 06, 2007 12:44 PM > > >To: ASH, GERALD R (JERRY), ATTLABS; stiemerling@netlab.nec.de;=20 > > >nsis@ietf.org > > >Subject: RE: [NSIS] QSPEC2: State machine text part in QSPEC I-D > > > > > >Jerry, > > > > > >I was thinking of text along the lines of the following: > > > > > > QoSMs define the RMF triggers for the underlying QoS NSLP=20 > > >and GIST=20 > > >signaling state. A QoSM works with the messaging processing=20 > > >rules of=20 > > >the QoS NSLP (defined in section 5.2). > > > If the QoSM defines new QoS NSLP processing rules, the QoSM MUST=20 > > >define a fallback to the standard QoS NSLP processing rules.=20 > > New QoS=20 > > >NSLP message processing rules can only defined in Standards Track=20 > > >extensions to the QoS NSLP. > > > > > >Does this make sense? > > > > > >John > > > > > >>-----Original Message----- > > >>From: ext ASH, GERALD R (JERRY), ATTLABS [mailto:gash@att.com] > > >>Sent: 06 February, 2007 08:42 > > >>To: Martin Stiemerling; nsis > > >>Cc: ASH, GERALD R (JERRY), ATTLABS > > >>Subject: RE: [NSIS] QSPEC2: State machine text part in QSPEC I-D > > >> > > >>Hi Martin, > > >> > > >>I agree with your clarified text, slightly edited here: > > >> > > >>"RMF/QOSMs cannot change the semantics and thus the state=20 > > >>machine of=20 > > >>the underlying QoS NSLP and GIST (a standards track document is=20 > > >>required for doing so), although RMF/QOSMs can send triggers > > >to the QoS > > >>NSLP that cause the QoS NSLP to run its semantics." > > >> > > >>Thanks, > > >>Regards, > > >>Jerry > > >> > > >>-----Original Message----- > > >>From: Martin Stiemerling [mailto:stiemerling@netlab.nec.de] > > >>Sent: Tuesday, February 06, 2007 8:55 AM > > >>To: nsis > > >>Subject: [NSIS] QSPEC2: State machine text part in QSPEC I-D > > >> > > >>Well, I have not yet seen consensus about this issue. > > >> > > >>Georgios proposed this text: > > >> > > >>"QOSMs all utilize the state machines of the underlying NSIS > > >protocols > > >>and are not expected to re-define or extend these in any=20 > > >>way. Note=20 > > >>that a QOSM can however, extend the RMF triggers to/from=20 > > the QOS-NSLP=20 > > >>functionality, which might affect the QoS-NSLP state machine." > > >> > > >>I personally also see that sentence 1 and 2 are=20 > > >>contradicting each=20 > > >>other at least partially. The first sentence is not allowing > > >>to extend > > >>the state machinery of the underlying NSIS protocols, where > > >>the second > > >>sentence is opening the door for extending it. > > >> > > >>However, I don't see any real technical issue here, but more > > >>a wording > > >>issue. > > >> > > >>I'm not a good wording expert here, but the base lines=20 > > >>seems to be: > > >>1) QOSMs cannot change the semantics (and thus state=20 > > >>machine) of the=20 > > >>underlying QoS NSLP and GIST. (A standards track document=20 > > >>is required=20 > > >>for doing so). > > >>2) QOSMs can send triggers to the QoS NSLP. These trigger can > > >>cause the > > >>QoS NSLP to run its semantics. Basically the " > > >>affect the QoS- NSLP state machine." is not very clear to > > >>readers. Yes, > > >>it affects the state machine, but only by giving a reason for an=20 > > >>initial state transition (e.g., send RESERVE). > > >> > > >>So, I'm now waiting for the big, loud scream of what is wrong > > >>here. :-) > > >> > > >> Martin > > >> > > >>stiemerling@netlab.nec.de > > >>NEC Europe Limited | > > >>Registered Office: NEC House, 1 Victoria Road, London W3 6BL |=20 > > >>Registered in England 2832014 > > >> _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Feb 07 08:58:11 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEnIa-0005vO-TD; Wed, 07 Feb 2007 08:57:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEnIY-0005vG-I3 for nsis@ietf.org; Wed, 07 Feb 2007 08:57:22 -0500 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HEnIX-00056U-06 for nsis@ietf.org; Wed, 07 Feb 2007 08:57:22 -0500 Received: from [10.1.1.109] (mito.netlab.nec.de [195.37.70.39]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 7398E13CF81; Wed, 7 Feb 2007 14:58:15 +0100 (CET) In-Reply-To: <9473683187ADC049A855ED2DA739ABCA0DDC81A2@KCCLUST06EVS1.ugd.att.com> References: <9473683187ADC049A855ED2DA739ABCA0DDC81A2@KCCLUST06EVS1.ugd.att.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <087587EC-D2FD-418B-932B-41C8409FBCFB@netlab.nec.de> Content-Transfer-Encoding: 7bit From: Martin Stiemerling Subject: Re: [NSIS] QSPEC2: State machine text part in QSPEC I-D Date: Wed, 7 Feb 2007 14:57:19 +0100 To: "ASH, GERALD R (JERRY), ATTLABS" X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 Cc: john.loughney@nokia.com, nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org I'm fine with this text! Martin Am 06.02.2007 um 20:35 schrieb ASH, GERALD R (JERRY), ATTLABS: > Hi John, > > How about this text: > > "QOSM specifications may define RMF triggers that cause the QoS > NSLP to > run semantics within the underlying QoS NSLP signaling state and > messaging processing rules, as defined in Section 5.2 of [QoS- > SIG]. New > QoS NSLP message processing rules can only be defined in Standards > Track > extensions to the QoS NSLP. If a QOSM specification defines triggers > that deviate from existing standard QoS NSLP processing rules (must be > standards track in that case), the fallback for QNEs not supporting > that > QOSM is to use the standard QoS NSLP state transition/message > processing > rules." > > Is that consistent with your proposal? > > Thanks, > Jerry > > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > Sent: Tuesday, February 06, 2007 12:44 PM > To: ASH, GERALD R (JERRY), ATTLABS; stiemerling@netlab.nec.de; > nsis@ietf.org > Subject: RE: [NSIS] QSPEC2: State machine text part in QSPEC I-D > > Jerry, > > I was thinking of text along the lines of the following: > > QoSMs define the RMF triggers for the underlying QoS NSLP and > GIST signaling state. A QoSM works with the messaging > processing rules of the QoS NSLP (defined in section 5.2). > If the QoSM defines new QoS NSLP processing rules, the QoSM > MUST define a fallback to the standard QoS NSLP processing > rules. New QoS NSLP message processing rules can only defined > in Standards Track extensions to the QoS NSLP. > > Does this make sense? > > John > >> -----Original Message----- >> From: ext ASH, GERALD R (JERRY), ATTLABS [mailto:gash@att.com] >> Sent: 06 February, 2007 08:42 >> To: Martin Stiemerling; nsis >> Cc: ASH, GERALD R (JERRY), ATTLABS >> Subject: RE: [NSIS] QSPEC2: State machine text part in QSPEC I-D >> >> Hi Martin, >> >> I agree with your clarified text, slightly edited here: >> >> "RMF/QOSMs cannot change the semantics and thus the state >> machine of the underlying QoS NSLP and GIST (a standards track >> document is required for doing so), although RMF/QOSMs can >> send triggers to the QoS NSLP that cause the QoS NSLP to run >> its semantics." >> >> Thanks, >> Regards, >> Jerry >> >> -----Original Message----- >> From: Martin Stiemerling [mailto:stiemerling@netlab.nec.de] >> Sent: Tuesday, February 06, 2007 8:55 AM >> To: nsis >> Subject: [NSIS] QSPEC2: State machine text part in QSPEC I-D >> >> Well, I have not yet seen consensus about this issue. >> >> Georgios proposed this text: >> >> "QOSMs all utilize the state machines of the underlying NSIS >> protocols and are not expected to re-define or extend these >> in any way. Note that a QOSM can however, extend the RMF >> triggers to/from the QOS-NSLP functionality, which might >> affect the QoS-NSLP state machine." >> >> I personally also see that sentence 1 and 2 are contradicting >> each other at least partially. The first sentence is not >> allowing to extend the state machinery of the underlying NSIS >> protocols, where the second sentence is is opening the door >> for extending it. >> >> However, I don't see any real technical issue here, but more a >> wording issue. >> >> I'm not a good wording expert here, but the base lines seems to be: >> 1) QOSMs cannot change the semantics (and thus state machine) >> of the underlying QoS NSLP and GIST. (A standards track >> document is required for doing so). >> 2) QOSMs can send triggers to the QoS NSLP. These trigger can >> cause the QoS NSLP to run its semantics. Basically the " >> affect the QoS- NSLP state machine." is not very clear to >> readers. Yes, it affects the state machine, but only by giving >> a reason for an initial state transition (e.g., send RESERVE). >> >> So, I'm now waiting for the big, loud scream of what is wrong >> here. :-) >> >> Martin >> >> stiemerling@netlab.nec.de >> NEC Europe Limited | >> Registered Office: NEC House, 1 Victoria Road, London W3 6BL | >> Registered in England 2832014 >> >> >> >> >> _______________________________________________ >> nsis mailing list >> nsis@ietf.org >> https://www1.ietf.org/mailman/listinfo/nsis >> >> _______________________________________________ >> nsis mailing list >> nsis@ietf.org >> https://www1.ietf.org/mailman/listinfo/nsis >> stiemerling@netlab.nec.de NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Feb 08 03:47:00 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HF4v0-0006mq-Kh; Thu, 08 Feb 2007 03:46:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HF4uz-0006mi-BC for nsis@ietf.org; Thu, 08 Feb 2007 03:46:13 -0500 Received: from rotterdam.ewi.utwente.nl ([130.89.10.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HF4ux-0003M7-OR for nsis@ietf.org; Thu, 08 Feb 2007 03:46:13 -0500 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by rotterdam.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id l188jXU1027103; Thu, 8 Feb 2007 09:45:44 +0100 (MET) From: "Georgios Karagiannis" To: "'ASH, GERALD R \(JERRY\), ATTLABS'" , , , References: <000601c74aa7$16b19880$4c0d5982@dynamic.ewi.utwente.nl> <9473683187ADC049A855ED2DA739ABCA0DDC81AA@KCCLUST06EVS1.ugd.att.com> Subject: RE: [NSIS] QSPEC2: State machine text part in QSPEC I-D Date: Thu, 8 Feb 2007 09:45:52 +0100 Message-ID: <000401c74b5d$91271d90$4c0d5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcdJ9rcBvdCriOehRVaR6h7+UByyLwAFkV0AAAIrkhAAA/ixIAABtYlAAB5XezAABAc/4AApzH4Q In-Reply-To: <9473683187ADC049A855ED2DA739ABCA0DDC81AA@KCCLUST06EVS1.ugd.att.com> X-Spam-Score: 0.3 () FVGT_s_OBFU_Q1 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (rotterdam.ewi.utwente.nl [130.89.10.5]); Thu, 08 Feb 2007 09:45:45 +0100 (MET) X-Spam-Score: 0.0 (/) X-Scan-Signature: 03fb21b15d5177c512a4caa19876f30a Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Jerry Thanks, I assume then that you agree then that we should anything possible to ensure that NSIS supports should be able to initiate and maintain the unidirectional/bidirectional and sender/receiver reservation initiation, refresh, tear, modification of: * bound and parallel end-to-end and end-to-end sessions * bound and parallel end-to-end and edge-to-edge sessions * bound and parallel end-to-end and end-to-edge sessions * Examples of QOSMs that support end-to-end sessions can be: ** Intserv like Controlled Load QOSM ** Intserv like Guaranteed Service QOSM * Examples of QOSMs that can support edge-to-edge sessions can be: ** RSVP aggregation like QOSM ** RMD-QOSM ** interdomain and intra-domain ITU-T RACF QoS model ** PCN like congestion notification and preemption QoS model. ** RSVP-TE like QOSM * Examples of QOSMs that can support end-to-edge sessions: ** IEEE 802.16 As being co-editor of the QoS-NSLP draft I will do anything possible to assure this! Best Regards, Georgios > -----Original Message----- > From: ASH, GERALD R (JERRY), ATTLABS [mailto:gash@att.com] > Sent: woensdag 7 februari 2007 14:15 > To: Georgios Karagiannis; john.loughney@nokia.com; > stiemerling@netlab.nec.de; nsis@ietf.org > Cc: ASH, GERALD R (JERRY), ATTLABS > Subject: RE: [NSIS] QSPEC2: State machine text part in QSPEC I-D > > Georgios, All, > > > -----Original Message----- > > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > > Sent: Wednesday, February 07, 2007 6:00 AM > > To: john.loughney@nokia.com; ASH, GERALD R (JERRY), ATTLABS; > > stiemerling@netlab.nec.de; nsis@ietf.org > > Subject: RE: [NSIS] QSPEC2: State machine text part in QSPEC I-D > > > > Hi John and Jerry > > > > I think that the text looks much better and is acceptable for me if > > you can guarantee that the RMF triggers that are acceptable > to you and > > are considered by you as being compliant to the QoS-NSLP should be > > able to initiate and maintain the unidirectional/bidirectional and > > sender/receiver reservation initiation, refresh, tear, modification > > of: > > * bound and parallel end-to-end and end-to-end sessions > > * bound and parallel end-to-end and edge-to-edge sessions > > * bound and parallel end-to-end and end-to-edge sessions > > > > * Examples of QOSMs that support end-to-end sessions can be: > > ** Intserv like Controlled Load QOSM > > ** Intserv like Guaranteed Service QOSM > > > > * Examples of QOSMs that can support edge-to-edge sessions can be: > > ** RSVP aggregation like QOSM > > ** RMD-QOSM > > ** interdomain and intra-domain ITU-T RACF QoS model > > ** PCN like congestion notification and preemption QoS model. > > ** RSVP-TE like QOSM > > > > * Examples of QOSMs that can support end-to-edge sessions: > > ** IEEE 802.16 > > You have said in your previous message: > "If you consider that the two following points MUST be > satisfied then I think that not all the NSIS concepts listed > above can be supported by the QoS-NSLP state machine: > * the reaction of the QOS-NSLP caused by RMF triggers is > considered to be a part of the QOS-NSLP state machine > * the QOSM is allowed to specify RMD triggers but these RMF > triggers should not modify the QoS-NSLP state machine (which > includes the reaction of the QoS-NSLP caused by RMF triggers)" > > If that is the case then as John said: > "(If) the current QoS NSLP currently limits any of the > above..., we need to either fix or extend the QoS NSLP to > meet your concerns." > > I agree with John. The QSPEC draft is not the place to > extend the QoS NSLP. Please propose any changes/extensions > to the QoS NSLP document you feel are necessary. > > Jerry > > > > > Best Regards, > > Georgios > > > > > > > -----Original Message----- > > > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > > > Sent: dinsdag 6 februari 2007 21:22 > > > To: gash@att.com; stiemerling@netlab.nec.de; nsis@ietf.org > > > Subject: RE: [NSIS] QSPEC2: State machine text part in QSPEC I-D > > > > > > I think that looks fine. What do others thing about this? > > > > > > John > > > > > > >-----Original Message----- > > > >From: ext ASH, GERALD R (JERRY), ATTLABS [mailto:gash@att.com] > > > >Sent: 06 February, 2007 11:36 > > > >To: Loughney John (Nokia-NRC/PaloAlto); > stiemerling@netlab.nec.de; > > > >nsis@ietf.org > > > >Cc: ASH, GERALD R (JERRY), ATTLABS > > > >Subject: RE: [NSIS] QSPEC2: State machine text part in QSPEC I-D > > > > > > > >Hi John, > > > > > > > >How about this text: > > > > > > > >"QOSM specifications may define RMF triggers that cause the > > > QoS NSLP to > > > >run semantics within the underlying QoS NSLP signaling state and > > > >messaging processing rules, as defined in Section 5.2 of > [QoS-SIG]. > > > >New QoS NSLP message processing rules can only be defined in > > > Standards > > > >Track extensions to the QoS NSLP. If a QOSM > specification defines > > > >triggers that deviate from existing standard QoS NSLP > > > processing rules > > > >(must be standards track in that case), the fallback for > QNEs not > > > >supporting that QOSM is to use the standard QoS NSLP state > > > >transition/message processing rules." > > > > > > > >Is that consistent with your proposal? > > > > > > > >Thanks, > > > >Jerry > > > > > > > >-----Original Message----- > > > >From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > > > >Sent: Tuesday, February 06, 2007 12:44 PM > > > >To: ASH, GERALD R (JERRY), ATTLABS; stiemerling@netlab.nec.de; > > > >nsis@ietf.org > > > >Subject: RE: [NSIS] QSPEC2: State machine text part in QSPEC I-D > > > > > > > >Jerry, > > > > > > > >I was thinking of text along the lines of the following: > > > > > > > > QoSMs define the RMF triggers for the underlying QoS NSLP and > > > >GIST signaling state. A QoSM works with the messaging > processing > > > >rules of the QoS NSLP (defined in section 5.2). > > > > If the QoSM defines new QoS NSLP processing rules, the > QoSM MUST > > > >define a fallback to the standard QoS NSLP processing rules. > > > New QoS > > > >NSLP message processing rules can only defined in > Standards Track > > > >extensions to the QoS NSLP. > > > > > > > >Does this make sense? > > > > > > > >John > > > > > > > >>-----Original Message----- > > > >>From: ext ASH, GERALD R (JERRY), ATTLABS [mailto:gash@att.com] > > > >>Sent: 06 February, 2007 08:42 > > > >>To: Martin Stiemerling; nsis > > > >>Cc: ASH, GERALD R (JERRY), ATTLABS > > > >>Subject: RE: [NSIS] QSPEC2: State machine text part in QSPEC I-D > > > >> > > > >>Hi Martin, > > > >> > > > >>I agree with your clarified text, slightly edited here: > > > >> > > > >>"RMF/QOSMs cannot change the semantics and thus the > state machine > > > >>of the underlying QoS NSLP and GIST (a standards track > document is > > > >>required for doing so), although RMF/QOSMs can send triggers > > > >to the QoS > > > >>NSLP that cause the QoS NSLP to run its semantics." > > > >> > > > >>Thanks, > > > >>Regards, > > > >>Jerry > > > >> > > > >>-----Original Message----- > > > >>From: Martin Stiemerling [mailto:stiemerling@netlab.nec.de] > > > >>Sent: Tuesday, February 06, 2007 8:55 AM > > > >>To: nsis > > > >>Subject: [NSIS] QSPEC2: State machine text part in QSPEC I-D > > > >> > > > >>Well, I have not yet seen consensus about this issue. > > > >> > > > >>Georgios proposed this text: > > > >> > > > >>"QOSMs all utilize the state machines of the underlying NSIS > > > >protocols > > > >>and are not expected to re-define or extend these in any way. > > > >>Note that a QOSM can however, extend the RMF triggers to/from > > > the QOS-NSLP > > > >>functionality, which might affect the QoS-NSLP state machine." > > > >> > > > >>I personally also see that sentence 1 and 2 are > contradicting each > > > >>other at least partially. The first sentence is not allowing to > > > >>extend the state machinery of the underlying NSIS > protocols, where > > > >>the second sentence is opening the door for extending it. > > > >> > > > >>However, I don't see any real technical issue here, but more a > > > >>wording issue. > > > >> > > > >>I'm not a good wording expert here, but the base lines seems to > > > >>be: > > > >>1) QOSMs cannot change the semantics (and thus state > > > >>machine) of the > > > >>underlying QoS NSLP and GIST. (A standards track document is > > > >>required for doing so). > > > >>2) QOSMs can send triggers to the QoS NSLP. These trigger can > > > >>cause the QoS NSLP to run its semantics. Basically the " > > > >>affect the QoS- NSLP state machine." is not very clear > to readers. > > > >>Yes, it affects the state machine, but only by giving a > reason for > > > >>an initial state transition (e.g., send RESERVE). > > > >> > > > >>So, I'm now waiting for the big, loud scream of what is wrong > > > >>here. :-) > > > >> > > > >> Martin > > > >> > > > >>stiemerling@netlab.nec.de > > > >>NEC Europe Limited | > > > >>Registered Office: NEC House, 1 Victoria Road, London W3 6BL | > > > >>Registered in England 2832014 > > > >> > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Feb 08 04:01:18 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HF58l-0005hc-Op; Thu, 08 Feb 2007 04:00:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HF58k-0005hU-8F for nsis@ietf.org; Thu, 08 Feb 2007 04:00:26 -0500 Received: from rotterdam.ewi.utwente.nl ([130.89.10.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HF58f-0007zy-RB for nsis@ietf.org; Thu, 08 Feb 2007 04:00:26 -0500 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by rotterdam.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id l188xqro027693 for ; Thu, 8 Feb 2007 09:59:57 +0100 (MET) From: "Georgios Karagiannis" To: Date: Thu, 8 Feb 2007 10:00:11 +0100 Message-ID: <000601c74b5f$8d3b7990$4c0d5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcdLX4omEk/vxQ5HTfiO1xW54pQLYw== X-Spam-Score: 0.4 () FVGT_s_OBFU_Q1,FVGT_u_HAS_2LETTERFLDR X-Scanned-By: MIMEDefang 2.52 on 130.89.10.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (rotterdam.ewi.utwente.nl [130.89.10.5]); Thu, 08 Feb 2007 09:59:57 +0100 (MET) X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Subject: [NSIS] Reintroduce QSPEC control information semantics back X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi all I think that we have yet not solved the issue related to the fact that the QSPEC control information has been removed from the QSPEC template draft In my opinion the concept of the QSPEC control information has been removed from the current version of the QSPEC template draft. This concept was included up to the previous version of the QSPEC template draft and it is needed for the situations that this parameter is used for providing signaling support for QSPEC/QOSM specific RMF functions, such as initiation, refresh, release, modification for unidirectional and bi-directional per traffic class RMF reservation states, per flow RMF reservation states, per aggregated RMF reservation states, specified for example, in [RMD-QOSM]. QSPEC control information examples used in RMD-QOSM are: and = , ,, , ,