From nsis-bounces@ietf.org Tue Aug 01 06:07:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7r9l-00075x-9E; Tue, 01 Aug 2006 06:07:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7r9k-00074D-47 for nsis@ietf.org; Tue, 01 Aug 2006 06:07:20 -0400 Received: from mail.gmx.net ([213.165.64.21]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G7r9j-0008Va-Gr for nsis@ietf.org; Tue, 01 Aug 2006 06:07:20 -0400 Received: (qmail invoked by alias); 01 Aug 2006 10:07:17 -0000 Received: from socks2.netz.sbs.de (EHLO [192.35.17.25]) [192.35.17.25] by mail.gmx.net (mp037) with SMTP; 01 Aug 2006 12:07:17 +0200 X-Authenticated: #29516787 Message-ID: <44CF27D4.5000406@gmx.net> Date: Tue, 01 Aug 2006 12:07:16 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Roy, Radhika R." Subject: Re: AW: [NSIS] Any resolution to the QSPEC mandatory parameter li st? References: <62D92A9A02BCC845B202323D49A48426209DC7@0591-ITS-EXMP02.us.saic.com> In-Reply-To: <62D92A9A02BCC845B202323D49A48426209DC7@0591-ITS-EXMP02.us.saic.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 88b11fc64c1bfdb4425294ef5374ca07 Cc: nsis@ietf.org, "Hancock, Robert" X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Roy, to me it seems that you haven't read the existing NSIS documents. I strongly suggest that you should do that. You cannot put the workload on me to summarize the documents for you. Since the IETF is contribution driven I think you should also work on a draft that describes what you want. You might, for example, develop the QoS model. It is easy to criticize the work of others if you haven't written your own proposal. Ciao Hannes Roy, Radhika R. wrote: > Hi, Hannes: > > It is very interesting that NSIS wants QOS model concept for signaling. The > question is this: Which QOS model? > > More inline [RRR]. > > BR/Radhika > > _____ > > From: nsis-bounces@ietf.org on behalf of Hannes Tschofenig > Sent: Mon 7/31/2006 3:34 PM > To: Roy, Radhika R. > Cc: Hancock, Robert; nsis@ietf.org; Tschofenig, Hannes > Subject: Re: AW: [NSIS] Any resolution to the QSPEC mandatory parameter li > st? > > > > Hi Roy, > > I strongly believe that we need the QoS model concept. > > [RRR] Which QOS model? > > I also think that > there will never be a single QoS model that everyone can agree with. > > [RRR] Again, which QOS model that NSIS needs to agree with? > > You > will always find deployment environments that are a bit different that > others. We already see this happening today. > > [RRR] Agreed. NSIS is not standardizing any specific implemention or > deployment. > > NSIS is about signaling QoS information obtained from the application to > the network, in one of the envisioned usage scenarios. > > [RRR] Agreed. One of the important real-time multimedia applications is SIP. > If its needs are not met, which applications that NSIS is shooting for? > Could you please provide a scenario how the SIP application will use NSIS > QOS parameters that will have no knowledge of any underlying transport > networks or network-specific QOS models other than its own codecs per se? I > would appreciate your help. > > But there are > others as well that are important. > > [RRR] I would think so. Could you please be more specifc with a given > example instead of being abstract? > > You just need to think about the > transition time where an E2E solution cannot be deployed. > > [RRR] Good. Let us understand what is the transitional QOS model where e2e > QOS solution cannot be deployed. No one in NSIS has yet written a > requirement that NSIS will develop a QOS signaling standard that will deal > with a transitional case before the e2e QOS solution is deployed. If so, let > us make it very specific what is the scope of this transitional QOS > solution. If we know this, definitely we all will work to this end. Let us > write a requirement document on this instead of being abstract. > > [RRR] We thought that NSIS will do in two steps: a. Simple one with e2e > application QOS and b. Network-specific e2e QOS while complementing the e2e > application QOS as the fundamental reference. Case a will always remain the > same as SIP will always use its QOS reference to its codecs while case b > will have numerous soultions/implementations, and NSIS may work for a long > time on item b. > > Ciao > Hannes > > > Roy, Radhika R. wrote: > >>Hi, Hannes: >> >>The most important conclusion is this: We do not need any QOS model. > > Period. > >>All we want in NSIS is this: Like NSIS QOS signaling messages, we just > > need > >>to express the end-to-end QOS parameters of the applications as follows: >>Bandwidth, Delay, Jitter, and Packet Loss. >> >>For non-real-time data application, "jitter" may or may not be required, > > but > >>for real-time/near-real-time audio/video application, the above 4 > > parameters > >>are needed. >> >>The application will express those values on end-to-end basis, > > "independent" > >>of any transport networking that may consist of one or many networks while >>transporting the application messages/payload on end-to-end basis. >> >>By the way, NSIS's charter is not to standardize or specify any "value" > > for > >>those performance parameters. >> >>It is so simple. >> >>How to deal with the network QOS, it is not NSIS's problems. NSIS's > > charter > >>is to "signal" the QOS parameters on end-to-end basis between the >>applications. By the way, the end-to-end QOS requirements for applications >>will remain the "same" because it is based on the "inherent" > > characteristics > >>of the system (e.g., MOS of audio/video application, response time >>requirements for data application depending on human or automa). >> >>Best regards, >>Radhika >> >>PS: >> >>1. Now, 3G may solve their part of the network QOS. For example, they >>provide the access wireless network. >> >>2. IEEE may solve the access LAN QOS problems. >> >>3. IETF may solve the problems of public Internet backbone network QOS >>(e.g., DiffServ, DSTE), access IP network QOS (e.g., IntServ) or > > end-to-end > >>IP (access + backbone). >> >>4. An implementer (say, service provider) that wants to provide end-to-end >>VoIP/SIP service will take NSIS QOS as the fundamental reference for >>addressing the end-to-end QOS for the application. They now need to choose >>what type of networks they will use on the end-to-end path. Accordingly, >>they will divide the NSIS's end-to-end QOS that has been signaled by the >>application into individual networks. The beauty of this is this: NSIS QOS >>signaling protocol still be used on end-to-end basis between the >>applications. >> >>5. If NSIS needs to address item 4, it needs to change its charter. It is > > a > >>huge problem to solve. I am extremely worried that NSIS focus might have >>distorted due to unnecessarily mixing of items 1, 2, 3, and 4 while they >>started discussing the QOS parameters. >> >> _____ >> >>From: nsis-bounces@ietf.org on behalf of Tschofenig, Hannes >>Sent: Mon 7/31/2006 11:32 AM >>To: Roy, Radhika R.; Hannes Tschofenig; Hancock, Robert >>Cc: nsis@ietf.org >>Subject: AW: AW: [NSIS] Any resolution to the QSPEC mandatory parameter li >>st? >> >> >> >>Hi Roy, >> >>from the discussion so far it seems that you have looked at the >>application layer to NSIS QoS mapping in more detail. >>What was the conclusion? >>Are the work-in-progress QoS models support what you want? >> >>Ciao >>Hannes >> > > > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Aug 01 08:25:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7tIq-0004Ex-Vd; Tue, 01 Aug 2006 08:24:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7tIq-0004Er-9r for nsis@ietf.org; Tue, 01 Aug 2006 08:24:52 -0400 Received: from iramx1.ira.uni-karlsruhe.de ([141.3.10.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7tIo-0008Hu-N9 for nsis@ietf.org; Tue, 01 Aug 2006 08:24:52 -0400 Received: from i72ms2.tm.uni-karlsruhe.de ([141.3.70.17] helo=smtp.ipv6.tm.uni-karlsruhe.de) by iramx1.ira.uni-karlsruhe.de with esmtps id 1G7tIf-0003gC-6Q; Tue, 01 Aug 2006 14:24:50 +0200 Received: from vorta.ipv6.tm.uni-karlsruhe.de (vorta.ipv6.tm.uni-karlsruhe.de [IPv6:2001:638:204:6:207:e9ff:fe0c:5e44]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id DC0FFBEFC; Tue, 1 Aug 2006 14:24:40 +0200 (CEST) Received: from localhost ([127.0.0.1]) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.44) id 1G7tIe-00069U-KM; Tue, 01 Aug 2006 14:24:40 +0200 Message-ID: <44CF4807.2080600@tm.uka.de> Date: Tue, 01 Aug 2006 14:24:39 +0200 From: Roland Bless Organization: Institute of Telematics, University of Karlsruhe User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060111 Thunderbird/1.5 Mnenhy/0.7.3.0 MIME-Version: 1.0 To: "Tschofenig, Hannes" Subject: Re: AW: [NSIS] Any resolution to the QSPEC mandatory parameter li st? References: <62D92A9A02BCC845B202323D49A48426209DC5@0591-ITS-EXMP02.us.saic.com> <44CE5B2B.9060403@gmx.net> In-Reply-To: <44CE5B2B.9060403@gmx.net> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: -4.2 (----) X-Spam-Status: No X-Spam-Report: -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] 0.2 AWL AWL: From: address is in the auto white-list X-Spam-Score: 0.0 (/) X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78 Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Hannes, Hannes Tschofenig schrieb: > I strongly believe that we need the QoS model concept. I also think that > there will never be a single QoS model that everyone can agree with. You > will always find deployment environments that are a bit different that > others. We already see this happening today. Yep, but the usefulness of QoS depends IMHO on having an inter-domain agreement on a common "service" so that one can request at least for example a reservation of bandwidth from one end of the Internet to the other. On the one hand I agree that we probably have different QOSMs and so on (side note: the DiffServ WG did not specify services, only building blocks in order to let ISPs define their own services), but on the other hand if QoS is not deployed widely, its use is very limited (it is similar with IPv6, ECN or multicast). Ok, we must get started somewhere and it's even progress if you can request QoS at least in one domain, but as I understood early charters of this WG, it was also a goal to work towards an Internet-wide (inter-domain) solution. So the QSPEC template is one contribution to achieve this. > NSIS is about signaling QoS information obtained from the application to > the network, in one of the envisioned usage scenarios. But there are > others as well that are important. You just need to think about the > transition time where an E2E solution cannot be deployed. Unfortunately, transitions that require infrastructural support and changes tend to last much longer than one guesses...(cf. examples above) :-( Regards, Roland > Roy, Radhika R. wrote: >> Hi, Hannes: >> >> The most important conclusion is this: We do not need any QOS model. >> Period. >> >> All we want in NSIS is this: Like NSIS QOS signaling messages, we just >> need >> to express the end-to-end QOS parameters of the applications as follows: >> Bandwidth, Delay, Jitter, and Packet Loss. >> >> For non-real-time data application, "jitter" may or may not be >> required, but >> for real-time/near-real-time audio/video application, the above 4 >> parameters >> are needed. >> >> The application will express those values on end-to-end basis, >> "independent" >> of any transport networking that may consist of one or many networks >> while >> transporting the application messages/payload on end-to-end basis. >> >> By the way, NSIS's charter is not to standardize or specify any >> "value" for >> those performance parameters. >> >> It is so simple. >> >> How to deal with the network QOS, it is not NSIS's problems. NSIS's >> charter >> is to "signal" the QOS parameters on end-to-end basis between the >> applications. By the way, the end-to-end QOS requirements for >> applications >> will remain the "same" because it is based on the "inherent" >> characteristics >> of the system (e.g., MOS of audio/video application, response time >> requirements for data application depending on human or automa). >> Best regards, >> Radhika >> >> PS: >> >> 1. Now, 3G may solve their part of the network QOS. For example, they >> provide the access wireless network. >> >> 2. IEEE may solve the access LAN QOS problems. >> >> 3. IETF may solve the problems of public Internet backbone network QOS >> (e.g., DiffServ, DSTE), access IP network QOS (e.g., IntServ) or >> end-to-end >> IP (access + backbone). >> >> 4. An implementer (say, service provider) that wants to provide >> end-to-end >> VoIP/SIP service will take NSIS QOS as the fundamental reference for >> addressing the end-to-end QOS for the application. They now need to >> choose >> what type of networks they will use on the end-to-end path. Accordingly, >> they will divide the NSIS's end-to-end QOS that has been signaled by the >> application into individual networks. The beauty of this is this: NSIS >> QOS >> signaling protocol still be used on end-to-end basis between the >> applications. >> >> 5. If NSIS needs to address item 4, it needs to change its charter. It >> is a >> huge problem to solve. I am extremely worried that NSIS focus might have >> distorted due to unnecessarily mixing of items 1, 2, 3, and 4 while they >> started discussing the QOS parameters. >> >> _____ >> From: nsis-bounces@ietf.org on behalf of Tschofenig, Hannes >> Sent: Mon 7/31/2006 11:32 AM >> To: Roy, Radhika R.; Hannes Tschofenig; Hancock, Robert >> Cc: nsis@ietf.org >> Subject: AW: AW: [NSIS] Any resolution to the QSPEC mandatory >> parameter li >> st? >> >> >> >> Hi Roy, >> >> from the discussion so far it seems that you have looked at the >> application layer to NSIS QoS mapping in more detail. >> What was the conclusion? >> Are the work-in-progress QoS models support what you want? >> >> Ciao >> Hannes >> >> _______________________________________________ >> nsis mailing list >> nsis@ietf.org >> https://www1.ietf.org/mailman/listinfo/nsis >> >> >> >> _______________________________________________ >> nsis mailing list >> nsis@ietf.org >> https://www1.ietf.org/mailman/listinfo/nsis >> >> > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > -- Dr. Roland Bless -- WWW: http://www.tm.uka.de/~bless Institut für Telematik, Universität Karlsruhe (TH), Germany Zirkel 2, D-76128 Karlsruhe -- Geb. 20.20, 3.OG, Raum 358 Tel.: +49 721 608-6413 Fax: +49 721 608-6789 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Aug 01 09:46:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7uZN-0002Dl-PQ; Tue, 01 Aug 2006 09:46:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7uZM-0002Dg-7i for nsis@ietf.org; Tue, 01 Aug 2006 09:46:00 -0400 Received: from mail.gmx.net ([213.165.64.21]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G7uZK-0004gB-Jv for nsis@ietf.org; Tue, 01 Aug 2006 09:46:00 -0400 Received: (qmail invoked by alias); 01 Aug 2006 12:45:56 -0000 Received: from socks2.netz.sbs.de (EHLO [192.35.17.25]) [192.35.17.25] by mail.gmx.net (mp020) with SMTP; 01 Aug 2006 14:45:56 +0200 X-Authenticated: #29516787 Message-ID: <44CF4D02.3010000@gmx.net> Date: Tue, 01 Aug 2006 14:45:54 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Roland Bless Subject: Re: AW: [NSIS] Any resolution to the QSPEC mandatory parameter li st? References: <62D92A9A02BCC845B202323D49A48426209DC5@0591-ITS-EXMP02.us.saic.com> <44CE5B2B.9060403@gmx.net> <44CF4807.2080600@tm.uka.de> In-Reply-To: <44CF4807.2080600@tm.uka.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 156eddb66af16eef49a76ae923b15b92 Cc: nsis@ietf.org, "Tschofenig, Hannes" X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Roland, I guess we agree about the current status of our work and the fact that the QSPEC template is very useful. No doubt that there is further work ahead of us as well. I think as a short term goal we need to conclude the discussions regarding the set of mandatory parameters for the QSPEC template draft. The QSPEC draft has already improved a lot with the last few versions and this issue seems to be the remaining one. Ciao Hannes Roland Bless wrote: > Hi Hannes, > > Hannes Tschofenig schrieb: > >>I strongly believe that we need the QoS model concept. I also think that >>there will never be a single QoS model that everyone can agree with. You >>will always find deployment environments that are a bit different that >>others. We already see this happening today. > > > Yep, but the usefulness of QoS depends IMHO on having > an inter-domain agreement on a common "service" so that one can request > at least for example a reservation of bandwidth from one end of the > Internet to the other. On the one hand I agree that we probably have > different QOSMs and so on (side note: the DiffServ WG did not specify > services, only building blocks in order to let ISPs define their own > services), but on the other hand if QoS is not deployed widely, its use > is very limited (it is similar with IPv6, ECN or multicast). Ok, we must > get started somewhere and it's even progress if you can request QoS at > least in one domain, but as I understood early charters of this WG, it > was also a goal to work towards an Internet-wide (inter-domain) > solution. So the QSPEC template is one contribution to achieve this. > > >>NSIS is about signaling QoS information obtained from the application to >>the network, in one of the envisioned usage scenarios. But there are >>others as well that are important. You just need to think about the >>transition time where an E2E solution cannot be deployed. > > > Unfortunately, transitions that require infrastructural support and > changes tend to last much longer than one guesses...(cf. examples above) > :-( > > Regards, > Roland > > >>Roy, Radhika R. wrote: >> >>>Hi, Hannes: >>> >>>The most important conclusion is this: We do not need any QOS model. >>>Period. >>> >>>All we want in NSIS is this: Like NSIS QOS signaling messages, we just >>>need >>>to express the end-to-end QOS parameters of the applications as follows: >>>Bandwidth, Delay, Jitter, and Packet Loss. >>> >>>For non-real-time data application, "jitter" may or may not be >>>required, but >>>for real-time/near-real-time audio/video application, the above 4 >>>parameters >>>are needed. >>> >>>The application will express those values on end-to-end basis, >>>"independent" >>>of any transport networking that may consist of one or many networks >>>while >>>transporting the application messages/payload on end-to-end basis. >>> >>>By the way, NSIS's charter is not to standardize or specify any >>>"value" for >>>those performance parameters. >>> >>>It is so simple. >>> >>>How to deal with the network QOS, it is not NSIS's problems. NSIS's >>>charter >>>is to "signal" the QOS parameters on end-to-end basis between the >>>applications. By the way, the end-to-end QOS requirements for >>>applications >>>will remain the "same" because it is based on the "inherent" >>>characteristics >>>of the system (e.g., MOS of audio/video application, response time >>>requirements for data application depending on human or automa). >>>Best regards, >>>Radhika >>> >>>PS: >>> >>>1. Now, 3G may solve their part of the network QOS. For example, they >>>provide the access wireless network. >>> >>>2. IEEE may solve the access LAN QOS problems. >>> >>>3. IETF may solve the problems of public Internet backbone network QOS >>>(e.g., DiffServ, DSTE), access IP network QOS (e.g., IntServ) or >>>end-to-end >>>IP (access + backbone). >>> >>>4. An implementer (say, service provider) that wants to provide >>>end-to-end >>>VoIP/SIP service will take NSIS QOS as the fundamental reference for >>>addressing the end-to-end QOS for the application. They now need to >>>choose >>>what type of networks they will use on the end-to-end path. Accordingly, >>>they will divide the NSIS's end-to-end QOS that has been signaled by the >>>application into individual networks. The beauty of this is this: NSIS >>>QOS >>>signaling protocol still be used on end-to-end basis between the >>>applications. >>> >>>5. If NSIS needs to address item 4, it needs to change its charter. It >>>is a >>>huge problem to solve. I am extremely worried that NSIS focus might have >>>distorted due to unnecessarily mixing of items 1, 2, 3, and 4 while they >>>started discussing the QOS parameters. >>> >>> _____ >>>From: nsis-bounces@ietf.org on behalf of Tschofenig, Hannes >>>Sent: Mon 7/31/2006 11:32 AM >>>To: Roy, Radhika R.; Hannes Tschofenig; Hancock, Robert >>>Cc: nsis@ietf.org >>>Subject: AW: AW: [NSIS] Any resolution to the QSPEC mandatory >>>parameter li >>>st? >>> >>> >>> >>>Hi Roy, >>> >>>from the discussion so far it seems that you have looked at the >>>application layer to NSIS QoS mapping in more detail. >>>What was the conclusion? >>>Are the work-in-progress QoS models support what you want? >>> >>>Ciao >>>Hannes >>> >>>_______________________________________________ >>>nsis mailing list >>>nsis@ietf.org >>>https://www1.ietf.org/mailman/listinfo/nsis >>> >>> >>> >>>_______________________________________________ >>>nsis mailing list >>>nsis@ietf.org >>>https://www1.ietf.org/mailman/listinfo/nsis >>> >>> >> >> >>_______________________________________________ >>nsis mailing list >>nsis@ietf.org >>https://www1.ietf.org/mailman/listinfo/nsis >> > > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Aug 01 10:23:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7v9x-00056P-Cc; Tue, 01 Aug 2006 10:23:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7v9w-00056K-Le for nsis@ietf.org; Tue, 01 Aug 2006 10:23:48 -0400 Received: from mclmx.mail.saic.com ([149.8.64.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7v9u-0006VO-DN for nsis@ietf.org; Tue, 01 Aug 2006 10:23:48 -0400 Received: from 0015-its-ieg01.mail.saic.com ([149.8.64.21] [149.8.64.21]) by mclmx.mail.saic.com; Tue, 1 Aug 2006 10:23:24 -0400 Received: from mcl-its-exig01.mail.saic.com ([149.8.64.12]) by 0015-its-ieg01.mail.saic.com (SMSSMTP 4.0.5.66) with SMTP id M2006080110232421514 ; Tue, 01 Aug 2006 10:23:24 -0400 Received: by mcl-its-exig01.mail.saic.com with Internet Mail Service (5.5.2657.72) id ; Tue, 1 Aug 2006 10:23:24 -0400 Message-Id: <62D92A9A02BCC845B202323D49A48426209DCA@0591-ITS-EXMP02.us.saic.com> From: "Roy, Radhika R." To: Hannes Tschofenig Subject: RE: AW: [NSIS] Any resolution to the QSPEC mandatory parameter li st? Date: Tue, 1 Aug 2006 10:23:13 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) content-class: urn:content-classes:message Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: nsis@ietf.org, "Hancock, Robert" X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hannes: You might be right to some extent as there are so many documents and each has many things inside it. Yes, the works are contribution driven based on its charter. The basic point, if I understand you correctly, QOS model in NSIS is under development for QOS signaling as we have been seeing some discussions are going on. What we are seeing here is this: There is a "gap" how to use the NSIS QOS model by the application like SIP. As you have said that the application will request QOS using NSIS QOS model. The application like SIP has to convert the e2e QOS needs per non-e2e NSIS QOS model. How the application like SIP will do it is not known - it is a "non-standard" scheme, and NSIS also does not want to address this as no one has brought contributions along this line. If it is true, let us make it is clear as objectives because no documents address this keeping this in disguise as if some miracle happens. That is point that I have been driving at for "complexity" of QOS parameter discussions that you have trying hard for mapping between NSIS QOS parameters to WiFi, WiMAX, cellular, IP, etc. Once we know this, we can easily fall back to the same schemes what other like DIAMETER are doing. Did I summarize correctly? I appreciate your patience. BR/Radhika _____ From: nsis-bounces@ietf.org on behalf of Hannes Tschofenig Sent: Tue 8/1/2006 6:07 AM To: Roy, Radhika R. Cc: nsis@ietf.org; Hancock, Robert Subject: Re: AW: [NSIS] Any resolution to the QSPEC mandatory parameter li st? Roy, to me it seems that you haven't read the existing NSIS documents. I strongly suggest that you should do that. You cannot put the workload on me to summarize the documents for you. Since the IETF is contribution driven I think you should also work on a draft that describes what you want. You might, for example, develop the QoS model. It is easy to criticize the work of others if you haven't written your own proposal. Ciao Hannes _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Aug 01 10:39:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7vP4-0007ru-IO; Tue, 01 Aug 2006 10:39:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7vP3-0007gG-1V for nsis@ietf.org; Tue, 01 Aug 2006 10:39:25 -0400 Received: from iramx1.ira.uni-karlsruhe.de ([141.3.10.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7vP1-0007Tc-He for nsis@ietf.org; Tue, 01 Aug 2006 10:39:25 -0400 Received: from i72ms2.tm.uni-karlsruhe.de ([141.3.70.17] helo=smtp.ipv6.tm.uni-karlsruhe.de) by iramx1.ira.uni-karlsruhe.de with esmtps id 1G7vOm-00078z-Gc; Tue, 01 Aug 2006 16:39:12 +0200 Received: from vorta.ipv6.tm.uni-karlsruhe.de (vorta.ipv6.tm.uni-karlsruhe.de [IPv6:2001:638:204:6:207:e9ff:fe0c:5e44]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id 2FE3E864E; Tue, 1 Aug 2006 16:39:08 +0200 (CEST) Received: from localhost ([127.0.0.1]) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.44) id 1G7vOl-0006El-RD; Tue, 01 Aug 2006 16:39:07 +0200 Message-ID: <44CF678B.7000608@tm.uka.de> Date: Tue, 01 Aug 2006 16:39:07 +0200 From: Roland Bless Organization: Institute of Telematics, University of Karlsruhe User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060111 Thunderbird/1.5 Mnenhy/0.7.3.0 MIME-Version: 1.0 To: "Hancock, Robert" Subject: Re: [NSIS] Last Call: 'GIST: General Internet Signaling Transport' to Proposed Standard (draft-ietf-nsis-ntlp) References: In-Reply-To: X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: -4.2 (----) X-Spam-Status: No X-Spam-Report: -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] 0.2 AWL AWL: From: address is in the auto white-list X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: Mark Doll , nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Robert, >> However, I would really like to see a clear statement like: >> GN2 sends the Response in D-mode directly to GN1, using >> the interface-address as destination addess as specified >> in the NLI of the query and the source port of the query >> as destination port of the response. > > there are three parts to the answer here: > > 1) the underlying requirement is to get the message to the right > node; apart from this, the encapsulation doesn't matter. That sounds logical, but it is quite fuzzy... I guess this will lead to different results depending on the particular implementation. > 2) for the scenarios which are in scope of the spec (i.e. no > legacy NATs) the correct (or at least intended) behaviour is > as you put it above. > > 3) it is not impossible that some approach to traversal of > legacy NATs would require sending the Response back to the > Query source. those approaches are not worked out in this > draft, but it is the basis of the approach described in > draft-pashalidis-ietf-nsis-gist-legacynats-00 for example > (see section 5). NATs cause headache and pain...so I probably skipped that part =:-> > so i can imagine writing something more explicit, but i > wouldn't want to pin it down to the extent of ruling out > the flexibility required by (3), expecially given the overall > criterion (1) - that it shouldn't matter provided it works. > more text suggestions welcome ;-) Hmm, actually I don't know how one could implement a robust scheme that works in all situations. I understood at least this: a) if no MA for given NLI exists then use D-Mode and send RESPONSE back to NLI (BTW: what if NLI is obviously useless, e.g. ::, 0.0.0.0, ::1 or unrouteable, should we send back an error to the source - I guess we have no suitable error code for that yet?) b) if MA for NLI exists, send RESPONSE back via that MA c) the GIST node could also send the response back to the source if no S-flag is set. Has this precedence over a)? Only in certain environments? So usually I would use a) and b) but you also suggest that c) might be useful in certain NAT scenarios... >> B) >> if the response must be sent back to what is specified in the >> NLI, this possibly opens up reflection attacks. This should be >> mentioned in the security considerations section and I'm not quite >> sure whether any sanity checks are possible to prevent this. > > this is the intention (one of the intentions) of the 3rd requirement > on the Q-cookie in section 8.5 (easily validated ... to discard > responses to spoofed queries). i don't see what other sanity > checks are possible to prevent this. This only covers a part of my question. So an NSIS node will discard responses to spoofed queries, this is good. Assume that an attacker A sends a query with the NLI containing the address of the victim V. The responder R will nevertheless answer the query and send the RESPONSE to V. This is a reflection attack and doesn't require spoofing the source address of the query (which can be A's address). In case the response is larger than the query the attacker cannot only hide behind the reflector, he can also use slight amplification as benefit. I meant sanity checks on the side of the responder: it is not easily possible to check that NLI and source address correspond to each other, because they may intentionally differ... Regards, Roland _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Aug 01 14:45:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7zFS-00052B-Lt; Tue, 01 Aug 2006 14:45:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7zFC-0004CT-Oh for nsis@ietf.org; Tue, 01 Aug 2006 14:45:30 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7x3u-00082v-7B for nsis@ietf.org; Tue, 01 Aug 2006 12:25:42 -0400 Received: from rsys002x.roke.co.uk ([193.118.201.109]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G7wvi-0000dD-L7 for nsis@ietf.org; Tue, 01 Aug 2006 12:17:16 -0400 Received: from rsys005a.comm.ad.roke.co.uk (rsys005a [193.118.193.85]) by rsys002x.roke.co.uk (8.13.1/8.13.1) with ESMTP id k71GGqRq028424; Tue, 1 Aug 2006 17:16:52 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] Last Call: 'GIST: General Internet Signaling Transport' to Proposed Standard (draft-ietf-nsis-ntlp) Date: Tue, 1 Aug 2006 17:16:52 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] Last Call: 'GIST: General Internet Signaling Transport' to Proposed Standard (draft-ietf-nsis-ntlp) Thread-Index: Aca1eFqYE8Pm/EUaQdCBdV20fxqGFQABYC1g From: "Hancock, Robert" To: "Roland Bless" X-MailScanner-roke-co-uk: Found to be clean X-MailScanner-roke-co-uk-SpamCheck: X-MailScanner-From: robert.hancock@roke.co.uk X-Spam-Score: -2.6 (--) X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c Cc: Mark Doll , nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org hi roland, inline: > -----Original Message----- > From: Roland Bless [mailto:bless@tm.uka.de]=20 > Sent: 01 August 2006 15:39 > To: Hancock, Robert > Cc: Mark Doll; nsis@ietf.org > Subject: Re: [NSIS] Last Call: 'GIST: General Internet=20 > Signaling Transport' to Proposed Standard (draft-ietf-nsis-ntlp) >=20 >=20 > Hi Robert, >=20 > >> However, I would really like to see a clear statement like: > >> GN2 sends the Response in D-mode directly to GN1, using > >> the interface-address as destination addess as specified > >> in the NLI of the query and the source port of the query > >> as destination port of the response. > >=20 > > there are three parts to the answer here: > >=20 > > 1) the underlying requirement is to get the message to the right > > node; apart from this, the encapsulation doesn't matter. >=20 > That sounds logical, but it is quite fuzzy... > I guess this will lead to different results depending > on the particular implementation. it is not quite that bad. i can think of some more deterministic text (see below). however, the key message from (1) in particular would be something like: "once the Querying has received a Response message, it MUST ignore=20 the addressing data from the IP header" (or something like that). to some extent, i don't care about fuzzyness of sender behaviour if it is not relevant to the receiver. >=20 > > 2) for the scenarios which are in scope of the spec (i.e. no > > legacy NATs) the correct (or at least intended) behaviour is=20 > > as you put it above. > >=20 > > 3) it is not impossible that some approach to traversal of > > legacy NATs would require sending the Response back to the=20 > > Query source. those approaches are not worked out in this > > draft, but it is the basis of the approach described in > > draft-pashalidis-ietf-nsis-gist-legacynats-00 for example > > (see section 5). >=20 > NATs cause headache and pain...so I probably skipped that > part =3D:-> tut tut ... >=20 > > so i can imagine writing something more explicit, but i > > wouldn't want to pin it down to the extent of ruling out > > the flexibility required by (3), expecially given the overall > > criterion (1) - that it shouldn't matter provided it works. > > more text suggestions welcome ;-) >=20 > Hmm, actually I don't know how one could implement a robust > scheme that works in all situations. I understood at least > this: > a) if no MA for given NLI exists then use D-Mode and send RESPONSE > back to NLI (BTW: what if NLI is obviously useless, e.g. ::, > 0.0.0.0, ::1 or unrouteable, should we send back an error to > the source - I guess we have no suitable error code for that yet?) i would guess: object value error with subcode 1, sent back to the IP source if S=3D1 else logging an error locally. (section 5.6 says this to some extent, but we don't try to define absolutely every condition...) > b) if MA for NLI exists, send RESPONSE back via that MA if it matches the re-use criteria (see the end of section 5.7.1). > c) the GIST node could also send the response back to the source if > no S-flag is set. Has this precedence over a)? Only in certain > environments? i think you mean "if S *is* set". i would probably make this a SHOULD given that we always initially have S=3D0 in the first Query. >=20 > So usually I would use a) and b) but you also suggest that c) > might be useful in certain NAT scenarios... >=20 > >> B) > >> if the response must be sent back to what is specified in the > >> NLI, this possibly opens up reflection attacks. This should be > >> mentioned in the security considerations section and I'm not quite > >> sure whether any sanity checks are possible to prevent this. > >=20 > > this is the intention (one of the intentions) of the 3rd requirement > > on the Q-cookie in section 8.5 (easily validated ... to discard > > responses to spoofed queries). i don't see what other sanity=20 > > checks are possible to prevent this. >=20 > This only covers a part of my question. So an NSIS node > will discard responses to spoofed queries, this is good. > Assume that an attacker A sends a query with the NLI containing the > address of the victim V. The responder R will nevertheless > answer the query and send the RESPONSE to V. This is a reflection > attack and doesn't require spoofing the source address of the query > (which can be A's address). i probably use the word 'spoofed' here less precisely. by 'spoofed query' i mean 'any query that the receiver of the Response did not actually send' (not only with a forged source address). > In case the response is larger than the query the attacker cannot > only hide behind the reflector, he can also use slight amplification > as benefit. yes, but it really is minimal - there is no increase in the number of messages and the message size change is marginal. > I meant sanity checks on the side of the responder: > it is not easily possible to check that NLI and source address > correspond to each other, because they may intentionally differ... indeed they may. and i think it is useful to preserve this flexibility. there are constraints on both the IP source and NLI interface-address; the former are to do with possible implementation restrictions and the latter to do with route change detection for some MRMs. we cannot rule out that those constraints will always be satisfiable by the same address. cheers, robert h. >=20 > Regards, > Roland >=20 >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Aug 02 01:49:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G89ba-0004LD-Mg; Wed, 02 Aug 2006 01:49:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G89bY-0004BD-Sz for nsis@ietf.org; Wed, 02 Aug 2006 01:49:16 -0400 Received: from mgw-ext12.nokia.com ([131.228.20.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G89Po-0007lG-CF for nsis@ietf.org; Wed, 02 Aug 2006 01:37:08 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext12.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k725b6CP014997; Wed, 2 Aug 2006 08:37:06 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 2 Aug 2006 08:37:06 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 2 Aug 2006 08:37:04 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: AW: [NSIS] Any resolution to the QSPEC mandatory parameter li st? Date: Wed, 2 Aug 2006 08:37:04 +0300 Message-ID: In-Reply-To: <62D92A9A02BCC845B202323D49A48426209DCA@0591-ITS-EXMP02.us.saic.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AW: [NSIS] Any resolution to the QSPEC mandatory parameter li st? Thread-Index: Aca1dmKgaxut6fQmRxqhOwzaLMyxfQAfkf3w From: To: , X-OriginalArrivalTime: 02 Aug 2006 05:37:04.0547 (UTC) FILETIME=[AFAAF730:01C6B5F5] X-Spam-Score: 0.2 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Cc: nsis@ietf.org, robert.hancock@roke.co.uk X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi all, I think this thread has out-lived its usefulness. Let me summarize. NSIS has developed a layered signaling model (outlined in the NSIS Framework RFC). NSIS is chartered not to develop new QoS solutions, but to reuse and support other QoS solutions. The IESG wanted us to consider how to support other SDO QoS solutions as well as IETF QoS Solutions (intserv/diffserv). Solutions developed outside of the IETF are clearly of Information status. Radhika would like NSIS QoS signaling to be able to support signaling different QoS parameters directly - bandwidth, Delay, Delay Jitter, Packet Loss, etc. These can be signaling directly with the Qspec template - I think we might want to think about creating a generic QoS model that allows endpoints to signal only what parameters are needed. This way, if there are QoS deployments that want to signal their QoS Models, than that is possible - if there is need to signal just simple parameters on an end-to-end basis, than that would be possible. In summary, NSIS is required to be able to signal other SDO's=20 QoS Models. By being able to signal these models, the IETF is not implying the relative fitness of the specifications developed elsewhere, but ensuring that NSIS's work supports deployments. If there is need / interest in signaling very simple or basic parameters, I suggest we consider how to generate a generic QoS model that allows us to signal just the basic parameters on an as-needed basis. John >-----Original Message----- >From: ext Roy, Radhika R. [mailto:RADHIKA.R.ROY@saic.com]=20 >Sent: 01 August, 2006 17:23 >To: Hannes Tschofenig >Cc: nsis@ietf.org; Hancock, Robert >Subject: RE: AW: [NSIS] Any resolution to the QSPEC mandatory=20 >parameter li st? > >Hannes: >=20 >You might be right to some extent as there are so many=20 >documents and each has many things inside it. >=20 >Yes, the works are contribution driven based on its charter. >=20 >The basic point, if I understand you correctly, QOS model in=20 >NSIS is under development for QOS signaling as we have been=20 >seeing some discussions are going on. >=20 >What we are seeing here is this: There is a "gap" how to use=20 >the NSIS QOS model by the application like SIP. As you have=20 >said that the application will request QOS using NSIS QOS=20 >model. The application like SIP has to convert the e2e QOS=20 >needs per non-e2e NSIS QOS model.=20 >=20 >How the application like SIP will do it is not known - it is a=20 >"non-standard" scheme, and NSIS also does not want to address=20 >this as no one has brought contributions along this line. >=20 >If it is true, let us make it is clear as objectives because=20 >no documents address this keeping this in disguise as if some=20 >miracle happens. >=20 >That is point that I have been driving at for "complexity" of=20 >QOS parameter discussions that you have trying hard for=20 >mapping between NSIS QOS parameters to WiFi, WiMAX, cellular, IP, etc. >=20 >Once we know this, we can easily fall back to the same schemes=20 >what other like DIAMETER are doing. >=20 >Did I summarize correctly? I appreciate your patience. >=20 >BR/Radhika > > _____ =20 > >From: nsis-bounces@ietf.org on behalf of Hannes Tschofenig >Sent: Tue 8/1/2006 6:07 AM >To: Roy, Radhika R. >Cc: nsis@ietf.org; Hancock, Robert >Subject: Re: AW: [NSIS] Any resolution to the QSPEC mandatory=20 >parameter li st? > > > >Roy, > >to me it seems that you haven't read the existing NSIS documents. >I strongly suggest that you should do that. You cannot put the=20 >workload on me to summarize the documents for you. Since the=20 >IETF is contribution driven I think you should also work on a=20 >draft that describes what you want. You might, for example,=20 >develop the QoS model. It is easy to criticize the work of=20 >others if you haven't written your own proposal. > >Ciao >Hannes > > > > >_______________________________________________ >nsis mailing list >nsis@ietf.org >https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Aug 02 04:47:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8CNt-0002Fd-MA; Wed, 02 Aug 2006 04:47:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8CNs-00024B-1S for nsis@ietf.org; Wed, 02 Aug 2006 04:47:20 -0400 Received: from mail.gmx.de ([213.165.64.21] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G8CNq-0005Lb-I2 for nsis@ietf.org; Wed, 02 Aug 2006 04:47:20 -0400 Received: (qmail invoked by alias); 02 Aug 2006 08:47:17 -0000 Received: from socks2.netz.sbs.de (EHLO [192.35.17.25]) [192.35.17.25] by mail.gmx.net (mp024) with SMTP; 02 Aug 2006 10:47:17 +0200 X-Authenticated: #29516787 Message-ID: <44D06693.4000501@gmx.net> Date: Wed, 02 Aug 2006 10:47:15 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: john.loughney@nokia.com Subject: Re: AW: [NSIS] Any resolution to the QSPEC mandatory parameter li st? References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Cc: RADHIKA.R.ROY@saic.com, nsis@ietf.org, robert.hancock@roke.co.uk X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Thanks for the nice summary, John. It is a good hint stop at this point. john.loughney@nokia.com wrote: > Hi all, > > I think this thread has out-lived its usefulness. Let me summarize. > NSIS has developed a layered signaling model (outlined in the > NSIS Framework RFC). NSIS is chartered not to develop new QoS > solutions, but to reuse and support other QoS solutions. The IESG > wanted us to consider how to support other SDO QoS solutions > as well as IETF QoS Solutions (intserv/diffserv). Solutions > developed outside of the IETF are clearly of Information status. > > Radhika would like NSIS QoS signaling to be able to support > signaling different QoS parameters directly - bandwidth, > Delay, Delay Jitter, Packet Loss, etc. These can be signaling > directly with the Qspec template - I think we might want to > think about creating a generic QoS model that allows endpoints to > signal only what parameters are needed. This way, if there are > QoS deployments that want to signal their QoS Models, than that > is possible - if there is need to signal just simple parameters > on an end-to-end basis, than that would be possible. > > In summary, NSIS is required to be able to signal other SDO's > QoS Models. By being able to signal these models, the IETF > is not implying the relative fitness of the specifications > developed elsewhere, but ensuring that NSIS's work supports deployments. > > If there is need / interest in signaling very simple or basic > parameters, > I suggest we consider how to generate a generic QoS model that allows > us to signal just the basic parameters on an as-needed basis. > > John > > > >>-----Original Message----- >>From: ext Roy, Radhika R. [mailto:RADHIKA.R.ROY@saic.com] >>Sent: 01 August, 2006 17:23 >>To: Hannes Tschofenig >>Cc: nsis@ietf.org; Hancock, Robert >>Subject: RE: AW: [NSIS] Any resolution to the QSPEC mandatory >>parameter li st? >> >>Hannes: >> >>You might be right to some extent as there are so many >>documents and each has many things inside it. >> >>Yes, the works are contribution driven based on its charter. >> >>The basic point, if I understand you correctly, QOS model in >>NSIS is under development for QOS signaling as we have been >>seeing some discussions are going on. >> >>What we are seeing here is this: There is a "gap" how to use >>the NSIS QOS model by the application like SIP. As you have >>said that the application will request QOS using NSIS QOS >>model. The application like SIP has to convert the e2e QOS >>needs per non-e2e NSIS QOS model. >> >>How the application like SIP will do it is not known - it is a >>"non-standard" scheme, and NSIS also does not want to address >>this as no one has brought contributions along this line. >> >>If it is true, let us make it is clear as objectives because >>no documents address this keeping this in disguise as if some >>miracle happens. >> >>That is point that I have been driving at for "complexity" of >>QOS parameter discussions that you have trying hard for >>mapping between NSIS QOS parameters to WiFi, WiMAX, cellular, IP, etc. >> >>Once we know this, we can easily fall back to the same schemes >>what other like DIAMETER are doing. >> >>Did I summarize correctly? I appreciate your patience. >> >>BR/Radhika >> >> _____ >> >>From: nsis-bounces@ietf.org on behalf of Hannes Tschofenig >>Sent: Tue 8/1/2006 6:07 AM >>To: Roy, Radhika R. >>Cc: nsis@ietf.org; Hancock, Robert >>Subject: Re: AW: [NSIS] Any resolution to the QSPEC mandatory >>parameter li st? >> >> >> >>Roy, >> >>to me it seems that you haven't read the existing NSIS documents. >>I strongly suggest that you should do that. You cannot put the >>workload on me to summarize the documents for you. Since the >>IETF is contribution driven I think you should also work on a >>draft that describes what you want. You might, for example, >>develop the QoS model. It is easy to criticize the work of >>others if you haven't written your own proposal. >> >>Ciao >>Hannes >> >> >> >> >>_______________________________________________ >>nsis mailing list >>nsis@ietf.org >>https://www1.ietf.org/mailman/listinfo/nsis >> > > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Aug 02 06:10:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8Dft-0001qh-9o; Wed, 02 Aug 2006 06:10:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8Dfs-0001qc-6A for nsis@ietf.org; Wed, 02 Aug 2006 06:10:00 -0400 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G8Dfq-0000fG-TB for nsis@ietf.org; Wed, 02 Aug 2006 06:10:00 -0400 Received: from [10.1.1.109] (mito.netlab.nec.de [195.37.70.39]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 3251E1BAC4D; Wed, 2 Aug 2006 11:53:09 +0200 (CEST) In-Reply-To: <20060731123814.GA7694@mafr.de> References: <20060712163212.GA8050@mafr.de> <778F8072-E72D-461D-80B0-74ED876772C0@netlab.nec.de> <20060731123814.GA7694@mafr.de> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <4F57D8D5-DE18-4E2B-97EA-1A491A831722@netlab.nec.de> Content-Transfer-Encoding: 7bit From: Martin Stiemerling Subject: Re: [NSIS] NATFW: LE-MRM and NATFW_DTINFO_IPv4/IPv6 Date: Wed, 2 Aug 2006 12:09:57 +0200 To: Matthias Friedrich X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Matthias, All, Am 31.07.2006 um 14:38 schrieb Matthias Friedrich: > Hi, > > On Monday, 2006-07-31, Martin Stiemerling wrote: > [ LE-MRM vs. PC-MRM etc. ] > > Thanks a lot for your detailed response. > > I think I understand now why the LE-MRM has been chosen, however, > I'm a bit unhappy about the special cases that have to be handled in > NATFW-implementations. Things are more tricky than I initially > thought, > but maybe I can work out an alternative that reduces complexity a bit > and post it to the list in the next couple of weeks. I'm fine with suggestions that make the protocol semantics and the implementation easier. I also would appreciate a review of the changed text around LE-MRM and PC-MRM in the upcoming revision of the NATFW NSLP. The new revision will be available around early October. Thanks, Martin _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Aug 02 07:17:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8EjR-0000jT-LE; Wed, 02 Aug 2006 07:17:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8EjQ-0000jM-3W for nsis@ietf.org; Wed, 02 Aug 2006 07:17:44 -0400 Received: from mail120.messagelabs.com ([216.82.250.83]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G8EjO-0003rg-O2 for nsis@ietf.org; Wed, 02 Aug 2006 07:17:44 -0400 X-VirusChecked: Checked X-Env-Sender: gash@att.com X-Msg-Ref: server-13.tower-120.messagelabs.com!1154517460!453890!2 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 2377 invoked from network); 2 Aug 2006 11:17:41 -0000 Received: from unknown (HELO attrh3i.attrh.att.com) (134.24.146.4) by server-13.tower-120.messagelabs.com with SMTP; 2 Aug 2006 11:17:41 -0000 Received: from kcclust06evs1.ugd.att.com (135.38.164.89) by attrh3i.attrh.att.com (7.2.052) id 44C39E8500148E7A; Wed, 2 Aug 2006 07:17:40 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: AW: [NSIS] Any resolution to the QSPEC mandatory parameter li st? Date: Wed, 2 Aug 2006 06:17:40 -0500 Message-ID: <9473683187ADC049A855ED2DA739ABCA0DDC7B9E@KCCLUST06EVS1.ugd.att.com> In-reply-to: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AW: [NSIS] Any resolution to the QSPEC mandatory parameter li st? Thread-Index: Aca1dmKgaxut6fQmRxqhOwzaLMyxfQAfkf3wAAvNu+A= From: "Ash, Gerald R \(Jerry\), ALABS" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: "Ash, Gerald R \(Jerry\), ALABS" , nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org John, > I think we might want to think about creating a generic QoS > model that allows endpoints to signal only what parameters > are needed.=20 Not sure I get what you mean. A QNI can already signal 'only what parameters are needed'. E.g., there is no need to signal all mandatory parameters, some or none can be signaled, for example (that's been a point of confusion). Jerry _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Aug 02 12:25:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8JXR-0000pk-Rj; Wed, 02 Aug 2006 12:25:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8JXQ-0000mB-Gd for nsis@ietf.org; Wed, 02 Aug 2006 12:25:40 -0400 Received: from mclmx2.mail.saic.com ([149.8.64.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G8JXO-0001nL-9b for nsis@ietf.org; Wed, 02 Aug 2006 12:25:40 -0400 Received: from 0015-its-ieg01.mail.saic.com ([149.8.64.21] [149.8.64.21]) by mclmx2.mail.saic.com; Wed, 2 Aug 2006 12:25:24 -0400 Received: from mcl-its-exig01.mail.saic.com ([149.8.64.12]) by 0015-its-ieg01.mail.saic.com (SMSSMTP 4.0.5.66) with SMTP id M2006080212252431984 ; Wed, 02 Aug 2006 12:25:24 -0400 Received: by mcl-its-exig01.mail.saic.com with Internet Mail Service (5.5.2657.72) id ; Wed, 2 Aug 2006 12:25:24 -0400 Message-Id: <62D92A9A02BCC845B202323D49A48426209DCC@0591-ITS-EXMP02.us.saic.com> From: "Roy, Radhika R." To: john.loughney@nokia.com, Hannes.Tschofenig@gmx.net Date: Wed, 2 Aug 2006 12:25:11 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) content-class: urn:content-classes:message Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: nsis@ietf.org Subject: [NSIS] NSIS QOS Model X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org John and Hannes: You have summarized an excellent conclusion from the previous thread as follows: 1. NSIS can use for signaling of e2e application QOS parameters (Bandwidth, Delay, Jitter, and Packet Loss) 2. NSIS can use network-specific e2e QOS parameters that go beyond above 4 parameters as many network-specific QOS models like DSTE, MPLS, IP, WiFi, WiMax, Y.xxxx, cellular, satellite etc. are doing. IESG wants to address this. (Hannes is trying to hard to map NSIS QOS Model to all of those.) Well, NSIS may use a generic network-specific QOS model of many parameters to address item 2. Let us also hope that NSIS would also address the mapping between items 1 and 2 as NSIS charter is to support the QOS for applications. For example, the SIP application will express its QOS parameters in item 1 and if the network supports item 2, NSIS needs to address the mapping between the two as well from standardization point of view. WG may invite contributions to address this if the present contributions do not like to address this. Best regards, Radhika _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Aug 02 13:27:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8KV4-0008Qi-V9; Wed, 02 Aug 2006 13:27:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8KV3-0008Qd-Qc for nsis@ietf.org; Wed, 02 Aug 2006 13:27:17 -0400 Received: from gecko.sbs.de ([194.138.37.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G8KV2-0005OZ-90 for nsis@ietf.org; Wed, 02 Aug 2006 13:27:17 -0400 Received: from mail1.sbs.de (localhost [127.0.0.1]) by gecko.sbs.de (8.12.6/8.12.6) with ESMTP id k72HRFL2002544 for ; Wed, 2 Aug 2006 19:27:15 +0200 Received: from fthw9xoa.ww002.siemens.net (fthw9xoa.ww002.siemens.net [157.163.133.201]) by mail1.sbs.de (8.12.6/8.12.6) with ESMTP id k72HRFUt007796 for ; Wed, 2 Aug 2006 19:27:15 +0200 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xoa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 2 Aug 2006 19:27:14 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 2 Aug 2006 19:27:14 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IP options and NATs Thread-Index: Aca2T10k3knVr1pzTAaNALWToWWOuAABfnXg From: "Tschofenig, Hannes" To: X-OriginalArrivalTime: 02 Aug 2006 17:27:14.0880 (UTC) FILETIME=[E567CC00:01C6B658] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Subject: [NSIS] WG: IP options and NATs X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi all,=20 Does anyone know something about the handling of RAO by NATS? Ciao Hannes -----Urspr=FCngliche Nachricht----- Von: Dan Wing [mailto:dwing@cisco.com]=20 Gesendet: Mittwoch, 2. August 2006 18:20 An: ietf-behave@list.sipfoundry.org Cc: Pashalidis, Andreas; Tschofenig, Hannes Betreff: IP options and NATs While reviewing draft-pashalidis-nsis-gist-legacynats-00.txt, I noticed: > The discussion in this document is based on the > following assumptions. =20 > ... > 6. The legacy NAT does not drop IP packets with a > Router Alert Option (RAO) or an IPv6 extensions > header. Furthermore, the RAO or extension header > is also present in the forwarded packet. If the > NAT does not do this, then there is no way for a > GIST QUERY to traverse the NAT, which is a > prerequisite for the mechanisms described in this > document. I am wondering how today's NATs handle IP options. I asked our = engineering teams and found that Cisco's IOS NAT preserves IP options across the = NAT, but our PIX and our ASA drop all IP options. Testing will be necessary = to determine how various residential style NATs (Linksys, etc.) handle IP options such as RAO. Does anyone know what other NATs do with RAO? -d _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Aug 03 06:13:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8aCp-0006np-TW; Thu, 03 Aug 2006 06:13:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8aCo-0006nk-U3 for nsis@ietf.org; Thu, 03 Aug 2006 06:13:30 -0400 Received: from difra-computer.de ([81.169.157.103] helo=www.difra-computer.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G8aCm-0003yJ-Ka for nsis@ietf.org; Thu, 03 Aug 2006 06:13:30 -0400 Received: from win2003.dickmann2003.home (p548A5165.dip.t-dialin.net [84.138.81.101]) by www.difra-computer.de (Postfix) with ESMTP id B942C3E4028 for ; Thu, 3 Aug 2006 12:11:29 +0200 (CEST) Received: from localhost ([192.168.0.5]) by win2003.dickmann2003.home with Microsoft SMTPSVC(6.0.3790.1830); Thu, 3 Aug 2006 12:01:54 +0200 MIME-Version: 1.0 Date: Thu, 3 Aug 2006 12:10:12 +0200 From: Christian Dickmann To: nsis@ietf.org Message-ID: <9611c181010dcbcccb963106770a1014@192.168.0.7> X-Sender: mail@christian-dickmann.de User-Agent: RoundCube Webmail/0.1b Content-Type: text/plain; charset="UTF-8" X-OriginalArrivalTime: 03 Aug 2006 10:01:54.0851 (UTC) FILETIME=[D970AF30:01C6B6E3] Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.1 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Subject: [NSIS] Loose-End MRM Direction X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Robert, I just read the text about Loose-End MRM again and wondered about the text "D flag: The direction flag. The only valid=20 value is D=3D0 (see Section 5.8.2)." The NATFW NSLP defines to use LEMRM for some cases of the REA message. I wonder how the response can travel back to the initiator if only downstream direction is allowed. Even a GIST Query/Response would not work, as according to Section 5.1 of the GIST draft the Response has inverted direction. "Note that the direction of this MRI will be inverted compared to that in the Query, that is, an upstream MRI becomes downstream and vice versa (see Section 3.3)." So I wondered if maybe using LEMRM implicitly means, that there is no GIST routing-state installed, but the question remains how to send the response to the REA back to initiator. Can you please clarify this? Christian Dickmann _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Aug 08 04:28:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAMx5-0006C6-QH; Tue, 08 Aug 2006 04:28:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAMx2-00062j-1u for nsis@ietf.org; Tue, 08 Aug 2006 04:28:36 -0400 Received: from iramx1.ira.uni-karlsruhe.de ([141.3.10.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAMwz-0004K8-Eg for nsis@ietf.org; Tue, 08 Aug 2006 04:28:36 -0400 Received: from i72ms2.tm.uni-karlsruhe.de ([141.3.70.17] helo=smtp.ipv6.tm.uni-karlsruhe.de) by iramx1.ira.uni-karlsruhe.de with esmtps id 1GAMwX-0008Vk-MJ; Tue, 08 Aug 2006 10:28:18 +0200 Received: from vorta.ipv6.tm.uni-karlsruhe.de (vorta.ipv6.tm.uni-karlsruhe.de [IPv6:2001:638:204:6:207:e9ff:fe0c:5e44]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id 6D61BBF53; Tue, 8 Aug 2006 10:28:05 +0200 (CEST) Received: from localhost ([127.0.0.1]) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.44) id 1GAMwX-0000HR-5g; Tue, 08 Aug 2006 10:28:05 +0200 Message-ID: <44D84B14.2020004@tm.uka.de> Date: Tue, 08 Aug 2006 10:28:04 +0200 From: Roland Bless Organization: Institute of Telematics, University of Karlsruhe User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060111 Thunderbird/1.5 Mnenhy/0.7.3.0 MIME-Version: 1.0 To: "Hancock, Robert" Subject: Re: [NSIS] Last Call: 'GIST: General Internet Signaling Transport' to Proposed Standard (draft-ietf-nsis-ntlp) References: In-Reply-To: X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: -4.2 (----) X-Spam-Status: No X-Spam-Report: -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] 0.2 AWL AWL: From: address is in the auto white-list X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 Cc: Mark Doll , nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Robert, > inline: dito >> -----Original Message----- >> From: Roland Bless [mailto:bless@tm.uka.de] >> Sent: 01 August 2006 15:39 >> To: Hancock, Robert >> Cc: Mark Doll; nsis@ietf.org >> Subject: Re: [NSIS] Last Call: 'GIST: General Internet >> Signaling Transport' to Proposed Standard (draft-ietf-nsis-ntlp) >> >> >> Hi Robert, >> >>>> However, I would really like to see a clear statement like: >>>> GN2 sends the Response in D-mode directly to GN1, using >>>> the interface-address as destination addess as specified >>>> in the NLI of the query and the source port of the query >>>> as destination port of the response. >>> there are three parts to the answer here: >>> >>> 1) the underlying requirement is to get the message to the right >>> node; apart from this, the encapsulation doesn't matter. >> That sounds logical, but it is quite fuzzy... >> I guess this will lead to different results depending >> on the particular implementation. > > it is not quite that bad. i can think of some more deterministic > text (see below). however, the key message from (1) in particular > would be something like: > "once the Querying has received a Response message, it MUST ignore > the addressing data from the IP header" > (or something like that). to some extent, i don't care about fuzzyness > of sender behaviour if it is not relevant to the receiver. Hmm, in this case you mean sender/receiver of GIST messages, not data sender... >>> so i can imagine writing something more explicit, but i >>> wouldn't want to pin it down to the extent of ruling out >>> the flexibility required by (3), expecially given the overall >>> criterion (1) - that it shouldn't matter provided it works. >>> more text suggestions welcome ;-) >> Hmm, actually I don't know how one could implement a robust >> scheme that works in all situations. I understood at least >> this: >> a) if no MA for given NLI exists then use D-Mode and send RESPONSE >> back to NLI (BTW: what if NLI is obviously useless, e.g. ::, >> 0.0.0.0, ::1 or unrouteable, should we send back an error to >> the source - I guess we have no suitable error code for that yet?) > > i would guess: > object value error with subcode 1, sent back to the IP source > if S=1 else logging an error locally. (section 5.6 says this to > some extent, but we don't try to define absolutely every condition...) Yep. That's ok. >> b) if MA for NLI exists, send RESPONSE back via that MA > > if it matches the re-use criteria (see the end of section 5.7.1). Sure. >> c) the GIST node could also send the response back to the source if >> no S-flag is set. Has this precedence over a)? Only in certain >> environments? > > i think you mean "if S *is* set". i would probably make this a > SHOULD given that we always initially have S=0 in the first Query. Yep, sorry I confused the S-Flag setting. >> So usually I would use a) and b) but you also suggest that c) >> might be useful in certain NAT scenarios... >> >>>> B) >>>> if the response must be sent back to what is specified in the >>>> NLI, this possibly opens up reflection attacks. This should be >>>> mentioned in the security considerations section and I'm not quite >>>> sure whether any sanity checks are possible to prevent this. >>> this is the intention (one of the intentions) of the 3rd requirement >>> on the Q-cookie in section 8.5 (easily validated ... to discard >>> responses to spoofed queries). i don't see what other sanity >>> checks are possible to prevent this. >> This only covers a part of my question. So an NSIS node >> will discard responses to spoofed queries, this is good. >> Assume that an attacker A sends a query with the NLI containing the >> address of the victim V. The responder R will nevertheless >> answer the query and send the RESPONSE to V. This is a reflection >> attack and doesn't require spoofing the source address of the query >> (which can be A's address). > > i probably use the word 'spoofed' here less precisely. by 'spoofed > query' i mean 'any query that the receiver of the Response did not > actually send' (not only with a forged source address). > >> In case the response is larger than the query the attacker cannot >> only hide behind the reflector, he can also use slight amplification >> as benefit. > > yes, but it really is minimal - there is no increase in the number of > messages and the message size change is marginal. Yep, however it should be mentioned in the security considerations. >> I meant sanity checks on the side of the responder: >> it is not easily possible to check that NLI and source address >> correspond to each other, because they may intentionally differ... > > indeed they may. and i think it is useful to preserve this flexibility. Agreed. > there are constraints on both the IP source and NLI interface-address; > the former are to do with possible implementation restrictions and > the latter to do with route change detection for some MRMs. we cannot > rule out that those constraints will always be satisfiable by the same > address. Yep, Roland _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Aug 09 11:25:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GApvX-0001wL-0c; Wed, 09 Aug 2006 11:24:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GApvW-0001wC-0T for nsis@ietf.org; Wed, 09 Aug 2006 11:24:58 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAnlx-00018X-IO for nsis@ietf.org; Wed, 09 Aug 2006 09:06:57 -0400 Received: from iramx1.ira.uni-karlsruhe.de ([141.3.10.80]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GAnZg-0003xE-GN for nsis@ietf.org; Wed, 09 Aug 2006 08:54:17 -0400 Received: from i72ms2.tm.uni-karlsruhe.de ([141.3.70.17] helo=smtp.ipv6.tm.uni-karlsruhe.de) by iramx1.ira.uni-karlsruhe.de with esmtps id 1GAnZQ-0005VX-JU; Wed, 09 Aug 2006 14:54:02 +0200 Received: from vorta.ipv6.tm.uni-karlsruhe.de (vorta.ipv6.tm.uni-karlsruhe.de [IPv6:2001:638:204:6:207:e9ff:fe0c:5e44]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id 58FE2BF45; Wed, 9 Aug 2006 14:54:00 +0200 (CEST) Received: from localhost ([127.0.0.1]) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.44) id 1GAnZQ-0002Bx-2R; Wed, 09 Aug 2006 14:54:00 +0200 Message-ID: <44D9DAE7.9050807@tm.uka.de> Date: Wed, 09 Aug 2006 14:53:59 +0200 From: Roland Bless Organization: Institute of Telematics, University of Karlsruhe User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060111 Thunderbird/1.5 Mnenhy/0.7.3.0 MIME-Version: 1.0 To: Christian Dickmann , "Hancock, Robert" Subject: Re: [NSIS] Loose-End MRM Direction References: <9611c181010dcbcccb963106770a1014@192.168.0.7> In-Reply-To: <9611c181010dcbcccb963106770a1014@192.168.0.7> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Score: -4.2 (----) X-Spam-Status: No X-Spam-Report: -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] 0.2 AWL AWL: From: address is in the auto white-list X-Spam-Score: -2.6 (--) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Christian, Christian Dickmann wrote: > I just read the text about Loose-End MRM again and wondered > about the text "D flag: The direction flag. The only valid > value is D=0 (see Section 5.8.2)." Good point! We are indeed a little bit confused, too. The draft also says in sec. 5.8.2.1: Additional control information defines the direction of the message relative to this flow as in the path-coupled case. What control information in which protocol? In GIST or in the NSLP? Or do you mean the D-flag (which is currently pretty useless)? > The NATFW NSLP defines to use LEMRM for some cases of the REA > message. I wonder how the response can travel back to > the initiator if only downstream direction is allowed. Actually that could be figured out by checking who actually sent the message, i.e. upstream or downstream peer. In either case you must forward it to the other peer. But that would break implementations that rely on evaluating the D-flag while routing messages and I think it will be an inconsequent use of the D-flag. Actually change history says: 23. Clarified why only D=0 is valid for the loose-end MRM in Appendix A.3.1.2 [AD review comment L23]. but frankly I don't see any explanation for this. > Even a GIST Query/Response would not work, as according to > Section 5.1 of the GIST draft the Response has inverted direction. > "Note that the direction of this MRI will be > inverted compared to that in the Query, that is, an upstream MRI > becomes downstream and vice versa (see Section 3.3)." > > So I wondered if maybe using LEMRM implicitly means, that > there is no GIST routing-state installed, but the question > remains how to send the response to the REA back to initiator. A possibility would be to forward a message to the upstream peer if it came from the downstream peer and vice versa. But I'm not sure that this will work in all cases. > Can you please clarify this? We are also looking forward to an answer. Regards, Roland _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Aug 09 12:53:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GArJ1-000308-6U; Wed, 09 Aug 2006 12:53:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GArJ0-0002vJ-3I for nsis@ietf.org; Wed, 09 Aug 2006 12:53:18 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAq3k-0007eM-Hk for nsis@ietf.org; Wed, 09 Aug 2006 11:33:28 -0400 Received: from iramx1.ira.uni-karlsruhe.de ([141.3.10.80]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GApvf-0006Lb-Qu for nsis@ietf.org; Wed, 09 Aug 2006 11:25:09 -0400 Received: from i72ms2.tm.uni-karlsruhe.de ([141.3.70.17] helo=smtp.ipv6.tm.uni-karlsruhe.de) by iramx1.ira.uni-karlsruhe.de with esmtps id 1GApvU-0001cT-Ch; Wed, 09 Aug 2006 17:25:04 +0200 Received: from vorta.ipv6.tm.uni-karlsruhe.de (vorta.ipv6.tm.uni-karlsruhe.de [IPv6:2001:638:204:6:207:e9ff:fe0c:5e44]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id 2B044BF2A; Wed, 9 Aug 2006 17:24:56 +0200 (CEST) Received: from localhost ([127.0.0.1]) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.44) id 1GApvT-0002Hv-M1; Wed, 09 Aug 2006 17:24:55 +0200 Message-ID: <44D9FE47.4060104@tm.uka.de> Date: Wed, 09 Aug 2006 17:24:55 +0200 From: Roland Bless Organization: Institute of Telematics, University of Karlsruhe User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060111 Thunderbird/1.5 Mnenhy/0.7.3.0 MIME-Version: 1.0 To: Martin Stiemerling Subject: Re: [NSIS] NATFW: LE-MRM and NATFW_DTINFO_IPv4/IPv6 References: <20060712163212.GA8050@mafr.de> <778F8072-E72D-461D-80B0-74ED876772C0@netlab.nec.de> In-Reply-To: <778F8072-E72D-461D-80B0-74ED876772C0@netlab.nec.de> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: -4.2 (----) X-Spam-Status: No X-Spam-Report: -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] 0.2 AWL AWL: From: address is in the auto white-list X-Spam-Score: -2.6 (--) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Martin, Martin Stiemerling wrote: > The LE-MRM has been just defined for the NAT usage and is not intended > for pure firewall usage. The main difference between LE-MRM and the > PC-MRM in the NAT case is: The message can probably not be forwarded > when the receiver is behind a NAT and it is using the PC-MRM with a > wildcarded sender IP address. When there are multiple NATs in parallel > to the Internet, GIST may have the issue of not knowing which route to > take. In this case GIST would return an error message. By using the Sorry, but I absolutely don't get it. Why doesn't the GIST node know which route to take? So a route lookup for the prefix N doesn't succeed in this case (no route) or returns more than one entry (should not happen), or what? I can only imagine the "MRI too wild case", i.e., specifying a /7 when you only have /8s or so. So what I understand from the draft and you mail is that: - DS is currently unknown and somewhere outside your (DRs) NATed domain. - DR wants to do a REA first which also includes a route pinning, i.e. no matter which NAT your REA hits, the incoming stream from DS will then hit that particular NAT. - DR sends a REA message "upstream" towards some external node with IP address LS (and maybe LS!=DS) behind the NAT. So the SDA is LS which is also used in the LE-MRM as destination. Why, then can't we use the very same address in a PC-MRM, so ip.src=R, ip.dst=LS, pc-mrm.src= LS, pc-mrm.dst= R, pc-mrm.direction=upstream pc-mrm.prefixlength=32? So it's not a wildcarded PC-MRM. In this case I don't see any routing problem for GIST. Or, what is the reason that we must use a wildcarded PC-MRM? > LE-MRM, GIST is always able to route the message upstream to "a" NAT. In > the first place it is not necessary to hit the best NAT, i.e., closest > to the data sender but to get a public reachable IP address. By choosing > different SDAs, one may get a better or worse located NAT. I understand and this is also clear. If you vary LS, your NAT may differ, but this doesn't matter (except for suboptimal routing) because you pin down the route by hitting the NAT. > It is not that easy, because LE-MRM gives more power to hosts behind > NATs. LE-MRM will definitely find an edge-NAT while PC-MRM can easily > fail if there are multiple NATs in parallel. Sorry, but it's not clear to me why the LE-MRM gives more power to hosts. If we use a PC-MRM like in the scenario above, there will be no problem, or, can you explain once again, giving a concrete example, why it would fail? > However, it is time to rework the section(s) on the LE-MRM/PC-MRM usage > (plus DTINFO) for getting it all clear. I see the issue of having the > information about the MRM usage spread too much over the document and > lack of some good introductory text. There will be an updated text in > the next version clarifying this. Actually the "magic" or "special power" behind the LE-MRM is currently not getting clear. Maybe there are some implicit assumptions that are not written down yet. Regards, Roland _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Aug 09 19:59:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAxxT-0002dg-3c; Wed, 09 Aug 2006 19:59:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAxxS-0002db-Ba for nsis@ietf.org; Wed, 09 Aug 2006 19:59:30 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAxxR-0006uM-3C for nsis@ietf.org; Wed, 09 Aug 2006 19:59:30 -0400 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-5.cisco.com with ESMTP; 09 Aug 2006 16:59:29 -0700 X-IronPort-AV: i="4.08,107,1154934000"; d="scan'208"; a="310824860:sNHT29808132" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-6.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k79NxSp2024661; Wed, 9 Aug 2006 16:59:28 -0700 Received: from dwingwxp (che-vpn-cluster-1-280.cisco.com [10.86.241.25]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k79NxQIZ018438; Wed, 9 Aug 2006 16:59:27 -0700 (PDT) From: "Dan Wing" To: , Date: Wed, 9 Aug 2006 16:59:21 -0700 Message-ID: <0c9601c6bc0f$d91485d0$2182200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: Aca8D9T3uNikOz+dR12gtJmxkkTWGQ== DKIM-Signature: a=rsa-sha1; q=dns; l=328; t=1155167968; x=1156031968; c=relaxed/simple; s=sjdkim6002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=22Dan=20Wing=22=20 |Subject:IP=20options=20and=20NATs; X=v=3Dcisco.com=3B=20h=3DjX2tQZLfqPwUE60AcjU3SyFGjvM=3D; b=ACRobhkm4rHlDExxhrlgq/SMzhq2FlMj9EvC/VaqjO3tANdsVrvf3LFOGF+ephLHG++ptCOL mKuu7WQoTQj+dgUMhZPHpXGUXrfQl974SFb8GswPXGSnXNodGDjTqCOx; Authentication-Results: sj-dkim-6.cisco.com; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: Subject: [NSIS] IP options and NATs X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org An update: I just tried sending UDP packets with IP options set through a Linksys WRT54Gv2 and I could successfully pass packets from inside->outside. I didn't try outside->inside. (Originally I was testing to a system on the Internet, but something was dropping my packets with IP options, as was cited earlier.) -d _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Aug 10 05:00:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GB6PC-00078o-C7; Thu, 10 Aug 2006 05:00:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GB6PB-00078F-AM for nsis@ietf.org; Thu, 10 Aug 2006 05:00:41 -0400 Received: from difra-computer.de ([81.169.157.103] helo=www.difra-computer.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GB6On-0006j1-P9 for nsis@ietf.org; Thu, 10 Aug 2006 05:00:19 -0400 Received: from win2003.dickmann2003.home (p548A609E.dip.t-dialin.net [84.138.96.158]) by www.difra-computer.de (Postfix) with ESMTP id 39AC23E4028 for ; Thu, 10 Aug 2006 10:57:28 +0200 (CEST) Received: from localhost ([192.168.0.5]) by win2003.dickmann2003.home with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 Aug 2006 10:49:12 +0200 MIME-Version: 1.0 Date: Thu, 10 Aug 2006 10:57:41 +0200 From: Christian Dickmann To: nsis@ietf.org Subject: Re: [NSIS] Last Call: 'GIST: General Internet Signaling Transport'to Proposed Standard (draft-ietf-nsis-ntlp) Message-ID: <3ec2d6da70e2c8097de9dc4967c7bacb@192.168.0.7> X-Sender: mail@christian-dickmann.de User-Agent: RoundCube Webmail/0.1b Content-Type: text/plain; charset="UTF-8" X-OriginalArrivalTime: 10 Aug 2006 08:49:12.0029 (UTC) FILETIME=[D9E320D0:01C6BC59] Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.1 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: robert.hancock@roke.co.uk X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi, I did a brief review of the GIST draft and here are my comments: Issue 1) In Figure 11 of Appendix C the GIST Confirm has no Stack- Configuration-Data object included. However, section 5.1 says: "The first message on an association MUST also repeat the Stack-Configuration- Data from the original Query in an abbreviated form, just containing the MA-Hold-Time." As the example in Figure 11 builds a new MA, the SCD should be contained in the Confirm. In addition, the MA-Hold-Time is not listed in the Query-= SCD in Figure 11. It would make sense to include it, to show the difference betw= een the full and abbreviated form of the SCD. Issue 2) Section 5.3.2 defines that a Q-mode encapsulated message has to = contain a RAO. In contrast, a lot of other encapsulation details are part of the = definition of the Message-Routing-Method, e.g. section 5.8.1.2 for downstream Q-mode= encapsulation for path-coupled MRM. Moving the RAO decision to the MRM definition seems= reasonable to me, as that would allow a wider range of MRMs, but not change the sema= ntics of the current specification. For example, one could define a MRM which build the interception of messa= ges on=20 a specific port number. Such a MRM should NOT contain a RAO. But such a M= RM would currently require changing the GIST specification instead of just definin= g a MRM. Issue 3) In section 5.2.1 "The Common Header" the GIST draft defines, tha= t the current GIST version number is 1. However, this is not listed in the IANA Conside= rations. As far as I can see, the IANA Considerations do not even cover how future versio= ns of GIST=20 can be defined. I am not sure, but shouldn't this be covered? Issue 4) In Section 5.1 DATA messages are defined without the possibility= to add=20 a NAT-Traversal-Object (NTO). While this is reasonable for normal D-Mode = or C-Mode=20 DATA messages, I think Q-mode encapsulated DATA messages (those DATA mess= ages, which are used in the stateless GIST operation) should be translated in NATs an= d a=20 NTO should be added.=20 Issue 5) I am still confused by the D-Flag of the Loose-End-MRM (see othe= r mail on the mailing list). Some additional thoughts: Section A.3.1.2 "Loose-En= d MRM" defines: "D flag: The direction flag. The only valid value is D=3D0 (see Section = 5.8.2)." So what does section 5.8.2 say? It says, that only downstream Q-mode enca= psulation is defined for LE-MRM (and NOT upstream Q-mode encapsulation like in the = PC-MRM case). However, this only refers to Q-mode encapsulation and not to the normal D= -Mode one, right? Thus, I do not need an upstream Q-mode encapsulation to send a D-M= ode message upstream (like a RESPONSE). Therefore, I have no clue, why section 5.8.2 = should tell me, that the only possible value of the direction flag in LE-MRM is = 0. Regards, Christian Dickmann _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Aug 10 10:44:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBBm4-0001JC-6L; Thu, 10 Aug 2006 10:44:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBBm2-0001Ey-VM for nsis@ietf.org; Thu, 10 Aug 2006 10:44:38 -0400 Received: from rsys002x.roke.co.uk ([193.118.201.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GBBm1-0008PU-BJ for nsis@ietf.org; Thu, 10 Aug 2006 10:44:38 -0400 Received: from rsys005a.comm.ad.roke.co.uk (rsys005a [193.118.193.85]) by rsys002x.roke.co.uk (8.13.1/8.13.1) with ESMTP id k7AEiPsI012789; Thu, 10 Aug 2006 15:44:25 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] Last Call: 'GIST: General Internet Signaling Transport' to Proposed Standard (draft-ietf-nsis-ntlp) Date: Thu, 10 Aug 2006 15:44:25 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] Last Call: 'GIST: General Internet Signaling Transport' to Proposed Standard (draft-ietf-nsis-ntlp) Thread-Index: Aca6xL38ozYjWe6SRUKXcjyf5K4V+wBuzzKQ From: "Hancock, Robert" To: "Roland Bless" X-MailScanner-roke-co-uk: Found to be clean X-MailScanner-roke-co-uk-SpamCheck: X-MailScanner-From: robert.hancock@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 3fbd9b434023f8abfcb1532abaec7a21 Cc: Mark Doll , nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org hi roland, i've created issues and updated text for both of these at http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-ntlp-issues/issue113 and=20 http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-ntlp-issues/issue114 you might like to take a look and see if they are clear. cheers, robert h. > -----Original Message----- > From: Roland Bless [mailto:bless@tm.uka.de]=20 > Sent: 08 August 2006 09:28 > To: Hancock, Robert > Cc: Mark Doll; nsis@ietf.org > Subject: Re: [NSIS] Last Call: 'GIST: General Internet=20 > Signaling Transport' to Proposed Standard (draft-ietf-nsis-ntlp) >=20 >=20 > Hi Robert, >=20 > > inline: >=20 > dito >=20 > >> -----Original Message----- > >> From: Roland Bless [mailto:bless@tm.uka.de]=20 > >> Sent: 01 August 2006 15:39 > >> To: Hancock, Robert > >> Cc: Mark Doll; nsis@ietf.org > >> Subject: Re: [NSIS] Last Call: 'GIST: General Internet=20 > >> Signaling Transport' to Proposed Standard (draft-ietf-nsis-ntlp) > >> > >> > >> Hi Robert, > >> > >>>> However, I would really like to see a clear statement like: > >>>> GN2 sends the Response in D-mode directly to GN1, using > >>>> the interface-address as destination addess as specified > >>>> in the NLI of the query and the source port of the query > >>>> as destination port of the response. > >>> there are three parts to the answer here: > >>> > >>> 1) the underlying requirement is to get the message to the right > >>> node; apart from this, the encapsulation doesn't matter. > >> That sounds logical, but it is quite fuzzy... > >> I guess this will lead to different results depending > >> on the particular implementation. > >=20 > > it is not quite that bad. i can think of some more deterministic > > text (see below). however, the key message from (1) in particular > > would be something like: > > "once the Querying has received a Response message, it MUST ignore=20 > > the addressing data from the IP header" > > (or something like that). to some extent, i don't care=20 > about fuzzyness > > of sender behaviour if it is not relevant to the receiver. >=20 > Hmm, in this case you mean sender/receiver of GIST messages, not > data sender... >=20 > >>> so i can imagine writing something more explicit, but i > >>> wouldn't want to pin it down to the extent of ruling out > >>> the flexibility required by (3), expecially given the overall > >>> criterion (1) - that it shouldn't matter provided it works. > >>> more text suggestions welcome ;-) > >> Hmm, actually I don't know how one could implement a robust > >> scheme that works in all situations. I understood at least > >> this: > >> a) if no MA for given NLI exists then use D-Mode and send RESPONSE > >> back to NLI (BTW: what if NLI is obviously useless, e.g. ::, > >> 0.0.0.0, ::1 or unrouteable, should we send back an error to > >> the source - I guess we have no suitable error code for=20 > that yet?) > >=20 > > i would guess: > > object value error with subcode 1, sent back to the IP source > > if S=3D1 else logging an error locally. (section 5.6 says this to > > some extent, but we don't try to define absolutely every=20 > condition...) >=20 > Yep. That's ok. >=20 > >> b) if MA for NLI exists, send RESPONSE back via that MA > >=20 > > if it matches the re-use criteria (see the end of section 5.7.1). >=20 > Sure. >=20 > >> c) the GIST node could also send the response back to the source if > >> no S-flag is set. Has this precedence over a)? Only in certain > >> environments? > >=20 > > i think you mean "if S *is* set". i would probably make this a > > SHOULD given that we always initially have S=3D0 in the first Query. >=20 > Yep, sorry I confused the S-Flag setting. >=20 > >> So usually I would use a) and b) but you also suggest that c) > >> might be useful in certain NAT scenarios... > >> > >>>> B) > >>>> if the response must be sent back to what is specified in the > >>>> NLI, this possibly opens up reflection attacks. This should be > >>>> mentioned in the security considerations section and I'm=20 > not quite > >>>> sure whether any sanity checks are possible to prevent this. > >>> this is the intention (one of the intentions) of the 3rd=20 > requirement > >>> on the Q-cookie in section 8.5 (easily validated ... to discard > >>> responses to spoofed queries). i don't see what other sanity=20 > >>> checks are possible to prevent this. > >> This only covers a part of my question. So an NSIS node > >> will discard responses to spoofed queries, this is good. > >> Assume that an attacker A sends a query with the NLI containing the > >> address of the victim V. The responder R will nevertheless > >> answer the query and send the RESPONSE to V. This is a reflection > >> attack and doesn't require spoofing the source address of the query > >> (which can be A's address). > >=20 > > i probably use the word 'spoofed' here less precisely. by 'spoofed > > query' i mean 'any query that the receiver of the Response did not > > actually send' (not only with a forged source address). > >=20 > >> In case the response is larger than the query the attacker cannot > >> only hide behind the reflector, he can also use slight=20 > amplification > >> as benefit. > >=20 > > yes, but it really is minimal - there is no increase in the=20 > number of > > messages and the message size change is marginal. >=20 > Yep, however it should be mentioned in the security considerations. >=20 > >> I meant sanity checks on the side of the responder: > >> it is not easily possible to check that NLI and source address > >> correspond to each other, because they may intentionally differ... > >=20 > > indeed they may. and i think it is useful to preserve this=20 > flexibility. >=20 > Agreed. >=20 > > there are constraints on both the IP source and NLI=20 > interface-address; > > the former are to do with possible implementation restrictions and > > the latter to do with route change detection for some MRMs.=20 > we cannot > > rule out that those constraints will always be satisfiable=20 > by the same > > address. >=20 >=20 > Yep, > Roland >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Aug 10 11:32:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBCW0-0006sm-47; Thu, 10 Aug 2006 11:32:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBCVz-0006sa-6m for nsis@ietf.org; Thu, 10 Aug 2006 11:32:07 -0400 Received: from rsys002x.roke.co.uk ([193.118.201.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GBCVx-0005QN-OD for nsis@ietf.org; Thu, 10 Aug 2006 11:32:07 -0400 Received: from rsys005a.comm.ad.roke.co.uk (rsys005a [193.118.193.85]) by rsys002x.roke.co.uk (8.13.1/8.13.1) with ESMTP id k7AFVtf6021480; Thu, 10 Aug 2006 16:31:55 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] Loose-End MRM Direction Date: Thu, 10 Aug 2006 16:31:55 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] Loose-End MRM Direction Thread-Index: Aca7yBjOnK5AqqSNRumi6UNZpdyBGAAyOBtQ From: "Hancock, Robert" To: "Roland Bless" , "Christian Dickmann" X-MailScanner-roke-co-uk: Found to be clean X-MailScanner-roke-co-uk-SpamCheck: X-MailScanner-From: robert.hancock@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org hi folks, there is no mystery here, it is just my screwup. Magnus' review highlighted the earlier text as being unclear and I tried to make it clearer; what I missed was that the earlier text was wrong and I just made it clearly wrong. The intent that *for Query encapsulated messages* only D=3D0 is allowed. I'll add that in the next version. see also http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-ntlp-issues/issue115 cheers, robert h. > -----Original Message----- > From: Roland Bless [mailto:bless@tm.uka.de]=20 > Sent: 09 August 2006 13:54 > To: Christian Dickmann; Hancock, Robert > Cc: nsis@ietf.org > Subject: Re: [NSIS] Loose-End MRM Direction >=20 >=20 > Hi Christian, >=20 > Christian Dickmann wrote: >=20 > > I just read the text about Loose-End MRM again and wondered > > about the text "D flag: The direction flag. The only valid=20 > > value is D=3D0 (see Section 5.8.2)." >=20 > Good point! We are indeed a little bit confused, too. > The draft also says in sec. 5.8.2.1: > Additional control information=20 > defines the > direction of the message relative to this flow as in the=20 > path-coupled > case. >=20 > What control information in which protocol? In GIST or in the NSLP? > Or do you mean the D-flag (which is currently pretty useless)? >=20 > > The NATFW NSLP defines to use LEMRM for some cases of the REA > > message. I wonder how the response can travel back to > > the initiator if only downstream direction is allowed. >=20 > Actually that could be figured out by checking who actually > sent the message, i.e. upstream or downstream peer. In either > case you must forward it to the other peer. But that would break > implementations that rely on evaluating the D-flag while routing > messages and I think it will be an inconsequent use of the D-flag. > Actually change history says: > 23. Clarified why only D=3D0 is valid for the loose-end MRM in > Appendix A.3.1.2 [AD review comment L23]. > but frankly I don't see any explanation for this. >=20 > > Even a GIST Query/Response would not work, as according to > > Section 5.1 of the GIST draft the Response has inverted direction. > > "Note that the direction of this MRI will be > > inverted compared to that in the Query, that is, an upstream MRI > > becomes downstream and vice versa (see Section 3.3)." > >=20 > > So I wondered if maybe using LEMRM implicitly means, that > > there is no GIST routing-state installed, but the question > > remains how to send the response to the REA back to initiator. >=20 > A possibility would be to forward a message to the > upstream peer if it came from the downstream peer > and vice versa. But I'm not sure that this will work > in all cases. >=20 > > Can you please clarify this? >=20 > We are also looking forward to an answer. >=20 > Regards, > Roland >=20 > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Aug 10 11:42:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBCgJ-0004hJ-M4; Thu, 10 Aug 2006 11:42:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBCgH-0004hD-TP for nsis@ietf.org; Thu, 10 Aug 2006 11:42:45 -0400 Received: from difra-computer.de ([81.169.157.103] helo=www.difra-computer.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GBCgG-0007NH-Ke for nsis@ietf.org; Thu, 10 Aug 2006 11:42:45 -0400 Received: from win2003.dickmann2003.home (p548A609E.dip.t-dialin.net [84.138.96.158]) by www.difra-computer.de (Postfix) with ESMTP id 0B9713E4028 for ; Thu, 10 Aug 2006 17:39:56 +0200 (CEST) Subject: RE: [NSIS] Loose-End MRM Direction MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-class: urn:content-classes:message Date: Thu, 10 Aug 2006 17:32:24 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] Loose-End MRM Direction Thread-Index: Aca7yBjOnK5AqqSNRumi6UNZpdyBGAAyOBtQAACDEtA= From: "Christian Dickmann" To: "Hancock, Robert" , "Roland Bless" X-Spam-Score: 0.1 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi, > see also > http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-ntlp-issues/issue115 Sounds good to me. Christian Dickmann _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Aug 11 15:18:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBcWx-0005UV-H1; Fri, 11 Aug 2006 15:18:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBcWw-0005UQ-Dm for nsis@ietf.org; Fri, 11 Aug 2006 15:18:50 -0400 Received: from difra-computer.de ([81.169.157.103] helo=www.difra-computer.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GBcWv-0008T6-5K for nsis@ietf.org; Fri, 11 Aug 2006 15:18:50 -0400 Received: from win2003.dickmann2003.home (p548A666C.dip.t-dialin.net [84.138.102.108]) by www.difra-computer.de (Postfix) with ESMTP id 3AEE53E4028 for ; Fri, 11 Aug 2006 21:15:53 +0200 (CEST) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: [NSIS] Last Call: 'GIST: General Internet Signaling Transport'toProposed Standard (draft-ietf-nsis-ntlp) Content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Date: Fri, 11 Aug 2006 21:06:37 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] Last Call: 'GIST: General Internet Signaling Transport'toProposed Standard (draft-ietf-nsis-ntlp) Thread-Index: Aca9ejUkdl4zvqbnR2WghJDZ2bJhZg== From: "Christian Dickmann" To: X-Spam-Score: 0.1 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Robert, I just noticed another small editorial issue: In section A.4.2., the "Object Value Info" text on=20 "Real Object Length" could be more clear. Is the length measured in words or bytes? I guess words, but the spec could say so. Christian Dickmann _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Aug 11 16:03:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBdET-0003hW-1f; Fri, 11 Aug 2006 16:03:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBdER-0003gv-TZ for nsis@ietf.org; Fri, 11 Aug 2006 16:03:47 -0400 Received: from natreg.rzone.de ([81.169.145.183]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GBdEQ-0003yx-H2 for nsis@ietf.org; Fri, 11 Aug 2006 16:03:47 -0400 Received: from [192.168.178.200] (p5484CA37.dip0.t-ipconnect.de [84.132.202.55]) (authenticated bits=0) by post.webmailer.de (8.13.6/8.13.6) with ESMTP id k7BK3glI020042 for ; Fri, 11 Aug 2006 22:03:43 +0200 (MEST) Message-ID: <44DCE1EF.8000203@cs.uni-goettingen.de> Date: Fri, 11 Aug 2006 22:00:47 +0200 From: Bernd Schloer User-Agent: Opera/8.51 (Windows NT 5.1; U; en) X-Accept-Language: en-us, en MIME-Version: 1.0 To: nsis@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Subject: [NSIS] CLS-QOSM - mapping of unsued mandatory parameters X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi, here's a new idea of what to do with mandatory parameters which are not used by CLS. The CLS-QOSM has a queueing mechanism with two priority levels: high priority for controlled-load(CL) and low priority for best-effort(BE) traffic. The queueing discipline used is the Token Bucket Filter (TBF) for CL and pfifo_fast for BE. The TBF limits the amount of traffic placed into the high priority queue. : defines the behaviour of the Traffic Conditioner for out-of-profile traffic 0: drop, some or all packets are discarded 1: shape, some or all packets are delayed 2: remark, reclassification to BE 3: no metering or policing, ... : can be mapped to Bucket Rate = Bandwidth Bucket Size = ? Peak Rate = ? Min Unit = ? MTU = ? The rest of the mandatory parameters contain somehow priority. This priority is used to distinguish between BE and CL to choose the correct queueing mechanism. : DSCP = 00000000 = default PHB = BE, other values = CL : Class 5 = BE, all others = CL : ?? what do the values 0..7 represent? : Is there a range for BE? : 0 = BE, 1 & 2 = CL : dsn.routine, drsn.routine, q735.4, ets.4, wps.4 = BE, other = CL What do you think of it? Bernd _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Aug 11 17:01:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBe89-0005Wt-9V; Fri, 11 Aug 2006 17:01:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBe88-0005Wo-6R for nsis@ietf.org; Fri, 11 Aug 2006 17:01:20 -0400 Received: from difra-computer.de ([81.169.157.103] helo=www.difra-computer.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GBe86-0002T0-Pi for nsis@ietf.org; Fri, 11 Aug 2006 17:01:20 -0400 Received: from win2003.dickmann2003.home (p548A666C.dip.t-dialin.net [84.138.102.108]) by www.difra-computer.de (Postfix) with ESMTP id 7CBAB3E4028 for ; Fri, 11 Aug 2006 22:58:22 +0200 (CEST) MIME-Version: 1.0 Subject: [NSIS] Last Call: 'GIST: General Internet SignalingTransport'toProposed Standard (draft-ietf-nsis-ntlp) Content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Date: Fri, 11 Aug 2006 22:49:19 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] Last Call: 'GIST: General Internet SignalingTransport'toProposed Standard (draft-ietf-nsis-ntlp) Thread-Index: Aca9iI35Rer1gWXtQMG7Xf/uosLIXA== From: "Christian Dickmann" To: X-Spam-Score: 0.1 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0894226868==" Errors-To: nsis-bounces@ietf.org This is a multi-part message in MIME format. --===============0894226868== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6BD87.9E33C310" Content-class: urn:content-classes:message This is a multi-part message in MIME format. ------_=_NextPart_001_01C6BD87.9E33C310 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Robert, =20 going through the various error conditions, I noticed, that there is no text on when the E-Flag is not allowed (I hope I did not miss it). As I understand the text about explicitly routed messages, only DATA messages can be sent using the E-flag, is this correct? If so, an error should be triggered if the message type is not DATA. Otherwise, could you please clarify the situation? =20 Christian Dickmann ------_=_NextPart_001_01C6BD87.9E33C310 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Robert,

 

going through the various error conditions, I = noticed, that there is no text on when the E-Flag is not allowed (I hope I did = not miss it).

As I understand the text about explicitly = routed messages, only DATA messages can be sent using the E-flag, is this = correct?

If so, an error should be triggered if the = message type is not DATA. Otherwise, could you please clarify the = situation?

 

Christian = Dickmann

------_=_NextPart_001_01C6BD87.9E33C310-- --===============0894226868== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis --===============0894226868==-- From nsis-bounces@ietf.org Sat Aug 12 04:51:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBpD6-0002QY-BR; Sat, 12 Aug 2006 04:51:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBpD5-0002PX-Ae for nsis@ietf.org; Sat, 12 Aug 2006 04:51:11 -0400 Received: from moutng.kundenserver.de ([212.227.126.186]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GBpD3-0001YR-VU for nsis@ietf.org; Sat, 12 Aug 2006 04:51:11 -0400 Received: from [84.163.45.126] (helo=alanis.mafr.de) by mrelayeu.kundenserver.de (node=mrelayeu6) with ESMTP (Nemesis), id 0ML29c-1GBpCz1l46-0002La; Sat, 12 Aug 2006 10:51:05 +0200 Received: by alanis.mafr.de (Postfix, from userid 1000) id 87D6E5E819E; Sat, 12 Aug 2006 10:50:50 +0200 (CEST) Date: Sat, 12 Aug 2006 10:50:50 +0200 From: Matthias Friedrich To: nsis@ietf.org Message-ID: <20060812085050.GA8057@mafr.de> Mail-Followup-To: nsis@ietf.org, stiemerling@netlab.nec.de MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.11 X-Provags-ID: kundenserver.de abuse@kundenserver.de login:b369618fd1a3462119ba5a921f6f235b X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: stiemerling@netlab.nec.de Subject: [NSIS] NATFW Proxy Mode X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi, I've got a question about the NATFW Proxy Mode (Section 3.7.7.1, "Proxying for a Data Sender"). It looks like case b) is incomplete: According to the spec, the NI+ may decide to "teardown the REA-PROXY sessions", but there is noting said how it should be done. I think the NI+ can't tear down the REA session because it would loose the reserved external address. Starting a new non-proxy REA session afterwards doesn't help because a different external address would be reserved. I'd suggest to add to the spec that the NI+ should keep the old REA session alive, but set the proxy bit in the REA messages to zero. The NF then tears down the CREATE session in the usual way, by sending CREATE(lifetime==0). What remains are two sessions: The old REA session and the CREATE session initiated by the DS. Cheers, Matthias _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Aug 14 15:50:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCiRs-0001WD-LU; Mon, 14 Aug 2006 15:50:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCiRm-0001VN-Mu; Mon, 14 Aug 2006 15:50:02 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GCiRm-0000B4-EN; Mon, 14 Aug 2006 15:50:02 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 6603D327BD; Mon, 14 Aug 2006 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GCiRm-0006R4-9F; Mon, 14 Aug 2006 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 14 Aug 2006 15:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: nsis@ietf.org Subject: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-11.txt X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org --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 : QoS NSLP QSPEC Template Author(s) : J. Ash, et al. Filename : draft-ietf-nsis-qspec-11.txt Pages : 62 Date : 2006-8-14 The QoS NSLP protocol is used to signal QoS reservations and is independent of a specific QoS model (QOSM) such as IntServ or DiffServ. Rather, all information specific to a QOSM is encapsulated in a separate object, the QSPEC. This document defines a template for the QSPEC, which contains both the QoS description and QSPEC control information. The QSPEC format is defined, as are a number of QSPEC parameters. The QSPEC-1 parameters provide a common language to be re-used in several QOSMs. QSPEC-2 parameters aim to ensure the extensibility of QoS NSLP to other QOSMs in the future. To a certain extent QSPEC parameters ensure interoperability of QOSMs. The node initiating the NSIS signaling adds an Initiator QSPEC that must not be removed, thereby ensuring the intention of the NSIS initiator is preserved along the signaling path. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nsis-qspec-11.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-qspec-11.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-qspec-11.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: <2006-8-14115504.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nsis-qspec-11.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nsis-qspec-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-8-14115504.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis --NextPart-- From nsis-bounces@ietf.org Mon Aug 14 16:28:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCj38-0003TW-6W; Mon, 14 Aug 2006 16:28:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCj36-0003TR-Mg for nsis@ietf.org; Mon, 14 Aug 2006 16:28:36 -0400 Received: from mail121.messagelabs.com ([216.82.241.195]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GCj34-0003Vz-Bl for nsis@ietf.org; Mon, 14 Aug 2006 16:28:36 -0400 X-VirusChecked: Checked X-Env-Sender: gash@att.com X-Msg-Ref: server-5.tower-121.messagelabs.com!1155587166!9921434!36 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 14821 invoked from network); 14 Aug 2006 20:28:33 -0000 Received: from unknown (HELO attrh3i.attrh.att.com) (134.24.146.4) by server-5.tower-121.messagelabs.com with SMTP; 14 Aug 2006 20:28:33 -0000 Received: from kcclust06evs1.ugd.att.com (135.38.164.88) by attrh3i.attrh.att.com (7.2.052) id 44C39E85002E5282 for nsis@ietf.org; Mon, 14 Aug 2006 16:28:33 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-11.txt Date: Mon, 14 Aug 2006 15:28:32 -0500 Message-ID: <9473683187ADC049A855ED2DA739ABCA0DDC7C1A@KCCLUST06EVS1.ugd.att.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-11.txt Thread-Index: Aca/2udObrHhY/NZTP2OAyPOnNRIrQAAT1Tg From: "Ash, Gerald R \(Jerry\), ALABS" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: "Ash, Gerald R \(Jerry\), ALABS" X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi All, The updated 'QoS NSLP QSPEC Template' I-D is available at http://www.ietf.org/internet-drafts/draft-ietf-nsis-qspec-11.txt. The updates are in response to a very large number of comments and discussion on the list since the last update (-10 version) in June. We have tried to incorporate all comments/agreements into the updated -11 version. =20 Given the large number of comments and extensive discussion, please check to be sure that the agreed-to changes/comments are properly incorporated. =20 The main changes are as follows: 1. 'QSPEC-1 parameter' replaces 'mandatory QSPEC parameter' 2. 'QSPEC-2 parameter' replaces 'optional QSPEC parameter' 3. R-flag ('remapped parameter flag') introduced to denote remapping, approximating, or otherwise not strictly interpreting a QSPEC parameter 3. T-flag ('tunneled parameter flag') eliminated and incorporated within the R-flag 4. Section 4 rewritten on QOSM concept, QSPEC processing, etc. to provide a more logical flow of information 5. read-write/read-only flag associated with QSPEC objects eliminated and object itself defined as rw or ro without a flag 6. parameter redefined as non-QOSM-hop Q-flag 7. Section 7 on QSPEC parameter definitions revised to clearly separate QSPEC-1 parameter coding from QSPEC-2 parameter coding 8. , , and QSPEC-1 parameters mapped to container parameters 9. references updated to include normative references defining procedures to 'strictly interpret' each QSPEC parameter 10. Section 7.2.1 on PHB class updated to specify additional RFC 3140 cases 11. Section 7.2.1 on excess treatment updated to specify excess treatment behaviors There are still 4 open issues currently identified based on the list discussion: 1. agreement/consensus on 4 QSPEC-1 (formerly called 'mandatory') parameters; see Section 7.2 2. agreement/consensus on what is allowed by remapping QSPEC parameters; see Section 4.3.1 3. agreement/consensus on whether to allow a QSPEC-1 parameter to be ignored; see Section 4.3.1 I will soon start a separate thread on each of the above issues so that we may reach final consensus. Please review the document and let us know of any further comments or suggestions. At this point comments/suggestions should be accompanied by suggested text changes, if any. Thanks, Regards, Jerry =20 -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]=20 Sent: Monday, August 14, 2006 3:50 PM To: i-d-announce@ietf.org Cc: nsis@ietf.org Subject: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-11.txt=20 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 : QoS NSLP QSPEC Template Author(s) : J. Ash, et al. Filename : draft-ietf-nsis-qspec-11.txt Pages : 62 Date : 2006-8-14 =09 The QoS NSLP protocol is used to signal QoS reservations and is independent of a specific QoS model (QOSM) such as IntServ or DiffServ. Rather, all information specific to a QOSM is encapsulated in a separate object, the QSPEC. This document defines a template for the QSPEC, which contains both the QoS description and QSPEC control information. The QSPEC format is defined, as are a number of QSPEC parameters. The QSPEC-1 parameters provide a common language to be re-used in several QOSMs. QSPEC-2 parameters aim to ensure the extensibility of QoS NSLP to other QOSMs in the future. To a certain extent QSPEC parameters ensure interoperability of QOSMs.=20 The node initiating the NSIS signaling adds an Initiator QSPEC that must not be removed, thereby ensuring the intention of the NSIS initiator is preserved along the signaling path. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nsis-qspec-11.txt _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Aug 14 17:45:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCkFb-0006O1-7V; Mon, 14 Aug 2006 17:45:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCkFa-0006LP-Lv for nsis@ietf.org; Mon, 14 Aug 2006 17:45:34 -0400 Received: from mail146.messagelabs.com ([216.82.245.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GCkFZ-00055B-E6 for nsis@ietf.org; Mon, 14 Aug 2006 17:45:34 -0400 X-VirusChecked: Checked X-Env-Sender: gash@att.com X-Msg-Ref: server-14.tower-146.messagelabs.com!1155591785!190321!42 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 12757 invoked from network); 14 Aug 2006 21:45:31 -0000 Received: from unknown (HELO attrh3i.attrh.att.com) (134.24.146.4) by server-14.tower-146.messagelabs.com with SMTP; 14 Aug 2006 21:45:31 -0000 Received: from kcclust06evs1.ugd.att.com (135.38.164.88) by attrh3i.attrh.att.com (7.2.052) id 44C39E85002E8A00 for nsis@ietf.org; Mon, 14 Aug 2006 17:45:31 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 14 Aug 2006 16:45:31 -0500 Message-ID: <9473683187ADC049A855ED2DA739ABCA0DDC7C1B@KCCLUST06EVS1.ugd.att.com> In-Reply-To: <9473683187ADC049A855ED2DA739ABCA0DDC7C1A@KCCLUST06EVS1.ugd.att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: QSPEC Issue #1 -- Number of QSPEC-1 (formerly called "mandatory") Parameters Thread-Index: Aca/2udObrHhY/NZTP2OAyPOnNRIrQAAT1TgAAE8mDA= From: "Ash, Gerald R \(Jerry\), ALABS" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: "Ash, Gerald R \(Jerry\), ALABS" Subject: [NSIS] QSPEC Issue #1 -- Number of QSPEC-1 (formerly called "mandatory") Parameters X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi All, One of the issues identified in the updated 'QoS NSLP QSPEC Template' I-D http://www.ietf.org/internet-drafts/draft-ietf-nsis-qspec-11.txt is as follows: 1. agreement/consensus on 4 QSPEC-1 (formerly called 'mandatory') parameters; see Section 7.2 There was extensive discussion on the list RE "Any resolution of QSPEC mandatory parameter list," which started at http://www1.ietf.org/mail-archive/web/nsis/current/msg06542.html. Various opinions were expressed as to a) whether the QSPEC-1 (mandatory) parameter concept was useful, and b) how many QSPEC-1 parameters there should be. Most opinions expressed on (a) supported the QSPEC-1 parameter concept as a means for a "common language" among different QOSMs and to enhance interoperability. Most opinions expressed on (b) did not oppose the 4 QSPEC parameters now included in the updated QSPEC draft: Parameter (Section 7.2.1) Parameter (Section 7.2.2) Parameter (Section 7.2.3) Parameter (Section 7.2.4) Note that the , , and parameters are "container" parameters. Please express any further comments in support of the proposed resolution, or otherwise, so that we may reach consensus on this issue. Thanks, Regards, Jerry _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Aug 14 17:45:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCkFp-0006Su-O6; Mon, 14 Aug 2006 17:45:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCkFp-0006Sj-4c for nsis@ietf.org; Mon, 14 Aug 2006 17:45:49 -0400 Received: from mail146.messagelabs.com ([216.82.245.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GCkFn-00055b-TO for nsis@ietf.org; Mon, 14 Aug 2006 17:45:49 -0400 X-VirusChecked: Checked X-Env-Sender: gash@att.com X-Msg-Ref: server-14.tower-146.messagelabs.com!1155591785!190321!45 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 12896 invoked from network); 14 Aug 2006 21:45:47 -0000 Received: from unknown (HELO attrh3i.attrh.att.com) (134.24.146.4) by server-14.tower-146.messagelabs.com with SMTP; 14 Aug 2006 21:45:47 -0000 Received: from kcclust06evs1.ugd.att.com (135.38.164.88) by attrh3i.attrh.att.com (7.2.052) id 44C39E85002E8A1A for nsis@ietf.org; Mon, 14 Aug 2006 17:45:47 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 14 Aug 2006 16:45:47 -0500 Message-ID: <9473683187ADC049A855ED2DA739ABCA0DDC7C1C@KCCLUST06EVS1.ugd.att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: QSPEC Issue #2 -- Remapping of QSPEC Parameters Thread-Index: Aca/6v+XZ64mWNrjQ2CGEB0yMcEbUA== From: "Ash, Gerald R \(Jerry\), ALABS" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: "Ash, Gerald R \(Jerry\), ALABS" Subject: [NSIS] QSPEC Issue #2 -- Remapping of QSPEC Parameters X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi All, One of the issues identified in the updated 'QoS NSLP QSPEC Template' I-D http://www.ietf.org/internet-drafts/draft-ietf-nsis-qspec-11.txt is as follows: 2. agreement/consensus on what is allowed by remapping QSPEC parameters; see Section 4.3.1 There was extensive discussion on the list RE remapping QSPEC parameters. Various examples of such remapping are given in Section 4.3.1. It is further required that procedures for any such remapping must be documented in a QOSM specification document, and any remapped parameter must be flagged with the "Remapped Parameter R-flag", as specified in the QSPEC draft. The common example used in the QSPEC I-D is remapping of a parameter to a parameter, which is straightforward. However, what should be allowed in the general case is unclear, such as whether to allow remapping between QSPEC parameter types, e.g., remapping to a . Indeed, the remapping concept may be a bit theoretical and some remappings would probably not make sense. A proposed resolution is to give a few examples of remapping, as currently included in Section 4.3.1, and specify the above requirements for the QOSM specification document and setting of the R-flag. It is further proposed in Section 4.3.1 that "We should have a separate document that defines typical remapping of QSPEC parameters, perhaps included in a QOSM definition document. This is to avoid misinterpretation of what is allowed by remapping QSPEC parameters." Please express any further comments in support of the proposed resolution, or otherwise, so that we may reach consensus on this issue. Thanks, Regards, Jerry _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Aug 14 17:46:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCkG9-0006WM-1O; Mon, 14 Aug 2006 17:46:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCkG7-0006WH-SX for nsis@ietf.org; Mon, 14 Aug 2006 17:46:07 -0400 Received: from mail120.messagelabs.com ([216.82.250.83]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GCkG6-00056T-Gu for nsis@ietf.org; Mon, 14 Aug 2006 17:46:07 -0400 X-VirusChecked: Checked X-Env-Sender: gash@att.com X-Msg-Ref: server-7.tower-120.messagelabs.com!1155591929!10128279!9 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 29107 invoked from network); 14 Aug 2006 21:46:03 -0000 Received: from unknown (HELO attrh3i.attrh.att.com) (134.24.146.4) by server-7.tower-120.messagelabs.com with SMTP; 14 Aug 2006 21:46:03 -0000 Received: from kcclust06evs1.ugd.att.com (135.38.164.88) by attrh3i.attrh.att.com (7.2.052) id 44C39E85002E8A49 for nsis@ietf.org; Mon, 14 Aug 2006 17:46:03 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 14 Aug 2006 16:46:03 -0500 Message-ID: <9473683187ADC049A855ED2DA739ABCA0DDC7C1D@KCCLUST06EVS1.ugd.att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: QSPEC Issue #3 -- Allowing a QSPEC-1 Parameter to be Ignored Thread-Index: Aca/6wl1mien3kJ5R0u2kXlkJtiCmA== From: "Ash, Gerald R \(Jerry\), ALABS" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: "Ash, Gerald R \(Jerry\), ALABS" Subject: [NSIS] QSPEC Issue #3 -- Allowing a QSPEC-1 Parameter to be Ignored X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi All, One of the issues identified in the updated 'QoS NSLP QSPEC Template' I-D http://www.ietf.org/internet-drafts/draft-ietf-nsis-qspec-11.txt is as follows: 3. agreement/consensus on whether to allow a QSPEC-1 (formerly called "mandatory") parameter to be ignored; see Section 4.3.1 There was extensive discussion on the list RE whether to allow a QSPEC-1 parameter to be ignored, as is allowed for a QSPEC-2 (formerly called "optional") parameter. Reasons given for allowing this are a) use of a QSPEC-1 parameter might be illegal, as with preemption in the U.S. PSTN, and b) a particular QOSM might not want to support certain QSPEC-1 parameters, i.e., while it would be nice for all QOSMs to support , some have suggested that might not be practical/realistic. Note that this issue is related to Issue #1, that is, if we retain the QSPEC-1 parameter concept, then allowing a QSPEC-1 parameter to be ignored is a step toward doing away with the distinction between QSPEC-1 and QSPEC-2 parameters. It is also related to Issue #2 in that an alternative to "strict interpretation" of QSPEC-1 parameters is remapping these parameters. However, in some cases remapping QSPEC-1 parameters between classes of QSPEC parameters may not make sense, e.g., mapping to . =20 The default resolution is that the QSPEC-1 concept is retained and that all QSPEC-1 parameters must be strictly interpreted or remapped by all QOSMs. Alternatively, it is suggested in Section 4.3.1 that if ignoring a QSPEC-1 parameter is to be allowed, that a high threshold be placed on justification for this in the QOSM specification document: "a QOSM may simply not want to support a QSPEC-1 parameter. In (that) case justification may be more difficult, however there is a filter on reasonableness in that QOSM specifications must be reviewed and approved by the IETF." Please express any further comments in support of the proposed resolution, or otherwise, so that we may reach consensus on this issue. Thanks, Regards, Jerry _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Aug 16 04:56:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDHBl-0006BA-0H; Wed, 16 Aug 2006 04:55:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDHBj-00069s-Va for nsis@ietf.org; Wed, 16 Aug 2006 04:55:47 -0400 Received: from difra-computer.de ([81.169.157.103] helo=www.difra-computer.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDHBi-000850-Ii for nsis@ietf.org; Wed, 16 Aug 2006 04:55:47 -0400 Received: from win2003.dickmann2003.home (p548A7ED8.dip.t-dialin.net [84.138.126.216]) by www.difra-computer.de (Postfix) with ESMTP id 59FF43E4029 for ; Wed, 16 Aug 2006 10:52:01 +0200 (CEST) Received: from localhost ([192.168.0.5]) by win2003.dickmann2003.home with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 Aug 2006 10:45:51 +0200 MIME-Version: 1.0 Date: Wed, 16 Aug 2006 10:54:38 +0200 From: Christian Dickmann To: nsis@ietf.org Subject: RE: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-11.txt Message-ID: <05927d47cdd34c3d65f063505424527d@192.168.0.7> X-Sender: mail@christian-dickmann.de User-Agent: RoundCube Webmail/0.1b Content-Type: text/plain; charset="UTF-8" X-OriginalArrivalTime: 16 Aug 2006 08:45:51.0171 (UTC) FILETIME=[60A52130:01C6C110] Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.1 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi, I just had a brief look at the new version of the QSPEC template draft (version 11). I did not make a real review and I also did not look into any protocol operation issues, but just had a look at the new=20 QSPEC-1 parameters.=20 I found several issues that make it hard to read, understand or implement the specification.=20 My comments are: - 7.2.2 Traffic Parameter: Make that two objects, that can be distinguish= ed based on the ID! Interpretation based on the length is a mess. It makes the life of implementors much easier, if you can directly judge from th= e ID. - 7.2.2 Traffic Paramater: " =3D ", = but "The above notation means that either or sub-parameters can be populated in the parameter." Please use a notation, that stands for itself. To me, this notation mea= ns: The traffic parameter is built by bandwidth AND token bucket-1. My sugg= estion: =3D [] [] and say, that one and only one of them MUST be present. - 7.2.2.1 Bandwidth Sub-Parameter: " can be represented using single-precision IEEE floating point." This is a=20 specification, right? So please say how it actually IS represented. - 7.2.4 Parameter: "+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Preemption Priority | Defending Priority | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Admission | RPH Namespace | RPH Priority | + Priority | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Priority Parameters(Reserved) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+" Do you really mean, that Admission priority spans two rows (meaning two 32-bit words? If not, please use an abbreviated form of Admission Priority, like "Admission Prio.". - Several of the issues above apply to more than just the referenced section, for example the issue regarding notation. Regards, Christian Dickmann _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Aug 16 09:32:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDLUR-0003tM-Jw; Wed, 16 Aug 2006 09:31:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDLUQ-0003tG-9H for nsis@ietf.org; Wed, 16 Aug 2006 09:31:22 -0400 Received: from difra-computer.de ([81.169.157.103] helo=www.difra-computer.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDLUN-0001Z2-Pj for nsis@ietf.org; Wed, 16 Aug 2006 09:31:22 -0400 Received: from win2003.dickmann2003.home (p548A53F4.dip.t-dialin.net [84.138.83.244]) by www.difra-computer.de (Postfix) with ESMTP id 15CF73E4029 for ; Wed, 16 Aug 2006 15:27:33 +0200 (CEST) Received: from localhost ([192.168.0.5]) by win2003.dickmann2003.home with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 Aug 2006 15:19:50 +0200 MIME-Version: 1.0 Date: Wed, 16 Aug 2006 15:28:36 +0200 From: Christian Dickmann To: nsis@ietf.org Message-ID: <3a5b10a19e5a377cc69a9714e94fd5ff@192.168.0.7> X-Sender: mail@christian-dickmann.de User-Agent: RoundCube Webmail/0.1b Content-Type: text/plain; charset="UTF-8" X-OriginalArrivalTime: 16 Aug 2006 13:19:50.0450 (UTC) FILETIME=[A7380920:01C6C136] Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.1 (/) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 Subject: [NSIS] QoS NSLP comments X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi, I did a brief review of the QoS NSLP and came up with some issues. None of them is really severe. Issue 1) Section 3.3 "GIST Interactions": "When GIST passes the QoS NSLP data to the NSLP for processing, it must also indicate the value of the 'D' (Direction) flag for that message. This is done in the Direction attribute of the SendMessage and RecvMessage primitives." Most likely this is outdated. There is no Direction attribute in the primitives, but the direction is indicated through the D-Flag in the MRI. Issue 2) Section 5.1 "QoS NSLP Message and Object Formats": "An implementation should create messages with the objects in the order shown here, but accept the objects in any order." Maybe this should be changed to something like: "An implementation SHOULD create message with the objects in the order shown here, but MUST accept the objects in any order" At least, it should be really clear, what an implementation is allowed to do and which aspects are mandatory. Issue 3) Section 5.1.1 "Common header": Why is this header a COMMON header, if there is a field in there, which is message specific? And in addition, why are the generic fields not really generic, but get their meaning based on the actual message type? This does not seem to be very reasonable to me. First, the common header is not common and then the generic flags are not generic.=20 Generic fields should have a generic meaning, which is defined once for all message types. Of course, some messages might have certain flags set to 0 or 1 every time, but again, this should not change the meaning of th= e flag. I suggest to change all flags to real generic ones, like it is done in GIST for example. Then the generic flags are generic and the header is=20 common. Issue 4) Section 5.1.2: Various time you state "There are no requirement on transmission order, although the above order is recommended." However, you already said so in the beginning of section 5.1=20 (see Issue 2). So to my mind, you do not have to repeat it for=20 every message.=20 Issue 5) Section 5.1.2.1: "RESERVE" "[ [ PACKET_CLASSIFIER ] [ QSPEC ] [ QSPEC ] ]". The outer brackets are unnecessary and should be removed. In addition see Issue 6. Issue 6) Section 5.1.2: In the RESPONSE message, you use the notation "[ QSPEC [ QSPEC ] ]", while you use "[ QSPEC ] [ QSPEC ]" in NOTIFY and RESERVE. I suggest to one use one version, namely the first one. Issue 7) Section 5.1.3.6: "INFO_SPEC": You should move the error codes their own section, that can be found in the table of contents. This would help to quickly lookup some error.=20 Issue 8) Section 5.2.1: "State manipulation": "The state information for a given key includes: Flow ID" Maybe calling it MRI (maybe in brackets) helps to map the different names= , especially if you talk about GIST identifiers here in the section. (I know, that you define it in the terminology, but it might help here) Issue 9) Section 5.2.4: "Retransmissions": "In the latter case, a failure SHOULD be indicated to the signaling application." I am not sure, if it is 100% clear here, which entity the "signaling appl= ication" is. For example in section 3.2.10.1 you write "GIST will also notify the signaling application that no downstream GIST nodes supporting the QoS NSLP are present." Here, the signaling application seems to be the QoS NSLP itself, since GIST will only communicate with the NSLPs. Issue 10) Section 6 "IANA Considerations": One the one hand you say, that you contribute your object types to the co= mmon NSLP object type registrym, but you also claim to create a NEW registry=20 called "QoS NSLP Object Types". The same for the NSLP ID. From my underst= anding (I am absolutely no IANA expert) GIST opens the registry and the NSLP onl= y=20 contributes a a new entry instead of opeing of a new registry. Issue 11) Section 5.1.3 "Object Formats": I am not sure, if the semantics of AB=3D11 are really wise. One the one h= and, I=20 am not exactly sure, why you would want such a behavior. On the other han= d, I am absolutely not sure, if there aren't any security implications. By pla= cing the AB=3D11 flag, you can trick any node to send an opaque object with ev= ery message it sends for that session.=20 Issue 12) Small editorial stuff in Intoduction:=20 "Section then clarifies the protocol by means of a number of=20 examples in Section 4." is broken. "The subsequent sections describe AINA allocation issues, and=20 security considerations." You mean IANA? Issue 13) Section 3.3: Again, editorial: "Currently, the QoS NSLP specification considers mainly the coupled MRM." There is an "path-" missing. Regards, Christian Dickmann _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Aug 17 04:43:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDdSz-0001go-H9; Thu, 17 Aug 2006 04:43:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDdSy-0001gi-4R for nsis@ietf.org; Thu, 17 Aug 2006 04:43:04 -0400 Received: from rsys002x.roke.co.uk ([193.118.201.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDdSw-0004bB-LG for nsis@ietf.org; Thu, 17 Aug 2006 04:43:04 -0400 Received: from rsys005a.comm.ad.roke.co.uk (rsys005a [193.118.193.85]) by rsys002x.roke.co.uk (8.13.1/8.13.1) with ESMTP id k7H8gZdD031753; Thu, 17 Aug 2006 09:42:39 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [NSIS] Last Call: 'GIST: General InternetSignalingTransport'toProposed Standard (draft-ietf-nsis-ntlp) Date: Thu, 17 Aug 2006 09:42:35 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] Last Call: 'GIST: General InternetSignalingTransport'toProposed Standard (draft-ietf-nsis-ntlp) Thread-Index: AcbB2RyLhvcMiw+oS0eatLj1pIdFHg== From: "Hancock, Robert" To: "Christian Dickmann" , X-MailScanner-roke-co-uk: Found to be clean X-MailScanner-roke-co-uk-SpamCheck: X-MailScanner-From: robert.hancock@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 225414c974e0d6437992164e91287a51 Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0657973660==" Errors-To: nsis-bounces@ietf.org This is a multi-part message in MIME format. --===============0657973660== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6C1D9.163AA3C5" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6C1D9.163AA3C5 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable hi christian, =20 i think this is right; it certainly doesn't make sense to set E except in a Data message. we can add a new subcode to the common header parse error message for this. =20 cheers, =20 robert h. -----Original Message----- From: Christian Dickmann [mailto:mail@christian-dickmann.de]=20 Sent: 11 August 2006 21:49 To: nsis@ietf.org Subject: [NSIS] Last Call: 'GIST: General InternetSignalingTransport'toProposed Standard (draft-ietf-nsis-ntlp) =09 =09 Hi Robert, =20 going through the various error conditions, I noticed, that there is no text on when the E-Flag is not allowed (I hope I did not miss it). As I understand the text about explicitly routed messages, only DATA messages can be sent using the E-flag, is this correct? If so, an error should be triggered if the message type is not DATA. Otherwise, could you please clarify the situation? =20 Christian Dickmann ------_=_NextPart_001_01C6C1D9.163AA3C5 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
hi=20 christian,
 
i=20 think this is right; it certainly doesn't make sense to set E except in = a Data=20 message. we can add a new subcode to the common header parse error = message for=20 this.
 
cheers,
 
robert=20 h.
-----Original Message-----
From: = Christian=20 Dickmann [mailto:mail@christian-dickmann.de]
Sent: 11 = August 2006=20 21:49
To: nsis@ietf.org
Subject: [NSIS] Last Call: = 'GIST:=20 General InternetSignalingTransport'toProposed Standard=20 (draft-ietf-nsis-ntlp)

Hi=20 Robert,

 

going through the = various error=20 conditions, I noticed, that there is no text on when the E-Flag is not = allowed=20 (I hope I did not miss it).

As I understand the text = about=20 explicitly routed messages, only DATA messages can be sent using the = E-flag,=20 is this correct?

If so, an error should = be=20 triggered if the message type is not DATA. Otherwise, could you please = clarify=20 the situation?

 

Christian=20 Dickmann

------_=_NextPart_001_01C6C1D9.163AA3C5-- --===============0657973660== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis --===============0657973660==-- From nsis-bounces@ietf.org Thu Aug 17 05:01:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDdkP-00006V-VO; Thu, 17 Aug 2006 05:01:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDdkP-00006Q-2D for nsis@ietf.org; Thu, 17 Aug 2006 05:01:05 -0400 Received: from rsys002x.roke.co.uk ([193.118.201.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDdkN-0008JJ-6h for nsis@ietf.org; Thu, 17 Aug 2006 05:01:05 -0400 Received: from rsys005a.comm.ad.roke.co.uk (rsys005a [193.118.193.85]) by rsys002x.roke.co.uk (8.13.1/8.13.1) with ESMTP id k7H90t41002660; Thu, 17 Aug 2006 10:00:55 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] Last Call: 'GIST: General Internet SignalingTransport'toProposed Standard (draft-ietf-nsis-ntlp) Date: Thu, 17 Aug 2006 10:00:55 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] Last Call: 'GIST: General Internet SignalingTransport'toProposed Standard (draft-ietf-nsis-ntlp) Thread-Index: Aca9ejUkdl4zvqbnR2WghJDZ2bJhZgEYU9oA From: "Hancock, Robert" To: "Christian Dickmann" , X-MailScanner-roke-co-uk: Found to be clean X-MailScanner-roke-co-uk-SpamCheck: X-MailScanner-From: robert.hancock@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org hi, yes, it should be words (also 'calculated length' in the same section). i will go through section A and check all uses of the word "[Ll]ength" (no pun intended ...). cheers, robert h. > -----Original Message----- > From: Christian Dickmann [mailto:mail@christian-dickmann.de]=20 > Sent: 11 August 2006 20:07 > To: nsis@ietf.org > Subject: [NSIS] Last Call: 'GIST: General Internet=20 > SignalingTransport'toProposed Standard (draft-ietf-nsis-ntlp) >=20 >=20 > Hi Robert, >=20 > I just noticed another small editorial issue: > In section A.4.2., the "Object Value Info" text on=20 > "Real Object Length" could be more clear. > Is the length measured in words or bytes? > I guess words, but the spec could say so. >=20 > Christian Dickmann >=20 >=20 > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Aug 17 10:18:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDigl-00083D-94; Thu, 17 Aug 2006 10:17:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDigj-000831-Lq for nsis@ietf.org; Thu, 17 Aug 2006 10:17:37 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDhxK-0000qc-Ql for nsis@ietf.org; Thu, 17 Aug 2006 09:30:42 -0400 Received: from rsys002x.roke.co.uk ([193.118.201.109]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GDhaA-0005YU-W7 for nsis@ietf.org; Thu, 17 Aug 2006 09:06:49 -0400 Received: from rsys005a.comm.ad.roke.co.uk (rsys005a [193.118.193.85]) by rsys002x.roke.co.uk (8.13.1/8.13.1) with ESMTP id k7HD6Nmb015250; Thu, 17 Aug 2006 14:06:23 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] Last Call: 'GIST: General Internet Signaling Transport'to Proposed Standard (draft-ietf-nsis-ntlp) Date: Thu, 17 Aug 2006 14:06:23 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] Last Call: 'GIST: General Internet Signaling Transport'to Proposed Standard (draft-ietf-nsis-ntlp) Thread-Index: Aca8W5PPF9UAlEBBTxiXyWt4KvAFSgFoM1Mw From: "Hancock, Robert" To: "Christian Dickmann" , X-MailScanner-roke-co-uk: Found to be clean X-MailScanner-roke-co-uk-SpamCheck: X-MailScanner-From: robert.hancock@roke.co.uk X-Spam-Score: -2.6 (--) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org hi christian, please see inline. > -----Original Message----- > From: Christian Dickmann [mailto:mail@christian-dickmann.de]=20 > Sent: 10 August 2006 09:58 > To: nsis@ietf.org > Cc: Hancock, Robert > Subject: Re: [NSIS] Last Call: 'GIST: General Internet=20 > Signaling Transport'to Proposed Standard (draft-ietf-nsis-ntlp) >=20 >=20 > Hi, >=20 > I did a brief review of the GIST draft and here are my comments: >=20 > Issue 1) In Figure 11 of Appendix C the GIST Confirm has no Stack- > Configuration-Data object included. However, section 5.1=20 > says: "The first > message on an association MUST also repeat the Stack-Configuration- > Data from the original Query in an abbreviated form, just=20 > containing > the MA-Hold-Time." > As the example in Figure 11 builds a new MA, the SCD should=20 > be contained > in the Confirm. In addition, the MA-Hold-Time is not listed=20 > in the Query-SCD in > Figure 11. It would make sense to include it, to show the=20 > difference between > the full and abbreviated form of the SCD. fair enough, this can be added to the example (as you suggest). =20 >=20 > Issue 2) Section 5.3.2 defines that a Q-mode encapsulated=20 > message has to contain > a RAO. In contrast, a lot of other encapsulation details are=20 > part of the definition > of the Message-Routing-Method, e.g. section 5.8.1.2 for=20 > downstream Q-mode encapsulation > for path-coupled MRM. Moving the RAO decision to the MRM=20 > definition seems reasonable > to me, as that would allow a wider range of MRMs, but not=20 > change the semantics of the > current specification. >=20 > For example, one could define a MRM which build the=20 > interception of messages on=20 > a specific port number. Such a MRM should NOT contain a RAO.=20 > But such a MRM would > currently require changing the GIST specification instead of=20 > just defining a MRM. i think this is a reasonable suggestion. we can modify the text to place the responsibility for deciding to use the RAO in the MRM definition, rather than making it instrinsic to Q-mode encapsulation, and point at the extensibility document for more details. (note that in the example you give, I would still say an RAO is appropriate; if interception is based solely on port=20 number, then routers have to inspect all packets up to the=20 transport layer, which is what we are trying to avoid.) further discussion about this at=20 http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-ntlp-issues/issue112 =20 >=20 > Issue 3) In section 5.2.1 "The Common Header" the GIST draft=20 > defines, that the current > GIST version number is 1. However, this is not listed in the=20 > IANA Considerations. As far > as I can see, the IANA Considerations do not even cover how=20 > future versions of GIST=20 > can be defined. I am not sure, but shouldn't this be covered? i don't think so - IANA doesn't allocate the version numbers. (basically, i think the idea is that if you want IANA to provide a codepoint management service you have to tell them exactly how to; but if you don't, you don't tell them anything. anything not explicitly delegated to IANA remains the responsibility of the IETF.) >=20 >=20 > Issue 4) In Section 5.1 DATA messages are defined without the=20 > possibility to add=20 > a NAT-Traversal-Object (NTO). While this is reasonable for=20 > normal D-Mode or C-Mode=20 > DATA messages, I think Q-mode encapsulated DATA messages=20 > (those DATA messages, which > are used in the stateless GIST operation) should be=20 > translated in NATs and a=20 > NTO should be added.=20 yep, right. actually, the text in 7.2 is already written this=20 way. but then someone [ ;-) ] asked to include the NTO in=20 the section 5.xx ABNF/text and i didn't do so consistently. >=20 >=20 > Issue 5) I am still confused by the D-Flag of the=20 > Loose-End-MRM (see other mail > on the mailing list). Some additional thoughts: Section=20 > A.3.1.2 "Loose-End MRM" defines: > "D flag: The direction flag. The only valid value is D=3D0=20 > (see Section 5.8.2)." > So what does section 5.8.2 say? It says, that only downstream=20 > Q-mode encapsulation > is defined for LE-MRM (and NOT upstream Q-mode encapsulation=20 > like in the PC-MRM case). > However, this only refers to Q-mode encapsulation and not to=20 > the normal D-Mode one, > right? Thus, I do not need an upstream Q-mode encapsulation=20 > to send a D-Mode message > upstream (like a RESPONSE). Therefore, I have no clue, why=20 > section 5.8.2 should > tell me, that the only possible value of the direction flag=20 > in LE-MRM is 0. see the separate answer on this. cheers, robert h. >=20 >=20 > Regards, > Christian Dickmann >=20 >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Sat Aug 19 08:33:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GEQ0L-0006m4-MZ; Sat, 19 Aug 2006 08:32:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GEQ0K-0006lz-8P for nsis@ietf.org; Sat, 19 Aug 2006 08:32:44 -0400 Received: from rsys002x.roke.co.uk ([193.118.201.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GEQ0F-0001vO-O6 for nsis@ietf.org; Sat, 19 Aug 2006 08:32:44 -0400 Received: from rsys005a.comm.ad.roke.co.uk (rsys005a [193.118.193.85]) by rsys002x.roke.co.uk (8.13.1/8.13.1) with ESMTP id k7JCWMve025257 for ; Sat, 19 Aug 2006 13:32:28 +0100 Received: from [193.118.197.193] ([193.118.197.193]) by rsys005a.comm.ad.roke.co.uk with Microsoft SMTPSVC(6.0.3790.1830); Sat, 19 Aug 2006 13:32:22 +0100 Message-ID: <44E704D6.7090507@roke.co.uk> Date: Sat, 19 Aug 2006 13:32:22 +0100 From: Andrew McDonald User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: NSIS Mailing List Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Aug 2006 12:32:22.0923 (UTC) FILETIME=[853325B0:01C6C38B] X-MailScanner-roke-co-uk: Found to be clean X-MailScanner-roke-co-uk-SpamCheck: X-MailScanner-From: andrew.mcdonald@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c Subject: [NSIS] SCTP for GIST draft comments X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi all, This draft is a good start at defining the use of SCTP as an MA protocol for GIST. I have, however, got a number of comments and questions. General: I understand that the document is meant to be about using SCTP with or without the partial reliability (PR-SCTP) extension. However, some parts seemed to assume that PR-SCTP was used and some bits assumed that plain SCTP was used (e.g. TLS discussion). Some clarification is probably needed. In the abstract and/or introduction I had expected to see the GIST term 'messaging association', but it instead talks only about 'connection mode operation'. The introduction makes a couple of claims, which I didn't see backed up in the document, e.g. "the GIST transport protocol must accommodate flexible retransmission" (must, even if not capitalised, seems strong - is the 'must' part of an argument that there is something wrong with the base spec? - I don't think that is the intended meaning), "a number of functions that are desirable for signaling transport, such as multiple streams and multiple IP addresses". I assume some of this will be covered by the 'appplicability statement' mentioned in the slides from Montreal. The introduction says that this document covers: 1) how to use the multiple streams feature of SCTP. 2) how to handle the message oriented nature of SCTP. 3) how to take the advantage of multi-homing support of SCTP. Is (2) simply covered by the statement that SCTP fragmentation needs to be supported? (does that need to be a MUST?) Or, is it expected that some further text will be added on this topic? I assume that (1) and (2) are still 'TBD' for a future version of this draft. SCTP Parameters: As well as the SCTP port number, the MA-Protocol-Options also negotiates an Initial RTO value and a Maximum RTO value. It is not clear to me why this is done, or even necessary. Similar options aren't negotiated in the MA-Protocol-Options for TCP. It is also not clear that SCTP intends these to be negotiated options. If they were meant to be negotiated, why aren't they part of the SCTP handshake? The SCTP API draft (draft-ietf-tsvwg-sctpsocket-13.txt) does allow these parameters to be set on a per-association basis, but this doesn't mean that GIST needs to get involved in negotiating them. It might also be useful to more closely follow the format used for the definitions of Forwards-TCP and TLS in the GIST draft, e.g. > o in a Query: no information apart from the field header. > > o in a Response: 2 byte port number at which the connection will be > accepted, followed by 2 pad bytes. Also some discussion probably needs to be given about transfer attributes (c.f. the Reliable=True discussion for TCP). Multi-streaming: A constraint currently not mentioned, is that all messages for a particular Session ID need to be sent down the same SCTP stream. This is necessary in order to retain the NSLP assumption of in-order delivery (GIST section 3.5). SCTP defines unidirectional streams (e.g. there can be a different number of streams from A to B than from B to A). The TLS over SCTP defines the concept of a bidirectional stream (the pair of streams between A and B with the same stream number in both directions). Should GIST be looking to use streams in a similar bidirectional way, or can we be more flexible than that? Would I be right to assume that multiple sessions will be mapped on to a single stream? Is there any further guidance we might want to give in that regard? Is there any further guidance we need to give on Messaging Assocation reuse? Multi-homing: It is not clear that to me multi-homing is an SCTP feature we would want to use for GIST. Opening an SCTP association with multiple endpoint addresses doesn't appear to be an obvious thing to do with GIST. The use of the Add-IP extension might conceivably be something that could be considered as part of MA reuse. However, I'm not clear why you'd want to use this. TLS usage with SCTP: TLS is used per-stream with SCTP. This means that a TLS handshake (or abbreviated handshake using session resumption) needs to be performed on each bidirectional stream. Would we want to mix TLS and non-TLS streams in a single SCTP assocation when using it with GIST? DTLS usage with PR-SCTP: TLS, obviously, won't work with partially reliable streams since it expects a reliable transport (and has some other limitations too). There is a draft on DTLS usage with PR-SCTP that was presented in the TLS working group meeting in Montreal (draft-tuexen-dtls-for-sctp-00.txt, presentation at http://www3.ietf.org/proceedings/06jul/slides/tls-5.pdf). It is not as trivial as it might sound since it also requires the use of SCTP-AUTH (to avoid spoofed acks which indicate data has been delivered when it hasn't). There is still an open issue of how to establish the shared secret SCTP-AUTH using DTLS. Once DTLS over SCTP is defined, there might be an argument that this should be used as the way to do TLS over both PR-SCTP and plain SCTP (since it will work in both reliable and partial reliable cases). IANA Considerations: Do we also need to be allocated an SCTP Payload Protocol Identifier? (Might particularly need if mixing TLS and non-TLS traffic?) References: Should [5] (PR-SCTP) and [7] (TLS over SCTP) be normative rather than informative? I hope those comments help. best regards, Andrew _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Aug 21 09:28:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GF9oM-0005y5-Bz; Mon, 21 Aug 2006 09:27:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GF9oL-0005xu-1t for nsis@ietf.org; Mon, 21 Aug 2006 09:27:25 -0400 Received: from iramx1.ira.uni-karlsruhe.de ([141.3.10.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GF9oJ-0004E9-OQ for nsis@ietf.org; Mon, 21 Aug 2006 09:27:25 -0400 Received: from i72ms2.tm.uni-karlsruhe.de ([141.3.70.17] helo=smtp.ipv6.tm.uni-karlsruhe.de) by iramx1.ira.uni-karlsruhe.de with esmtps id 1GF9o9-0003vL-3T; Mon, 21 Aug 2006 15:27:22 +0200 Received: from vorta.ipv6.tm.uni-karlsruhe.de (vorta.ipv6.tm.uni-karlsruhe.de [IPv6:2001:638:204:6:207:e9ff:fe0c:5e44]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id C8B31BFBA; Mon, 21 Aug 2006 15:27:12 +0200 (CEST) Received: from localhost ([127.0.0.1]) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.44) id 1GF9o8-0003dR-Hq; Mon, 21 Aug 2006 15:27:12 +0200 Message-ID: <44E9B4B0.4070402@tm.uka.de> Date: Mon, 21 Aug 2006 15:27:12 +0200 From: Roland Bless Organization: Institute of Telematics, University of Karlsruhe User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060111 Thunderbird/1.5 Mnenhy/0.7.3.0 MIME-Version: 1.0 To: "Hancock, Robert" Subject: Re: [NSIS] Loose-End MRM Direction References: In-Reply-To: X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: -4.2 (----) X-Spam-Status: No X-Spam-Report: -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] 0.2 AWL AWL: From: address is in the auto white-list X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: "nsis@ietf.org" X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Robert, [sorry for the delay, I was on a short vacation] > there is no mystery here, it is just my screwup. Magnus' > review highlighted the earlier text as being unclear and > I tried to make it clearer; what I missed was that the > earlier text was wrong and I just made it clearly wrong. > The intent that *for Query encapsulated messages* only D=0 > is allowed. I'll add that in the next version. > > see also > http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-ntlp-issues/issue115 D flag: The direction flag. Note that for Q-mode messages, the only valid value is D=0 (see Section 5.8.2). This actually makes more sense. So it's ok to invert the flag in the RESPONSE. On the other hand it's somehow still confusing: if one takes the original definition of upstream/downstream signaling into account, it would be *upstream* not downstream. At least if one follows the definitions and scenarios in the NAT/FW draft, because the GIST node that sends a query message containing the LE MRM is actually the data receiver. Thus, the signaling direction is upstream in this case?! Regards, Roland _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Aug 22 05:21:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFSRQ-0007QK-0b; Tue, 22 Aug 2006 05:21:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFSRO-0007QC-QA for nsis@ietf.org; Tue, 22 Aug 2006 05:20:58 -0400 Received: from py-out-1112.google.com ([64.233.166.177]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFSRN-0005My-Il for nsis@ietf.org; Tue, 22 Aug 2006 05:20:58 -0400 Received: by py-out-1112.google.com with SMTP id z59so1542417pyg for ; Tue, 22 Aug 2006 02:20:57 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:mime-version:content-type:x-google-sender-auth; b=qcM3RWrjXcd+A4HT7aoPAMSaTKUtgrOfbtAOCTu7HaixITbTJaiOYrIJDK/qll8Qd+KC8QrPA3pp4CVrG5pIMDCGuNxOoXMvXlVNLCTPBnVusAlY0BdwwV0atxHkRrk8kf3Fqq4DHk/cXicRW1/ERp8t8BHJtXVV2jFW0M/uqs8= Received: by 10.35.37.18 with SMTP id p18mr15145242pyj; Tue, 22 Aug 2006 02:20:57 -0700 (PDT) Received: by 10.35.31.16 with HTTP; Tue, 22 Aug 2006 02:20:57 -0700 (PDT) Message-ID: <951128250608220220o656558a8n7c58c7baefb289bf@mail.gmail.com> Date: Tue, 22 Aug 2006 09:20:57 +0000 From: "=?ISO-8859-1?Q?Rui_Vil=E3o?=" To: nsis@ietf.org MIME-Version: 1.0 X-Google-Sender-Auth: e35aeffde57a1911 X-Spam-Score: 0.2 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Subject: [NSIS] Session Lifetime processing question [Section 3.4] X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0384866444==" Errors-To: nsis-bounces@ietf.org --===============0384866444== Content-Type: multipart/alternative; boundary="----=_Part_91634_1243664.1156238457147" ------=_Part_91634_1243664.1156238457147 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline I'm from University of Coimbra and I'm currently implementing NATFW version 12. When processing the session lifetime object in a NF upstream node, after a successful response from the NR, as described in section 3.4, one of three things can happen: - everything is OK, the response message continues to be forward; - session lifetime is greater than the stored value, generates an error response message; - session lifetime is smaller than the acceptable value for the node, generates an error response message. What to do when generating such an error response message? Is the default action of the response message to continue upstream with the proper error code? In this case what happens to the entities already signalled? Is the request deleted due to the soft-states or should we send = a specific notify message towards the NR? Best regards, Rui Vil=E3o ------=_Part_91634_1243664.1156238457147 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline I'm from University of Coimbra and I'm currently implementing NATFW version= 12.

When processing the session lifetime object in a NF upstream = node, after a successful response from the NR, as described in section 3.4 , one of three things can happen:

- everything is OK, the response= message continues to be forward;
- session lifetime is greater than th= e stored value, generates an error response message;
- session lifetime= is smaller than the acceptable value for the node, generates an error resp= onse message.=20

What to do when generating such an error response message?
Is the default action of the response message to continue upstream with t= he proper error code? In this case what happens to the entities already sig= nalled? Is the request deleted due to the soft-states or should we send a s= pecific notify message towards the NR?  


Best regards,

Rui Vil=E3o  =20 ------=_Part_91634_1243664.1156238457147-- --===============0384866444== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis --===============0384866444==-- From nsis-bounces@ietf.org Fri Aug 25 05:41:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGYBP-00086F-0E; Fri, 25 Aug 2006 05:40:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGYBN-0007ze-K3 for nsis@ietf.org; Fri, 25 Aug 2006 05:40:57 -0400 Received: from denhaag.ewi.utwente.nl ([130.89.10.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGYBM-0008JX-6A for nsis@ietf.org; Fri, 25 Aug 2006 05:40:57 -0400 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by denhaag.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id k7P9eeUs020027; Fri, 25 Aug 2006 11:40:49 +0200 (MEST) From: "Georgios Karagiannis" To: "'Ash, Gerald R \(Jerry\), ALABS'" , Subject: RE: [NSIS] QSPEC Issue #1 -- Number of QSPEC-1 (formerly called"mandatory") Parameters Date: Fri, 25 Aug 2006 11:40:36 +0200 Message-ID: <000801c6c82a$8a2dd940$4c0d5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 In-Reply-To: <9473683187ADC049A855ED2DA739ABCA0DDC7C1B@KCCLUST06EVS1.ugd.att.com> Thread-Index: Aca/2udObrHhY/NZTP2OAyPOnNRIrQAAT1TgAAE8mDACEdb18A== X-Spam-Score: -5.534 () ALL_TRUSTED,AWL,BAYES_00,FVGT_s_OBFU_Q1 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0b5 (denhaag.ewi.utwente.nl [130.89.10.11]); Fri, 25 Aug 2006 11:40:50 +0200 (MEST) X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Jerry I have doubts on the need of having all these 4 parameters as being mandatory parameters. The reasons are: * Excess treatment parameter. It should be possible to ignore this parameter in certain domains. For example, when a Diffserv domain is using PCN or RMD it should be able to ignore this parameter. The reason of this is that the way of how the remarking or the dropping of packets is influencing e.g., the PCN or RMD solution. Therefore, it should be possible that the QNEs that are located in such regions to ignore this parameter. * QoS class: It should be possible for some QNEs to ignore this parameter. E.g., problematic when: * a non Diffserv aware QNE receives a PHB class parameter * a non Y.1541 aware QNE receives a Y.1541 class parameter * a non MPLS aware QNE receives a DSTE class parameter. In such situations such QNEs should be able to ignore this parameter. * Priority You already mentioned some reasons on why it should be possible to ignore this parameter. Best regards, Georgios -----Original Message----- From: Ash, Gerald R (Jerry), ALABS [mailto:gash@att.com] Sent: maandag 14 augustus 2006 23:46 To: nsis@ietf.org Cc: Ash, Gerald R (Jerry), ALABS Subject: [NSIS] QSPEC Issue #1 -- Number of QSPEC-1 (formerly called"mandatory") Parameters Hi All, One of the issues identified in the updated 'QoS NSLP QSPEC Template' I-D http://www.ietf.org/internet-drafts/draft-ietf-nsis-qspec-11.txt is as follows: 1. agreement/consensus on 4 QSPEC-1 (formerly called 'mandatory') parameters; see Section 7.2 There was extensive discussion on the list RE "Any resolution of QSPEC mandatory parameter list," which started at http://www1.ietf.org/mail-archive/web/nsis/current/msg06542.html. Various opinions were expressed as to a) whether the QSPEC-1 (mandatory) parameter concept was useful, and b) how many QSPEC-1 parameters there should be. Most opinions expressed on (a) supported the QSPEC-1 parameter concept as a means for a "common language" among different QOSMs and to enhance interoperability. Most opinions expressed on (b) did not oppose the 4 QSPEC parameters now included in the updated QSPEC draft: Parameter (Section 7.2.1) Parameter (Section 7.2.2) Parameter (Section 7.2.3) Parameter (Section 7.2.4) Note that the , , and parameters are "container" parameters. Please express any further comments in support of the proposed resolution, or otherwise, so that we may reach consensus on this issue. Thanks, Regards, Jerry _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Aug 25 05:45:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGYF6-0001H1-KI; Fri, 25 Aug 2006 05:44:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGYF4-0001Gw-Vw for nsis@ietf.org; Fri, 25 Aug 2006 05:44:46 -0400 Received: from denhaag.ewi.utwente.nl ([130.89.10.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGYF3-0000mr-H2 for nsis@ietf.org; Fri, 25 Aug 2006 05:44:46 -0400 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by denhaag.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id k7P9ibQC020217; Fri, 25 Aug 2006 11:44:40 +0200 (MEST) From: "Georgios Karagiannis" To: "'Ash, Gerald R \(Jerry\), ALABS'" , Subject: RE: [NSIS] QSPEC Issue #3 -- Allowing a QSPEC-1 Parameter to be Ignored Date: Fri, 25 Aug 2006 11:44:33 +0200 Message-ID: <000901c6c82b$149f2200$4c0d5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 In-Reply-To: <9473683187ADC049A855ED2DA739ABCA0DDC7C1D@KCCLUST06EVS1.ugd.att.com> Thread-Index: Aca/6wl1mien3kJ5R0u2kXlkJtiCmAIP4e+w X-Spam-Score: -5.533 () ALL_TRUSTED,AWL,BAYES_00,FVGT_s_OBFU_Q1 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0b5 (denhaag.ewi.utwente.nl [130.89.10.11]); Fri, 25 Aug 2006 11:44:42 +0200 (MEST) X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Jerry The below comments are coupled to my comments on QSPEC Issue #1: I am in favour of havenig the possibility to ignore QSPEC-1 parameters. The reasons are identical to the ones I mentioned in my commnets on Issue #1 The reasons are: * Excess treatment parameter. It should be possible to ignore this parameter in certain domains. For example, when a Diffserv domain is using PCN or RMD it should be able to ignore this parameter. The reason of this is that the way of how the remarking or the dropping of packets is influencing e.g., the PCN or RMD solution. Therefore, it should be possible that the QNEs that are located in such regions to ignore this parameter. * QoS class: It should be possible for some QNEs to ignore this parameter. E.g., problematic when: * a non Diffserv aware QNE receives a PHB class parameter * a non Y.1541 aware QNE receives a Y.1541 class parameter * a non MPLS aware QNE receives a DSTE class parameter. In such situations such QNEs should be able to ignore this parameter. * Priority You already mentioned some reasons on why it should be possible to ignore this parameter. Thus if we allow to ignore QSPEC-1 paranmeters, then I can agree on haviong 4 QSPEC-1 parameters. Best regards, Georgios -----Original Message----- From: Ash, Gerald R (Jerry), ALABS [mailto:gash@att.com] Sent: maandag 14 augustus 2006 23:46 To: nsis@ietf.org Cc: Ash, Gerald R (Jerry), ALABS Subject: [NSIS] QSPEC Issue #3 -- Allowing a QSPEC-1 Parameter to be Ignored Hi All, One of the issues identified in the updated 'QoS NSLP QSPEC Template' I-D http://www.ietf.org/internet-drafts/draft-ietf-nsis-qspec-11.txt is as follows: 3. agreement/consensus on whether to allow a QSPEC-1 (formerly called "mandatory") parameter to be ignored; see Section 4.3.1 There was extensive discussion on the list RE whether to allow a QSPEC-1 parameter to be ignored, as is allowed for a QSPEC-2 (formerly called "optional") parameter. Reasons given for allowing this are a) use of a QSPEC-1 parameter might be illegal, as with preemption in the U.S. PSTN, and b) a particular QOSM might not want to support certain QSPEC-1 parameters, i.e., while it would be nice for all QOSMs to support , some have suggested that might not be practical/realistic. Note that this issue is related to Issue #1, that is, if we retain the QSPEC-1 parameter concept, then allowing a QSPEC-1 parameter to be ignored is a step toward doing away with the distinction between QSPEC-1 and QSPEC-2 parameters. It is also related to Issue #2 in that an alternative to "strict interpretation" of QSPEC-1 parameters is remapping these parameters. However, in some cases remapping QSPEC-1 parameters between classes of QSPEC parameters may not make sense, e.g., mapping to . The default resolution is that the QSPEC-1 concept is retained and that all QSPEC-1 parameters must be strictly interpreted or remapped by all QOSMs. Alternatively, it is suggested in Section 4.3.1 that if ignoring a QSPEC-1 parameter is to be allowed, that a high threshold be placed on justification for this in the QOSM specification document: "a QOSM may simply not want to support a QSPEC-1 parameter. In (that) case justification may be more difficult, however there is a filter on reasonableness in that QOSM specifications must be reviewed and approved by the IETF." Please express any further comments in support of the proposed resolution, or otherwise, so that we may reach consensus on this issue. Thanks, Regards, Jerry _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Aug 25 05:54:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGYOF-0005ds-NE; Fri, 25 Aug 2006 05:54:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGYOE-0005dn-I0 for nsis@ietf.org; Fri, 25 Aug 2006 05:54:14 -0400 Received: from denhaag.ewi.utwente.nl ([130.89.10.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGYOD-0002tw-3a for nsis@ietf.org; Fri, 25 Aug 2006 05:54:14 -0400 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by denhaag.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id k7P9s2Aa020779; Fri, 25 Aug 2006 11:54:09 +0200 (MEST) From: "Georgios Karagiannis" To: "'Ash, Gerald R \(Jerry\), ALABS'" , Subject: RE: [NSIS] QSPEC Issue #2 -- Remapping of QSPEC Parameters Date: Fri, 25 Aug 2006 11:53:57 +0200 Message-ID: <000a01c6c82c$657bb480$4c0d5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 In-Reply-To: <9473683187ADC049A855ED2DA739ABCA0DDC7C1C@KCCLUST06EVS1.ugd.att.com> Thread-Index: Aca/6v+XZ64mWNrjQ2CGEB0yMcEbUAIQCTAg X-Spam-Score: -5.532 () ALL_TRUSTED,AWL,BAYES_00,FVGT_s_OBFU_Q1 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0b5 (denhaag.ewi.utwente.nl [130.89.10.11]); Fri, 25 Aug 2006 11:54:10 +0200 (MEST) X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Jerry I agree on the need of including the "Remapped Parameter R-flag". However, I would very much appreciate if you could change the text in Section 4.3.2, page 15: In the last paragraph of bullet a) you mentioned: "The local QSPEC is interpreted by the QNEs in the local domain, and the egress QNE in the local domain pops the local QSPEC and populates token bucket in the initiator QSPEC with just the bandwidth parameter for the token bucket (and not the other token bucket parameters)." I would very much appreciate if the remapping procedure (at the ingress and egress) should be Defined by the QoS models. You could for example replace the above sentence with: "The local QSPEC is interpreted by the QNEs in the local domain, and the egress QNE in the local domain pops the local QSPEC and remaps the bandwidth parameter into the token bucket parameter in the initiator QSPEC." Best regards, Georgios -----Original Message----- From: Ash, Gerald R (Jerry), ALABS [mailto:gash@att.com] Sent: maandag 14 augustus 2006 23:46 To: nsis@ietf.org Cc: Ash, Gerald R (Jerry), ALABS Subject: [NSIS] QSPEC Issue #2 -- Remapping of QSPEC Parameters Hi All, One of the issues identified in the updated 'QoS NSLP QSPEC Template' I-D http://www.ietf.org/internet-drafts/draft-ietf-nsis-qspec-11.txt is as follows: 2. agreement/consensus on what is allowed by remapping QSPEC parameters; see Section 4.3.1 There was extensive discussion on the list RE remapping QSPEC parameters. Various examples of such remapping are given in Section 4.3.1. It is further required that procedures for any such remapping must be documented in a QOSM specification document, and any remapped parameter must be flagged with the "Remapped Parameter R-flag", as specified in the QSPEC draft. The common example used in the QSPEC I-D is remapping of a parameter to a parameter, which is straightforward. However, what should be allowed in the general case is unclear, such as whether to allow remapping between QSPEC parameter types, e.g., remapping to a . Indeed, the remapping concept may be a bit theoretical and some remappings would probably not make sense. A proposed resolution is to give a few examples of remapping, as currently included in Section 4.3.1, and specify the above requirements for the QOSM specification document and setting of the R-flag. It is further proposed in Section 4.3.1 that "We should have a separate document that defines typical remapping of QSPEC parameters, perhaps included in a QOSM definition document. This is to avoid misinterpretation of what is allowed by remapping QSPEC parameters." Please express any further comments in support of the proposed resolution, or otherwise, so that we may reach consensus on this issue. Thanks, Regards, Jerry _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Aug 25 05:59:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGYSp-0008TC-WC; Fri, 25 Aug 2006 05:59:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGYSp-0008T7-0y for nsis@ietf.org; Fri, 25 Aug 2006 05:58:59 -0400 Received: from denhaag.ewi.utwente.nl ([130.89.10.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGYSn-0003lW-Hl for nsis@ietf.org; Fri, 25 Aug 2006 05:58:59 -0400 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by denhaag.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id k7P9wmvF020993; Fri, 25 Aug 2006 11:58:51 +0200 (MEST) From: "Georgios Karagiannis" To: "'Ash, Gerald R \(Jerry\), ALABS'" , Subject: RE: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-11.txt Date: Fri, 25 Aug 2006 11:58:44 +0200 Message-ID: <000b01c6c82d$1004c770$4c0d5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 In-Reply-To: <9473683187ADC049A855ED2DA739ABCA0DDC7C1A@KCCLUST06EVS1.ugd.att.com> Thread-Index: Aca/2udObrHhY/NZTP2OAyPOnNRIrQAAT1TgAhQsFhA= X-Spam-Score: -5.531 () ALL_TRUSTED,AWL,BAYES_00,FVGT_s_OBFU_Q1 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0b5 (denhaag.ewi.utwente.nl [130.89.10.11]); Fri, 25 Aug 2006 11:58:54 +0200 (MEST) X-Spam-Score: 0.0 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi all Looking to the last version of QSPEC template (v.11) submitted I can see that NSIS is not able to detect that a RESERVE message passed a node that is NSIS/QoS-NSLP unaware. I think that we have to include a solution in the QoS-NSLP draft (solution similar to RSVP) to support this feature. Best Regards, Georgios -----Original Message----- From: Ash, Gerald R (Jerry), ALABS [mailto:gash@att.com] Sent: maandag 14 augustus 2006 22:29 To: nsis@ietf.org Cc: Ash, Gerald R (Jerry), ALABS Subject: RE: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-11.txt Hi All, The updated 'QoS NSLP QSPEC Template' I-D is available at http://www.ietf.org/internet-drafts/draft-ietf-nsis-qspec-11.txt. The updates are in response to a very large number of comments and discussion on the list since the last update (-10 version) in June. We have tried to incorporate all comments/agreements into the updated -11 version. Given the large number of comments and extensive discussion, please check to be sure that the agreed-to changes/comments are properly incorporated. The main changes are as follows: 1. 'QSPEC-1 parameter' replaces 'mandatory QSPEC parameter' 2. 'QSPEC-2 parameter' replaces 'optional QSPEC parameter' 3. R-flag ('remapped parameter flag') introduced to denote remapping, approximating, or otherwise not strictly interpreting a QSPEC parameter 3. T-flag ('tunneled parameter flag') eliminated and incorporated within the R-flag 4. Section 4 rewritten on QOSM concept, QSPEC processing, etc. to provide a more logical flow of information 5. read-write/read-only flag associated with QSPEC objects eliminated and object itself defined as rw or ro without a flag 6. parameter redefined as non-QOSM-hop Q-flag 7. Section 7 on QSPEC parameter definitions revised to clearly separate QSPEC-1 parameter coding from QSPEC-2 parameter coding 8. , , and QSPEC-1 parameters mapped to container parameters 9. references updated to include normative references defining procedures to 'strictly interpret' each QSPEC parameter 10. Section 7.2.1 on PHB class updated to specify additional RFC 3140 cases 11. Section 7.2.1 on excess treatment updated to specify excess treatment behaviors There are still 4 open issues currently identified based on the list discussion: 1. agreement/consensus on 4 QSPEC-1 (formerly called 'mandatory') parameters; see Section 7.2 2. agreement/consensus on what is allowed by remapping QSPEC parameters; see Section 4.3.1 3. agreement/consensus on whether to allow a QSPEC-1 parameter to be ignored; see Section 4.3.1 I will soon start a separate thread on each of the above issues so that we may reach final consensus. Please review the document and let us know of any further comments or suggestions. At this point comments/suggestions should be accompanied by suggested text changes, if any. Thanks, Regards, Jerry -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: Monday, August 14, 2006 3:50 PM To: i-d-announce@ietf.org Cc: nsis@ietf.org Subject: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-11.txt 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 : QoS NSLP QSPEC Template Author(s) : J. Ash, et al. Filename : draft-ietf-nsis-qspec-11.txt Pages : 62 Date : 2006-8-14 The QoS NSLP protocol is used to signal QoS reservations and is independent of a specific QoS model (QOSM) such as IntServ or DiffServ. Rather, all information specific to a QOSM is encapsulated in a separate object, the QSPEC. This document defines a template for the QSPEC, which contains both the QoS description and QSPEC control information. The QSPEC format is defined, as are a number of QSPEC parameters. The QSPEC-1 parameters provide a common language to be re-used in several QOSMs. QSPEC-2 parameters aim to ensure the extensibility of QoS NSLP to other QOSMs in the future. To a certain extent QSPEC parameters ensure interoperability of QOSMs. The node initiating the NSIS signaling adds an Initiator QSPEC that must not be removed, thereby ensuring the intention of the NSIS initiator is preserved along the signaling path. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nsis-qspec-11.txt _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Aug 25 08:54:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGbBV-00037n-62; Fri, 25 Aug 2006 08:53:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGbBT-00036s-JT for nsis@ietf.org; Fri, 25 Aug 2006 08:53:15 -0400 Received: from mail121.messagelabs.com ([216.82.241.195]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GGbBR-0007FA-8Q for nsis@ietf.org; Fri, 25 Aug 2006 08:53:15 -0400 X-VirusChecked: Checked X-Env-Sender: gash@att.com X-Msg-Ref: server-14.tower-121.messagelabs.com!1156508607!10628044!50 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 9151 invoked from network); 25 Aug 2006 12:26:32 -0000 Received: from unknown (HELO attrh3i.attrh.att.com) (134.24.146.4) by server-14.tower-121.messagelabs.com with SMTP; 25 Aug 2006 12:26:32 -0000 Received: from kcclust06evs1.ugd.att.com (135.38.164.88) by attrh3i.attrh.att.com (7.2.052) id 44E128F50019DF65; Fri, 25 Aug 2006 08:26:31 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] QSPEC Issue #3 -- Allowing a QSPEC-1 Parameter to be Ignored Date: Fri, 25 Aug 2006 07:26:31 -0500 Message-ID: <9473683187ADC049A855ED2DA739ABCA0DDC7C9A@KCCLUST06EVS1.ugd.att.com> In-Reply-To: <000901c6c82b$149f2200$4c0d5982@dynamic.ewi.utwente.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] QSPEC Issue #3 -- Allowing a QSPEC-1 Parameter to be Ignored Thread-Index: Aca/6wl1mien3kJ5R0u2kXlkJtiCmAIP4e+wAAWS8CA= From: "Ash, Gerald R \(Jerry\), ALABS" To: "Georgios Karagiannis" , X-Spam-Score: 0.0 (/) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 Cc: "Ash, Gerald R \(Jerry\), ALABS" X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Georgios, See comments below.=20 > -----Original Message----- > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl]=20 > Sent: Friday, August 25, 2006 5:45 AM > To: Ash, Gerald R (Jerry), ALABS; nsis@ietf.org > Subject: RE: [NSIS] QSPEC Issue #3 -- Allowing a QSPEC-1=20 > Parameter to be Ignored >=20 > Hi Jerry >=20 > The below comments are coupled to my comments on QSPEC Issue #1: > I am in favour of having the possibility to ignore QSPEC-1=20 > parameters. > The reasons are identical to the ones I mentioned in my=20 > comments on Issue #1 >=20 >=20 > The reasons are: >=20 > * Excess treatment parameter. =20 > It should be possible to ignore this parameter in certain domains. > For example, when a Diffserv domain is using PCN or RMD it=20 > should be able to > ignore this parameter. > The reason of this is that the way of how the remarking or=20 > the dropping of > packets=20 > is influencing e.g., the PCN or RMD solution. Therefore, it should be > possible that the=20 > QNEs that are located in such regions to ignore this parameter. >=20 > * QoS class: > It should be possible for some QNEs=20 > to ignore this parameter. > E.g., problematic when: > * a non Diffserv aware QNE receives a PHB class parameter > * a non Y.1541 aware QNE receives a Y.1541 class parameter > * a non MPLS aware QNE receives a DSTE class parameter. > In such situations such QNEs should be able to ignore this parameter. >=20 > * Priority > You already mentioned some reasons on why it should be=20 > possible to ignore > this parameter. >=20 > Thus if we allow to ignore QSPEC-1 parameters, then I can=20 > agree on having 4 QSPEC-1 parameters. As stated below, allowing to ignore QSPEC-1 parameters would pretty much do away with the distinction between QSPEC-1 and QSPEC-2 parameters. Thanks, Jerry =20 >=20 > Best regards, > Georgios=20 >=20 > -----Original Message----- > From: Ash, Gerald R (Jerry), ALABS [mailto:gash@att.com]=20 > Sent: maandag 14 augustus 2006 23:46 > To: nsis@ietf.org > Cc: Ash, Gerald R (Jerry), ALABS > Subject: [NSIS] QSPEC Issue #3 -- Allowing a QSPEC-1=20 > Parameter to be Ignored >=20 > Hi All, >=20 > One of the issues identified in the updated 'QoS NSLP QSPEC Template' > I-D=20 > http://www.ietf.org/internet-drafts/draft-ietf-nsis-qspec-11.txt is as > follows: >=20 > 3. agreement/consensus on whether to allow a QSPEC-1 (formerly called > "mandatory") parameter to be ignored; see Section 4.3.1 >=20 > There was extensive discussion on the list RE whether to=20 > allow a QSPEC-1 > parameter to be ignored, as is allowed for a QSPEC-2 (formerly called > "optional") parameter. Reasons given for allowing this are=20 > a) use of a > QSPEC-1 parameter might be illegal, as with preemption in the=20 > U.S. PSTN, and > b) a particular QOSM might not want to support certain=20 > QSPEC-1 parameters, > i.e., while it would be nice for all QOSMs to support Class>, some have suggested that might not be practical/realistic. >=20 > Note that this issue is related to Issue #1, that is, if we retain the > QSPEC-1 parameter concept, then allowing a QSPEC-1 parameter=20 > to be ignored > is a step toward doing away with the distinction between=20 > QSPEC-1 and QSPEC-2 > parameters. It is also related to Issue #2 in that an alternative to > "strict interpretation" of QSPEC-1 parameters is remapping=20 > these parameters. > However, in some cases remapping QSPEC-1 parameters between=20 > classes of QSPEC > parameters may not make sense, e.g., mapping to=20 > . > =20 > The default resolution is that the QSPEC-1 concept is=20 > retained and that all > QSPEC-1 parameters must be strictly interpreted or remapped=20 > by all QOSMs. > Alternatively, it is suggested in Section 4.3.1 that if=20 > ignoring a QSPEC-1 > parameter is to be allowed, that a high threshold be placed=20 > on justification > for this in the QOSM specification document: > "a QOSM may simply not want to support a QSPEC-1 parameter. =20 > In (that) case > justification may be more difficult, however there is a filter on > reasonableness in that QOSM specifications must be reviewed=20 > and approved by > the IETF." >=20 > Please express any further comments in support of the=20 > proposed resolution, > or otherwise, so that we may reach consensus on this issue. >=20 > Thanks, > Regards, > Jerry _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Aug 25 09:39:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGbtn-0000ar-GY; Fri, 25 Aug 2006 09:39:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGbtm-0000aM-0F for nsis@ietf.org; Fri, 25 Aug 2006 09:39:02 -0400 Received: from rsys002x.roke.co.uk ([193.118.201.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGbtj-0005pt-4B for nsis@ietf.org; Fri, 25 Aug 2006 09:39:01 -0400 Received: from rsys005a.comm.ad.roke.co.uk (rsys005a [193.118.193.85]) by rsys002x.roke.co.uk (8.13.1/8.13.1) with ESMTP id k7PDcXoo019621; Fri, 25 Aug 2006 14:38:33 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] QSPEC Issue #3 -- Allowing a QSPEC-1 Parameter to beIgnored Date: Fri, 25 Aug 2006 14:38:33 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] QSPEC Issue #3 -- Allowing a QSPEC-1 Parameter to beIgnored Thread-Index: Aca/6wl1mien3kJ5R0u2kXlkJtiCmAIP4e+wAAWS8CAAAoy9AA== From: "Hancock, Robert" To: "Ash, Gerald R \(Jerry\), ALABS" , "Georgios Karagiannis" , X-MailScanner-roke-co-uk: Found to be clean X-MailScanner-roke-co-uk-SpamCheck: X-MailScanner-From: robert.hancock@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 995b2e24d23b953c94bac5288c432399 Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org hi, on the question of whether a type 1 parameter can be ignored: i agree that making this change reduces the distinction within the protocol operation between type 1 and type 2 parameters. however, i don't think we should lose sight of the fact that there can still be a difference which applies during the=20 specfication process. namely, that when a QoS model is reviewed, if it defines something a bit like a type 1 parameter but not identical to it, and/or refuses to say how a type 1 parameter should be handled when there is a clear way to do so, then this would be grounds for preventing it being approved as a specification. (at least, that i my interpretation of the proposal.)=20 so, it is a weaker distinction, but still valuable. cheers, robert h. > -----Original Message----- > From: Ash, Gerald R (Jerry), ALABS [mailto:gash@att.com]=20 > Sent: 25 August 2006 13:27 > To: Georgios Karagiannis; nsis@ietf.org > Cc: Ash, Gerald R (Jerry), ALABS > Subject: RE: [NSIS] QSPEC Issue #3 -- Allowing a QSPEC-1=20 > Parameter to beIgnored >=20 >=20 > Hi Georgios, >=20 > See comments below.=20 >=20 > > -----Original Message----- > > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl]=20 > > Sent: Friday, August 25, 2006 5:45 AM > > To: Ash, Gerald R (Jerry), ALABS; nsis@ietf.org > > Subject: RE: [NSIS] QSPEC Issue #3 -- Allowing a QSPEC-1=20 > > Parameter to be Ignored > >=20 > > Hi Jerry > >=20 > > The below comments are coupled to my comments on QSPEC Issue #1: > > I am in favour of having the possibility to ignore QSPEC-1=20 > > parameters. > > The reasons are identical to the ones I mentioned in my=20 > > comments on Issue #1 > >=20 > >=20 > > The reasons are: > >=20 > > * Excess treatment parameter. =20 > > It should be possible to ignore this parameter in certain domains. > > For example, when a Diffserv domain is using PCN or RMD it=20 > > should be able to > > ignore this parameter. > > The reason of this is that the way of how the remarking or=20 > > the dropping of > > packets=20 > > is influencing e.g., the PCN or RMD solution. Therefore, it=20 > should be > > possible that the=20 > > QNEs that are located in such regions to ignore this parameter. > >=20 > > * QoS class: > > It should be possible for some QNEs=20 > > to ignore this parameter. > > E.g., problematic when: > > * a non Diffserv aware QNE receives a PHB class parameter > > * a non Y.1541 aware QNE receives a Y.1541 class parameter > > * a non MPLS aware QNE receives a DSTE class parameter. > > In such situations such QNEs should be able to ignore this=20 > parameter. > >=20 > > * Priority > > You already mentioned some reasons on why it should be=20 > > possible to ignore > > this parameter. > >=20 > > Thus if we allow to ignore QSPEC-1 parameters, then I can=20 > > agree on having 4 QSPEC-1 parameters. >=20 > As stated below, allowing to ignore QSPEC-1 parameters would=20 > pretty much > do away with the distinction between QSPEC-1 and QSPEC-2 parameters. >=20 > Thanks, > Jerry > =20 > >=20 > > Best regards, > > Georgios=20 > >=20 > > -----Original Message----- > > From: Ash, Gerald R (Jerry), ALABS [mailto:gash@att.com]=20 > > Sent: maandag 14 augustus 2006 23:46 > > To: nsis@ietf.org > > Cc: Ash, Gerald R (Jerry), ALABS > > Subject: [NSIS] QSPEC Issue #3 -- Allowing a QSPEC-1=20 > > Parameter to be Ignored > >=20 > > Hi All, > >=20 > > One of the issues identified in the updated 'QoS NSLP QSPEC=20 > Template' > > I-D=20 > >=20 > http://www.ietf.org/internet-drafts/draft-ietf-nsis-qspec-11.txt is as > > follows: > >=20 > > 3. agreement/consensus on whether to allow a QSPEC-1=20 > (formerly called > > "mandatory") parameter to be ignored; see Section 4.3.1 > >=20 > > There was extensive discussion on the list RE whether to=20 > > allow a QSPEC-1 > > parameter to be ignored, as is allowed for a QSPEC-2=20 > (formerly called > > "optional") parameter. Reasons given for allowing this are=20 > > a) use of a > > QSPEC-1 parameter might be illegal, as with preemption in the=20 > > U.S. PSTN, and > > b) a particular QOSM might not want to support certain=20 > > QSPEC-1 parameters, > > i.e., while it would be nice for all QOSMs to support > Class>, some have suggested that might not be practical/realistic. > >=20 > > Note that this issue is related to Issue #1, that is, if we=20 > retain the > > QSPEC-1 parameter concept, then allowing a QSPEC-1 parameter=20 > > to be ignored > > is a step toward doing away with the distinction between=20 > > QSPEC-1 and QSPEC-2 > > parameters. It is also related to Issue #2 in that an=20 > alternative to > > "strict interpretation" of QSPEC-1 parameters is remapping=20 > > these parameters. > > However, in some cases remapping QSPEC-1 parameters between=20 > > classes of QSPEC > > parameters may not make sense, e.g., mapping to=20 > > . > > =20 > > The default resolution is that the QSPEC-1 concept is=20 > > retained and that all > > QSPEC-1 parameters must be strictly interpreted or remapped=20 > > by all QOSMs. > > Alternatively, it is suggested in Section 4.3.1 that if=20 > > ignoring a QSPEC-1 > > parameter is to be allowed, that a high threshold be placed=20 > > on justification > > for this in the QOSM specification document: > > "a QOSM may simply not want to support a QSPEC-1 parameter. =20 > > In (that) case > > justification may be more difficult, however there is a filter on > > reasonableness in that QOSM specifications must be reviewed=20 > > and approved by > > the IETF." > >=20 > > Please express any further comments in support of the=20 > > proposed resolution, > > or otherwise, so that we may reach consensus on this issue. > >=20 > > Thanks, > > Regards, > > Jerry >=20 > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Aug 28 04:17:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHcIa-0006Kp-P0; Mon, 28 Aug 2006 04:16:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHcIZ-0006Ke-9P for nsis@ietf.org; Mon, 28 Aug 2006 04:16:47 -0400 Received: from mailing.unile.it ([193.204.77.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GHcIU-0002j1-T4 for nsis@ietf.org; Mon, 28 Aug 2006 04:16:47 -0400 Received: from elena1 (unknown [10.0.12.115]) by mailing.unile.it (Postfix) with SMTP id D096C104B50; Mon, 28 Aug 2006 09:59:36 +0200 (CEST) Message-ID: <006d01c6ca77$f84813b0$730c000a@elena1> From: "Elena Scialpi" To: Date: Mon, 28 Aug 2006 10:00:03 +0200 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Antivirus: avast! (VPS 0634-2, 24/08/2006), Outbound message X-Antivirus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: Andrea Tricco , "franco.tommasi" , Simone Molendini Subject: [NSIS] draft-tommasi-nsis-semipro -01 version X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0309030709==" Errors-To: nsis-bounces@ietf.org This is a multi-part message in MIME format. --===============0309030709== Content-Type: multipart/alternative; boundary="----=_NextPart_000_006A_01C6CA88.BB78B190" This is a multi-part message in MIME format. ------=_NextPart_000_006A_01C6CA88.BB78B190 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, we have updated the draft "Semi-Proactive QoS Re-establishment"; you can = see it at: http://www.ietf.org/internet-drafts/draft-tommasi-nsis-semipro-01.txt In this draft we introduce a new MRM, the "Semi-Proactive MRM". Any comments or suggestions are very much appreciated. Thanks and regards, Elena Scialpi ------------=20 LIIS Laboratorio per l'Internetworking e l'Interoperabilita' tra i Sistemi http://liis.unile.it http://www.campusdelsalento.it Office: (+39) 0832-297310 c/o Palazzo di Ingegneria Via per Monteroni I-73100 Lecce LE, Italy ------=_NextPart_000_006A_01C6CA88.BB78B190 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
Hi all,
we have updated the draft "Semi-Proactive QoS = Re-establishment"; you=20 can see it at:
http://www.ietf.org/internet-drafts/draft-tommasi-nsis-semipro-01.t= xt
 
 
In this draft we introduce a new MRM, the "Semi-Proactive = MRM".
 
Any comments or suggestions are very much = appreciated.

Thanks and=20 regards,
Elena Scialpi
 
 
 
 
 
------------
LIIS
Laboratorio = per=20 l'Internetworking
e l'Interoperabilita' tra i Sistemi
http://liis.unile.it
http://www.campusdelsalento.it
Office:=20 (+39) 0832-297310
c/o Palazzo di Ingegneria
Via per = Monteroni
I-73100=20 Lecce LE, Italy
------=_NextPart_000_006A_01C6CA88.BB78B190-- --===============0309030709== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis --===============0309030709==-- From nsis-bounces@ietf.org Mon Aug 28 06:03:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHdxL-0002VE-8L; Mon, 28 Aug 2006 06:02:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHdxJ-0002V0-UN for nsis@ietf.org; Mon, 28 Aug 2006 06:02:57 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GHdJ7-0003nw-TI for nsis@ietf.org; Mon, 28 Aug 2006 05:21:25 -0400 Received: from rsys002x.roke.co.uk ([193.118.201.109]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GHdAk-00059F-Pz for nsis@ietf.org; Mon, 28 Aug 2006 05:12:50 -0400 Received: from rsys005a.comm.ad.roke.co.uk (rsys005a [193.118.193.85]) by rsys002x.roke.co.uk (8.13.1/8.13.1) with ESMTP id k7S9CRtI030589; Mon, 28 Aug 2006 10:12:32 +0100 Received: from [193.118.197.193] ([193.118.197.193]) by rsys005a.comm.ad.roke.co.uk with Microsoft SMTPSVC(6.0.3790.1830); Mon, 28 Aug 2006 10:12:27 +0100 Message-ID: <44F2B37B.9050201@roke.co.uk> Date: Mon, 28 Aug 2006 10:12:27 +0100 From: Andrew McDonald User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Bernd Schloer Subject: Re: [NSIS] Receiver Initiated Reservation - Teardown References: <44A99A80.2060904@cs.uni-goettingen.de> <016f01c6a04a$36286980$730c000a@elena1> <44ABEF57.2030002@schloer.net> In-Reply-To: <44ABEF57.2030002@schloer.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Aug 2006 09:12:27.0759 (UTC) FILETIME=[153E1FF0:01C6CA82] X-MailScanner-roke-co-uk: Found to be clean X-MailScanner-roke-co-uk-SpamCheck: X-MailScanner-From: andrew.mcdonald@roke.co.uk X-Spam-Score: -2.6 (--) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: nsis@ietf.org, Elena Scialpi X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Bernd, Elena, Checking through some old e-mails, I came across this: Bernd Schloer wrote: > Elena Scialpi wrote: >> Bernd Schloer wrote: >>> >>> RSVP has two types of teardown-messages: PathTear and ResvTear. The >>> QoS NSLP is only allowed to send a RESERVE towards the QNR. How can a >>> receiver initiated reservation be torn down? The QNR is not allowed. >> >> I think that a reservation can be torn down by a RESERVE message ( >> with TEAR flag set) from both, QNI and QNR, entity. >> Only RESERVE for resource reservation MUST travel from QNI to QNR and >> not in the opposite direction. >> > That would make sense. But section 5.4.1 says: > > RESERVE messages MUST only be sent towards the QNR. > > In my opinion this includes also RESERVE messages with set T-Flag. I'm in agreement with Bernd on what the current text says - The intention is that this applies both to the reservation-making RESERVE and the reservation-removing RESERVE (i.e. it applies to all RESERVE messages). The reasoning behind this was to do with authorization - if only the peer QNE that established the reservation can manipulate it (change it, remove it, etc), it makes the reasoning simpler about whether a RESERVE is authorized or not. I think that the situation being envisaged is not unique to receiver initiated reservations. A similar situation could apply with a pair of sender initiated reservations for a bidirectional flow, where one end decides to terminate the user data session and so cause the reservation to also be torn down. Some end-to-end communication will be performed as part of the user data flow, which would provide the information to the other signalling endpoint necessary for it to decide to tear down the reservation from its end. In the past, I believe, we've considered that sufficient when looking at this particular issue. regards, Andrew _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Aug 28 09:06:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHgoX-0000Cc-Ej; Mon, 28 Aug 2006 09:06:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHgoV-0000CW-SN for nsis@ietf.org; Mon, 28 Aug 2006 09:06:03 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GHf9V-0003HL-42 for nsis@ietf.org; Mon, 28 Aug 2006 07:19:37 -0400 Received: from rsys002x.roke.co.uk ([193.118.201.109]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GHek5-00085e-4r for nsis@ietf.org; Mon, 28 Aug 2006 06:53:26 -0400 Received: from rsys005a.comm.ad.roke.co.uk (rsys005a [193.118.193.85]) by rsys002x.roke.co.uk (8.13.1/8.13.1) with ESMTP id k7SAo9M6010147; Mon, 28 Aug 2006 11:50:13 +0100 Received: from [193.118.197.193] ([193.118.197.193]) by rsys005a.comm.ad.roke.co.uk with Microsoft SMTPSVC(6.0.3790.1830); Mon, 28 Aug 2006 11:50:09 +0100 Message-ID: <44F2CA60.4090305@roke.co.uk> Date: Mon, 28 Aug 2006 11:50:08 +0100 From: Andrew McDonald User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: "Tschofenig, Hannes" Subject: Re: [NSIS] QoS NSLP Review References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Aug 2006 10:50:09.0093 (UTC) FILETIME=[BADEB750:01C6CA8F] X-MailScanner-roke-co-uk: Found to be clean X-MailScanner-roke-co-uk-SpamCheck: X-MailScanner-From: andrew.mcdonald@roke.co.uk X-Spam-Score: -2.6 (--) X-Scan-Signature: 93df555cbdbcdae9621e5b95d44b301e Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Hannes, Tschofenig, Hannes wrote: > * Section 3.1.3. > > Change from: > > " > The protocol does not currently define a way to carry such additional > information (sometimes called "Policy data"), but this could be > provided as a later extension. Some work in this direction is > described in [NSLP-AUTH]. > " > > to: > > " > The QoS NSLP does not contain objects to carry authorization > information. [NSLP-AUTH] provides this functionality for the QoS NSLP > and the NATFW NSLP. > " I agree. Added as Issue 94. http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-qos-nslp-issues/issue94 > * In Section 3.3.1 (overview section) you use RFC 2119 language. I don't > think it is necessary. I agree - section 3 is supposed to be informative rather than normative anyway. Added as Issue 95. http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-qos-nslp-issues/issue95 > * Section 3.3.5 describes two different aspects. Put the second > paragraph into a separate subsection, if you think it is needed. The first is about a GIST interaction (i.e. fits in section 3.3), the second part isn't. However, there is some connection since they are both part of the "how to indicate that no QoS was provided along some part of the path" question that, I think, is still open. I've added issue 96 to track this for now. http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-qos-nslp-issues/issue96 > * Section 5.1.1: Difference between message-specific flags and generic > flags is not obvious since even the generic flags are not applicable to > all messages. Is this still inline with your thinking? I think this is more of a text structuring issue than a technical change. I think that the generic flags should be defined once in section 5.1.1. It so happens that the 'S' (scoping) flag doesn't affect the behaviour of NOTIFY, because of the way the default scope of that message is defined. i.e. it doesn't make any difference whether 'S' is set or not, so the 'S' flag could be used for NOTIFY (it would be strange, but not invalid). Added issue 97. http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-qos-nslp-issues/issue97 > * Section 5.1.2.1, TEAR(T) flag: The usage of a QSPEC seems to depend on > a few things that are not described. This might make it more difficult > for interoperability. Would a QoSM describe the semantic. The same is > true for the usage of the QSPEC object in a QUERY, a RESPONSE or a > NOTIFY. Is it sufficient to point to the QSPEC or QoSMs with regard to > the behavior? What is your proposal here? Is it just to delete the example (",e.g. for an aggregation ... from the aggregate.")? > * Section 5.1.3.5: You might want to include an MRI identifier if you > think that the parameter description is different for other MRIs. > > Hence, delete the following figure: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > // Method-specific classifier data (variable) // > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ An MRI identifier was included in the first iteration of this. It was removed since it is carried in the GIST MRI anyway. The MRI identifier in this object would always be the same as that in the GIST MRI. So, it would carry no additional information, and leave us with an additional error case to deal with. > * Section 5.3.6: > > The following text is wrong: > " > Yet, if the top most QSPEC > (i.e., te first QSPEC in the message) defines an unknown QOSM not > understood by the RMF, the QNE MUST send an RESPONSE containing an > INFO_SPEC and MUST NOT attempt to recover by inspecting the other > QSPEC at the bottom of the stack. > " > > If a QNE does not understand the QOSM then it looks at the mandatory > objects. You could just point to the QSPEC template draft. Agreed. Added issue 98. http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-qos-nslp-issues/issue98 > * IANA Consideration Section: > > - How can you define new Error Source Identifiers? > > - For the QoS NSLP ID you don't need IANA to instruct a new registry. > Delete the text in Section 6.4 and ask IANA to allocate a value from the > registry created by GIST. > > - I guess you need to create a registry for the BOUND_SESSION_ID > Binding Codes. > > - With Section 6.2 I was not quite sure what you ask IANA todo. How > would the registry look like? I've added these to the existing issue 45. http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-qos-nslp-issues/issue45 > - I guess you also have to create a registry for the PACKET_CLASSIFIER > flags. I don't think these needs a new IANA registry - it just relies on the GIST MRM registry. What, I think, is needed is some guidance on what to do when defining QoS NSLP support for a new MRM. It would probably be sufficient to add some words to 5.1.3.5 saying: "When QoS NSLP support for a new MRM is defined, appropriate Method-specific Classifier Data needs to be defined." I've added this as issue 99. http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-qos-nslp-issues/issue99 > Editorial: > > * Editor: Check the document for missing 'the' in front of "QoS NSLP". I > got the impression that many of them are missing. > > * Make the RFC editors job easier by using capitalized headings. This is > what I mean: > > Change from: "3.1. Overall approach" to ""3.1. Overall Approach" > > Not a lot of work but the editor will be thankful. > > * Use only QoS NSLP (instead of QoS-NSLP). See, for example, Section > 3.1, first paragraph. I've added these as issue 100. http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-qos-nslp-issues/issue100 > * Section 5.3.4 > > " > There are two time parameters relevant to each QoS NSLP state in a > node: the refresh period R between generation of successive refreshes > for the state by the neighbor node, and the local state's lifetime L. > Each RESERVE message may contain a REFRESH_PERIOD object specifying > the R value that was used to generate this (refresh) message. This R > value is then used to determine the value for L when the state is > received and stored. The values for R and L may vary from peer to > peer. This peer-to-peer refreshing (as opposed to the QNI initiating > a refresh which travels all the way to the QNR) allows QNEs to choose > refresh intervals as appropriate for their environment. For example, > it is conceivable that refreshing intervals in the backbone, where > reservations are relatively stable, are much larger than in an access > network. > " > > to: > > " > There are two time parameters relevant to each QoS NSLP state in a > node: the refresh period R between generation of successive refreshes > for the state by the neighbor node, and the local state's lifetime L. > Each RESERVE message may contain a REFRESH_PERIOD object specifying > the R value that was used to generate this (refresh) message. This R > value is then used to determine the value for L when the state is > received and stored. The values for R and L may vary from peer to > peer. > " > > Reason: The deleted text appeared already in a previous paragraph. Added these as issue 101. http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-qos-nslp-issues/issue101 thanks, Andrew _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Aug 28 11:07:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHihu-0003Oo-GH; Mon, 28 Aug 2006 11:07:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHiht-0003Oe-LL for nsis@ietf.org; Mon, 28 Aug 2006 11:07:21 -0400 Received: from rsys002x.roke.co.uk ([193.118.201.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GHihr-0006Ac-Cl for nsis@ietf.org; Mon, 28 Aug 2006 11:07:21 -0400 Received: from rsys005a.comm.ad.roke.co.uk (rsys005a [193.118.193.85]) by rsys002x.roke.co.uk (8.13.1/8.13.1) with ESMTP id k7SF77fs012941 for ; Mon, 28 Aug 2006 16:07:12 +0100 Received: from [193.118.197.193] ([193.118.197.193]) by rsys005a.comm.ad.roke.co.uk with Microsoft SMTPSVC(6.0.3790.1830); Mon, 28 Aug 2006 16:07:08 +0100 Message-ID: <44F3069B.9080709@roke.co.uk> Date: Mon, 28 Aug 2006 16:07:07 +0100 From: Andrew McDonald User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: nsis@ietf.org Subject: Re: [NSIS] QoS NSLP comments References: <3a5b10a19e5a377cc69a9714e94fd5ff@192.168.0.7> In-Reply-To: <3a5b10a19e5a377cc69a9714e94fd5ff@192.168.0.7> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Aug 2006 15:07:08.0098 (UTC) FILETIME=[A1502A20:01C6CAB3] X-MailScanner-roke-co-uk: Found to be clean X-MailScanner-roke-co-uk-SpamCheck: X-MailScanner-From: andrew.mcdonald@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 0e9ebc0cbd700a87c0637ad0e2c91610 X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Christian, Christian Dickmann wrote: > I did a brief review of the QoS NSLP and came up with some issues. > None of them is really severe. > > Issue 1) Section 3.3 "GIST Interactions": > "When GIST passes the QoS NSLP data to the NSLP for processing, it > must also indicate the value of the 'D' (Direction) flag for that > message. This is done in the Direction attribute of the SendMessage > and RecvMessage primitives." > Most likely this is outdated. There is no Direction attribute in the > primitives, but the direction is indicated through the D-Flag in the > MRI. Agreed. Added as issue 102. http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-qos-nslp-issues/issue102 > Issue 2) Section 5.1 "QoS NSLP Message and Object Formats": > "An implementation should create messages with the objects > in the order shown here, but accept the objects in any order." > Maybe this should be changed to something like: > "An implementation SHOULD create message with the objects > in the order shown here, but MUST accept the objects in any order" > At least, it should be really clear, what an implementation > is allowed to do and which aspects are mandatory. I agree, we should use RFC2119 language here. Added issue 103. http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-qos-nslp-issues/issue103 > Issue 3) Section 5.1.1 "Common header": > Why is this header a COMMON header, if there is a field in there, which > is message specific? And in addition, why are the generic fields > not really generic, but get their meaning based on the actual message > type? > This does not seem to be very reasonable to me. First, the common header > is not common and then the generic flags are not generic. > > Generic fields should have a generic meaning, which is defined once for > all message types. Of course, some messages might have certain flags set > to 0 or 1 every time, but again, this should not change the meaning of the > flag. > I suggest to change all flags to real generic ones, like it is done in > GIST for example. Then the generic flags are generic and the header is > common. I agree. I think this is captured in issue 97 which I opened in response to a similar comment from Hannes. http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-qos-nslp-issues/issue97 > Issue 4) Section 5.1.2: > Various time you state "There are no requirement on > transmission order, although the above order is recommended." > However, you already said so in the beginning of section 5.1 > (see Issue 2). So to my mind, you do not have to repeat it for > every message. > > > Issue 5) Section 5.1.2.1: "RESERVE" > "[ [ PACKET_CLASSIFIER ] [ QSPEC ] [ QSPEC ] ]". The outer brackets > are unnecessary and should be removed. In addition see Issue 6. Based on the text in that section, I think this should actually be: [ [ PACKET_CLASSIFIER ] QSPEC [ QSPEC ] ] i.e. you can have a QSPEC without a PACKET_CLASSIFIER, but not vice versa Added issue 104. http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-qos-nslp-issues/issue104 > Issue 6) Section 5.1.2: > In the RESPONSE message, you use the notation "[ QSPEC [ QSPEC ] ]", > while you use "[ QSPEC ] [ QSPEC ]" in NOTIFY and RESERVE. > I suggest to one use one version, namely the first one. By 'first one', I assume you mean "[ QSPEC [ QSPEC ] ]". I think that one shows the intent better (though in pure BNF terms they actually mean the same things since all 'QSPEC's are the same). Added issue 105. http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-qos-nslp-issues/issue105 > Issue 7) Section 5.1.3.6: "INFO_SPEC": > You should move the error codes their own section, that can be found > in the table of contents. This would help to quickly lookup some > error. I've no particular view on this. I suspect, as a fifth level heading, it won't appear in the ToC anyway. I've added it as issue 106, so that Jukka (as Editor) can make a decision. http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-qos-nslp-issues/issue106 > Issue 8) Section 5.2.1: "State manipulation": > "The state information for a given key includes: > Flow ID" > Maybe calling it MRI (maybe in brackets) helps to map the different names, > especially if you talk about GIST identifiers here in the section. > (I know, that you define it in the terminology, but it might help here) I'd suggest changing the first sentence of the description to say "Based on GIST MRI." Added issue 107. http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-qos-nslp-issues/issue107 > Issue 9) Section 5.2.4: "Retransmissions": > "In the latter case, a failure SHOULD be indicated to > the signaling application." > I am not sure, if it is 100% clear here, which entity the "signaling application" > is. For example in section 3.2.10.1 you write > "GIST will also notify the signaling application that no downstream > GIST nodes supporting the QoS NSLP are present." > Here, the signaling application seems to be the QoS NSLP itself, since > GIST will only communicate with the NSLPs. I'm not sure what this is meant to say. Jukka may be able to comment. > Issue 10) Section 6 "IANA Considerations": > One the one hand you say, that you contribute your object types to the common > NSLP object type registrym, but you also claim to create a NEW registry > called "QoS NSLP Object Types". The same for the NSLP ID. From my understanding > (I am absolutely no IANA expert) GIST opens the registry and the NSLP only > contributes a a new entry instead of opeing of a new registry. Yes, some fixing needs to happen here. I think that the current proposal is that the first NSLP opens the registry, rather than GIST, but the idea is basically the same. I've added a note to issue 45. http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-qos-nslp-issues/issue45 > Issue 11) Section 5.1.3 "Object Formats": > I am not sure, if the semantics of AB=11 are really wise. One the one hand, I > am not exactly sure, why you would want such a behavior. On the other hand, I > am absolutely not sure, if there aren't any security implications. By placing > the AB=11 flag, you can trick any node to send an opaque object with every > message it sends for that session. The idea for this original came up when we were looking at the extensibility considerations for the NTLP (i.e. what became GIST). However, it was then removed from there since it didn't make sense in the context of GIST's per-hop applicability. I think that some form of 'policy data' (authorization tokens, etc) has been suggested as one extension that might make use of this. I don't think the security issue is as bad as it might first sound, since it is only those nodes that are accepting the reservation (and hence agreeing to do somewhat more than forward/repeat a lump of opaque data) that have to worry about this. I'd be interested to see any other comments on this. > Issue 12) Small editorial stuff in Intoduction: > "Section then clarifies the protocol by means of a number of > examples in Section 4." is broken. > "The subsequent sections describe AINA allocation issues, and > security considerations." You mean IANA? Added as issue 108. http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-qos-nslp-issues/issue108 > Issue 13) > Section 3.3: Again, editorial: "Currently, the QoS NSLP > specification considers mainly the coupled MRM." > There is an "path-" missing. Added as issue 109. http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-qos-nslp-issues/issue109 thanks, Andrew _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Aug 28 13:40:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHl59-0001FI-He; Mon, 28 Aug 2006 13:39:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHl58-0001F6-8G for nsis@ietf.org; Mon, 28 Aug 2006 13:39:30 -0400 Received: from py-out-1112.google.com ([64.233.166.180]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GHl55-0003g8-Ul for nsis@ietf.org; Mon, 28 Aug 2006 13:39:30 -0400 Received: by py-out-1112.google.com with SMTP id e30so1042489pya for ; Mon, 28 Aug 2006 10:39:27 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:mime-version:content-type:x-google-sender-auth; b=PhiDrLzFnI4RCFEcnS5QQL+JVF7rcO5AmC30N7TWDjxHIHvL+fM8t3y616FfSWoFvdb00FQU10vPgtzPV2PSx0SI1YjeTtzCIAB8/taLIj/HL/9+rMoBkJpmYa0+6ikNuxemxP4QIqQvxHRM4N24cvmwVCcNqbh8d1d1mVVpRqc= Received: by 10.35.8.1 with SMTP id l1mr12914131pyi; Mon, 28 Aug 2006 10:37:49 -0700 (PDT) Received: by 10.35.31.16 with HTTP; Mon, 28 Aug 2006 10:37:49 -0700 (PDT) Message-ID: <951128250608281037w7d34ffc9p4d460f75827814d@mail.gmail.com> Date: Mon, 28 Aug 2006 17:37:49 +0000 From: "=?ISO-8859-1?Q?Rui_Vil=E3o?=" To: nsis@ietf.org MIME-Version: 1.0 X-Google-Sender-Auth: ce2c687d0383e530 X-Spam-Score: 0.2 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Subject: [NSIS] Responses to TRACE messages X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1426874635==" Errors-To: nsis-bounces@ietf.org --===============1426874635== Content-Type: multipart/alternative; boundary="----=_Part_241156_8115357.1156786669167" ------=_Part_241156_8115357.1156786669167 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi all, I'm having doubts when generating a RESPONSE to TRACE messages. In section 3.7.6 we can find several times that we have to send a RESPONSE message, bu= t when we read section 4.3.3, we can find "RESPONSE messages are responses to CREATE and REA messages.". So what to do when processing a TRACE message? Best regards, Rui Vil=E3o ------=_Part_241156_8115357.1156786669167 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi all,

I'm having doubts when generating a RESPONSE to TRACE messag= es. In section 3.7.6 we can find several times that we have to send a RESPO= NSE message, but when we read section 4.3.3, we can find "RESPONSE mes= sages are responses to CREATE and REA messages.". So what to do when p= rocessing a TRACE message?

Best regards,

Rui Vil=E3o
------=_Part_241156_8115357.1156786669167-- --===============1426874635== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis --===============1426874635==-- From nsis-bounces@ietf.org Mon Aug 28 14:41:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHm23-0007RE-Va; Mon, 28 Aug 2006 14:40:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHm21-0007ML-RB for nsis@ietf.org; Mon, 28 Aug 2006 14:40:21 -0400 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GHm20-0006Iz-CZ for nsis@ietf.org; Mon, 28 Aug 2006 14:40:21 -0400 Received: (qmail invoked by alias); 28 Aug 2006 18:40:19 -0000 Received: from p54984D01.dip.t-dialin.net (EHLO [192.168.2.33]) [84.152.77.1] by mail.gmx.net (mp017) with SMTP; 28 Aug 2006 20:40:19 +0200 X-Authenticated: #29516787 Message-ID: <44F33896.80005@gmx.net> Date: Mon, 28 Aug 2006 20:40:22 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: =?ISO-8859-1?Q?Rui_Vil=E3o?= Subject: Re: [NSIS] Responses to TRACE messages References: <951128250608281037w7d34ffc9p4d460f75827814d@mail.gmail.com> In-Reply-To: <951128250608281037w7d34ffc9p4d460f75827814d@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.1 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Rui, we are currently in the process to update the specification based on the received comments. A number of comments targeted the TRACE functionality and we added an issue to the issue tracker, see: https://kobe.netlab.nec.de/roundup/nsis-natfw-nslp/issue77 https://kobe.netlab.nec.de/roundup/nsis-natfw-nslp/issue73 We will post a mail to the list once we have a detailed proposal. We would appreciate your input. Ciao Hannes Rui Vilão schrieb: > Hi all, > > I'm having doubts when generating a RESPONSE to TRACE messages. In > section 3.7.6 we can find several times that we have to send a RESPONSE > message, but when we read section 4.3.3, we can find "RESPONSE messages > are responses to CREATE and REA messages.". So what to do when > processing a TRACE message? > > Best regards, > > Rui Vilão > > > ------------------------------------------------------------------------ > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Aug 29 04:46:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHzE8-0008E3-Rn; Tue, 29 Aug 2006 04:45:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHzE7-0008Du-Mp for nsis@ietf.org; Tue, 29 Aug 2006 04:45:43 -0400 Received: from moutng.kundenserver.de ([212.227.126.186]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GHzE6-0007N5-8b for nsis@ietf.org; Tue, 29 Aug 2006 04:45:43 -0400 Received: from [84.163.64.140] (helo=alanis.mafr.de) by mrelayeu.kundenserver.de (node=mrelayeu4) with ESMTP (Nemesis), id 0ML21M-1GHzDn3Tye-0002en; Tue, 29 Aug 2006 10:45:34 +0200 Received: by alanis.mafr.de (Postfix, from userid 1000) id 3D3F15E8384; Tue, 29 Aug 2006 10:45:11 +0200 (CEST) Date: Tue, 29 Aug 2006 10:45:11 +0200 From: Matthias Friedrich To: nsis@ietf.org Message-ID: <20060829084511.GA27113@mafr.de> Mail-Followup-To: nsis@ietf.org, stiemerling@netlab.nec.de, Hannes.Tschofenig@gmx.net MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.11 X-Provags-ID: kundenserver.de abuse@kundenserver.de login:b369618fd1a3462119ba5a921f6f235b X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: stiemerling@netlab.nec.de Subject: [NSIS] NATFW: some minor, non-technical issues X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi, I'd like to post my list of collected nitpicks (mostly spelling) before I lose the file once again. The section numbers have been updated to draft version -12. * Section 3.2.3., first paragraph "consists" seems to be superfluous here * Section 3.7.5., item "NSLP responder" "The _NF_ should never receive NOTIFY messages ..." -> should be NR * Section 3.7.6., second paragraph "The processing when receiving a TRACE message is _the_ different for ..." * Section 3.7.7., last paragraph "... by setting the P flag in the NSLP header _is set_ to P=1 ..." * Section 3.7.7.1., first paragraph "In this case, _a_ NR can signal ..." -> an * Section 3.7.7.1., second paragraph "The absence of _an_ NONCE object ..." -> a * Section 3.7.7.2., last paragraph "Any device beyond this point will never _received_ ..." -> receive * Section 5.1.1., first paragraph "_An_ addition to authentication the nodes will ..." -> In addition? * Section 5.1.2., first paragraph "In such a scenario, _a_ the previously discussed ..." * Section 5.1.3., first paragraph "In many cases the signaling message initiator might already aware of ... " -> already _be_ aware * Section 5.2.4., first sentence I don't get it. Also, what does the "(*)" mean? * Section 5.2.4., third paragraph "The data _sender_ might want to update the NAT binding ..." Shouldn't this be the receiver? * Section 5.2.4., last paragraph "The DR MUST be able to specify which data _sender_ are allowed to traverse the NAT in order to be forwarded to _DRs_ address." -> plural, DR's * Section 5.2.5., third paragraph "By injecting a bogus _responses_ or NOTIFY message, for instance, _timeout_, a malicious host could try to teardown NATFW NSLP session state as well." -> "responses"? And what is meant by "timeout" here? * Section 5.3.1.3., last paragraph "A NATFW NSLP node MUST be configurable to block unauthorized signaling _message_." -> plural * Section 5.4., last paragraph There is no "firewall FW" in figure 42. * Section 5.11.1., first paragraph I'd remove the "provide" after the colon. * Section 5.11.1., last paragraph "Hencem" Regards, Matthias _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Aug 29 09:51:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GI3yz-0001VP-5J; Tue, 29 Aug 2006 09:50:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GI3yy-0001Tz-Ew for nsis@ietf.org; Tue, 29 Aug 2006 09:50:24 -0400 Received: from moutng.kundenserver.de ([212.227.126.188]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GI3yx-0006YJ-3e for nsis@ietf.org; Tue, 29 Aug 2006 09:50:24 -0400 Received: from [84.163.42.222] (helo=alanis.mafr.de) by mrelayeu.kundenserver.de (node=mrelayeu6) with ESMTP (Nemesis), id 0ML29c-1GI3yl0yYa-0008Rk; Tue, 29 Aug 2006 15:50:11 +0200 Received: by alanis.mafr.de (Postfix, from userid 1000) id E00C65E809B; Tue, 29 Aug 2006 15:49:50 +0200 (CEST) Date: Tue, 29 Aug 2006 15:49:50 +0200 From: Matthias Friedrich To: nsis@ietf.org Message-ID: <20060829134950.GA4517@mafr.de> Mail-Followup-To: nsis@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.11 X-Provags-ID: kundenserver.de abuse@kundenserver.de login:b369618fd1a3462119ba5a921f6f235b X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Subject: [NSIS] NATFW: NATFW_CREDENTIAL vs. AUTH_SESSION object X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi, I'm wondering what the relationship between the NATFW_CREDENTIAL object and the AUTH_SESSION object from the new "Authorization for NSIS Signaling Layer Protocols" draft is. Will the NATFW_CREDENTIAL object be removed in the next draft revision or is there use for both that I currently don't see? According to the IANA considerations section, the AUTH_SESSION object's ID is taken from the GIST object value space, so this could be the difference. But on the other hand, that's a contradiction to the last paragraph of section two: | This document describes a generic NSLP layer session authorization | policy object (AUTH_SESSION) used to convey authorization | information for the request. Could someone please clarify this? Thanks, Matthias _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Aug 29 15:30:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GI9Hf-000357-St; Tue, 29 Aug 2006 15:30:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GI9He-000352-Gd for nsis@ietf.org; Tue, 29 Aug 2006 15:30:02 -0400 Received: from courier.cs.helsinki.fi ([128.214.9.1] helo=mail.cs.helsinki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GI9Hc-0004i2-5l for nsis@ietf.org; Tue, 29 Aug 2006 15:30:02 -0400 Received: from sbz-31.cs.helsinki.fi (sbz-31.cs.helsinki.fi [128.214.9.99]) (TLS: TLSv1/SSLv3,256bits,AES256-SHA) by mail.cs.helsinki.fi with esmtp; Tue, 29 Aug 2006 22:24:54 +0300 id 0007C053.44F49486.00007C3E Date: Tue, 29 Aug 2006 22:24:53 +0300 (EEST) From: Jukka MJ Manner To: Matthias Friedrich Subject: Re: [NSIS] NATFW: NATFW_CREDENTIAL vs. AUTH_SESSION object In-Reply-To: <20060829134950.GA4517@mafr.de> Message-ID: References: <20060829134950.GA4517@mafr.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi, The NAT/FW CREDENTIAL object will disappear in favor of the AUTH_SESSION. The AUTH_SESSION draft has misleading info about the object type allocation. It will be fixed in a future version of the spec. Jukka On Tue, 29 Aug 2006, Matthias Friedrich wrote: > Hi, > > I'm wondering what the relationship between the NATFW_CREDENTIAL object > and the AUTH_SESSION object from the new "Authorization for NSIS > Signaling Layer Protocols" draft is. Will the NATFW_CREDENTIAL object > be removed in the next draft revision or is there use for both that I > currently don't see? > > According to the IANA considerations section, the AUTH_SESSION object's > ID is taken from the GIST object value space, so this could be the > difference. But on the other hand, that's a contradiction to the last > paragraph of section two: > > | This document describes a generic NSLP layer session authorization > | policy object (AUTH_SESSION) used to convey authorization > | information for the request. > > Could someone please clarify this? > > Thanks, > Matthias > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Aug 30 07:32:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIOIi-0004ZC-Tc; Wed, 30 Aug 2006 07:32:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIOIh-0004Wm-Vl for nsis@ietf.org; Wed, 30 Aug 2006 07:32:07 -0400 Received: from rsys002x.roke.co.uk ([193.118.201.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIO50-00078h-O8 for nsis@ietf.org; Wed, 30 Aug 2006 07:18:00 -0400 Received: from rsys005a.comm.ad.roke.co.uk (rsys005a [193.118.193.85]) by rsys002x.roke.co.uk (8.13.1/8.13.1) with ESMTP id k7UBHdrJ008698; Wed, 30 Aug 2006 12:17:43 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] Loose-End MRM Direction Date: Wed, 30 Aug 2006 12:17:39 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] Loose-End MRM Direction Thread-Index: AcbFJZN8EFK8zKTVRFWDqbeJzeqtigG/+6wg From: "Hancock, Robert" To: "Roland Bless" X-MailScanner-roke-co-uk: Found to be clean X-MailScanner-roke-co-uk-SpamCheck: X-MailScanner-From: robert.hancock@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org hi roland, > -----Original Message----- > From: Roland Bless [mailto:bless@tm.uka.de]=20 > Sent: 21 August 2006 14:27 > To: Hancock, Robert > Cc: nsis@ietf.org > Subject: Re: [NSIS] Loose-End MRM Direction >=20 >=20 > Hi Robert, >=20 > [sorry for the delay, I was on a short vacation] >=20 > > there is no mystery here, it is just my screwup. Magnus' > > review highlighted the earlier text as being unclear and > > I tried to make it clearer; what I missed was that the > > earlier text was wrong and I just made it clearly wrong. > > The intent that *for Query encapsulated messages* only D=3D0 > > is allowed. I'll add that in the next version. > >=20 > > see also > > http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-ntlp-issues/issue115 >=20 > D flag: The direction flag. Note that for Q-mode messages, the only > valid value is D=3D0 (see Section 5.8.2). >=20 > This actually makes more sense. So it's ok to invert the > flag in the RESPONSE. >=20 > On the other hand it's somehow still confusing: > if one takes the original definition > of upstream/downstream signaling into account, it would > be *upstream* not downstream. At least if one follows > the definitions and scenarios in the NAT/FW draft, > because the GIST node that sends a query message containing > the LE MRM is actually the data receiver. Thus, the signaling > direction is upstream in this case?! it may be that we should have abandoned the terms upstream and downstream altogether. however, i think for the GIST specification the usage is OK; GIST is not aware of the semantics of the messages being carried over it, and one could equally imagine other NSLPs wanting to discover the edge of the local network for other reasons. r. >=20 > Regards, > Roland >=20 >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Aug 31 11:20:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIoKS-0001zJ-Np; Thu, 31 Aug 2006 11:19:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIoKR-0001zE-Kf for nsis@ietf.org; Thu, 31 Aug 2006 11:19:39 -0400 Received: from denhaag.ewi.utwente.nl ([130.89.10.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIoKR-00083h-4U for nsis@ietf.org; Thu, 31 Aug 2006 11:19:39 -0400 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by denhaag.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id k7VFIe3c009315; Thu, 31 Aug 2006 17:18:48 +0200 (MEST) From: "Georgios Karagiannis" To: "'Hancock, Robert'" , "'Ash, Gerald R \(Jerry\), ALABS'" , Subject: RE: [NSIS] QSPEC Issue #3 -- Allowing a QSPEC-1 Parameter to beIgnored Date: Thu, 31 Aug 2006 17:18:36 +0200 Message-ID: <001501c6cd10$c0860fe0$4c0d5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: Aca/6wl1mien3kJ5R0u2kXlkJtiCmAIP4e+wAAWS8CAAAoy9AAExUSgg In-Reply-To: X-Spam-Score: -5.531 () ALL_TRUSTED,AWL,BAYES_00,FVGT_s_OBFU_Q1 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0b5 (denhaag.ewi.utwente.nl [130.89.10.11]); Thu, 31 Aug 2006 17:18:50 +0200 (MEST) X-Spam-Score: 0.0 (/) X-Scan-Signature: 48472a944c87678fcfe8db15ffecdfff Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Robert Are you in favour on allowing to ignore QSPEC-1 parameters? Best regards, Georgios -----Original Message----- From: Hancock, Robert [mailto:robert.hancock@roke.co.uk] Sent: vrijdag 25 augustus 2006 15:39 To: Ash, Gerald R (Jerry), ALABS; Georgios Karagiannis; nsis@ietf.org Subject: RE: [NSIS] QSPEC Issue #3 -- Allowing a QSPEC-1 Parameter to beIgnored hi, on the question of whether a type 1 parameter can be ignored: i agree that making this change reduces the distinction within the protocol operation between type 1 and type 2 parameters. however, i don't think we should lose sight of the fact that there can still be a difference which applies during the specfication process. namely, that when a QoS model is reviewed, if it defines something a bit like a type 1 parameter but not identical to it, and/or refuses to say how a type 1 parameter should be handled when there is a clear way to do so, then this would be grounds for preventing it being approved as a specification. (at least, that i my interpretation of the proposal.) so, it is a weaker distinction, but still valuable. cheers, robert h. > -----Original Message----- > From: Ash, Gerald R (Jerry), ALABS [mailto:gash@att.com] > Sent: 25 August 2006 13:27 > To: Georgios Karagiannis; nsis@ietf.org > Cc: Ash, Gerald R (Jerry), ALABS > Subject: RE: [NSIS] QSPEC Issue #3 -- Allowing a QSPEC-1 Parameter to > beIgnored > > > Hi Georgios, > > See comments below. > > > -----Original Message----- > > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > > Sent: Friday, August 25, 2006 5:45 AM > > To: Ash, Gerald R (Jerry), ALABS; nsis@ietf.org > > Subject: RE: [NSIS] QSPEC Issue #3 -- Allowing a QSPEC-1 Parameter > > to be Ignored > > > > Hi Jerry > > > > The below comments are coupled to my comments on QSPEC Issue #1: > > I am in favour of having the possibility to ignore QSPEC-1 > > parameters. > > The reasons are identical to the ones I mentioned in my comments on > > Issue #1 > > > > > > The reasons are: > > > > * Excess treatment parameter. > > It should be possible to ignore this parameter in certain domains. > > For example, when a Diffserv domain is using PCN or RMD it should be > > able to ignore this parameter. > > The reason of this is that the way of how the remarking or the > > dropping of packets is influencing e.g., the PCN or RMD solution. > > Therefore, it > should be > > possible that the > > QNEs that are located in such regions to ignore this parameter. > > > > * QoS class: > > It should be possible for some QNEs to ignore this parameter. > > E.g., problematic when: > > * a non Diffserv aware QNE receives a PHB class parameter > > * a non Y.1541 aware QNE receives a Y.1541 class parameter > > * a non MPLS aware QNE receives a DSTE class parameter. > > In such situations such QNEs should be able to ignore this > parameter. > > > > * Priority > > You already mentioned some reasons on why it should be possible to > > ignore this parameter. > > > > Thus if we allow to ignore QSPEC-1 parameters, then I can agree on > > having 4 QSPEC-1 parameters. > > As stated below, allowing to ignore QSPEC-1 parameters would pretty > much do away with the distinction between QSPEC-1 and QSPEC-2 > parameters. > > Thanks, > Jerry > > > > > Best regards, > > Georgios > > > > -----Original Message----- > > From: Ash, Gerald R (Jerry), ALABS [mailto:gash@att.com] > > Sent: maandag 14 augustus 2006 23:46 > > To: nsis@ietf.org > > Cc: Ash, Gerald R (Jerry), ALABS > > Subject: [NSIS] QSPEC Issue #3 -- Allowing a QSPEC-1 Parameter to be > > Ignored > > > > Hi All, > > > > One of the issues identified in the updated 'QoS NSLP QSPEC > Template' > > I-D > > > http://www.ietf.org/internet-drafts/draft-ietf-nsis-qspec-11.txt is as > > follows: > > > > 3. agreement/consensus on whether to allow a QSPEC-1 > (formerly called > > "mandatory") parameter to be ignored; see Section 4.3.1 > > > > There was extensive discussion on the list RE whether to allow a > > QSPEC-1 parameter to be ignored, as is allowed for a QSPEC-2 > (formerly called > > "optional") parameter. Reasons given for allowing this are > > a) use of a > > QSPEC-1 parameter might be illegal, as with preemption in the U.S. > > PSTN, and > > b) a particular QOSM might not want to support certain > > QSPEC-1 parameters, > > i.e., while it would be nice for all QOSMs to support > Class>, some have suggested that might not be practical/realistic. > > > > Note that this issue is related to Issue #1, that is, if we > retain the > > QSPEC-1 parameter concept, then allowing a QSPEC-1 parameter to be > > ignored is a step toward doing away with the distinction between > > QSPEC-1 and QSPEC-2 > > parameters. It is also related to Issue #2 in that an > alternative to > > "strict interpretation" of QSPEC-1 parameters is remapping these > > parameters. > > However, in some cases remapping QSPEC-1 parameters between classes > > of QSPEC parameters may not make sense, e.g., mapping to > > . > > > > The default resolution is that the QSPEC-1 concept is retained and > > that all > > QSPEC-1 parameters must be strictly interpreted or remapped by all > > QOSMs. > > Alternatively, it is suggested in Section 4.3.1 that if ignoring a > > QSPEC-1 parameter is to be allowed, that a high threshold be placed > > on justification for this in the QOSM specification document: > > "a QOSM may simply not want to support a QSPEC-1 parameter. > > In (that) case > > justification may be more difficult, however there is a filter on > > reasonableness in that QOSM specifications must be reviewed and > > approved by the IETF." > > > > Please express any further comments in support of the proposed > > resolution, or otherwise, so that we may reach consensus on this > > issue. > > > > Thanks, > > Regards, > > Jerry > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Aug 31 15:51:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIsYT-0001Uc-9V; Thu, 31 Aug 2006 15:50:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIsY6-0000ih-Sl; Thu, 31 Aug 2006 15:50:02 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIsY6-0001t1-H7; Thu, 31 Aug 2006 15:50:02 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 7813C26E39; Thu, 31 Aug 2006 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GIsY6-0007i7-Bf; Thu, 31 Aug 2006 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 31 Aug 2006 15:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: nsis@ietf.org Subject: [NSIS] I-D ACTION:draft-ietf-nsis-ntlp-11.txt X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org --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 : GIST: General Internet Signaling Transport Author(s) : H. Schulzrinne, R. Hancock Filename : draft-ietf-nsis-ntlp-11.txt Pages : 144 Date : 2006-8-31 This document specifies protocol stacks for the routing and transport of per-flow signaling messages along the path taken by that flow through the network. The design uses existing transport and security protocols under a common messaging layer, the General Internet Signaling Transport (GIST), which provides a universal service for diverse signaling applications. GIST does not handle signaling application state itself, but manages its own internal state and the configuration of the underlying transport and security protocols to enable the transfer of messages in both directions along the flow path. The combination of GIST and the lower layer transport and security protocols provides a solution for the base protocol component of the "Next Steps in Signaling" framework. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nsis-ntlp-11.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-ntlp-11.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-ntlp-11.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: <2006-8-31105824.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nsis-ntlp-11.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nsis-ntlp-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-8-31105824.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis --NextPart--