From nsis-bounces@ietf.org Mon Jul 02 08:55:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5LQl-00050M-31; Mon, 02 Jul 2007 08:55:03 -0400 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1I3Hsx-0006Oa-GQ for nsis-confirm+ok@megatron.ietf.org; Tue, 26 Jun 2007 16:43:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3Hsx-0006OS-6v for nsis@ietf.org; Tue, 26 Jun 2007 16:43:39 -0400 Received: from goliath.siemens.de ([192.35.17.28]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3HsF-0004l8-7R for nsis@ietf.org; Tue, 26 Jun 2007 16:43:39 -0400 Received: from mail2.siemens.de (localhost [127.0.0.1]) by goliath.siemens.de (8.12.6/8.12.6) with ESMTP id l5QKgsjx025417 for ; Tue, 26 Jun 2007 22:42:54 +0200 Received: from mchp771a.ww002.siemens.net (mchp771a.ww002.siemens.net [139.25.131.189]) by mail2.siemens.de (8.12.6/8.12.6) with ESMTP id l5QKgs9h030924 for ; Tue, 26 Jun 2007 22:42:54 +0200 Received: from MCHP7R6A.ww002.siemens.net ([139.25.131.164]) by mchp771a.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 Jun 2007 22:42:54 +0200 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] WGLC:draft-ietf-nsis-qos-nslp-14.txt Date: Tue, 26 Jun 2007 22:42:52 +0200 Message-ID: <662C3EB2067DD64FBB2CDA77CD2B1A5601D758B9@MCHP7R6A.ww002.siemens.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] WGLC:draft-ietf-nsis-qos-nslp-14.txt Thread-Index: Ace375U6bCF2rcn7T/qPbAOyjEIsDwABedIwAAEbbFAACKMaQA== References: <071568CA7B789D4AA170CEF8C9613B4FB11B80@daebe103.NOE.Nokia.com><468109B4.2070102@tm.uka.de><19EBBEC503C3B5469070E0A6674A533A39B060@daebe104.NOE.Nokia.com> From: "Ersue, Mehmet" To: X-OriginalArrivalTime: 26 Jun 2007 20:42:54.0098 (UTC) FILETIME=[92044F20:01C7B832] X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b X-Mailman-Approved-At: Mon, 02 Jul 2007 08:55:02 -0400 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, just got through the QoS NSLP specification. It is readable and reasonably complete. I can second Roberts statement not to put everything into one document. Mehmet=20 =20 > -----Original Message----- > From: Hancock, Robert [mailto:robert.hancock@roke.co.uk]=20 > Sent: Tuesday, June 26, 2007 3:59 PM > To: john.loughney@nokia.com; bless@tm.uka.de;=20 > stiemerling@netlab.nec.de > Cc: nsis@ietf.org > Subject: RE: [NSIS] WGLC:draft-ietf-nsis-qos-nslp-14.txt >=20 > hi all, >=20 > i've read the draft. basically i think it is ready to ship. > we could all certainly think of things to add, but I think actually > as a core protocol it has the right balance between completeness > and conciseness; AFAICT anything i'd like to add can be done as > an extension (which is probably a good approach anyway). >=20 > cheers, >=20 > robert h.=20 >=20 > > -----Original Message----- > > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com]=20 > > Sent: 26 June 2007 14:26 > > To: bless@tm.uka.de; stiemerling@netlab.nec.de > > Cc: nsis@ietf.org > > Subject: RE: [NSIS] WGLC:draft-ietf-nsis-qos-nslp-14.txt > >=20 > > That's OK. =20 > >=20 > > Anyone else who is still reading the draft? > >=20 > > John=20 > >=20 > > >-----Original Message----- > > >From: ext Roland Bless [mailto:bless@tm.uka.de] > > >Sent: 26 June, 2007 05:42 > > >To: Martin Stiemerling > > >Cc: nsis > > >Subject: Re: [NSIS] WGLC:draft-ietf-nsis-qos-nslp-14.txt > > > > > >Hi, > > > > > >Martin Stiemerling wrote: > > >> [writing chair's hat off] > > >> I have read the draft and think it is ready to take the=20 > next steps. > > > > > >I'm still reading the draft completely and will provide=20 > > comments ASAP=20 > > >(scheduled for tomorrow). Sorry for not being able to make=20 > it in the=20 > > >WGLC time frame... > > > > > >Regards, > > > Roland > > > > > > > > >_______________________________________________ > > >nsis mailing list > > >nsis@ietf.org > > >https://www1.ietf.org/mailman/listinfo/nsis > > > > >=20 > >=20 > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > >=20 >=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 Tue Jul 03 05:30:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5eio-0000b3-H9; Tue, 03 Jul 2007 05:30:58 -0400 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1I5eil-0000Hh-At for nsis-confirm+ok@megatron.ietf.org; Tue, 03 Jul 2007 05:30:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5eik-0000FF-JC for nsis@ietf.org; Tue, 03 Jul 2007 05:30:54 -0400 Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I5eiR-0004mh-7G for nsis@ietf.org; Tue, 03 Jul 2007 05:30:54 -0400 Received: from i72ms.tm.uni-karlsruhe.de ([141.3.70.5] helo=smtp.ipv6.tm.uni-karlsruhe.de) by iramx2.ira.uni-karlsruhe.de with esmtps id 1I5eiN-0003mn-44; Tue, 03 Jul 2007 11:30:33 +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 EA4AD2FC015; Tue, 3 Jul 2007 11:30:30 +0200 (CEST) Received: from localhost ([127.0.0.1]) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.44) id 1I5eiL-0007gd-Vs; Tue, 03 Jul 2007 11:30:30 +0200 Message-ID: <468A1735.7070408@tm.uka.de> Date: Tue, 03 Jul 2007 11:30:29 +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: Jukka MJ Manner , Andrew McDonald , Georgios Karagiannis , nsis-chairs@tools.ietf.org Subject: Re: [NSIS] Reminder WGLC:draft-ietf-nsis-qos-nslp-14.txt References: <071568CA7B789D4AA170CEF8C9613B4FB11B80@daebe103.NOE.Nokia.com> <892AE2E7-643F-492D-8695-609C87BE7DC4@netlab.nec.de> In-Reply-To: <892AE2E7-643F-492D-8695-609C87BE7DC4@netlab.nec.de> X-Enigmail-Version: 0.94.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Status: No X-Spam-Score: -1.4 (-) X-Spam-Report: -1.4 ALL_TRUSTED Passed through trusted hosts only via SMTP 0.1 AWL AWL: From: address is in the auto white-list X-ATIS-Checksum: v3zoCAcc32ckk X-Spam-Score: 0.0 (/) X-Scan-Signature: a3f7094ccc62748c06b21fcf44c073ee Cc: nsis X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi all, Martin Stiemerling wrote: > Just to remind you about the currently running WGLC for the QoS NSLP. > A simple mail saying that the draft is ready for publication would be great. I reread the whole draft (sorry for being late, but several other activities interrupted me) and have some minor comments only. So I would say that's it's ready for IESG review after the next update. The most important things first: =================================================================== * Section 4.3: Refreshing receiver-initiated reservations... "are set up. The reservation can subsequently be refreshed with RESERVE messages in the same way as for the sender-initiated approach." Is a little bit to vague for me. Are the refreshing RESERVE messages now sent downstream? I guess so because otherwise re-routing detection would not work. So it should be made clear that the RESERVE messages are only sent in reverse direction for the initial state installation, but that the refreshing RESERVE messages are sent as usually in flow direction. * Section 4.5: there seem to be remnants stacking concept which was removed: RESERVE message to be sent out is constructed mostly as usual but with a second QSPEC object added on top, which becomes the 'current' one. as well as A message can contain at most two QSPEC objects, i.e., the end-to-end QSPEC and a local QSPEC. Probably this could replaced by something like: The local QoS model (QoSM2) can define its own local QSPEC that also contains the original QSPEC from QoSM1. * Section 5.1.2.1 RESERVE Q-Flag: REQUEST REDUCED REFRESHES (Q) - when set, indicates the sender of the RESERVE proposes to use the reduced refresh for this session. I really don't know what this should be good for (or maybe I forgot). IMHO this is not necessary, because the QNE can simply try to sent a reduced refresh. If this cannot be supported by the peer, it will answer with * 0x03 - Reduced refreshes not supported, full QSPEC required. In this case the QNE should continue to always send full refreshes to this peer. I also don't see any description in the draft of what should happen according to this bit. So I don't think that the flag is useful and I am in favor of removing it. * TEARing RESERVE in which direction and REPLACE flag. As far as I understood, it should be possible for a node to remove reservations at the old branch explicitly. This is at least what I read from 5.1.4: The default behavior of a QNE that receives a RESERVE with a SESSION_ID for which it already has state installed but with a different flow ID is to replace the existing reservation (and tear down the reservation on the old branch if the RESERVE is received with a different SII). I'm a little bit confused which node will tear down the reservation on the old branch. Sometimes we have a node where the routes diverge and sometimes we have a node where route converge and sometimes we have both. In the above description: if a QNE receives a RESERVE with a different SII it's obviously a node where routes converge again. Otherwise it would be a QNE sending a RESERVE along a new SII (this would be indicated by GIST). So a more concrete example: +-+ /--|B|--\ / +-+ \ +-+ +-+ ----|A| |D|---- +-+ +-+ \ +-+ / \--|C|--/ +-+ Let's assume that the MRI is unchanged. Flow is A->B->D at first. After re-routing happens the new route is A->C->D. It would make sense that node A will try to remove the old branch, so it may send a RESERVE w/ TEAR along the old path. D will not forward the tearing RESERVE, because it knows, that the TEAR came along the old branch. But would it be also possible for node D to send a tearing reserve in the reverse direction (upstream)? This is current not allowed by 5.1.4: "RESERVE messages MUST only be sent towards the QNR." The signaling mobility draft has an example where node D sends a tearing reserve in reverse direction. The situation there is different since there is no branching A; it can be considered as the MN moving between ARs B and C. In this case only D can send the tearing RESERVE. So if it is allowed for D to send a tearing RESERVE, how would it be coordinated with the branching node A? ============================================== Now the minor stuff: * Introduction: e.g., edge-to-edge, end-to-access, etc. On the other hand, there is no support for IP multicast. The GIST draft mentions that multicast support may be added later and I'll like to see something similar in here. Probably adding the word "currently" is enough: there is currently no support for IP multicast. * p. 12: All QSPECs must follow the QSPEC template [I-D.ietf-nsis-qspec]. I'm not sure whether a must is too strong here. Local QSPECs may be different from the e2e-QSPEC. Probably this one is better: All QSPECs should follow the design of the QSPEC template. * p. 13: change "may cause removal of an earlier reservation." into "may cause removal of an earlier admitted reservation." (or "established" if you like). * p. 26: 3.3.5 this difference can set the "B" (BREAK) flag. What means can here? better use may or should? * P. 37: Sec. 4.7 - probably we need to mention that retransmissions can only be expected if an RII was set. - it's not clear that it's better to use a MsgIDWait timeout longer than the retransmission timer. We may change that. * p.39: Sec 4.8.1 It should be mentioned that the message binding can be used to synchronize the messages. * p. 45: 5.1.2.1 A "reservation collision" may occur if the sender believes that a It is not clear to me how such a collision would occur. What would be the reason for such a collision. Could you give an example? * p. 46: 5.1.2.1 resulting refresh is a new RESERVE. This RESERVE includes a new MRI and will be propagated end-to-end without requesting a RESPONSE. It is meant that "will be propagated end-to-end _even_ without requesting a RESPONSE." But additionally it may also include an RII, so I would suggest to rephrase it as it may sound that an RII must not be included. * p. 5.1.3.7/5.1.3.8: As I got feedback from our implementer: it would be easier to parse if we had also a combined list of SID/RSN tuples. ============================================== Typos: p.12: missing closing parenthesis: flag in the common header). ^ additional blank line (as in several places in the doc, please check): requested will usually contain objects which need to be understood by all implementations, and it can also be enhanced with additional p.13: period missing or incomplete sentence? "Authentication may be required." The authorization of a resource request often depends on the identity of the entity making the request. Authentication may be required The p.22: 3.2.12.1 "D. The signaling path initially ends at C, but this node is not on" must be change to: "D. The signaling path initially ends at B, but this node is not on" p.23: 3.2.12.2 "its API to the NSLP with a NetworkNotification. The QoS NSLP at A will then attempt to repair the path by installing the reservation on the path'." There is no path' defined. Probably better use: installing the reservation on path (2),(3). p.24: Typo: This in the peer from which it was receiving RESERVE messages. s/in /is / p.27: [I-D.ietf-nsis-qspec]. For example, in a RMD-QOSM s/a /an / p. 29: "to GIST to be forwarded back down the path." back down may be confusing, because the direction is upstream. p. 29: s/prepated/prepared P. 36: Sec 4.7 Wrong reference to Figure 15 (two times) should be 14. p. 43: s/P -QNE/P-QNE p. 44: s/mesasages/messages p. 54: insert a CRLF before "o Protocol Error" p. 57: Object Value Info format is messed up. p. 79: s/decice/decide ------------------------------------------------------------------ Regards, Roland _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Jul 03 11:44:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5kYX-0002YM-PU; Tue, 03 Jul 2007 11:44:45 -0400 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1I5kYV-0002YE-TC for nsis-confirm+ok@megatron.ietf.org; Tue, 03 Jul 2007 11:44:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5kYV-0002Y6-JT; Tue, 03 Jul 2007 11:44:43 -0400 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I5kXm-0007x6-Q0; Tue, 03 Jul 2007 11:44:43 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id F32A23290B; Tue, 3 Jul 2007 15:15:01 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1I5k5l-0007OH-S2; Tue, 03 Jul 2007 11:15:01 -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: Tue, 03 Jul 2007 11:15:01 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: nsis@ietf.org Subject: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-17.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-17.txt Pages : 55 Date : 2007-7-3 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 including a number of QSPEC parameters. The QSPEC parameters provide a common language to be re-used in several QOSMs and thereby aim to ensure the extensibility and interoperability of QoS NSLP. The node initiating the NSIS signaling adds an initiator QSPEC, which indicates the QSPEC parameters that must be interpreted by the downstream nodes less the reservation fails, 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-17.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-17.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-17.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: <2007-7-3101340.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nsis-qspec-17.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nsis-qspec-17.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-7-3101340.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 Wed Jul 04 22:10:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6Gnm-0001Xh-3V; Wed, 04 Jul 2007 22:10:38 -0400 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1I6Gnk-0001Xc-OK for nsis-confirm+ok@megatron.ietf.org; Wed, 04 Jul 2007 22:10:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6Gnk-0001XR-DK for nsis@ietf.org; Wed, 04 Jul 2007 22:10:36 -0400 Received: from smtp.mei.co.jp ([133.183.129.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6Gnf-0000eH-QL for nsis@ietf.org; Wed, 04 Jul 2007 22:10:36 -0400 Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/kings) with ESMTP id l652AUIl015546 for ; Thu, 5 Jul 2007 11:10:30 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx1) with ESMTP id l652AU918596 for ; Thu, 5 Jul 2007 11:10:30 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/expos) with ESMTP id l652ASZ22233 for ; Thu, 5 Jul 2007 11:10:29 +0900 (JST) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Thu, 5 Jul 2007 10:10:09 +0800 Message-ID: <5F09D220B62F79418461A978CA0921BD01E12CB2@pslexc01.psl.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Tearing direction in Mobility Applicability I-D Thread-Index: Ace9VN953hyktU87RGiWuXZaR8OKPQBVE8Hw From: "Shivanajay Marwaha" To: "nsis" X-Spam-Score: 0.1 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Subject: [NSIS] Tearing direction in Mobility Applicability I-D X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Dear all, I have the following comment on section 4 of Mobility Applicability Draft:- Direction of teardown in Figure 1 should be made compliant with NSLP I-D. In Fig. 1, RESERVE (T) (message no. 9) is sent from CRN towards QNI, as opposed to as indicated in the NSLP I-D: "RESERVE messages MUST only be sent towards the QNR" (Section 5.4.1, para 2). This has also been pointed out by Roland in his QoS NSLP I-D comment. Cheers, Shiv _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Jul 04 22:11:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6GoX-0002Um-Lt; Wed, 04 Jul 2007 22:11:25 -0400 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1I6GoV-0002TY-Tc for nsis-confirm+ok@megatron.ietf.org; Wed, 04 Jul 2007 22:11:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6GoV-0002TQ-K0 for nsis@ietf.org; Wed, 04 Jul 2007 22:11:23 -0400 Received: from smtp.mei.co.jp ([133.183.129.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6GoR-0000rl-18 for nsis@ietf.org; Wed, 04 Jul 2007 22:11:23 -0400 Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/kings) with ESMTP id l652BIvg016441 for ; Thu, 5 Jul 2007 11:11:18 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx2) with ESMTP id l652BIX06322 for ; Thu, 5 Jul 2007 11:11:18 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/bluejays) with ESMTP id l652BFi07838 for ; Thu, 5 Jul 2007 11:11:16 +0900 (JST) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Thu, 5 Jul 2007 10:10:58 +0800 Message-ID: <5F09D220B62F79418461A978CA0921BD01E12CB3@pslexc01.psl.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comment on MIP Interaction section of Mobility I-D Thread-Index: Ace+qbpoDwfuSoxERQqH3sUOScEaLw== From: "Shivanajay Marwaha" To: X-Spam-Score: 0.1 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Subject: [NSIS] Comment on MIP Interaction section of Mobility I-D X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Dear all, My comment on MIP Interaction section (Section 5) of Mobility Applicability I-D:- MIP Interaction section needs to be cleaned up. For example figure 7 is incorrect, this figure shows a signaling sequence chart for "Receiver-Initiated QoS NSLP over Tunnel - Parallel Mode". However, in the figure the MN (Sender) is sending the RESERVE message.=20 Also, this section should illustrate how Tunnel I-D is applicable to MIP cases. Redundant MIP signaling scenarios in the NSIS Mobility I-D from NSIS Tunnel I-D should be removed. Cheers, Shiv _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Jul 05 03:36:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6LtI-0006aR-44; Thu, 05 Jul 2007 03:36:40 -0400 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1I6LtG-0006aG-GS for nsis-confirm+ok@megatron.ietf.org; Thu, 05 Jul 2007 03:36:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6LtC-0006Zs-Lu for nsis@ietf.org; Thu, 05 Jul 2007 03:36:34 -0400 Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6Lt8-0004Yq-2K for nsis@ietf.org; Thu, 05 Jul 2007 03:36:34 -0400 Received: from irams2.ira.uni-karlsruhe.de ([141.3.10.82]) by iramx2.ira.uni-karlsruhe.de with esmtps id 1I6Lt4-0003xh-Ii; Thu, 05 Jul 2007 09:36:28 +0200 Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5]) by irams2.ira.uni-karlsruhe.de with esmtps id 1I6Lt3-00029t-Ac; Thu, 05 Jul 2007 09:36:26 +0200 Received: from i72ms.tm.uni-karlsruhe.de ([141.3.70.5] helo=smtp.ipv6.tm.uni-karlsruhe.de) by irams1.ira.uni-karlsruhe.de with esmtps id 1I6Lt2-0006nw-Vz; Thu, 05 Jul 2007 09:36:25 +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 D09732FC015; Thu, 5 Jul 2007 09:36:23 +0200 (CEST) Received: from localhost ([127.0.0.1]) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.44) id 1I6Lt1-0002pO-HE; Thu, 05 Jul 2007 09:36:23 +0200 Message-ID: <468C9F76.8020708@tm.uka.de> Date: Thu, 05 Jul 2007 09:36:22 +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: Shivanajay Marwaha Subject: Re: [NSIS] Tearing direction in Mobility Applicability I-D References: <5F09D220B62F79418461A978CA0921BD01E12CB2@pslexc01.psl.local> In-Reply-To: <5F09D220B62F79418461A978CA0921BD01E12CB2@pslexc01.psl.local> X-Enigmail-Version: 0.94.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Status: No X-Spam-Score: -1.4 (-) X-Spam-Report: -1.4 ALL_TRUSTED Passed through trusted hosts only via SMTP 0.1 AWL AWL: From: address is in the auto white-list X-Spam-Host: irams2.ira.uni-karlsruhe.de X-ATIS-Checksum: v3zoCAcc32ckk X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: nsis X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi, Shivanajay Marwaha wrote: > I have the following comment on section 4 of Mobility Applicability > Draft:- > > Direction of teardown in Figure 1 should be made compliant with NSLP > I-D. In Fig. 1, RESERVE (T) (message no. 9) is sent from CRN towards > QNI, as opposed to as indicated in the NSLP I-D: "RESERVE messages MUST > only be sent towards the QNR" (Section 5.4.1, para 2). This has also > been pointed out by Roland in his QoS NSLP I-D comment. Yes that was also one of my comments to this draft (I've to write them up though), however, the QoS NSLP is unclear in this respect an I guess it even would make sometimes sense to do it in the way that is described in the Mobility Applicability Draft. However, authorization issues may come up. Furthermore, what about receiver-initiated reservations? What would be the allowed direction for a TEAR. Is it also the receiver? Regards, Roland _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Jul 05 21:12:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6cMc-0007f7-W0; Thu, 05 Jul 2007 21:12:02 -0400 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1I6cMc-0007ez-00 for nsis-confirm+ok@megatron.ietf.org; Thu, 05 Jul 2007 21:12:02 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6cMb-0007er-K8 for nsis@ietf.org; Thu, 05 Jul 2007 21:12:01 -0400 Received: from smtp.mei.co.jp ([133.183.129.25]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I6cMa-0005HO-Pl for nsis@ietf.org; Thu, 05 Jul 2007 21:12:01 -0400 Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/bulls) with ESMTP id l6619wFq007709 for ; Fri, 6 Jul 2007 10:09:58 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx1) with ESMTP id l6619we08028 for ; Fri, 6 Jul 2007 10:09:58 +0900 (JST) Received: from localhost (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/redsox) with SMTP id l6619wx16741 for ; Fri, 6 Jul 2007 10:09:58 +0900 (JST) Received: from [127.0.0.1] ([10.68.141.109]) by pslexc01.psl.local with Microsoft SMTPSVC(6.0.3790.1830); Fri, 6 Jul 2007 09:09:46 +0800 Message-ID: <468D9653.1000909@sg.panasonic.com> Date: Fri, 06 Jul 2007 09:09:39 +0800 From: Hong Cheng User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Takako Sanda Subject: Re: [NSIS] Request comments for Mobility draft References: <20070628204538.1246.SANDA.TAKAKO@jp.panasonic.com> In-Reply-To: <20070628204538.1246.SANDA.TAKAKO@jp.panasonic.com> X-Enigmail-Version: 0.95.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Jul 2007 01:09:46.0408 (UTC) FILETIME=[57D0AA80:01C7BF6A] X-Spam-Score: 0.1 (/) X-Scan-Signature: 3be09dac38eaa50f02d21c7fcee1128c 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 Dear all, Please find some comments regarding the security considerations of the draft. cheers Cheng Hong > ===== > 7. Security Considerations > > > > The movement of the mobile node after the initial flow setup requires > authorization. Various session ownership authorization issues are > illustrated in [10]. > > > > MN DCRN CN > > + E.g. > ------>----->------>------>------>------>------> | Movement > ACTION | with state > | creation at > <-----<-----<------<------<------<------<------- + new path > ACK > > > > > > Sanda (Ed.), et al. Expires September 6, 2007 [Page 34] > > Internet-Draft NSIS Signaling in Mobility March 2007 > > > Figure 11: MN authorizes DCRN > > The following questions are of interest: > > - Why should the DCRN execute something on behalf of the MN? > (i.e., why should it trust the MN and what information can the > DCRN use for verification? [the trust is not the other way round: > the MN trusts the DCRN?]) As an example, the DCRN might delete > state along the old segment. [Cheng] The MN is the Authorizing entity, why the DCRN cannot trust the MN? This seems like a redundant questions. Suggest to remove it. Or, is it trying to say something else? [/Cheng] > - Should the DCRN alone be able to start signaling (the DCRN might > be a dedicated node in some mobility protocols (e.g., MAP)) since > it is the node which has more information than other nodes based > on the mobility signaling protocols? > > - How should other nodes between the MN and the DCRN and the nodes > between the DCRN and the CN know that the DCRN is now acting on > behalf of the MN? > > The case of a corresponding node triggering an action is discussed in > the paragraph below. Figure 12 shows the exchange graphically. > > In this scenario the CN wants to, for example, tear-down a > reservation. > > > > MN DCRN CN > > <~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + > TRIGGER | E.g. > | Tear > | Down > ------>----->------>------>------>------>------> | > ACTION | > | > <-----<-----<------<------<------<------<------- + > ACK > > > Figure 12: CN triggers action > > The following questions arise: > > - Why should the MN trust the trigger? Why should the > intermediate nodes trust it? > [Cheng] Second part of the question looks suspicious. Is this TRIGGER a direct message to MN? Why intermediate node need to process it since the ACTION will anyway come from MN later? Suggest drop the second part. [/Cheng] > > > > Sanda (Ed.), et al. Expires September 6, 2007 [Page 35] > > Internet-Draft NSIS Signaling in Mobility March 2007 > > > - Is it possible to specify the security properties of the trigger > message in more detail? Is this an NSIS signaling message? > [Cheng] Related to the above question, another question to be asked is probably "is this TRIGGER processed by intermediate node?" [/Cheng] > > > - The discussions about an indicator which entity to charge for > the reservation might be relevant (see [12]). > > - Should the CN restrict the actions of the MN (e.g., delete, > update, create action of established state information)? On the > shared segment it might, for example, be possible to restrict the > allowed action to a flow identifier update. > [Cheng] What does this mean? Isn't MN the authorizing entity? It can carry out any action it sees suitable. CN is just providing the trigger (or enough information) for MN to make a decision. In the above figure, ACTION is sent from MN. Suggest to clarify the meaning of the above text. [/Cheng] > > > > > Sanda (Ed.), et al. Expires September 6, 2007 [Page 37] > > Internet-Draft NSIS Signaling in Mobility March 2007 > > > delete). An optimistic delete operation is certainly more error > prone. > > > > MN DCNR CN > > [ ~~~~~~~~~~~~ TRIGGER (e.g., MIP) ~~~~~~~~~~~~~~> ] + > > ------<-----<------<------<------<------<------< | > ACTION (CN is authz) | > +--------------------+ +-----------------+ | > | Action:optimistic | | Action: | | > | 'delete' along | | 'update' along)| | > | old segment) | | shared segment)| | > +--------------------+ +-----------------+ | > >------>------>----------->------>------>------- | > +-----------------+ ACK | > | Action: | | Action > | 'create' along)| | > | new segment) | | > +-----------------+ | > <------<------<------- | > +-------------------+ | > | Action:pessimistic| | > | 'delete' along) | | > | old segment) | | > +-------------------+ | > =================Traffic==========================> + > > > > Figure 14: CN uses installed state to route message backwards > > Figure 14 raises a few questions: > > The security properties of the trigger message need to be > evaluated. > > It is not always possible to route signaling message backwards > from the CN to the MN: > > - state at the new path might not be established (hence the > signaling message cannot travel backwards) > [Cheng]: As the section title suggested: "CN uses install state to route message backwards", why it has to do with whether the new path is established or not?The above "ACTION" is to be routed along the old path. The issue seems more likely associated with the message from "DCNR" (?shouldn't this be DCRN?) towards MN. Suggest to clarify this point or remove it. [/Cheng] > > - the signaling message might not reach the MN via the old > segment. > > > > > Sanda (Ed.), et al. Expires September 6, 2007 [Page 38] > > > 7.2. CN as data sender > > In this section we consider the scenarios where the CN acts as a data > sender. Figure 15 shows the topology and the participating entities. > > 7.2.1. CN is authorizing entity > > This scenario is similar to the one described in Section 6.1.1. No [Cheng] ^^^^^^^^^^^^^^ Is this the correct section number? [/Cheng] > > > additional problems arise with a scenario where the CN is both data > sender and also the authorizing entity. In Figure 15 the CN > authorizes the UCNR to delete the old segment and to establish a new [Cheng] ^^^^^ change UCNR to UCRN [/Cheng] > > reservation along the new segment. Furthermore, at the shared > segment only an update of the flow identifier might be necessary. > > > Sanda (Ed.), et al. Expires September 6, 2007 [Page 39] > > Internet-Draft NSIS Signaling in Mobility March 2007 > > > 7.2.2. MN is authorizing entity > > In this scenario we consider the case where the CN is the data sender > but the MN authorizes actions. The considerations are similar to > those elaborated in Section 6.1.3 where the MN is the data sender but [Cheng] ^^^^^^^^^^^^^^ IS this the correct section number? [/Cheng] > > > > the CN is the authorizing entity. > > > > 7.3.2. CN as data sender > > This section shows the multi-homing scenario with the CN as a data > sender. The scenario is simpler (for the CN authorizing case) than > the one described in Section 6.1 since the signaling message along > the shared segment travels the previously established path. It shows > some similarities with a route change scenario. At the mobile node > itself the two paths merge which again leads to a session ownership > problem. How should the MN know whether a signaling message with the > same session identifier hitting a different interface belongs to the > indicated session authorized by the CN? [Cheng] The issue above for MN is the same for the DCRN in the issue of 7.3.1. That is to say, it is a common problem for the DCRN for both cases. [/Cheng] Takako Sanda wrote: > Hi all, > > Mobility Draft still have open issues and some sections need to clean up, > such as. > - NAT/FW interaction (open issue) > When MN moves, IP address and routing are changed. In this case, new > NAT/FW pinhole need to be opened and old one should be torn. When and > how should NSIS tear old pinhole? > - Security consideration (need to clean up) > - Terminology (need to clean up) > > For terminology section, authors plan to remove the terms which are not > used in the main body (such as NSPL/NTLP/NSIS CRN). However other parts > are not discussed well. > > Your comments will be highly appreciated ;-) > > cheers, > Takako > > > > _______________________________________________ > 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 Jul 05 21:16:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6cR9-000307-CW; Thu, 05 Jul 2007 21:16:43 -0400 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1I6cR7-0002vp-P1 for nsis-confirm+ok@megatron.ietf.org; Thu, 05 Jul 2007 21:16:41 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6cR7-0002tr-Aw for nsis@ietf.org; Thu, 05 Jul 2007 21:16:41 -0400 Received: from smtp.mei.co.jp ([133.183.129.25]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I6cR6-0006Az-Mg for nsis@ietf.org; Thu, 05 Jul 2007 21:16:41 -0400 Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/kings) with ESMTP id l661GTnX000378; Fri, 6 Jul 2007 10:16:29 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx3) with ESMTP id l661GUa17607; Fri, 6 Jul 2007 10:16:30 +0900 (JST) Received: from epochmail.jp.panasonic.com (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/expos) with ESMTP id l661GTZ25415; Fri, 6 Jul 2007 10:16:29 +0900 (JST) Received: by epochmail.jp.panasonic.com (8.12.11.20060308/3.7W/soml22) id l661GTIu018965; Fri, 6 Jul 2007 10:16:29 +0900 (JST) Received: from [10.68.141.107] by soml22.jp.panasonic.com (8.12.11.20060308/3.7W) with ESMTP id l661GJlD018503; Fri, 6 Jul 2007 10:16:19 +0900 (JST) Date: Fri, 06 Jul 2007 10:16:56 +0900 From: Takako Sanda To: Roland Bless Subject: Re: [NSIS] Tearing direction in Mobility Applicability I-D In-Reply-To: <468C9F76.8020708@tm.uka.de> References: <5F09D220B62F79418461A978CA0921BD01E12CB2@pslexc01.psl.local> <468C9F76.8020708@tm.uka.de> Message-Id: <20070706101547.9FA5.SANDA.TAKAKO@jp.panasonic.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.12.01 [ja] X-Spam-Score: 0.1 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: nsis X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Roland and Shiv, Thank you for your comments. For direction of RESERVE_with_tear message, Mobility draft should be synchronized with QoS NSLP draft. So this issue need to be clear in QoS NSLP draft first. cheers, Takako On Thu, 05 Jul 2007 09:36:22 +0200 Roland Bless wrote: > Hi, > > Shivanajay Marwaha wrote: > > I have the following comment on section 4 of Mobility Applicability > > Draft:- > > > > Direction of teardown in Figure 1 should be made compliant with NSLP > > I-D. In Fig. 1, RESERVE (T) (message no. 9) is sent from CRN towards > > QNI, as opposed to as indicated in the NSLP I-D: "RESERVE messages MUST > > only be sent towards the QNR" (Section 5.4.1, para 2). This has also > > been pointed out by Roland in his QoS NSLP I-D comment. > > Yes that was also one of my comments to this draft (I've to write them > up though), however, the QoS NSLP is unclear in this respect an I guess > it even would make sometimes sense to do it in the way that is described > in the Mobility Applicability Draft. However, authorization issues may > come up. Furthermore, what about receiver-initiated reservations? What > would be the allowed direction for a TEAR. Is it also the receiver? > > Regards, > Roland > > > _______________________________________________ > 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 Jul 06 01:21:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6gG1-0005D6-IE; Fri, 06 Jul 2007 01:21:29 -0400 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1I6gFz-0005C4-Of for nsis-confirm+ok@megatron.ietf.org; Fri, 06 Jul 2007 01:21:27 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6gFy-0005A8-OJ for nsis@ietf.org; Fri, 06 Jul 2007 01:21:26 -0400 Received: from smtp.mei.co.jp ([133.183.129.25]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I6gFy-0003MD-3M for nsis@ietf.org; Fri, 06 Jul 2007 01:21:26 -0400 Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/jazz) with ESMTP id l665LFq2001678 for ; Fri, 6 Jul 2007 14:21:15 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx3) with ESMTP id l665LHa08342 for ; Fri, 6 Jul 2007 14:21:17 +0900 (JST) Received: from epochmail.jp.panasonic.com ([127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/dodgers) with ESMTP id l665LFr20058 for ; Fri, 6 Jul 2007 14:21:15 +0900 (JST) Received: by epochmail.jp.panasonic.com (8.12.11.20060308/3.7W/soml24) id l665LGiw023520 for nsis@ietf.org; Fri, 6 Jul 2007 14:21:16 +0900 (JST) Received: from [10.68.141.77] by soml24.jp.panasonic.com (8.12.11.20060308/3.7W) with ESMTP id l665LFL2023488 for ; Fri, 6 Jul 2007 14:21:15 +0900 (JST) Date: Fri, 06 Jul 2007 14:21:52 +0900 From: Takako Sanda To: nsis@ietf.org Message-Id: <20070706140925.2B54.SANDA.TAKAKO@jp.panasonic.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.12.01 [ja] X-Spam-Score: 0.1 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Subject: [NSIS] NAT traversal in Mobility case 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, In mobility scenario, it is possible that MN attaches to private network, but it does not know whether the NAT is NSIS aware or not. Therefore I suggest that Mobility draft should contain the text:- - If MN detects the attached network is private, MN MUST set S-flag in signaling message in case the MN is an NI. In addition, I have two questions about NAT traversal:- - In case NSIS aware NAT detects S-flag in the message, isn't it necessary to un-set the flag to avoid unnecessary operation in a QNE outside the NAT? Is N-flag enough? (although it may be an implementation issue) - GIST draft says in case of legacy NAT, Querying node will terminate the handshake after receiving the response. However the QNE outside of the NAT may be able to act as a proxy. In this case, is there anything else the GIST can do? cheers, Takako _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Jul 09 03:31:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7niR-0001qr-Uw; Mon, 09 Jul 2007 03:31:27 -0400 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1I7niP-0001ql-VB for nsis-confirm+ok@megatron.ietf.org; Mon, 09 Jul 2007 03:31:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7niP-0001qd-Kz for nsis@ietf.org; Mon, 09 Jul 2007 03:31:25 -0400 Received: from an-out-0708.google.com ([209.85.132.240]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I7niL-0006Je-9b for nsis@ietf.org; Mon, 09 Jul 2007 03:31:25 -0400 Received: by an-out-0708.google.com with SMTP id c17so164919anc for ; Mon, 09 Jul 2007 00:31:21 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=g4F22E84cwyZm/Nq74O8sBsJ/O3z1hD5OMt9jY9lPrVKtByc0ICUKxZliRFG15vd0W0YvK41KKCP1q2gRjQG9rb3ZTf6AYUa4Xn4BmiH+mOTjnagPpONKGnvXAl10le1i1R+/+6NonJ6ByeNSyzTZ2TizZbN0HOa6jK0gdOpKsY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=KqcyQ5mQQlNabxRrqhw/XI07BdImhTKJa30+Q1gwiCmAQYt223CnEX3d4hg4mxyPghkhmAN8SN9yORJQ/ZIbm+hCcFZQWpHirffUSY/JTcMJZjeXtq9dhAwIsbUPuRKDtjx7gxcOwJfnRNRB8uLYYw+giGLVkkMkoCR92WFWbYA= Received: by 10.100.132.16 with SMTP id f16mr1452841and.1183966280960; Mon, 09 Jul 2007 00:31:20 -0700 (PDT) Received: by 10.100.137.2 with HTTP; Mon, 9 Jul 2007 00:31:20 -0700 (PDT) Message-ID: Date: Mon, 9 Jul 2007 03:31:20 -0400 From: "Charles Shen" To: "Shivanajay Marwaha" Subject: Re: [NSIS] Comment on MIP Interaction section of Mobility I-D In-Reply-To: <5F09D220B62F79418461A978CA0921BD01E12CB3@pslexc01.psl.local> MIME-Version: 1.0 References: <5F09D220B62F79418461A978CA0921BD01E12CB3@pslexc01.psl.local> X-Google-Sender-Auth: 6d0f2dd71d89f6ef X-Spam-Score: 0.1 (/) 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: , Content-Type: multipart/mixed; boundary="===============0872939896==" Errors-To: nsis-bounces@ietf.org --===============0872939896== Content-Type: multipart/alternative; boundary="----=_Part_94824_17879086.1183966280930" ------=_Part_94824_17879086.1183966280930 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Yes, it would be a good idea to synchronize the contents and clarify the scope of presentations in the tunnel ID and the mobility ID where the scenarios overlap. Thanks. Charles On 7/4/07, Shivanajay Marwaha wrote: > > Dear all, > > My comment on MIP Interaction section (Section 5) of Mobility > Applicability I-D:- > > MIP Interaction section needs to be cleaned up. For example figure 7 is > incorrect, this figure shows a signaling sequence chart for > "Receiver-Initiated QoS NSLP over Tunnel - Parallel Mode". However, in > the figure the MN (Sender) is sending the RESERVE message. > > Also, this section should illustrate how Tunnel I-D is applicable to MIP > cases. Redundant MIP signaling scenarios in the NSIS Mobility I-D from > NSIS Tunnel I-D should be removed. > > Cheers, > Shiv > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > ------=_Part_94824_17879086.1183966280930 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Yes, it would be a good idea to synchronize the contents and clarify the scope of presentations in the tunnel ID and the mobility ID where the scenarios overlap. 

Thanks.

Charles

On 7/4/07, Shivanajay Marwaha <Shivanajay.Marwaha@sg.panasonic.com> wrote:
Dear all,

My comment on MIP Interaction section (Section 5) of Mobility
Applicability I-D:-

MIP Interaction section needs to be cleaned up. For example figure 7 is
incorrect, this figure shows a signaling sequence chart for
"Receiver-Initiated QoS NSLP over Tunnel - Parallel Mode". However, in
the figure the MN (Sender) is sending the RESERVE message.

Also, this section should illustrate how Tunnel I-D is applicable to MIP
cases. Redundant MIP signaling scenarios in the NSIS Mobility I-D from
NSIS Tunnel I-D should be removed.

Cheers,
Shiv


_______________________________________________
nsis mailing list
nsis@ietf.org
https://www1.ietf.org/mailman/listinfo/nsis

------=_Part_94824_17879086.1183966280930-- --===============0872939896== 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 --===============0872939896==-- From nsis-bounces@ietf.org Mon Jul 09 06:50:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7qoh-0001dR-Uk; Mon, 09 Jul 2007 06:50:07 -0400 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1I7qod-0001Wp-CQ for nsis-confirm+ok@megatron.ietf.org; Mon, 09 Jul 2007 06:50:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7qoc-0001VQ-5f; Mon, 09 Jul 2007 06: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 1I7qob-0002tR-QP; Mon, 09 Jul 2007 06:50:02 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id AE6DA26E66; Mon, 9 Jul 2007 10:50:01 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1I7qob-0008AA-K4; Mon, 09 Jul 2007 06:50:01 -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, 09 Jul 2007 06:50:01 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Cc: nsis@ietf.org Subject: [NSIS] I-D Action:draft-ietf-nsis-ntlp-14.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 Signalling Transport Author(s) : H. Schulzrinne, R. Hancock Filename : draft-ietf-nsis-ntlp-14.txt Pages : 157 Date : 2007-07-09 This document specifies protocol stacks for the routing and transport of per-flow signalling 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 Signalling Transport (GIST), which provides a common service for diverse signalling applications. GIST does not handle signalling 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 Signalling" framework. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nsis-ntlp-14.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-14.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-14.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: <2007-07-09064440.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nsis-ntlp-14.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nsis-ntlp-14.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-07-09064440.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 Tue Jul 10 09:26:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8Fjx-00016e-QL; Tue, 10 Jul 2007 09:26:53 -0400 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1I8Fjv-0000pL-TB for nsis-confirm+ok@megatron.ietf.org; Tue, 10 Jul 2007 09:26:51 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8Fjv-0000gv-9l for nsis@ietf.org; Tue, 10 Jul 2007 09:26:51 -0400 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I8Fju-0005F0-Jw for nsis@ietf.org; Tue, 10 Jul 2007 09:26:51 -0400 Received: from [10.1.1.109] (mito.netlab.nec.de [195.37.70.39]) by kyoto.netlab.nec.de (Postfix) with ESMTP id E0F2813CF81; Tue, 10 Jul 2007 15:26:29 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <44809A82-9ABA-46E9-A154-41D3FCC9CD43@netlab.nec.de> From: Martin Stiemerling Date: Tue, 10 Jul 2007 15:26:29 +0200 To: nsis X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: ded6070f7eed56e10c4f4d0d5043d9c7 Cc: Jukka Manner Subject: [NSIS] Agenda for IETF-69 in Chicago X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: nsis-chairs@tools.ietf.org, Jukka Manner List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0343536702==" Errors-To: nsis-bounces@ietf.org --===============0343536702== Content-Type: multipart/alternative; boundary=Apple-Mail-18--391640694 --Apple-Mail-18--391640694 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Dear all, Here is the agenda for the NSIS WG session at the 69th IETF meeting in Chicago. Be reminded that neither John nor me are able to attend this IETF meeting. Jukka Manner is chairing the session in Chicago. Thanks again to Jukka. An always up-to-date version is available here: http://www3.ietf.org/proceedings/07jul/agenda/nsis.txt IETF-69, Chicago, IL, US **Draft Agenda for NSIS WG** WG Chair(s): John Loughney Martin Stiemerling Chair of the WG session at the IETF-69: Jukka Manner Important: Send any change request to nsis-chairs@tools.ietf.org and jmanner@cs.helsinki.fi MONDAY, July 23, 2007 0900-1130 Morning Session I * Agenda Bashing (20 minutes) NOTE WELL Document Status and Accomplishments - GIST update Milestones Review * Report from the interop in Karlsruhe - Roland Bless (10 minutes) * QoS NSLP - Jukka Manner (15 minutes) * NAT/FW NSLP - Hannes Tschofenig (15 minutes) * Mobility Applicability Statement - Takako Sanda (10 minutes) * QSPEC - TBD (5 minutes) * RMD-QOSM - TBD (5 minutes) * Y.1541 QOSM - TBD (15 minutes) * NSIS Operation over IP Tunnels - TBD (10 minutes) * GIST state machine - TBD (10 minutes) * GIST over SCTP - TBD (10 minutes) These individual drafts can be presented if time permits, after the WG items have been discussed (each of them max. 5 minutes): * NSIS Multihoming Support Issues- Cheng Hong draft-cheng-nsis-multihoming-00 * HyPath - Luis Cordeiro * reservation aggregation - Roland Bless * Peering Data for NSIS Signaling Layer Protocols - Jukka Manner draft-manner-nsis-peering-data-00.txt * Authorization for NSIS Signaling Layer Protocols - Jukka Manner draft-manner-nsis-nslp-auth-03.txt stiemerling@netlab.nec.de NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 --Apple-Mail-18--391640694 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Dear all,

Here is the agenda for the = NSIS WG session at the 69th IETF meeting in Chicago.=A0

Be reminded that neither = John nor me are able to attend this IETF meeting. Jukka Manner is = chairing the session in Chicago. Thanks again to Jukka.

An always up-to-date = version is available here:



IETF-69, Chicago, IL, = US

**Draft = Agenda for NSIS WG**

WG Chair(s):
John = Loughney <john.loughney@nokia.com>
Martin Stiemerling <stiemerling@netlab.nec.de>= ;

Chair of = the WG session at the IETF-69:
Jukka Manner <jmanner@cs.helsinki.fi>

Important: Send = any change request to


MONDAY, July 23, 2007 =
0900-1130 Morning Session I


* Agenda Bashing=A0=A0 (20 = minutes)
=A0 NOTE WELL
=A0 Document Status and = Accomplishments
=A0 - GIST update
=A0 Milestones = Review

* = Report from the interop in Karlsruhe - Roland Bless (10 = minutes)

* = QoS NSLP - Jukka Manner (15 minutes)

* NAT/FW NSLP - Hannes = Tschofenig (15 minutes)

* Mobility Applicability = Statement - Takako Sanda (10 minutes)

* QSPEC - TBD (5 = minutes)

* = RMD-QOSM - TBD (5 minutes)

* Y.1541 QOSM - TBD (15 = minutes)

* = NSIS Operation over IP Tunnels - TBD (10 minutes)

* GIST state machine - TBD = (10 minutes)

* = GIST over SCTP - TBD (10 minutes)

These individual drafts can = be presented if time permits, after the WG items have been discussed = (each of them max. 5 minutes):
* NSIS Multihoming Support = Issues-=A0 Cheng = Hong
draft-cheng-nsis-multihoming-00

* HyPath - Luis = Cordeiro

* = reservation aggregation - Roland Bless

* Peering Data for NSIS = Signaling Layer Protocols - Jukka = Manner
draft-manner-nsis-peering-data-00.txt

* Authorization for NSIS = Signaling Layer Protocols - Jukka = Manner
draft-manner-nsis-nslp-auth-03.txt



stiemerling@netlab.nec.de
NEC Europe Limited |=A0Registered Office: NEC House, = 1 Victoria Road, London W3 6BL |=A0Registered in England = 2832014

=

= --Apple-Mail-18--391640694-- --===============0343536702== 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 --===============0343536702==-- From nsis-bounces@ietf.org Tue Jul 10 09:28:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8Fll-0004lv-Lx; Tue, 10 Jul 2007 09:28:45 -0400 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1I8Flk-0004ln-A2 for nsis-confirm+ok@megatron.ietf.org; Tue, 10 Jul 2007 09:28:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8Flk-0004le-0U for nsis@ietf.org; Tue, 10 Jul 2007 09:28:44 -0400 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8Flj-0004Wm-PB for nsis@ietf.org; Tue, 10 Jul 2007 09:28:43 -0400 Received: from [10.1.1.109] (mito.netlab.nec.de [195.37.70.39]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 5494613CF81 for ; Tue, 10 Jul 2007 15:28:43 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v752.3) To: nsis Message-Id: <5ADDF815-B574-4E2D-9E81-49BE5F72CCD7@netlab.nec.de> From: Martin Stiemerling Date: Tue, 10 Jul 2007 15:28:43 +0200 X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Subject: [NSIS] Away for the next four weeks 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="===============1593675232==" Errors-To: nsis-bounces@ietf.org --===============1593675232== Content-Type: multipart/alternative; boundary=Apple-Mail-19--391507066 --Apple-Mail-19--391507066 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hi all, Just to let you know: I'm going on holidays for the next four weeks for a very private (but happy) reason. I will be virtually around for the NSIS session during the IETF meeting, i.e., participating by Jabber and audio. Thanks, Martin stiemerling@netlab.nec.de NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 --Apple-Mail-19--391507066 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Hi all,

Just to let you know: I'm = going on holidays for the next four weeks for a very private (but happy) = reason.=A0

I = will be virtually around for the NSIS session during the IETF meeting, = i.e., participating by Jabber and audio.

Thanks,

=A0 = Martin

stiemerling@netlab.nec.de
NEC Europe Limited |=A0Registered Office: NEC House, = 1 Victoria Road, London W3 6BL |=A0Registered in England = 2832014

=

= --Apple-Mail-19--391507066-- --===============1593675232== 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 --===============1593675232==-- From nsis-bounces@ietf.org Tue Jul 10 09:32:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8FpY-0000OE-Su; Tue, 10 Jul 2007 09:32:40 -0400 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1I8FpW-0000KC-39 for nsis-confirm+ok@megatron.ietf.org; Tue, 10 Jul 2007 09:32:38 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8FpU-0000Ja-GD for nsis@ietf.org; Tue, 10 Jul 2007 09:32:37 -0400 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I8FpU-0005PD-5X for nsis@ietf.org; Tue, 10 Jul 2007 09:32:36 -0400 Received: from [10.1.1.109] (mito.netlab.nec.de [195.37.70.39]) by kyoto.netlab.nec.de (Postfix) with ESMTP id B4D4C13CF81 for ; Tue, 10 Jul 2007 15:32:35 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v752.3) To: nsis Message-Id: From: Martin Stiemerling Date: Tue, 10 Jul 2007 15:32:35 +0200 X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Subject: [NSIS] Presentations for the IETF-69 NSIS session due on Sunday July 22nd! 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="===============0837361816==" Errors-To: nsis-bounces@ietf.org --===============0837361816== Content-Type: multipart/alternative; boundary=Apple-Mail-20--391274881 --Apple-Mail-20--391274881 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Dear all, To give all people a chance to browse through your IETF NSIS presentation slides, I kindly request all presenters to send their presentations to **nsis-chairs@tools.ietf.org** by **Sunday, July 22nd, 11:30pm Chicago time!** I will upload all the slides to the meeting materials web page: https://datatracker.ietf.org/meeting/69/materials.html Thanks, Martin stiemerling@netlab.nec.de NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 --Apple-Mail-20--391274881 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Dear all,

To give all people a chance = to browse through your IETF NSIS presentation slides, I kindly request = all presenters to send their presentations to=A0


by

**Sunday, July 22nd, = 11:30pm Chicago time!**

I will upload all the = slides to the meeting materials web page:

Thanks,

=A0 = Martin

stiemerling@netlab.nec.de
NEC Europe Limited |=A0Registered Office: NEC House, = 1 Victoria Road, London W3 6BL |=A0Registered in England = 2832014

=

= --Apple-Mail-20--391274881-- --===============0837361816== 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 --===============0837361816==-- From nsis-bounces@ietf.org Thu Jul 12 11:15:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I90Ns-0006TQ-D7; Thu, 12 Jul 2007 11:15:12 -0400 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1I90Nj-00062F-QI for nsis-confirm+ok@megatron.ietf.org; Thu, 12 Jul 2007 11:15:03 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I90Nj-00061z-4x; Thu, 12 Jul 2007 11:15:03 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I90Ni-0003jj-Tt; Thu, 12 Jul 2007 11:15:03 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 98CFA175DD; Thu, 12 Jul 2007 15:15:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1I90Ni-0000NQ-57; Thu, 12 Jul 2007 11:15: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, 12 Jul 2007 11:15:02 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: nsis@ietf.org Subject: [NSIS] I-D ACTION:draft-ietf-nsis-ntlp-statemachine-04.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 State Machine Author(s) : H. Tschofenig, et al. Filename : draft-ietf-nsis-ntlp-statemachine-04.txt,.pdf Pages : 24 Date : 2007-7-12 This document describes the state machines for the General Internet Signaling Transport (GIST). The states of GIST nodes for a given flow and their transitions are presented in order to illustrate how GIST may be implemented. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nsis-ntlp-statemachine-04.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-statemachine-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-nsis-ntlp-statemachine-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-7-12105840.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nsis-ntlp-statemachine-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nsis-ntlp-statemachine-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-7-12105840.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 Thu Jul 12 11:15:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I90OP-0007Si-DE; Thu, 12 Jul 2007 11:15:45 -0400 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1I90OD-0007D3-HE for nsis-confirm+ok@megatron.ietf.org; Thu, 12 Jul 2007 11:15:33 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I90OD-0007CX-4d; Thu, 12 Jul 2007 11:15:33 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I90OC-0003lP-S5; Thu, 12 Jul 2007 11:15:33 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 8C0C2175DA; Thu, 12 Jul 2007 15:15:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1I90Ni-0000NM-3e; Thu, 12 Jul 2007 11:15: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, 12 Jul 2007 11:15:02 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: nsis@ietf.org Subject: [NSIS] I-D ACTION:draft-ietf-nsis-nslp-natfw-15.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 : NAT/Firewall NSIS Signaling Layer Protocol (NSLP) Author(s) : M. Stiemerling, et al. Filename : draft-ietf-nsis-nslp-natfw-15.txt Pages : 88 Date : 2007-7-12 This memo defines the NSIS Signaling Layer Protocol (NSLP) for Network Address Translators (NATs) and firewalls. This NSLP allows hosts to signal on the data path for NATs and firewalls to be configured according to the needs of the application data flows. It enables hosts behind NATs to obtain a public reachable address and hosts behind firewalls to receive data traffic. The overall architecture is given by the framework and requirements defined by the Next Steps in Signaling (NSIS) working group. The network scenarios, the protocol itself, and examples for path-coupled signaling are given in this memo. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nsis-nslp-natfw-15.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-nslp-natfw-15.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-nslp-natfw-15.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: <2007-7-12105601.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nsis-nslp-natfw-15.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nsis-nslp-natfw-15.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-7-12105601.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 Fri Jul 13 02:47:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9EwN-0002mx-4i; Fri, 13 Jul 2007 02:47:47 -0400 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1I9EwM-0002mp-D1 for nsis-confirm+ok@megatron.ietf.org; Fri, 13 Jul 2007 02:47:46 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9EwI-0002fX-SY for nsis@ietf.org; Fri, 13 Jul 2007 02:47:42 -0400 Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I9EwI-0006Pc-Bt for nsis@ietf.org; Fri, 13 Jul 2007 02:47:42 -0400 Received: from irams2.ira.uni-karlsruhe.de ([141.3.10.82]) by iramx2.ira.uni-karlsruhe.de with esmtps id 1I9Evy-0000Qw-Uy for ; Fri, 13 Jul 2007 08:47:25 +0200 Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5]) by irams2.ira.uni-karlsruhe.de with esmtps for id 1I9Evy-0005Zi-O0; Fri, 13 Jul 2007 08:47:22 +0200 Received: from i72ms.tm.uni-karlsruhe.de ([141.3.70.5] helo=smtp.ipv6.tm.uni-karlsruhe.de) by irams1.ira.uni-karlsruhe.de with esmtps for id 1I9Evy-0001EZ-EM; Fri, 13 Jul 2007 08:47: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 01F502FC015 for ; Fri, 13 Jul 2007 08:47:22 +0200 (CEST) Received: from localhost ([127.0.0.1]) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.44) id 1I9Evw-0001Bl-Vo for nsis@ietf.org; Fri, 13 Jul 2007 08:47:21 +0200 Resent-From: Roland Bless Resent-To: nsis@ietf.org Resent-Date: Fri, 13 Jul 2007 08:47:20 +0200 Resent-Message-Id: <46971FF8.3090704@tm.uka.de> Resent-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 Received: from murder ([unix socket]) by vorta (Cyrus v2.2.12) with LMTPA; Thu, 12 Jul 2007 21:22:01 +0200 X-Sieve: CMU Sieve 2.2 Received: from localhost ([127.0.0.1]) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.44) id 1I94EQ-0000Eb-NJ for bless@localhost; Thu, 12 Jul 2007 21:21:42 +0200 Received: from irams1.ira.uni-karlsruhe.de [141.3.10.5] by localhost with POP3 (fetchmail-6.2.5) for bless@localhost (single-drop); Thu, 12 Jul 2007 21:21:42 +0200 (CEST) Received: from irams2.ira.uni-karlsruhe.de ([141.3.10.82]) by irams1.ira.uni-karlsruhe.de with esmtps id 1I94Ct-0006sP-Bm; Thu, 12 Jul 2007 21:20:07 +0200 Received: from iramx1.ira.uni-karlsruhe.de ([141.3.10.80]) by irams2.ira.uni-karlsruhe.de with esmtps id 1I94Cr-00081c-16; Thu, 12 Jul 2007 21:20:05 +0200 Received: from optimus.ietf.org ([156.154.16.145] helo=megatron.ietf.org) by iramx1.ira.uni-karlsruhe.de with esmtps id 1I94Cj-0004Fh-U5; Thu, 12 Jul 2007 21:20:02 +0200 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I948A-00072H-Hb; Thu, 12 Jul 2007 15:15:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I947y-0006tD-Cj for i-d-announce@ietf.org; Thu, 12 Jul 2007 15:15:02 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I947y-0001PJ-1T for i-d-announce@ietf.org; Thu, 12 Jul 2007 15:15:02 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id DDFD226E8C for ; Thu, 12 Jul 2007 19:15:01 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1I947x-0005xE-Nb for i-d-announce@ietf.org; Thu, 12 Jul 2007 15:15:01 -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, 12 Jul 2007 15:15:01 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Archive: X-Spam-Status: No X-Spam-Score: -99.2 (---------------------------------------------------) X-Spam-Report: 0.6 NO_REAL_NAME From: does not include a real name -100 USER_IN_WHITELIST From: address is in the user's white-list 0.2 MIME_BOUND_NEXTPART Spam tool pattern in MIME boundary 0.0 AWL AWL: From: address is in the auto white-list X-Spam-Host: iramx1.ira.uni-karlsruhe.de X-ATIS-Checksum: v3zoCAcc32ckk X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Resent-Date: Fri, 13 Jul 2007 02:47:46 -0400 Cc: Subject: [NSIS] I-D ACTION:draft-bless-nsis-resv-aggr-01.txt X-BeenThere: nsis@ietf.org Reply-To: internet-drafts@ietf.org List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Inter-Domain Reservation Aggregation for QoS NSLP Author(s) : M. Doll, R. Bless Filename : draft-bless-nsis-resv-aggr-01.txt Pages : 22 Date : 2007-7-12 QoS NSLP is a recently proposed signaling protocol that allows to establish QoS reservations in the Internet. In order to enable large scale deployment, inter-domain aggregation should be considered as mechanism to allow for the necessary scalability in the control plane. This draft describes the major problems that must be solved and proposes also solutions to these problems, requiring only modest modifications and extensions to the currently defined GIST and QoS NSLP specifications. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-bless-nsis-resv-aggr-01.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-bless-nsis-resv-aggr-01.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-bless-nsis-resv-aggr-01.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: <2007-7-12140128.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-bless-nsis-resv-aggr-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-bless-nsis-resv-aggr-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-7-12140128.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --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 Fri Jul 13 14:15:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9Pfb-0005fm-3Q; Fri, 13 Jul 2007 14:15:11 -0400 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1I9PfT-0005YY-7m for nsis-confirm+ok@megatron.ietf.org; Fri, 13 Jul 2007 14:15:03 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9PfS-0005YK-QV; Fri, 13 Jul 2007 14:15:02 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I9PfS-0003jI-Ic; Fri, 13 Jul 2007 14:15:02 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 412CA1761E; Fri, 13 Jul 2007 18:15:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1I9PfR-0007Qt-Pj; Fri, 13 Jul 2007 14:15:01 -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: Fri, 13 Jul 2007 14:15:01 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: nsis@ietf.org Subject: [NSIS] I-D ACTION:draft-ietf-nsis-applicability-mobility-signaling-07.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 : Applicability Statement of NSIS Protocols in Mobile Environments Author(s) : S. Lee, et al. Filename : draft-ietf-nsis-applicability-mobility-signaling-07.txt Pages : 58 Date : 2007-7-13 Mobility of an IP-based node affects routing paths, and as a result, can have a significant effect on the protocol operation and state management. This draft discusses the effects mobility can cause to the NSIS protocol suite, and how the protocols operate in different scenarios, with mobility management protocols. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nsis-applicability-mobility-signaling-07.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-applicability-mobility-signaling-07.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-applicability-mobility-signaling-07.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: <2007-7-13131302.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nsis-applicability-mobility-signaling-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nsis-applicability-mobility-signaling-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-7-13131302.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 Sun Jul 15 08:34:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IA3Ie-00075J-R8; Sun, 15 Jul 2007 08:34:08 -0400 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1IA3Ie-00075C-2J for nsis-confirm+ok@megatron.ietf.org; Sun, 15 Jul 2007 08:34:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IA3Id-000753-OX for nsis@ietf.org; Sun, 15 Jul 2007 08:34:07 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IA3IZ-0001pl-B1 for nsis@ietf.org; Sun, 15 Jul 2007 08:34:07 -0400 Received: (qmail invoked by alias); 15 Jul 2007 12:34:01 -0000 Received: from p54985558.dip.t-dialin.net (EHLO [192.168.1.4]) [84.152.85.88] by mail.gmx.net (mp051) with SMTP; 15 Jul 2007 14:34:01 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+jKK1tLFCjGAc7zpw7XYgyIv4H7u4nRACiYeqL3I TDVIWjNpMCwxdE Message-ID: <469A1437.1070801@gmx.net> Date: Sun, 15 Jul 2007 14:33:59 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: "nsis@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.5 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Subject: [NSIS] QoS NSLP -- INFO_SPEC 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 Section 5.1.3.6 defines the INFO_SPEC object. The object format is garbled and it is difficult to figure out how long the fields are. Object Value Info: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Rsvd | Real Object Length | Offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // Object // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ How long are the individual fields? Ciao Hannes _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Sun Jul 15 09:02:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IA3k1-0005gf-Qa; Sun, 15 Jul 2007 09:02:25 -0400 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1IA3k0-0005gZ-SJ for nsis-confirm+ok@megatron.ietf.org; Sun, 15 Jul 2007 09:02:24 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IA3k0-0005gQ-I9 for nsis@ietf.org; Sun, 15 Jul 2007 09:02:24 -0400 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IA3jl-0000Zb-3h for nsis@ietf.org; Sun, 15 Jul 2007 09:02:24 -0400 Received: (qmail invoked by alias); 15 Jul 2007 13:01:28 -0000 Received: from p54985558.dip.t-dialin.net (EHLO [192.168.1.4]) [84.152.85.88] by mail.gmx.net (mp018) with SMTP; 15 Jul 2007 15:01:28 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+Uqc0ap2CUwYbrYhPW07o4fMEepJtyOJIgDKFyOs FfM2iTPKIgVQmP Message-ID: <469A1AA5.80908@gmx.net> Date: Sun, 15 Jul 2007 15:01:25 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: "nsis@ietf.org" 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: b19722fc8d3865b147c75ae2495625f2 Subject: [NSIS] QoS NSLP, Packet Classifier 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 Section 5.1.3.5 defines the Packet Classifier The text says: " Value: Contains a variable length MRM-specific data 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) // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ At this stage, the QoS NSLP only uses the path-coupled routing MRM. The method-specific classifier data is two bytes long and consists of a set of flags: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |X|Y|P|T|F|S|A|B| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ " The field, as currently written, is not extensible to a different MRM. Hence, you have two options: * either enhance the field with a MRM type field, or * delete all the text that could give the reader the impression that there might in a later stage an extension that defines other packet classifiers based on other MRMs. Ciao Hannes _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Jul 16 05:43:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAN6b-0005J8-37; Mon, 16 Jul 2007 05:43:01 -0400 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1IAN6a-0005J3-Dt for nsis-confirm+ok@megatron.ietf.org; Mon, 16 Jul 2007 05:43:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAN6a-0005Iv-46 for nsis@ietf.org; Mon, 16 Jul 2007 05:43:00 -0400 Received: from rsys002x.roke.co.uk ([193.118.201.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IAN6T-000454-Mg for nsis@ietf.org; Mon, 16 Jul 2007 05:43: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 l6G9gaSM013369; Mon, 16 Jul 2007 10:42:36 +0100 Received: from [193.118.197.216] ([193.118.197.216]) by rsys005a.comm.ad.roke.co.uk with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Jul 2007 10:42:36 +0100 Message-ID: <469B3D8B.6040808@roke.co.uk> Date: Mon, 16 Jul 2007 10:42:35 +0100 From: Andrew McDonald User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Hannes Tschofenig Subject: Re: [NSIS] QoS NSLP, Packet Classifier References: <469A1AA5.80908@gmx.net> In-Reply-To: <469A1AA5.80908@gmx.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Jul 2007 09:42:36.0246 (UTC) FILETIME=[A432D760:01C7C78D] 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: 2409bba43e9c8d580670fda8b695204a 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 Hannes Tschofenig wrote: > Section 5.1.3.5 defines the Packet Classifier > > The text says: [snip] > > The field, as currently written, is not extensible to a different MRM. > Hence, you have two options: > > * either enhance the field with a MRM type field, or As a QoS NSLP you already have this information - it is carried in the MRI supplied to the NSLP from the GIST layer. In an earlier version we did have an explicit MRM type field, but this was removed. Since you already have the information from the GIST data it would just create further error cases to deal with, e.g. what happens if the NSLP and GIST MRM type indicators are in conflict? > * delete all the text that could give the reader the impression that > there might in a later stage an extension that defines other packet > classifiers based on other MRMs. The solution may be to add a sentence indicating more clearly how the NSLP knows what MRM type is being used. Andrew _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Jul 17 09:24:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAn2C-0002uN-Gw; Tue, 17 Jul 2007 09:24:12 -0400 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1IAn29-0002q0-Fn for nsis-confirm+ok@megatron.ietf.org; Tue, 17 Jul 2007 09:24:09 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAn29-0002oJ-40 for nsis@ietf.org; Tue, 17 Jul 2007 09:24:09 -0400 Received: from mail.uc.pt ([193.137.200.38] helo=mail-2.ci.uc.pt) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IAn27-00086G-Fi for nsis@ietf.org; Tue, 17 Jul 2007 09:24:09 -0400 Received: from mail-2.ci.uc.pt (mail.uc.pt [127.0.0.1]) by localhost.mail.uc.pt (Postfix) with ESMTP id D065888DE36 for ; Tue, 17 Jul 2007 14:24:05 +0100 (WEST) Received: from [127.0.0.1] (dhcp-eucpii-149.ci.uc.pt [193.136.207.149]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail-2.ci.uc.pt (Postfix) with ESMTP id B7C9F88DE35 for ; Tue, 17 Jul 2007 14:24:05 +0100 (WEST) Message-ID: <469CC2F2.80506@dei.uc.pt> Date: Tue, 17 Jul 2007 14:24:02 +0100 From: =?ISO-8859-1?Q?Lu=EDs_Cordeiro?= User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: NSIS Group Content-Type: multipart/mixed; boundary="------------010204010701010201070609" X-Spam-Score: 0.3 (/) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab Subject: [NSIS] [Fwd: I-D ACTION:draft-cordeiro-nsis-hypath-04.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 This is a multi-part message in MIME format. --------------010204010701010201070609 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear all,

The new version of the HyPath proposal has been submitted.

Please take some time to read this proposal so that it may be discussed in Chicago.

BR,
Luís Cordeiro

-------- Original Message --------
Subject: I-D ACTION:draft-cordeiro-nsis-hypath-04.txt
Date: Wed, 11 Jul 2007 14:15:02 -0400
From: Internet-Drafts@ietf.org
Reply-To: internet-drafts@ietf.org
To: i-d-announce@ietf.org 


A New Internet-Draft is available from the on-line Internet-Drafts 
directories.


	Title		: GIST Extension for Hybrid On-path Off-path Signaling (HyPath)
	Author(s)	: L. Cordeiro, et al.
	Filename	: draft-cordeiro-nsis-hypath-04.txt
	Pages		: 33
	Date		: 2007-7-11
	
In a multi-domain Internet that offers QoS guaranties for
   applications, there is the need of signaling among the domain
   entities that are responsible for the management of QoS.  Because
   different domains have different network protocols and topologies,
   the HyPath approach uses the NSIS protocol and interactions with the
   local routing protocols to have an off-path signaling in hybrid
   environments.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-cordeiro-nsis-hypath-04.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-cordeiro-nsis-hypath-04.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-cordeiro-nsis-hypath-04.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
--------------010204010701010201070609 Content-Type: Message/External-body; name="draft-cordeiro-nsis-hypath-04.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="draft-cordeiro-nsis-hypath-04.txt" Content-Type: text/plain Content-ID: <2007-7-11135713.I-D@ietf.org> --------------010204010701010201070609 Content-Type: text/plain; name="file:///C:/USERS/CORDEIRO/APPDATA/LOCAL/TEMP/nsmail.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename*0="file:///C:/USERS/CORDEIRO/APPDATA/LOCAL/TEMP/nsmail.txt" _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --------------010204010701010201070609 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 --------------010204010701010201070609-- From nsis-bounces@ietf.org Thu Jul 19 12:18:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBYhj-0001ze-9q; Thu, 19 Jul 2007 12:18:15 -0400 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1IBYhh-0001wO-RJ for nsis-confirm+ok@megatron.ietf.org; Thu, 19 Jul 2007 12:18:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBYhh-0001wG-Hd for nsis@ietf.org; Thu, 19 Jul 2007 12:18:13 -0400 Received: from mailer.gwdg.de ([134.76.10.26]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBYhg-0002sh-36 for nsis@ietf.org; Thu, 19 Jul 2007 12:18:13 -0400 Received: from s4.ifi.informatik.uni-goettingen.de ([134.76.81.226] helo=smtp.stud.informatik.uni-goettingen.de) by mailer.gwdg.de with esmtp (Exim 4.66) (envelope-from ) id 1IBYhf-0000jw-2k; Thu, 19 Jul 2007 18:18:11 +0200 Received: from [192.168.0.250] (p54848FD9.dip0.t-ipconnect.de [84.132.143.217]) by smtp.stud.informatik.uni-goettingen.de (Postfix) with ESMTP; Thu, 19 Jul 2007 18:18:10 +0200 (CEST) Message-ID: <469F8EA6.2020406@cs.uni-goettingen.de> Date: Thu, 19 Jul 2007 18:17:42 +0200 From: Bernd Schloer User-Agent: Thunderbird 1.5.0.7 (X11/20061008) MIME-Version: 1.0 To: Hannes Tschofenig Subject: Re: [NSIS] QoS NSLP -- INFO_SPEC References: <469A1437.1070801@gmx.net> In-Reply-To: <469A1437.1070801@gmx.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Level: - X-Virus-Scanned: (clean) by exiscan+sophie X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c 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, sorry for the late reply. In draft v.13 'Real Object Length' was 12 bit and 'Offset' was 16 bit long. 'Object' contains one or more erroneous objects. Object Value Info: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Rsvd | Real Object Length | Offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // Object // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Best regards, Bernd Hannes Tschofenig wrote: > Section 5.1.3.6 defines the INFO_SPEC object. > The object format is garbled and it is difficult to figure out how long > the fields are. > > > Object Value Info: > > 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | > Rsvd | Real Object Length | Offset | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > // Object // > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > How long are the individual fields? > > Ciao > Hannes > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Jul 20 12:25:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBvIP-0006Sd-MW; Fri, 20 Jul 2007 12:25:37 -0400 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1IBvIN-0006SX-Kw for nsis-confirm+ok@megatron.ietf.org; Fri, 20 Jul 2007 12:25:35 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBvIN-0006QL-AU for nsis@ietf.org; Fri, 20 Jul 2007 12:25:35 -0400 Received: from rotterdam.ewi.utwente.nl ([130.89.10.5]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBvIM-0006jB-RK for nsis@ietf.org; Fri, 20 Jul 2007 12:25:35 -0400 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by rotterdam.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id l6KGPOfv027011; Fri, 20 Jul 2007 18:25:33 +0200 (MEST) From: "Georgios Karagiannis" To: "'Hannes Tschofenig'" , References: <469A1437.1070801@gmx.net> Subject: RE: [NSIS] QoS NSLP -- INFO_SPEC Date: Fri, 20 Jul 2007 18:25:19 +0200 Message-ID: <002901c7caea$935333d0$4c0d5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <469A1437.1070801@gmx.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: AcfG3IFv7yjP0mJiSlaB9y5RXvyopAEDfcWQ X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.52 on 130.89.10.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (rotterdam.ewi.utwente.nl [130.89.10.5]); Fri, 20 Jul 2007 18:25:33 +0200 (MEST) X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa 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 Hannes Thank you very much for the comment! We will take care of it! Best Regards, Georgios > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > Sent: zondag 15 juli 2007 14:34 > To: nsis@ietf.org > Subject: [NSIS] QoS NSLP -- INFO_SPEC > > Section 5.1.3.6 defines the INFO_SPEC object. > The object format is garbled and it is difficult to figure > out how long the fields are. > > > Object Value Info: > > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | > Rsvd | Real Object Length | Offset | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > // Object // > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > How long are the individual fields? > > Ciao > Hannes > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Jul 23 06:55:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICvZO-0000T1-E0; Mon, 23 Jul 2007 06:55:18 -0400 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1ICvZN-0000Sh-1R for nsis-confirm+ok@megatron.ietf.org; Mon, 23 Jul 2007 06:55:17 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICvZM-0000SY-N7 for nsis@ietf.org; Mon, 23 Jul 2007 06:55:16 -0400 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ICvZM-0000nW-9k for nsis@ietf.org; Mon, 23 Jul 2007 06:55:16 -0400 Received: from [192.168.178.25] (mnhm-590c08e4.pool.einsundeins.de [89.12.8.228]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 6C63813CF81 for ; Mon, 23 Jul 2007 12:55:11 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v752.3) To: nsis Message-Id: From: Martin Stiemerling Date: Mon, 23 Jul 2007 12:55:15 +0200 X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Subject: [NSIS] Updated meeting agenda and presentations for IETF-69 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="===============1027986564==" Errors-To: nsis-bounces@ietf.org --===============1027986564== Content-Type: multipart/alternative; boundary=Apple-Mail-23-722485004 --Apple-Mail-23-722485004 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hi all, The latest agenda and the presentations have been uploaded for the IETF-69 session to this web page: https://datatracker.ietf.org/meeting/69/materials.html I will be around for the NSIS session during the IETF meeting, i.e., participating by Jabber and audio. Have a nice session Martin stiemerling@netlab.nec.de NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 --Apple-Mail-23-722485004 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Hi all,

The latest agenda and the = presentations have been uploaded for the IETF-69 session to this web = page:


I will be around for the = NSIS session during the IETF meeting, i.e., participating by Jabber and = audio.

Have a = nice session

=A0= Martin

stiemerling@netlab.nec.de
NEC Europe Limited |=A0Registered Office: NEC House, = 1 Victoria Road, London W3 6BL |=A0Registered in England = 2832014

=

= --Apple-Mail-23-722485004-- --===============1027986564== 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 --===============1027986564==-- From nsis-bounces@ietf.org Mon Jul 23 12:46:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ID13d-00044v-MW; Mon, 23 Jul 2007 12:46:53 -0400 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1ID13b-00044m-Jh for nsis-confirm+ok@megatron.ietf.org; Mon, 23 Jul 2007 12:46:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ID13b-00044d-9w for nsis@ietf.org; Mon, 23 Jul 2007 12:46:51 -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 1ID13Z-0003ME-Ih for nsis@ietf.org; Mon, 23 Jul 2007 12:46:51 -0400 Received: from sbz-30.cs.helsinki.fi (sbz-30.cs.helsinki.fi [128.214.9.98]) (TLS: TLSv1/SSLv3,256bits,AES256-SHA) by mail.cs.helsinki.fi with esmtp; Mon, 23 Jul 2007 19:46:48 +0300 id 0005FF26.46A4DB78.000033A1 Date: Mon, 23 Jul 2007 19:46:48 +0300 (EEST) From: Jukka MJ Manner To: Roland Bless Subject: Re: [NSIS] Reminder WGLC:draft-ietf-nsis-qos-nslp-14.txt In-Reply-To: <468A1735.7070408@tm.uka.de> Message-ID: References: <071568CA7B789D4AA170CEF8C9613B4FB11B80@daebe103.NOE.Nokia.com> <892AE2E7-643F-492D-8695-609C87BE7DC4@netlab.nec.de> <468A1735.7070408@tm.uka.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 2a9ffb6f997442a3b543bcdaf483b990 Cc: Andrew McDonald , Georgios Karagiannis , nsis-chairs@tools.ietf.org, nsis X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi, A couple of comments to your most important things from me and Georgios. Thanks for the review. See below. Jukka On Tue, 3 Jul 2007, Roland Bless wrote: > Hi all, > > Martin Stiemerling wrote: > > Just to remind you about the currently running WGLC for the QoS NSLP. > > A simple mail saying that the draft is ready for publication would be great. > > I reread the whole draft (sorry for being late, but several other > activities interrupted me) and have some minor comments only. > So I would say that's it's ready for IESG review after the next > update. > > The most important things first: > =================================================================== > * Section 4.3: Refreshing receiver-initiated reservations... > "are set up. The reservation can subsequently be refreshed with > RESERVE messages in the same way as for the sender-initiated > approach." > Is a little bit to vague for me. Are the refreshing RESERVE messages > now sent downstream? I guess so because otherwise re-routing > detection would not work. So it should be made clear that the > RESERVE messages are only sent in reverse direction for the initial > state installation, but that the refreshing RESERVE messages are > sent as usually in flow direction. No, the text is misleading. The refreshes are also sent in the same direction as the initial RESERVE. I'll fix the text to be more specific. > > * Section 4.5: there seem to be remnants stacking concept > which was removed: > > RESERVE message to be sent out is constructed mostly as usual but > with a second QSPEC object added on top, which becomes the 'current' > one. > > as well as > > A message can contain at most two QSPEC objects, i.e., the end-to-end > QSPEC and a local QSPEC. > > Probably this could replaced by something like: > The local QoS model (QoSM2) can define its own local QSPEC that > also contains the original QSPEC from QoSM1. Yes, my bad. Will fix. > > * Section 5.1.2.1 RESERVE > Q-Flag: > > REQUEST REDUCED REFRESHES (Q) - when set, indicates the sender of > the RESERVE proposes to use the reduced refresh for this session. > > I really don't know what this should be good for (or maybe I forgot). > IMHO this is not necessary, because the QNE can simply try to sent > a reduced refresh. If this cannot be supported by the peer, it will > answer with > * 0x03 - Reduced refreshes not supported, full QSPEC required. > In this case the QNE should continue to always send full refreshes to > this peer. > I also don't see any description in the draft of what should happen > according to this bit. > So I don't think that the flag is useful and I am in favor of removing > it. Yes, again. Good point. THis is not needed anymore. Will remove. > > * TEARing RESERVE in which direction and REPLACE flag. > As far as I understood, it should be possible for a node > to remove reservations at the old branch explicitly. This > is at least what I read from 5.1.4: > > The default behavior of a QNE that receives a RESERVE with a > SESSION_ID for which it already has state installed but with a > different flow ID is to replace the existing reservation (and tear > down the reservation on the old branch if the RESERVE is received > with a different SII). > > I'm a little bit confused which node will tear down the > reservation on the old branch. Sometimes we have a node where > the routes diverge and sometimes we have a node where route > converge and sometimes we have both. In the above description: > if a QNE receives a RESERVE with a different > SII it's obviously a node where routes converge again. > Otherwise it would be a QNE sending a RESERVE along a > new SII (this would be indicated by GIST). > > So a more concrete example: > +-+ > /--|B|--\ > / +-+ \ > +-+ +-+ > ----|A| |D|---- > +-+ +-+ > \ +-+ / > \--|C|--/ > +-+ > > Let's assume that the MRI is unchanged. > Flow is A->B->D at first. After re-routing happens > the new route is A->C->D. It would make sense that > node A will try to remove the old branch, so it > may send a RESERVE w/ TEAR along the old path. > D will not forward the tearing RESERVE, because > it knows, that the TEAR came along the old branch. > > But would it be also possible for node D to send > a tearing reserve in the reverse direction (upstream)? > This is current not allowed by 5.1.4: > "RESERVE messages MUST only be sent towards the QNR." > The signaling mobility draft has an example where > node D sends a tearing reserve in reverse direction. > The situation there is different since there is no branching > A; it can be considered as the MN moving between ARs B and C. > In this case only D can send the tearing RESERVE. > So if it is allowed for D to send a tearing RESERVE, > how would it be coordinated with the branching node A? This works in the same way as in the mobility case. Node D sends a NOTIFY on the old path, saying "Route Change Happened". This will be eventually forwarded to A, which obviously knows that the route changed, and can tear down explicitly the old branch. Node D will in its turn get the tear, and stop the tearing process there. > > ============================================== > Now the minor stuff: > * Introduction: > e.g., edge-to-edge, end-to-access, etc. On the other hand, there is > no support for IP multicast. > > The GIST draft mentions that multicast support may be added later and > I'll like to see something similar in here. Probably adding the word > "currently" is enough: there is currently no support for IP multicast. > > * p. 12: All QSPECs must follow the QSPEC template > [I-D.ietf-nsis-qspec]. > I'm not sure whether a must is too strong here. > Local QSPECs may be different from the e2e-QSPEC. > Probably this one is better: > All QSPECs should follow the design of the > QSPEC template. > > * p. 13: change > "may cause removal of an earlier reservation." > into > "may cause removal of an earlier admitted reservation." > (or "established" if you like). > > * p. 26: 3.3.5 > > this difference can set the "B" (BREAK) flag. > > What means can here? better use may or should? > > * P. 37: Sec. 4.7 > - probably we need to mention that retransmissions > can only be expected if an RII was set. > - it's not clear that it's better to use a > MsgIDWait timeout longer than the retransmission > timer. We may change that. > > * p.39: Sec 4.8.1 > It should be mentioned that the message binding > can be used to synchronize the messages. > > * p. 45: 5.1.2.1 > A "reservation collision" may occur if the sender believes that a > It is not clear to me how such a collision would occur. What would > be the reason for such a collision. Could you give an example? > > * p. 46: 5.1.2.1 > resulting refresh is a new RESERVE. This RESERVE includes a new MRI > and will be propagated end-to-end without requesting a RESPONSE. > > It is meant that "will be propagated end-to-end _even_ without > requesting a RESPONSE." But additionally it may also include an RII, > so I would suggest to rephrase it as it may sound that an RII > must not be included. > * p. 5.1.3.7/5.1.3.8: > As I got feedback from our implementer: it would be easier to > parse if we had also a combined list of SID/RSN tuples. > > ============================================== > Typos: > p.12: missing closing parenthesis: > flag in the common header). > ^ > additional blank line (as in several places in the doc, please check): > requested will usually contain objects which need to be understood by > > all implementations, and it can also be enhanced with additional > > p.13: period missing or incomplete sentence? > "Authentication may be required." > The authorization of a resource request often depends on the identity > of the entity making the request. Authentication may be required The > > p.22: 3.2.12.1 > "D. The signaling path initially ends at C, but this node is not on" > must be change to: > "D. The signaling path initially ends at B, but this node is not on" > p.23: 3.2.12.2 > "its API to the NSLP with a NetworkNotification. The QoS NSLP at A > will then attempt to repair the path by installing the reservation on > the path'." > > There is no path' defined. Probably better use: installing the > reservation on path (2),(3). > > p.24: Typo: > This in the peer from which it was receiving RESERVE messages. > s/in /is / > > p.27: > [I-D.ietf-nsis-qspec]. For example, in a RMD-QOSM > s/a /an / > > p. 29: > "to GIST to be forwarded back down the path." > back down may be confusing, because the direction is upstream. > > p. 29: s/prepated/prepared > > P. 36: Sec 4.7 > Wrong reference to Figure 15 (two times) > should be 14. > > p. 43: s/P -QNE/P-QNE > p. 44: s/mesasages/messages > p. 54: insert a CRLF before "o Protocol Error" > p. 57: Object Value Info format is messed up. > p. 79: s/decice/decide > > ------------------------------------------------------------------ > Regards, > Roland > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Jul 23 17:13:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ID5DH-0007DM-UV; Mon, 23 Jul 2007 17:13:07 -0400 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1ID5DH-0007C4-55 for nsis-confirm+ok@megatron.ietf.org; Mon, 23 Jul 2007 17:13:07 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ID5DG-00079u-9l for nsis@ietf.org; Mon, 23 Jul 2007 17:13:06 -0400 Received: from courier.cs.helsinki.fi ([128.214.9.1] helo=mail.cs.helsinki.fi) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ID5DF-0002Vp-1T for nsis@ietf.org; Mon, 23 Jul 2007 17:13:05 -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, 24 Jul 2007 00:13:03 +0300 id 00060193.46A519DF.00000DA8 Date: Tue, 24 Jul 2007 00:13:03 +0300 (EEST) From: Jukka MJ Manner To: Roland Bless Subject: Re: [NSIS] Reminder WGLC:draft-ietf-nsis-qos-nslp-14.txt In-Reply-To: <468A1735.7070408@tm.uka.de> Message-ID: References: <071568CA7B789D4AA170CEF8C9613B4FB11B80@daebe103.NOE.Nokia.com> <892AE2E7-643F-492D-8695-609C87BE7DC4@netlab.nec.de> <468A1735.7070408@tm.uka.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: Andrew McDonald , Georgios Karagiannis , nsis X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org A follow-up to Roland's first comment, in the case where the route changes. See below. On Tue, 3 Jul 2007, Roland Bless wrote: > =================================================================== > * Section 4.3: Refreshing receiver-initiated reservations... > "are set up. The reservation can subsequently be refreshed with > RESERVE messages in the same way as for the sender-initiated > approach." > Is a little bit to vague for me. Are the refreshing RESERVE messages > now sent downstream? I guess so because otherwise re-routing > detection would not work. So it should be made clear that the > RESERVE messages are only sent in reverse direction for the initial > state installation, but that the refreshing RESERVE messages are > sent as usually in flow direction. > Roland and I had a chat about what happens, if the route changes during a receiver-initiated reservation? In the sender-initiated it is quite clear, just send a full refresh on the new path. Using Roland's previous picture: +-+ /--|B|--\ QNR / +-+ \ QNI +------+ +-+ +-+ +------+ | Data |-----|A| |D|----| Data | |sender| +-+ +-+ | recv | ++++++++ \ +-+ / +------+ \--|C|--/ +-+ * Data is flowing through A-B-D. * QUERY is sent through A-B-D. * RESERVE and refresh RESERVE and sent through D-B-A. After a route change through C with the receiver-initiated case, D is sending a refresh to B, while data is coming through C. Now, A is in a key position here. It should get from GIST a network notification saying that routing has changed. A can then send a QUERY through C, which then sends a QUERY to D. Now D will notice that the next hop for the given MRI has changed, and can send subsequent refreshes through C. Is this description correct? If so, then for the R-I reservations, nodes should store enough information to enable them to send QUERY messages in the middle of a session, after a routing change. Jukka _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Jul 24 16:13:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDQkf-0002vL-Sj; Tue, 24 Jul 2007 16:13:01 -0400 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1IDQke-0002vF-FG for nsis-confirm+ok@megatron.ietf.org; Tue, 24 Jul 2007 16:13:00 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDQke-0002v6-28 for nsis@ietf.org; Tue, 24 Jul 2007 16:13:00 -0400 Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IDQkd-0005g9-82 for nsis@ietf.org; Tue, 24 Jul 2007 16:12:59 -0400 Received: from irams2.ira.uni-karlsruhe.de ([141.3.10.82]) by iramx2.ira.uni-karlsruhe.de with esmtps id 1IDQkZ-0000tg-MX; Tue, 24 Jul 2007 22:12:57 +0200 Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5]) by irams2.ira.uni-karlsruhe.de with esmtps id 1IDQkY-0005dW-An; Tue, 24 Jul 2007 22:12:55 +0200 Received: from i72ms.tm.uni-karlsruhe.de ([141.3.70.5] helo=smtp.ipv6.tm.uni-karlsruhe.de) by irams1.ira.uni-karlsruhe.de with esmtps id 1IDQkX-0004P7-Pa; Tue, 24 Jul 2007 22:12:53 +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 536DA2FC015; Tue, 24 Jul 2007 22:12:53 +0200 (CEST) Received: from localhost ([127.0.0.1]) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.44) id 1IDQkW-0002Z3-GD; Tue, 24 Jul 2007 22:12:52 +0200 Message-ID: <46A65D42.9050609@tm.uka.de> Date: Tue, 24 Jul 2007 22:12:50 +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: Jukka MJ Manner Subject: Re: [NSIS] Reminder WGLC:draft-ietf-nsis-qos-nslp-14.txt References: <071568CA7B789D4AA170CEF8C9613B4FB11B80@daebe103.NOE.Nokia.com> <892AE2E7-643F-492D-8695-609C87BE7DC4@netlab.nec.de> <468A1735.7070408@tm.uka.de> In-Reply-To: X-Enigmail-Version: 0.94.4.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Status: No X-Spam-Score: -1.4 (-) X-Spam-Report: -1.4 ALL_TRUSTED Passed through trusted hosts only via SMTP 0.1 AWL AWL: From: address is in the auto white-list X-Spam-Host: irams2.ira.uni-karlsruhe.de X-ATIS-Checksum: v3zoCAcc32ckk X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: Andrew McDonald , Georgios Karagiannis , nsis X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Jukka, and all Jukka MJ Manner wrote: > A follow-up to Roland's first comment, in the case where the route > changes. See below. > > On Tue, 3 Jul 2007, Roland Bless wrote: > >> =================================================================== >> * Section 4.3: Refreshing receiver-initiated reservations... >> "are set up. The reservation can subsequently be refreshed with >> RESERVE messages in the same way as for the sender-initiated >> approach." >> Is a little bit to vague for me. Are the refreshing RESERVE messages >> now sent downstream? I guess so because otherwise re-routing >> detection would not work. So it should be made clear that the >> RESERVE messages are only sent in reverse direction for the initial >> state installation, but that the refreshing RESERVE messages are >> sent as usually in flow direction. This would make the handling of route changes easier, but the problem is that the RESERVE is flowing into the "wrong" direction. So in order to retain the differences of receiver-initiated reservations and sender-initiated reservations we should try to send RESERVE only in the same direction. > Roland and I had a chat about what happens, if the route changes during a > receiver-initiated reservation? In the sender-initiated it is quite clear, > just send a full refresh on the new path. > > Using Roland's previous picture: > > +-+ > /--|B|--\ > QNR / +-+ \ QNI > +------+ +-+ +-+ +------+ > | Data |-----|A| |D|----| Data | > |sender| +-+ +-+ | recv | > ++++++++ \ +-+ / +------+ > \--|C|--/ > +-+ > > * Data is flowing through A-B-D. > * QUERY is sent through A-B-D. > * RESERVE and refresh RESERVE and sent through D-B-A. > > After a route change through C with the receiver-initiated case, D is > sending a refresh to B, while data is coming through C. Now, A is in a key > position here. It should get from GIST a network notification saying that > routing has changed. A can then send a QUERY through C, which then sends a At latest GIST probing will discover a new next peer for this data flow. This will initiate the notification about the route change at A. The problem is that only the GIST peering is renewed, so as long as there is no NSLP message flowing, signaling stops at C. The correct way of handling this would indeed be letting A sending an end-to-end QUERY for receiver-initiated reservation. This will then be routed to C. C will route the QUERY to D and thereby establish a new GIST peering between C and D. > QUERY to D. Now D will notice that the next hop for the given MRI has > changed, and can send subsequent refreshes through C. Actually it shouldn't be a refresh, because resources must be reserved anew. D should directly send a new RESERVE upstream to C (if it would only try to send a refreshing RESERVE to C, it would get an error back that a full QSPEC is required). The interesting question is now whether the forwarding of the QUERY should stop at D. > Is this description correct? If so, then for the R-I reservations, nodes I guess that it boils down to two things: 1) requiring that a node, which has a receiver-initiated reservation, sends a QUERY after detecting a downstream route change. This is necessary, because the route change must be propagated up to the node where the routes converge again and GIST cannot really route upstream (except for probably limited cases). 2) letting a node initiating a RESERVE upstream as soon as it detects an upstream route change (in this case we hopefully have a complete signaling path upstream). This is required in order to try to install the resource reservation along the new path. > should store enough information to enable them to send QUERY messages in > the middle of a session, after a routing change. This shouldn't be a problem IMHO unless the node is stateless... On the other hand a NULL Query is probably sufficient, because node D must issue a RESERVE with a full QSPEC anyway. Regards, Roland _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Jul 24 16:37:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDR85-00034h-Gd; Tue, 24 Jul 2007 16:37:13 -0400 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1IDR84-00034c-0D for nsis-confirm+ok@megatron.ietf.org; Tue, 24 Jul 2007 16:37:12 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDR83-00034U-LM for nsis@ietf.org; Tue, 24 Jul 2007 16:37:11 -0400 Received: from courier.cs.helsinki.fi ([128.214.9.1] helo=mail.cs.helsinki.fi) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IDR82-0006GP-RM for nsis@ietf.org; Tue, 24 Jul 2007 16:37:11 -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, 24 Jul 2007 23:37:09 +0300 id 0005FEB7.46A662F5.0000018B Date: Tue, 24 Jul 2007 23:37:09 +0300 (EEST) From: Jukka MJ Manner To: Roland Bless Subject: Re: [NSIS] Reminder WGLC:draft-ietf-nsis-qos-nslp-14.txt In-Reply-To: <46A65D42.9050609@tm.uka.de> Message-ID: References: <071568CA7B789D4AA170CEF8C9613B4FB11B80@daebe103.NOE.Nokia.com> <892AE2E7-643F-492D-8695-609C87BE7DC4@netlab.nec.de> <468A1735.7070408@tm.uka.de> <46A65D42.9050609@tm.uka.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Cc: Andrew McDonald , Georgios Karagiannis , nsis X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi, based on our discussion a minute ago, the proposal below works with a small update: the node D must wait for the NSLP QUERY to arrive before sending the full RESERVE, in order to make sure the upstream (reverse) path is properly set up - so a network notification is not yet enough for sending the RESERVE. Jukka On Tue, 24 Jul 2007, Roland Bless wrote: > Hi Jukka, and all > > Jukka MJ Manner wrote: > > A follow-up to Roland's first comment, in the case where the route > > changes. See below. > > > > On Tue, 3 Jul 2007, Roland Bless wrote: > > > >> =================================================================== > >> * Section 4.3: Refreshing receiver-initiated reservations... > >> "are set up. The reservation can subsequently be refreshed with > >> RESERVE messages in the same way as for the sender-initiated > >> approach." > >> Is a little bit to vague for me. Are the refreshing RESERVE messages > >> now sent downstream? I guess so because otherwise re-routing > >> detection would not work. So it should be made clear that the > >> RESERVE messages are only sent in reverse direction for the initial > >> state installation, but that the refreshing RESERVE messages are > >> sent as usually in flow direction. > > This would make the handling of route changes easier, but the problem > is that the RESERVE is flowing into the "wrong" direction. So in order > to retain the differences of receiver-initiated reservations and > sender-initiated reservations we should try to send RESERVE only in the > same direction. > > > Roland and I had a chat about what happens, if the route changes during a > > receiver-initiated reservation? In the sender-initiated it is quite clear, > > just send a full refresh on the new path. > > > > Using Roland's previous picture: > > > > +-+ > > /--|B|--\ > > QNR / +-+ \ QNI > > +------+ +-+ +-+ +------+ > > | Data |-----|A| |D|----| Data | > > |sender| +-+ +-+ | recv | > > ++++++++ \ +-+ / +------+ > > \--|C|--/ > > +-+ > > > > * Data is flowing through A-B-D. > > * QUERY is sent through A-B-D. > > * RESERVE and refresh RESERVE and sent through D-B-A. > > > > After a route change through C with the receiver-initiated case, D is > > sending a refresh to B, while data is coming through C. Now, A is in a key > > position here. It should get from GIST a network notification saying that > > routing has changed. A can then send a QUERY through C, which then sends a > > At latest GIST probing will discover a new next peer for this > data flow. This will initiate the notification about the route change > at A. The problem is that only the GIST peering is renewed, so as long > as there is no NSLP message flowing, signaling stops at C. The correct > way of handling this would indeed be letting A sending an end-to-end > QUERY for receiver-initiated reservation. This will then be routed to > C. C will route the QUERY to D and thereby establish a new GIST peering > between C and D. > > > QUERY to D. Now D will notice that the next hop for the given MRI has > > changed, and can send subsequent refreshes through C. > > Actually it shouldn't be a refresh, because resources must be reserved > anew. D should directly send a new RESERVE upstream to C (if it would > only try to send a refreshing RESERVE to C, it would get an error back > that a full QSPEC is required). The interesting question is now whether > the forwarding of the QUERY should stop at D. > > > Is this description correct? If so, then for the R-I reservations, nodes > > I guess that it boils down to two things: > 1) requiring that a node, which has a receiver-initiated reservation, > sends a QUERY after detecting a downstream route change. This is > necessary, because the route change must be propagated up to the > node where the routes converge again and GIST cannot really route > upstream (except for probably limited cases). > 2) letting a node initiating a RESERVE upstream as soon as it > detects an upstream route change (in this case we hopefully > have a complete signaling path upstream). This is required > in order to try to install the resource reservation along the > new path. > > > should store enough information to enable them to send QUERY messages in > > the middle of a session, after a routing change. > > This shouldn't be a problem IMHO unless the node is stateless... > On the other hand a NULL Query is probably sufficient, because > node D must issue a RESERVE with a full QSPEC anyway. > > Regards, > Roland > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Jul 25 10:13:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDhcP-0000zu-8e; Wed, 25 Jul 2007 10:13:37 -0400 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1IDhcN-0000zp-Vw for nsis-confirm+ok@megatron.ietf.org; Wed, 25 Jul 2007 10:13:35 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDhcN-0000zh-Lg for nsis@ietf.org; Wed, 25 Jul 2007 10:13:35 -0400 Received: from courier.cs.helsinki.fi ([128.214.9.1] helo=mail.cs.helsinki.fi) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IDhcN-0004JS-Ap for nsis@ietf.org; Wed, 25 Jul 2007 10:13:35 -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; Wed, 25 Jul 2007 17:13:34 +0300 id 0005FEAB.46A75A8E.000025D6 Date: Wed, 25 Jul 2007 17:13:34 +0300 (EEST) From: Jukka MJ Manner To: NSIS Working Group Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Subject: [NSIS] QoS NSLP: Done? 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 have made the changes to the QoS NSLP based on WGLC feedback. Two types of diffs and the current draft are at: http://www.cs.helsinki.fi/u/jmanner/qos-nslp/ I intend to submit the draft this week and ask the chairs for an AD review, unless someone has objections. Regards, Jukka _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Jul 25 10:57:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDiJ6-0004z7-E9; Wed, 25 Jul 2007 10:57:44 -0400 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1IDiJ5-0004z1-59 for nsis-confirm+ok@megatron.ietf.org; Wed, 25 Jul 2007 10:57:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDiJ4-0004yt-Rf for nsis@ietf.org; Wed, 25 Jul 2007 10:57:42 -0400 Received: from web27805.mail.ukl.yahoo.com ([217.146.182.10]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IDiJ3-0000kn-Ut for nsis@ietf.org; Wed, 25 Jul 2007 10:57:42 -0400 Received: (qmail 13421 invoked by uid 60001); 25 Jul 2007 14:57:41 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.de; h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=Ww9OZTYhUY3GKcGjVtQ4l5WysPK0kTiy38NsZapDg4bvlN4DWvlAR1RTI2on7G0AGn/a0JeLj3MTA4tzfbf+tW2uKntt0ASaPUPc1huCfm/gjh7OjXQgvShcKatXPplbkJuZHI9CWLRISOg9XjlJ9bqvHWZyUHAbcIxAsHCGwfw=; X-YMail-OSG: _gRnfqgVM1mSyF3wwBe4lRSEsQMl3iOCOOzqqc_Z2kFozeichp9Wp0MvugXjw4Oo523pSD4TgVSSsvN3Ku8hP1XSTKwcMvQyAuBVFte2vMGipR0E Received: from [192.35.17.15] by web27805.mail.ukl.yahoo.com via HTTP; Wed, 25 Jul 2007 14:57:41 GMT X-Mailer: YahooMailRC/651.41 YahooMailWebService/0.7.119 Date: Wed, 25 Jul 2007 14:57:41 +0000 (GMT) From: Mehmet Ersue Subject: RE: [NSIS] QoS NSLP: Done? To: jmanner@cs.Helsinki.FI MIME-Version: 1.0 Message-ID: <333008.12843.qm@web27805.mail.ukl.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: NSIS X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0875320729==" Errors-To: nsis-bounces@ietf.org --===============0875320729== Content-Type: multipart/alternative; boundary="0-1469110087-1185375461=:12843" --0-1469110087-1185375461=:12843 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable =0AHi Jukka,=0A=0AI think the draft is readable, reasonably complete and re= ady for AD review.=0A=0AMehmet =0A=0A=0A> -----Original Message-----=0A> Fr= om: ext Jukka MJ Manner [mailto:jmanner@cs.Helsinki.FI] =0A> Sent: Wednesda= y, July 25, 2007 4:14 PM=0A> To: NSIS Working Group=0A> Subject: [NSIS] QoS= NSLP: Done?=0A> =0A> =0A> Hi all,=0A> =0A> I have made the changes to the = QoS NSLP based on WGLC =0A> feedback. Two types =0A> of diffs and the curre= nt draft are at:=0A> =0A> http://www.cs.helsinki.fi/u/jmanner/qos-nslp/=0A>= =0A> I intend to submit the draft this week and ask the chairs for an AD = =0A> review, unless someone has objections.=0A> =0A> Regards,=0A> Jukka=0A>= =0A> =0A> _______________________________________________=0A> nsis mailing= list=0A> nsis@ietf.org=0A> https://www1.ietf.org/mailman/listinfo/nsis=0A>= =0A=0A=0A=0A=0A dddd --0-1469110087-1185375461=:12843 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable

Hi Jukka,

I think the draft is readable, reasonably comp= lete and ready for AD review.

Mehmet


> -----Original = Message-----
> From: ext Jukka MJ Manner [mailto:jmanner@cs.Helsinki.= FI]
> Sent: Wednesday, July 25, 2007 4:14 PM
> To: NSIS Workin= g Group
> Subject: [NSIS] QoS NSLP: Done?
>
>
> H= i all,
>
> I have made the changes to the QoS NSLP based on WG= LC
> feedback. Two types
> of diffs and the current draft are= at:
>
> http://www.cs.helsinki.fi/u/jmanner/qos-nslp/<= /a>
>
> I intend to submit the draft this week and ask = the chairs for an AD
> review, unless someone has objections.
>= ;
> Regards,
> Jukka
>
>
> ________________= _______________________________
> nsis mailing list
> nsis@ietf= .org
> https://www1.ietf.org/mailman/listinfo/nsis>

=0A=0A=0A
Jetzt Mails schnell i= n einem Vorschaufenster =FCberfliegen. Dies und viel mehr bietet das =0Aneue Yahoo! Mail. =0A --0-1469110087-1185375461=:12843-- --===============0875320729== 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 --===============0875320729==-- From nsis-bounces@ietf.org Wed Jul 25 13:28:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDkei-0005XL-FH; Wed, 25 Jul 2007 13:28:12 -0400 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1IDkeZ-0005UD-RS for nsis-confirm+ok@megatron.ietf.org; Wed, 25 Jul 2007 13:28:04 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDkeZ-0005U3-GD for nsis@ietf.org; Wed, 25 Jul 2007 13:28:03 -0400 Received: from amailer.gwdg.de ([134.76.10.18]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IDkeZ-0003Nc-2V for nsis@ietf.org; Wed, 25 Jul 2007 13:28:03 -0400 Received: from p5b03bbcf.dip0.t-ipconnect.de ([91.3.187.207] helo=[192.168.0.183]) by mailer.gwdg.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.66) (envelope-from ) id 1IDkeY-0003U5-3J for nsis@ietf.org; Wed, 25 Jul 2007 19:28:02 +0200 Message-ID: <46A7881A.8020801@cs.uni-goettingen.de> Date: Wed, 25 Jul 2007 19:27:54 +0200 From: Xiaoming Fu User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: nsis Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated: Id:xfu X-Spam-Level: - X-Virus-Scanned: (clean) by exiscan+sophie X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Subject: [NSIS] FW: I-D ACTION:draft-kappler-nsis-qosmodel-controlledload-05.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 Hi all, We have updated the ID on signaling CLS using NSIS, and diff to previous version can be found in: http://user.informatik.uni-goettingen.de/~fu/nsis/cls_qosm/draft-kappler-nsis-qosmodel-controlledload-05_diff_04.html More specifically, we updated the usage examples and interoperation with RSVP section according to the new version of QoS NSLP and QSPEC, and incorporated comments received in previous discussions in the ML and IETF meetings. Your comments, suggestions are appreciated. Xiaoming On Wed, 25 Jul 2007 12:15:01 -0400, Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : A QoS Model for Signaling IntServ Controlled-Load Service with NSIS > Author(s) : C. Kappler, et al. > Filename : draft-kappler-nsis-qosmodel-controlledload-05.txt > Pages : 25 > Date : 2007-7-25 > > This document describes a QoS Model to signal IntServ controlled load > service with QoS NSLP. QoS NSLP is QoS Model agnostic. All QoS > Model specific information is carried in an opaque object, the QSPEC. > This document hence specifies the QSPEC for controlled load service, > how the QSPEC must be processed in QoS NSLP nodes, and how QoS NSLP > messages must be used. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-kappler-nsis-qosmodel-controlledload-05.txt _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Jul 30 14:15:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFZmJ-0005Q0-0q; Mon, 30 Jul 2007 14:15:35 -0400 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1IFZmH-0005PF-DW for nsis-confirm+ok@megatron.ietf.org; Mon, 30 Jul 2007 14:15:33 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFZmH-0005P7-1R; Mon, 30 Jul 2007 14:15:33 -0400 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IFZmG-00058N-Hm; Mon, 30 Jul 2007 14:15:32 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 646FE2AC6B; Mon, 30 Jul 2007 18:15:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IFZlm-0007W4-2j; Mon, 30 Jul 2007 14:15: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, 30 Jul 2007 14:15:02 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: nsis@ietf.org Subject: [NSIS] I-D ACTION:draft-ietf-nsis-qos-nslp-15.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 : NSLP for Quality-of-Service Signaling Author(s) : J. Manner, et al. Filename : draft-ietf-nsis-qos-nslp-15.txt Pages : 97 Date : 2007-7-30 This specification describes the NSIS Signaling Layer Protocol (NSLP) for signaling QoS reservations in the Internet. It is in accordance with the framework and requirements developed in NSIS. Together with GIST, it provides functionality similar to RSVP and extends it. The QoS NSLP is independent of the underlying QoS specification or architecture and provides support for different reservation models. It is simplified by the elimination of support for multicast flows. This specification explains the overall protocol approach, design decisions made and provides examples. It specifies object, message formats and processing rules. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nsis-qos-nslp-15.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-qos-nslp-15.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-qos-nslp-15.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: <2007-7-30130540.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nsis-qos-nslp-15.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nsis-qos-nslp-15.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-7-30130540.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 Tue Jul 31 05:46:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFoIy-0004yW-5E; Tue, 31 Jul 2007 05:46:16 -0400 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1IFoIw-0004yR-U9 for nsis-confirm+ok@megatron.ietf.org; Tue, 31 Jul 2007 05:46:15 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFoIt-0004yI-EV for nsis@ietf.org; Tue, 31 Jul 2007 05:46:11 -0400 Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IFoIs-0000Lm-R6 for nsis@ietf.org; Tue, 31 Jul 2007 05:46:11 -0400 Received: from irams2.ira.uni-karlsruhe.de ([141.3.10.82]) by iramx2.ira.uni-karlsruhe.de with esmtps id 1IFoIp-000408-1u; Tue, 31 Jul 2007 11:46:08 +0200 Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5]) by irams2.ira.uni-karlsruhe.de with esmtps id 1IFoIn-0001Is-K9; Tue, 31 Jul 2007 11:46:06 +0200 Received: from i72ms.tm.uni-karlsruhe.de ([141.3.70.5] helo=smtp.ipv6.tm.uni-karlsruhe.de) by irams1.ira.uni-karlsruhe.de with esmtps id 1IFoIn-0004z4-0Z; Tue, 31 Jul 2007 11:46:05 +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 17EEF2FC015; Tue, 31 Jul 2007 11:46:02 +0200 (CEST) Received: from localhost ([127.0.0.1]) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.44) id 1IFoIj-0003mR-S2; Tue, 31 Jul 2007 11:46:01 +0200 Message-ID: <46AF0433.3060606@tm.uka.de> Date: Tue, 31 Jul 2007 11:43:15 +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" X-Enigmail-Version: 0.94.4.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-Spam-Status: No X-Spam-Score: -1.4 (-) X-Spam-Report: -1.4 ALL_TRUSTED Passed through trusted hosts only via SMTP 0.1 AWL AWL: From: address is in the auto white-list X-Spam-Host: irams2.ira.uni-karlsruhe.de X-ATIS-Checksum: v3zoCAcc32ckk X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: "nsis@ietf.org" Subject: [NSIS] GIST Draft-14 Refresh/Confirm 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, during the revision of our code I came across the following issue: for the following cases I assume that an initial handshake for C-mode already happened and that an MA has been properly setup. While it is really clearly described what to do for C-Mode/MA setup it is less clear for routing state refreshes. - Is it necessary for a _refreshing_ Query to contain a stack proposal in order to indicate C-mode usage? - Is it possible that a refresh for C-mode uses only Query and a Response in D-mode? I would say no from the table in sec. 5.5, but I could not find it anywhere in the text. Sec. 5.1 says it MAY be sent in C-mode if an existing MA is being re-used, whereas I interpret the table from sec. 5.5 that this is actually a MUST, i.e. it MUST be sent in C-mode in case an existing is being re-used. This also matches the text from sec. 4.4.3: Section 5.7.1. This is indicated by sending the remaining messages in the handshake over that association. This will lead So I guess a refresh for C-mode consists at least of a Query and a Response sent back in C-Mode. - I was not absolutely sure about how to send the Confirm that may be used in case of a state refresh, because most of the text seems to be related to state setup but not to a refresh. Though now it is really clear that a confirm is always required for initial C-mode setup and otherwise it is only required if a Response requests it. The only hints that I found are: * Sec. 5.1: A Confirm MUST be sent in C-mode if a messaging association is being used for this routing state, and MUST be sent before other messages for this routing state. [while the first part is pretty clear, the second part sounds as it would be related to an MA setup only] * Table in 5.5 says Confirm C-Mode usage: if an MA has been set up or is being re-used and the column for D-Mode is the logical negation of this, so D-Mode is not allowed. Explicitly saying that Response/Confirm must be sent in C-Mode for an existing usable MA would be nice. - Section 5.5 now mentions that if the Confirm didn't arrive via the C-Mode that an Incorrect Encapsulation Error should be sent. It would be good to mention this in A.4.4.3, too. Sorry for being nitpicking, Roland _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Jul 31 10:51:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFt45-0005ai-DO; Tue, 31 Jul 2007 10:51:13 -0400 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1IFt44-0005aZ-87 for nsis-confirm+ok@megatron.ietf.org; Tue, 31 Jul 2007 10:51:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFt43-0005aR-Up for nsis@ietf.org; Tue, 31 Jul 2007 10:51:11 -0400 Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IFt42-0002al-Ad for nsis@ietf.org; Tue, 31 Jul 2007 10:51:11 -0400 Received: from irams2.ira.uni-karlsruhe.de ([141.3.10.82]) by iramx2.ira.uni-karlsruhe.de with esmtps id 1IFt3x-0005k9-BB; Tue, 31 Jul 2007 16:51:08 +0200 Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5]) by irams2.ira.uni-karlsruhe.de with esmtps id 1IFt3r-000305-79; Tue, 31 Jul 2007 16:51:05 +0200 Received: from i72ms.tm.uni-karlsruhe.de ([141.3.70.5] helo=smtp.ipv6.tm.uni-karlsruhe.de) by irams1.ira.uni-karlsruhe.de with esmtps id 1IFt3q-0006Mc-OE; Tue, 31 Jul 2007 16:50:58 +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 BEC422FC015; Tue, 31 Jul 2007 16:50:56 +0200 (CEST) Received: from localhost ([127.0.0.1]) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.44) id 1IFt3n-00043L-T3; Tue, 31 Jul 2007 16:50:56 +0200 Message-ID: <46AF4C4E.8080701@tm.uka.de> Date: Tue, 31 Jul 2007 16:50:54 +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" X-Enigmail-Version: 0.94.1.1 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-Spam-Status: No X-Spam-Score: -1.4 (-) X-Spam-Report: -1.4 ALL_TRUSTED Passed through trusted hosts only via SMTP 0.1 AWL AWL: From: address is in the auto white-list X-Spam-Host: irams2.ira.uni-karlsruhe.de X-ATIS-Checksum: v3zoCAcc32ckk X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: "nsis@ietf.org" Subject: [NSIS] GIST: Responding Node D-Mode to C-Mode upgrade? 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, this is an old topic, but probably still not solved satisfactory. Nuutti Varis, who is currently implementing GIST at University of Helsinki, came also across this issue again. Problem: in case a responding node has to send a payload larger than the MAX_MTU size, it currently cannot upgrade the session from D-Mode to C-mode, because it is a responding node. See also http://www1.ietf.org/mail-archive/web/nsis/current/msg05672.html and your answer here: http://www1.ietf.org/mail-archive/web/nsis/current/msg05676.html Same applies for requiring a reliable transfer mode on the responder side when only an unreliable transfer was considered by the querier so far. I could think of the following alternatives: a) the responding node queues the data for transmission and sends and informative error message to the querier who can then decide on upgrading the session to C-mode. This has the problem that we need a timer on the responder side and must wait until the MA is established. Otherwise it will notify the application with a MessageStatus() call that the message could not be sent. Probably a part of the code could be re-used that is already there for initial setup of an MA. Furthermore, even smaller D-mode messages must enqueue behind this earlier message, because in order delivery for the same session is required. b) indicate a local error condition via MessageStatus that the message is too large. However, reacting to this failure situation requires probably a similar logic that could have been used by the application itself _before_ calling the SendMessage() call. c) see it as global policy for the NSLP as in your answer. However, it would be good to mention the problem (and a solution) in the draft at least. Any other opinions? Regards, Roland _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Jul 31 11:21:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFtXN-0001r7-Ua; Tue, 31 Jul 2007 11:21:29 -0400 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1IFtXJ-0001hY-5T for nsis-confirm+ok@megatron.ietf.org; Tue, 31 Jul 2007 11:21:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFtXH-0001gk-Sk; Tue, 31 Jul 2007 11:21:23 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IFtXG-0003rm-8U; Tue, 31 Jul 2007 11:21:23 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id A5EBB548021; Tue, 31 Jul 2007 17:21:21 +0200 (CEST) X-AuditID: c1b4fb3c-afe7ebb0000007e1-a7-46af53713e29 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 4277920474; Tue, 31 Jul 2007 17:21:21 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 31 Jul 2007 17:21:20 +0200 Received: from [147.214.30.247] ([147.214.30.247]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 31 Jul 2007 17:21:20 +0200 Message-ID: <46AF5370.9020304@ericsson.com> Date: Tue, 31 Jul 2007 17:21:20 +0200 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: tsvwg , NSIS , IETF SIPPING WG , sip@ietf.org Content-Type: text/plain; charset=UTF-8; format=flowed X-OriginalArrivalTime: 31 Jul 2007 15:21:20.0301 (UTC) FILETIME=[7279C5D0:01C7D386] X-Brightmail-Tracker: AAAAAA== Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 96d3a783a4707f1ab458eb15058bb2d7 Cc: Subject: [NSIS] Draft Liaision response to SG13 on Emergency Telecommunications 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 This is the draft for a liaison response to be sent to SG 13 of the=20 ITU-T from the TSVWG, NSIS, SIP and SIPPING WGs. Please provide any=20 comments at the latest by the 14th of August. After that we will address=20 any raised comments and send the liaison to ITU-T before the end of Augus= t. Submission Date: , 2007 From: IETF Working groups TSVWG, NSIS, SIP and SIPPING To: Georges Sebek , Keith Knightson Cc: Magnus Westerlund , Lars Eggert , James Polk , Martin Stiemerling , John Loughney Dean Willis , Keith Drage , Mary Barnes , Gonzalo Camarillo , Scott Bradner , Kimberly King , Scott Brim Response Contact: TSV WG (tsv-chairs@tools.ietf.org) NSIS (nsis-chairs@tools.ietf.org) SIPPING (sipping-chairs@tools.ietf.org) SIP (sip-chairs@tools.ietf.org) =09 Purpose: Response to Liaison Request Deadline: None Title: Response to liaison request from ITU-T Study Group 13 work on=20 emergency telecommunications This is a response to the liaison request made by Q3/13 regarding=20 emergency telecommunications (REF: NGN-GSI/DOC =E2=80=93 60 Rev.2). We wo= uld=20 first like to apologize for failing to meet the deadline in responding.=20 We do hope that the late answer still can be of some use. The liaison request was made to the following working groups (WG):=20 IEPREP, TSVWG, and NSIS. Since the request was sent the IEPREP WG has=20 concluded. In addition to the WGs from which information was requested,=20 we also think that work performed by the SIP and SIPPING WG may be of=20 relevance. Pursuant to ITU-T Study Group 13 request for information on relevant and=20 related work in the IETF regarding emergency communications, we list=20 below RFCs and works in progress that we feel may be of interest to your=20 group. Some of the completed work is Informational, and others are in=20 the category of Standards Track. Q.3/13 also requested that we keep you informed of any developments in=20 regards to emergency telecommunications. In those regards we would like=20 to make you aware that IETF mailing list participation and document=20 information is free and open for anyone. Allowing participants in Q.3/13=20 to keep them selves informed of any developments. If Q.3/13 desire to=20 get further information about specific ongoing work, then please send a=20 liaison request to the responsible WG for those specific documents. The following list is divided under the associated working groups from=20 which the work has been done within the IETF. SIP Working Group RFC 4411 Title: Extending the Session Initiation Protocol (SIP) Reason Header for Preemption Events Abstract: This document proposes an IANA Registration extension to the Session Initiation Protocol (SIP) Reason Header to be included in a BYE Method Request as a result of a session preemption event, either at a user agent (UA), or somewhere in the network involving a reservation-based protocol such as the Resource ReSerVation Protocol (RSVP) or Next Steps in Signaling (NSIS). This document does not attempt to address routers failing in the packet path; instead, it addresses a deliberate tear down of a flow between UAs, and informs the terminated UA(s) with an indication of what occurred. RFC 4412 Title: Communications Resource Priority for the Session Initiation Protocol (SIP) Abstract: This document defines two new Session Initiation Protocol (SIP) header fields for communicating resource priority, namely, "Resource-Priority" and "Accept-Resource-Priority". The "Resource-Priority" header field can influence the behavior of SIP user agents (such as telephone gateways and IP telephones) and SIP proxies. It does not directly influence the forwarding behavior of IP routers. SIPPING Working Group The below two documents are proposed work items not yet accepted as IETF WG items but are likely of interest as they update RFC 4412. Work In Progress: draft-polk-sip-rph-in-responses-00 Title: Allowing SIP Resource Priority Header in SIP Responses Abstract: The Session Initiation Protocol (SIP) Resource Priority Header (RPH), in its current form, is ignored in SIP responses. This was a design choice during RFC 4412's development. This is now considered a bad design choice in certain scenarios. This document corrects RFC 4412's communications model by optionally allowing a SIP server or user agent client to process the Resource-Priority Header in a response. Work In Progress: draft-polk-sip-rph-new-namespaces--00 Title: New Session Initiation Protocol Resource-Priority Header Namespaces for the Defense Information Systems Agency Abstract: This document creates additional Session Initiation Protocol Resource-Priority header namespaces, to be IANA registered. This document intends to update RFC 4412, as a Proposed Standard document if published by the RFC-Editor. IEPREP Working Group RFC 3487 Title: Requirements for Resource Priority Mechanisms for the Session Initiation Protocol (SIP) Abstract: This document summarizes requirements for prioritizing access to circuit-switched network, end system and proxy resources for emergency preparedness communications using the Session Initiation Protocol (SIP). RFC 3689 Title: General Requirements for Emergency Telecommunication Service (ETS) Abstract: This document presents a list of general requirements in support of Emergency Telecommunications Service (ETS). Solutions to these requirements are not presented in this document. Additional requirements pertaining to specific applications, or types of applications, are to be specified in separate document(s). RFC 3690 Title: IP Telephony Requirements for Emergency Telecommunication Service (ETS) Abstract: This document presents a list of requirements in support of Emergency Telecommunications Service (ETS) within the context of IP telephony. It is an extension to the general requirements presented in RFC 3689. Solutions to these requirements are not presented in this document. RFC 4190 Title: Framework for Supporting Emergency Telecommunications Service (ETS) in IP Telephony Abstract: This document presents a framework for supporting authorized, emergency-related communication within the context of IP telephony. We present a series of objectives that reflect a general view of how authorized emergency service, in line with the Emergency Telecommunications Service (ETS), should be realized within today's IP architecture and service models. From these objectives, we present a corresponding set of protocols and capabilities, which provide a more specific set of recommendations regarding existing IETF protocols. Finally, we present two scenarios that act as guiding models for the objectives and functions listed in this document. These models, coupled with an example of an existing service in the Public Switched Telephone Network (PSTN), contribute to a constrained solution space. RFC 4375 Title: Emergency Telecommunications Services (ETS) Requirements for a Single Administrative Domain Abstract: This document presents a list of requirements in support of Emergency Telecommunications Service (ETS) within a single administrative domain. This document focuses on a specific set of administrative constraints and scope. Solutions to these requirements are not presented in this document. TSV Working Group RFC 4542 Title: Implementing an Emergency Telecommunications Service (ETS) for Real-Time Services in the Internet Protocol Suite Abstract: RFCs 3689 and 3690 detail requirements for an Emergency Telecommunications Service (ETS), of which an Internet Emergency Preparedness Service (IEPS) would be a part. Some of these types of services require call preemption; others require call queuing or other mechanisms. IEPS requires a Call Admission Control (CAC) procedure and a Per Hop Behavior (PHB) for the data that meet the needs of this architecture. Such a CAC procedure and PHB is appropriate to any service that might use H.323 or SIP to set up real-time sessions. The key requirement is to guarantee an elevated probability of call completion to an authorized user in time of crisis. This document primarily discusses supporting ETS in the context of the US Government and NATO, because it focuses on the Multi-Level Precedence and Preemption (MLPP) and Government Emergency Telecommunication Service (GETS) standards. The architectures described here are applicable beyond these organizations. Work In Progress: draft-ietf-tsvwg-emergency-rsvp-03.txt Title: Resource ReSerVation Protovol (RSVP) Extensions for Emergency Services Abstract: An Emergency Telecommunications Service (ETS) requires the ability to provide an elevated probability of session establishment to an authorized user in times of network congestion (typically, during a crisis). When supported over the Internet Protocol suite, this may be facilitated through a network layer admission control solution, which supports prioritized access to resources (e.g., bandwidth). These resources may be explicitly set aside for emergency services, or they may be shared with other sessions. This document specifies RSVP extensions that can be used to support such an admission priority capability at the network layer. Note that these extensions represent one possible solution component in satisfying ETS requirements. Other solution components, or other solutions, are outside the scope of this document. NSIS Working Group Work In Progress: draft-ietf-nsis-qos-nslp-14.txt Title: NSLP for Quality-of-Service Signaling Abstract: This specification describes the NSIS Signaling Layer Protocol (NSLP) for signaling QoS reservations in the Internet. It is in accordance with the framework and requirements developed in NSIS. Together with GIST, it provides functionality similar to RSVP and extends it. The QoS NSLP is independent of the underlying QoS specification or architecture and provides support for different reservation models. It is simplified by the elimination of support for multicast flows. This specification explains the overall protocol approach, design decisions made and provides examples. It specifies object, message formats and processing rules. --=20 Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM/M ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Jul 31 11:34:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFtk2-0005VW-LN; Tue, 31 Jul 2007 11:34:34 -0400 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1IFtk0-0005Rw-VE for nsis-confirm+ok@megatron.ietf.org; Tue, 31 Jul 2007 11:34:32 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFtk0-0005Rk-HX; Tue, 31 Jul 2007 11:34:32 -0400 Received: from mail171.messagelabs.com ([216.82.253.243]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IFtjx-00062P-RG; Tue, 31 Jul 2007 11:34:32 -0400 X-VirusChecked: Checked X-Env-Sender: jgunn6@csc.com X-Msg-Ref: server-12.tower-171.messagelabs.com!1185896061!8098786!1 X-StarScan-Version: 5.5.12.11; banners=-,-,- X-Originating-IP: [20.137.52.151] Received: (qmail 14991 invoked from network); 31 Jul 2007 15:34:22 -0000 Received: from amer-mta07.csc.com (HELO amer-mta07.csc.com) (20.137.52.151) by server-12.tower-171.messagelabs.com with AES256-SHA encrypted SMTP; 31 Jul 2007 15:34:22 -0000 Received: from amer-gw09.amer.csc.com (amer-gw09.amer.csc.com [20.6.39.245]) by amer-mta07.csc.com (Switch-3.1.6/Switch-3.1.7) with ESMTP id l6VFYaYJ009979; Tue, 31 Jul 2007 11:34:37 -0400 (EDT) In-Reply-To: <46AF5370.9020304@ericsson.com> To: Magnus Westerlund MIME-Version: 1.0 X-Mailer: Lotus Notes 652HF83 November 04, 2004 From: Janet P Gunn Message-ID: Date: Tue, 31 Jul 2007 11:34:17 -0400 X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 7.0.2FP1 HF180|March 29, 2007) at 07/31/2007 11:32:58 AM, Serialize complete at 07/31/2007 11:32:58 AM X-Spam-Score: 0.0 (/) X-Scan-Signature: ee8eaa76ea6a4fb3ccc9059a3f656ffc Cc: sip@ietf.org, IETF SIPPING WG , tsvwg , NSIS Subject: [NSIS] Re: [Tsvwg] Draft Liaision response to SG13 on Emergency Telecommunications 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="===============2091230778==" Errors-To: nsis-bounces@ietf.org This is a multipart message in MIME format. --===============2091230778== Content-Type: multipart/alternative; boundary="=_alternative 0055890785257329_=" This is a multipart message in MIME format. --=_alternative 0055890785257329_= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 TWFnbnVzLA0KDQpZb3UgbWlnaHQgd2FudCB0byBhZGQtDQoNCmRyYWZ0LXBvbGstdHN2d2ctc2ln bmFsZWQtZG9tYWluLWlkLTAwLnR4dA0KYW5kIA0KZHJhZnQtcG9say1lY3JpdC1sb2NhbC1lbWVy Z2VuY3ktcnBoLW5hbWVzcGFjZS0wMS50eHQNCg0KKEJvdGggd2VyZSBvbiB0aGUgYWdlbmRhIGFu ZCBkaXNjdXNzZWQuKQ0KDQpBbmQgbWF5YmUNCmRyYWZ0LWNhcmxiZXJnLXRyaXAtYXR0cmlidXRl LXJwLTAyIA0KDQoodGhvdWdoIEkgZGlkIG5vdCBzZWUgaXQgb24gdGhlIGFnZW5kYSkNCg0KSmFu ZXQNCg0KUFMsDQoNCk15IHNwZWxsaW5nIGNoZWNrZXIgc2F5cyAiTGlhaXNpb24iIHNob3VsZCBi ZSAiTGlhaXNvbiIsIGJ1dCBpdCBtYXkgYmUgYSANClVTIGNlbnRyaWMgZGljdGlvbmFyeS4NCkoN Ck1hZ251cyBXZXN0ZXJsdW5kIDxtYWdudXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb20+IHdyb3Rl IG9uIDA3LzMxLzIwMDcgDQoxMToyMToyMCBBTToNCg0KPiBIaQ0KPiANCj4gVGhpcyBpcyB0aGUg ZHJhZnQgZm9yIGEgbGlhaXNvbiByZXNwb25zZSB0byBiZSBzZW50IHRvIFNHIDEzIG9mIHRoZSAN Cj4gSVRVLVQgZnJvbSB0aGUgVFNWV0csIE5TSVMsIFNJUCBhbmQgU0lQUElORyBXR3MuIFBsZWFz ZSBwcm92aWRlIGFueSANCj4gY29tbWVudHMgYXQgdGhlIGxhdGVzdCBieSB0aGUgMTR0aCBvZiBB dWd1c3QuIEFmdGVyIHRoYXQgd2Ugd2lsbCBhZGRyZXNzIA0KDQo+IGFueSByYWlzZWQgY29tbWVu dHMgYW5kIHNlbmQgdGhlIGxpYWlzb24gdG8gSVRVLVQgYmVmb3JlIHRoZSBlbmQgb2YgDQpBdWd1 c3QuDQo+IA0KPiBTdWJtaXNzaW9uDQo+IERhdGU6ICAgICAgPHRiZD4sIDIwMDcNCj4gDQo+IEZy b206ICAgICAgIElFVEYgV29ya2luZyBncm91cHMgVFNWV0csIE5TSVMsIFNJUCBhbmQgU0lQUElO Rw0KPiANCj4gVG86ICAgICAgR2VvcmdlcyBTZWJlayAgPHRzYnNnMTNAaXR1LmludD4gLA0KPiAg ICAgICBLZWl0aCBLbmlnaHRzb24gPGtna0BpZ3MubmV0Pg0KPiANCj4gQ2M6ICAgICAgTWFnbnVz IFdlc3Rlcmx1bmQgPG1hZ251cy53ZXN0ZXJsdW5kQGVyaWNzc29uLmNvbT4sDQo+ICAgICAgICAg ICAgICAgICAgTGFycyBFZ2dlcnQgPGxhcnMuZWdnZXJ0QG5va2lhLmNvbT4sDQo+ICAgICAgICAg ICAgICAgICAgSmFtZXMgUG9sayA8am1wb2xrQGNpc2NvLmNvbT4sDQo+ICAgICAgICAgICAgICAg ICAgTWFydGluIFN0aWVtZXJsaW5nIDxzdGllbWVybGluZ0BuZXRsYWIubmVjLmRlPiwNCj4gICAg ICAgICAgICAgICAgICBKb2huIExvdWdobmV5IDxqb2huLmxvdWdobmV5QG5va2lhLmNvbT4NCj4g ICAgICAgICAgICAgICAgICBEZWFuIFdpbGxpcyA8ZGVhbi53aWxsaXNAc29mdGFybW9yLmNvbT4s DQo+ICAgICAgICAgICAgICAgICAgS2VpdGggRHJhZ2UgPGRyYWdlQGFsY2F0ZWwtbHVjZW50LmNv bT4sDQo+ICAgICAgICAgICAgICAgICAgTWFyeSBCYXJuZXMgPG1hcnkuYmFybmVzQG5vcnRlbC5j b20+LA0KPiAgICAgICAgICAgICAgICAgIEdvbnphbG8gQ2FtYXJpbGxvIDxnb256YWxvLmNhbWFy aWxsb0Blcmljc3Nvbi5jb20+LA0KPiAgICAgICAgICAgICAgICAgIFNjb3R0IEJyYWRuZXIgPHNv YkBoYXJ2YXJkLmVkdT4sDQo+ICAgICAgICAgICAgICAgICAgS2ltYmVybHkgS2luZyA8a3NraW5n QG1pdHJlLm9yZz4sDQo+ICAgICAgICAgICAgICAgICAgU2NvdHQgQnJpbSA8c3diQGVtcGxveWVl cy5vcmc+DQo+IA0KPiBSZXNwb25zZQ0KPiBDb250YWN0OiAgIFRTViBXRyAodHN2LWNoYWlyc0B0 b29scy5pZXRmLm9yZykNCj4gICAgICAgTlNJUyAobnNpcy1jaGFpcnNAdG9vbHMuaWV0Zi5vcmcp DQo+ICAgICAgIFNJUFBJTkcgKHNpcHBpbmctY2hhaXJzQHRvb2xzLmlldGYub3JnKQ0KPiAgICAg ICBTSVAgKHNpcC1jaGFpcnNAdG9vbHMuaWV0Zi5vcmcpDQo+IA0KPiBQdXJwb3NlOiAgICBSZXNw b25zZSB0byBMaWFpc29uIFJlcXVlc3QNCj4gDQo+IERlYWRsaW5lOiAgIE5vbmUNCj4gDQo+IFRp dGxlOiBSZXNwb25zZSB0byBsaWFpc29uIHJlcXVlc3QgZnJvbSBJVFUtVCBTdHVkeSBHcm91cCAx MyB3b3JrIG9uIA0KPiBlbWVyZ2VuY3kgdGVsZWNvbW11bmljYXRpb25zDQo+IA0KPiBUaGlzIGlz IGEgcmVzcG9uc2UgdG8gdGhlIGxpYWlzb24gcmVxdWVzdCBtYWRlIGJ5IFEzLzEzIHJlZ2FyZGlu ZyANCj4gZW1lcmdlbmN5IHRlbGVjb21tdW5pY2F0aW9ucyAoUkVGOiBOR04tR1NJL0RPQyDigJMg NjAgUmV2LjIpLiBXZSB3b3VsZCANCj4gZmlyc3QgbGlrZSB0byBhcG9sb2dpemUgZm9yIGZhaWxp bmcgdG8gbWVldCB0aGUgZGVhZGxpbmUgaW4gcmVzcG9uZGluZy4gDQo+IFdlIGRvIGhvcGUgdGhh dCB0aGUgbGF0ZSBhbnN3ZXIgc3RpbGwgY2FuIGJlIG9mIHNvbWUgdXNlLg0KPiANCj4gVGhlIGxp YWlzb24gcmVxdWVzdCB3YXMgbWFkZSB0byB0aGUgZm9sbG93aW5nIHdvcmtpbmcgZ3JvdXBzIChX Ryk6IA0KPiBJRVBSRVAsIFRTVldHLCBhbmQgTlNJUy4gU2luY2UgdGhlIHJlcXVlc3Qgd2FzIHNl bnQgdGhlIElFUFJFUCBXRyBoYXMgDQo+IGNvbmNsdWRlZC4gSW4gYWRkaXRpb24gdG8gdGhlIFdH cyBmcm9tIHdoaWNoIGluZm9ybWF0aW9uIHdhcyByZXF1ZXN0ZWQsIA0KPiB3ZSBhbHNvIHRoaW5r IHRoYXQgd29yayBwZXJmb3JtZWQgYnkgdGhlIFNJUCBhbmQgU0lQUElORyBXRyBtYXkgYmUgb2Yg DQo+IHJlbGV2YW5jZS4NCj4gDQo+IFB1cnN1YW50IHRvIElUVS1UIFN0dWR5IEdyb3VwIDEzIHJl cXVlc3QgZm9yIGluZm9ybWF0aW9uIG9uIHJlbGV2YW50IGFuZCANCg0KPiByZWxhdGVkIHdvcmsg aW4gdGhlIElFVEYgcmVnYXJkaW5nIGVtZXJnZW5jeSBjb21tdW5pY2F0aW9ucywgd2UgbGlzdCAN Cj4gYmVsb3cgUkZDcyBhbmQgd29ya3MgaW4gcHJvZ3Jlc3MgdGhhdCB3ZSBmZWVsIG1heSBiZSBv ZiBpbnRlcmVzdCB0byB5b3VyIA0KDQo+IGdyb3VwLiAgU29tZSBvZiB0aGUgY29tcGxldGVkIHdv cmsgaXMgSW5mb3JtYXRpb25hbCwgYW5kIG90aGVycyBhcmUgaW4gDQo+IHRoZSBjYXRlZ29yeSBv ZiBTdGFuZGFyZHMgVHJhY2suDQo+IA0KPiBRLjMvMTMgYWxzbyByZXF1ZXN0ZWQgdGhhdCB3ZSBr ZWVwIHlvdSBpbmZvcm1lZCBvZiBhbnkgZGV2ZWxvcG1lbnRzIGluIA0KPiByZWdhcmRzIHRvIGVt ZXJnZW5jeSB0ZWxlY29tbXVuaWNhdGlvbnMuIEluIHRob3NlIHJlZ2FyZHMgd2Ugd291bGQgbGlr ZSANCj4gdG8gbWFrZSB5b3UgYXdhcmUgdGhhdCBJRVRGIG1haWxpbmcgbGlzdCBwYXJ0aWNpcGF0 aW9uIGFuZCBkb2N1bWVudCANCj4gaW5mb3JtYXRpb24gaXMgZnJlZSBhbmQgb3BlbiBmb3IgYW55 b25lLiBBbGxvd2luZyBwYXJ0aWNpcGFudHMgaW4gUS4zLzEzIA0KDQo+IHRvIGtlZXAgdGhlbSBz ZWx2ZXMgaW5mb3JtZWQgb2YgYW55IGRldmVsb3BtZW50cy4gSWYgUS4zLzEzIGRlc2lyZSB0byAN Cj4gZ2V0IGZ1cnRoZXIgaW5mb3JtYXRpb24gYWJvdXQgc3BlY2lmaWMgb25nb2luZyB3b3JrLCB0 aGVuIHBsZWFzZSBzZW5kIGEgDQo+IGxpYWlzb24gcmVxdWVzdCB0byB0aGUgcmVzcG9uc2libGUg V0cgZm9yIHRob3NlIHNwZWNpZmljIGRvY3VtZW50cy4NCj4gDQo+IFRoZSBmb2xsb3dpbmcgbGlz dCBpcyBkaXZpZGVkIHVuZGVyIHRoZSBhc3NvY2lhdGVkIHdvcmtpbmcgZ3JvdXBzIGZyb20gDQo+ IHdoaWNoIHRoZSB3b3JrIGhhcyBiZWVuIGRvbmUgd2l0aGluIHRoZSBJRVRGLg0KPiANCj4gDQo+ IFNJUCBXb3JraW5nIEdyb3VwDQo+IA0KPiBSRkMgNDQxMQ0KPiANCj4gVGl0bGU6DQo+ICAgICBF eHRlbmRpbmcgdGhlIFNlc3Npb24gSW5pdGlhdGlvbiBQcm90b2NvbCAoU0lQKQ0KPiAgICAgUmVh c29uIEhlYWRlciBmb3IgUHJlZW1wdGlvbiBFdmVudHMNCj4gDQo+IEFic3RyYWN0Og0KPiAgICBU aGlzIGRvY3VtZW50IHByb3Bvc2VzIGFuIElBTkEgUmVnaXN0cmF0aW9uIGV4dGVuc2lvbiB0byB0 aGUgU2Vzc2lvbg0KPiAgICAgSW5pdGlhdGlvbiBQcm90b2NvbCAoU0lQKSBSZWFzb24gSGVhZGVy IHRvIGJlIGluY2x1ZGVkIGluIGEgQllFDQo+ICAgICBNZXRob2QgUmVxdWVzdCBhcyBhIHJlc3Vs dCBvZiBhIHNlc3Npb24gcHJlZW1wdGlvbiBldmVudCwgZWl0aGVyIGF0IA0KYQ0KPiAgICAgdXNl ciBhZ2VudCAoVUEpLCBvciBzb21ld2hlcmUgaW4gdGhlIG5ldHdvcmsgaW52b2x2aW5nIGENCj4g ICAgIHJlc2VydmF0aW9uLWJhc2VkIHByb3RvY29sIHN1Y2ggYXMgdGhlIFJlc291cmNlIFJlU2Vy VmF0aW9uIFByb3RvY29sDQo+ICAgICAoUlNWUCkgb3IgTmV4dCBTdGVwcyBpbiBTaWduYWxpbmcg KE5TSVMpLiAgVGhpcyBkb2N1bWVudCBkb2VzIG5vdA0KPiAgICAgYXR0ZW1wdCB0byBhZGRyZXNz IHJvdXRlcnMgZmFpbGluZyBpbiB0aGUgcGFja2V0IHBhdGg7IGluc3RlYWQsIGl0DQo+ICAgICBh ZGRyZXNzZXMgYSBkZWxpYmVyYXRlIHRlYXIgZG93biBvZiBhIGZsb3cgYmV0d2VlbiBVQXMsIGFu ZCBpbmZvcm1zDQo+ICAgICB0aGUgdGVybWluYXRlZCBVQShzKSB3aXRoIGFuIGluZGljYXRpb24g b2Ygd2hhdCBvY2N1cnJlZC4NCj4gDQo+IFJGQyA0NDEyDQo+IA0KPiBUaXRsZToNCj4gICAgIENv bW11bmljYXRpb25zIFJlc291cmNlIFByaW9yaXR5IGZvciB0aGUgU2Vzc2lvbiBJbml0aWF0aW9u DQo+ICAgICBQcm90b2NvbCAoU0lQKQ0KPiANCj4gQWJzdHJhY3Q6DQo+ICAgICBUaGlzIGRvY3Vt ZW50IGRlZmluZXMgdHdvIG5ldyBTZXNzaW9uIEluaXRpYXRpb24gUHJvdG9jb2wgKFNJUCkNCj4g ICAgIGhlYWRlciBmaWVsZHMgZm9yIGNvbW11bmljYXRpbmcgcmVzb3VyY2UgcHJpb3JpdHksIG5h bWVseSwNCj4gICAgICJSZXNvdXJjZS1Qcmlvcml0eSIgYW5kICJBY2NlcHQtUmVzb3VyY2UtUHJp b3JpdHkiLiAgVGhlDQo+ICAgICAiUmVzb3VyY2UtUHJpb3JpdHkiIGhlYWRlciBmaWVsZCBjYW4g aW5mbHVlbmNlIHRoZSBiZWhhdmlvciBvZiBTSVANCj4gICAgIHVzZXIgYWdlbnRzIChzdWNoIGFz IHRlbGVwaG9uZSBnYXRld2F5cyBhbmQgSVAgdGVsZXBob25lcykgYW5kIFNJUA0KPiAgICAgcHJv eGllcy4gIEl0IGRvZXMgbm90IGRpcmVjdGx5IGluZmx1ZW5jZSB0aGUgZm9yd2FyZGluZyBiZWhh dmlvciBvZg0KPiAgICAgSVAgcm91dGVycy4NCj4gDQo+IA0KPiANCj4gU0lQUElORyBXb3JraW5n IEdyb3VwDQo+IA0KPiAgICAgVGhlIGJlbG93IHR3byBkb2N1bWVudHMgYXJlIHByb3Bvc2VkIHdv cmsgaXRlbXMgbm90IHlldCBhY2NlcHRlZCBhcw0KPiAgICAgSUVURiBXRyBpdGVtcyBidXQgYXJl IGxpa2VseSBvZiBpbnRlcmVzdCBhcyB0aGV5IHVwZGF0ZSBSRkMgNDQxMi4NCj4gDQo+IFdvcmsg SW4gUHJvZ3Jlc3M6ICAgZHJhZnQtcG9say1zaXAtcnBoLWluLXJlc3BvbnNlcy0wMA0KPiANCj4g VGl0bGU6DQo+ICAgICBBbGxvd2luZyBTSVAgUmVzb3VyY2UgUHJpb3JpdHkgSGVhZGVyIGluIFNJ UCBSZXNwb25zZXMNCj4gDQo+IEFic3RyYWN0Og0KPiAgICAgVGhlIFNlc3Npb24gSW5pdGlhdGlv biBQcm90b2NvbCAoU0lQKSBSZXNvdXJjZSBQcmlvcml0eSBIZWFkZXINCj4gICAgIChSUEgpLCBp biBpdHMgY3VycmVudCBmb3JtLCBpcyBpZ25vcmVkIGluIFNJUCByZXNwb25zZXMuICBUaGlzIHdh cyBhDQo+ICAgICBkZXNpZ24gY2hvaWNlIGR1cmluZyBSRkMgNDQxMidzIGRldmVsb3BtZW50LiBU aGlzIGlzIG5vdyBjb25zaWRlcmVkDQo+ICAgICBhIGJhZCBkZXNpZ24gY2hvaWNlIGluIGNlcnRh aW4gc2NlbmFyaW9zLiAgVGhpcyBkb2N1bWVudCBjb3JyZWN0cw0KPiAgICAgUkZDIDQ0MTIncyBj b21tdW5pY2F0aW9ucyBtb2RlbCBieSBvcHRpb25hbGx5IGFsbG93aW5nIGEgU0lQIHNlcnZlcg0K PiAgICAgb3IgdXNlciBhZ2VudCBjbGllbnQgdG8gcHJvY2VzcyB0aGUgUmVzb3VyY2UtUHJpb3Jp dHkgSGVhZGVyIGluIGENCj4gICAgIHJlc3BvbnNlLg0KPiANCj4gV29yayBJbiBQcm9ncmVzczog ICBkcmFmdC1wb2xrLXNpcC1ycGgtbmV3LW5hbWVzcGFjZXMtLTAwDQo+IA0KPiBUaXRsZToNCj4g ICAgIE5ldyBTZXNzaW9uIEluaXRpYXRpb24gUHJvdG9jb2wgUmVzb3VyY2UtUHJpb3JpdHkgSGVh ZGVyIE5hbWVzcGFjZXMNCj4gICAgIGZvciB0aGUgRGVmZW5zZSBJbmZvcm1hdGlvbiBTeXN0ZW1z IEFnZW5jeQ0KPiANCj4gQWJzdHJhY3Q6DQo+ICAgICBUaGlzIGRvY3VtZW50IGNyZWF0ZXMgYWRk aXRpb25hbCBTZXNzaW9uIEluaXRpYXRpb24gUHJvdG9jb2wNCj4gICAgIFJlc291cmNlLVByaW9y aXR5IGhlYWRlciBuYW1lc3BhY2VzLCB0byBiZSBJQU5BIHJlZ2lzdGVyZWQuICBUaGlzDQo+ICAg ICBkb2N1bWVudCBpbnRlbmRzIHRvIHVwZGF0ZSBSRkMgNDQxMiwgYXMgYSBQcm9wb3NlZCBTdGFu ZGFyZCBkb2N1bWVudA0KPiAgICAgaWYgcHVibGlzaGVkIGJ5IHRoZSBSRkMtRWRpdG9yLg0KPiAN Cj4gSUVQUkVQIFdvcmtpbmcgR3JvdXANCj4gDQo+IFJGQyAzNDg3DQo+IA0KPiBUaXRsZToNCj4g ICAgIFJlcXVpcmVtZW50cyBmb3IgUmVzb3VyY2UgUHJpb3JpdHkgTWVjaGFuaXNtcyBmb3IgdGhl DQo+ICAgICBTZXNzaW9uIEluaXRpYXRpb24gUHJvdG9jb2wgKFNJUCkNCj4gDQo+IEFic3RyYWN0 Og0KPiAgICAgVGhpcyBkb2N1bWVudCBzdW1tYXJpemVzIHJlcXVpcmVtZW50cyBmb3IgcHJpb3Jp dGl6aW5nIGFjY2VzcyB0bw0KPiAgICAgY2lyY3VpdC1zd2l0Y2hlZCBuZXR3b3JrLCBlbmQgc3lz dGVtIGFuZCBwcm94eSByZXNvdXJjZXMgZm9yDQo+ICAgICBlbWVyZ2VuY3kgcHJlcGFyZWRuZXNz IGNvbW11bmljYXRpb25zIHVzaW5nIHRoZSBTZXNzaW9uIEluaXRpYXRpb24NCj4gICAgIFByb3Rv Y29sIChTSVApLg0KPiANCj4gUkZDIDM2ODkNCj4gDQo+IFRpdGxlOg0KPiAgICAgR2VuZXJhbCBS ZXF1aXJlbWVudHMgZm9yDQo+ICAgICBFbWVyZ2VuY3kgVGVsZWNvbW11bmljYXRpb24gU2Vydmlj ZSAoRVRTKQ0KPiANCj4gQWJzdHJhY3Q6DQo+ICAgICBUaGlzIGRvY3VtZW50IHByZXNlbnRzIGEg bGlzdCBvZiBnZW5lcmFsIHJlcXVpcmVtZW50cyBpbiBzdXBwb3J0IG9mDQo+ICAgICBFbWVyZ2Vu Y3kgVGVsZWNvbW11bmljYXRpb25zIFNlcnZpY2UgKEVUUykuICBTb2x1dGlvbnMgdG8gdGhlc2UN Cj4gICAgIHJlcXVpcmVtZW50cyBhcmUgbm90IHByZXNlbnRlZCBpbiB0aGlzIGRvY3VtZW50LiAg QWRkaXRpb25hbA0KPiAgICAgcmVxdWlyZW1lbnRzIHBlcnRhaW5pbmcgdG8gc3BlY2lmaWMgYXBw bGljYXRpb25zLCBvciB0eXBlcyBvZg0KPiAgICAgYXBwbGljYXRpb25zLCBhcmUgdG8gYmUgc3Bl Y2lmaWVkIGluIHNlcGFyYXRlIGRvY3VtZW50KHMpLg0KPiANCj4gUkZDIDM2OTANCj4gDQo+IFRp dGxlOg0KPiAgICAgSVAgVGVsZXBob255IFJlcXVpcmVtZW50cyBmb3INCj4gICAgIEVtZXJnZW5j eSBUZWxlY29tbXVuaWNhdGlvbiBTZXJ2aWNlIChFVFMpDQo+IA0KPiBBYnN0cmFjdDoNCj4gICAg IFRoaXMgZG9jdW1lbnQgcHJlc2VudHMgYSBsaXN0IG9mIHJlcXVpcmVtZW50cyBpbiBzdXBwb3J0 IG9mIA0KRW1lcmdlbmN5DQo+ICAgICBUZWxlY29tbXVuaWNhdGlvbnMgU2VydmljZSAoRVRTKSB3 aXRoaW4gdGhlIGNvbnRleHQgb2YgSVAgdGVsZXBob255Lg0KPiAgICAgSXQgaXMgYW4gZXh0ZW5z aW9uIHRvIHRoZSBnZW5lcmFsIHJlcXVpcmVtZW50cyBwcmVzZW50ZWQgaW4gUkZDIA0KMzY4OS4N Cj4gICAgIFNvbHV0aW9ucyB0byB0aGVzZSByZXF1aXJlbWVudHMgYXJlIG5vdCBwcmVzZW50ZWQg aW4gdGhpcyBkb2N1bWVudC4NCj4gDQo+IFJGQyA0MTkwDQo+IA0KPiBUaXRsZToNCj4gICAgIEZy YW1ld29yayBmb3IgU3VwcG9ydGluZyBFbWVyZ2VuY3kgVGVsZWNvbW11bmljYXRpb25zDQo+ICAg ICBTZXJ2aWNlIChFVFMpIGluIElQIFRlbGVwaG9ueQ0KPiANCj4gQWJzdHJhY3Q6DQo+ICAgICBU aGlzIGRvY3VtZW50IHByZXNlbnRzIGEgZnJhbWV3b3JrIGZvciBzdXBwb3J0aW5nIGF1dGhvcml6 ZWQsDQo+ICAgICBlbWVyZ2VuY3ktcmVsYXRlZCBjb21tdW5pY2F0aW9uIHdpdGhpbiB0aGUgY29u dGV4dCBvZiBJUCB0ZWxlcGhvbnkuDQo+ICAgICBXZSBwcmVzZW50IGEgc2VyaWVzIG9mIG9iamVj dGl2ZXMgdGhhdCByZWZsZWN0IGEgZ2VuZXJhbCB2aWV3IG9mIGhvdw0KPiAgICAgYXV0aG9yaXpl ZCBlbWVyZ2VuY3kgc2VydmljZSwgaW4gbGluZSB3aXRoIHRoZSBFbWVyZ2VuY3kNCj4gICAgIFRl bGVjb21tdW5pY2F0aW9ucyBTZXJ2aWNlIChFVFMpLCBzaG91bGQgYmUgcmVhbGl6ZWQgd2l0aGlu IHRvZGF5J3MNCj4gICAgIElQIGFyY2hpdGVjdHVyZSBhbmQgc2VydmljZSBtb2RlbHMuICBGcm9t IHRoZXNlIG9iamVjdGl2ZXMsIHdlDQo+ICAgICBwcmVzZW50IGEgY29ycmVzcG9uZGluZyBzZXQg b2YgcHJvdG9jb2xzIGFuZCBjYXBhYmlsaXRpZXMsIHdoaWNoDQo+ICAgICBwcm92aWRlIGEgbW9y ZSBzcGVjaWZpYyBzZXQgb2YgcmVjb21tZW5kYXRpb25zIHJlZ2FyZGluZyBleGlzdGluZw0KPiAg ICAgSUVURiBwcm90b2NvbHMuICBGaW5hbGx5LCB3ZSBwcmVzZW50IHR3byBzY2VuYXJpb3MgdGhh dCBhY3QgYXMNCj4gICAgIGd1aWRpbmcgbW9kZWxzIGZvciB0aGUgb2JqZWN0aXZlcyBhbmQgZnVu Y3Rpb25zIGxpc3RlZCBpbiB0aGlzDQo+ICAgICBkb2N1bWVudC4gIFRoZXNlIG1vZGVscywgY291 cGxlZCB3aXRoIGFuIGV4YW1wbGUgb2YgYW4gZXhpc3RpbmcNCj4gICAgIHNlcnZpY2UgaW4gdGhl IFB1YmxpYyBTd2l0Y2hlZCBUZWxlcGhvbmUgTmV0d29yayAoUFNUTiksIGNvbnRyaWJ1dGUNCj4g ICAgIHRvIGEgY29uc3RyYWluZWQgc29sdXRpb24gc3BhY2UuDQo+IA0KPiBSRkMgNDM3NQ0KPiAN Cj4gVGl0bGU6DQo+ICAgICBFbWVyZ2VuY3kgVGVsZWNvbW11bmljYXRpb25zIFNlcnZpY2VzIChF VFMpIFJlcXVpcmVtZW50cw0KPiAgICAgZm9yIGEgU2luZ2xlIEFkbWluaXN0cmF0aXZlIERvbWFp bg0KPiANCj4gQWJzdHJhY3Q6DQo+ICAgICBUaGlzIGRvY3VtZW50IHByZXNlbnRzIGEgbGlzdCBv ZiByZXF1aXJlbWVudHMgaW4gc3VwcG9ydCBvZiANCkVtZXJnZW5jeQ0KPiAgICAgVGVsZWNvbW11 bmljYXRpb25zIFNlcnZpY2UgKEVUUykgd2l0aGluIGEgc2luZ2xlIGFkbWluaXN0cmF0aXZlDQo+ ICAgICBkb21haW4uICBUaGlzIGRvY3VtZW50IGZvY3VzZXMgb24gYSBzcGVjaWZpYyBzZXQgb2Yg YWRtaW5pc3RyYXRpdmUNCj4gICAgIGNvbnN0cmFpbnRzIGFuZCBzY29wZS4gIFNvbHV0aW9ucyB0 byB0aGVzZSByZXF1aXJlbWVudHMgYXJlIG5vdA0KPiAgICAgcHJlc2VudGVkIGluIHRoaXMgZG9j dW1lbnQuDQo+IA0KPiANCj4gVFNWIFdvcmtpbmcgR3JvdXANCj4gDQo+IFJGQyA0NTQyDQo+IA0K PiBUaXRsZToNCj4gICAgIEltcGxlbWVudGluZyBhbiBFbWVyZ2VuY3kgVGVsZWNvbW11bmljYXRp b25zIFNlcnZpY2UgKEVUUykNCj4gICAgIGZvciBSZWFsLVRpbWUgU2VydmljZXMgaW4gdGhlIElu dGVybmV0IFByb3RvY29sIFN1aXRlDQo+IA0KPiBBYnN0cmFjdDoNCj4gICAgIFJGQ3MgMzY4OSBh bmQgMzY5MCBkZXRhaWwgcmVxdWlyZW1lbnRzIGZvciBhbiBFbWVyZ2VuY3kNCj4gICAgIFRlbGVj b21tdW5pY2F0aW9ucyBTZXJ2aWNlIChFVFMpLCBvZiB3aGljaCBhbiBJbnRlcm5ldCBFbWVyZ2Vu Y3kNCj4gICAgIFByZXBhcmVkbmVzcyBTZXJ2aWNlIChJRVBTKSB3b3VsZCBiZSBhIHBhcnQuICBT b21lIG9mIHRoZXNlIHR5cGVzIG9mDQo+ICAgICBzZXJ2aWNlcyByZXF1aXJlIGNhbGwgcHJlZW1w dGlvbjsgb3RoZXJzIHJlcXVpcmUgY2FsbCBxdWV1aW5nIG9yDQo+ICAgICBvdGhlciBtZWNoYW5p c21zLiAgSUVQUyByZXF1aXJlcyBhIENhbGwgQWRtaXNzaW9uIENvbnRyb2wgKENBQykNCj4gICAg IHByb2NlZHVyZSBhbmQgYSBQZXIgSG9wIEJlaGF2aW9yIChQSEIpIGZvciB0aGUgZGF0YSB0aGF0 IG1lZXQgdGhlDQo+ICAgICBuZWVkcyBvZiB0aGlzIGFyY2hpdGVjdHVyZS4gIFN1Y2ggYSBDQUMg cHJvY2VkdXJlIGFuZCBQSEIgaXMNCj4gICAgIGFwcHJvcHJpYXRlIHRvIGFueSBzZXJ2aWNlIHRo YXQgbWlnaHQgdXNlIEguMzIzIG9yIFNJUCB0byBzZXQgdXANCj4gICAgIHJlYWwtdGltZSBzZXNz aW9ucy4gIFRoZSBrZXkgcmVxdWlyZW1lbnQgaXMgdG8gZ3VhcmFudGVlIGFuIGVsZXZhdGVkDQo+ ICAgICBwcm9iYWJpbGl0eSBvZiBjYWxsIGNvbXBsZXRpb24gdG8gYW4gYXV0aG9yaXplZCB1c2Vy IGluIHRpbWUgb2YNCj4gICAgIGNyaXNpcy4NCj4gDQo+ICAgICBUaGlzIGRvY3VtZW50IHByaW1h cmlseSBkaXNjdXNzZXMgc3VwcG9ydGluZyBFVFMgaW4gdGhlIGNvbnRleHQgb2YNCj4gICAgIHRo ZSBVUyBHb3Zlcm5tZW50IGFuZCBOQVRPLCBiZWNhdXNlIGl0IGZvY3VzZXMgb24gdGhlIE11bHRp LUxldmVsDQo+ICAgICBQcmVjZWRlbmNlIGFuZCBQcmVlbXB0aW9uIChNTFBQKSBhbmQgR292ZXJu bWVudCBFbWVyZ2VuY3kNCj4gICAgIFRlbGVjb21tdW5pY2F0aW9uIFNlcnZpY2UgKEdFVFMpIHN0 YW5kYXJkcy4gIFRoZSBhcmNoaXRlY3R1cmVzDQo+ICAgICBkZXNjcmliZWQgaGVyZSBhcmUgYXBw bGljYWJsZSBiZXlvbmQgdGhlc2Ugb3JnYW5pemF0aW9ucy4NCj4gDQo+IFdvcmsgSW4gUHJvZ3Jl c3M6ICAgZHJhZnQtaWV0Zi10c3Z3Zy1lbWVyZ2VuY3ktcnN2cC0wMy50eHQNCj4gDQo+IFRpdGxl Og0KPiAgICAgUmVzb3VyY2UgUmVTZXJWYXRpb24gUHJvdG92b2wgKFJTVlApIEV4dGVuc2lvbnMg Zm9yDQo+ICAgICBFbWVyZ2VuY3kgU2VydmljZXMNCj4gDQo+IEFic3RyYWN0Og0KPiAgICAgQW4g RW1lcmdlbmN5IFRlbGVjb21tdW5pY2F0aW9ucyBTZXJ2aWNlIChFVFMpIHJlcXVpcmVzIHRoZSBh YmlsaXR5IA0KdG8NCj4gICAgIHByb3ZpZGUgYW4gZWxldmF0ZWQgcHJvYmFiaWxpdHkgb2Ygc2Vz c2lvbiBlc3RhYmxpc2htZW50IHRvIGFuDQo+ICAgICBhdXRob3JpemVkIHVzZXIgaW4gdGltZXMg b2YgbmV0d29yayBjb25nZXN0aW9uICh0eXBpY2FsbHksIGR1cmluZyBhDQo+ICAgICBjcmlzaXMp LiBXaGVuIHN1cHBvcnRlZCBvdmVyIHRoZSBJbnRlcm5ldCBQcm90b2NvbCBzdWl0ZSwgdGhpcyBt YXkgDQpiZQ0KPiAgICAgZmFjaWxpdGF0ZWQgdGhyb3VnaCBhIG5ldHdvcmsgbGF5ZXIgYWRtaXNz aW9uIGNvbnRyb2wgc29sdXRpb24sIA0Kd2hpY2gNCj4gICAgIHN1cHBvcnRzIHByaW9yaXRpemVk IGFjY2VzcyB0byByZXNvdXJjZXMgKGUuZy4sIGJhbmR3aWR0aCkuIFRoZXNlDQo+ICAgICByZXNv dXJjZXMgbWF5IGJlIGV4cGxpY2l0bHkgc2V0IGFzaWRlIGZvciBlbWVyZ2VuY3kgc2VydmljZXMs IG9yIA0KdGhleQ0KPiAgICAgbWF5IGJlIHNoYXJlZCB3aXRoIG90aGVyIHNlc3Npb25zLg0KPiAN Cj4gICAgVGhpcyBkb2N1bWVudCBzcGVjaWZpZXMgUlNWUCBleHRlbnNpb25zIHRoYXQgY2FuIGJl IHVzZWQgdG8gc3VwcG9ydA0KPiAgICAgc3VjaCBhbiBhZG1pc3Npb24gcHJpb3JpdHkgY2FwYWJp bGl0eSBhdCB0aGUgbmV0d29yayBsYXllci4gTm90ZSANCnRoYXQNCj4gICAgIHRoZXNlIGV4dGVu c2lvbnMgcmVwcmVzZW50IG9uZSBwb3NzaWJsZSBzb2x1dGlvbiBjb21wb25lbnQgaW4NCj4gICAg IHNhdGlzZnlpbmcgRVRTIHJlcXVpcmVtZW50cy4gT3RoZXIgc29sdXRpb24gY29tcG9uZW50cywg b3Igb3RoZXINCj4gICAgIHNvbHV0aW9ucywgYXJlIG91dHNpZGUgdGhlIHNjb3BlIG9mIHRoaXMg ZG9jdW1lbnQuDQo+IA0KPiBOU0lTIFdvcmtpbmcgR3JvdXANCj4gDQo+IFdvcmsgSW4gUHJvZ3Jl c3M6IGRyYWZ0LWlldGYtbnNpcy1xb3MtbnNscC0xNC50eHQNCj4gDQo+IFRpdGxlOg0KPiAgICAg TlNMUCBmb3IgUXVhbGl0eS1vZi1TZXJ2aWNlIFNpZ25hbGluZw0KPiANCj4gQWJzdHJhY3Q6DQo+ ICAgICBUaGlzIHNwZWNpZmljYXRpb24gZGVzY3JpYmVzIHRoZSBOU0lTIFNpZ25hbGluZyBMYXll ciBQcm90b2NvbA0KPiAgICAgKE5TTFApIGZvciBzaWduYWxpbmcgUW9TIHJlc2VydmF0aW9ucyBp biB0aGUgSW50ZXJuZXQuICBJdCBpcyBpbg0KPiAgICAgYWNjb3JkYW5jZSB3aXRoIHRoZSBmcmFt ZXdvcmsgYW5kIHJlcXVpcmVtZW50cyBkZXZlbG9wZWQgaW4gTlNJUy4NCj4gICAgIFRvZ2V0aGVy IHdpdGggR0lTVCwgaXQgcHJvdmlkZXMgZnVuY3Rpb25hbGl0eSBzaW1pbGFyIHRvIFJTVlAgYW5k DQo+ICAgICBleHRlbmRzIGl0LiAgVGhlIFFvUyBOU0xQIGlzIGluZGVwZW5kZW50IG9mIHRoZSB1 bmRlcmx5aW5nIFFvUw0KPiAgICAgc3BlY2lmaWNhdGlvbiBvciBhcmNoaXRlY3R1cmUgYW5kIHBy b3ZpZGVzIHN1cHBvcnQgZm9yIGRpZmZlcmVudA0KPiAgICAgcmVzZXJ2YXRpb24gbW9kZWxzLiBJ dCBpcyBzaW1wbGlmaWVkIGJ5IHRoZSBlbGltaW5hdGlvbiBvZiBzdXBwb3J0DQo+ICAgICBmb3Ig bXVsdGljYXN0IGZsb3dzLiBUaGlzIHNwZWNpZmljYXRpb24gZXhwbGFpbnMgdGhlIG92ZXJhbGwN Cj4gICAgIHByb3RvY29sIGFwcHJvYWNoLCBkZXNpZ24gZGVjaXNpb25zIG1hZGUgYW5kIHByb3Zp ZGVzIGV4YW1wbGVzLiAgSXQNCj4gICAgIHNwZWNpZmllcyBvYmplY3QsIG1lc3NhZ2UgIGZvcm1h dHMgYW5kIHByb2Nlc3NpbmcgcnVsZXMuDQo+IA0KPiAtLSANCj4gDQo+IE1hZ251cyBXZXN0ZXJs dW5kDQo+IA0KPiBJRVRGIFRyYW5zcG9ydCBBcmVhIERpcmVjdG9yICYgVFNWV0cgQ2hhaXINCj4g LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLQ0KPiBNdWx0aW1lZGlhIFRlY2hub2xvZ2llcywgRXJpY3Nzb24gUmVzZWFy Y2ggRUFCL1RWTS9NDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gRXJpY3Nzb24gQUIgICAgICAgICAgICAg ICAgfCBQaG9uZSArNDYgOCA0MDQ4Mjg3DQo+IFRvcnNoYW1zZ2F0YW4gMjMgICAgICAgICAgIHwg RmF4ICAgKzQ2IDggNzU3NTU1MA0KPiBTLTE2NCA4MCBTdG9ja2hvbG0sIFN3ZWRlbiB8IG1haWx0 bzogbWFnbnVzLndlc3Rlcmx1bmRAZXJpY3Nzb24uY29tDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gDQo+ IA0KDQo= --=_alternative 0055890785257329_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPk1hZ251cyw8YnI+DQo8YnI+DQpZ b3UgbWlnaHQgd2FudCB0byBhZGQtPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNl PSJzYW5zLXNlcmlmIj5kcmFmdC1wb2xrLXRzdndnLXNpZ25hbGVkLWRvbWFpbi1pZC0wMC50eHQ8 L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPmFuZCA8YnI+DQpkcmFm dC1wb2xrLWVjcml0LWxvY2FsLWVtZXJnZW5jeS1ycGgtbmFtZXNwYWNlLTAxLnR4dDwvZm9udD4N Cjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+KEJvdGggd2VyZSBvbiB0 aGUgYWdlbmRhIGFuZCBkaXNjdXNzZWQuKTwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIg ZmFjZT0ic2Fucy1zZXJpZiI+QW5kIG1heWJlPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNl PSJzYW5zLXNlcmlmIj5kcmFmdC1jYXJsYmVyZy10cmlwLWF0dHJpYnV0ZS1ycC0wMg0KPC9mb250 Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4odGhvdWdoIEkgZGlk IG5vdCBzZWUgaXQgb24gdGhlIGFnZW5kYSk8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0y IGZhY2U9InNhbnMtc2VyaWYiPkphbmV0PC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBm YWNlPSJzYW5zLXNlcmlmIj5QUyw8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9 InNhbnMtc2VyaWYiPk15IHNwZWxsaW5nIGNoZWNrZXIgc2F5cyAmcXVvdDtMaWFpc2lvbiZxdW90 Ow0Kc2hvdWxkIGJlICZxdW90O0xpYWlzb24mcXVvdDssIGJ1dCBpdCBtYXkgYmUgYSBVUyBjZW50 cmljIGRpY3Rpb25hcnkuPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlm Ij5KPC9mb250Pg0KPGJyPjxmb250IHNpemU9Mj48dHQ+TWFnbnVzIFdlc3Rlcmx1bmQgJmx0O21h Z251cy53ZXN0ZXJsdW5kQGVyaWNzc29uLmNvbSZndDsNCndyb3RlIG9uIDA3LzMxLzIwMDcgMTE6 MjE6MjAgQU06PGJyPg0KPGJyPg0KJmd0OyBIaTxicj4NCiZndDsgPGJyPg0KJmd0OyBUaGlzIGlz IHRoZSBkcmFmdCBmb3IgYSBsaWFpc29uIHJlc3BvbnNlIHRvIGJlIHNlbnQgdG8gU0cgMTMgb2Yg dGhlDQo8YnI+DQomZ3Q7IElUVS1UIGZyb20gdGhlIFRTVldHLCBOU0lTLCBTSVAgYW5kIFNJUFBJ TkcgV0dzLiBQbGVhc2UgcHJvdmlkZSBhbnkNCjxicj4NCiZndDsgY29tbWVudHMgYXQgdGhlIGxh dGVzdCBieSB0aGUgMTR0aCBvZiBBdWd1c3QuIEFmdGVyIHRoYXQgd2Ugd2lsbCBhZGRyZXNzDQo8 YnI+DQomZ3Q7IGFueSByYWlzZWQgY29tbWVudHMgYW5kIHNlbmQgdGhlIGxpYWlzb24gdG8gSVRV LVQgYmVmb3JlIHRoZSBlbmQgb2YNCkF1Z3VzdC48YnI+DQomZ3Q7IDxicj4NCiZndDsgU3VibWlz c2lvbjxicj4NCiZndDsgRGF0ZTogJm5ic3A7ICZuYnNwOyAmbmJzcDsmbHQ7dGJkJmd0OywgMjAw Nzxicj4NCiZndDsgPGJyPg0KJmd0OyBGcm9tOiAmbmJzcDsgJm5ic3A7ICZuYnNwOyBJRVRGIFdv cmtpbmcgZ3JvdXBzIFRTVldHLCBOU0lTLCBTSVAgYW5kDQpTSVBQSU5HPGJyPg0KJmd0OyA8YnI+ DQomZ3Q7IFRvOiAmbmJzcDsgJm5ic3A7ICZuYnNwO0dlb3JnZXMgU2ViZWsgJm5ic3A7Jmx0O3Rz YnNnMTNAaXR1LmludCZndDsNCiw8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IEtlaXRo IEtuaWdodHNvbiAmbHQ7a2drQGlncy5uZXQmZ3Q7PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IENjOiAm bmJzcDsgJm5ic3A7ICZuYnNwO01hZ251cyBXZXN0ZXJsdW5kICZsdDttYWdudXMud2VzdGVybHVu ZEBlcmljc3Nvbi5jb20mZ3Q7LDxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtMYXJzDQpFZ2dlcnQgJmx0O2xhcnMu ZWdnZXJ0QG5va2lhLmNvbSZndDssPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0phbWVzDQpQb2xrICZsdDtqbXBv bGtAY2lzY28uY29tJmd0Oyw8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7TWFydGluDQpTdGllbWVybGluZyAmbHQ7 c3RpZW1lcmxpbmdAbmV0bGFiLm5lYy5kZSZndDssPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0pvaG4NCkxvdWdo bmV5ICZsdDtqb2huLmxvdWdobmV5QG5va2lhLmNvbSZndDs8YnI+DQomZ3Q7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7RGVhbg0K V2lsbGlzICZsdDtkZWFuLndpbGxpc0Bzb2Z0YXJtb3IuY29tJmd0Oyw8YnI+DQomZ3Q7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 S2VpdGgNCkRyYWdlICZsdDtkcmFnZUBhbGNhdGVsLWx1Y2VudC5jb20mZ3Q7LDxicj4NCiZndDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDtNYXJ5DQpCYXJuZXMgJmx0O21hcnkuYmFybmVzQG5vcnRlbC5jb20mZ3Q7LDxicj4NCiZn dDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDtHb256YWxvDQpDYW1hcmlsbG8gJmx0O2dvbnphbG8uY2FtYXJpbGxvQGVyaWNzc29u LmNvbSZndDssPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO1Njb3R0DQpCcmFkbmVyICZsdDtzb2JAaGFydmFyZC5l ZHUmZ3Q7LDxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtLaW1iZXJseQ0KS2luZyAmbHQ7a3NraW5nQG1pdHJlLm9y ZyZndDssPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwO1Njb3R0DQpCcmltICZsdDtzd2JAZW1wbG95ZWVzLm9yZyZn dDs8YnI+DQomZ3Q7IDxicj4NCiZndDsgUmVzcG9uc2U8YnI+DQomZ3Q7IENvbnRhY3Q6ICZuYnNw OyBUU1YgV0cgKHRzdi1jaGFpcnNAdG9vbHMuaWV0Zi5vcmcpPGJyPg0KJmd0OyAmbmJzcDsgJm5i c3A7ICZuYnNwOyBOU0lTIChuc2lzLWNoYWlyc0B0b29scy5pZXRmLm9yZyk8YnI+DQomZ3Q7ICZu YnNwOyAmbmJzcDsgJm5ic3A7IFNJUFBJTkcgKHNpcHBpbmctY2hhaXJzQHRvb2xzLmlldGYub3Jn KTxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgU0lQIChzaXAtY2hhaXJzQHRvb2xzLmll dGYub3JnKTxicj4NCiZndDsgJm5ic3A7ICZuYnNwOzxicj4NCiZndDsgUHVycG9zZTogJm5ic3A7 ICZuYnNwO1Jlc3BvbnNlIHRvIExpYWlzb24gUmVxdWVzdDxicj4NCiZndDsgPGJyPg0KJmd0OyBE ZWFkbGluZTogJm5ic3A7IE5vbmU8YnI+DQomZ3Q7IDxicj4NCiZndDsgVGl0bGU6IFJlc3BvbnNl IHRvIGxpYWlzb24gcmVxdWVzdCBmcm9tIElUVS1UIFN0dWR5IEdyb3VwIDEzIHdvcmsNCm9uIDxi cj4NCiZndDsgZW1lcmdlbmN5IHRlbGVjb21tdW5pY2F0aW9uczxicj4NCiZndDsgPGJyPg0KJmd0 OyBUaGlzIGlzIGEgcmVzcG9uc2UgdG8gdGhlIGxpYWlzb24gcmVxdWVzdCBtYWRlIGJ5IFEzLzEz IHJlZ2FyZGluZw0KPGJyPg0KJmd0OyBlbWVyZ2VuY3kgdGVsZWNvbW11bmljYXRpb25zIChSRUY6 IE5HTi1HU0kvRE9DIOKAkyA2MCBSZXYuMikuIFdlIHdvdWxkDQo8YnI+DQomZ3Q7IGZpcnN0IGxp a2UgdG8gYXBvbG9naXplIGZvciBmYWlsaW5nIHRvIG1lZXQgdGhlIGRlYWRsaW5lIGluIHJlc3Bv bmRpbmcuDQo8YnI+DQomZ3Q7IFdlIGRvIGhvcGUgdGhhdCB0aGUgbGF0ZSBhbnN3ZXIgc3RpbGwg Y2FuIGJlIG9mIHNvbWUgdXNlLjxicj4NCiZndDsgPGJyPg0KJmd0OyBUaGUgbGlhaXNvbiByZXF1 ZXN0IHdhcyBtYWRlIHRvIHRoZSBmb2xsb3dpbmcgd29ya2luZyBncm91cHMgKFdHKToNCjxicj4N CiZndDsgSUVQUkVQLCBUU1ZXRywgYW5kIE5TSVMuIFNpbmNlIHRoZSByZXF1ZXN0IHdhcyBzZW50 IHRoZSBJRVBSRVAgV0cNCmhhcyA8YnI+DQomZ3Q7IGNvbmNsdWRlZC4gSW4gYWRkaXRpb24gdG8g dGhlIFdHcyBmcm9tIHdoaWNoIGluZm9ybWF0aW9uIHdhcyByZXF1ZXN0ZWQsDQo8YnI+DQomZ3Q7 IHdlIGFsc28gdGhpbmsgdGhhdCB3b3JrIHBlcmZvcm1lZCBieSB0aGUgU0lQIGFuZCBTSVBQSU5H IFdHIG1heSBiZQ0Kb2YgPGJyPg0KJmd0OyByZWxldmFuY2UuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7 IFB1cnN1YW50IHRvIElUVS1UIFN0dWR5IEdyb3VwIDEzIHJlcXVlc3QgZm9yIGluZm9ybWF0aW9u IG9uIHJlbGV2YW50DQphbmQgPGJyPg0KJmd0OyByZWxhdGVkIHdvcmsgaW4gdGhlIElFVEYgcmVn YXJkaW5nIGVtZXJnZW5jeSBjb21tdW5pY2F0aW9ucywgd2UgbGlzdA0KPGJyPg0KJmd0OyBiZWxv dyBSRkNzIGFuZCB3b3JrcyBpbiBwcm9ncmVzcyB0aGF0IHdlIGZlZWwgbWF5IGJlIG9mIGludGVy ZXN0IHRvDQp5b3VyIDxicj4NCiZndDsgZ3JvdXAuICZuYnNwO1NvbWUgb2YgdGhlIGNvbXBsZXRl ZCB3b3JrIGlzIEluZm9ybWF0aW9uYWwsIGFuZCBvdGhlcnMNCmFyZSBpbiA8YnI+DQomZ3Q7IHRo ZSBjYXRlZ29yeSBvZiBTdGFuZGFyZHMgVHJhY2suPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFEuMy8x MyBhbHNvIHJlcXVlc3RlZCB0aGF0IHdlIGtlZXAgeW91IGluZm9ybWVkIG9mIGFueSBkZXZlbG9w bWVudHMNCmluIDxicj4NCiZndDsgcmVnYXJkcyB0byBlbWVyZ2VuY3kgdGVsZWNvbW11bmljYXRp b25zLiBJbiB0aG9zZSByZWdhcmRzIHdlIHdvdWxkDQpsaWtlIDxicj4NCiZndDsgdG8gbWFrZSB5 b3UgYXdhcmUgdGhhdCBJRVRGIG1haWxpbmcgbGlzdCBwYXJ0aWNpcGF0aW9uIGFuZCBkb2N1bWVu dA0KPGJyPg0KJmd0OyBpbmZvcm1hdGlvbiBpcyBmcmVlIGFuZCBvcGVuIGZvciBhbnlvbmUuIEFs bG93aW5nIHBhcnRpY2lwYW50cyBpbg0KUS4zLzEzIDxicj4NCiZndDsgdG8ga2VlcCB0aGVtIHNl bHZlcyBpbmZvcm1lZCBvZiBhbnkgZGV2ZWxvcG1lbnRzLiBJZiBRLjMvMTMgZGVzaXJlDQp0byA8 YnI+DQomZ3Q7IGdldCBmdXJ0aGVyIGluZm9ybWF0aW9uIGFib3V0IHNwZWNpZmljIG9uZ29pbmcg d29yaywgdGhlbiBwbGVhc2Ugc2VuZA0KYSA8YnI+DQomZ3Q7IGxpYWlzb24gcmVxdWVzdCB0byB0 aGUgcmVzcG9uc2libGUgV0cgZm9yIHRob3NlIHNwZWNpZmljIGRvY3VtZW50cy48YnI+DQomZ3Q7 IDxicj4NCiZndDsgVGhlIGZvbGxvd2luZyBsaXN0IGlzIGRpdmlkZWQgdW5kZXIgdGhlIGFzc29j aWF0ZWQgd29ya2luZyBncm91cHMNCmZyb20gPGJyPg0KJmd0OyB3aGljaCB0aGUgd29yayBoYXMg YmVlbiBkb25lIHdpdGhpbiB0aGUgSUVURi48YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0 OyBTSVAgV29ya2luZyBHcm91cDxicj4NCiZndDsgPGJyPg0KJmd0OyBSRkMgNDQxMTxicj4NCiZn dDsgPGJyPg0KJmd0OyBUaXRsZTo8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgRXh0ZW5kaW5nIHRo ZSBTZXNzaW9uIEluaXRpYXRpb24gUHJvdG9jb2wgKFNJUCk8YnI+DQomZ3Q7ICZuYnNwOyAmbmJz cDsgUmVhc29uIEhlYWRlciBmb3IgUHJlZW1wdGlvbiBFdmVudHM8YnI+DQomZ3Q7IDxicj4NCiZn dDsgQWJzdHJhY3Q6PGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7VGhpcyBkb2N1bWVudCBwcm9wb3Nl cyBhbiBJQU5BIFJlZ2lzdHJhdGlvbiBleHRlbnNpb24NCnRvIHRoZSBTZXNzaW9uPGJyPg0KJmd0 OyAmbmJzcDsgJm5ic3A7IEluaXRpYXRpb24gUHJvdG9jb2wgKFNJUCkgUmVhc29uIEhlYWRlciB0 byBiZSBpbmNsdWRlZA0KaW4gYSBCWUU8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgTWV0aG9kIFJl cXVlc3QgYXMgYSByZXN1bHQgb2YgYSBzZXNzaW9uIHByZWVtcHRpb24gZXZlbnQsDQplaXRoZXIg YXQgYTxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyB1c2VyIGFnZW50IChVQSksIG9yIHNvbWV3aGVy ZSBpbiB0aGUgbmV0d29yayBpbnZvbHZpbmcNCmE8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgcmVz ZXJ2YXRpb24tYmFzZWQgcHJvdG9jb2wgc3VjaCBhcyB0aGUgUmVzb3VyY2UgUmVTZXJWYXRpb24N ClByb3RvY29sPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7IChSU1ZQKSBvciBOZXh0IFN0ZXBzIGlu IFNpZ25hbGluZyAoTlNJUykuICZuYnNwO1RoaXMNCmRvY3VtZW50IGRvZXMgbm90PGJyPg0KJmd0 OyAmbmJzcDsgJm5ic3A7IGF0dGVtcHQgdG8gYWRkcmVzcyByb3V0ZXJzIGZhaWxpbmcgaW4gdGhl IHBhY2tldCBwYXRoOw0KaW5zdGVhZCwgaXQ8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgYWRkcmVz c2VzIGEgZGVsaWJlcmF0ZSB0ZWFyIGRvd24gb2YgYSBmbG93IGJldHdlZW4gVUFzLA0KYW5kIGlu Zm9ybXM8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgdGhlIHRlcm1pbmF0ZWQgVUEocykgd2l0aCBh biBpbmRpY2F0aW9uIG9mIHdoYXQgb2NjdXJyZWQuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFJGQyA0 NDEyPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFRpdGxlOjxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyBD b21tdW5pY2F0aW9ucyBSZXNvdXJjZSBQcmlvcml0eSBmb3IgdGhlIFNlc3Npb24gSW5pdGlhdGlv bjxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyBQcm90b2NvbCAoU0lQKTxicj4NCiZndDsgPGJyPg0K Jmd0OyBBYnN0cmFjdDo8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgVGhpcyBkb2N1bWVudCBkZWZp bmVzIHR3byBuZXcgU2Vzc2lvbiBJbml0aWF0aW9uIFByb3RvY29sDQooU0lQKTxicj4NCiZndDsg Jm5ic3A7ICZuYnNwOyBoZWFkZXIgZmllbGRzIGZvciBjb21tdW5pY2F0aW5nIHJlc291cmNlIHBy aW9yaXR5LCBuYW1lbHksPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZxdW90O1Jlc291cmNlLVBy aW9yaXR5JnF1b3Q7IGFuZCAmcXVvdDtBY2NlcHQtUmVzb3VyY2UtUHJpb3JpdHkmcXVvdDsuDQom bmJzcDtUaGU8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJnF1b3Q7UmVzb3VyY2UtUHJpb3JpdHkm cXVvdDsgaGVhZGVyIGZpZWxkIGNhbiBpbmZsdWVuY2UNCnRoZSBiZWhhdmlvciBvZiBTSVA8YnI+ DQomZ3Q7ICZuYnNwOyAmbmJzcDsgdXNlciBhZ2VudHMgKHN1Y2ggYXMgdGVsZXBob25lIGdhdGV3 YXlzIGFuZCBJUCB0ZWxlcGhvbmVzKQ0KYW5kIFNJUDxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyBw cm94aWVzLiAmbmJzcDtJdCBkb2VzIG5vdCBkaXJlY3RseSBpbmZsdWVuY2UgdGhlIGZvcndhcmRp bmcNCmJlaGF2aW9yIG9mPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7IElQIHJvdXRlcnMuPGJyPg0K Jmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyBTSVBQSU5HIFdvcmtpbmcgR3Jv dXA8YnI+DQomZ3Q7IDxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyBUaGUgYmVsb3cgdHdvIGRvY3Vt ZW50cyBhcmUgcHJvcG9zZWQgd29yayBpdGVtcyBub3QNCnlldCBhY2NlcHRlZCBhczxicj4NCiZn dDsgJm5ic3A7ICZuYnNwOyBJRVRGIFdHIGl0ZW1zIGJ1dCBhcmUgbGlrZWx5IG9mIGludGVyZXN0 IGFzIHRoZXkgdXBkYXRlDQpSRkMgNDQxMi48YnI+DQomZ3Q7IDxicj4NCiZndDsgV29yayBJbiBQ cm9ncmVzczogJm5ic3A7IGRyYWZ0LXBvbGstc2lwLXJwaC1pbi1yZXNwb25zZXMtMDA8YnI+DQom Z3Q7IDxicj4NCiZndDsgVGl0bGU6PGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7IEFsbG93aW5nIFNJ UCBSZXNvdXJjZSBQcmlvcml0eSBIZWFkZXIgaW4gU0lQIFJlc3BvbnNlczxicj4NCiZndDsgPGJy Pg0KJmd0OyBBYnN0cmFjdDo8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgVGhlIFNlc3Npb24gSW5p dGlhdGlvbiBQcm90b2NvbCAoU0lQKSBSZXNvdXJjZSBQcmlvcml0eQ0KSGVhZGVyPGJyPg0KJmd0 OyAmbmJzcDsgJm5ic3A7IChSUEgpLCBpbiBpdHMgY3VycmVudCBmb3JtLCBpcyBpZ25vcmVkIGlu IFNJUCByZXNwb25zZXMuDQombmJzcDtUaGlzIHdhcyBhPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7 IGRlc2lnbiBjaG9pY2UgZHVyaW5nIFJGQyA0NDEyJ3MgZGV2ZWxvcG1lbnQuIFRoaXMgaXMNCm5v dyBjb25zaWRlcmVkPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7IGEgYmFkIGRlc2lnbiBjaG9pY2Ug aW4gY2VydGFpbiBzY2VuYXJpb3MuICZuYnNwO1RoaXMNCmRvY3VtZW50IGNvcnJlY3RzPGJyPg0K Jmd0OyAmbmJzcDsgJm5ic3A7IFJGQyA0NDEyJ3MgY29tbXVuaWNhdGlvbnMgbW9kZWwgYnkgb3B0 aW9uYWxseSBhbGxvd2luZw0KYSBTSVAgc2VydmVyPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7IG9y IHVzZXIgYWdlbnQgY2xpZW50IHRvIHByb2Nlc3MgdGhlIFJlc291cmNlLVByaW9yaXR5DQpIZWFk ZXIgaW4gYTxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyByZXNwb25zZS48YnI+DQomZ3Q7IDxicj4N CiZndDsgV29yayBJbiBQcm9ncmVzczogJm5ic3A7IGRyYWZ0LXBvbGstc2lwLXJwaC1uZXctbmFt ZXNwYWNlcy0tMDA8YnI+DQomZ3Q7IDxicj4NCiZndDsgVGl0bGU6PGJyPg0KJmd0OyAmbmJzcDsg Jm5ic3A7IE5ldyBTZXNzaW9uIEluaXRpYXRpb24gUHJvdG9jb2wgUmVzb3VyY2UtUHJpb3JpdHkg SGVhZGVyDQpOYW1lc3BhY2VzPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7IGZvciB0aGUgRGVmZW5z ZSBJbmZvcm1hdGlvbiBTeXN0ZW1zIEFnZW5jeTxicj4NCiZndDsgPGJyPg0KJmd0OyBBYnN0cmFj dDo8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgVGhpcyBkb2N1bWVudCBjcmVhdGVzIGFkZGl0aW9u YWwgU2Vzc2lvbiBJbml0aWF0aW9uDQpQcm90b2NvbDxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyBS ZXNvdXJjZS1Qcmlvcml0eSBoZWFkZXIgbmFtZXNwYWNlcywgdG8gYmUgSUFOQSByZWdpc3RlcmVk Lg0KJm5ic3A7VGhpczxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyBkb2N1bWVudCBpbnRlbmRzIHRv IHVwZGF0ZSBSRkMgNDQxMiwgYXMgYSBQcm9wb3NlZCBTdGFuZGFyZA0KZG9jdW1lbnQ8YnI+DQom Z3Q7ICZuYnNwOyAmbmJzcDsgaWYgcHVibGlzaGVkIGJ5IHRoZSBSRkMtRWRpdG9yLjxicj4NCiZn dDsgPGJyPg0KJmd0OyBJRVBSRVAgV29ya2luZyBHcm91cDxicj4NCiZndDsgPGJyPg0KJmd0OyBS RkMgMzQ4Nzxicj4NCiZndDsgPGJyPg0KJmd0OyBUaXRsZTo8YnI+DQomZ3Q7ICZuYnNwOyAmbmJz cDsgUmVxdWlyZW1lbnRzIGZvciBSZXNvdXJjZSBQcmlvcml0eSBNZWNoYW5pc21zIGZvciB0aGU8 YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgU2Vzc2lvbiBJbml0aWF0aW9uIFByb3RvY29sIChTSVAp PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEFic3RyYWN0Ojxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyBU aGlzIGRvY3VtZW50IHN1bW1hcml6ZXMgcmVxdWlyZW1lbnRzIGZvciBwcmlvcml0aXppbmcNCmFj Y2VzcyB0bzxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyBjaXJjdWl0LXN3aXRjaGVkIG5ldHdvcmss IGVuZCBzeXN0ZW0gYW5kIHByb3h5IHJlc291cmNlcw0KZm9yPGJyPg0KJmd0OyAmbmJzcDsgJm5i c3A7IGVtZXJnZW5jeSBwcmVwYXJlZG5lc3MgY29tbXVuaWNhdGlvbnMgdXNpbmcgdGhlIFNlc3Np b24NCkluaXRpYXRpb248YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgUHJvdG9jb2wgKFNJUCkuPGJy Pg0KJmd0OyA8YnI+DQomZ3Q7IFJGQyAzNjg5PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFRpdGxlOjxi cj4NCiZndDsgJm5ic3A7ICZuYnNwOyBHZW5lcmFsIFJlcXVpcmVtZW50cyBmb3I8YnI+DQomZ3Q7 ICZuYnNwOyAmbmJzcDsgRW1lcmdlbmN5IFRlbGVjb21tdW5pY2F0aW9uIFNlcnZpY2UgKEVUUyk8 YnI+DQomZ3Q7IDxicj4NCiZndDsgQWJzdHJhY3Q6PGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7IFRo aXMgZG9jdW1lbnQgcHJlc2VudHMgYSBsaXN0IG9mIGdlbmVyYWwgcmVxdWlyZW1lbnRzDQppbiBz dXBwb3J0IG9mPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7IEVtZXJnZW5jeSBUZWxlY29tbXVuaWNh dGlvbnMgU2VydmljZSAoRVRTKS4gJm5ic3A7U29sdXRpb25zDQp0byB0aGVzZTxicj4NCiZndDsg Jm5ic3A7ICZuYnNwOyByZXF1aXJlbWVudHMgYXJlIG5vdCBwcmVzZW50ZWQgaW4gdGhpcyBkb2N1 bWVudC4gJm5ic3A7QWRkaXRpb25hbDxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyByZXF1aXJlbWVu dHMgcGVydGFpbmluZyB0byBzcGVjaWZpYyBhcHBsaWNhdGlvbnMsIG9yDQp0eXBlcyBvZjxicj4N CiZndDsgJm5ic3A7ICZuYnNwOyBhcHBsaWNhdGlvbnMsIGFyZSB0byBiZSBzcGVjaWZpZWQgaW4g c2VwYXJhdGUgZG9jdW1lbnQocykuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFJGQyAzNjkwPGJyPg0K Jmd0OyA8YnI+DQomZ3Q7IFRpdGxlOjxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyBJUCBUZWxlcGhv bnkgUmVxdWlyZW1lbnRzIGZvcjxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyBFbWVyZ2VuY3kgVGVs ZWNvbW11bmljYXRpb24gU2VydmljZSAoRVRTKTxicj4NCiZndDsgPGJyPg0KJmd0OyBBYnN0cmFj dDo8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgVGhpcyBkb2N1bWVudCBwcmVzZW50cyBhIGxpc3Qg b2YgcmVxdWlyZW1lbnRzIGluIHN1cHBvcnQNCm9mIEVtZXJnZW5jeTxicj4NCiZndDsgJm5ic3A7 ICZuYnNwOyBUZWxlY29tbXVuaWNhdGlvbnMgU2VydmljZSAoRVRTKSB3aXRoaW4gdGhlIGNvbnRl eHQNCm9mIElQIHRlbGVwaG9ueS48YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgSXQgaXMgYW4gZXh0 ZW5zaW9uIHRvIHRoZSBnZW5lcmFsIHJlcXVpcmVtZW50cyBwcmVzZW50ZWQNCmluIFJGQyAzNjg5 Ljxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyBTb2x1dGlvbnMgdG8gdGhlc2UgcmVxdWlyZW1lbnRz IGFyZSBub3QgcHJlc2VudGVkIGluDQp0aGlzIGRvY3VtZW50Ljxicj4NCiZndDsgPGJyPg0KJmd0 OyBSRkMgNDE5MDxicj4NCiZndDsgPGJyPg0KJmd0OyBUaXRsZTo8YnI+DQomZ3Q7ICZuYnNwOyAm bmJzcDsgRnJhbWV3b3JrIGZvciBTdXBwb3J0aW5nIEVtZXJnZW5jeSBUZWxlY29tbXVuaWNhdGlv bnM8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgU2VydmljZSAoRVRTKSBpbiBJUCBUZWxlcGhvbnk8 YnI+DQomZ3Q7IDxicj4NCiZndDsgQWJzdHJhY3Q6PGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7IFRo aXMgZG9jdW1lbnQgcHJlc2VudHMgYSBmcmFtZXdvcmsgZm9yIHN1cHBvcnRpbmcgYXV0aG9yaXpl ZCw8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgZW1lcmdlbmN5LXJlbGF0ZWQgY29tbXVuaWNhdGlv biB3aXRoaW4gdGhlIGNvbnRleHQgb2YNCklQIHRlbGVwaG9ueS48YnI+DQomZ3Q7ICZuYnNwOyAm bmJzcDsgV2UgcHJlc2VudCBhIHNlcmllcyBvZiBvYmplY3RpdmVzIHRoYXQgcmVmbGVjdCBhIGdl bmVyYWwNCnZpZXcgb2YgaG93PGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7IGF1dGhvcml6ZWQgZW1l cmdlbmN5IHNlcnZpY2UsIGluIGxpbmUgd2l0aCB0aGUgRW1lcmdlbmN5PGJyPg0KJmd0OyAmbmJz cDsgJm5ic3A7IFRlbGVjb21tdW5pY2F0aW9ucyBTZXJ2aWNlIChFVFMpLCBzaG91bGQgYmUgcmVh bGl6ZWQNCndpdGhpbiB0b2RheSdzPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7IElQIGFyY2hpdGVj dHVyZSBhbmQgc2VydmljZSBtb2RlbHMuICZuYnNwO0Zyb20gdGhlc2UNCm9iamVjdGl2ZXMsIHdl PGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7IHByZXNlbnQgYSBjb3JyZXNwb25kaW5nIHNldCBvZiBw cm90b2NvbHMgYW5kIGNhcGFiaWxpdGllcywNCndoaWNoPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7 IHByb3ZpZGUgYSBtb3JlIHNwZWNpZmljIHNldCBvZiByZWNvbW1lbmRhdGlvbnMgcmVnYXJkaW5n DQpleGlzdGluZzxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyBJRVRGIHByb3RvY29scy4gJm5ic3A7 RmluYWxseSwgd2UgcHJlc2VudCB0d28gc2NlbmFyaW9zDQp0aGF0IGFjdCBhczxicj4NCiZndDsg Jm5ic3A7ICZuYnNwOyBndWlkaW5nIG1vZGVscyBmb3IgdGhlIG9iamVjdGl2ZXMgYW5kIGZ1bmN0 aW9ucyBsaXN0ZWQNCmluIHRoaXM8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgZG9jdW1lbnQuICZu YnNwO1RoZXNlIG1vZGVscywgY291cGxlZCB3aXRoIGFuIGV4YW1wbGUNCm9mIGFuIGV4aXN0aW5n PGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7IHNlcnZpY2UgaW4gdGhlIFB1YmxpYyBTd2l0Y2hlZCBU ZWxlcGhvbmUgTmV0d29yayAoUFNUTiksDQpjb250cmlidXRlPGJyPg0KJmd0OyAmbmJzcDsgJm5i c3A7IHRvIGEgY29uc3RyYWluZWQgc29sdXRpb24gc3BhY2UuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7 IFJGQyA0Mzc1PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFRpdGxlOjxicj4NCiZndDsgJm5ic3A7ICZu YnNwOyBFbWVyZ2VuY3kgVGVsZWNvbW11bmljYXRpb25zIFNlcnZpY2VzIChFVFMpIFJlcXVpcmVt ZW50czxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyBmb3IgYSBTaW5nbGUgQWRtaW5pc3RyYXRpdmUg RG9tYWluPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEFic3RyYWN0Ojxicj4NCiZndDsgJm5ic3A7ICZu YnNwOyBUaGlzIGRvY3VtZW50IHByZXNlbnRzIGEgbGlzdCBvZiByZXF1aXJlbWVudHMgaW4gc3Vw cG9ydA0Kb2YgRW1lcmdlbmN5PGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7IFRlbGVjb21tdW5pY2F0 aW9ucyBTZXJ2aWNlIChFVFMpIHdpdGhpbiBhIHNpbmdsZSBhZG1pbmlzdHJhdGl2ZTxicj4NCiZn dDsgJm5ic3A7ICZuYnNwOyBkb21haW4uICZuYnNwO1RoaXMgZG9jdW1lbnQgZm9jdXNlcyBvbiBh IHNwZWNpZmljIHNldA0Kb2YgYWRtaW5pc3RyYXRpdmU8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsg Y29uc3RyYWludHMgYW5kIHNjb3BlLiAmbmJzcDtTb2x1dGlvbnMgdG8gdGhlc2UgcmVxdWlyZW1l bnRzDQphcmUgbm90PGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7IHByZXNlbnRlZCBpbiB0aGlzIGRv Y3VtZW50Ljxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFRTViBXb3JraW5nIEdyb3Vw PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFJGQyA0NTQyPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFRpdGxl Ojxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyBJbXBsZW1lbnRpbmcgYW4gRW1lcmdlbmN5IFRlbGVj b21tdW5pY2F0aW9ucyBTZXJ2aWNlDQooRVRTKTxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyBmb3Ig UmVhbC1UaW1lIFNlcnZpY2VzIGluIHRoZSBJbnRlcm5ldCBQcm90b2NvbCBTdWl0ZTxicj4NCiZn dDsgPGJyPg0KJmd0OyBBYnN0cmFjdDo8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgUkZDcyAzNjg5 IGFuZCAzNjkwIGRldGFpbCByZXF1aXJlbWVudHMgZm9yIGFuIEVtZXJnZW5jeTxicj4NCiZndDsg Jm5ic3A7ICZuYnNwOyBUZWxlY29tbXVuaWNhdGlvbnMgU2VydmljZSAoRVRTKSwgb2Ygd2hpY2gg YW4gSW50ZXJuZXQNCkVtZXJnZW5jeTxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyBQcmVwYXJlZG5l c3MgU2VydmljZSAoSUVQUykgd291bGQgYmUgYSBwYXJ0LiAmbmJzcDtTb21lDQpvZiB0aGVzZSB0 eXBlcyBvZjxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyBzZXJ2aWNlcyByZXF1aXJlIGNhbGwgcHJl ZW1wdGlvbjsgb3RoZXJzIHJlcXVpcmUgY2FsbA0KcXVldWluZyBvcjxicj4NCiZndDsgJm5ic3A7 ICZuYnNwOyBvdGhlciBtZWNoYW5pc21zLiAmbmJzcDtJRVBTIHJlcXVpcmVzIGEgQ2FsbCBBZG1p c3Npb24NCkNvbnRyb2wgKENBQyk8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgcHJvY2VkdXJlIGFu ZCBhIFBlciBIb3AgQmVoYXZpb3IgKFBIQikgZm9yIHRoZSBkYXRhDQp0aGF0IG1lZXQgdGhlPGJy Pg0KJmd0OyAmbmJzcDsgJm5ic3A7IG5lZWRzIG9mIHRoaXMgYXJjaGl0ZWN0dXJlLiAmbmJzcDtT dWNoIGEgQ0FDIHByb2NlZHVyZQ0KYW5kIFBIQiBpczxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyBh cHByb3ByaWF0ZSB0byBhbnkgc2VydmljZSB0aGF0IG1pZ2h0IHVzZSBILjMyMyBvciBTSVANCnRv IHNldCB1cDxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyByZWFsLXRpbWUgc2Vzc2lvbnMuICZuYnNw O1RoZSBrZXkgcmVxdWlyZW1lbnQgaXMgdG8NCmd1YXJhbnRlZSBhbiBlbGV2YXRlZDxicj4NCiZn dDsgJm5ic3A7ICZuYnNwOyBwcm9iYWJpbGl0eSBvZiBjYWxsIGNvbXBsZXRpb24gdG8gYW4gYXV0 aG9yaXplZCB1c2VyDQppbiB0aW1lIG9mPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7IGNyaXNpcy48 YnI+DQomZ3Q7IDxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyBUaGlzIGRvY3VtZW50IHByaW1hcmls eSBkaXNjdXNzZXMgc3VwcG9ydGluZyBFVFMgaW4NCnRoZSBjb250ZXh0IG9mPGJyPg0KJmd0OyAm bmJzcDsgJm5ic3A7IHRoZSBVUyBHb3Zlcm5tZW50IGFuZCBOQVRPLCBiZWNhdXNlIGl0IGZvY3Vz ZXMgb24gdGhlDQpNdWx0aS1MZXZlbDxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyBQcmVjZWRlbmNl IGFuZCBQcmVlbXB0aW9uIChNTFBQKSBhbmQgR292ZXJubWVudCBFbWVyZ2VuY3k8YnI+DQomZ3Q7 ICZuYnNwOyAmbmJzcDsgVGVsZWNvbW11bmljYXRpb24gU2VydmljZSAoR0VUUykgc3RhbmRhcmRz LiAmbmJzcDtUaGUNCmFyY2hpdGVjdHVyZXM8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgZGVzY3Jp YmVkIGhlcmUgYXJlIGFwcGxpY2FibGUgYmV5b25kIHRoZXNlIG9yZ2FuaXphdGlvbnMuPGJyPg0K Jmd0OyA8YnI+DQomZ3Q7IFdvcmsgSW4gUHJvZ3Jlc3M6ICZuYnNwOyBkcmFmdC1pZXRmLXRzdndn LWVtZXJnZW5jeS1yc3ZwLTAzLnR4dDxicj4NCiZndDsgPGJyPg0KJmd0OyBUaXRsZTo8YnI+DQom Z3Q7ICZuYnNwOyAmbmJzcDsgUmVzb3VyY2UgUmVTZXJWYXRpb24gUHJvdG92b2wgKFJTVlApIEV4 dGVuc2lvbnMgZm9yPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7IEVtZXJnZW5jeSBTZXJ2aWNlczxi cj4NCiZndDsgPGJyPg0KJmd0OyBBYnN0cmFjdDo8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgQW4g RW1lcmdlbmN5IFRlbGVjb21tdW5pY2F0aW9ucyBTZXJ2aWNlIChFVFMpIHJlcXVpcmVzDQp0aGUg YWJpbGl0eSB0bzxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyBwcm92aWRlIGFuIGVsZXZhdGVkIHBy b2JhYmlsaXR5IG9mIHNlc3Npb24gZXN0YWJsaXNobWVudA0KdG8gYW48YnI+DQomZ3Q7ICZuYnNw OyAmbmJzcDsgYXV0aG9yaXplZCB1c2VyIGluIHRpbWVzIG9mIG5ldHdvcmsgY29uZ2VzdGlvbiAo dHlwaWNhbGx5LA0KZHVyaW5nIGE8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgY3Jpc2lzKS4gV2hl biBzdXBwb3J0ZWQgb3ZlciB0aGUgSW50ZXJuZXQgUHJvdG9jb2wgc3VpdGUsDQp0aGlzIG1heSBi ZTxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyBmYWNpbGl0YXRlZCB0aHJvdWdoIGEgbmV0d29yayBs YXllciBhZG1pc3Npb24gY29udHJvbA0Kc29sdXRpb24sIHdoaWNoPGJyPg0KJmd0OyAmbmJzcDsg Jm5ic3A7IHN1cHBvcnRzIHByaW9yaXRpemVkIGFjY2VzcyB0byByZXNvdXJjZXMgKGUuZy4sIGJh bmR3aWR0aCkuDQpUaGVzZTxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyByZXNvdXJjZXMgbWF5IGJl IGV4cGxpY2l0bHkgc2V0IGFzaWRlIGZvciBlbWVyZ2VuY3kNCnNlcnZpY2VzLCBvciB0aGV5PGJy Pg0KJmd0OyAmbmJzcDsgJm5ic3A7IG1heSBiZSBzaGFyZWQgd2l0aCBvdGhlciBzZXNzaW9ucy48 YnI+DQomZ3Q7IDxicj4NCiZndDsgJm5ic3A7ICZuYnNwO1RoaXMgZG9jdW1lbnQgc3BlY2lmaWVz IFJTVlAgZXh0ZW5zaW9ucyB0aGF0IGNhbiBiZSB1c2VkDQp0byBzdXBwb3J0PGJyPg0KJmd0OyAm bmJzcDsgJm5ic3A7IHN1Y2ggYW4gYWRtaXNzaW9uIHByaW9yaXR5IGNhcGFiaWxpdHkgYXQgdGhl IG5ldHdvcmsNCmxheWVyLiBOb3RlIHRoYXQ8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgdGhlc2Ug ZXh0ZW5zaW9ucyByZXByZXNlbnQgb25lIHBvc3NpYmxlIHNvbHV0aW9uIGNvbXBvbmVudA0KaW48 YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgc2F0aXNmeWluZyBFVFMgcmVxdWlyZW1lbnRzLiBPdGhl ciBzb2x1dGlvbiBjb21wb25lbnRzLA0Kb3Igb3RoZXI8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsg c29sdXRpb25zLCBhcmUgb3V0c2lkZSB0aGUgc2NvcGUgb2YgdGhpcyBkb2N1bWVudC48YnI+DQom Z3Q7IDxicj4NCiZndDsgTlNJUyBXb3JraW5nIEdyb3VwPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFdv cmsgSW4gUHJvZ3Jlc3M6IGRyYWZ0LWlldGYtbnNpcy1xb3MtbnNscC0xNC50eHQ8YnI+DQomZ3Q7 IDxicj4NCiZndDsgVGl0bGU6PGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7IE5TTFAgZm9yIFF1YWxp dHktb2YtU2VydmljZSBTaWduYWxpbmc8YnI+DQomZ3Q7IDxicj4NCiZndDsgQWJzdHJhY3Q6PGJy Pg0KJmd0OyAmbmJzcDsgJm5ic3A7IFRoaXMgc3BlY2lmaWNhdGlvbiBkZXNjcmliZXMgdGhlIE5T SVMgU2lnbmFsaW5nIExheWVyDQpQcm90b2NvbDxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyAoTlNM UCkgZm9yIHNpZ25hbGluZyBRb1MgcmVzZXJ2YXRpb25zIGluIHRoZSBJbnRlcm5ldC4NCiZuYnNw O0l0IGlzIGluPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7IGFjY29yZGFuY2Ugd2l0aCB0aGUgZnJh bWV3b3JrIGFuZCByZXF1aXJlbWVudHMgZGV2ZWxvcGVkDQppbiBOU0lTLjxicj4NCiZndDsgJm5i c3A7ICZuYnNwOyBUb2dldGhlciB3aXRoIEdJU1QsIGl0IHByb3ZpZGVzIGZ1bmN0aW9uYWxpdHkg c2ltaWxhcg0KdG8gUlNWUCBhbmQ8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgZXh0ZW5kcyBpdC4g Jm5ic3A7VGhlIFFvUyBOU0xQIGlzIGluZGVwZW5kZW50IG9mIHRoZQ0KdW5kZXJseWluZyBRb1M8 YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgc3BlY2lmaWNhdGlvbiBvciBhcmNoaXRlY3R1cmUgYW5k IHByb3ZpZGVzIHN1cHBvcnQgZm9yDQpkaWZmZXJlbnQ8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsg cmVzZXJ2YXRpb24gbW9kZWxzLiBJdCBpcyBzaW1wbGlmaWVkIGJ5IHRoZSBlbGltaW5hdGlvbg0K b2Ygc3VwcG9ydDxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyBmb3IgbXVsdGljYXN0IGZsb3dzLiBU aGlzIHNwZWNpZmljYXRpb24gZXhwbGFpbnMgdGhlDQpvdmVyYWxsPGJyPg0KJmd0OyAmbmJzcDsg Jm5ic3A7IHByb3RvY29sIGFwcHJvYWNoLCBkZXNpZ24gZGVjaXNpb25zIG1hZGUgYW5kIHByb3Zp ZGVzDQpleGFtcGxlcy4gJm5ic3A7SXQ8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgc3BlY2lmaWVz IG9iamVjdCwgbWVzc2FnZSAmbmJzcDtmb3JtYXRzIGFuZCBwcm9jZXNzaW5nDQpydWxlcy48YnI+ DQomZ3Q7IDxicj4NCiZndDsgLS0gPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IE1hZ251cyBXZXN0ZXJs dW5kPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IElFVEYgVHJhbnNwb3J0IEFyZWEgRGlyZWN0b3IgJmFt cDsgVFNWV0cgQ2hhaXI8YnI+DQomZ3Q7IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQomZ3Q7IE11bHRpbWVk aWEgVGVjaG5vbG9naWVzLCBFcmljc3NvbiBSZXNlYXJjaCBFQUIvVFZNL008YnI+DQomZ3Q7IC0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS08YnI+DQomZ3Q7IEVyaWNzc29uIEFCICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt8DQpQaG9uZSArNDYgOCA0MDQ4Mjg3PGJy Pg0KJmd0OyBUb3JzaGFtc2dhdGFuIDIzICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgfCBGYXggJm5ic3A7ICs0Ng0KOCA3NTc1NTUwPGJyPg0KJmd0OyBTLTE2NCA4MCBTdG9ja2hv bG0sIFN3ZWRlbiB8IG1haWx0bzogbWFnbnVzLndlc3Rlcmx1bmRAZXJpY3Nzb24uY29tPGJyPg0K Jmd0OyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCjwvdHQ+PC9mb250 Pg0K --=_alternative 0055890785257329_=-- --===============2091230778== 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 --===============2091230778==--