From daemon@ns.ietf.org Fri Aug 2 00:18:16 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA27029 for ; Fri, 2 Aug 2002 00:18:16 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id AAA11699 for nsis-archive@odin.ietf.org; Fri, 2 Aug 2002 00:19:25 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA10560; Thu, 1 Aug 2002 23:58:44 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA10507 for ; Thu, 1 Aug 2002 23:58:42 -0400 (EDT) Received: from nycsmtp1out.rdc-nyc.rr.com (nycsmtp1out.rdc-nyc.rr.com [24.29.99.226]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA26710 for ; Thu, 1 Aug 2002 23:57:32 -0400 (EDT) Received: from R2D2 (24-90-220-88.nyc.rr.com [24.90.220.88]) by nycsmtp1out.rdc-nyc.rr.com (8.12.1/Road Runner SMTP Server 1.0) with ESMTP id g723vYZi024568 for ; Thu, 1 Aug 2002 23:57:38 -0400 (EDT) Message-ID: <418-2200285235838964@R2D2> From: "LGPro1" To: nsis@ietf.org Date: Thu, 1 Aug 2002 23:58:38 -0400 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id XAA10508 Subject: [NSIS] Time Share Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Interested in Renting or Selling your Timeshare or Vacation Membership? We can help! For a FREE consultation, simply reply with your name and telephone number. Also include the name of your resort. We will be in touch with you shortly! Have a great day! Removal instructions: ************************* To be removed from this list please reply with "remove" in the subject. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Aug 2 16:40:57 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05551 for ; Fri, 2 Aug 2002 16:40:57 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA06897 for nsis-archive@odin.ietf.org; Fri, 2 Aug 2002 16:42:07 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA06209; Fri, 2 Aug 2002 16:30:46 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA06168 for ; Fri, 2 Aug 2002 16:30:42 -0400 (EDT) Received: from localhost.com ([61.174.203.173]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA05124 for ; Fri, 2 Aug 2002 16:29:29 -0400 (EDT) From: emailharvest@email.com Message-Id: <200208022029.QAA05124@ietf.org> Reply-To: emailharvest@email.com To: nsis@ietf.org Date: Sat, 3 Aug 2002 04:30:39 +0800 X-Mailer: QuickSender 1.05 MIME-Version: 1.0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Subject: [NSIS] ADV: Harvest lots of E-mail addresses quickly ! Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: quoted-printable Dear nsis =2C =3CBODY bgColor=3D#ffccff=3E =3CTABLE border=3D0 cellPadding=3D0 cellSpacing=3D0 width=3D475=3E =3CTBODY=3E =3CTR=3E =3CTD align=3Dmiddle vAlign=3Dtop=3E=3C=2FTD=3E=3C=2FTR=3E=3C=2FTBODY=3E=3C=2FTABLE=3E=3CBR=3E =3CTABLE=3E =3CTBODY=3E =3CTR=3E =3CTD width=3D=225%=22=3E=3C=2FTD=3E =3CTD bgColor=3D#b8ecff borderColor=3D#0000ff width=3D=2290%=22=3E=3CFONT color=3D#ff0000 face=3D=22Arial Black=22 size=3D6=3E =3B =3B =3B =3B =3B =3B =3B =3B =3B =3B Want To Harvest A Lot Of Email =3B =3B Addresses In A Very Short Time=3F=3C=2FFONT=3E =3CP=3E=3CB=3E=3CFONT color=3D#0000ff face=3DArial size=3D4=3EEasy Email Searcher=3C=2FFONT=3E=3CFONT color=3D#ff00ff face=3DArial size=3D4=3E =3B is =3B a =3B powerful =3B Email =3B software =3B =3B that =3B harvests general Email lists from mail servers =3B =3B =3C=2FFONT=3E=3CFONT color=3D#0000ff face=3DArial size=3D4=3EEasy Email Searcher =3C=2FFONT=3E=3CFONT color=3D#ff00ff face=3DArial size=3D4=3Ecan get 100=2C000 Email=3C=2FFONT=3E=3C=2FB=3E =3CFONT color=3D#ff00ff face=3DArial size=3D4=3E=3CB=3Eaddresses directly from the Email servers in only one hour! =3B=3C=2FB=3E=3C=2FFONT=3E=3C=2FP=3E =3CUL=3E =3CLI=3E=3CFONT face=3DArial size=3D2=3E=3CB=3E=3CFONT color=3D#0000ff=3EEasy Email Searcher=3C=2FFONT=3E=3C=2FB=3E is a 32 bit Windows Program for e-mail marketing=2E It is intended for easy and convenient search large e-mail address lists from mail servers=2E The program can be operated on Windows 95=2F98=2FME=2F2000 and NT=2E=3C=2FFONT=3E =3CLI=3E=3CFONT face=3DArial size=3D2=3E=3CB=3E=3CFONT color=3D#0000ff=3EEasy Email Searcher=3C=2FFONT=3E =3C=2FB=3Esupport multi-threads =28up to 512 connections=29=2E=3C=2FFONT=3E =3CLI=3E=3CFONT face=3DArial size=3D2=3E=3CB=3E=3CFONT color=3D#0000ff=3EEasy Email Searcher=3C=2FFONT=3E=3C=2FB=3E has the ability =3B to reconnect to the mail server if the server has disconnected and continue the searching at the point where it has been interrupted=2E=3C=2FFONT=3E =3CLI=3E=3CFONT face=3DArial size=3D2=3E=3CB=3E=3CFONT color=3D#0000ff=3EEasy Email Searcher=3C=2FFONT=3E=3C=2FB=3E has an ergonomic interface that is easy to set up and simple to use=2E=3C=2FFONT=3E =3C=2FLI=3E=3C=2FUL=3E =3CP=3E=A1=A1=3CB=3E=3CFONT color=3D#0000ff face=3DArial=3EEasy Email Searcher is an email address searcher and bulk e-mail sender=2E It can verify more than 5500 email addresses per minute at only 56Kbps speed=2E It even allows you send email to valid email address while searching=2E You can save the searching progress and load it to resume work at your convenience=2E All you need to do is just input an email address=2C and press the =22Search=22 button=2E=3C=2FFONT=3E=3C=2FB=3E=3C=2FP=3E =3CP=3E=3CB=3E=3CFONT color=3D#0000ff face=3DArial=3E=3CBR=3E=3C=2FFONT=3E=3Cfont face=3D=22Comic Sans MS=22 size=3D=224=22 color=3D=22#FF00FF=22=3EVery Low Price ! ------- =3B Now=2C =3B The full version of Easy Email Searcher only costs =3C=2Ffont=3E=3Cfont face=3D=22Comic Sans MS=22 size=3D=224=22 color=3D=22#0000FF=22=3E$ 39=2E 95=3C=2Ffont=3E=3C=2FB=3E=3C=2FP=3E =3CP=3E=3CB=3E=3CFONT color=3D#ff0000 face=3DArial size=3D4=3E=3CI=3EClick The Following Link To Download The Demo =3A=3C=2FI=3E=3C=2FFONT=3E=3C=2FB=3E=3C=2FP=3E =3CP=3E=3CB=3E=3CFONT color=3D#ff0000 face=3DArial size=3D4=3E=3CA href=3D=22http=3A=2F=2Fwww=2Ewldinfo=2Ecom=2Fdownload=2Femail=2Fnewees=2Ezip=22=3EDownload Site 1=3C=2FA=3E=3C=2FFONT=3E=3C=2FB=3E=3C=2FP=3E =3CP=3E=3CB=3E=3CFONT color=3D#ff0000 face=3DArial size=3D4=3E=3CA href=3D=22http=3A=2F=2Fbestsoft=2E3322=2Eorg=2Fonlinedown=2Fnewees=2Ezip=22=3EDownload Site 2=3C=2FA=3E =3B =3B =3B =3B =3B =3B =3B =3B =3B =3B =3B =3C=2FFONT=3E=3C=2FB=3E=A1=A1=3CFONT color=3D#0000a0 face=3DArial size=3D3=3E=3CSTRONG=3EIf =3B you can not download this program =2C =3B please copy the following link into your URL =2C and then click =22 Enter=22 on your Computer Keyboard=2E=3C=2FSTRONG=3E=3C=2FFONT=3E=3C=2FP=3E =3CP=3E=3CFONT size=3D2=3E=3CFONT color=3D#0000a0 face=3DArial size=3D3=3E=3CSTRONG=3EHere is the download links=3A=3C=2FSTRONG=3E=3C=2FFONT=3E=3C=2FP=3E =3CDIV=3E =3CP=3Ehttp=3A=2F=2Fwww=2Ewldinfo=2Ecom=2Fdownload=2Femail=2Fnewees=2Ezip=3C=2FP=3E =3CP=3Ehttp=3A=2F=2Fbestsoft=2E3322=2Eorg=2Fonlinedown=2Fnewees=2Ezip=3C=2FP=3E=3C=2FFONT=3E=3C=2FDIV=3E =3CP=3E=3C=2FP=3E=3C=2FTD=3E =3CTD width=3D=225%=22=3E=3C=2FTD=3E=3C=2FTR=3E =3CTR=3E =3CTD width=3D=225%=22=3E=3C=2FTD=3E =3CTD bgColor=3D#0f95de width=3D=2290%=22=3E=3CFONT color=3D#ffffff face=3D=22Verdana=2C Tahoma=2C Helvetica=2C SansSerif=22 size=3D1=3E=3CB=3EDisclaimer=3A=3C=2FB=3E=3CBR=3EWe are strongly against continuously sending unsolicited emails to those who do not wish to receive our special mailings=2E We have attained the services of an independent 3rd party to overlook list management and removal services=2E This is not unsolicited email=2E If you do not wish to receive further mailings=2C please click this link =3CA href=3D=22 mailto=3Aremoval=40btamail=2Enet=2Ecn =22 target=3D=5Fblank=3E=3CFONT color=3D#fdd32a=3E=3CB=3Emailto=3Aremoval=40btamail=2Enet=2Ecn =3C=2FB=3E=3C=2FFONT=3E=3C=2FA=3E=2E =3B=3C=2FFONT=3E=3CB=3E=3CFONT class=3Ddisclaimer color=3D#000080 face=3DArial=3E=3CBR=3EThis message is a commercial advertisement=2E It is compliant with all federal and state laws regarding email messages including the California Business and Professions Code=2E We have provided the subject line =22ADV=22 to provide you notification that this is a commercial advertisement for persons over 18yrs old=2E=3C=2FFONT=3E=3C=2FB=3E=3C=2FTD=3E =3CTD width=3D=225%=22=3E=3C=2FTD=3E=3C=2FTR=3E=3C=2FTBODY=3E=3C=2FTABLE=3E =3CBR=3E _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Sun Aug 4 12:51:58 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08648 for ; Sun, 4 Aug 2002 12:51:58 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA28254 for nsis-archive@odin.ietf.org; Sun, 4 Aug 2002 12:53:08 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA27791; Sun, 4 Aug 2002 12:36:14 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA27760 for ; Sun, 4 Aug 2002 12:36:12 -0400 (EDT) Received: from mail.icu.ac.kr (mail.icu.ac.kr [210.107.128.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08097 for ; Sun, 4 Aug 2002 12:35:00 -0400 (EDT) Received: from jkchoi (jkchoi.icu.ac.kr [210.107.133.60]) by mail.icu.ac.kr (8.11.6/8.11.6) with SMTP id g74GdVQ26367; Mon, 5 Aug 2002 01:39:40 +0900 (KST) Message-ID: <007601c23bd6$13bbcc70$3c856bd2@jkchoi> From: "jkchoi" To: , "Shahrier, Sharif M." Cc: References: <180970.1028022659@[192.168.102.207]> Subject: Re: [NSIS] question for clarification Date: Mon, 5 Aug 2002 01:43:26 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by optimus.ietf.org id MAA27761 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit I just read this mail. It is me to raise a question for bi-directional QoS signaling at nsis WG. For the further development of "A Framework for Bi-Directional QoS Signaling" presented at Yokohama meeting, it needs to check the existing activities at mpls WG and ccamp WG to their signaling protocols (If time is available, check the signaling protocols developed by ITU-T SG13 and ISO/OSI etc. even though it is not for IP network. You can find some helpful mechanism to use for IP network.) It notes that - uni-directional signaling on LDP/CR-LDP and RSVP/RSVP-TE for MPLS network - on-going for bi-directional signaling on RSVP-TE and CR-LDP extension for GMPLS network. It also notes that most of the ATM network and most of data network use the bi-directional signaling in general. The author of draft-shahrier-nsis-framework-00.txt may first hear some backgrounds why the mpls WG choose uni-directional signaling. It was taken with some considerations of physical media type, end user applications, network provider operation and maintenance, and system implementation, etc. In addition, routing algorithm and forwarding logic of IP router are another factors for decision. In order to make a decision for bi-directional signaling at nsis WG, it may be needed to check the related technical issues including end user requirements, network operator requirements and system designer requirements. It may help to clarify the needs and the work scopes of that draft. Specifically, it may need to find target signaling objectives according to layered concept, service provisioning rule, gegographical view, network dimensioning and physical coverage, etc. In my personal views (since I am much oriented on telco- viewpoints), I don't clearly understand what is the real objectives of this draft ? What is the target application ? Is that only for a specific end appllication, otherwise is it generally both for end user and network provider ? I think that the author may find some critical problems on the existing activities of bi-directional signaling at other group or other body. Why new bi-directional signaling protocol is needed ? It may be reasonable to wait until the nsis WG finish the requirements even though I don't follow what is going on in detail yet. In general, different and individual signaling protocols are needed when end applications and intermediate network elements are different on operational rule, service provisioning, and control mechanism including resource reservation, etc. If a number of signaling requirements merge into one set of signaling protocol, some trade-offs among benefits, cost, and performance must be analyzed. It notes that the trade-off analyses are not just focusing on technical matters. Jun Kyun Choi ----- Original Message ----- From: "Marcus Brunner" To: "Shahrier, Sharif M." Cc: Sent: Tuesday, July 30, 2002 4:50 PM Subject: RE: [NSIS] question for clarification > Whach the ccamp WG > MArcus > > --On Montag, 29. Juli 2002 14:49 -0400 "Shahrier, Sharif M." > wrote: > > > Marcus, > > > > Thanks for the information. Would you have the link to this draft > > that you can send to us? Thanks. > > > > Sharif. > > > > > > -----Original Message----- > > From: Marcus Brunner [mailto:brunner@ccrle.nec.de] > > Sent: Thursday, July 25, 2002 6:36 AM > > To: Shahrier, Sharif M. > > Cc: 'nsis@ietf.org' > > Subject: Re: [NSIS] question for clarification > > > > Sharif, > > > > RSVP-TE with GMPLS extension is a signaling protocol for setting up GMPLS > > pathes, which might be optical or what ever. There one of the extension > > is that they allow for bi-directional path setup. > > > > Marcus > > > > --On Dienstag, 23. Juli 2002 15:16 -0400 "Shahrier, Sharif M." > > wrote: > > > >> Following my presentation of the framework draft at Yokohama, a person > >> had asked me whether our approach was the same as the "bi-directional > >> GMPLS" that the MPLS WG had worked on. > >> > >> I am not sure what this is, and would appreciate if that person can > >> provide us with more information. > >> Thanks. > >> > >> Sharif. > >> _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Mon Aug 5 05:09:31 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05501 for ; Mon, 5 Aug 2002 05:09:30 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA19689 for nsis-archive@odin.ietf.org; Mon, 5 Aug 2002 05:09:54 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA19195; Mon, 5 Aug 2002 05:00:36 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA19163 for ; Mon, 5 Aug 2002 05:00:34 -0400 (EDT) Received: from tokyo.ccrle.nec.de (tokyo.ccrle.nec.de [195.37.70.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05392 for ; Mon, 5 Aug 2002 04:59:17 -0400 (EDT) Received: from imap.heidelberg.ccrle.nec.de (imap [192.168.102.11]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g758xoU65842; Mon, 5 Aug 2002 10:59:50 +0200 (CEST) (envelope-from brunner@ccrle.nec.de) Received: from [192.168.102.207] (marcus.heidelberg.ccrle.nec.de [192.168.102.207]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 6BF2353DCE; Mon, 5 Aug 2002 10:59:48 +0200 (CEST) Date: Mon, 05 Aug 2002 10:59:49 +0200 From: Marcus Brunner Reply-To: brunner@ccrle.nec.de To: jkchoi , "Shahrier, Sharif M." Cc: nsis@ietf.org Subject: Re: [NSIS] question for clarification Message-ID: <263008906.1028545189@[192.168.102.207]> In-Reply-To: <007601c23bd6$13bbcc70$3c856bd2@jkchoi> References: <007601c23bd6$13bbcc70$3c856bd2@jkchoi> X-Mailer: Mulberry/2.2.0 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 7bit Concerning bi-directional, In the requirements draft we currently have -------------- 5.7.4 Uni / bi-directional reservation Both unidirectional as well as bi-direction reservations must be possible. With bi-directional reservations we mean here reservations having the same end-points. But the path in the two directions does not need to be the same. The goal of a bi-directional reservation is mainly an optimization in terms of setup delay. There is no requirements on constrains such as use the same data path etc. ------------- It is important to note that we explicity mention that bi-directional is meant to have only the same end-points, but does not need to follow the same path. This is follwing the Internet Routing ARchitecture. Any constraint to force bi-directional reservations on the same path are very complex and not workable in many cases. Marcus --On Montag, 5. August 2002 01:43 +0900 jkchoi wrote: > I just read this mail. It is me to raise a question for bi-directional > QoS signaling at nsis WG. > > For the further development of "A Framework for Bi-Directional QoS > Signaling" presented at Yokohama meeting, it needs to check the existing > activities at mpls WG and ccamp WG to their signaling protocols (If time > is available, check the signaling protocols developed by ITU-T SG13 and > ISO/OSI etc. even though it is not for IP network. You can find some > helpful mechanism to use for IP network.) > > It notes that > > - uni-directional signaling on LDP/CR-LDP and RSVP/RSVP-TE for MPLS > network - on-going for bi-directional signaling on RSVP-TE and CR-LDP > extension for GMPLS network. > > It also notes that most of the ATM network and most of data network use > the bi-directional signaling in general. > > The author of draft-shahrier-nsis-framework-00.txt may first hear some > backgrounds why the mpls WG choose uni-directional signaling. It was > taken with some considerations of physical media type, end user > applications, network provider operation and maintenance, and system > implementation, etc. In addition, routing algorithm and forwarding logic > of IP router are another factors for decision. In order to make a > decision for bi-directional signaling at nsis WG, it may be needed to > check the related technical issues including end user requirements, > network operator requirements and system designer requirements. It may > help to clarify the needs and the work scopes of that draft. > Specifically, it may need to find target signaling objectives according > to layered concept, service provisioning rule, gegographical view, > network dimensioning and physical coverage, etc. > > In my personal views (since I am much oriented on telco- viewpoints), I > don't clearly understand what is the real objectives of this draft ? What > is the target application ? Is that only for a specific end appllication, > otherwise is it generally both for end user and network provider ? I > think that the author may find some critical problems on the existing > activities of bi-directional signaling at other group or other body. Why > new bi-directional signaling protocol is needed ? > It may be reasonable to wait until the nsis WG finish the requirements > even though I don't follow what is going on in detail yet. > > In general, different and individual signaling protocols are needed when > end applications and intermediate network elements are different on > operational rule, service provisioning, and control mechanism including > resource reservation, etc. If a number of signaling requirements merge > into one set of signaling protocol, some trade-offs among benefits, cost, > and performance must be analyzed. It notes that the trade-off analyses > are not just focusing on technical matters. > > Jun Kyun Choi > > ----- Original Message ----- > From: "Marcus Brunner" > To: "Shahrier, Sharif M." > Cc: > Sent: Tuesday, July 30, 2002 4:50 PM > Subject: RE: [NSIS] question for clarification > > >> Whach the ccamp WG >> MArcus >> >> --On Montag, 29. Juli 2002 14:49 -0400 "Shahrier, Sharif M." >> wrote: >> >> > Marcus, >> > >> > Thanks for the information. Would you have the link to this draft >> > that you can send to us? Thanks. >> > >> > Sharif. >> > >> > >> > -----Original Message----- >> > From: Marcus Brunner [mailto:brunner@ccrle.nec.de] >> > Sent: Thursday, July 25, 2002 6:36 AM >> > To: Shahrier, Sharif M. >> > Cc: 'nsis@ietf.org' >> > Subject: Re: [NSIS] question for clarification >> > >> > Sharif, >> > >> > RSVP-TE with GMPLS extension is a signaling protocol for setting up >> > GMPLS pathes, which might be optical or what ever. There one of the >> > extension is that they allow for bi-directional path setup. >> > >> > Marcus >> > >> > --On Dienstag, 23. Juli 2002 15:16 -0400 "Shahrier, Sharif M." >> > wrote: >> > >> >> Following my presentation of the framework draft at Yokohama, a person >> >> had asked me whether our approach was the same as the "bi-directional >> >> GMPLS" that the MPLS WG had worked on. >> >> >> >> I am not sure what this is, and would appreciate if that person can >> >> provide us with more information. >> >> Thanks. >> >> >> >> Sharif. >> >> > -------------------------------------- Dr. Marcus Brunner Network Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ Phone: +49 (0) 6221 905 11 29 personal home page: http://www.brubers.org/marcus _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Mon Aug 5 12:06:01 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19419 for ; Mon, 5 Aug 2002 12:06:01 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA12583 for nsis-archive@odin.ietf.org; Mon, 5 Aug 2002 12:07:12 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA10633; Mon, 5 Aug 2002 11:59:29 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA10603 for ; Mon, 5 Aug 2002 11:59:27 -0400 (EDT) Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18742 for ; Mon, 5 Aug 2002 11:58:16 -0400 (EDT) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id IAA15856; Mon, 5 Aug 2002 08:59:21 -0700 (MST)] Received: [from noah.dma.isg.mot.com (noah.dma.isg.mot.com [150.21.2.29]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id IAA22052; Mon, 5 Aug 2002 08:59:21 -0700 (MST)] Received: from dma.isg.mot.com (ma07-0056.dma.isg.mot.com [150.21.30.201]) by noah.dma.isg.mot.com (8.8.8+Sun/8.8.8) with ESMTP id LAA25773; Mon, 5 Aug 2002 11:59:20 -0400 (EDT) Message-ID: <3D4EA0D8.D84DF1B8@dma.isg.mot.com> Date: Mon, 05 Aug 2002 11:59:20 -0400 From: Dan Grossman X-Mailer: Mozilla 4.5 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: brunner@ccrle.nec.de CC: jkchoi , "Shahrier, Sharif M." , nsis@ietf.org Subject: Re: [NSIS] question for clarification References: <007601c23bd6$13bbcc70$3c856bd2@jkchoi> <263008906.1028545189@[192.168.102.207]> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 7bit PacketCable http://www.packetcable.com/specs/PKT-SP-DQOS-I03-020116.pdf has also specified RSVP extensions for bi-directional reservations, in the context of IP telephony over cable. They're taking advantage of some unique topological limitations that constrain flows in opposite directions to follow the same path. I don't think you want to preclude this case any more than you want to require that flows always be constrained to follow the same path (or, actually, reverse paths). Questions: should we do anything special in the signalling protocol to force or prefer the same path? would it be desirable to discover those kinds of topological constraints and take advantage of them in the signalling protocol where they exist? would a style of bidirectional reservation that takes advantage of reverse paths would be so much simpler than one that assumes non-reverse paths that it's worth being a special case in the signalling protocol? Marcus Brunner wrote: > Concerning bi-directional, > > In the requirements draft we currently have > -------------- > 5.7.4 Uni / bi-directional reservation > > Both unidirectional as well as bi-direction reservations must be possible. > With bi-directional reservations we mean here reservations having the same > end-points. But the path in the two directions does not need to be the same. > > The goal of a bi-directional reservation is mainly an optimization in terms > of setup delay. There is no requirements on constrains such as use the same > data path etc. > ------------- > > It is important to note that we explicity mention that bi-directional is > meant to have only the same end-points, but does not need to follow the > same path. This is follwing the Internet Routing ARchitecture. > > Any constraint to force bi-directional reservations on the same path are > very complex and not workable in many cases. > > Marcus > > --On Montag, 5. August 2002 01:43 +0900 jkchoi wrote: > > > I just read this mail. It is me to raise a question for bi-directional > > QoS signaling at nsis WG. > > > > For the further development of "A Framework for Bi-Directional QoS > > Signaling" presented at Yokohama meeting, it needs to check the existing > > activities at mpls WG and ccamp WG to their signaling protocols (If time > > is available, check the signaling protocols developed by ITU-T SG13 and > > ISO/OSI etc. even though it is not for IP network. You can find some > > helpful mechanism to use for IP network.) > > > > It notes that > > > > - uni-directional signaling on LDP/CR-LDP and RSVP/RSVP-TE for MPLS > > network - on-going for bi-directional signaling on RSVP-TE and CR-LDP > > extension for GMPLS network. > > > > It also notes that most of the ATM network and most of data network use > > the bi-directional signaling in general. > > > > The author of draft-shahrier-nsis-framework-00.txt may first hear some > > backgrounds why the mpls WG choose uni-directional signaling. It was > > taken with some considerations of physical media type, end user > > applications, network provider operation and maintenance, and system > > implementation, etc. In addition, routing algorithm and forwarding logic > > of IP router are another factors for decision. In order to make a > > decision for bi-directional signaling at nsis WG, it may be needed to > > check the related technical issues including end user requirements, > > network operator requirements and system designer requirements. It may > > help to clarify the needs and the work scopes of that draft. > > Specifically, it may need to find target signaling objectives according > > to layered concept, service provisioning rule, gegographical view, > > network dimensioning and physical coverage, etc. > > > > In my personal views (since I am much oriented on telco- viewpoints), I > > don't clearly understand what is the real objectives of this draft ? What > > is the target application ? Is that only for a specific end appllication, > > otherwise is it generally both for end user and network provider ? I > > think that the author may find some critical problems on the existing > > activities of bi-directional signaling at other group or other body. Why > > new bi-directional signaling protocol is needed ? > > It may be reasonable to wait until the nsis WG finish the requirements > > even though I don't follow what is going on in detail yet. > > > > In general, different and individual signaling protocols are needed when > > end applications and intermediate network elements are different on > > operational rule, service provisioning, and control mechanism including > > resource reservation, etc. If a number of signaling requirements merge > > into one set of signaling protocol, some trade-offs among benefits, cost, > > and performance must be analyzed. It notes that the trade-off analyses > > are not just focusing on technical matters. > > > > Jun Kyun Choi > > > > ----- Original Message ----- > > From: "Marcus Brunner" > > To: "Shahrier, Sharif M." > > Cc: > > Sent: Tuesday, July 30, 2002 4:50 PM > > Subject: RE: [NSIS] question for clarification > > > > > >> Whach the ccamp WG > >> MArcus > >> > >> --On Montag, 29. Juli 2002 14:49 -0400 "Shahrier, Sharif M." > >> wrote: > >> > >> > Marcus, > >> > > >> > Thanks for the information. Would you have the link to this draft > >> > that you can send to us? Thanks. > >> > > >> > Sharif. > >> > > >> > > >> > -----Original Message----- > >> > From: Marcus Brunner [mailto:brunner@ccrle.nec.de] > >> > Sent: Thursday, July 25, 2002 6:36 AM > >> > To: Shahrier, Sharif M. > >> > Cc: 'nsis@ietf.org' > >> > Subject: Re: [NSIS] question for clarification > >> > > >> > Sharif, > >> > > >> > RSVP-TE with GMPLS extension is a signaling protocol for setting up > >> > GMPLS pathes, which might be optical or what ever. There one of the > >> > extension is that they allow for bi-directional path setup. > >> > > >> > Marcus > >> > > >> > --On Dienstag, 23. Juli 2002 15:16 -0400 "Shahrier, Sharif M." > >> > wrote: > >> > > >> >> Following my presentation of the framework draft at Yokohama, a person > >> >> had asked me whether our approach was the same as the "bi-directional > >> >> GMPLS" that the MPLS WG had worked on. > >> >> > >> >> I am not sure what this is, and would appreciate if that person can > >> >> provide us with more information. > >> >> Thanks. > >> >> > >> >> Sharif. > >> >> > > > > -------------------------------------- > Dr. Marcus Brunner > Network Laboratories > NEC Europe Ltd. > > E-Mail: brunner@ccrle.nec.de > WWW: http://www.ccrle.nec.de/ > Phone: +49 (0) 6221 905 11 29 > personal home page: http://www.brubers.org/marcus > > _______________________________________________ > 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 daemon@optimus.ietf.org Tue Aug 6 04:06:42 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28875 for ; Tue, 6 Aug 2002 04:06:42 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA11869 for nsis-archive@odin.ietf.org; Tue, 6 Aug 2002 04:07:55 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA11597; Tue, 6 Aug 2002 04:01:51 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA11569 for ; Tue, 6 Aug 2002 04:01:49 -0400 (EDT) Received: from rsys000a.roke.co.uk (rsys000a.roke.co.uk [193.118.203.102]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA28784 for ; Tue, 6 Aug 2002 04:00:35 -0400 (EDT) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Tue, 6 Aug 2002 09:01:07 +0100 Message-ID: <76C92FBBFB58D411AE760090271ED4181EA498@rsys002a.roke.co.uk> From: "Hancock, Robert" To: "'Dan Grossman'" , brunner@ccrle.nec.de Cc: jkchoi , "Shahrier, Sharif M." , nsis@ietf.org Subject: RE: [NSIS] question for clarification Date: Tue, 6 Aug 2002 09:01:05 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org This is a multi-part message in MIME format. --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; charset="iso-8859-1" hi dan, all, some points: firstly, i've long had a background assumption that it was not the role of NSIS as a transport protocol to influence/force/modify packet paths. Resource messages carried by NSIS might do this as a side effect, but NSIS itself has to be able to work in arbitrary environments (possibly taking advantage of special characteristics of those environments, of course). on the other hand, i've been involved in enough conversations to realise that this assumption is not universally held (maybe i'm even in the minority). in any case, we should probably state something more concrete. so, my take on dan's questions: a) no, NSIS shouldn't do things to force/prefer symmetric routing b) if there are good low-overhead ways to discover topological constraints i don't see why we shouldn't exploit them. the most important constraint would be that a host knew it was connected to the network over a point to point link. c) i doubt that a bidirectional reservation would be simpler than individual unidirectional ones, rather you could do grouping to get the same effect with very little extra complexity. (i think this is essentially what packetcable does.) i think the current requirements encourage this as a possibility to the right extent already, however. cheers, robert h. > -----Original Message----- > From: Dan Grossman [mailto:dan@dma.isg.mot.com] > Sent: 05 August 2002 16:59 > To: brunner@ccrle.nec.de > Cc: jkchoi; Shahrier, Sharif M.; nsis@ietf.org > Subject: Re: [NSIS] question for clarification > > > PacketCable > http://www.packetcable.com/specs/PKT-SP-DQOS-I03-020116.pdf has also > specified RSVP extensions for bi-directional reservations, in > the context of IP > telephony over cable. They're taking advantage of some > unique topological > limitations that constrain flows in opposite directions to > follow the same > path. I don't think you want to preclude this case any more > than you want to > require that flows always be constrained to follow the same > path (or, actually, > reverse paths). Questions: > should we do anything special in the signalling protocol > to force or prefer > the same path? > would it be desirable to discover those kinds of > topological constraints and > take advantage of them in the signalling protocol where they exist? > would a style of bidirectional reservation that takes > advantage of reverse > paths would be so much simpler than one that assumes > non-reverse paths that it's > worth being a special case in the signalling protocol? > > Marcus Brunner wrote: > > > Concerning bi-directional, > > > > In the requirements draft we currently have > > -------------- > > 5.7.4 Uni / bi-directional reservation > > > > Both unidirectional as well as bi-direction reservations > must be possible. > > With bi-directional reservations we mean here reservations > having the same > > end-points. But the path in the two directions does not > need to be the same. > > > > The goal of a bi-directional reservation is mainly an > optimization in terms > > of setup delay. There is no requirements on constrains such > as use the same > > data path etc. > > ------------- > > > > It is important to note that we explicity mention that > bi-directional is > > meant to have only the same end-points, but does not need > to follow the > > same path. This is follwing the Internet Routing ARchitecture. > > > > Any constraint to force bi-directional reservations on the > same path are > > very complex and not workable in many cases. > > > > Marcus > > > > --On Montag, 5. August 2002 01:43 +0900 jkchoi > wrote: > > > > > I just read this mail. It is me to raise a question for > bi-directional > > > QoS signaling at nsis WG. > > > > > > For the further development of "A Framework for Bi-Directional QoS > > > Signaling" presented at Yokohama meeting, it needs to > check the existing > > > activities at mpls WG and ccamp WG to their signaling > protocols (If time > > > is available, check the signaling protocols developed by > ITU-T SG13 and > > > ISO/OSI etc. even though it is not for IP network. You > can find some > > > helpful mechanism to use for IP network.) > > > > > > It notes that > > > > > > - uni-directional signaling on LDP/CR-LDP and > RSVP/RSVP-TE for MPLS > > > network - on-going for bi-directional signaling on > RSVP-TE and CR-LDP > > > extension for GMPLS network. > > > > > > It also notes that most of the ATM network and most of > data network use > > > the bi-directional signaling in general. > > > > > > The author of draft-shahrier-nsis-framework-00.txt may > first hear some > > > backgrounds why the mpls WG choose uni-directional > signaling. It was > > > taken with some considerations of physical media type, end user > > > applications, network provider operation and maintenance, > and system > > > implementation, etc. In addition, routing algorithm and > forwarding logic > > > of IP router are another factors for decision. In order to make a > > > decision for bi-directional signaling at nsis WG, it may > be needed to > > > check the related technical issues including end user > requirements, > > > network operator requirements and system designer > requirements. It may > > > help to clarify the needs and the work scopes of that draft. > > > Specifically, it may need to find target signaling > objectives according > > > to layered concept, service provisioning rule, gegographical view, > > > network dimensioning and physical coverage, etc. > > > > > > In my personal views (since I am much oriented on telco- > viewpoints), I > > > don't clearly understand what is the real objectives of > this draft ? What > > > is the target application ? Is that only for a specific > end appllication, > > > otherwise is it generally both for end user and network > provider ? I > > > think that the author may find some critical problems on > the existing > > > activities of bi-directional signaling at other group or > other body. Why > > > new bi-directional signaling protocol is needed ? > > > It may be reasonable to wait until the nsis WG finish the > requirements > > > even though I don't follow what is going on in detail yet. > > > > > > In general, different and individual signaling protocols > are needed when > > > end applications and intermediate network elements are > different on > > > operational rule, service provisioning, and control > mechanism including > > > resource reservation, etc. If a number of signaling > requirements merge > > > into one set of signaling protocol, some trade-offs among > benefits, cost, > > > and performance must be analyzed. It notes that the > trade-off analyses > > > are not just focusing on technical matters. > > > > > > Jun Kyun Choi > > > > > > ----- Original Message ----- > > > From: "Marcus Brunner" > > > To: "Shahrier, Sharif M." > > > Cc: > > > Sent: Tuesday, July 30, 2002 4:50 PM > > > Subject: RE: [NSIS] question for clarification > > > > > > > > >> Whach the ccamp WG > > >> MArcus > > >> > > >> --On Montag, 29. Juli 2002 14:49 -0400 "Shahrier, Sharif M." > > >> wrote: > > >> > > >> > Marcus, > > >> > > > >> > Thanks for the information. Would you have the link to > this draft > > >> > that you can send to us? Thanks. > > >> > > > >> > Sharif. > > >> > > > >> > > > >> > -----Original Message----- > > >> > From: Marcus Brunner [mailto:brunner@ccrle.nec.de] > > >> > Sent: Thursday, July 25, 2002 6:36 AM > > >> > To: Shahrier, Sharif M. > > >> > Cc: 'nsis@ietf.org' > > >> > Subject: Re: [NSIS] question for clarification > > >> > > > >> > Sharif, > > >> > > > >> > RSVP-TE with GMPLS extension is a signaling protocol > for setting up > > >> > GMPLS pathes, which might be optical or what ever. > There one of the > > >> > extension is that they allow for bi-directional path setup. > > >> > > > >> > Marcus > > >> > > > >> > --On Dienstag, 23. Juli 2002 15:16 -0400 "Shahrier, Sharif M." > > >> > wrote: > > >> > > > >> >> Following my presentation of the framework draft at > Yokohama, a person > > >> >> had asked me whether our approach was the same as the > "bi-directional > > >> >> GMPLS" that the MPLS WG had worked on. > > >> >> > > >> >> I am not sure what this is, and would appreciate if > that person can > > >> >> provide us with more information. > > >> >> Thanks. > > >> >> > > >> >> Sharif. > > >> >> > > > > > > > -------------------------------------- > > Dr. Marcus Brunner > > Network Laboratories > > NEC Europe Ltd. > > > > E-Mail: brunner@ccrle.nec.de > > WWW: http://www.ccrle.nec.de/ > > Phone: +49 (0) 6221 905 11 29 > > personal home page: http://www.brubers.org/marcus > > > > _______________________________________________ > > 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 > ======================================================================================== Permission is hereby granted to pass the contents of this communication to third parties and any restrictions regarding confidentiality do not apply. --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; name="RMRL-Disclaimer.txt" Content-Disposition: attachment; filename="RMRL-Disclaimer.txt" Content-Transfer-Encoding: 7bit Registered Office: Roke Manor Research Ltd, Siemens House, Oldbury, Bracknell, Berkshire. RG12 8FZ The information contained in this e-mail and any attachments is confidential to Roke Manor Research Ltd and must not be passed to any third party without permission. This communication is for information only and shall not create or change any contractual relationship. --------------InterScan_NT_MIME_Boundary-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Tue Aug 6 04:21:49 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29118 for ; Tue, 6 Aug 2002 04:21:49 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA12209 for nsis-archive@odin.ietf.org; Tue, 6 Aug 2002 04:23:02 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA11770; Tue, 6 Aug 2002 04:05:46 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA11744 for ; Tue, 6 Aug 2002 04:05:44 -0400 (EDT) Received: from tokyo.ccrle.nec.de (tokyo.ccrle.nec.de [195.37.70.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28845 for ; Tue, 6 Aug 2002 04:04:30 -0400 (EDT) Received: from imap.heidelberg.ccrle.nec.de (imap [192.168.102.11]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g7684sU10427; Tue, 6 Aug 2002 10:04:54 +0200 (CEST) (envelope-from brunner@ccrle.nec.de) Received: from [192.168.102.207] (marcus.heidelberg.ccrle.nec.de [192.168.102.207]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 77AD359373; Tue, 6 Aug 2002 10:04:53 +0200 (CEST) Date: Tue, 06 Aug 2002 10:04:54 +0200 From: Marcus Brunner Reply-To: brunner@ccrle.nec.de To: Dan Grossman Cc: jkchoi , "Shahrier, Sharif M." , nsis@ietf.org Subject: Re: [NSIS] question for clarification Message-ID: <346121496.1028628294@[192.168.102.207]> In-Reply-To: <3D4EA0D8.D84DF1B8@dma.isg.mot.com> References: <3D4EA0D8.D84DF1B8@dma.isg.mot.com> X-Mailer: Mulberry/2.2.0 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 7bit --On Montag, 5. August 2002 11:59 -0400 Dan Grossman wrote: > Questions: > should we do anything special in the signalling protocol to force or > prefer the same path? That is exactly what I don't want to do. If the protocol works bi-directional on the same path due to topological constraints this is fine. But finding the same path is IMHO a routing issue. I pretty much like the decoupling of routing and signaling. > would it be desirable to discover those kinds of topological > constraints and take advantage of them in the signalling protocol where > they exist? would a style of bidirectional reservation that takes > advantage of reverse paths would be so much simpler than one that assumes > non-reverse paths that it's worth being a special case in the signalling > protocol? I currently assume that it is simpler. The issue is that the protocol should NOT take into account topological issues at all. Marcus > Marcus Brunner wrote: > >> Concerning bi-directional, >> >> In the requirements draft we currently have >> -------------- >> 5.7.4 Uni / bi-directional reservation >> >> Both unidirectional as well as bi-direction reservations must be >> possible. With bi-directional reservations we mean here reservations >> having the same end-points. But the path in the two directions does not >> need to be the same. >> >> The goal of a bi-directional reservation is mainly an optimization in >> terms of setup delay. There is no requirements on constrains such as use >> the same data path etc. >> ------------- >> >> It is important to note that we explicity mention that bi-directional is >> meant to have only the same end-points, but does not need to follow the >> same path. This is follwing the Internet Routing ARchitecture. >> >> Any constraint to force bi-directional reservations on the same path are >> very complex and not workable in many cases. >> >> Marcus >> >> --On Montag, 5. August 2002 01:43 +0900 jkchoi wrote: >> >> > I just read this mail. It is me to raise a question for bi-directional >> > QoS signaling at nsis WG. >> > >> > For the further development of "A Framework for Bi-Directional QoS >> > Signaling" presented at Yokohama meeting, it needs to check the >> > existing activities at mpls WG and ccamp WG to their signaling >> > protocols (If time is available, check the signaling protocols >> > developed by ITU-T SG13 and ISO/OSI etc. even though it is not for IP >> > network. You can find some helpful mechanism to use for IP network.) >> > >> > It notes that >> > >> > - uni-directional signaling on LDP/CR-LDP and RSVP/RSVP-TE for MPLS >> > network - on-going for bi-directional signaling on RSVP-TE and CR-LDP >> > extension for GMPLS network. >> > >> > It also notes that most of the ATM network and most of data network use >> > the bi-directional signaling in general. >> > >> > The author of draft-shahrier-nsis-framework-00.txt may first hear some >> > backgrounds why the mpls WG choose uni-directional signaling. It was >> > taken with some considerations of physical media type, end user >> > applications, network provider operation and maintenance, and system >> > implementation, etc. In addition, routing algorithm and forwarding >> > logic of IP router are another factors for decision. In order to make a >> > decision for bi-directional signaling at nsis WG, it may be needed to >> > check the related technical issues including end user requirements, >> > network operator requirements and system designer requirements. It may >> > help to clarify the needs and the work scopes of that draft. >> > Specifically, it may need to find target signaling objectives according >> > to layered concept, service provisioning rule, gegographical view, >> > network dimensioning and physical coverage, etc. >> > >> > In my personal views (since I am much oriented on telco- viewpoints), I >> > don't clearly understand what is the real objectives of this draft ? >> > What is the target application ? Is that only for a specific end >> > appllication, otherwise is it generally both for end user and network >> > provider ? I think that the author may find some critical problems on >> > the existing activities of bi-directional signaling at other group or >> > other body. Why new bi-directional signaling protocol is needed ? >> > It may be reasonable to wait until the nsis WG finish the requirements >> > even though I don't follow what is going on in detail yet. >> > >> > In general, different and individual signaling protocols are needed >> > when end applications and intermediate network elements are different >> > on operational rule, service provisioning, and control mechanism >> > including resource reservation, etc. If a number of signaling >> > requirements merge into one set of signaling protocol, some trade-offs >> > among benefits, cost, and performance must be analyzed. It notes that >> > the trade-off analyses are not just focusing on technical matters. >> > >> > Jun Kyun Choi >> > >> > ----- Original Message ----- >> > From: "Marcus Brunner" >> > To: "Shahrier, Sharif M." >> > Cc: >> > Sent: Tuesday, July 30, 2002 4:50 PM >> > Subject: RE: [NSIS] question for clarification >> > >> > >> >> Whach the ccamp WG >> >> MArcus >> >> >> >> --On Montag, 29. Juli 2002 14:49 -0400 "Shahrier, Sharif M." >> >> wrote: >> >> >> >> > Marcus, >> >> > >> >> > Thanks for the information. Would you have the link to this draft >> >> > that you can send to us? Thanks. >> >> > >> >> > Sharif. >> >> > >> >> > >> >> > -----Original Message----- >> >> > From: Marcus Brunner [mailto:brunner@ccrle.nec.de] >> >> > Sent: Thursday, July 25, 2002 6:36 AM >> >> > To: Shahrier, Sharif M. >> >> > Cc: 'nsis@ietf.org' >> >> > Subject: Re: [NSIS] question for clarification >> >> > >> >> > Sharif, >> >> > >> >> > RSVP-TE with GMPLS extension is a signaling protocol for setting up >> >> > GMPLS pathes, which might be optical or what ever. There one of the >> >> > extension is that they allow for bi-directional path setup. >> >> > >> >> > Marcus >> >> > >> >> > --On Dienstag, 23. Juli 2002 15:16 -0400 "Shahrier, Sharif M." >> >> > wrote: >> >> > >> >> >> Following my presentation of the framework draft at Yokohama, a >> >> >> person had asked me whether our approach was the same as the >> >> >> "bi-directional GMPLS" that the MPLS WG had worked on. >> >> >> >> >> >> I am not sure what this is, and would appreciate if that person can >> >> >> provide us with more information. >> >> >> Thanks. >> >> >> >> >> >> Sharif. >> >> >> >> > >> >> -------------------------------------- >> Dr. Marcus Brunner >> Network Laboratories >> NEC Europe Ltd. >> >> E-Mail: brunner@ccrle.nec.de >> WWW: http://www.ccrle.nec.de/ >> Phone: +49 (0) 6221 905 11 29 >> personal home page: http://www.brubers.org/marcus >> >> _______________________________________________ >> nsis mailing list >> nsis@ietf.org >> https://www1.ietf.org/mailman/listinfo/nsis > -------------------------------------- Dr. Marcus Brunner Network Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ Phone: +49 (0) 6221 905 11 29 personal home page: http://www.brubers.org/marcus _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Tue Aug 6 04:38:27 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29374 for ; Tue, 6 Aug 2002 04:38:26 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA13168 for nsis-archive@odin.ietf.org; Tue, 6 Aug 2002 04:39:40 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA13017; Tue, 6 Aug 2002 04:33:18 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA12986 for ; Tue, 6 Aug 2002 04:33:16 -0400 (EDT) Received: from mail1.telekom.de (mail1.telekom.de [62.225.183.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29292 for ; Tue, 6 Aug 2002 04:32:02 -0400 (EDT) Received: from g8pbr.blf01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Tue, 6 Aug 2002 10:32:18 +0200 Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Tue, 6 Aug 2002 10:32:17 +0200 Message-Id: From: "Geib, Ruediger" To: brunner@ccrle.nec.de Cc: nsis@ietf.org Subject: RE: [NSIS] question for clarification Date: Tue, 6 Aug 2002 10:32:16 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id EAA12987 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Marcus, you are absolutely right, let's keep signaling for resources separated from signaling for routing. Regards, Rüdiger >> Questions: >> should we do anything special in the signalling protocol >> to force or prefer the same path? > That is exactly what I don't want to do. If the protocol works > bi-directional on the same path due to topological constraints > this is fine. But finding the same path is IMHO a routing > issue. I pretty much like the decoupling of routing and > signaling. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Tue Aug 6 06:12:55 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01777 for ; Tue, 6 Aug 2002 06:12:55 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA17447 for nsis-archive@odin.ietf.org; Tue, 6 Aug 2002 06:14:07 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA16815; Tue, 6 Aug 2002 06:06:12 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA16781 for ; Tue, 6 Aug 2002 06:06:10 -0400 (EDT) Received: from chollian.net ([218.50.187.237]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01352 for ; Tue, 6 Aug 2002 06:04:57 -0400 (EDT) Message-Id: <200208061004.GAA01352@ietf.org> From: BRANDBANK To: Dear nsis Date: Tue, 06 Aug 2002 19:06:10 +0900 MIME-Version: 1.0 Content-Type: text/html; charset="ks_c_5601-1987" X-Priority: 3 Subject: [NSIS] [ADV] BRANDBANK, valuable source for your BRAND business Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Untitled

This message is a commercial advertisement. It is compliant with all federal and state laws regarding email messages. We have provided ¡°opt out¡± email contact so you can be deleted from our mailing list. In addition we have provided the subject line ¡°ADV¡± to provide you notification that is a commercial advertisement for person over 18yrs old.

_______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Tue Aug 6 07:32:26 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05549 for ; Tue, 6 Aug 2002 07:32:26 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA27624 for nsis-archive@odin.ietf.org; Tue, 6 Aug 2002 07:33:39 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA25281; Tue, 6 Aug 2002 07:24:48 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA25133 for ; Tue, 6 Aug 2002 07:24:42 -0400 (EDT) Received: from africamail.com (66-178-46-224.newskies.net [66.178.46.224] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA04786 for ; Tue, 6 Aug 2002 07:22:48 -0400 (EDT) Message-Id: <200208061122.HAA04786@ietf.org> From: "DR GARUBA UMAR" To: Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit Date: Tue, 6 Aug 2002 12:24:22 +0100 Content-Transfer-Encoding: 8bit Subject: [NSIS] SEEKING IMMIDIATE ASSISTANCE AND PARTHNERSHIP Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Fro m the de sk of: DR . GAR BA UMA R Tel No : You r Int l. Acc ess Co de + 234 9 272 720 1 E-F AX : +17 752 561 718 +1 77 5-2 69- 702 8 Ema il: um arg aru ba@ ade xec .co m gar uba uma r@a fri cam ail .co m gar uba uma r@a dex ec. com Lag os, Ni ger ia. Dea r Sir , REQ UES T FOR AN UR GEN T CON FID ENT IAL BU SIN ESS RE LAT ION SHI P Aft er due de lib era tio n wit h my col lea gue s, I hav e dec ide d to for war d to you th is bus ine ss pro pos al. We wa nt a rel iab le per son wh o cou ld ass ist us to tr ans fer th e sum of Tw ent y Mil lio n Fiv e Hun dre d Tho usa nd Uni ted St ate s Dol lar s ($2 0,5 00, 000 ) int o his / her ac cou nt. Thi s fun d res ult ed fro m an ove r-i nvo ice d bil l fro m con tra cts aw ard ed by us und er the bu dge t all oca tio n to my Min ist ry and th is bil l has be en app rov ed for pa yme nt by the co nce rne d aut hor iti es. Th e con tra ct has si nce be en exe cut ed, co mmi ssi one d and th e con tra cto r was pa id the ac tua l cos t of the co ntr act . We are le ft wit h the ba lan ce US$ 20. 5M as par t of the ov er- inv oic ed amo unt wh ich we ha ve del ibe rat ely ov er est ima ted fo r our ow n use . But un der ou r pro toc ol div isi on, ci vil se rva nts ar e for bid den to op era te or own fo rei gn acc oun ts. Thi s is why I am con tac tin g you to be ou r cus tod ian fo r thi s fun d. As you ma y wan t to kno w and to ma ke you le ss cur iou s, I got yo ur add res s fro m a sit e in the in ter net th at por tra yed yo u (yo ur est abl ish men t) in goo d lig ht. I am the Ch ief Ac cou nta nt/ Int ern al Aud ito r of the Co ntr act Aw ard Co mmi tte e (C. A.C .) of the Ni ger ian Na tio nal Pe tro leu mCo rpo rat ion (NN PC) . Thi s tra nsa cti on is ver y muc h fre e fro m all so rts of RI SKS an d TRO UBL E fro m my Gov ern men t. We the N. N.P .C. Of fic ial s inv olv ed in thi s dea l hav e put in ma ny yea rs in ser vic e to thi s Min ist ry. We ha ve bee n exe rci sin g pat ien ce for th is opp ort uni ty for so lo ng and to us , thi s is a lif e tim e opp ort uni ty we can not af for d to mis s. You ne ed not to wo rry ab out th e res pon sib ili tie s of tra nsf err ing th is fun d int o you r acc oun t, bec aus e all th e adm ini str ati ve ste p nee ded fo r the tr ans fer of th is fun d int o you r des ign ate d ban kac cou nt wil l be don e by me. We hav e agr eed to CO MPE NSA TE you du ly ifa gre eme nt is rea che d by bot h of us. My col lea gue an d I wil l com e to you r cou ntr y to arr ang e for ou r sha re, upo n the co nfi rma tio n fro m you th at the mo ney ha s bee n cre dit ed int o you r nom ina ted ba nk acc oun t. Con seq uen t upo n you r acc ept anc e of thi s pro pos al, ki ndl y con fir m you r int ere st by sen din g me a rev ert em ail vi a the ema il acc oun ts bel ow (ga rub aum ar@ afr ica mai l.c om) Yo ur ind ica tio n by rev ert em ail to me of yo ur sin cer e and se rio us int ere st wil l ena ble me sen d you th e PRO CED URE FO R OPE RAT ION . NOT E: In the ev ent of yo ur ina bil ity to ha ndl e thi s tra nsa cti on ple ase in for m us so tha t we can lo ok for an oth er rel iab le per son wh o can ass ist in th is res pec t. It mig ht sur pri se you wh y we cho ose yo u and tr ust ed you fo r thi s tra nsa cti on. Ye s, we bel iev e tha t goo d fri end s can be di sco ver ed and bus ine ss lik e thi s can no t be exe cut ed wit hou t tru st. Th is is why we hav e dec ide d to tru st you fo r thi s tra nsa cti on. We ar e loo kin g for war d to doi ng thi s tra nsa cti on wit h you . Be fur the r inf orm ed tha t eve ryb ody ÷Õ int ere st and se cur ity ha d bee n con sid ere d bef ore yo u wer e con tac ted , so be res t ass ure d and fe el fre e to go int o thi s tra nsa cti on wit h us. Bu t let Ho nes tya nd Tru st be our wa tch wor d thr oug hou t thi s tra nsa cti on and yo ur pro mpt re ply wi ll be hig hly ap pre cia ted . Tha nk you an d God bl ess . Bes t Reg ard s, DR. GA RUB A UMA R. Ple ase re ply th is mai l via th e abo ve lis ted e- mai l add res ses (ga rub aum ar@ afr ica mai l.c om) for co nfi den tia l rea son s. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Tue Aug 6 10:42:30 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13540 for ; Tue, 6 Aug 2002 10:42:30 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA08711 for nsis-archive@odin.ietf.org; Tue, 6 Aug 2002 10:43:45 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA08187; Tue, 6 Aug 2002 10:31:27 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA08160 for ; Tue, 6 Aug 2002 10:31:26 -0400 (EDT) Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13037 for ; Tue, 6 Aug 2002 10:30:10 -0400 (EDT) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate2.mot.com (motgate2 2.1) with ESMTP id HAA02074; Tue, 6 Aug 2002 07:31:08 -0700 (MST)] Received: [from noah.dma.isg.mot.com (noah.dma.isg.mot.com [150.21.2.29]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id HAA24887; Tue, 6 Aug 2002 07:31:07 -0700 (MST)] Received: from dma.isg.mot.com (ma07-0056.dma.isg.mot.com [150.21.30.201]) by noah.dma.isg.mot.com (8.8.8+Sun/8.8.8) with ESMTP id KAA07042; Tue, 6 Aug 2002 10:31:07 -0400 (EDT) Message-ID: <3D4FDDAA.DA2C8249@dma.isg.mot.com> Date: Tue, 06 Aug 2002 10:31:06 -0400 From: Dan Grossman X-Mailer: Mozilla 4.5 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "Hancock, Robert" CC: brunner@ccrle.nec.de, jkchoi , "Shahrier, Sharif M." , nsis@ietf.org Subject: Re: [NSIS] question for clarification References: <76C92FBBFB58D411AE760090271ED4181EA498@rsys002a.roke.co.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 7bit "Hancock, Robert" wrote: > hi dan, all, > > some points: > > firstly, i've long had a background assumption that it was not the role of NSIS as a transport protocol to influence/force/modify packet paths. Resource messages carried by NSIS might do this as a side effect, but NSIS itself has to be able to work in arbitrary environments (possibly taking advantage of special characteristics of those environments, of course). Why not? There are cases where the originator of a flow has a (small 'p') policy objective, like "I'd rather use service provider 'x' than service provider 'y'", or "Please constrain this bidirectional flow to use reverse paths" or "Please route these two flows as diversely as possible". I don't think that there are very many of these cases, but I don't see any architectural reason to preclude them. > > > on the other hand, i've been involved in enough conversations to realise that this assumption is not universally held (maybe i'm even in the minority). in any case, we should probably state something more concrete. > > so, my take on dan's questions: > a) no, NSIS shouldn't do things to force/prefer symmetric routing The more we discuss this, the more inclined I am to believe that the mechanisms to do so should be put in place, as long as the network has the right of refusal. You could do it with preference ("I prefer reverse paths") and/or you can do it with source directed blocking ("If you can't or won't give me reverse paths, please reject the flow, I don't want it"). > > b) if there are good low-overhead ways to discover topological constraints i don't see why we shouldn't exploit them. the most important constraint would be that a host knew it was connected to the network over a point to point link. Actually, that's "connected to a stub network". > > c) i doubt that a bidirectional reservation would be simpler than individual unidirectional ones, rather you could do grouping to get the same effect with very little extra complexity. (i think this is essentially what packetcable does.) i think the current requirements encourage this as a possibility to the right extent already, however. I believe that the point in PacketCable was to reduce signalling latency and message overhead by exploiting the fact that the cable subnet is a stub network. It also simplifies recovery from cases where the flow in one direction can't be set up, making having a flow in the other direction not useful. If bi-directional flows are dominant, deadlocks can occur unless there is some atomic way reserve resources for both directions. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Tue Aug 6 11:55:35 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16042 for ; Tue, 6 Aug 2002 11:55:35 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA12664 for nsis-archive@odin.ietf.org; Tue, 6 Aug 2002 11:56:50 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA12419; Tue, 6 Aug 2002 11:50:10 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA12323 for ; Tue, 6 Aug 2002 11:50:04 -0400 (EDT) Received: from arb-exchange1.cetaceannetworks.com ([63.127.199.196]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15756 for ; Tue, 6 Aug 2002 11:48:48 -0400 (EDT) Received: by mail.cetaceannetworks.com with Internet Mail Service (5.5.2653.19) id ; Tue, 6 Aug 2002 11:42:29 -0400 Message-ID: <6D8664171C38D511B5AD0002B325CE66A9332B@mail.cetaceannetworks.com> From: "Freytsis, Ilya" To: "'Dan Grossman'" , "Hancock, Robert" Cc: brunner@ccrle.nec.de, jkchoi , "Shahrier, Sharif M." , nsis@ietf.org Subject: RE: [NSIS] question for clarification Date: Tue, 6 Aug 2002 11:42:22 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hi Dan, all I think Dan making good arguments for the NSIS support of the optional modalities of bi-directional reservations. Since their value as well as complexity probably depends on the part of the network it should be thoroughly analyzed and reflected in the section 6 of the Marcus' draft. Regards, Ilya -----Original Message----- From: Dan Grossman [mailto:dan@dma.isg.mot.com] Sent: Tuesday, August 06, 2002 10:31 AM To: Hancock, Robert Cc: brunner@ccrle.nec.de; jkchoi; Shahrier, Sharif M.; nsis@ietf.org Subject: Re: [NSIS] question for clarification "Hancock, Robert" wrote: > hi dan, all, > > some points: > > firstly, i've long had a background assumption that it was not the role of NSIS as a transport protocol to influence/force/modify packet paths. Resource messages carried by NSIS might do this as a side effect, but NSIS itself has to be able to work in arbitrary environments (possibly taking advantage of special characteristics of those environments, of course). Why not? There are cases where the originator of a flow has a (small 'p') policy objective, like "I'd rather use service provider 'x' than service provider 'y'", or "Please constrain this bidirectional flow to use reverse paths" or "Please route these two flows as diversely as possible". I don't think that there are very many of these cases, but I don't see any architectural reason to preclude them. > > > on the other hand, i've been involved in enough conversations to realise that this assumption is not universally held (maybe i'm even in the minority). in any case, we should probably state something more concrete. > > so, my take on dan's questions: > a) no, NSIS shouldn't do things to force/prefer symmetric routing The more we discuss this, the more inclined I am to believe that the mechanisms to do so should be put in place, as long as the network has the right of refusal. You could do it with preference ("I prefer reverse paths") and/or you can do it with source directed blocking ("If you can't or won't give me reverse paths, please reject the flow, I don't want it"). > > b) if there are good low-overhead ways to discover topological constraints i don't see why we shouldn't exploit them. the most important constraint would be that a host knew it was connected to the network over a point to point link. Actually, that's "connected to a stub network". > > c) i doubt that a bidirectional reservation would be simpler than individual unidirectional ones, rather you could do grouping to get the same effect with very little extra complexity. (i think this is essentially what packetcable does.) i think the current requirements encourage this as a possibility to the right extent already, however. I believe that the point in PacketCable was to reduce signalling latency and message overhead by exploiting the fact that the cable subnet is a stub network. It also simplifies recovery from cases where the flow in one direction can't be set up, making having a flow in the other direction not useful. If bi-directional flows are dominant, deadlocks can occur unless there is some atomic way reserve resources for both directions. _______________________________________________ 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 daemon@optimus.ietf.org Tue Aug 6 12:20:26 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16928 for ; Tue, 6 Aug 2002 12:20:26 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA15276 for nsis-archive@odin.ietf.org; Tue, 6 Aug 2002 12:21:38 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA14774; Tue, 6 Aug 2002 12:12:30 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA14745 for ; Tue, 6 Aug 2002 12:12:29 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16552 for ; Tue, 6 Aug 2002 12:11:16 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (IDENT:mirapoint@mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g76GBvhI015718; Tue, 6 Aug 2002 09:11:57 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id AES22896; Tue, 6 Aug 2002 09:07:55 -0700 (PDT) Message-Id: <200208061607.AES22896@mira-sjc5-4.cisco.com> To: Dan Grossman cc: nsis@ietf.org From: Melinda Shore Subject: Re: [NSIS] question for clarification In-Reply-To: Message from Dan Grossman of "Tue, 06 Aug 2002 10:31:06 EDT." <3D4FDDAA.DA2C8249@dma.isg.mot.com> Date: Tue, 06 Aug 2002 12:09:55 -0400 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org > Why not? There are cases where the originator of a flow > has a (small 'p') policy objective, like "I'd rather use > service provider 'x' than service provider 'y'", or > "Please constrain this bidirectional flow to use reverse > paths" or "Please route these two flows as diversely as > possible". I don't think that there are very many of > these cases, but I don't see any architectural reason to > preclude them. My stock response to this sort of thing is "I understand why you want to do this, but I don't understand why you'd want to do it over IP." I tend to be uncomfortable with mechanisms that are inconsistent with how IP was designed to be used, since they remove the advantages it brings. I'm also not clear on why we'd want to overlap with MPLS to such an extent. These examples concern me more than others we've seen. NSIS isn't here to add another routing protocol into the soup - it's here to provide a way to make requests of NSIS-capable devices along a path. Those are two completely orthogonal things. There's a strong case to be made for upper-layer routing protocols (regard TRIP, for example), and perhaps once the NSIS protocol machinery is specified an upper-layer routing protocol can be created as an NSIS application, but I don't believe there's a strong case for upper-layer routing protocols as an NSIS primitive. Melinda _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Tue Aug 6 14:18:48 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22130 for ; Tue, 6 Aug 2002 14:18:48 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA22587 for nsis-archive@odin.ietf.org; Tue, 6 Aug 2002 14:20:01 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA21821; Tue, 6 Aug 2002 14:01:03 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA21783 for ; Tue, 6 Aug 2002 14:01:01 -0400 (EDT) Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21229 for ; Tue, 6 Aug 2002 13:59:47 -0400 (EDT) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate2.mot.com (motgate2 2.1) with ESMTP id LAA03083; Tue, 6 Aug 2002 11:00:54 -0700 (MST)] Received: [from noah.dma.isg.mot.com (noah.dma.isg.mot.com [150.21.2.29]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id LAA24608; Tue, 6 Aug 2002 11:00:53 -0700 (MST)] Received: from dma.isg.mot.com (ma07-0056.dma.isg.mot.com [150.21.30.201]) by noah.dma.isg.mot.com (8.8.8+Sun/8.8.8) with ESMTP id NAA08222; Tue, 6 Aug 2002 13:59:19 -0400 (EDT) Message-ID: <3D500E77.272D13C0@dma.isg.mot.com> Date: Tue, 06 Aug 2002 13:59:19 -0400 From: Dan Grossman X-Mailer: Mozilla 4.5 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Melinda Shore CC: nsis@ietf.org Subject: Re: [NSIS] question for clarification References: <200208061607.AES22896@mira-sjc5-4.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 7bit Melinda Shore wrote: > > Why not? There are cases where the originator of a flow > > has a (small 'p') policy objective, like "I'd rather use > > service provider 'x' than service provider 'y'", or > > "Please constrain this bidirectional flow to use reverse > > paths" or "Please route these two flows as diversely as > > possible". I don't think that there are very many of > > these cases, but I don't see any architectural reason to > > preclude them. > > My stock response to this sort of thing is "I understand why > you want to do this, but I don't understand why you'd want > to do it over IP." I tend to be uncomfortable with > mechanisms that are inconsistent with how IP was designed to > be used, since they remove the advantages it brings. I'm > also not clear on why we'd want to overlap with MPLS to such > an extent. It sounds like you're trying to articulate an architectural principle, but I don't understand what it is or how you justify it. If somebody has written down "how IP is supposed to be used", I'm not aware of it, much less why you claim that this is inconsistent.. You claim that some advantages of IP are removed, but you don't say which ones. As far as MPLS is concerned, I consider this to be complementrary rather than overlapping capabilities. > > > These examples concern me more than others we've seen. NSIS > isn't here to add another routing protocol into the soup - Nobody's talking about adding a routing protocol: we've got too many of them already. And certainly there are precedents in IP for requesting particular routing treatments (source routing and the security field come immediately to mind). > > it's here to provide a way to make requests of NSIS-capable > devices along a path. That's my point. Just that I'd like to be able to make particular requests to NSIS-capable devices that influence their next-hop forwarding decisions for a particular flow or set of flows. Nobody's been able to articulate why that is a Bad Thing. > Those are two completely orthogonal > things. There's a strong case to be made for upper-layer > routing protocols (regard TRIP, for example), and perhaps > once the NSIS protocol machinery is specified an upper-layer > routing protocol can be created as an NSIS application, but > I don't believe there's a strong case for upper-layer > routing protocols as an NSIS primitive. I don't understand why you'd need an upper layer routing protocol for this or why there's so much of a separation of concerns that would warrant creating a new layer. Or are you talking about discovery rather than communicating policy requests? _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Tue Aug 6 15:37:33 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25752 for ; Tue, 6 Aug 2002 15:37:33 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA27531 for nsis-archive@odin.ietf.org; Tue, 6 Aug 2002 15:38:46 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA26253; Tue, 6 Aug 2002 15:23:25 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA26224 for ; Tue, 6 Aug 2002 15:23:23 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25116 for ; Tue, 6 Aug 2002 15:22:08 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (IDENT:mirapoint@mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g76JMohI011716; Tue, 6 Aug 2002 12:22:50 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id AES31039; Tue, 6 Aug 2002 12:18:48 -0700 (PDT) Message-Id: <200208061918.AES31039@mira-sjc5-4.cisco.com> To: Dan Grossman cc: Melinda Shore , nsis@ietf.org From: Melinda Shore Subject: Re: [NSIS] question for clarification In-Reply-To: Message from Dan Grossman of "Tue, 06 Aug 2002 13:59:19 EDT." <3D500E77.272D13C0@dma.isg.mot.com> Date: Tue, 06 Aug 2002 15:20:47 -0400 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org > It sounds like you're trying to articulate an architectural principle, > but I don't understand what it is or how you justify it. Put a packet into the network with a valid destination address and allow IP-layer routing to determine how it gets from here to there. If applications start determining routes for traffic, you run into problems like suboptimal routes, tromboning, and so forth, and you can only avoid those by pushing routing state into the applications themselves. That starts to interfere with network robustness (recovery from outages, convergence after routing changes, etc.) and greatly increases the complexity of both the network and the application. > Nobody's talking about adding a routing protocol: we've got too many of > them already. Sure you are. If you're telling the IP layer how to route packets, you're a routing protocol. > And certainly there are precedents in IP for requesting > particular routing treatments (source routing and the security field > come immediately to mind). You'll note that source routed packets are usually dropped. I'm not sure what you mean by "security field" - are you referring to the DS byte? That's an in-band signaling mechanism, not a routing mechanism. > I don't understand why you'd need an upper layer routing protocol for > this or why there's so much of a separation of concerns that would > warrant creating a new layer. It's generally appropriate to route among entities at the same layer. So, for VoIP the signaling problem is how to route to appropriate gateways, not how to choose the routers the traffic will traverse en route. For content networking it's how to find the appropriate cache. And so on. That's one aspect of "layer." The other layering question is related to the NSIS protocol itself. There appears to be widespread agreement that the NSIS protocol will be split into two layers; one providing the NSIS transport and protocol machinery and the other providing the data representing the NSIS request (see Bob Braden's two-layer draft). This provides greater generality/power in the base protocol and resolves some of the weaknesses that prevent RSVP from being a more general-purpose signaling protocol. It seems clear to me that to the extent that routing should be treated as an NSIS function, and I'm not convinced that it should, it belongs in the upper layer, not the transport, and we're not working on the upper layer yet. Melinda _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Tue Aug 6 17:01:32 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28794 for ; Tue, 6 Aug 2002 17:01:32 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA03583 for nsis-archive@odin.ietf.org; Tue, 6 Aug 2002 17:02:47 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA02078; Tue, 6 Aug 2002 16:49:17 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA02047 for ; Tue, 6 Aug 2002 16:49:15 -0400 (EDT) Received: from arb-exchange1.cetaceannetworks.com ([63.127.199.199]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28449 for ; Tue, 6 Aug 2002 16:48:00 -0400 (EDT) Received: by mail.cetaceannetworks.com with Internet Mail Service (5.5.2653.19) id ; Tue, 6 Aug 2002 16:41:41 -0400 Message-ID: <6D8664171C38D511B5AD0002B325CE66A93333@mail.cetaceannetworks.com> From: "Freytsis, Ilya" To: "'Melinda Shore'" , Dan Grossman Cc: nsis@ietf.org Subject: RE: [NSIS] question for clarification Date: Tue, 6 Aug 2002 16:41:33 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Melinda, I disagree with your judgment that Dan's proposal "telling" how to route packets. It is about NSIS being able to ask network the following question: "Based on the topology/routing knowledge that you have could you please (preferably) allocate resources that satisfy the certain conditions." I do not see how will it effect routing in the negative ways that you have mentioned and why does it go against IP philosophy. I am not convinced that VoIP and TRIP is an adequate analogy here. Regards, Ilya -----Original Message----- From: Melinda Shore [mailto:mshore@cisco.com] Sent: Tuesday, August 06, 2002 3:21 PM To: Dan Grossman Cc: Melinda Shore; nsis@ietf.org Subject: Re: [NSIS] question for clarification > It sounds like you're trying to articulate an architectural principle, > but I don't understand what it is or how you justify it. Put a packet into the network with a valid destination address and allow IP-layer routing to determine how it gets from here to there. If applications start determining routes for traffic, you run into problems like suboptimal routes, tromboning, and so forth, and you can only avoid those by pushing routing state into the applications themselves. That starts to interfere with network robustness (recovery from outages, convergence after routing changes, etc.) and greatly increases the complexity of both the network and the application. > Nobody's talking about adding a routing protocol: we've got too many of > them already. Sure you are. If you're telling the IP layer how to route packets, you're a routing protocol. > And certainly there are precedents in IP for requesting > particular routing treatments (source routing and the security field > come immediately to mind). You'll note that source routed packets are usually dropped. I'm not sure what you mean by "security field" - are you referring to the DS byte? That's an in-band signaling mechanism, not a routing mechanism. > I don't understand why you'd need an upper layer routing protocol for > this or why there's so much of a separation of concerns that would > warrant creating a new layer. It's generally appropriate to route among entities at the same layer. So, for VoIP the signaling problem is how to route to appropriate gateways, not how to choose the routers the traffic will traverse en route. For content networking it's how to find the appropriate cache. And so on. That's one aspect of "layer." The other layering question is related to the NSIS protocol itself. There appears to be widespread agreement that the NSIS protocol will be split into two layers; one providing the NSIS transport and protocol machinery and the other providing the data representing the NSIS request (see Bob Braden's two-layer draft). This provides greater generality/power in the base protocol and resolves some of the weaknesses that prevent RSVP from being a more general-purpose signaling protocol. It seems clear to me that to the extent that routing should be treated as an NSIS function, and I'm not convinced that it should, it belongs in the upper layer, not the transport, and we're not working on the upper layer yet. Melinda _______________________________________________ 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 daemon@optimus.ietf.org Tue Aug 6 17:14:49 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29217 for ; Tue, 6 Aug 2002 17:14:49 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA04100 for nsis-archive@odin.ietf.org; Tue, 6 Aug 2002 17:16:04 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA02191; Tue, 6 Aug 2002 16:51:56 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA02160 for ; Tue, 6 Aug 2002 16:51:54 -0400 (EDT) Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28524 for ; Tue, 6 Aug 2002 16:50:39 -0400 (EDT) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate2.mot.com (motgate2 2.1) with ESMTP id NAA15235; Tue, 6 Aug 2002 13:51:47 -0700 (MST)] Received: [from noah.dma.isg.mot.com (noah.dma.isg.mot.com [150.21.2.29]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id NAA29997; Tue, 6 Aug 2002 13:51:46 -0700 (MST)] Received: from dma.isg.mot.com (ma07-0056.dma.isg.mot.com [150.21.30.201]) by noah.dma.isg.mot.com (8.8.8+Sun/8.8.8) with ESMTP id QAA09219; Tue, 6 Aug 2002 16:51:46 -0400 (EDT) Message-ID: <3D5036E2.4DFF921C@dma.isg.mot.com> Date: Tue, 06 Aug 2002 16:51:46 -0400 From: Dan Grossman X-Mailer: Mozilla 4.5 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Melinda Shore CC: nsis@ietf.org Subject: Re: [NSIS] question for clarification References: <200208061918.AES31039@mira-sjc5-4.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 7bit Melinda Shore wrote: > > It sounds like you're trying to articulate an architectural principle, > > but I don't understand what it is or how you justify it. > > Put a packet into the network with a valid destination > address and allow IP-layer routing to determine how it gets > from here to there. But IP violates this principle at a much lower level of abstraction (strict source route, loose source route, security options). Do you propose to move those things to 'historic'? Besides, that still doesn't address the point that the applications (or human end users) may have policy objectives that they need the routing system to take into account in making next hop forwarding decisions for the flow. Or, rather, changing one or more next-hop forwarding decisions from the default. The IP routing layer **is** determining how it gets from here to there, just doing so consistent with policy requests. > If applications start determining > routes for traffic, you run into problems like suboptimal > routes, tromboning, and so forth, and you can only avoid > those by pushing routing state into the applications > themselves. This is true if you're doing (loose) source route. If the NSIS protocol just provides policy-type requests that the network can either act upon or reject, then I don't see a need. Or if you did need that kind of information, it would probably be very aggregated and very static. > That starts to interfere with network > robustness (recovery from outages, convergence after routing > changes, etc.) and greatly increases the complexity of both > the network and the application. > > > Nobody's talking about adding a routing protocol: we've got too many of > > them already. > > Sure you are. If you're telling the IP layer how to route > packets, you're a routing protocol. Maybe your definitions of "routing protocol" and "signalling protocol" are different from mine. I understand a routing protocol to distribute information related to network topology. I understand a signalling protocol to allow hosts and routers to establish, maintain and release state information and resources associated with flows (and groups of flows). Mechanisms in a signalling protocol that request establishment of a flow whose path has particular characteristics do not make it a routing protocol. > > > > And certainly there are precedents in IP for requesting > > particular routing treatments (source routing and the security field > > come immediately to mind). > > You'll note that source routed packets are usually dropped. From RFC 1812: "A router MUST implement support for source route options in forwarded packets. A router MAY implement a configuration option that, when enabled, causes all source-routed packets to be discarded. However, such an option MUST NOT be enabled by default." So either folks are building routers that aren't compliant with RFC1812, or operators are turning on an optional configuration option. That doesn't remove the architectural principle that packets can influence their own path through an IP network. > > I'm not sure what you mean by "security field" - are you > referring to the DS byte? That's an in-band signaling > mechanism, not a routing mechanism. Oops, I meant the US DOD Security Option (RFC1108)... I'd been looking at the Security Option in RFC791 and had forgotten that it was obsoleted a few times. > > > > I don't understand why you'd need an upper layer routing protocol for > > this or why there's so much of a separation of concerns that would > > warrant creating a new layer. > > It's generally appropriate to route among entities at the > same layer. So, for VoIP the signaling problem is how to > route to appropriate gateways, not how to choose the routers > the traffic will traverse en route. For content networking > it's how to find the appropriate cache. And so on. That's > one aspect of "layer." The other layering question is > related to the NSIS protocol itself. There appears to be > widespread agreement that the NSIS protocol will be split > into two layers; one providing the NSIS transport and > protocol machinery and the other providing the data > representing the NSIS request (see Bob Braden's two-layer > draft). This provides greater generality/power in the base > protocol and resolves some of the weaknesses that prevent > RSVP from being a more general-purpose signaling protocol. > It seems clear to me that to the extent that routing should > be treated as an NSIS function, and I'm not convinced that > it should, it belongs in the upper layer, not the transport, > and we're not working on the upper layer yet. Oh. In which case I disagree. This is a discussion about signalling to influence the IP layer path across IP networks. While it's true that higher layers would request these kinds of things from the IP layer, there's no reason to incorporate them in the higher layer signalling protocol, since the higher layer signalling protocol is not in any way acted upon by the IP network. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Tue Aug 6 17:22:50 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29682 for ; Tue, 6 Aug 2002 17:22:49 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA04292 for nsis-archive@odin.ietf.org; Tue, 6 Aug 2002 17:24:04 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA03970; Tue, 6 Aug 2002 17:13:08 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA03939 for ; Tue, 6 Aug 2002 17:13:06 -0400 (EDT) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.54]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29023 for ; Tue, 6 Aug 2002 17:11:51 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (IDENT:mirapoint@mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g76LCX6I026401; Tue, 6 Aug 2002 14:12:33 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id AES34933; Tue, 6 Aug 2002 14:08:33 -0700 (PDT) Message-Id: <200208062108.AES34933@mira-sjc5-4.cisco.com> To: Dan Grossman cc: Melinda Shore , nsis@ietf.org From: Melinda Shore Subject: Re: [NSIS] question for clarification In-Reply-To: Message from Dan Grossman of "Tue, 06 Aug 2002 16:51:46 EDT." <3D5036E2.4DFF921C@dma.isg.mot.com> Date: Tue, 06 Aug 2002 17:10:33 -0400 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org > But IP violates this principle at a much lower level of > abstraction (strict source route, loose source route, > security options). Do you propose to move those things to > 'historic'? Again, source routing is 1) rarely used, and 2) frequently dropped. I certainly wouldn't use its existence to argue much of anything. If you try to inject source routed packets into the network you'll see that they probably won't be delivered. But aside from that, source routing scales badly and is both unmanageable and unstable. IP was designed around different fundamental assumptions from the phone network, and if you don't respect the basic underlying design you start to have problems - consider the consequences of NAT, for example. > Besides, that still doesn't address the point that the > applications (or human end users) may have policy > objectives that they need the routing system to take into > account in making next hop forwarding decisions for the > flow. Of course they do. But telling the network what services you need (QoS, etc.) and leaving how (and whether) to do it up to the devices in the network is fundamentally different from telling the network how to route the packets. Probably the biggest lesson from midcom is that layer violation leads to topology problems, and having applications tell routers where to forward packets is a layer violation. > This is true if you're doing (loose) source route. If the > NSIS protocol just provides policy-type requests that the > network can either act upon or reject, then I don't see a > need. Policy requests are good, and I hope that we can remain focused on them rather than on the specifics of telling routers how to forward. Still, the policy belongs to an NSIS application, not NSIS transport. That is to say, what needs to be considered in this discussion is how using NSIS to carry the policy requests you're interested in might affect the NSIS protocol machinery. The policy application itself is not embedded in the protocol machinery (or at least it shouldn't be) - it's not part of the protocol itself. > Maybe your definitions of "routing protocol" and > "signalling protocol" are different from mine. I > understand a routing protocol to distribute information > related to network topology. I understand a signalling > protocol to allow hosts and routers to establish, maintain > and release state information and resources associated > with flows (and groups of flows). By that description, a routing protocol is an instance of a signaling protocol, right? Melinda _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Wed Aug 7 10:39:06 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20866 for ; Wed, 7 Aug 2002 10:39:06 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA14364 for nsis-archive@odin.ietf.org; Wed, 7 Aug 2002 10:40:19 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA13342; Wed, 7 Aug 2002 10:29:34 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA13307 for ; Wed, 7 Aug 2002 10:29:32 -0400 (EDT) Received: from motgate4.mot.com (motgate4.mot.com [144.189.100.102]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19839 for ; Wed, 7 Aug 2002 10:28:18 -0400 (EDT) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate4.mot.com (motgate4 2.1) with ESMTP id HAA14605; Wed, 7 Aug 2002 07:29:29 -0700 (MST)] Received: [from noah.dma.isg.mot.com (noah.dma.isg.mot.com [150.21.2.29]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id HAA07070; Wed, 7 Aug 2002 07:29:29 -0700 (MST)] Received: from dma.isg.mot.com (ma07-0056.dma.isg.mot.com [150.21.30.201]) by noah.dma.isg.mot.com (8.8.8+Sun/8.8.8) with ESMTP id KAA19597; Wed, 7 Aug 2002 10:29:28 -0400 (EDT) Message-ID: <3D512EC8.E9E1F039@dma.isg.mot.com> Date: Wed, 07 Aug 2002 10:29:28 -0400 From: Dan Grossman X-Mailer: Mozilla 4.5 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Melinda Shore CC: nsis@ietf.org Subject: Re: [NSIS] question for clarification References: <200208062108.AES34933@mira-sjc5-4.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 7bit Melinda Shore wrote: > > But IP violates this principle at a much lower level of > > abstraction (strict source route, loose source route, > > security options). Do you propose to move those things to > > 'historic'? > > Again, source routing is 1) rarely used, and 2) frequently > dropped. I certainly wouldn't use its existence to argue > much of anything. If you try to inject source routed > packets into the network you'll see that they probably won't > be delivered. But aside from that, source routing scales > badly and is both unmanageable and unstable. I stipulate that source routing is the wrong level of abstraction given some of the other architectural decisions in IP (it was the right decision in PNNI given PNNI's objectives). I do not wish to encourage its use. That doesn't invalidate the architectural principle that IP packets can and do have the means to affect their own path through the network. > IP was > designed around different fundamental assumptions from the > phone network, and if you don't respect the basic underlying > design you start to have problems - consider the > consequences of NAT, for example. I stipulate that NAT is a gross violation of several basic architectural principles. You realize that you just invalidated your argument that relates usage of some feature to its validity? Ah, the phone network shibboleth. I stipulate that IP was designed around different assumptions from the phone network. In some cases, this was prescient, and in other cases it was short sighted. We are trying to retrofit network awareness of flows into the nominally stateless IP forwarding path. Flows have paths. The question we're trying to answer is whether the path originator should have any influence on the path of the flow. This has nothing to do with the telephone network, and in fact many of the capabilities needed here are not an issue in the telephone network because the design of the telephone network *is* different that the design of the Internet.. > > > > Besides, that still doesn't address the point that the > > applications (or human end users) may have policy > > objectives that they need the routing system to take into > > account in making next hop forwarding decisions for the > > flow. > > Of course they do. But telling the network what services > you need (QoS, etc.) and leaving how (and whether) to do it > up to the devices in the network is fundamentally different > from telling the network how to route the packets. Probably > the biggest lesson from midcom is that layer violation leads > to topology problems, and having applications tell routers > where to forward packets is a layer violation. Nobody is proposing to put source routing into NSIS. I am proposing to put policy requests into NSIS that affect path calculations. Maybe we're arguing about an appropriate level of abstraction. I stipulate that putting a list of next-hop routers (or next hop networks) into NSIS messages is not the right thing to do. I suggest an option to request that a set of related flows follow the same (or reversed) paths, and probably others will think of options at the same level of abstraction. You suggest that there is something at a higher level of abstraction that will have the net result I'm looking for. What is it, please? > > > > This is true if you're doing (loose) source route. If the > > NSIS protocol just provides policy-type requests that the > > network can either act upon or reject, then I don't see a > > need. > > Policy requests are good, and I hope that we can remain > focused on them rather than on the specifics of telling > routers how to forward. Still, the policy belongs to an > NSIS application, not NSIS transport. That is to say, what > needs to be considered in this discussion is how using NSIS > to carry the policy requests you're interested in might > affect the NSIS protocol machinery. The policy application > itself is not embedded in the protocol machinery (or at > least it shouldn't be) - it's not part of the protocol > itself. There's message syntax and coding rules, there's message semantics and there's protocol procedures and abstract state machines. I stipulate that this is not a syntax/coding rules issue. We need to add semantics, procedures and state machines in order to do this. If you think that should be a different document, that's fine. > > > > Maybe your definitions of "routing protocol" and > > "signalling protocol" are different from mine. I > > understand a routing protocol to distribute information > > related to network topology. I understand a signalling > > protocol to allow hosts and routers to establish, maintain > > and release state information and resources associated > > with flows (and groups of flows). > > By that description, a routing protocol is an instance of a > signaling protocol, right? Wrong. Let me try again: Routing protocol: distributes network topology information represents global state of a network Signalling protocol: establishes/maintains/releases flows negotiates and reserves resources along a path establishes state only in those systems along the path of the flow(s) established Explain how a routing protocol is an instance of a signalling protocol? _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Wed Aug 7 11:21:07 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23070 for ; Wed, 7 Aug 2002 11:21:07 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA17210 for nsis-archive@odin.ietf.org; Wed, 7 Aug 2002 11:22:20 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA16764; Wed, 7 Aug 2002 11:12:35 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA16721 for ; Wed, 7 Aug 2002 11:12:30 -0400 (EDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22552 for ; Wed, 7 Aug 2002 11:11:16 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (IDENT:mirapoint@mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g77FBXAK022595; Wed, 7 Aug 2002 08:11:33 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id AES55150; Wed, 7 Aug 2002 08:07:34 -0700 (PDT) Message-Id: <200208071507.AES55150@mira-sjc5-4.cisco.com> To: Dan Grossman cc: nsis@ietf.org From: Melinda Shore Subject: Re: [NSIS] question for clarification In-Reply-To: Message from Dan Grossman of "Wed, 07 Aug 2002 10:29:28 EDT." <3D512EC8.E9E1F039@dma.isg.mot.com> Date: Wed, 07 Aug 2002 11:09:32 -0400 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org > I stipulate that source routing is the wrong level of abstraction given > some of the other architectural decisions in IP (it was the right > decision in PNNI given PNNI's objectives). I think it has a lot less to do with PNNI's objectives than it does to do with the design of ATM, which is label-switched and doesn't contain destination addresses in each cell. Because of that there's a need to temporarily wire routes for each flow into every switch along the path for the duration of the flow. > I stipulate that NAT is a gross violation of several basic architectural > principles. You realize that you just invalidated your argument that > relates usage of some feature to its validity? Not really, unless you think that choosing to use something that's bad is the same thing as not choosing to use something that's not good for general-purpose use. The reason that I raised the NAT issue is that it's a very good example of something that's not idiomatic to the underlying technology and that as a consequence of doing something that conflicts with basic design decisions, it's causing severe and fundamentally insoluble problems with both routing and security. I would not like to see NSIS make the same mistake. > Routing protocol: distributes network topology information > represents global state of a network > Signalling protocol: establishes/maintains/releases flows > negotiates and reserves resources along a > path > establishes state only in those systems > along the path of the flow(s) established > > Explain how a routing protocol is an instance of a signalling protocol? I don't agree with your definitions - for example, a signaling protocol needn't (and, in fact, doesn't) represent the global state of a network. And a signaling protocol needn't limit itself to on-path state manipulation, although NSIS does. Melinda _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Wed Aug 7 12:15:21 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26099 for ; Wed, 7 Aug 2002 12:15:21 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA21298 for nsis-archive@odin.ietf.org; Wed, 7 Aug 2002 12:16:35 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA20993; Wed, 7 Aug 2002 12:06:53 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA20959 for ; Wed, 7 Aug 2002 12:06:51 -0400 (EDT) Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25652 for ; Wed, 7 Aug 2002 12:05:36 -0400 (EDT) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate.mot.com (motgate 2.1) with ESMTP id JAA06485; Wed, 7 Aug 2002 09:06:38 -0700 (MST)] Received: [from noah.dma.isg.mot.com (noah.dma.isg.mot.com [150.21.2.29]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id JAA26576; Wed, 7 Aug 2002 09:06:38 -0700 (MST)] Received: from dma.isg.mot.com (ma07-0056.dma.isg.mot.com [150.21.30.201]) by noah.dma.isg.mot.com (8.8.8+Sun/8.8.8) with ESMTP id MAA20210; Wed, 7 Aug 2002 12:06:37 -0400 (EDT) Message-ID: <3D51458D.FEA1DBFD@dma.isg.mot.com> Date: Wed, 07 Aug 2002 12:06:37 -0400 From: Dan Grossman X-Mailer: Mozilla 4.5 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Melinda Shore CC: nsis@ietf.org Subject: Re: [NSIS] question for clarification References: <200208071507.AES55150@mira-sjc5-4.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 7bit I think we've strayed from the original topic, but I'll respond anyway. Melinda Shore wrote: > > I stipulate that source routing is the wrong level of abstraction given > > some of the other architectural decisions in IP (it was the right > > decision in PNNI given PNNI's objectives). > > I think it has a lot less to do with PNNI's objectives than > it does to do with the design of ATM, which is > label-switched and doesn't contain destination addresses in > each cell. Because of that there's a need to temporarily > wire routes for each flow into every switch along the path > for the duration of the flow. No, it could have done next hop path computations on a distributed basis like OSPF or IS/IS, differing only that it configured VPI/VCI mappings for the next hop rather than forwarding a single packet. In fact, some folks initially thought we could pretty much reuse OSPF, until we looked a bit deeper at the requirements. The reason for the designated transit list was to allow QoS objectives and QoS and policy metrics to be used in path calculation (difficult to do in a distributed algorithm in bounded time), and to make crankback not keep retrying paths that don't work. It is true that hard state and labels (VPI/VCI) make the cost of getting a path wrong a lot greater, and reduce the computational and overhead cost of path calculation and DTL transport per user data packet (at least for long-lived virtual connections). So what was a good decision for PNNI was not a good decision for IP. I suspect you could argue that it might be a good decision if you were doing NSIS and a new routing protocol on a clean sheet of paper. But since we don't have a clean sheet of paper, it's a moot point. In any event, this is off topic. > > > > I stipulate that NAT is a gross violation of several basic architectural > > principles. You realize that you just invalidated your argument that > > relates usage of some feature to its validity? > > Not really, unless you think that choosing to use something > that's bad is the same thing as not choosing to use > something that's not good for general-purpose use. The > reason that I raised the NAT issue is that it's a very good > example of something that's not idiomatic to the underlying > technology and that as a consequence of doing something that > conflicts with basic design decisions, it's causing severe > and fundamentally insoluble problems with both routing and > security. I would not like to see NSIS make the same > mistake. You still haven't made a convincing case why putting policy requests for paths into NSIS is bad. > > > > Routing protocol: distributes network topology information > > represents global state of a network > > Signalling protocol: establishes/maintains/releases flows > > negotiates and reserves resources along a > > path > > establishes state only in those systems > > along the path of the flow(s) established > > > > Explain how a routing protocol is an instance of a signalling protocol? > > I don't agree with your definitions - for example, a > signaling protocol needn't (and, in fact, doesn't) represent > the global state of a network. I assume you mean routing protocol here. And if a map of link state doesn't define a relevant portion of the global state of the network, I'm not sure what does. > And a signaling protocol > needn't limit itself to on-path state manipulation, although > NSIS does. Well, ok, there are some cases where entities not along the path of the flow might need to be manipulated. I think that those are higher layer signalling cases rather than happening at the NSIS level, which is why I wasn't thinking about them. The point is that signalling protocols generally don't distribute information across entire (non-trivial) networks. > > > > Melinda _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Wed Aug 7 17:43:25 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10625 for ; Wed, 7 Aug 2002 17:43:25 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA10534 for nsis-archive@odin.ietf.org; Wed, 7 Aug 2002 17:44:38 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA10322; Wed, 7 Aug 2002 17:36:17 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA10291 for ; Wed, 7 Aug 2002 17:36:15 -0400 (EDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10325 for ; Wed, 7 Aug 2002 17:35:01 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (IDENT:mirapoint@mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g77LZjpD002557; Wed, 7 Aug 2002 14:35:45 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id AES70294; Wed, 7 Aug 2002 14:31:44 -0700 (PDT) Message-Id: <200208072131.AES70294@mira-sjc5-4.cisco.com> To: Dan Grossman cc: nsis@ietf.org From: Melinda Shore Subject: Re: [NSIS] question for clarification In-Reply-To: Message from Dan Grossman of "Wed, 07 Aug 2002 12:06:37 EDT." <3D51458D.FEA1DBFD@dma.isg.mot.com> Date: Wed, 07 Aug 2002 17:33:42 -0400 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org > From: Dan Grossman > You still haven't made a convincing case why putting > policy requests for paths into NSIS is bad. "Convincing" is almost entirely subjective, of course. It's not that I think that putting policy requests for paths into nsis is bad but that I don't think it's universally good. That is to say, it depends on the policy being requested. A lot of this depends on your base assumptions, as well. My starting point is that nsis's job is to figure out what went wrong with RSVP and to try to fix that, if necessary. From my perspective RSVP is very, very good for situations in which you'd like to request services from the network but you don't know where network entities are. It is less good for situations in which you either already know where entities are or in which you want to affect routing. Part of it is the question of where knowledge of current routing state is retained, which affects the ability of participating entities to be able to respond to network events like outages and routing changes. A related problem is bootstrapping and the ability to tie the signaling path to the data path. In the default case, where you simply send a packet into the network and let IP routing take care of figuring out which routers must be traversed, you can predict with a high degree of reliability that the signaling data and the data flow will follow the same path. When there's policy in there that creates differentials between packet treatment based not on the destination address but on some other piece of information, you need to ensure that the signaling messages will flow along the same path that the data will take. Using the signaling messages to install the differential policy along the appropriate path is going to be difficult. It also assumes that you've already got some knowledge of network topology, which I continue to believe creates more problems than it solves. Part of the reason that I'm particularly hinky about this is that an unimplementable QoS architecture is coming out of some of the VoIP standards bodies that shares some features with what you're proposing. At any rate, as I said I understand why you want to do that but I don't understand why you want to do it that way. MPLS will solve the same problem cleaner and more reliably, as will using tunnels or relays. I'd really rather see nsis remain focused on the case where network topology is initially opaque to applications. Melinda _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Wed Aug 7 18:31:54 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12153 for ; Wed, 7 Aug 2002 18:31:54 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA12776 for nsis-archive@odin.ietf.org; Wed, 7 Aug 2002 18:33:08 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA12114; Wed, 7 Aug 2002 18:24:59 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA12063 for ; Wed, 7 Aug 2002 18:24:57 -0400 (EDT) Received: from oemcomputer.maine.rr.com (ptd-24-198-51-104.maine.rr.com [24.198.51.104]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11768 for ; Wed, 7 Aug 2002 18:23:43 -0400 (EDT) From: biligi@kanser-tedavisi.com Message-Id: <200208072223.SAA11768@ietf.org> To: nsis@ietf.org Date: Thu, 8 Aug 2002 01:23:10 +0300 MIME-Version: 1.0 (produced by Synapse) x-mailer: Synapse - Delphi & Kylix TCP/IP library by Lukas Gebauer Content-type: text/plain; charset=ISO-8859-1 Content-Disposition: inline Content-Description: Message text Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from Quoted-printable to 8bit by optimus.ietf.org id SAA12064 Subject: [NSIS] kanser tedavis Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Kemoterapi veya radyoterapinin yan etkileri ile bogusan bir yakininiz varsa, www.kanser-tedavisi.com a ugrayin ve bitkisel kanser ilaci Carctolu taniyin. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Thu Aug 8 08:08:06 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08843 for ; Thu, 8 Aug 2002 08:08:06 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA27341 for nsis-archive@odin.ietf.org; Thu, 8 Aug 2002 08:09:20 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA26553; Thu, 8 Aug 2002 07:56:51 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA26522 for ; Thu, 8 Aug 2002 07:56:49 -0400 (EDT) Received: from yahoo.co.kr ([211.42.218.202]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA08629 for ; Thu, 8 Aug 2002 07:55:33 -0400 (EDT) Message-Id: <200208081155.HAA08629@ietf.org> Reply-To: sang21@yahoo.co.kr From: mysun To: Mime-Version: 1.0 Content-Type: text/html; charset="ks_c_5601-1987" Date: Thu, 8 Aug 2002 20:57:28 +0900 Subject: [NSIS] you should know truth Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Untitled

Lies!  Lies!

RECOVER CHINA'S WORTHINESS

PLEASE SAVE LINK FILES BELOW IF YOU DON'T WATCH MOVIE PROPERLY.
JUST I WANT TO INFORM YOU REAL EVENTS.  

Video link

 
  (56k) (128k)
  (56k) (128k)   (56k) (128k)

Book link

word file

pdf file

chm file

_______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Thu Aug 8 10:44:49 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14168 for ; Thu, 8 Aug 2002 10:44:49 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA05976 for nsis-archive@odin.ietf.org; Thu, 8 Aug 2002 10:46:05 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA05362; Thu, 8 Aug 2002 10:34:57 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA05330 for ; Thu, 8 Aug 2002 10:34:55 -0400 (EDT) Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13727 for ; Thu, 8 Aug 2002 10:33:38 -0400 (EDT) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate2.mot.com (motgate2 2.1) with ESMTP id HAA24839; Thu, 8 Aug 2002 07:34:52 -0700 (MST)] Received: [from noah.dma.isg.mot.com (noah.dma.isg.mot.com [150.21.2.29]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id HAA06039; Thu, 8 Aug 2002 07:34:51 -0700 (MST)] Received: from dma.isg.mot.com (ma07-0056.dma.isg.mot.com [150.21.30.201]) by noah.dma.isg.mot.com (8.8.8+Sun/8.8.8) with ESMTP id KAA02082; Thu, 8 Aug 2002 10:34:50 -0400 (EDT) Message-ID: <3D52818A.FD8CDDD5@dma.isg.mot.com> Date: Thu, 08 Aug 2002 10:34:50 -0400 From: Dan Grossman X-Mailer: Mozilla 4.5 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Melinda Shore CC: nsis@ietf.org Subject: Re: [NSIS] question for clarification References: <200208072131.AES70294@mira-sjc5-4.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 7bit Melinda, Thank you for the clarifying your position. Now that I understand where you're coming from, we can at least agree to narrow the scope of our disagreement, maybe even agree. > "Convincing" is almost entirely subjective, of course. It's > not that I think that putting policy requests for paths into > nsis is bad but that I don't think it's universally good. > That is to say, it depends on the policy being requested. I think we're close here. I would expect policy requests to be exceptional or restricted to certain environments (as in PacketCable). I also agree that we would need to set some architectural guidelines for what represents 'good' types of policy requests and what represents architectural abominations. > > > A lot of this depends on your base assumptions, as well. My > starting point is that nsis's job is to figure out what went > wrong with RSVP and to try to fix that, if necessary. This sounds like a whole 'nother thread. Perhaps it played out on the list while I was procrastinating about joining. Needless to say, I have my own ideas about what went wrong, and would write them down if prompted to do so. > From > my perspective RSVP is very, very good for situations in > which you'd like to request services from the network but > you don't know where network entities are. It is less good > for situations in which you either already know where > entities are or in which you want to affect routing. Part > of it is the question of where knowledge of current routing > state is retained, which affects the ability of > participating entities to be able to respond to network > events like outages and routing changes. That sounds like the beginnings of an architectural principle, to the effect that any policy that can safely be invoked only with knowledge of current routing state can only be invoked by an entity that posesses current routing state. > > > A related problem is bootstrapping and the ability to tie > the signaling path to the data path. In the default case, > where you simply send a packet into the network and let IP By "simply send a packet", do you mean a signalling packet or a user data packet? I assume the former for now... > > routing take care of figuring out which routers must be > traversed, you can predict with a high degree of reliability > that the signaling data and the data flow will follow the > same path. When there's policy in there that creates > differentials between packet treatment based not on the I assume you mean "flow treatment' rather than 'packet treatment" here. That is, the router makes a next hop forwarding decision based on the signalling message's destination IP address (and possibly some policy requests), binds it to a flowspec and then forwards the signalling packet to that next hop. > > destination address but on some other piece of information, > you need to ensure that the signaling messages will flow > along the same path that the data will take. Agreed. > Using the > signaling messages to install the differential policy along > the appropriate path is going to be difficult. Can you explain? > It also > assumes that you've already got some knowledge of network > topology, which I continue to believe creates more problems > than it solves. Which 'you'? > > > Part of the reason that I'm particularly hinky about this is > that an unimplementable QoS architecture is coming out of > some of the VoIP standards bodies that shares some features > with what you're proposing. I've tried with considerable success to keep clear of deep involvement in VoIP signalling, so don't know the issues that you're raising. On the other hand, I've had deep involvement over many years with ISDN, Frame Relay, and ATM signalling and think that there are lessons to be learned there. As an aside, I think that some of what went wrong with RSVP stems in part from failure to learn lessons from ISDN and SS7 protocols and their progeny. > > > At any rate, as I said I understand why you want to do that > but I don't understand why you want to do it that way. MPLS > will solve the same problem cleaner and more reliably, as > will using tunnels or relays. Well, yes, but I don't think that anybody is talking about MPLS-to-the-desktop (or to the MTA). In fact, in the context of this discussion, doing so would require far more knowledge of routing state (and thus heavyweight routing implementation) than would be desirable in the ends or even in the edges. > I'd really rather see nsis > remain focused on the case where network topology is > initially opaque to applications. I think we might be able to agree with an architectural principle that says that we quantify how much network topology knowlege is required for a particular policy option, and that we forbid any entity from using that option unless it has at least that much topology knowledge. I'm sure we could agree that mechanisms for topology discovery (other than as side-effects like "no, you can't do that, destination unreachable") are out of scope for NSIS. Dan _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Aug 9 21:42:57 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17594 for ; Fri, 9 Aug 2002 21:42:57 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA02423 for nsis-archive@odin.ietf.org; Fri, 9 Aug 2002 21:44:11 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA02341; Fri, 9 Aug 2002 21:37:48 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA02293 for ; Fri, 9 Aug 2002 21:37:46 -0400 (EDT) Received: from oemcomputer.maine.rr.com (ptd-24-198-51-104.maine.rr.com [24.198.51.104]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17285 for ; Fri, 9 Aug 2002 21:36:31 -0400 (EDT) From: bilgi@kanser-tedavisi.com Message-Id: <200208100136.VAA17285@ietf.org> To: nsis@ietf.org Date: Sat, 10 Aug 2002 04:36:56 +0300 MIME-Version: 1.0 (produced by Synapse) x-mailer: Synapse - Delphi & Kylix TCP/IP library by Lukas Gebauer Content-type: text/plain; charset=ISO-8859-1 Content-Disposition: inline Content-Description: Message text Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from Quoted-printable to 8bit by optimus.ietf.org id VAA02294 Subject: [NSIS] kanser tedavisi Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Kemoterapinin yan etkileri nedeniyle yorgun ve bitkin düsmüs bir yakininiz mi var? Yanitiniz evetse vakit kaybetmeyin ve CARCTOL'u denemesini saglayin. Genelde ancak klasik tedavinin ise yaramadiginin anlasilmasi, insanlari baska seçenekler aramaya itmektedir, ancak o durumda maalesef yapacak fazla birsey kalmamaktadir. Ayni hatanin yapilmasina izin vermeyin ve hiçbir yan etkisi olmayan, Himalaya Dagi bitkilerinden üretilen Carctol'u denemesini saglayin. CARCTOL, birkaç bin yillik, alternatif Hint Tibbinin (Ayuverda'nin) insanliga sundugu bir umut isigidir. Önceleri vücudu takviye edici tonik olarak kullanilan bu ürün simdi yeni formülüyle kansere karsi etkili bir ilaçtir Lütfen asagidaki siteye ugrayin ve Carctol'u yakindan taniyin. http://www.kanser-tedavisi.com esenlikler dileriz.. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Sun Aug 11 20:28:18 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25230 for ; Sun, 11 Aug 2002 20:28:18 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA27007 for nsis-archive@odin.ietf.org; Sun, 11 Aug 2002 20:29:34 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA26426; Sun, 11 Aug 2002 20:21:10 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA26385 for ; Sun, 11 Aug 2002 20:21:08 -0400 (EDT) Received: from odin.ietf.org ([216.139.170.13]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA24973 for ; Sun, 11 Aug 2002 20:19:48 -0400 (EDT) Message-Id: <200208120019.UAA24973@ietf.org> From: "Malik Abacha" Date: Sun, 02 Jan 2000 16:36:50 To: nsis@ietf.org MIME-Version: 1.0 Content-Type: text/plain;charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [NSIS] REPLY AS SOON AS POSSIBLE Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 7bit ATTN:SIR, My wish at its peak is that you're in good health because health is wealth. I know you dont know me so I have to introduce myself to you. My name is Muhameed Abacha, a second cousin to the late Nigerian Head of state Gen.Sani Abacha who rule between 1993 and 1998. For more reference to me I would love you to know more about my uncle. Please view this site and read it contents carefully; http://news.bbc.co.uk/hi/english/world/africa/newsid_741000/741506.stm During the 4th year of his rule, he gave me a sum of US$23M to boost my business which I just opened in Ogba area of Lagos. Unfortunately, the complex which I was using as a ware-house got burnt by a very ragious inferno. I decided to keep the money until the next year when I would start importing new goods from a contractor in Germany which I had signed earlier before the incident. My uncle died the next year and everything blew up, the new government started probing the whole family members and freezed most of the family accounts. To cut the long story short, they have not detected the money which I secured in a Security company in Holland. Please, I would need you to assist me in retrieving the fund from the company because if I want to retrieve it and they know my identity they would definitely freeze the money in their account. What you have to do is very simple, you will claim the fund as a beneficiary from a contract which was executed by an uncle of yours. All paper works would be put in place for you to claim the money for me. The total amount involved is US$16.5M. 10% would be for any expenses incured during the transaction, 30% would be for your support, while the remaining 60% remains mine. I'm an African who believes in divine direction and you have been divinely chosen to handle this transaction. I hope to hear from you soon. Thanks. Yours Muhameed Abacha. Alternate e-mail address:m_abacha@sify.com _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Mon Aug 12 03:36:35 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA12247 for ; Mon, 12 Aug 2002 03:36:35 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA22639 for nsis-archive@odin.ietf.org; Mon, 12 Aug 2002 03:37:51 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA21629; Mon, 12 Aug 2002 03:25:33 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA21602 for ; Mon, 12 Aug 2002 03:25:31 -0400 (EDT) Received: from cawutao ([61.144.216.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA12051 for ; Mon, 12 Aug 2002 03:24:11 -0400 (EDT) Message-Id: <200208120724.DAA12051@ietf.org> From: "¡°ËÉÆÕ¡±---ÎâÌÎ" To: "nsis" Mime-Version: 1.0 Content-Type: text/plain; charset="GB2312" Date: Mon, 12 Aug 2002 15:25:21 +0800 X-Priority: 3 X-Mailer: JiXing mailer V1.73 Design By JohnnieHuang Subject: [NSIS] ¡°ËÉÆÕ¡±ÎªÄúµÄ²¼Ïß·½°¸ÌṩǿÓÐÁ¦µÄÖ§³ÖÓë±£ÕÏ Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org ×ܾ­Àí£º ÄãºÃ£¡ ¹ú¼ÊÖªÃ÷Æ·ÅÆ¡°ËÉÆÕ¡±ÎªÄúµÄ²¼Ïß·½°¸ÌṩǿÓÐÁ¦µÄÖ§³ÖÓë±£ÕÏ¡£ ÉîÛÚÊаÙÄêËÉÆÕÐÅÏ¢¼¼ÊõÓÐÏÞ¹«Ë¾£¬ÊÇÒ»¼ÒÑз¢¡¢Éú²ú¡¢ÏúÊÛ¿í ´øÍøÂç½ÓÈëÉ豸¼°Îª²»Í¬ÐÐÒµ¿Í»§Ìṩ¶¨ÖÆ»¯¸ßÐԼ۱ȵÄ"¿í´øÍøÂç Á¬½Ó"½â¾ö·½°¸µÄ¸ß¿Æ¼¼¹«Ë¾£¬ÊÇÓ¢¹ú°ÙÄêͶ×ʹËÎʼ¯ÍÅÓę̈ÍåÉÏÊÐ ¹«Ë¾ËÉÆտƼ¼£¨SUNPU Technology Co., Ltd.£©ÔÚÖйú´ó½µÄºÏ×÷ ¹«Ë¾£¬Îª"ËÉÆÕ"Æ·ÅƲ¼ÏßϵÁвúÆ·ÔÚÖйúµØÇøµÄÊг¡Ñо¿¡¢Íƹ㡢ÐÐ Ïú¡¢·þÎñ¡¢Ö§³ÖµÄ»ú¹¹£¬Ïò¸÷Àà¿Í»§Ìṩ¾ßÓоø¶ÔÖʸ߼ÛÓŵĸßÐÔÄÜ µÄ²úÆ·¡£ÏÖÔÚÉîÛÚÉèÓжþ¼Ò¹¤³§¡£ ¸ù¾Ý¿í´øÍøÂçµÄ·¢Õ¹Ç÷ÊÆ£¬ÎÒÃÇÏò¿Í»§Ìṩ¸ßÐԼ۱ȵĵIJúÆ·£º 1¡¢³¬ÎåÀà¡¢ÁùÀàÆÁ±Î¼°·ÇÆÁ±ÎË«½ÊÏß¡£ 2¡¢½Ó²åÔª¼þ¡£ 3¡¢Á¬½ÓÅä¼þµÈ¡£ ËÉÆÕ²¼Ïß²úÆ·¼°Ó¦ÓÃϵͳ£¬×¿ÉÀ©Õ¹ÖÁÒ»°ÙÄêÐÔÄÜÆ·Öʱ£Ö¤£¬ ¸Ã±£Ö¤ÓÉÎÒ¹«Ë¾Í¨¹ýÖйúÈËÃñ±£ÏÕ¹«Ë¾³Ðµ££¬Ê¹ÄúÔÚÍøÂçÉϵÄͶ×Ê£¬ »ñµÃ×î´óµÄ±£ÕÏ¡£ »¶Ó­ä¯ÀÀÎÒÃǵÄÍøÕ¾£ºhttp://www.broadlinker.com »òÕߵ绰ÓëÎÒÃÇÁªÏµ£¬Ë÷È¡¸üÏêϸµÄ×ÊÁÏ¡£ ÎÒÃǽ«ÓÐרҵµÄÈËԱΪÄú·þÎñ¡£ ÁªÏµµç»°£º0755-83664411 83664422 83664433 ´« Õ棺0755-83664499 Áª ϵ ÈË£ºÎâ ÌÎ 13823338529 E---mail: cawutao@21cn.com ========================================================================== ÖÐ×ÊÔ´¹«Ë¾http://www.net001.net ÌṩÓòÃûÏÈ×¢²áºó¸¶¿î;Ö÷»úÏÈ¿ªÍ¨ºóÊÕ·Ñ·þÎñ, ÖÐ;¿ÉÍË¿î¡£ÌØ»ÝÍƼö£ºÓòÃû+100MÖ÷»ú²¢¸½ËÍ5¸ö10MÆóÒµÓÊÏ䣬ÿÄêÖ»Ðè350Ôª£¡£¡ ʹÓü«ÐÇÓʼþȺ·¢£¬ÎÞÐëͨ¹ýÓʼþ·þÎñÆ÷£¬Ö±´ï¶Ô·½ÓÊÏ䣬ËٶȾø¶ÔÒ»Á÷£¡ ÏÂÔØÍøÖ·£ºhttp://www.lovexin.com£¬¸ü¶àÃâ·ÑµÄ³¬¿áÈí¼þµÈÄãÀ´Ï¡­¡­ _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Mon Aug 12 06:21:31 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14870 for ; Mon, 12 Aug 2002 06:21:31 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA00563 for nsis-archive@odin.ietf.org; Mon, 12 Aug 2002 06:22:47 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA00338; Mon, 12 Aug 2002 06:16:19 -0400 (EDT) Received: from cawutao ([61.144.216.40]) by optimus.ietf.org (8.9.1a/8.9.1) with SMTP id GAA00255 for ; Mon, 12 Aug 2002 06:16:15 -0400 (EDT) Message-Id: <200208121016.GAA00255@optimus.ietf.org> From: "¡°ËÉÆÕ¡±---ÎâÌÎ" To: "nsis" Mime-Version: 1.0 Content-Type: text/plain; charset="GB2312" Date: Mon, 12 Aug 2002 18:16:08 +0800 X-Priority: 3 X-Mailer: JiXing mailer V1.73 Design By JohnnieHuang Subject: [NSIS] ¡°ËÉÆÕ¡±ÎªÄúµÄ²¼Ïß·½°¸ÌṩǿÓÐÁ¦µÄÖ§³ÖÓë±£ÕÏ Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org ×ܾ­Àí£º ÄãºÃ£¡ ¹ú¼ÊÖªÃ÷Æ·ÅÆ¡°ËÉÆÕ¡±ÎªÄúµÄ²¼Ïß·½°¸ÌṩǿÓÐÁ¦µÄÖ§³ÖÓë±£ÕÏ¡£ ÉîÛÚÊаÙÄêËÉÆÕÐÅÏ¢¼¼ÊõÓÐÏÞ¹«Ë¾£¬ÊÇÒ»¼ÒÑз¢¡¢Éú²ú¡¢ÏúÊÛ¿í ´øÍøÂç½ÓÈëÉ豸¼°Îª²»Í¬ÐÐÒµ¿Í»§Ìṩ¶¨ÖÆ»¯¸ßÐԼ۱ȵÄ"¿í´øÍøÂç Á¬½Ó"½â¾ö·½°¸µÄ¸ß¿Æ¼¼¹«Ë¾£¬ÊÇÓ¢¹ú°ÙÄêͶ×ʹËÎʼ¯ÍÅÓę̈ÍåÉÏÊÐ ¹«Ë¾ËÉÆտƼ¼£¨SUNPU Technology Co., Ltd.£©ÔÚÖйú´ó½µÄºÏ×÷ ¹«Ë¾£¬Îª"ËÉÆÕ"Æ·ÅƲ¼ÏßϵÁвúÆ·ÔÚÖйúµØÇøµÄÊг¡Ñо¿¡¢Íƹ㡢ÐÐ Ïú¡¢·þÎñ¡¢Ö§³ÖµÄ»ú¹¹£¬Ïò¸÷Àà¿Í»§Ìṩ¾ßÓоø¶ÔÖʸ߼ÛÓŵĸßÐÔÄÜ µÄ²úÆ·¡£ÏÖÔÚÉîÛÚÉèÓжþ¼Ò¹¤³§¡£ ¸ù¾Ý¿í´øÍøÂçµÄ·¢Õ¹Ç÷ÊÆ£¬ÎÒÃÇÏò¿Í»§Ìṩ¸ßÐԼ۱ȵĵIJúÆ·£º 1¡¢³¬ÎåÀà¡¢ÁùÀàÆÁ±Î¼°·ÇÆÁ±ÎË«½ÊÏß¡£ 2¡¢½Ó²åÔª¼þ¡£ 3¡¢Á¬½ÓÅä¼þµÈ¡£ ËÉÆÕ²¼Ïß²úÆ·¼°Ó¦ÓÃϵͳ£¬×¿ÉÀ©Õ¹ÖÁÒ»°ÙÄêÐÔÄÜÆ·Öʱ£Ö¤£¬ ¸Ã±£Ö¤ÓÉÎÒ¹«Ë¾Í¨¹ýÖйúÈËÃñ±£ÏÕ¹«Ë¾³Ðµ££¬Ê¹ÄúÔÚÍøÂçÉϵÄͶ×Ê£¬ »ñµÃ×î´óµÄ±£ÕÏ¡£ »¶Ó­ä¯ÀÀÎÒÃǵÄÍøÕ¾£ºhttp://www.broadlinker.com »òÕߵ绰ÓëÎÒÃÇÁªÏµ£¬Ë÷È¡¸üÏêϸµÄ×ÊÁÏ¡£ ÎÒÃǽ«ÓÐרҵµÄÈËԱΪÄú·þÎñ¡£ ÁªÏµµç»°£º0755-83664411 83664422 83664433 ´« Õ棺0755-83664499 Áª ϵ ÈË£ºÎâ ÌÎ 13823338529 E---mail: cawutao@21cn.com ========================================================================== ÖÐ×ÊÔ´¹«Ë¾http://www.net001.net ÌṩÓòÃûÏÈ×¢²áºó¸¶¿î;Ö÷»úÏÈ¿ªÍ¨ºóÊÕ·Ñ·þÎñ, ÖÐ;¿ÉÍË¿î¡£ÌØ»ÝÍƼö£ºÓòÃû+100MÖ÷»ú²¢¸½ËÍ5¸ö10MÆóÒµÓÊÏ䣬ÿÄêÖ»Ðè350Ôª£¡£¡ ʹÓü«ÐÇÓʼþȺ·¢£¬ÎÞÐëͨ¹ýÓʼþ·þÎñÆ÷£¬Ö±´ï¶Ô·½ÓÊÏ䣬ËٶȾø¶ÔÒ»Á÷£¡ ÏÂÔØÍøÖ·£ºhttp://www.lovexin.com£¬¸ü¶àÃâ·ÑµÄ³¬¿áÈí¼þµÈÄãÀ´Ï¡­¡­ _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Wed Aug 14 07:38:19 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05117 for ; Wed, 14 Aug 2002 07:38:19 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA23393 for nsis-archive@odin.ietf.org; Wed, 14 Aug 2002 07:39:38 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA23053; Wed, 14 Aug 2002 07:32:50 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA23022 for ; Wed, 14 Aug 2002 07:32:47 -0400 (EDT) Received: from yahoo.co.kr ([211.42.218.202]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA04915 for ; Wed, 14 Aug 2002 07:31:27 -0400 (EDT) Message-Id: <200208141131.HAA04915@ietf.org> Reply-To: sang21@yahoo.co.kr From: òØà¼ìÛ To: Mime-Version: 1.0 Content-Type: text/html; charset="ks_c_5601-1987" Date: Wed, 14 Aug 2002 20:33:41 +0900 Subject: [NSIS] jiang's reputation of the world Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Á¦¸ñ ¾øÀ½

_______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Aug 16 08:03:04 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12587 for ; Fri, 16 Aug 2002 08:03:04 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA28180 for nsis-archive@odin.ietf.org; Fri, 16 Aug 2002 08:04:25 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA27136; Fri, 16 Aug 2002 07:47:52 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA27110 for ; Fri, 16 Aug 2002 07:47:50 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12121; Fri, 16 Aug 2002 07:46:26 -0400 (EDT) Message-Id: <200208161146.HAA12121@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: nsis@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Fri, 16 Aug 2002 07:46:26 -0400 Subject: [NSIS] I-D ACTION:draft-ietf-nsis-req-04.txt Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Next Steps in Signaling Working Group of the IETF. Title : Requirements for Signaling Protocols Author(s) : M. Brunner Filename : draft-ietf-nsis-req-04.txt Pages : 38 Date : 15-Aug-02 This document defines requirements for signaling across different network environments, where different network environments across administrative and technology domains. Signaling is mainly though for QoS such as [1], however in recent year several other applications of signaling have been defined such as signaling for MPLS label distribution [2]. To achieve wide applicability of the requirements, the starting point is a diverse set of scenarios/use cases concerning various types of networks and application interactions. We also provide an outline structure for the problem, including related terminology. Taken with the scenarios, this allows us to focus more precisely on which parts of the overall problem need to be solved. We present the assumptions and the aspects not considered within scope before listing the requirements grouped according to areas such as architecture and design goals, signaling flows, layering, performance, flexibility, security, and mobility. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nsis-req-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-nsis-req-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-nsis-req-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020815150909.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nsis-req-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nsis-req-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020815150909.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Tue Aug 20 00:41:42 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24190 for ; Tue, 20 Aug 2002 00:41:42 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id AAA04569 for nsis-archive@odin.ietf.org; Tue, 20 Aug 2002 00:43:05 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA04057; Tue, 20 Aug 2002 00:31:38 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA04010 for ; Tue, 20 Aug 2002 00:31:34 -0400 (EDT) Received: from mail.carington.com (cvg-65-29-198-42.cinci.rr.com [65.29.198.42]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23950; Tue, 20 Aug 2002 00:30:10 -0400 (EDT) Received: from mail168.finestoffers.com ([61.145.75.241]) by mail.carington.com (8.12.5/8.12.5) with SMTP id g7K4V9Dq020245; Tue, 20 Aug 2002 00:31:10 -0400 Message-Id: <200208200431.g7K4V9Dq020245@mail.carington.com> Date: Tue, 20 Aug 2002 12:32:23 +0800 From: "Donald Scott" X-Mailer: The Bat! (v1.53d) X-Priority: 3 To: nsirt@aol.com CC: nsis-request@ietf.org, nsis@ietf.org, nsiskowic@caprica.com, nsisok@earthlink.net Mime-Version: 1.0 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [NSIS] Forever Young HGH! Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 7bit
Hello, nsirt@aol.com

Human Growth Hormone Therapy

Lose weight while building lean muscle mass
and reversing the ravages of aging all at once.
As seen on NBC, CBS, and CNN, and even Oprah! The health
discovery that actually reverses aging while burning fat,
without dieting or exercise! This proven discovery has even
been reported on by the New England Journal of Medicine.
Forget aging and dieting forever! And it's Guaranteed!

Lose Weight
Build Muscle Tone
Reverse Aging
Increased Libido
Duration Of Penile Erection

Healthier Bones
Improved Memory
Improved skin
New Hair Growth
Wrinkle Disappearance

Visit Our Web Site and Learn The Facts : Click Here

OR Here


You are receiving this email as a subscriber
to the Opt-In America Mailing List.
To remove yourself from all related maillists,
just Click Here
_______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Aug 21 16:13:48 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24001 for ; Wed, 21 Aug 2002 16:13:47 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g7LKElV05739 for nsis-archive@odin.ietf.org; Wed, 21 Aug 2002 16:14:47 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by optimus.ietf.org (8.11.6/8.11.6) with ESMTP id g7LKEhW05731; Wed, 21 Aug 2002 16:14:43 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by optimus.ietf.org (8.11.6/8.11.6) with ESMTP id g7LKDCW05690 for ; Wed, 21 Aug 2002 16:13:12 -0400 Received: from idcpa4.pa.interdigital.com (idcmail.interdigital.com [12.32.197.142]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23915 for ; Wed, 21 Aug 2002 16:11:42 -0400 (EDT) Received: by idcpa4.pa.interdigital.com with Internet Mail Service (5.5.2653.19) id ; Wed, 21 Aug 2002 16:11:30 -0400 Message-ID: From: "Shahrier, Sharif M." To: "'Hancock, Robert'" , "'Dan Grossman'" , brunner@ccrle.nec.de Cc: jkchoi , "Shahrier, Sharif M." , nsis@ietf.org, "Kiernan, Brian G." Subject: RE: [NSIS] question for clarification Date: Wed, 21 Aug 2002 16:11:29 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , I had just returned from vacation, thus have not been keeping up with the mailing-list. I have some comments. c) i doubt that a bidirectional reservation would be simpler than individual unidirectional ones, rather you could do grouping to get the same effect with very little extra complexity. I presented a bi-directional reservation scheme at the last IETF meeting. It showed that there is a reduction in the number of signaling messages in bi-directional reservation compared to individual unidirectional ones. Thus, clearly bi-directional should be simpler, with less overhead. Sharif. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Aug 22 06:11:22 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20435 for ; Thu, 22 Aug 2002 06:11:22 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g7MACIW16783 for nsis-archive@odin.ietf.org; Thu, 22 Aug 2002 06:12:18 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by optimus.ietf.org (8.11.6/8.11.6) with ESMTP id g7MACFW16767; Thu, 22 Aug 2002 06:12:15 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by optimus.ietf.org (8.11.6/8.11.6) with ESMTP id g7MABiW16750 for ; Thu, 22 Aug 2002 06:11:44 -0400 Received: from cawutao ([61.144.216.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA20404 for ; Thu, 22 Aug 2002 06:10:16 -0400 (EDT) Message-Id: <200208221010.GAA20404@ietf.org> From: "¡°ËÉÆÕ¡±---ÎâÌÎ" To: "nsis" Mime-Version: 1.0 Content-Type: text/plain; charset="GB2312" Date: Thu, 22 Aug 2002 18:10:33 +0800 X-Priority: 3 X-Mailer: JiXing mailer V1.73 Design By JohnnieHuang Subject: [NSIS] ¡°ËÉÆÕ¡±ÎªÄúµÄ²¼Ïß·½°¸ÌṩǿÓÐÁ¦µÄÖ§³ÖÓë±£ÕÏ Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , ×ܾ­Àí£º ÄãºÃ£¡ ¹ú¼ÊÖªÃ÷Æ·ÅÆ¡°ËÉÆÕ¡±ÎªÄúµÄ²¼Ïß·½°¸ÌṩǿÓÐÁ¦µÄÖ§³ÖÓë±£ÕÏ¡£ ÉîÛÚÊаÙÄêËÉÆÕÐÅÏ¢¼¼ÊõÓÐÏÞ¹«Ë¾£¬ÊÇÒ»¼ÒÑз¢¡¢Éú²ú¡¢ÏúÊÛ¿í ´øÍøÂç½ÓÈëÉ豸¼°Îª²»Í¬ÐÐÒµ¿Í»§Ìṩ¶¨ÖÆ»¯¸ßÐԼ۱ȵÄ"¿í´øÍøÂç Á¬½Ó"½â¾ö·½°¸µÄ¸ß¿Æ¼¼¹«Ë¾£¬ÊÇÓ¢¹ú°ÙÄêͶ×ʹËÎʼ¯ÍÅÓę̈ÍåÉÏÊÐ ¹«Ë¾ËÉÆտƼ¼£¨SUNPU Technology Co., Ltd.£©ÔÚÖйú´ó½µÄºÏ×÷ ¹«Ë¾£¬Îª"ËÉÆÕ"Æ·ÅƲ¼ÏßϵÁвúÆ·ÔÚÖйúµØÇøµÄÊг¡Ñо¿¡¢Íƹ㡢ÐÐ Ïú¡¢·þÎñ¡¢Ö§³ÖµÄ»ú¹¹£¬Ïò¸÷Àà¿Í»§Ìṩ¾ßÓоø¶ÔÖʸ߼ÛÓŵĸßÐÔÄÜ µÄ²úÆ·¡£ÏÖÔÚÉîÛÚÉèÓжþ¼Ò¹¤³§¡£ ¸ù¾Ý¿í´øÍøÂçµÄ·¢Õ¹Ç÷ÊÆ£¬ÎÒÃÇÏò¿Í»§Ìṩ¸ßÐԼ۱ȵĵIJúÆ·£º 1¡¢³¬ÎåÀà¡¢ÁùÀàÆÁ±Î¼°·ÇÆÁ±ÎË«½ÊÏß¡£ 2¡¢½Ó²åÔª¼þ¡£ 3¡¢Á¬½ÓÅä¼þµÈ¡£ ËÉÆÕ²¼Ïß²úÆ·¼°Ó¦ÓÃϵͳ£¬×¿ÉÀ©Õ¹ÖÁÒ»°ÙÄêÐÔÄÜÆ·Öʱ£Ö¤£¬ ¸Ã±£Ö¤ÓÉÎÒ¹«Ë¾Í¨¹ýÖйúÈËÃñ±£ÏÕ¹«Ë¾³Ðµ££¬Ê¹ÄúÔÚÍøÂçÉϵÄͶ×Ê£¬ »ñµÃ×î´óµÄ±£ÕÏ¡£ »¶Ó­ä¯ÀÀÎÒÃǵÄÍøÕ¾£ºhttp://www.broadlinker.com »òÕߵ绰ÓëÎÒÃÇÁªÏµ£¬Ë÷È¡¸üÏêϸµÄ×ÊÁÏ¡£ ÎÒÃǽ«ÓÐרҵµÄÈËԱΪÄú·þÎñ¡£ ÁªÏµµç»°£º0755-83664411 83664422 83664433 ´« Õ棺0755-83664499 Áª ϵ ÈË£ºÎâ ÌÎ 13823338529 E---mail: cawutao@21cn.com ========================================================================== ÖÐ×ÊÔ´¹«Ë¾http://www.net001.net ÌṩÓòÃûÏÈ×¢²áºó¸¶¿î;Ö÷»úÏÈ¿ªÍ¨ºóÊÕ·Ñ·þÎñ, ÖÐ;¿ÉÍË¿î¡£ÌØ»ÝÍƼö£ºÓòÃû+100MÖ÷»ú²¢¸½ËÍ5¸ö10MÆóÒµÓÊÏ䣬ÿÄêÖ»Ðè350Ôª£¡£¡ ʹÓü«ÐÇÓʼþȺ·¢£¬ÎÞÐëͨ¹ýÓʼþ·þÎñÆ÷£¬Ö±´ï¶Ô·½ÓÊÏ䣬ËٶȾø¶ÔÒ»Á÷£¡ ÏÂÔØÍøÖ·£ºhttp://www.lovexin.com£¬¸ü¶àÃâ·ÑµÄ³¬¿áÈí¼þµÈÄãÀ´Ï¡­¡­ _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Aug 27 23:50:21 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA22632 for ; Tue, 27 Aug 2002 23:50:21 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g7S3pUL23857 for nsis-archive@odin.ietf.org; Tue, 27 Aug 2002 23:51:30 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g7S3pQo23847; Tue, 27 Aug 2002 23:51:26 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g7RJGgo28188 for ; Tue, 27 Aug 2002 15:16:42 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06546 for <1timer>; Tue, 27 Aug 2002 14:44:44 -0400 (EDT) Message-Id: <200208271844.OAA06546@ietf.org> From: Phil Roberts To: IETF WG Participants: ; Date: Tue, 27 Aug 2002 14:44:44 -0400 Subject: [NSIS] Nomcom call for volunteers Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , The members of the IESG and IAB and the IETF chair are selected by a nominations committee made up of volunteers from the IETF community. The nominations committee is now in the process of being formed and volunteers are being accepted until Sep 6. Please see (http://www.ietf.org/nomcom/msg19765.html) for information if you are interested in volunteering to be on the nominations committee. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Aug 28 21:58:13 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27636 for ; Wed, 28 Aug 2002 21:58:13 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g7T1xLo04533 for nsis-archive@odin.ietf.org; Wed, 28 Aug 2002 21:59:21 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g7T1xHo04525; Wed, 28 Aug 2002 21:59:17 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g7T1wVo04478 for ; Wed, 28 Aug 2002 21:58:31 -0400 Received: from yahoo.com ([218.76.246.28]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA27572 for ; Wed, 28 Aug 2002 21:56:34 -0400 (EDT) From: gtts1@cable.net.co Received: from 179.110.205.194 ([179.110.205.194]) by web13708.mail.yahoo.com with QMQP; Tue, 27 Aug 2002 10:58:19 -0000 Reply-To: Message-ID: <42EA0286-BACA-11D6-B365-00E0188F81AA@SpiY6SDn> To: Date: Wed, 28 Aug 2002 22:00:43 -0400 MiME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_00U8_69X80A1B.C1121G32" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal Subject: [NSIS] Laser Print Supplies Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , ------=_NextPart_000_00U8_69X80A1B.C1121G32 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: base64 PGh0bWw+DQo8eC10YWI+DQoNCjxoZWFkPg0KPC9oZWFkPg0KDQo8cCBhbGlnbj0iY2VudGVyIj4N CjxiPjxhIGhyZWY9Im1haWx0bzpndHRzMUBjYWJsZS5uZXQuY28iPjxmb250IGNvbG9yPSIjMDAw MDgwIiBzaXplPSIzIiBmYWNlPSJBcmlhbCI+R1QgVE9ORVINClNVUFBMSUVTPGJyPkxhc2VyIHBy aW50ZXIgYW5kIGNvbXB1dGVyIHN1cHBsaWVzPGJyPg0KICAxLTg2Ni0yMzctNzM5NzwvZm9udD48 L2E+PC9iPg0KDQo8cCBhbGlnbj0iY2VudGVyIj4NCjxpbWcgYm9yZGVyPSIwIiANCnNyYz0iaHR0 cDovL2ltYWdlcy5nb29nbGUuY29tL2ltYWdlcz9xPXRibjp0R2kyNWJCR000b0M6ZGF0YWRldmlj ZXMuaG9tZS5taW5kc3ByaW5nLmNvbS80MDAwcHJpbnRlci5qcGciIHdpZHRoPSI4MSIgDQpoZWln aHQ9IjY5Ij4NCjxpbWcgYm9yZGVyPSIwIiBzcmM9Imh0dHA6Ly9pbWFnZXMuZ29vZ2xlLmNvbS9p bWFnZXM/cT10Ym46WW9BdDRyVG1aOHNDOnd3dy5jYXJ0cmlkZ2UtZmlsbC5jby51ay9ncm9vcHBy aW50ZXIuZ2lmIiANCndpZHRoPSI4MSIgaGVpZ2h0PSI2OSI+DQo8cD4NCjxiPjxpPjxmb250IGNv bG9yPSIjODA4MDAwIiBmYWNlPSJBcmlhbCIgc2l6ZT0iNCI+U2F2ZSB1cCB0byA0MCUgZnJvbSBy ZXRhaWwgcHJpY2Ugb24gbGFzZXIgcHJpbnRlciB0b25lcg0KY2FydHJpZGdlcyw8YnI+DQpjb3Bp ZXIgYW5kIGZheCBjYXJ0cmlkZ2VzLjwvZm9udD48L2k+DQo8L2I+IDwvcD4NCjxwPg0KPGI+PGk+ PGEgaHJlZj0iI3ByaWNlcyI+PGZvbnQgZmFjZT0iQ29taWMgU2FucyBNUyIgc2l6ZT0iMyIgY29s b3I9IiMwMDAwRkYiPkNIRUNLIE9VVCBPVVIgR1JFQVQNClBSSUNFUyE8L2ZvbnQ+PC9hPjwvaT4N CjwvYj4gPC9wPg0KPHA+PGI+PGk+PGZvbnQgY29sb3I9IiM4MDAwMCIgc2l6ZT0iMyIgZmFjZT0i Q29taWMgU2FucyBNUyI+SWYgeW91IHJlY2VpdmVkIHRoaXMgZW1haWwgb24gZXJyb3IsIHBsZWFz ZSByZXBseSB0byANCmd0dHMxQGNhYmxlLm5ldC5jbyB3aXRoIHN1YmplY3Q6IFJFTU9WRS4uLiBz b3JyeSBmb3IgdGhlIGluY29udmVuaWVuY2UuDQo8cD48Yj48aT48Zm9udCBjb2xvcj0iIzgwODAw MCIgc2l6ZT0iNCIgZmFjZT0iQXJpYWwiPlBsZWFzZSBmb3J3YXJkIHRvIHRoZSBwZXJzb24gcmVz cG9uc2libGUgZm9yIHB1cmNoYXNpbmcgeW91ciBsYXNlciANCnByaW50ZXINCnN1cHBsaWVzLjwv Zm9udD48L2k+DQo8L3A+DQo8cD48Zm9udCBmYWNlPSJBcmlhbCIgc2l6ZT0iMiI+PGZvbnQgY29s b3I9IiM4MDgwMDAiPjx4LXRhYj4mbmJzcDsmbmJzcDsmbmJzcDsgT3JkZXIgYnkNCnBob25lOiAo dG9sbCBmcmVlKSAxLTg2Ni0yMzctNzM5Nw0KPC9mb250Pjxmb250IGNvbG9yPSIjMDAwMDgwIj4g PGJyPg0KPC9mb250Pg0KPC9wPg0KPC9mb250Pjxmb250IGNvbG9yPSIjODA4MDAwIj48eC10YWI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7IE9yZGVyIGJ5IGVtYWlsOiA8L2ZvbnQ+DQo8L2ZvbnQ+DQo8Zm9u dCBjb2xvcj0iIzAwMDBGRiIgZmFjZT0iQXJpYWwiIHNpemU9IjMiPlNpbXBseSByZXBseTwvZm9u dD48Zm9udCBjb2xvcj0iIzAwMDA4MCI+IHRoaXMgbWVzc2FnZSBvciA8L2ZvbnQ+PGEgDQpocmVm PSJtYWlsdG86Z3R0czFAY2FibGUubmV0LmNvIj48Zm9udCBjb2xvcj0iIzAwMDBGRiIgZmFjZT0i QXJpYWwiIHNpemU9IjMiPmNsaWNrIGhlcmU8L2ZvbnQ+PC9hPjxmb250IGZhY2U9IkFyaWFsIiAN CnNpemU9IjIiPjxmb250IGNvbG9yPSIjODA4MDAwIj4mbmJzcDsNCndpdGggc3ViamVjdDogPC9m b250Pjxmb250IGNvbG9yPSIjMDAwMDgwIj4gT1JERVI8L2ZvbnQ+DQo8L2ZvbnQ+DQo8L3A+DQo8 cD48Zm9udCBmYWNlPSJBcmlhbCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7PC9mb250PjwvYj4gPGZvbnQg ZmFjZT0iQXJpYWwiPiA8Yj4gPGZvbnQgc2l6ZT0iMiI+IDxmb250IGNvbG9yPSIjODA4MDAwIj5F bWFpbA0KcmVtb3ZhbDogPC9mb250Pjxmb250IGNvbG9yPSIjMDAwMDgwIj5TaW1wbHkgcmVwbHkg dGhpcyBtZXNzYWdlIG9yIDwvZm9udD4NCjwvZm9udD4NCjxhIGhyZWY9Im1haWx0bzpndHRzMUBj YWJsZS5uZXQuY28iPjxmb250IHNpemU9IjMiIGNvbG9yPSIjMDAwMEZGIj5jbGljayBoZXJlPC9m b250PjwvYT4gPGZvbnQgc2l6ZT0iMiI+IDxmb250IA0KY29sb3I9IiM4MDgwMDAiPg0KPHgtdGFi PiZuYnNwOyB3aXRoIHN1YmplY3Q6DQo8L2ZvbnQ+PGZvbnQgY29sb3I9IiMwMDAwODAiPiBSRU1P VkU8L2ZvbnQ+PGZvbnQgY29sb3I9IiM4MDgwMDAiPg0KPGJyPjxicj4NCjwvZm9udD4NCjwvZm9u dD4NCjxmb250IGNvbG9yPSIjMDAwMDgwIiBzaXplPSI0Ij5Vbml2ZXJzaXR5PC9mb250PiA8Zm9u dCBzaXplPSIyIj4gIGFuZC9vcg0KPC9mb250Pg0KPGZvbnQgY29sb3I9IiMwMDAwODAiIHNpemU9 IjQiPlNjaG9vbDwvZm9udD48Zm9udCBzaXplPSIzIj4gPC9mb250PiA8Zm9udCBzaXplPSIyIj4g cHVyY2hhc2UNCm9yZGVycyBXRUxDT01FLiAobm8gY3JlZGl0IGFwcHJvdmFsIHJlcXVpcmVkKTxi cj4NClBheSBieSBjaGVjaywgYy5vLmQsIG9yIHB1cmNoYXNlIG9yZGVyIChuZXQgMzAgZGF5cyku DQo8L2ZvbnQ+DQo8L2I+DQo8L2ZvbnQ+DQo8L3A+DQo8cD48Yj48aT48Zm9udCBjb2xvcj0iIzAw MDA4MCIgc2l6ZT0iMyI+V0UgQUNDRVBUIEFMTCBNQUpPUiBDUkVESVQgQ0FSRFMhPC9mb250Pjwv aT48L2I+DQo8L3A+DQo8cD48Yj48YSBocmVmPSIjY29sb3IiPjxmb250IGZhY2U9IkFyaWFsIiBz aXplPSIzIj5OZXchIEhQIDQ1MDAvNDU1MCBzZXJpZXMgY29sb3INCmNhcnRyaWRnZXMgaW4gc3Rv Y2shPC9mb250PjwvYT48L2I+DQo8L3A+DQo8cCBhbGlnbj0ibGVmdCI+IDxmb250IHNpemU9IjIi PiA8Yj4NCjxpPjxmb250IGNvbG9yPSIjODA4MDAwIiBmYWNlPSJBcmlhbCI+DQpPdXIgY2FydHJp ZGdlIHByaWNlcyBhcmUgYXMgZm9sbG93czogPGJyPg0KKHBsZWFzZSBvcmRlciBieSBpdGVtIG51 bWJlcik8L2ZvbnQ+PC9pPg0KPC9iPg0KPC9mb250Pg0KPC9wPg0KPHAgYWxpZ249ImxlZnQiPiA8 Yj48Zm9udCBmYWNlPSJMdWNpZGEgU2FucyBUeXBld3JpdGVyIiBjb2xvcj0iIzAwMDAwMCIgDQpz aXplPSIzIj5JdGVtJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQpIZXdsZXR0DQog ICAgIFBhY2thcmQ8YSANCm5hbWU9InByaWNlcyI+PC9hPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYg0Kc3A7Jm5ic3A7Jm5ic3A7DQpQcmljZTwvZm9udD48L2I+DQo8L3A+DQo8 cCBhbGlnbj0ibGVmdCI+IDx0dD48Zm9udCBjb2xvcj0iIzAwMDAwMCI+PGI+PGZvbnQgc2l6ZT0i MiI+MSAtLSA5MjI3NEEgVG9uZXIgQ2FydHJpZGdlIGZvciBMYXNlckpldCA0TCwgNE1MLCA0UCwg NE1QDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0kNDcuNTA8YnI+DQo8L2ZvbnQ+DQo8c3BhbiBz dHlsZT0iYmFja2dyb3VuZC1jb2xvcjogI0M0QzRBNiI+DQo8Zm9udCBzaXplPSIyIj4NCjIgLS0g QzQwOTJBIEJsYWNrIFRvbmVyIENhcnRyaWRnZSBmb3IgTGFzZXJKZXQgMTEwMEEsIEFTRSwgMzIw MFNFLS0tLS0tLS0tLS0tLS0tLS0kNDUuNTA8YnI+DQo8L2ZvbnQ+DQo8L3NwYW4+DQo8Zm9udCBz aXplPSIyIj4NCjJBIC0gQzcxMTVBIFRvbmVyIENhcnRyaWRnZSBGb3IgSFAgTGFzZXJKZXQgMTAw MCwgMTIwMCwgMzMzMCAtLS0tLS0tLS0tLS0tLS0tLS0tLS0kNTUuNTA8YnI+DQo8c3BhbiBzdHls ZT0iYmFja2dyb3VuZC1jb2xvcjogI0M0QzRBNiI+DQoyQiAtIEM3MTE1WCBIaWdoIENhcGFjaXR5 IFRvbmVyIENhcnRyaWRnZSBmb3IgSFAgTGFzZXJKZXQgMTAwMCwgMTIwMCwgMzMzMCAtLS0tLS0t JDY1LjUwPGJyPg0KPC9zcGFuPg0KMyAtLSA5MjI5NUEgVG9uZXIgQ2FydHJpZGdlIGZvciBMYXNl ckpldCBJSSwgSUlELCBJSUksIElJSUQgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSQ0OS41MDxicj4N CjxzcGFuIHN0eWxlPSJiYWNrZ3JvdW5kLWNvbG9yOiAjQzRDNEE2Ij4NCjQgLS0gOTIyNzVBIFRv bmVyIENhcnRyaWRnZSBmb3IgTGFzZXJKZXQgSUlQLCBJSVArLCBJSUlQIC0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0kNTUuNTA8YnI+DQo8L3NwYW4+DQo1IC0tIEMzOTAzQSBUb25lciBDYXJ0cmlk Z2UgZm9yIExhc2VySmV0IDVQLCA1TVAsIDZQLCA2UHNlLCA2TVAsIDZQeGkgLS0tLS0tLS0tLS0t JDQ2LjUwPGJyPg0KPHNwYW4gc3R5bGU9ImJhY2tncm91bmQtY29sb3I6ICNDNEM0QTYiPg0KNiAt LSBDMzkwOUEgVG9uZXIgQ2FydHJpZGdlIGZvciBMYXNlckpldCA1U2ksIDVTaU1YLCA1U2kgQ29w aWVyLCA4MDAwIC0tLS0tLS0tLS0tLSQ5Mi41MDxicj4NCjwvc3Bhbj4NCjcgLS0gQzQwOTZBIFRv bmVyIENhcnRyaWRnZSBmb3IgTGFzZXJKZXQgMjEwMCwgMjIwMERTRSwgMjIwMERUTiAtLS0tLS0t LS0tLS0tLS0tLS0kNzIuNTA8YnI+DQo8c3BhbiBzdHlsZT0iYmFja2dyb3VuZC1jb2xvcjogI0M0 QzRBNiI+DQo4IC0gQzQxODJYIFVsdHJhUHJlY2lzZSBIaWdoIENhcGFjaXR5IFRvbmVyIENhcnRy aWRnZSBmb3IgTGFzZXJKZXQgODEwMCBTZXJpZXMtLS0kMTI1LjUwPGJyPg0KPC9zcGFuPg0KOSAt LSBDMzkwNkEgVG9uZXIgQ2FydHJpZGdlIGZvciBMYXNlckpldCA1TCwgNUwgWHRyYSwgNkxzZSwg NkwsIDZMeGksIDMxMDBzZS0tLS0tLSQ0Mi41MCA8YnI+DQo8c3BhbiBzdHlsZT0iYmFja2dyb3Vu ZC1jb2xvcjogI0M0QzRBNiI+DQo5QSAtIEMzOTA2QSBUb25lciBDYXJ0cmlkZ2UgZm9yIExhc2Vy SmV0IDMxMDAsIDMxNTAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tJDQyLjUwPGJyPg0K PC9zcGFuPg0KMTAgLSBDMzkwMEEgQmxhY2sgVG9uZXIgQ2FydHJpZGdlIGZvciBIUCBMYXNlckpl dCA0TVYsIDRWIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSQ4OS41MDxicj4NCjxzcGFuIHN0eWxl PSJiYWNrZ3JvdW5kLWNvbG9yOiAjQzRDNEE2Ij4NCjExIC0gQzQxMjdBIEJsYWNrIFRvbmVyIENh cnRyaWRnZSBmb3IgTGFzZXJKZXQgNDAwMFNFLCA0MDAwTiwgNDAwMFQsIDQwMDBUTiAtLS0tLS0k NzYuNTA8YnI+DQo8L3NwYW4+DQoxMUEtIEM4MDYxQSBCbGFjayBMYXNlciBUb25lciBmb3IgSFAg TGFzZXJKZXQgNDEwMCwgNDEwME4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tJDc2LjUwPGJyPg0K PHNwYW4gc3R5bGU9ImJhY2tncm91bmQtY29sb3I6ICNDNEM0QTYiPg0KMTFCLSBDODA2MVggSGln aCBDYXBhY2l0eSBUb25lciBDYXJ0cmlkZ2UgZm9yIExKNDEwMCwgNDEwME4gLS0tLS0tLS0tLS0t LS0tLS0tLS0tLSQ4NS41MDxicj4NCjwvc3Bhbj4NCjExQy0gQzQxMjdYIEhpZ2ggQ2FwYWNpdHkg QmxhY2sgQ2FydHJpZGdlIGZvciBMYXNlckpldCA0MDAwU0UsNDAwME4sNDAwMFQsNDAwMFRODQot JDg0LjUwPGJyPg0KPHNwYW4gc3R5bGU9ImJhY2tncm91bmQtY29sb3I6ICNDNEM0QTYiPg0KMTIg LSA5MjI5MUEgVG9uZXIgQ2FydHJpZGdlIGZvciBMYXNlckpldCBJSUlTaSwgNFNpLCA0U2lNWCAt LS0tLS0tLS0tLS0tLS0tLS0tLS0tLSQ1Ny41MDxicj4NCjwvc3Bhbj4NCjEzIC0gOTIyOThBIFRv bmVyIENhcnRyaWRnZSBmb3IgTGFzZXJKZXQgNCwgNCBQbHVzLCA0TSwgNE0gUGx1cywgNSwgNXNl LCA1TSwgNU4NCi0tJDQ2LjUwPGJyPg0KPHNwYW4gc3R5bGU9ImJhY2tncm91bmQtY29sb3I6ICND NEM0QTYiPg0KMTQgLSBDNDEyOVggSGlnaCBDYXBhY2l0eSBCbGFjayBUb25lciBDYXJ0cmlkZ2Ug Zm9yIExhc2VySmV0IDUwMDBOIC0tLS0tLS0tLS0tLS0tLSQ5Ny41MDxicj4NCjwvc3Bhbj4NCjE1 IC0gTEFTRVJGQVggNTAwLCA3MDAgKEZYMSkgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0kNDkuMDA8YnI+DQo8c3BhbiBzdHlsZT0iYmFja2dyb3Vu ZC1jb2xvcjogI0M0QzRBNiI+DQoxNiAtIExBU0VSRkFYIDUwMDAsIDcwMDAgKEZYMikgLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tJDU0LjAwPGJyPg0K PC9zcGFuPg0KMTcgLSBMQVNFUkZBWCAoRlgzKSAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSQ0OS4wMDwvZm9udD48L2I+PGZvbnQg c2l6ZT0iMiI+PGJyPg0KPGI+PHNwYW4gc3R5bGU9ImJhY2tncm91bmQtY29sb3I6ICNDNEM0QTYi Pg0KMTggLSBMQVNFUkZBWCAoRlg0KSAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSQ0OS4wMDwvc3Bhbj48L2I+PC9mb250PjwvZm9u dD48L3R0Pg0KPC9wPg0KPHAgYWxpZ249ImxlZnQiPiA8Yj48Zm9udCBmYWNlPSJMdWNpZGEgU2Fu cyBUeXBld3JpdGVyIiANCnNpemU9IjMiPkl0ZW0mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCkhld2xldHQgUGFja2FyZCAt IENvbG9yPGEgDQpuYW1lPSJjb2xvciI+PC9hPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOw0KJm5ic3A7Jm5ic3A7DQpQcmljZTwvZm9udD48L2I+DQo8L3A+DQo8cCBhbGlnbj0ibGVm dCI+IDx0dD48Yj48c3BhbiBzdHlsZT0iYmFja2dyb3VuZC1jb2xvcjogI0M0QzRBNiI+PGZvbnQg ZmFjZT0iTHVjaWRhIFNhbnMgVHlwZXdyaXRlciIgc2l6ZT0iMiIgDQpjb2xvcj0iIzAwMDAwMCI+ QzEgLS0gQzQxOTRhIFRvbmVyDQpDYXJ0cmlkZ2UsDQpZZWxsb3cgKGNvbG9yIGxqIDQ1MDAvNDU1 MCBzZXJpZXMpLS0tLS0tLS0tLS0tLS0tLS0tICQgODkuNTA8YnI+DQo8L2ZvbnQ+PC9zcGFuPjxm b250IGZhY2U9Ikx1Y2lkYSBTYW5zIFR5cGV3cml0ZXIiIHNpemU9IjIiIGNvbG9yPSIjMDAwMDAw Ij5DMiAtLSBDNDE5M2EgVG9uZXINCkNhcnRyaWRnZSwgTWFnZW50YSAoY29sb3IgbGogNDUwMC80 NTUwIHNlcmllcyktLS0tLS0tLS0tLS0tLS0tLQ0KJCA4OS41MDxicj4NCjxzcGFuIHN0eWxlPSJi YWNrZ3JvdW5kLWNvbG9yOiAjQzRDNEE2Ij5DMyAtLSBDNDE5MmEgdG9uZXIgY2FydHJpZGdlLCBj eWFuIChjb2xvciBsaiA0NTAwLzQ1NTAgc2VyaWVzKS0tLS0tLS0tLS0tLS0tLS0tLS0tICQNCjg5 LjUwPGJyPg0KPC9zcGFuPkM0IC0tIGM0MTkxYSB0b25lciBjYXJ0cmlkZ2UsIGJsYWNrIChjb2xv ciBsaiA0NTAwLzQ1NTAgc2VyaWVzKS0tLS0tLS0tLS0tLS0tLS0tLS0NCiQgNzQuNTA8L2ZvbnQ+ PC9iPjwvdHQ+DQo8L3A+DQo8cCBhbGlnbj0ibGVmdCI+IDxiPjxmb250IGZhY2U9Ikx1Y2lkYSBT YW5zIFR5cGV3cml0ZXIiIA0Kc2l6ZT0iMyI+SXRlbSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnMNCnA7Jm5ic3A7Jm5ic3A7DQpMZXhtYXJrJm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm4NCmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsNClByaWNlPC9mb250PjwvYj4NCjwvcD4NCjxwIGFsaWduPSJsZWZ0 Ij4gPHR0Pjxmb250IHNpemU9IjIiIGZhY2U9Ikx1Y2lkYSBTYW5zIFR5cGV3cml0ZXIiIGNvbG9y PSIjMDAwMDAwIj48Yj48c3BhbiBzdHlsZT0iYmFja2dyb3VuZC1jb2xvcjogDQojQzRDNEE2Ij4x OSAtIDEzODA1MjAgSGlnaCBZaWVsZCBCbGFjayBMYXNlciBUb25lciBmb3IgNDAxOSwgNDAxOUUs IDQwMjgsIDQwMjksIDYsIDEwLCAxMEwgLS0gJDEwOS41MDxicj4NCjwvc3Bhbj4yMCAtIDEzODIx NTAgSGlnaCBZaWVsZCBUb25lciBmb3IgMzExMiwgMzExNiwgNDAzOS0xMCssIDQwNDktIE1vZGVs IDEyTCwxNlIsDQpPcHRyYSAtICQxMDkuNTA8YnI+DQo8c3BhbiBzdHlsZT0iYmFja2dyb3VuZC1j b2xvcjogI0M0QzRBNiI+MjEgLSA2OUc4MjU2IExhc2VyIENhcnRyaWRnZSBmb3IgT3B0cmEgRSwN CkUrLCBFUCwgRVMsIDQwMjYsIDQwMjYgKDZBLDZCLDZELDZFKSZuYnNwOyAtLS0tICQgNDkuMDA8 YnI+DQo8L3NwYW4+MjIgLSAxM1QwMTAxIEhpZ2ggWWllbGQgVG9uZXIgQ2FydHJpZGdlIGZvciBM ZXhtYXJrIE9wdHJhIEUzMTAsIEUzMTIsIEUzMTJMIC0tLS0tLS0tICQgODkuMDA8YnI+DQo8c3Bh biBzdHlsZT0iYmFja2dyb3VuZC1jb2xvcjogI0M0QzRBNiI+MjMgLSAxMzgyNjI1IEhpZ2gtWWll bGQgTGFzZXIgVG9uZXIgQ2FydHJpZGdlIGZvciBMZXhtYXJrIE9wdHJhIFMgKDQwNTkpIC0tLS0t LS0tLS0tIA0KJDEyOS41MDxicj4NCjwvc3Bhbj4yNCAtIDEyQTU3NDUgSGlnaCBZaWVsZCBMYXNl ciBUb25lciBmb3IgTGV4bWFyayBPcHRyYSBUNjEwLCA2MTIsIDYxNCAoNDA2OSkgLS0tLS0tLS0g JDE2NS4wMDwvYj48L2ZvbnQ+PC90dD4NCjwvcD4NCjxwIGFsaWduPSJsZWZ0Ij4gPGI+PGZvbnQg ZmFjZT0iTHVjaWRhIFNhbnMgVHlwZXdyaXRlciIgDQpzaXplPSIzIj5JdGVtJm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQpFcHNvbiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnMNCnA7Jm5ic3A7Jm5ic3A7DQpQcmljZTwvZm9udD48L2I+DQo8 L3A+DQo8cCBhbGlnbj0ibGVmdCI+PHR0Pjxmb250IGNvbG9yPSIjMDAwMDAwIiBzaXplPSIyIiBm YWNlPSJMdWNpZGEgU2FucyBUeXBld3JpdGVyIj48Yj48c3BhbiBzdHlsZT0iYmFja2dyb3VuZC1j b2xvcjogDQojQzRDNEE2Ij4yNQ0KLS0tLSBTMDUxMDA5IFRvbmVyIENhcnRyaWRnZSBmb3IgRXBz b24gRVBMNzAwMCwgNzUwMCwgODAwMCsgLSAkMTE1LjUwPGJyPg0KPC9zcGFuPjI1QSAtLS0gUzA1 MTAwOSBMUC0zMDAwIFBTIDcwMDAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0gJDEx NS41MDxicj4NCjxzcGFuIHN0eWxlPSJiYWNrZ3JvdW5kLWNvbG9yOiAjQzRDNEE2Ij4yNiAtLS0t IEFTMDUxMDExIEltYWdpbmcgQ2FydHJpZGdlIGZvcg0KQWN0aW9uTGFzZXItMTAwMCwgMTUwMCAt LSAkIDk5LjUwPGJyPg0KPC9zcGFuPjI2QSAtLS0gQVMwNTEwMTEgRVBMLTUwMDAsIEVQTC01MTAw LCBFUEwtNTIwMCAtLS0tLS0tLS0tLS0tLS0tLS0gJCA5OS41MDxicj48L2I+PC9mb250Pg0KPC90 dD48L3A+DQo8cCBhbGlnbj0ibGVmdCI+PGI+PGZvbnQgZmFjZT0iTHVjaWRhIFNhbnMgVHlwZXdy aXRlciIgDQpzaXplPSIzIj5JdGVtJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQpQYW5hc29uaWMmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsNClByaWNlPC9mb250PjwvYj48L3A+DQo8cCBhbGlnbj0ibGVmdCI+ PHR0PjxzcGFuIHN0eWxlPSJiYWNrZ3JvdW5kLWNvbG9yOiAjQzRDNEE2Ij48Zm9udCBjb2xvcj0i IzAwMDAwMCIgZmFjZT0iTHVjaWRhIFNhbnMgVHlwZXdyaXRlciIgDQpzaXplPSIyIj48Yj4yNw0K LS0tLS0tTmVjIHNlcmllcyAyIG1vZGVscyA5MCBhbmQgOTUgLS0tLS0tLS0tLS0tLS0tLS0tLS0t LSAkMTA5LjUwPGJyPjwvYj48L2ZvbnQ+PC9zcGFuPjwvdHQ+PC9wPg0KPHAgYWxpZ249ImxlZnQi PjxiPjxmb250IGZhY2U9Ikx1Y2lkYSBTYW5zIFR5cGV3cml0ZXIiIA0Kc2l6ZT0iMyI+SXRlbSZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 DQpBcHBsZSZuYnNwOyANCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnMNCnA7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQpQcmljZTwvZm9udD48L2I+PC9wPg0KPHAgYWxpZ249Imxl ZnQiPjx0dD48Yj48Zm9udCBmYWNlPSJDb3VyaWVyIE5ldyIgc2l6ZT0iMiIgY29sb3I9IiMwMDAw MDAiPjxzcGFuIHN0eWxlPSJiYWNrZ3JvdW5kLWNvbG9yOiAjQzRDNEE2Ij4yOCANCi0tLS0gMjQ3 M0cvQSBMYXNlciBUb25lciBmb3IgTGFzZXJXcml0ZXIgUHJvIDYwMCwgNjMwLCBMYXNlcldyaXRl ciAxNi82MDAgUFMgLQ0KJCA1Ny41MDxicj4NCjwvc3Bhbj4yOSAtLS0tIDE5NjBHL0EgTGFzZXIg VG9uZXIgZm9yIEFwcGxlIExhc2VyV3JpdGVyIFNlbGVjdCwgMzAwLCAzMTAsIDM2MCAtLS0tLS0t LS0gJA0KNzEuNTA8YnI+DQo8c3BhbiBzdHlsZT0iYmFja2dyb3VuZC1jb2xvcjogI0M0QzRBNiI+ MzAgLS0tLSBNMDA4OUxML0EgVG9uZXIgQ2FydHJpZGdlIGZvciBMYXNlcndyaXRlciAzMDAsIDMy MCAoNzRBKSAtLS0tLS0tLS0tLS0tLS0tICQNCjUyLjUwPGJyPg0KPC9zcGFuPjMxIC0tLS0gTTYw MDIgVG9uZXIgQ2FydHJpZGdlIGZvciBMYXNlcndyaXRlciBJSU5ULCBJSU5UWCwgSUlTQywgSUlG LCBJSUcgKDk1QSkgLSAkDQo0Ny41MDxicj4NCjxzcGFuIHN0eWxlPSJiYWNrZ3JvdW5kLWNvbG9y OiAjQzRDNEE2Ij4zMUEgLS0tIE0wMDg5TEwvQSBUb25lciBDYXJ0cmlkZ2UgZm9yIExhc2Vyd3Jp dGVyDQpMUywgTlQsIE5UUiwgU0MgKDc1QSkgLS0tLS0tLS0tICQNCjU1LjUwPGJyPg0KPC9zcGFu PjMyIC0tLS0gTTQ2ODNHL0EgTGFzZXIgVG9uZXIgZm9yIExhc2VyV3JpdGVyIDEyLCA2NDBQUyAt LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KJCA4NS41MDxicj48L2ZvbnQ+PC9iPg0KPC90dD48 L3A+DQo8cCBhbGlnbj0ibGVmdCI+PGI+PGZvbnQgZmFjZT0iTHVjaWRhIFNhbnMgVHlwZXdyaXRl ciIgDQpzaXplPSIzIj5JdGVtJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQpDYW5v biZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnMNCnA7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQpQcmljZTwvZm9u dD48L2I+PC9wPg0KPHA+PHR0Pjxmb250IGNvbG9yPSIjMDAwMDAwIiBzaXplPSIyIiBmYWNlPSJM dWNpZGEgU2FucyBUeXBld3JpdGVyIj48Yj48c3BhbiBzdHlsZT0iYmFja2dyb3VuZC1jb2xvcjog I0M0QzRBNiI+MzMgLS0tIA0KRmF4DQpDRlgtTDM1MDAsIENGWC00MDAwIENGWC1MNDUwMCwgQ0ZY LUw0NTAwSUUgJmFtcDsgSUYgRlgzIC0tLS0tLS0tLS0tICQgNDkuNTA8YnI+DQo8L3NwYW4+MzNB IC0tIEwtMjUwLCBMLTI2MGksIEwtMzAwIEZYMyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0NCiQgNDkuNTA8YnI+DQo8c3BhbiBzdHlsZT0iYmFja2dyb3VuZC1jb2xv cjogI0M0QzRBNiI+MzNCIC0tIExBU0VSIENMQVNTIDIwNjAsIDIwNjBQLCA0MDAwIEZYMyAtLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCiQgNDkuNTA8YnI+DQo8L3NwYW4+MzQgLS0t IExBU0VSIENMQVNTIDUwMDAsIDU1MDAsIDcwMDAsIDcxMDAsIDc1MDAsIDYwMDAgRlgyIC0tLS0t LS0tLS0tLS0tLS0NCiQgNDkuNTA8c3BhbiBzdHlsZT0iYmFja2dyb3VuZC1jb2xvcjogI0M0QzRB NiI+PGJyPg0KMzUgLS0tIEZBWCA1MDAwIEZYMiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCiQgNDkuNTA8YnI+DQo8L3NwYW4+MzYgLS0tIExB U0VSIENMQVNTIDg1MDAsIDkwMDAsIDkwMDBMLCA5MDAwTVMsIDk1MDAsIDk1MDAgTVMsIDk1MDAg UyBGWDQgLS0NCiQgNDkuNTA8c3BhbiBzdHlsZT0iYmFja2dyb3VuZC1jb2xvcjogI0M0QzRBNiI+ PGJyPg0KMzZBIC0tIEZheCBMNzAwLDcyMCw3NjAsNzcwLDc3NSw3NzcsNzgwLDc4NSw3OTAsICZh bXA7IEwzMzAwIEZYMQ0KLS0tLS0tLS0tLS0tLSAkIDQ5LjUwPGJyPg0KPC9zcGFuPjM2QiAtLSBM LTgwMCwgTC05MDAgRlg0IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tDQokIDQ5LjUwPHNwYW4gc3R5bGU9ImJhY2tncm91bmQtY29sb3I6ICNDNEM0QTYi Pjxicj4NCjM3IC0tLSBBMzBSIFRvbmVyIENhcnRyaWRnZSBmb3IgUEMtNiwgNlJFLCA3LCAxMSwg MTIgLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQokIDU5LjUwPGJyPg0KPC9zcGFuPjM4IC0tLSBFLTQw IFRvbmVyIENhcnRyaWRnZSBmb3IgUEMtNzIwLCA3NDAsIDc3MCwgNzkwLDc5NSwgOTIwLCA5NTAs IDk4MCAtDQokIDg1LjUwPHNwYW4gc3R5bGU9ImJhY2tncm91bmQtY29sb3I6ICNDNEM0QTYiPjxi cj4NCjM4QSAtLSBFLTIwIFRvbmVyIENhcnRyaWRnZSBmb3IgUEMtMzEwLCAzMjUsIDMzMCwgMzMw TCwgNDAwLCA0MjAsIDQzMCAtLS0tDQokIDg1LjUwPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iYmFj a2dyb3VuZC1jb2xvcjogI0M0QzRBNiI+PGJyPjwvc3Bhbj48L2ZvbnQ+DQo8L3R0PjwvcD4NCjxw PjxiPjxmb250IGZhY2U9Ikx1Y2lkYSBTYW5zIFR5cGV3cml0ZXIiIHNpemU9IjMiPkl0ZW0mbmJz cDsmbmJzcDsNClhlcm94Jm5ic3A7Jm5ic3A7Jm5ic3A7IFByaWNlPC9mb250PjwvYj48L3A+DQo8 cD48dHQ+PGZvbnQgY29sb3I9IiMwMDAwMDAiIHNpemU9IjIiIGZhY2U9Ikx1Y2lkYSBTYW5zIFR5 cGV3cml0ZXIiPjxiPjxzcGFuIHN0eWxlPSJiYWNrZ3JvdW5kLWNvbG9yOiAjQzRDNEE2Ij4zOSAt LS0tIA0KNlI5MDAgNzVBIC0tLS0gJCA1NS41MDxicj4NCjwvc3Bhbj40MCAtLS0tIDZSOTAzIDk4 QSAtLS0tICQgNDYuNTA8c3BhbiBzdHlsZT0iYmFja2dyb3VuZC1jb2xvcjogI0M0QzRBNiI+PGJy Pg0KNDEgLS0tLSA2UjkwMiA5NUEgLS0tLSAkIDQ5LjUwPGJyPg0KPC9zcGFuPjQyIC0tLS0gNlI5 MDEgOTFBIC0tLS0gJCA2NS41MDxzcGFuIHN0eWxlPSJiYWNrZ3JvdW5kLWNvbG9yOiAjQzRDNEE2 Ij48YnI+DQo0MyAtLS0tIDZSOTA4IDA2QSAtLS0tICQgNDIuNTA8YnI+DQo8L3NwYW4+NDQgLS0t LSA2Ujg5OSA3NEEgLS0tLSAkIDQ3LjUwPHNwYW4gc3R5bGU9ImJhY2tncm91bmQtY29sb3I6ICND NEM0QTYiPjxicj4NCjQ1IC0tLS0gNlI5MjggOTZBIC0tLS0gJCA3Mi41MDxicj4NCjwvc3Bhbj40 NiAtLS0tIDZSOTI2IDI3WCAtLS0tICQgODQuNTA8c3BhbiBzdHlsZT0iYmFja2dyb3VuZC1jb2xv cjogI0M0QzRBNiI+PGJyPg0KNDcgLS0tLSA2UjkwNiAwOUEgLS0tLSAkIDkyLjUwPGJyPg0KPC9z cGFuPjQ4IC0tLS0gNlI5MDcgNE1WIC0tLS0gJCA4OS41MDxzcGFuIHN0eWxlPSJiYWNrZ3JvdW5k LWNvbG9yOiAjQzRDNEE2Ij48YnI+DQo0OSAtLS0tIDZSOTA1IDAzQSAtLS0tICQgNDYuNTA8L3Nw YW4+PC9iPjwvZm9udD48L3R0PjwvcD4NCjxwIGFsaWduPSJsZWZ0Ij48Yj48aT48Zm9udCBjb2xv cj0iIzgwODAwMCIgc2l6ZT0iMyIgZmFjZT0iQXJpYWwiPjMwIERheSB1bmxpbWl0ZWQgd2FycmFu dHkgaW5jbHVkZWQgb24gYWxsDQpwcm9kdWN0czxicj4NCkdUIFRvbmVyIFN1cHBsaWVzIGd1YXJh bnRlZXMgdGhlc2UgY2FydHJpZGdlcyB0byBiZSBmcmVlIGZyb20gZGVmZWN0cyBpbg0Kd29ya21h bnNoaXAgYW5kIG1hdGVyaWFsLjwvZm9udD48L2k+DQo8L2I+DQo8L3A+DQo8cCBhbGlnbj0ibGVm dCI+PGI+PGk+PGZvbnQgY29sb3I9IiMwMDAwRkYiIHNpemU9IjMiIGZhY2U9IkFyaWFsIj5XZSBs b29rDQpmb3J3YXJkIGluIGRvaW5nIGJ1c2luZXNzIHdpdGggeW91LjwvZm9udD48L2k+PC9iPg0K PC9wPg0KPHAgYWxpZ249ImxlZnQiPjxiPjxpPjxmb250IGNvbG9yPSIjMDAwMEZGIiBzaXplPSIz IiBmYWNlPSJBcmlhbCI+Q3VzdG9tZXImbmJzcDsNClNhdGlzZmFjdGlvbiBndWFyYW50ZWVkPC9m b250PjwvaT48L2I+DQo8L3A+DQo8cD4NCjxmb250IHNpemU9IjIiIGZhY2U9IkFyaWFsIj48Yj5J PGZvbnQgY29sb3I9IiMwMDAwODAiPmYgeW91IGFyZSBvcmRlcmluZyBieSBlLW1haWwgb3INCmMu by5kLiBwbGVhc2UgZmlsbCBvdXQgYW4gb3JkZXI8YnI+DQpmb3JtIHdpdGggdGhlIGZvbGxvd2lu ZyBpbmZvcm1hdGlvbjo8L2ZvbnQ+PGZvbnQgY29sb3I9IiM4MDgwMDAiPjxpPiZuYnNwOyZuYnNw OyZuYnNwOzwvaT48L2ZvbnQ+PGZvbnQgY29sb3I9IiMwMDAwODAiPg0KPC9mb250PjxpPiZuYnNw OyZuYnNwOyZuYnNwOzwvaT48Zm9udCBjb2xvcj0iIzAwMDA4MCIgZmFjZT0iQXJpYWwiPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzwvZm9udD48Zm9udCANCmNvbG9yPSIjMDAwMEZGIj4N CjwvZm9udD48Zm9udCBjb2xvcj0iIzgwODAwMCI+PGk+Jm5ic3A7PC9pPjwvZm9udD48Zm9udCBj b2xvcj0iIzAwMDA4MCI+PGJyPjxicj4NCjwvZm9udD48Zm9udCBjb2xvcj0iIzgwODAwMCI+cGhv bmUgbnVtYmVyPGJyPg0KY29tcGFueSBuYW1lPGJyPg0KZmlyc3QgYW5kIGxhc3QgbmFtZTxicj4N CnN0cmVldCBhZGRyZXNzPGJyPg0KY2l0eSwgc3RhdGUgemlwIA0KY29kZSZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KJm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7DQo8L2ZvbnQ+PC9iPjwvZm9udD48Zm9udCBzaXplPSIyIiBmYWNlPSJBcmlhbCI+PGI+PGk+ PGEgaHJlZj0ibWFpbHRvOmd0dHMxQGNhYmxlLm5ldC5jbyI+PGZvbnQgY29sb3I9IiMwMDAwRkYi Pk9yZGVyIA0KTm93PC9mb250PjwvYT4gPC9pPjxmb250IGNvbG9yPSIjMDAwMDgwIj5vcg0KY2Fs bCB0b2xsIGZyZWUgPC9mb250Pjxmb250IHNpemU9IjMiIGNvbG9yPSIjMDAwMEZGIj4gMS04NjYt MjM3LTczOTc8L2ZvbnQ+IDwvYj48L2ZvbnQ+DQo8Zm9udCBzaXplPSIyIiBmYWNlPSJBcmlhbCI+ PGI+PGZvbnQgY29sb3I9IiM4MDgwMDAiPjxicj48YnI+DQo8L2ZvbnQ+PGZvbnQgY29sb3I9IiMw MDAwODAiPklmIHlvdSBhcmUgb3JkZXJpbmcgYnkgcHVyY2hhc2Ugb3JkZXIgcGxlYXNlIGZpbGwg b3V0IGFuIG9yZGVyIGZvcm08YnI+DQp3aXRoIHRoZSBmb2xsb3dpbmcgaW5mb3JtYXRpb246Jm5i c3A7Jm5ic3A7Jm5ic3A7IDwvZm9udD48aT4mbmJzcDsmbmJzcDsmbmJzcDs8L2k+PGZvbnQgY29s b3I9IiMwMDAwODAiIA0KZmFjZT0iQXJpYWwiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9m b250PjwvYj48L2ZvbnQ+PC9wPg0KPHA+PGI+PGZvbnQgZmFjZT0iQXJpYWwiIGNvbG9yPSIjODA4 MDAwIiBzaXplPSIyIj5wdXJjaGFzZSBvcmRlciBudW1iZXI8YnI+DQpwaG9uZSBudW1iZXI8YnI+ DQpjb21wYW55IG9yIHNjaG9vbCBuYW1lPGJyPg0Kc2hpcHBpbmcgYWRkcmVzcyBhbmQgYmlsbGlu ZyBhZGRyZXNzPGJyPg0KY2l0eSwgc3RhdGUgemlwIA0KY29kZSZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8 L2ZvbnQ+PC9iPjxmb250IHNpemU9IjIiIGZhY2U9IkFyaWFsIj48Yj48aT48YSBocmVmPSJtYWls dG86Z3R0czFAY2FibGUubmV0LmNvIj48Zm9udCBjb2xvcj0iIzAwMDBGRiI+T3JkZXINCk5vdzwv Zm9udD48L2E+PC9pPjwvYj48L2ZvbnQ+PC9wPg0KPHAgYWxpZ249ImxlZnQiPjxiPjxmb250IHNp emU9IjIiPjxpPjxmb250IGNvbG9yPSIjODAwMDAwIiBzaXplPSIyIiBmYWNlPSJBcmlhbCI+QWxs IHRyYWRlIG1hcmtzIGFuZCBicmFuZCBuYW1lcyBsaXN0ZWQgDQphYm92ZSBhcmUgcHJvcGVydHkN Cm9mIHRoZSByZXNwZWN0aXZlPGJyPg0KaG9sZGVycyBhbmQgdXNlZCBmb3IgZGVzY3JpcHRpdmUg cHVycG9zZXMgb25seS48L2ZvbnQ+DQo8L2k+DQo8L2ZvbnQ+DQo8L2I+DQo8L3A+DQo= ------=_NextPart_000_00U8_69X80A1B.C1121G32-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis