From nsis-bounces@ietf.org Fri Jun 01 01:22: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 1Htzag-00037M-N8; Fri, 01 Jun 2007 01:22:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Htzaf-00037E-6K for nsis@ietf.org; Fri, 01 Jun 2007 01:22:21 -0400 Received: from smtp.mei.co.jp ([133.183.129.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Htzae-0006ph-I6 for nsis@ietf.org; Fri, 01 Jun 2007 01:22:21 -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 l515M8SH018602; Fri, 1 Jun 2007 14:22:08 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx1) with ESMTP id l515M9n12708; Fri, 1 Jun 2007 14:22:09 +0900 (JST) Received: from localhost (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/bluejays) with SMTP id l515M9708243; Fri, 1 Jun 2007 14:22:09 +0900 (JST) Received: from [127.0.0.1] ([10.81.113.75]) by pslexc01.psl.local with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 Jun 2007 13:18:37 +0800 Message-ID: <465FAC29.1070405@sg.panasonic.com> Date: Fri, 01 Jun 2007 13:18:33 +0800 From: Hong Cheng User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Jukka MJ Manner Subject: Re: [NSIS] QoS NSLP Abstract API: feedback wanted References: In-Reply-To: X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Jun 2007 05:18:37.0048 (UTC) FILETIME=[4EB64780:01C7A40C] X-Spam-Score: 0.1 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: NSIS Working Group X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Jukka, I have just browsed through the API definitions. It seems like a good start. However, I have a few comments and questions: - "filter" in both sendrmf() and recvrmf() is defined as "PACKET CLASSIFIER" (defined in 5.1.3.5). But, the current definition for "PACKET CLASSIFIER" only contains several flags. It obviously does not provide the necessary filter information. Shouldn't this parameter also includes the MRI information, or be the real filter (with addr, port, etc)? - "Features_in" in sendrmf() includes a "synchronization_required" trigger. Is this necessary, since all the information, e.g. BOUND_SESSION_ID (and corresponding binding_code) is also passed in sendrmf()? - From the description of the recvrmf() at A.2, it seems that it is always the RMF decide what messages to be sent out. Does the NSLP itself has any state managed or capable of deciding what message to sent? - Related to above, is there a way for the NSLP to influence/regulate what to be returned by the RMF (i.e. what message in the recvrmf() should follow a sendrmf())? From the API, it seem not. Or, this is purely left to RMF to decide? - Suggest to add a qne_type of "CRN" in config(). - Should the qne_type be configured from NSLP to RMF or from RMF to NSLP? At least the QNR, QNE, and CRN discovery should be carried out at NTLP or NSLP layer. If the config() is just one way, would it imply the QNR/CRN discovery is carried out in RMF? And for QNI, QNI_Ingress or QNI_Egress, they probably should be from RMF to NSLP. - What is the use of state_type in the config()? Would the NSLP behavior change because of this parameters? What kind of state if left for NSLP to maintain, as from the recvrmf() definition, it seems all that will be done at RMF, and NSLP is just to assemble/dissemble NSLP messages. cheers Cheng Hong Jukka MJ Manner wrote: > Dear all, > > The last thing before a WGLC is to specify the abstract API for the QoS > NSLP. The current spec has our initial proposal, which after a fresh > re-read looks quite ok to me. Maybe some examples on the usage would help > clarify the operation but in general the API looks quite good. > > What do people feel? Is the abstract and informational API good enough at > this stage to go for WGLC? Or do we want to change it in some way? > > Regards, > Jukka > > _______________________________________________ > 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 Jun 01 03:44: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 1Hu1oP-0008Ji-Ao; Fri, 01 Jun 2007 03:44:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hu1oO-0008I4-5X for nsis@ietf.org; Fri, 01 Jun 2007 03:44:40 -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 1Hu1oM-0002le-JT for nsis@ietf.org; Fri, 01 Jun 2007 03:44:40 -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; Fri, 01 Jun 2007 10:44:37 +0300 id 0009FE44.465FCE65.0000039B Date: Fri, 1 Jun 2007 10:44:37 +0300 (EEST) From: Jukka MJ Manner To: Hong Cheng Subject: Re: [NSIS] QoS NSLP Abstract API: feedback wanted In-Reply-To: <465FAC29.1070405@sg.panasonic.com> Message-ID: References: <465FAC29.1070405@sg.panasonic.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c Cc: NSIS Working Group X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi, thanks for the feedback. Some answers below. On Fri, 1 Jun 2007, Hong Cheng wrote: > Hi Jukka, > > I have just browsed through the API definitions. It seems like a good > start. However, I have a few comments and questions: > > - "filter" in both sendrmf() and recvrmf() is defined as "PACKET > CLASSIFIER" (defined in 5.1.3.5). But, the current definition for > "PACKET CLASSIFIER" only contains several flags. It obviously does not > provide the necessary filter information. Shouldn't this parameter also > includes the MRI information, or be the real filter (with addr, port, etc)? [JM]: Good point, will change to say in general "packet classifier" and not refer to the object itself, which is useless. > > - "Features_in" in sendrmf() includes a "synchronization_required" > trigger. Is this necessary, since all the information, e.g. > BOUND_SESSION_ID (and corresponding binding_code) is also passed in > sendrmf()? [JM]: Maybe you are right, sounds like the same information is passed twice. > > - From the description of the recvrmf() at A.2, it seems that it is > always the RMF decide what messages to be sent out. Does the NSLP itself > has any state managed or capable of deciding what message to sent? [JM]: Well, let's think about it a while. * QUERY is always forwarded when the QNE code gets an answer from the RMF. So, this is RMF triggered. * RESERVE: same thing for initial reservation. Refreshes are hop-by-hop, so again, triggered by the RMF. A tearing RESERVE might be done with a "fast path" where an incoming tear causes a notification to the RMF, and simultaneously a QNE code builds a tear to be sent out. However, this might be an optimzation. I think this could also be done based on a trigger from the RMF saying "state removed successfully". * NOTIFY and RESPONSE: these may be sent without consulting the RMF, if the notification does not involve the RMF. So, all messages that carry a QSPEC would in my mind be forwarded after the RMF has done some magic with the incoming message. And since this may take an unspecified time, an implementation should not try to block and wait for a message from the RMF, but rather be prepared to get asynchronous triggers causing NSLP messages to be sent out. > > - Related to above, is there a way for the NSLP to influence/regulate > what to be returned by the RMF (i.e. what message in the recvrmf() > should follow a sendrmf())? From the API, it seem not. Or, this is > purely left to RMF to decide? [JM]: This depends heavily on the QoS Model. Say we have an RMD-like QOSM, then at ingress and egress we have different operation that elsewhere in the network, or outside the domain. Also, e.g. a RESERVE may cause a RESPONSE to be sent out, or a new RESERVE. I think this should be left to the RMF to decide. [JM]: In general, I tend to view the RMF as a separate node to communicate with. Its like [QI] --- [QNE1]-[RMF]-[QNE1] --- [QNE2]-[RMF]-[QNE2] --- ... When a QNE receives a packet, it usually "sends" it to the RMF, and forgets about it. Later, the RMF "sends" a message back to the QNE, instructing to send a message out. > > - Suggest to add a qne_type of "CRN" in config(). [JM]: Where and how would you use it? The config call is meant for setting static information at startup. > > - Should the qne_type be configured from NSLP to RMF or from RMF to > NSLP? At least the QNR, QNE, and CRN discovery should be carried out at > NTLP or NSLP layer. If the config() is just one way, would it imply the > QNR/CRN discovery is carried out in RMF? And for QNI, QNI_Ingress or > QNI_Egress, they probably should be from RMF to NSLP. [JM]: CRN discovery is carried at the NSLP level based on a trigger by the NTLP. Only the NSLP is able to figure out if the next hop has changed, but needs to hint from the NTLP to start looking at that. Maybe I don't follow your idea...? > > - What is the use of state_type in the config()? Would the NSLP behavior > change because of this parameters? What kind of state if left for NSLP > to maintain, as from the recvrmf() definition, it seems all that will be > done at RMF, and NSLP is just to assemble/dissemble NSLP messages. [JM]: the state is mainly used currently in RMD, but is a generic static functionality of a QNE. BR, Jukka > > cheers > > Cheng Hong > > > > > Jukka MJ Manner wrote: > > Dear all, > > > > The last thing before a WGLC is to specify the abstract API for the QoS > > NSLP. The current spec has our initial proposal, which after a fresh > > re-read looks quite ok to me. Maybe some examples on the usage would help > > clarify the operation but in general the API looks quite good. > > > > What do people feel? Is the abstract and informational API good enough at > > this stage to go for WGLC? Or do we want to change it in some way? > > > > Regards, > > Jukka > > > > _______________________________________________ > > 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 Jun 01 03:54:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hu1xU-0004fn-R0; Fri, 01 Jun 2007 03:54:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hu1xT-0004fi-2b for nsis@ietf.org; Fri, 01 Jun 2007 03:54:03 -0400 Received: from goliath.siemens.de ([192.35.17.28]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hu1xR-0005pv-KJ for nsis@ietf.org; Fri, 01 Jun 2007 03:54:03 -0400 Received: from mail1.siemens.de (localhost [127.0.0.1]) by goliath.siemens.de (8.12.6/8.12.6) with ESMTP id l517rsWP016672; Fri, 1 Jun 2007 09:53:54 +0200 Received: from mchp7wta.ww002.siemens.net (mchp7wta.ww002.siemens.net [139.25.131.193]) by mail1.siemens.de (8.12.6/8.12.6) with ESMTP id l517rqQF004946; Fri, 1 Jun 2007 09:53:53 +0200 Received: from blns00fa.ww002.siemens.net ([147.54.45.102]) by mchp7wta.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 Jun 2007 09:53:53 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: AW: [NSIS] smallest path MTU - Maximum Packet Size [M] Date: Fri, 1 Jun 2007 09:53:50 +0200 Message-ID: In-Reply-To: <465C9BAE.1050505@cs.uni-goettingen.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] smallest path MTU - Maximum Packet Size [M] Thread-Index: AceiOM3OwdCeaEOuS267eWNZJzBL6QB6Qufg References: <465C9BAE.1050505@cs.uni-goettingen.de> From: "Kappler, Cornelia" To: "ext Bernd Schloer" , X-OriginalArrivalTime: 01 Jun 2007 07:53:53.0543 (UTC) FILETIME=[FFC69970:01C7A421] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi all,=20 at the Interim meeting in May 2005 we decided to drop the MTU, see = http://www.ietf-nsis.org/nsis/Munich_Interim_Meeting/MeetingMinutes.html = Cornelia=20 > -----Urspr=FCngliche Nachricht----- > Von: ext Bernd Schloer [mailto:bschloer@cs.uni-goettingen.de]=20 > Gesendet: Dienstag, 29. Mai 2007 23:31 > An: nsis@ietf.org > Betreff: [NSIS] smallest path MTU - Maximum Packet Size [M] >=20 > Hi, >=20 > in version 13 of the QSPEC-draft the Maximum Packet Size [M]=20 > was removed from the > TMOD parameter (former Traffic parameter). >=20 > RFC2211 mentions, that links are not permitted to fragment=20 > packets which receive > the controlled-load service and packets larger than the MTU=20 > of the link are treated > as non-conformant to the TSPEC. >=20 > What was the reason to omit this parameter? >=20 > Best regards, > Bernd >=20 >=20 >=20 >=20 > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Jun 01 04:29:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hu2Vb-0002ns-UJ; Fri, 01 Jun 2007 04:29:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hu2Va-0002ng-76 for nsis@ietf.org; Fri, 01 Jun 2007 04:29:18 -0400 Received: from smtp.mei.co.jp ([133.183.129.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hu2VZ-00072X-Fz for nsis@ietf.org; Fri, 01 Jun 2007 04:29:18 -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 l518TBDN005851; Fri, 1 Jun 2007 17:29:11 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx3) with ESMTP id l518TCA27178; Fri, 1 Jun 2007 17:29:12 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/phillies) with ESMTP id l518TAE14089; Fri, 1 Jun 2007 17:29:10 +0900 (JST) Received: from [127.0.0.1] ([10.81.113.75]) by pslexc01.psl.local with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 Jun 2007 16:27:57 +0800 Message-ID: <465FD874.90302@sg.panasonic.com> Date: Fri, 01 Jun 2007 16:27:32 +0800 From: Hong Cheng User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Jukka MJ Manner Subject: Re: [NSIS] QoS NSLP Abstract API: feedback wanted References: <465FAC29.1070405@sg.panasonic.com> In-Reply-To: X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Jun 2007 08:27:57.0282 (UTC) FILETIME=[C1F06C20:01C7A426] X-Spam-Score: 0.1 (/) X-Scan-Signature: 200d029292fbb60d25b263122ced50fc Cc: NSIS Working Group X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Jukka, Thanks for your answer. Some further comments inline. >> - From the description of the recvrmf() at A.2, it seems that it is >> always the RMF decide what messages to be sent out. Does the NSLP itself >> has any state managed or capable of deciding what message to sent? > > [JM]: Well, let's think about it a while. > * QUERY is always forwarded when the QNE code gets an answer from the RMF. > So, this is RMF triggered. > > * RESERVE: same thing for initial reservation. Refreshes are hop-by-hop, > so again, triggered by the RMF. A tearing RESERVE might be done with a > "fast path" where an incoming tear causes a notification to the RMF, and > simultaneously a QNE code builds a tear to be sent out. However, this > might be an optimzation. I think this could also be done based on a > trigger from the RMF saying "state removed successfully". > > * NOTIFY and RESPONSE: these may be sent without consulting the RMF, if > the notification does not involve the RMF. > > So, all messages that carry a QSPEC would in my mind be forwarded after > the RMF has done some magic with the incoming message. And since this may > take an unspecified time, an implementation should not try to block and > wait for a message from the RMF, but rather be prepared to get > asynchronous triggers causing NSLP messages to be sent out. > >> - Related to above, is there a way for the NSLP to influence/regulate >> what to be returned by the RMF (i.e. what message in the recvrmf() >> should follow a sendrmf())? From the API, it seem not. Or, this is >> purely left to RMF to decide? > > [JM]: This depends heavily on the QoS Model. Say we have an RMD-like QOSM, > then at ingress and egress we have different operation that elsewhere in > the network, or outside the domain. Also, e.g. a RESERVE may cause a > RESPONSE to be sent out, or a new RESERVE. I think this should be left to > the RMF to decide. > > [JM]: In general, I tend to view the RMF as a separate node to communicate > with. Its like > > [QI] --- [QNE1]-[RMF]-[QNE1] --- [QNE2]-[RMF]-[QNE2] --- ... > > When a QNE receives a packet, it usually "sends" it to the RMF, and > forgets about it. Later, the RMF "sends" a message back to the QNE, > instructing to send a message out. If I understand this correctly, it means the NSLP layer would not need to keep any state about the messages received (QNE1 before and after the RMF does not need to related the two messages), and everything is kept in the RMF. This would be OK. What you have described above probably should be included into the draft also (as the suggested example/explanation). >> - Suggest to add a qne_type of "CRN" in config(). > > [JM]: Where and how would you use it? The config call is meant for setting > static information at startup. Sorry. Did not notice that the config() is meant for static info for startup (only saw the text "the config() function is meant for configuring per-session settings"). However, I am still a bit curious about the types like QNR/QNE/QNI. Especially for the QNR, how could it be a static configuration (considering the path extension in 3.2.11.1)? The CRN related issue is discussed below: >> - Should the qne_type be configured from NSLP to RMF or from RMF to >> NSLP? At least the QNR, QNE, and CRN discovery should be carried out at >> NTLP or NSLP layer. If the config() is just one way, would it imply the >> QNR/CRN discovery is carried out in RMF? And for QNI, QNI_Ingress or >> QNI_Egress, they probably should be from RMF to NSLP. > > [JM]: CRN discovery is carried at the NSLP level based on a trigger by the > NTLP. Only the NSLP is able to figure out if the next hop has changed, but > needs to hint from the NTLP to start looking at that. Maybe I don't follow > your idea...? Yes. That is what I thought the CRN discovery operation should be. But, after the NSLP discovered the QNE is a CRN, shouldn't it inform the RMF about it? The current API does not address this information. Or, by saying "NSLP" you are really referring to RMF? I was thinking maybe the config() could be used for that purpose (by making it two-way, i.e. allow the NSLP to call it). But obviously it is not meant for that use. >> - What is the use of state_type in the config()? Would the NSLP behavior >> change because of this parameters? What kind of state if left for NSLP >> to maintain, as from the recvrmf() definition, it seems all that will be >> done at RMF, and NSLP is just to assemble/dissemble NSLP messages. > > [JM]: the state is mainly used currently in RMD, but is a generic > static functionality of a QNE. Meaning the NSLP will form different formats of the NSLP message (maybe different flags set) based on this parameter (given the same recvrmf() contents)? It sounds logical if that is the case. cheers Cheng Hong > > BR, Jukka > >> cheers >> >> Cheng Hong >> >> >> >> >> Jukka MJ Manner wrote: >>> Dear all, >>> >>> The last thing before a WGLC is to specify the abstract API for the QoS >>> NSLP. The current spec has our initial proposal, which after a fresh >>> re-read looks quite ok to me. Maybe some examples on the usage would help >>> clarify the operation but in general the API looks quite good. >>> >>> What do people feel? Is the abstract and informational API good enough at >>> this stage to go for WGLC? Or do we want to change it in some way? >>> >>> Regards, >>> Jukka >>> >>> _______________________________________________ >>> 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 Jun 01 05:05:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hu34w-0001o6-6s; Fri, 01 Jun 2007 05:05:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hu30w-0004LG-An for nsis@ietf.org; Fri, 01 Jun 2007 05:01:42 -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 1Hu30u-0005HB-Mu for nsis@ietf.org; Fri, 01 Jun 2007 05:01:42 -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; Fri, 01 Jun 2007 12:01:39 +0300 id 0009FDE4.465FE073.00002924 Date: Fri, 1 Jun 2007 12:01:38 +0300 (EEST) From: Jukka MJ Manner To: Hong Cheng Subject: Re: [NSIS] QoS NSLP Abstract API: feedback wanted In-Reply-To: <465FD874.90302@sg.panasonic.com> Message-ID: References: <465FAC29.1070405@sg.panasonic.com> <465FD874.90302@sg.panasonic.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 33cc095b503da4365ce57c727e553cf1 Cc: NSIS Working Group X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi, some comments back inline. On Fri, 1 Jun 2007, Hong Cheng wrote: > Hi Jukka, > > Thanks for your answer. Some further comments inline. > > > >> - From the description of the recvrmf() at A.2, it seems that it is > >> always the RMF decide what messages to be sent out. Does the NSLP itself > >> has any state managed or capable of deciding what message to sent? > > > > [JM]: Well, let's think about it a while. > > * QUERY is always forwarded when the QNE code gets an answer from the RMF. > > So, this is RMF triggered. > > > > * RESERVE: same thing for initial reservation. Refreshes are hop-by-hop, > > so again, triggered by the RMF. A tearing RESERVE might be done with a > > "fast path" where an incoming tear causes a notification to the RMF, and > > simultaneously a QNE code builds a tear to be sent out. However, this > > might be an optimzation. I think this could also be done based on a > > trigger from the RMF saying "state removed successfully". > > > > * NOTIFY and RESPONSE: these may be sent without consulting the RMF, if > > the notification does not involve the RMF. > > > > So, all messages that carry a QSPEC would in my mind be forwarded after > > the RMF has done some magic with the incoming message. And since this may > > take an unspecified time, an implementation should not try to block and > > wait for a message from the RMF, but rather be prepared to get > > asynchronous triggers causing NSLP messages to be sent out. > > > >> - Related to above, is there a way for the NSLP to influence/regulate > >> what to be returned by the RMF (i.e. what message in the recvrmf() > >> should follow a sendrmf())? From the API, it seem not. Or, this is > >> purely left to RMF to decide? > > > > [JM]: This depends heavily on the QoS Model. Say we have an RMD-like QOSM, > > then at ingress and egress we have different operation that elsewhere in > > the network, or outside the domain. Also, e.g. a RESERVE may cause a > > RESPONSE to be sent out, or a new RESERVE. I think this should be left to > > the RMF to decide. > > > > [JM]: In general, I tend to view the RMF as a separate node to communicate > > with. Its like > > > > [QI] --- [QNE1]-[RMF]-[QNE1] --- [QNE2]-[RMF]-[QNE2] --- ... > > > > When a QNE receives a packet, it usually "sends" it to the RMF, and > > forgets about it. Later, the RMF "sends" a message back to the QNE, > > instructing to send a message out. > > If I understand this correctly, it means the NSLP layer would not need > to keep any state about the messages received (QNE1 before and after the > RMF does not need to related the two messages), and everything is kept > in the RMF. This would be OK. What you have described above probably > should be included into the draft also (as the suggested > example/explanation). Yes, and no. The NSLP layer must keep some NSLP state related to the session. But the main point is that the messaging with the RMF should be asynchronous, not synchronous. The NSLP stores state info based on the SID, and messages from the RMF should indicate which SID is being triggered for the NSLP to be able to send the correct message on the right direction. > > > > >> - Suggest to add a qne_type of "CRN" in config(). > > > > [JM]: Where and how would you use it? The config call is meant for setting > > static information at startup. > > Sorry. Did not notice that the config() is meant for static info for > startup (only saw the text "the config() function is meant for > configuring per-session settings"). > > However, I am still a bit curious about the types like QNR/QNE/QNI. > Especially for the QNR, how could it be a static configuration > (considering the path extension in 3.2.11.1)? You are right that the type may be a bit vague, and can change between sessions. Still, being a CRN is in mind a different issue. > > The CRN related issue is discussed below: > > >> - Should the qne_type be configured from NSLP to RMF or from RMF to > >> NSLP? At least the QNR, QNE, and CRN discovery should be carried out at > >> NTLP or NSLP layer. If the config() is just one way, would it imply the > >> QNR/CRN discovery is carried out in RMF? And for QNI, QNI_Ingress or > >> QNI_Egress, they probably should be from RMF to NSLP. > > > > [JM]: CRN discovery is carried at the NSLP level based on a trigger by the > > NTLP. Only the NSLP is able to figure out if the next hop has changed, but > > needs to hint from the NTLP to start looking at that. Maybe I don't follow > > your idea...? > > Yes. That is what I thought the CRN discovery operation should be. But, > after the NSLP discovered the QNE is a CRN, shouldn't it inform the RMF > about it? The current API does not address this information. Or, by > saying "NSLP" you are really referring to RMF? > > I was thinking maybe the config() could be used for that purpose (by > making it two-way, i.e. allow the NSLP to call it). But obviously it is > not meant for that use. I don't think the RMF should be bothered by mobility in general. You only tell the RMF whether the interfaces for the session have changed, or whether a new reservation is needed, or an existing torn down. The RMF just sees those triggers from the NSLP code, and the reason doesn't need to be propagated, I think. > > >> - What is the use of state_type in the config()? Would the NSLP behavior > >> change because of this parameters? What kind of state if left for NSLP > >> to maintain, as from the recvrmf() definition, it seems all that will be > >> done at RMF, and NSLP is just to assemble/dissemble NSLP messages. > > > > [JM]: the state is mainly used currently in RMD, but is a generic > > static functionality of a QNE. > > Meaning the NSLP will form different formats of the NSLP message (maybe > different flags set) based on this parameter (given the same recvrmf() > contents)? It sounds logical if that is the case. Yes, see Section 4.6 where aggregation is discussed. The stateless QNE is one specific type of QNE inside a certain domain, e.g., an RMD domain. Jukka > > > cheers > > Cheng Hong > > > > > > > BR, Jukka > > > >> cheers > >> > >> Cheng Hong > >> > >> > >> > >> > >> Jukka MJ Manner wrote: > >>> Dear all, > >>> > >>> The last thing before a WGLC is to specify the abstract API for the QoS > >>> NSLP. The current spec has our initial proposal, which after a fresh > >>> re-read looks quite ok to me. Maybe some examples on the usage would help > >>> clarify the operation but in general the API looks quite good. > >>> > >>> What do people feel? Is the abstract and informational API good enough at > >>> this stage to go for WGLC? Or do we want to change it in some way? > >>> > >>> Regards, > >>> Jukka > >>> > >>> _______________________________________________ > >>> 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 Jun 01 05:42:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hu3eB-0001Pw-Ty; Fri, 01 Jun 2007 05:42:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hu3eA-0001OS-Ed for nsis@ietf.org; Fri, 01 Jun 2007 05:42:14 -0400 Received: from smtp.mei.co.jp ([133.183.129.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hu3e8-00048o-Rv for nsis@ietf.org; Fri, 01 Jun 2007 05:42:14 -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 l519g6A6028429; Fri, 1 Jun 2007 18:42:06 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx2) with ESMTP id l519g8s18043; Fri, 1 Jun 2007 18:42:08 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/astros) with ESMTP id l519g7001856; Fri, 1 Jun 2007 18:42:07 +0900 (JST) Received: from [127.0.0.1] ([10.81.113.75]) by pslexc01.psl.local with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 Jun 2007 17:40:54 +0800 Message-ID: <465FE985.7080006@sg.panasonic.com> Date: Fri, 01 Jun 2007 17:40:21 +0800 From: Hong Cheng User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Jukka MJ Manner Subject: Re: [NSIS] QoS NSLP Abstract API: feedback wanted References: <465FAC29.1070405@sg.panasonic.com> <465FD874.90302@sg.panasonic.com> In-Reply-To: X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Jun 2007 09:40:54.0064 (UTC) FILETIME=[F2B45B00:01C7A430] X-Spam-Score: 0.1 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: NSIS Working Group X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Jukka, Please see below one issue. Other than that, I don't have further questions :) >>>> - Should the qne_type be configured from NSLP to RMF or from RMF to >>>> NSLP? At least the QNR, QNE, and CRN discovery should be carried out at >>>> NTLP or NSLP layer. If the config() is just one way, would it imply the >>>> QNR/CRN discovery is carried out in RMF? And for QNI, QNI_Ingress or >>>> QNI_Egress, they probably should be from RMF to NSLP. >>> [JM]: CRN discovery is carried at the NSLP level based on a trigger by the >>> NTLP. Only the NSLP is able to figure out if the next hop has changed, but >>> needs to hint from the NTLP to start looking at that. Maybe I don't follow >>> your idea...? >> Yes. That is what I thought the CRN discovery operation should be. But, >> after the NSLP discovered the QNE is a CRN, shouldn't it inform the RMF >> about it? The current API does not address this information. Or, by >> saying "NSLP" you are really referring to RMF? >> >> I was thinking maybe the config() could be used for that purpose (by >> making it two-way, i.e. allow the NSLP to call it). But obviously it is >> not meant for that use. > > I don't think the RMF should be bothered by mobility in general. You only > tell the RMF whether the interfaces for the session have changed, or > whether a new reservation is needed, or an existing torn down. The RMF > just sees those triggers from the NSLP code, and the reason doesn't need > to be propagated, I think. > This might as well work. However, it would mean that the NSLP would generate some messages by itself (instead of triggered by RMF). For example, when receiving a new RESERVE message with the REPLACE flag, a normal QNE and a CRN should behave differently. (The CRN should generate another message to be sent to the old path). So, if RMF is not aware of the difference, the NSLP at the CRN should be the one that generates the extra messages towards the old path. This might be a bit inconsistent in the operation description(though it is not a bit problem for implementation). cheers Cheng Hong _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Jun 01 05:54: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 1Hu3qA-0004eQ-Fo; Fri, 01 Jun 2007 05:54:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hu3q8-0004du-KH for nsis@ietf.org; Fri, 01 Jun 2007 05:54:36 -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 1Hu3q8-0007C5-76 for nsis@ietf.org; Fri, 01 Jun 2007 05:54:36 -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; Fri, 01 Jun 2007 12:54:35 +0300 id 000A0270.465FECDB.00001288 Date: Fri, 1 Jun 2007 12:54:34 +0300 (EEST) From: Jukka MJ Manner To: Hong Cheng Subject: Re: [NSIS] QoS NSLP Abstract API: feedback wanted In-Reply-To: <465FE985.7080006@sg.panasonic.com> Message-ID: References: <465FAC29.1070405@sg.panasonic.com> <465FD874.90302@sg.panasonic.com> <465FE985.7080006@sg.panasonic.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: NSIS Working Group X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi, A valid point. I haven't figured out all the usage examples of the API, in various complex cases. It might well be that there are cases, where the API is not enough. I would propose that I make the small modifications we talked today, and we go with that version into the WGLC. Jukka On Fri, 1 Jun 2007, Hong Cheng wrote: > Hi Jukka, > > Please see below one issue. Other than that, I don't have further > questions :) > > >>>> - Should the qne_type be configured from NSLP to RMF or from RMF to > >>>> NSLP? At least the QNR, QNE, and CRN discovery should be carried out at > >>>> NTLP or NSLP layer. If the config() is just one way, would it imply the > >>>> QNR/CRN discovery is carried out in RMF? And for QNI, QNI_Ingress or > >>>> QNI_Egress, they probably should be from RMF to NSLP. > >>> [JM]: CRN discovery is carried at the NSLP level based on a trigger by the > >>> NTLP. Only the NSLP is able to figure out if the next hop has changed, but > >>> needs to hint from the NTLP to start looking at that. Maybe I don't follow > >>> your idea...? > >> Yes. That is what I thought the CRN discovery operation should be. But, > >> after the NSLP discovered the QNE is a CRN, shouldn't it inform the RMF > >> about it? The current API does not address this information. Or, by > >> saying "NSLP" you are really referring to RMF? > >> > >> I was thinking maybe the config() could be used for that purpose (by > >> making it two-way, i.e. allow the NSLP to call it). But obviously it is > >> not meant for that use. > > > > I don't think the RMF should be bothered by mobility in general. You only > > tell the RMF whether the interfaces for the session have changed, or > > whether a new reservation is needed, or an existing torn down. The RMF > > just sees those triggers from the NSLP code, and the reason doesn't need > > to be propagated, I think. > > > > This might as well work. However, it would mean that the NSLP would > generate some messages by itself (instead of triggered by RMF). > > For example, when receiving a new RESERVE message with the REPLACE flag, > a normal QNE and a CRN should behave differently. (The CRN should > generate another message to be sent to the old path). So, if RMF is not > aware of the difference, the NSLP at the CRN should be the one that > generates the extra messages towards the old path. > > This might be a bit inconsistent in the operation description(though it > is not a bit problem for implementation). > > cheers > > Cheng Hong > > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Jun 01 06:22:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hu4Gj-0001ZJ-Ab; Fri, 01 Jun 2007 06:22:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hu4Gi-0001YE-8y for nsis@ietf.org; Fri, 01 Jun 2007 06:22:04 -0400 Received: from smtp.mei.co.jp ([133.183.129.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hu4Gh-0005vY-L5 for nsis@ietf.org; Fri, 01 Jun 2007 06:22:04 -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 l51ALva8012569; Fri, 1 Jun 2007 19:21:57 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx3) with ESMTP id l51ALwA29731; Fri, 1 Jun 2007 19:21:58 +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 l51ALt318460; Fri, 1 Jun 2007 19:21:55 +0900 (JST) Received: from [127.0.0.1] ([10.81.113.75]) by pslexc01.psl.local with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 Jun 2007 18:20:42 +0800 Message-ID: <465FF311.5000804@sg.panasonic.com> Date: Fri, 01 Jun 2007 18:21:05 +0800 From: Hong Cheng User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Jukka MJ Manner Subject: Re: [NSIS] QoS NSLP Abstract API: feedback wanted References: <465FAC29.1070405@sg.panasonic.com> <465FD874.90302@sg.panasonic.com> <465FE985.7080006@sg.panasonic.com> In-Reply-To: X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Jun 2007 10:20:42.0892 (UTC) FILETIME=[828E94C0:01C7A436] X-Spam-Score: 0.1 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: NSIS Working Group X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi, I am OK with that. Let's see what others have to say about it. cheers Cheng Hong Jukka MJ Manner wrote: > Hi, > A valid point. I haven't figured out all the usage examples of the API, in > various complex cases. It might well be that there are cases, where the > API is not enough. > > I would propose that I make the small modifications we talked today, and > we go with that version into the WGLC. > > Jukka > > On Fri, 1 Jun 2007, Hong Cheng wrote: > >> Hi Jukka, >> >> Please see below one issue. Other than that, I don't have further >> questions :) >> >>>>>> - Should the qne_type be configured from NSLP to RMF or from RMF to >>>>>> NSLP? At least the QNR, QNE, and CRN discovery should be carried out at >>>>>> NTLP or NSLP layer. If the config() is just one way, would it imply the >>>>>> QNR/CRN discovery is carried out in RMF? And for QNI, QNI_Ingress or >>>>>> QNI_Egress, they probably should be from RMF to NSLP. >>>>> [JM]: CRN discovery is carried at the NSLP level based on a trigger by the >>>>> NTLP. Only the NSLP is able to figure out if the next hop has changed, but >>>>> needs to hint from the NTLP to start looking at that. Maybe I don't follow >>>>> your idea...? >>>> Yes. That is what I thought the CRN discovery operation should be. But, >>>> after the NSLP discovered the QNE is a CRN, shouldn't it inform the RMF >>>> about it? The current API does not address this information. Or, by >>>> saying "NSLP" you are really referring to RMF? >>>> >>>> I was thinking maybe the config() could be used for that purpose (by >>>> making it two-way, i.e. allow the NSLP to call it). But obviously it is >>>> not meant for that use. >>> I don't think the RMF should be bothered by mobility in general. You only >>> tell the RMF whether the interfaces for the session have changed, or >>> whether a new reservation is needed, or an existing torn down. The RMF >>> just sees those triggers from the NSLP code, and the reason doesn't need >>> to be propagated, I think. >>> >> This might as well work. However, it would mean that the NSLP would >> generate some messages by itself (instead of triggered by RMF). >> >> For example, when receiving a new RESERVE message with the REPLACE flag, >> a normal QNE and a CRN should behave differently. (The CRN should >> generate another message to be sent to the old path). So, if RMF is not >> aware of the difference, the NSLP at the CRN should be the one that >> generates the extra messages towards the old path. >> >> This might be a bit inconsistent in the operation description(though it >> is not a bit problem for implementation). >> >> cheers >> >> Cheng Hong >> >> >> > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Jun 01 08:04: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 1Hu5s5-0002N8-Is; Fri, 01 Jun 2007 08:04:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hu5s4-0002N0-Bt for nsis@ietf.org; Fri, 01 Jun 2007 08:04:44 -0400 Received: from david.siemens.de ([192.35.17.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hu5s1-0001tf-Rn for nsis@ietf.org; Fri, 01 Jun 2007 08:04:44 -0400 Received: from mail2.siemens.de (localhost [127.0.0.1]) by david.siemens.de (8.12.6/8.12.6) with ESMTP id l51C4eHx013424; Fri, 1 Jun 2007 14:04:40 +0200 Received: from mchp7wta.ww002.siemens.net (mchp7wta.ww002.siemens.net [139.25.131.193]) by mail2.siemens.de (8.12.6/8.12.6) with ESMTP id l51C4dag010844; Fri, 1 Jun 2007 14:04:40 +0200 Received: from blns00fa.ww002.siemens.net ([147.54.45.102]) by mchp7wta.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 Jun 2007 14:04:39 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: AW: [NSIS] QoS NSLP Abstract API: feedback wanted Date: Fri, 1 Jun 2007 14:04:37 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] QoS NSLP Abstract API: feedback wanted Thread-Index: AcejuyfALFHnaPOdT0yGOnidbSTTrQAibkZA References: From: "Kappler, Cornelia" To: "ext Jukka MJ Manner" , "NSIS Working Group" X-OriginalArrivalTime: 01 Jun 2007 12:04:39.0887 (UTC) FILETIME=[08187DF0:01C7A445] X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 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 Dear all,=20 from the minutes of the IETF in Prague I assumed the API would be split = into a RMF API and an application API. Isnt this still planned? Cornelia=20 > -----Urspr=FCngliche Nachricht----- > Von: ext Jukka MJ Manner [mailto:jmanner@cs.Helsinki.FI]=20 > Gesendet: Donnerstag, 31. Mai 2007 21:37 > An: NSIS Working Group > Betreff: [NSIS] QoS NSLP Abstract API: feedback wanted >=20 >=20 > Dear all, >=20 > The last thing before a WGLC is to specify the abstract API=20 > for the QoS=20 > NSLP. The current spec has our initial proposal, which after a fresh=20 > re-read looks quite ok to me. Maybe some examples on the=20 > usage would help=20 > clarify the operation but in general the API looks quite good. >=20 > What do people feel? Is the abstract and informational API=20 > good enough at=20 > this stage to go for WGLC? Or do we want to change it in some way? >=20 > Regards, > Jukka >=20 > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Jun 01 08:45: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 1Hu6V9-0004cP-Q0; Fri, 01 Jun 2007 08:45:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hu6V8-0004cE-Hl for nsis@ietf.org; Fri, 01 Jun 2007 08:45:06 -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 1Hu6V5-00033y-Tz for nsis@ietf.org; Fri, 01 Jun 2007 08:45:06 -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; Fri, 01 Jun 2007 15:45:02 +0300 id 0009FF43.466014CE.00001728 Date: Fri, 1 Jun 2007 15:45:02 +0300 (EEST) From: Jukka MJ Manner To: "Kappler, Cornelia" Subject: Re: AW: [NSIS] QoS NSLP Abstract API: feedback wanted In-Reply-To: Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=_courier-5932-1180701903-0001-2" X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: NSIS Working Group X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_courier-5932-1180701903-0001-2 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Mime-Autoconverted: from 8bit to quoted-printable by courier 0.53.3 Hi, I don't know of any application API. The main point was to try to split the work into a simple and advanced RMF APIs, but looking at the current spec, it doesn't need to be split. Jukka On Fri, 1 Jun 2007, Kappler, Cornelia wrote: > Dear all, > > from the minutes of the IETF in Prague I assumed the API would be split= into a RMF API and an application API. Isnt this still planned? > > Cornelia > > > -----Urspr=FCngliche Nachricht----- > > Von: ext Jukka MJ Manner [mailto:jmanner@cs.Helsinki.FI] > > Gesendet: Donnerstag, 31. Mai 2007 21:37 > > An: NSIS Working Group > > Betreff: [NSIS] QoS NSLP Abstract API: feedback wanted > > > > > > Dear all, > > > > The last thing before a WGLC is to specify the abstract API > > for the QoS > > NSLP. The current spec has our initial proposal, which after a fresh > > re-read looks quite ok to me. Maybe some examples on the > > usage would help > > clarify the operation but in general the API looks quite good. > > > > What do people feel? Is the abstract and informational API > > good enough at > > this stage to go for WGLC? Or do we want to change it in some way? > > > > Regards, > > Jukka > > > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > > > --=_courier-5932-1180701903-0001-2 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 --=_courier-5932-1180701903-0001-2-- From nsis-bounces@ietf.org Mon Jun 04 14:00:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvGqw-0008A6-5v; Mon, 04 Jun 2007 14:00:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvGqu-0007vs-Ck for nsis@ietf.org; Mon, 04 Jun 2007 14:00:24 -0400 Received: from mailer.gwdg.de ([134.76.10.26]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvGqs-0002gT-Me for nsis@ietf.org; Mon, 04 Jun 2007 14:00:24 -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 1HvGqn-0004s4-2I; Mon, 04 Jun 2007 20:00:17 +0200 Received: from [192.168.0.21] (p54849348.dip0.t-ipconnect.de [84.132.147.72]) by smtp.stud.informatik.uni-goettingen.de (Postfix) with ESMTP; Mon, 4 Jun 2007 20:00:16 +0200 (CEST) Message-ID: <46645321.7040202@cs.uni-goettingen.de> Date: Mon, 04 Jun 2007 20:00:01 +0200 From: Bernd Schloer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050920 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jukka MJ Manner Subject: Re: AW: [NSIS] QoS NSLP Abstract API: feedback wanted References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-Spam-Level: - X-Virus-Scanned: (clean) by exiscan+sophie X-Spam-Score: 0.0 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Cc: "Kappler, Cornelia" , NSIS Working Group X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi, I have a proposal for an API between the QoS NSLP and the local applicati= on: 1. From local application to QoS NSLP: reserve_qos(tmod, dst-addr, [dst-port], [dst-prefix], [src-addr], [src-port], [src-prefix], [reservation-style], [authorization info]) -> SessionID The local application initiates a reservation by using the reserve= _qos() command. It includes a traffic description represented by a TMOD p= arameter and the destination address. Optional parameters are destination port, destination prefix, sour= ce address, source port, source prefix, a boolean whether sender or receiver i= nitiated reservation will be used and authorization info. If source and/or destination prefix are omitted default values wil= l be used. The default reservation style is sender initiated reservation. If the source address is omitted the IP address from the outgoing = interface is taken. This parameter is needed on a host with multiple interfa= ces. The QoS NSLP returns immediately the generated SessionID. teardown_qos(SessionID) This call removes the reservation state. The parameter is the Sess= ionID. 2. From QoS NSLP to local application: recv_qos(SessionID, status) The QoS NSLP provides status information to the client using the c= ommand recv_qos(). The status information is taken from the InfoSpec obje= ct and informs the local application about the success of the requested r= eservation or teardown. What do you think of it? Best regards, Bernd Jukka MJ Manner wrote: > Hi, >=20 > I don't know of any application API. The main point was to try to split= =20 > the work into a simple and advanced RMF APIs, but looking at the curren= t=20 > spec, it doesn't need to be split. >=20 > Jukka >=20 > On Fri, 1 Jun 2007, Kappler, Cornelia wrote: >=20 >=20 >>Dear all,=20 >> >>from the minutes of the IETF in Prague I assumed the API would be split= into a RMF API and an application API. Isnt this still planned? >> >>Cornelia=20 >> >> >>>-----Urspr=FCngliche Nachricht----- >>>Von: ext Jukka MJ Manner [mailto:jmanner@cs.Helsinki.FI]=20 >>>Gesendet: Donnerstag, 31. Mai 2007 21:37 >>>An: NSIS Working Group >>>Betreff: [NSIS] QoS NSLP Abstract API: feedback wanted >>> >>> >>>Dear all, >>> >>>The last thing before a WGLC is to specify the abstract API=20 >>>for the QoS=20 >>>NSLP. The current spec has our initial proposal, which after a fresh=20 >>>re-read looks quite ok to me. Maybe some examples on the=20 >>>usage would help=20 >>>clarify the operation but in general the API looks quite good. >>> >>>What do people feel? Is the abstract and informational API=20 >>>good enough at=20 >>>this stage to go for WGLC? Or do we want to change it in some way? >>> >>>Regards, >>>Jukka >>> >>>_______________________________________________ >>>nsis mailing list >>>nsis@ietf.org >>>https://www1.ietf.org/mailman/listinfo/nsis >>> >> >> >>-----------------------------------------------------------------------= - >> >>_______________________________________________ >>nsis mailing list >>nsis@ietf.org >>https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Jun 05 05:20: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 1HvVDZ-00059E-Nh; Tue, 05 Jun 2007 05:20:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvVDY-000596-8n for nsis@ietf.org; Tue, 05 Jun 2007 05:20:44 -0400 Received: from smtp.mei.co.jp ([133.183.129.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvVDW-0007Kt-Jq for nsis@ietf.org; Tue, 05 Jun 2007 05:20:44 -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 l559KLCK023500; Tue, 5 Jun 2007 18:20:21 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx1) with ESMTP id l559KOZ21460; Tue, 5 Jun 2007 18:20:24 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/redsox) with ESMTP id l559KNF12470; Tue, 5 Jun 2007 18:20:23 +0900 (JST) Received: from [127.0.0.1] ([10.81.113.75]) by pslexc01.psl.local with Microsoft SMTPSVC(6.0.3790.1830); Tue, 5 Jun 2007 17:19:06 +0800 Message-ID: <46652A8B.3060203@sg.panasonic.com> Date: Tue, 05 Jun 2007 17:19:07 +0800 From: Hong Cheng User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Bernd Schloer Subject: Re: AW: [NSIS] QoS NSLP Abstract API: feedback wanted References: <46645321.7040202@cs.uni-goettingen.de> In-Reply-To: <46645321.7040202@cs.uni-goettingen.de> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 X-OriginalArrivalTime: 05 Jun 2007 09:19:06.0767 (UTC) FILETIME=[9125A9F0:01C7A752] Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by smtp.mei.co.jp id l559KLCK023500 X-Spam-Score: 0.1 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c Cc: "Kappler, Cornelia" , Jukka MJ Manner , NSIS Working Group X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Bernd, Based on the Figure 2 of the QoS NSLP draft, the Local Application is interfacing with the Resource Management instead of the QoS NSLP block. So, is this API proposed for that interface? cheers Cheng Hong Bernd Schloer wrote: > Hi, >=20 > I have a proposal for an API between the QoS NSLP and the local > application: >=20 > 1. From local application to QoS NSLP: >=20 > reserve_qos(tmod, dst-addr, [dst-port], [dst-prefix], [src-addr], > [src-port], [src-prefix], [reservation-style], > [authorization info]) -> SessionID >=20 > The local application initiates a reservation by using the > reserve_qos() > command. It includes a traffic description represented by a TMOD > parameter > and the destination address. >=20 > Optional parameters are destination port, destination prefix, > source address, > source port, source prefix, a boolean whether sender or receiver > initiated > reservation will be used and authorization info. >=20 > If source and/or destination prefix are omitted default values > will be used. > The default reservation style is sender initiated reservation. >=20 > If the source address is omitted the IP address from the outgoing > interface > is taken. This parameter is needed on a host with multiple > interfaces. >=20 > The QoS NSLP returns immediately the generated SessionID. >=20 >=20 > teardown_qos(SessionID) >=20 > This call removes the reservation state. The parameter is the > SessionID. >=20 >=20 > 2. From QoS NSLP to local application: >=20 > recv_qos(SessionID, status) >=20 > The QoS NSLP provides status information to the client using the > command > recv_qos(). The status information is taken from the InfoSpec > object and > informs the local application about the success of the requested > reservation > or teardown. >=20 >=20 > What do you think of it? >=20 > Best regards, > Bernd >=20 >=20 > Jukka MJ Manner wrote: >> Hi, >> >> I don't know of any application API. The main point was to try to >> split the work into a simple and advanced RMF APIs, but looking at the >> current spec, it doesn't need to be split. >> >> Jukka >> >> On Fri, 1 Jun 2007, Kappler, Cornelia wrote: >> >> >>> Dear all, >>> from the minutes of the IETF in Prague I assumed the API would be >>> split into a RMF API and an application API. Isnt this still planned? >>> >>> Cornelia >>> >>>> -----Urspr=FCngliche Nachricht----- >>>> Von: ext Jukka MJ Manner [mailto:jmanner@cs.Helsinki.FI] Gesendet: >>>> Donnerstag, 31. Mai 2007 21:37 >>>> An: NSIS Working Group >>>> Betreff: [NSIS] QoS NSLP Abstract API: feedback wanted >>>> >>>> >>>> Dear all, >>>> >>>> The last thing before a WGLC is to specify the abstract API for the >>>> QoS NSLP. The current spec has our initial proposal, which after a >>>> fresh re-read looks quite ok to me. Maybe some examples on the usage >>>> would help clarify the operation but in general the API looks quite >>>> good. >>>> >>>> What do people feel? Is the abstract and informational API good >>>> enough at this stage to go for WGLC? Or do we want to change it in >>>> some way? >>>> >>>> Regards, >>>> Jukka >>>> >>>> _______________________________________________ >>>> 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 >=20 >=20 > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis >=20 >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Jun 05 05:37: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 1HvVTP-0000EB-Ph; Tue, 05 Jun 2007 05:37:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvVTO-0000E3-Rn for nsis@ietf.org; Tue, 05 Jun 2007 05:37:06 -0400 Received: from rotterdam.ewi.utwente.nl ([130.89.10.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvVTO-00013l-Bs for nsis@ietf.org; Tue, 05 Jun 2007 05:37:06 -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 l559aux2022669; Tue, 5 Jun 2007 11:37:00 +0200 (MEST) From: "Georgios Karagiannis" To: "'Hong Cheng'" , "'Bernd Schloer'" References: <46645321.7040202@cs.uni-goettingen.de> <46652A8B.3060203@sg.panasonic.com> Subject: RE: AW: [NSIS] QoS NSLP Abstract API: feedback wanted Date: Tue, 5 Jun 2007 11:36:51 +0200 Message-ID: <001701c7a755$0e9f7b20$4c0d5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcenUux722iydBitRuixYiSaEkteLgAARzDw In-Reply-To: <46652A8B.3060203@sg.panasonic.com> 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]); Tue, 05 Jun 2007 11:37:01 +0200 (MEST) X-Spam-Score: 0.0 (/) X-Scan-Signature: 88b11fc64c1bfdb4425294ef5374ca07 Cc: "'Kappler, Cornelia'" , 'Jukka MJ Manner' , 'NSIS Working Group' X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Bernd I think that your proposal is already covered by the current API! Is it really needed to split the API in: API for RMF <---> QoS-NSLP And API for Application <------> QoS-NSLP Or is it enough to just change the name of the current=20 version of the API as follows: From: Appendix A. Abstract NSLP-RMF API Into: Appendix A. Abstract NSLP-RMF/Application API And also change: From: A.1 Triggers from QOS-NSLP towards RMF=20 INTO: A.1 Triggers from QOS-NSLP towards RMF/Application And also change: From: A.2 Triggers from RMF/QOSM towards QOS-NSLP INTO: A.2 Triggers from RMF/application towards QOS-NSLP Best regards, Georgios > -----Original Message----- > From: Hong Cheng [mailto:hong.cheng@sg.panasonic.com]=20 > Sent: dinsdag 5 juni 2007 11:19 > To: Bernd Schloer > Cc: Kappler, Cornelia; Jukka MJ Manner; NSIS Working Group > Subject: Re: AW: [NSIS] QoS NSLP Abstract API: feedback wanted >=20 > Hi Bernd, >=20 > Based on the Figure 2 of the QoS NSLP draft, the Local=20 > Application is interfacing with the Resource Management=20 > instead of the QoS NSLP block. > So, is this API proposed for that interface? >=20 > cheers >=20 > Cheng Hong >=20 >=20 >=20 > Bernd Schloer wrote: > > Hi, > >=20 > > I have a proposal for an API between the QoS NSLP and the local > > application: > >=20 > > 1. From local application to QoS NSLP: > >=20 > > reserve_qos(tmod, dst-addr, [dst-port], [dst-prefix], [src-addr], > > [src-port], [src-prefix], [reservation-style], > > [authorization info]) -> SessionID > >=20 > > The local application initiates a reservation by using the > > reserve_qos() > > command. It includes a traffic description=20 > represented by a TMOD=20 > > parameter > > and the destination address. > >=20 > > Optional parameters are destination port, destination prefix,=20 > > source address, > > source port, source prefix, a boolean whether sender=20 > or receiver=20 > > initiated > > reservation will be used and authorization info. > >=20 > > If source and/or destination prefix are omitted=20 > default values=20 > > will be used. > > The default reservation style is sender initiated reservation. > >=20 > > If the source address is omitted the IP address from the=20 > > outgoing interface > > is taken. This parameter is needed on a host with multiple=20 > > interfaces. > >=20 > > The QoS NSLP returns immediately the generated SessionID. > >=20 > >=20 > > teardown_qos(SessionID) > >=20 > > This call removes the reservation state. The parameter is the=20 > > SessionID. > >=20 > >=20 > > 2. From QoS NSLP to local application: > >=20 > > recv_qos(SessionID, status) > >=20 > > The QoS NSLP provides status information to the=20 > client using the=20 > > command > > recv_qos(). The status information is taken from the InfoSpec=20 > > object and > > informs the local application about the success of=20 > the requested=20 > > reservation > > or teardown. > >=20 > >=20 > > What do you think of it? > >=20 > > Best regards, > > Bernd > >=20 > >=20 > > Jukka MJ Manner wrote: > >> Hi, > >> > >> I don't know of any application API. The main point was to try to=20 > >> split the work into a simple and advanced RMF APIs, but looking at=20 > >> the current spec, it doesn't need to be split. > >> > >> Jukka > >> > >> On Fri, 1 Jun 2007, Kappler, Cornelia wrote: > >> > >> > >>> Dear all, > >>> from the minutes of the IETF in Prague I assumed the API would be=20 > >>> split into a RMF API and an application API. Isnt this=20 > still planned? > >>> > >>> Cornelia > >>> > >>>> -----Urspr=FCngliche Nachricht----- > >>>> Von: ext Jukka MJ Manner [mailto:jmanner@cs.Helsinki.FI]=20 > Gesendet: > >>>> Donnerstag, 31. Mai 2007 21:37 > >>>> An: NSIS Working Group > >>>> Betreff: [NSIS] QoS NSLP Abstract API: feedback wanted > >>>> > >>>> > >>>> Dear all, > >>>> > >>>> The last thing before a WGLC is to specify the abstract=20 > API for the=20 > >>>> QoS NSLP. The current spec has our initial proposal,=20 > which after a=20 > >>>> fresh re-read looks quite ok to me. Maybe some examples on the=20 > >>>> usage would help clarify the operation but in general=20 > the API looks=20 > >>>> quite good. > >>>> > >>>> What do people feel? Is the abstract and informational API good=20 > >>>> enough at this stage to go for WGLC? Or do we want to=20 > change it in=20 > >>>> some way? > >>>> > >>>> Regards, > >>>> Jukka > >>>> > >>>> _______________________________________________ > >>>> 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 > >=20 > >=20 > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > >=20 > >=20 >=20 >=20 > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Jun 05 12:54:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvcIr-0003ES-97; Tue, 05 Jun 2007 12:54:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvcIq-0003EN-D2 for nsis@ietf.org; Tue, 05 Jun 2007 12:54:40 -0400 Received: from mailer.gwdg.de ([134.76.10.26]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvcIp-0007yo-Sj for nsis@ietf.org; Tue, 05 Jun 2007 12:54:40 -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 1HvcIh-0002Me-6v; Tue, 05 Jun 2007 18:54:31 +0200 Received: from [192.168.0.21] (p5484A981.dip0.t-ipconnect.de [84.132.169.129]) by smtp.stud.informatik.uni-goettingen.de (Postfix) with ESMTP; Tue, 5 Jun 2007 18:54:30 +0200 (CEST) Message-ID: <46659538.6090105@cs.uni-goettingen.de> Date: Tue, 05 Jun 2007 18:54:16 +0200 From: Bernd Schloer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050920 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Hong Cheng Subject: Re: AW: [NSIS] QoS NSLP Abstract API: feedback wanted References: <46645321.7040202@cs.uni-goettingen.de> <46652A8B.3060203@sg.panasonic.com> In-Reply-To: <46652A8B.3060203@sg.panasonic.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-Spam-Level: - X-Virus-Scanned: (clean) by exiscan+sophie X-Spam-Score: 0.0 (/) X-Scan-Signature: 3971661e40967acfc35f708dd5f33760 Cc: "Kappler, Cornelia" , Jukka MJ Manner , NSIS Working Group X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi, yes, this API is proposed for the Resource Management. Best regards, Bernd Hong Cheng wrote: > Hi Bernd, >=20 > Based on the Figure 2 of the QoS NSLP draft, the Local Application is > interfacing with the Resource Management instead of the QoS NSLP block.= > So, is this API proposed for that interface? >=20 > cheers >=20 > Cheng Hong >=20 >=20 >=20 > Bernd Schloer wrote: >=20 >>Hi, >> >>I have a proposal for an API between the QoS NSLP and the local >>application: >> >>1. From local application to QoS NSLP: >> >> reserve_qos(tmod, dst-addr, [dst-port], [dst-prefix], [src-addr], >> [src-port], [src-prefix], [reservation-style], >> [authorization info]) -> SessionID >> >> The local application initiates a reservation by using the >>reserve_qos() >> command. It includes a traffic description represented by a TMOD >>parameter >> and the destination address. >> >> Optional parameters are destination port, destination prefix, >>source address, >> source port, source prefix, a boolean whether sender or receiver >>initiated >> reservation will be used and authorization info. >> >> If source and/or destination prefix are omitted default values >>will be used. >> The default reservation style is sender initiated reservation. >> >> If the source address is omitted the IP address from the outgoing= >>interface >> is taken. This parameter is needed on a host with multiple >>interfaces. >> >> The QoS NSLP returns immediately the generated SessionID. >> >> >> teardown_qos(SessionID) >> >> This call removes the reservation state. The parameter is the >>SessionID. >> >> >>2. From QoS NSLP to local application: >> >> recv_qos(SessionID, status) >> >> The QoS NSLP provides status information to the client using the >>command >> recv_qos(). The status information is taken from the InfoSpec >>object and >> informs the local application about the success of the requested >>reservation >> or teardown. >> >> >>What do you think of it? >> >>Best regards, >>Bernd >> >> >>Jukka MJ Manner wrote: >> >>>Hi, >>> >>>I don't know of any application API. The main point was to try to >>>split the work into a simple and advanced RMF APIs, but looking at the= >>>current spec, it doesn't need to be split. >>> >>>Jukka >>> >>>On Fri, 1 Jun 2007, Kappler, Cornelia wrote: >>> >>> >>> >>>>Dear all, >>>>from the minutes of the IETF in Prague I assumed the API would be >>>>split into a RMF API and an application API. Isnt this still planned?= >>>> >>>>Cornelia >>>> >>>> >>>>>-----Urspr=FCngliche Nachricht----- >>>>>Von: ext Jukka MJ Manner [mailto:jmanner@cs.Helsinki.FI] Gesendet: >>>>>Donnerstag, 31. Mai 2007 21:37 >>>>>An: NSIS Working Group >>>>>Betreff: [NSIS] QoS NSLP Abstract API: feedback wanted >>>>> >>>>> >>>>>Dear all, >>>>> >>>>>The last thing before a WGLC is to specify the abstract API for the >>>>>QoS NSLP. The current spec has our initial proposal, which after a >>>>>fresh re-read looks quite ok to me. Maybe some examples on the usage= >>>>>would help clarify the operation but in general the API looks quite >>>>>good. >>>>> >>>>>What do people feel? Is the abstract and informational API good >>>>>enough at this stage to go for WGLC? Or do we want to change it in >>>>>some way? >>>>> >>>>>Regards, >>>>>Jukka >>>>> >>>>>_______________________________________________ >>>>>nsis mailing list >>>>>nsis@ietf.org >>>>>https://www1.ietf.org/mailman/listinfo/nsis >>>>> >>>> >>>> >>>>---------------------------------------------------------------------= --- >>>> >>>>_______________________________________________ >>>>nsis mailing list >>>>nsis@ietf.org >>>>https://www1.ietf.org/mailman/listinfo/nsis >> >> >>_______________________________________________ >>nsis mailing list >>nsis@ietf.org >>https://www1.ietf.org/mailman/listinfo/nsis >> >> _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Jun 05 15:59:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvfBJ-0004qg-Uq; Tue, 05 Jun 2007 15:59:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvfBI-0004qP-96 for nsis@ietf.org; Tue, 05 Jun 2007 15:59:04 -0400 Received: from mailer.gwdg.de ([134.76.10.26]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvfBG-0005zN-Ls for nsis@ietf.org; Tue, 05 Jun 2007 15:59:04 -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 1Hvf46-0006JU-LA; Tue, 05 Jun 2007 21:51:39 +0200 Received: from [192.168.0.21] (p5484A981.dip0.t-ipconnect.de [84.132.169.129]) by smtp.stud.informatik.uni-goettingen.de (Postfix) with ESMTP; Tue, 5 Jun 2007 21:51:37 +0200 (CEST) Message-ID: <4665BEB8.1020101@cs.uni-goettingen.de> Date: Tue, 05 Jun 2007 21:51:20 +0200 From: Bernd Schloer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050920 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Georgios Karagiannis Subject: Re: AW: [NSIS] QoS NSLP Abstract API: feedback wanted References: <46645321.7040202@cs.uni-goettingen.de> <46652A8B.3060203@sg.panasonic.com> <001701c7a755$0e9f7b20$4c0d5982@dynamic.ewi.utwente.nl> In-Reply-To: <001701c7a755$0e9f7b20$4c0d5982@dynamic.ewi.utwente.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-Spam-Level: - X-Virus-Scanned: (clean) by exiscan+sophie X-Spam-Score: 0.0 (/) X-Scan-Signature: 2b2ad76aced9b1d558e34a970a85c027 Cc: "'Kappler, Cornelia'" , 'Hong Cheng' , 'NSIS Working Group' , 'Jukka MJ Manner' 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, for network management (e.g. initiating a tunnel, handle aggregate reserv= ations) it is useful to have full control about the message types, objects and fl= ags. For a local application that just wants to make a reservation, a subset of th= eese features would be enough. But it's not really needed to split the API sin= ce the current one covers all functionality. Best regards, Bernd Georgios Karagiannis wrote: > Hi Bernd >=20 > I think that your proposal is already covered by the current API! >=20 > Is it really needed to split the API in: >=20 > API for RMF <---> QoS-NSLP > And > API for Application <------> QoS-NSLP >=20 > Or is it enough to just change the name of the current=20 > version of the API as follows: >=20 > From: Appendix A. Abstract NSLP-RMF API >=20 > Into: Appendix A. Abstract NSLP-RMF/Application API >=20 > And also change: >=20 > From: A.1 Triggers from QOS-NSLP towards RMF=20 >=20 > INTO: A.1 Triggers from QOS-NSLP towards RMF/Application >=20 > And also change: >=20 > From: >=20 > A.2 Triggers from RMF/QOSM towards QOS-NSLP >=20 > INTO: >=20 > A.2 Triggers from RMF/application towards QOS-NSLP >=20 > Best regards, > Georgios >=20 >=20 >=20 >=20 >>-----Original Message----- >>From: Hong Cheng [mailto:hong.cheng@sg.panasonic.com]=20 >>Sent: dinsdag 5 juni 2007 11:19 >>To: Bernd Schloer >>Cc: Kappler, Cornelia; Jukka MJ Manner; NSIS Working Group >>Subject: Re: AW: [NSIS] QoS NSLP Abstract API: feedback wanted >> >>Hi Bernd, >> >>Based on the Figure 2 of the QoS NSLP draft, the Local=20 >>Application is interfacing with the Resource Management=20 >>instead of the QoS NSLP block. >>So, is this API proposed for that interface? >> >>cheers >> >>Cheng Hong >> >> >> >>Bernd Schloer wrote: >> >>>Hi, >>> >>>I have a proposal for an API between the QoS NSLP and the local >>>application: >>> >>>1. From local application to QoS NSLP: >>> >>> reserve_qos(tmod, dst-addr, [dst-port], [dst-prefix], [src-addr], >>> [src-port], [src-prefix], [reservation-style], >>> [authorization info]) -> SessionID >>> >>> The local application initiates a reservation by using the >>>reserve_qos() >>> command. It includes a traffic description=20 >> >>represented by a TMOD=20 >> >>>parameter >>> and the destination address. >>> >>> Optional parameters are destination port, destination prefix,=20 >>>source address, >>> source port, source prefix, a boolean whether sender=20 >> >>or receiver=20 >> >>>initiated >>> reservation will be used and authorization info. >>> >>> If source and/or destination prefix are omitted=20 >> >>default values=20 >> >>>will be used. >>> The default reservation style is sender initiated reservation. >>> >>> If the source address is omitted the IP address from the=20 >>>outgoing interface >>> is taken. This parameter is needed on a host with multiple=20 >>>interfaces. >>> >>> The QoS NSLP returns immediately the generated SessionID. >>> >>> >>> teardown_qos(SessionID) >>> >>> This call removes the reservation state. The parameter is the=20 >>>SessionID. >>> >>> >>>2. From QoS NSLP to local application: >>> >>> recv_qos(SessionID, status) >>> >>> The QoS NSLP provides status information to the=20 >> >>client using the=20 >> >>>command >>> recv_qos(). The status information is taken from the InfoSpec=20 >>>object and >>> informs the local application about the success of=20 >> >>the requested=20 >> >>>reservation >>> or teardown. >>> >>> >>>What do you think of it? >>> >>>Best regards, >>>Bernd >>> >>> >>>Jukka MJ Manner wrote: >>> >>>>Hi, >>>> >>>>I don't know of any application API. The main point was to try to=20 >>>>split the work into a simple and advanced RMF APIs, but looking at=20 >>>>the current spec, it doesn't need to be split. >>>> >>>>Jukka >>>> >>>>On Fri, 1 Jun 2007, Kappler, Cornelia wrote: >>>> >>>> >>>> >>>>>Dear all, >>>>>from the minutes of the IETF in Prague I assumed the API would be=20 >>>>>split into a RMF API and an application API. Isnt this=20 >> >>still planned? >> >>>>>Cornelia >>>>> >>>>> >>>>>>-----Urspr=FCngliche Nachricht----- >>>>>>Von: ext Jukka MJ Manner [mailto:jmanner@cs.Helsinki.FI]=20 >> >>Gesendet: >> >>>>>>Donnerstag, 31. Mai 2007 21:37 >>>>>>An: NSIS Working Group >>>>>>Betreff: [NSIS] QoS NSLP Abstract API: feedback wanted >>>>>> >>>>>> >>>>>>Dear all, >>>>>> >>>>>>The last thing before a WGLC is to specify the abstract=20 >> >>API for the=20 >> >>>>>>QoS NSLP. The current spec has our initial proposal,=20 >> >>which after a=20 >> >>>>>>fresh re-read looks quite ok to me. Maybe some examples on the=20 >>>>>>usage would help clarify the operation but in general=20 >> >>the API looks=20 >> >>>>>>quite good. >>>>>> >>>>>>What do people feel? Is the abstract and informational API good=20 >>>>>>enough at this stage to go for WGLC? Or do we want to=20 >> >>change it in=20 >> >>>>>>some way? >>>>>> >>>>>>Regards, >>>>>>Jukka >>>>>> >>>>>>_______________________________________________ >>>>>>nsis mailing list >>>>>>nsis@ietf.org >>>>>>https://www1.ietf.org/mailman/listinfo/nsis >>>>>> >>>>> >>>>> >>>>> >>-------------------------------------------------------------------- >> >>>>>---- >>>>> >>>>>_______________________________________________ >>>>>nsis mailing list >>>>>nsis@ietf.org >>>>>https://www1.ietf.org/mailman/listinfo/nsis >>> >>> >>>_______________________________________________ >>>nsis mailing list >>>nsis@ietf.org >>>https://www1.ietf.org/mailman/listinfo/nsis >>> >>> >> >> >>_______________________________________________ >>nsis mailing list >>nsis@ietf.org >>https://www1.ietf.org/mailman/listinfo/nsis >=20 >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Jun 06 04:42:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hvr6V-0002O4-KM; Wed, 06 Jun 2007 04:42:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hvr6T-0002Ny-Ga for nsis@ietf.org; Wed, 06 Jun 2007 04:42:53 -0400 Received: from rotterdam.ewi.utwente.nl ([130.89.10.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hvr6R-0003Jg-W8 for nsis@ietf.org; Wed, 06 Jun 2007 04:42:53 -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 l568gZ54014082; Wed, 6 Jun 2007 10:42:49 +0200 (MEST) From: "Georgios Karagiannis" To: "'Bernd Schloer'" References: <46645321.7040202@cs.uni-goettingen.de> <46652A8B.3060203@sg.panasonic.com> <001701c7a755$0e9f7b20$4c0d5982@dynamic.ewi.utwente.nl> <4665BEB8.1020101@cs.uni-goettingen.de> Subject: RE: AW: [NSIS] QoS NSLP Abstract API: feedback wanted Date: Wed, 6 Jun 2007 10:42:31 +0200 Message-ID: <000a01c7a816$a7d68830$4c0d5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: <4665BEB8.1020101@cs.uni-goettingen.de> Thread-Index: AcenqvA6f6AU+8zKQYWm+/vzopC8WQAaytMQ 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]); Wed, 06 Jun 2007 10:42:50 +0200 (MEST) X-Spam-Score: 0.0 (/) X-Scan-Signature: f8ee348dcc4be4a59bc395f7cd6343ad Cc: "'Kappler, Cornelia'" , 'Hong Cheng' , 'NSIS Working Group' , 'Jukka MJ Manner' X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Bernd Okay, but does this mean that you are satisfied with the current version = of the API, or=20 would you like to see an additional section into the draft that = describes the=20 API between user application and QoS-NSLP? Best Regards, Georgios =20 > -----Original Message----- > From: Bernd Schloer [mailto:bschloer@cs.uni-goettingen.de]=20 > Sent: dinsdag 5 juni 2007 21:51 > To: Georgios Karagiannis > Cc: 'Hong Cheng'; 'Kappler, Cornelia'; 'Jukka MJ Manner';=20 > 'NSIS Working Group' > Subject: Re: AW: [NSIS] QoS NSLP Abstract API: feedback wanted >=20 > Hi, >=20 > for network management (e.g. initiating a tunnel, handle=20 > aggregate reservations) it is useful to have full control=20 > about the message types, objects and flags. For a local=20 > application that just wants to make a reservation, a subset=20 > of theese features would be enough. But it's not really=20 > needed to split the API since the current one covers all=20 > functionality. >=20 > Best regards, > Bernd >=20 >=20 > Georgios Karagiannis wrote: > > Hi Bernd > >=20 > > I think that your proposal is already covered by the current API! > >=20 > > Is it really needed to split the API in: > >=20 > > API for RMF <---> QoS-NSLP > > And > > API for Application <------> QoS-NSLP > >=20 > > Or is it enough to just change the name of the current=20 > version of the=20 > > API as follows: > >=20 > > From: Appendix A. Abstract NSLP-RMF API > >=20 > > Into: Appendix A. Abstract NSLP-RMF/Application API > >=20 > > And also change: > >=20 > > From: A.1 Triggers from QOS-NSLP towards RMF > >=20 > > INTO: A.1 Triggers from QOS-NSLP towards RMF/Application > >=20 > > And also change: > >=20 > > From: > >=20 > > A.2 Triggers from RMF/QOSM towards QOS-NSLP > >=20 > > INTO: > >=20 > > A.2 Triggers from RMF/application towards QOS-NSLP > >=20 > > Best regards, > > Georgios > >=20 > >=20 > >=20 > >=20 > >>-----Original Message----- > >>From: Hong Cheng [mailto:hong.cheng@sg.panasonic.com] > >>Sent: dinsdag 5 juni 2007 11:19 > >>To: Bernd Schloer > >>Cc: Kappler, Cornelia; Jukka MJ Manner; NSIS Working Group > >>Subject: Re: AW: [NSIS] QoS NSLP Abstract API: feedback wanted > >> > >>Hi Bernd, > >> > >>Based on the Figure 2 of the QoS NSLP draft, the Local=20 > Application is=20 > >>interfacing with the Resource Management instead of the QoS NSLP=20 > >>block. > >>So, is this API proposed for that interface? > >> > >>cheers > >> > >>Cheng Hong > >> > >> > >> > >>Bernd Schloer wrote: > >> > >>>Hi, > >>> > >>>I have a proposal for an API between the QoS NSLP and the local > >>>application: > >>> > >>>1. From local application to QoS NSLP: > >>> > >>> reserve_qos(tmod, dst-addr, [dst-port], [dst-prefix],=20 > [src-addr], > >>> [src-port], [src-prefix], [reservation-style], > >>> [authorization info]) -> SessionID > >>> > >>> The local application initiates a reservation by using the > >>>reserve_qos() > >>> command. It includes a traffic description > >> > >>represented by a TMOD > >> > >>>parameter > >>> and the destination address. > >>> > >>> Optional parameters are destination port,=20 > destination prefix,=20 > >>>source address, > >>> source port, source prefix, a boolean whether sender > >> > >>or receiver > >> > >>>initiated > >>> reservation will be used and authorization info. > >>> > >>> If source and/or destination prefix are omitted > >> > >>default values > >> > >>>will be used. > >>> The default reservation style is sender initiated=20 > reservation. > >>> > >>> If the source address is omitted the IP address from the=20 > >>>outgoing interface > >>> is taken. This parameter is needed on a host with multiple=20 > >>>interfaces. > >>> > >>> The QoS NSLP returns immediately the generated SessionID. > >>> > >>> > >>> teardown_qos(SessionID) > >>> > >>> This call removes the reservation state. The=20 > parameter is the=20 > >>>SessionID. > >>> > >>> > >>>2. From QoS NSLP to local application: > >>> > >>> recv_qos(SessionID, status) > >>> > >>> The QoS NSLP provides status information to the > >> > >>client using the > >> > >>>command > >>> recv_qos(). The status information is taken from the=20 > InfoSpec=20 > >>>object and > >>> informs the local application about the success of > >> > >>the requested > >> > >>>reservation > >>> or teardown. > >>> > >>> > >>>What do you think of it? > >>> > >>>Best regards, > >>>Bernd > >>> > >>> > >>>Jukka MJ Manner wrote: > >>> > >>>>Hi, > >>>> > >>>>I don't know of any application API. The main point was to try to=20 > >>>>split the work into a simple and advanced RMF APIs, but=20 > looking at=20 > >>>>the current spec, it doesn't need to be split. > >>>> > >>>>Jukka > >>>> > >>>>On Fri, 1 Jun 2007, Kappler, Cornelia wrote: > >>>> > >>>> > >>>> > >>>>>Dear all, > >>>>>from the minutes of the IETF in Prague I assumed the API=20 > would be=20 > >>>>>split into a RMF API and an application API. Isnt this > >> > >>still planned? > >> > >>>>>Cornelia > >>>>> > >>>>> > >>>>>>-----Urspr=FCngliche Nachricht----- > >>>>>>Von: ext Jukka MJ Manner [mailto:jmanner@cs.Helsinki.FI] > >> > >>Gesendet: > >> > >>>>>>Donnerstag, 31. Mai 2007 21:37 > >>>>>>An: NSIS Working Group > >>>>>>Betreff: [NSIS] QoS NSLP Abstract API: feedback wanted > >>>>>> > >>>>>> > >>>>>>Dear all, > >>>>>> > >>>>>>The last thing before a WGLC is to specify the abstract > >> > >>API for the > >> > >>>>>>QoS NSLP. The current spec has our initial proposal, > >> > >>which after a > >> > >>>>>>fresh re-read looks quite ok to me. Maybe some examples on the=20 > >>>>>>usage would help clarify the operation but in general > >> > >>the API looks > >> > >>>>>>quite good. > >>>>>> > >>>>>>What do people feel? Is the abstract and informational API good=20 > >>>>>>enough at this stage to go for WGLC? Or do we want to > >> > >>change it in > >> > >>>>>>some way? > >>>>>> > >>>>>>Regards, > >>>>>>Jukka > >>>>>> > >>>>>>_______________________________________________ > >>>>>>nsis mailing list > >>>>>>nsis@ietf.org > >>>>>>https://www1.ietf.org/mailman/listinfo/nsis > >>>>>> > >>>>> > >>>>> > >>>>> > >>-------------------------------------------------------------------- > >> > >>>>>---- > >>>>> > >>>>>_______________________________________________ > >>>>>nsis mailing list > >>>>>nsis@ietf.org > >>>>>https://www1.ietf.org/mailman/listinfo/nsis > >>> > >>> > >>>_______________________________________________ > >>>nsis mailing list > >>>nsis@ietf.org > >>>https://www1.ietf.org/mailman/listinfo/nsis > >>> > >>> > >> > >> > >>_______________________________________________ > >>nsis mailing list > >>nsis@ietf.org > >>https://www1.ietf.org/mailman/listinfo/nsis > >=20 > >=20 >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Jun 06 12:35: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 1HvyTV-0001xM-0V; Wed, 06 Jun 2007 12:35:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvyTT-0001uo-7t for nsis@ietf.org; Wed, 06 Jun 2007 12:35:07 -0400 Received: from rsys001x.roke.co.uk ([193.118.201.108]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvyTM-0000EP-20 for nsis@ietf.org; Wed, 06 Jun 2007 12:35:07 -0400 Received: from rsys005a.comm.ad.roke.co.uk ([193.118.193.85]) by rsys001x.roke.co.uk (8.13.1/8.13.1) with ESMTP id l56GYrc3008993; Wed, 6 Jun 2007 17:34:53 +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); Wed, 6 Jun 2007 17:34:53 +0100 Message-ID: <4666E22D.6090707@roke.co.uk> Date: Wed, 06 Jun 2007 17:34:53 +0100 From: Andrew McDonald User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Jukka MJ Manner Subject: Re: AW: [NSIS] QoS NSLP Abstract API: feedback wanted References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-OriginalArrivalTime: 06 Jun 2007 16:34:53.0806 (UTC) FILETIME=[9C68F0E0:01C7A858] X-MailScanner-roke-co-uk: Found to be clean X-MailScanner-roke-co-uk-SpamCheck: X-MailScanner-From: andrew.mcdonald@roke.co.uk Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by rsys001x.roke.co.uk id l56GYrc3008993 X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: "Kappler, Cornelia" , NSIS Working Group X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Jukka, Jukka MJ Manner wrote: > I don't know of any application API. The main point was to try to split= =20 > the work into a simple and advanced RMF APIs, but looking at the curren= t=20 > spec, it doesn't need to be split. It was a proposal we discussed, and you presented in the slides at=20 Prague. Some discussion is also mentioned in the meeting minutes. See the last couple of slides of: http://www3.ietf.org/proceedings/07mar/slides/nsis-0.pdf The minutes say: > api: > probably needs to parts > rmf api > application api >=20 > dave oran: > this is one way to look at it > the direction is different for the two > appplication to nslp > nslp to rmf > key point is that there are two parts and the directions are different There were two general ideas we discussed (I think we discussed (a) more=20 off-line than in the WG meeting): a) simple + complex (rich) API - provide an API to do basic things, and=20 then extra bits to do clever things b) RMF + application APIs - replace the current API proposal to change=20 from the model of application/NSLP interaction being done purely via the = RMF I don't think (a) is particularly helpful in simplifying things overall.=20 In particular, it doesn't help in more precisely defining the interface=20 between the NSLP and RMF (which is one of the main points of the=20 abstract API). The problem is that application/NSLP interactions that=20 really have nothing to do with the RMF are all being done via the RMF. (b) provides a more logical structure since it makes it clear whether=20 the RMF is really involved or not. (In the (a) case it often has to=20 forward opaque data between the application and NSLP.) Andrew > On Fri, 1 Jun 2007, Kappler, Cornelia wrote: >=20 >> Dear all,=20 >> >> from the minutes of the IETF in Prague I assumed the API would be spli= t into a RMF API and an application API. Isnt this still planned? >> >> Cornelia=20 >> >>> -----Urspr=FCngliche Nachricht----- >>> Von: ext Jukka MJ Manner [mailto:jmanner@cs.Helsinki.FI]=20 >>> Gesendet: Donnerstag, 31. Mai 2007 21:37 >>> An: NSIS Working Group >>> Betreff: [NSIS] QoS NSLP Abstract API: feedback wanted >>> >>> >>> Dear all, >>> >>> The last thing before a WGLC is to specify the abstract API=20 >>> for the QoS=20 >>> NSLP. The current spec has our initial proposal, which after a fresh=20 >>> re-read looks quite ok to me. Maybe some examples on the=20 >>> usage would help=20 >>> clarify the operation but in general the API looks quite good. >>> >>> What do people feel? Is the abstract and informational API=20 >>> good enough at=20 >>> this stage to go for WGLC? Or do we want to change it in some way? >>> >>> Regards, >>> Jukka _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Jun 06 22:08: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 1Hw7Pu-0006Kk-Sf; Wed, 06 Jun 2007 22:08:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hw7Pt-0006Kf-An for nsis@ietf.org; Wed, 06 Jun 2007 22:08:01 -0400 Received: from smtp.mei.co.jp ([133.183.129.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hw7Ps-00021g-KE for nsis@ietf.org; Wed, 06 Jun 2007 22:08: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/kings) with ESMTP id l5727pkZ013659; Thu, 7 Jun 2007 11:07:51 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx3) with ESMTP id l5727pY02665; Thu, 7 Jun 2007 11:07:51 +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 l5727n710919; Thu, 7 Jun 2007 11:07:49 +0900 (JST) Received: from [127.0.0.1] ([10.81.113.75]) by pslexc01.psl.local with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Jun 2007 10:06:33 +0800 Message-ID: <46676831.4060705@sg.panasonic.com> Date: Thu, 07 Jun 2007 10:06:41 +0800 From: Hong Cheng User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Andrew McDonald Subject: Re: AW: [NSIS] QoS NSLP Abstract API: feedback wanted References: <4666E22D.6090707@roke.co.uk> In-Reply-To: <4666E22D.6090707@roke.co.uk> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 X-OriginalArrivalTime: 07 Jun 2007 02:06:33.0986 (UTC) FILETIME=[78E90E20:01C7A8A8] Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by smtp.mei.co.jp id l5727pkZ013659 X-Spam-Score: 0.1 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 Cc: "Kappler, Cornelia" , Jukka MJ Manner , NSIS Working Group X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Andrew, Regarding the proposal: > b) RMF + application APIs - replace the current API proposal to change > from the model of application/NSLP interaction being done purely via th= e > RMF Does this mean a (RMF-NSLP API) + a (Application-NSLP API), or a (RMF/Application-NSLP API) as mentioned by Georgios earlier? > (b) provides a more logical structure since it makes it clear whether > the RMF is really involved or not. (In the (a) case it often has to > forward opaque data between the application and NSLP.) In the b) case, does the Application still have an interface to the RMF, or must it go via the NSLP now? Maybe a new architecture diagram will help to understand the proposal better (obviously, it is different from Figure 2 in the draft now). Also, would like to know in the proposal what would be the states/information managed by the NSLP. Jukka provided an operation model for the current API and that seems OK. Similar explanation would be helpful. For example, would the NSLP now need to forward opaque data between Application and RMF? cheers Cheng Hong Andrew McDonald wrote: > Hi Jukka, >=20 > Jukka MJ Manner wrote: >> I don't know of any application API. The main point was to try to >> split the work into a simple and advanced RMF APIs, but looking at the >> current spec, it doesn't need to be split. >=20 > It was a proposal we discussed, and you presented in the slides at > Prague. Some discussion is also mentioned in the meeting minutes. > See the last couple of slides of: > http://www3.ietf.org/proceedings/07mar/slides/nsis-0.pdf > The minutes say: >> api: >> probably needs to parts >> rmf api >> application api >> >> dave oran: >> this is one way to look at it >> the direction is different for the two >> appplication to nslp >> nslp to rmf >> key point is that there are two parts and the directions are different >=20 > There were two general ideas we discussed (I think we discussed (a) mor= e > off-line than in the WG meeting): > a) simple + complex (rich) API - provide an API to do basic things, and > then extra bits to do clever things > b) RMF + application APIs - replace the current API proposal to change > from the model of application/NSLP interaction being done purely via th= e > RMF >=20 > I don't think (a) is particularly helpful in simplifying things overall. > In particular, it doesn't help in more precisely defining the interface > between the NSLP and RMF (which is one of the main points of the > abstract API). The problem is that application/NSLP interactions that > really have nothing to do with the RMF are all being done via the RMF. >=20 > (b) provides a more logical structure since it makes it clear whether > the RMF is really involved or not. (In the (a) case it often has to > forward opaque data between the application and NSLP.) >=20 > Andrew >=20 >> On Fri, 1 Jun 2007, Kappler, Cornelia wrote: >> >>> Dear all, >>> from the minutes of the IETF in Prague I assumed the API would be >>> split into a RMF API and an application API. Isnt this still planned? >>> >>> Cornelia >>>> -----Urspr=FCngliche Nachricht----- >>>> Von: ext Jukka MJ Manner [mailto:jmanner@cs.Helsinki.FI] Gesendet: >>>> Donnerstag, 31. Mai 2007 21:37 >>>> An: NSIS Working Group >>>> Betreff: [NSIS] QoS NSLP Abstract API: feedback wanted >>>> >>>> >>>> Dear all, >>>> >>>> The last thing before a WGLC is to specify the abstract API for the >>>> QoS NSLP. The current spec has our initial proposal, which after a >>>> fresh re-read looks quite ok to me. Maybe some examples on the usage >>>> would help clarify the operation but in general the API looks quite >>>> good. >>>> >>>> What do people feel? Is the abstract and informational API good >>>> enough at this stage to go for WGLC? Or do we want to change it in >>>> some way? >>>> >>>> Regards, >>>> Jukka >=20 >=20 > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis >=20 >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Jun 06 23:27:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hw8eX-0006A8-6t; Wed, 06 Jun 2007 23:27:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hw8eV-00069y-J4 for nsis@ietf.org; Wed, 06 Jun 2007 23:27:11 -0400 Received: from an-out-0708.google.com ([209.85.132.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hw8eU-0006Sr-CD for nsis@ietf.org; Wed, 06 Jun 2007 23:27:11 -0400 Received: by an-out-0708.google.com with SMTP id c17so80766anc for ; Wed, 06 Jun 2007 20:27:10 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; b=XLEderblvbPzt2S8PD6WQelvuBd62BEmNyyUsasgrF8mwjey8GsyRxLZJdNTvy14FVQE2YGWpdUTrjmUOvkR51TmbguRZeoYXx3jNLFwyXKRU1Cxn3jNzKE8f8/cKO0IylALZ2M1RTPMZvDsSoFiXbYW1Su7bWoktyyBoABI0Qk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type; b=Dmh2ZjKzs1NusP2utXJdLDgpwQjZyqpM5YEBX4517YsEhpcibnw2In8Krc/sFm1GfHNPMHGC7ptFj8h6QzDPZ9JA+PAGl56ImgKqeAdUUBvKX/VRD5XXfLXEQqfA/LVwtwnusEeU87ObNQsGwdsNlWG1opf5tns8zpE0+sdwSoE= Received: by 10.100.79.16 with SMTP id c16mr153612anb.1181186829943; Wed, 06 Jun 2007 20:27:09 -0700 (PDT) Received: by 10.100.190.9 with HTTP; Wed, 6 Jun 2007 20:27:09 -0700 (PDT) Message-ID: <5a26be460706062027y3c81fc39j4e7f835ac43a1cc@mail.gmail.com> Date: Thu, 7 Jun 2007 11:27:09 +0800 From: "=?GB2312?B?sfOx8831?=" To: nsis@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.8 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Subject: [NSIS] NSIS in Mobile Environment 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="===============1467249496==" Errors-To: nsis-bounces@ietf.org --===============1467249496== Content-Type: multipart/alternative; boundary="----=_Part_49537_23145571.1181186829928" ------=_Part_49537_23145571.1181186829928 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi All, I want to use the NSIS signaling to guarantee the QoS of SIP Phone in Mobile IPv6 Environments. However, after Mobile node (MN) moves to the foreign networks, how to trigger the NSIS set up a new signaling state path along the optimization path? which component is responsible to trigger this procedure? For the mobility event is transparent to our specific application (sip phone). I am confused. And I don't know which component (or which layer in the protocol stack) should be responsible to trigger the new NSIS signaling setup procedure after mobility. B.R. Wang 2007-06-07 -- Wang.bupt ------=_Part_49537_23145571.1181186829928 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi All,

I want to use the NSIS signaling to guarantee the QoS of SIP Phone in Mobile IPv6 Environments.  However,  after  Mobile node  (MN) moves to the foreign networks, how to trigger the NSIS set up a new signaling state path along the optimization path? which component is responsible to trigger this procedure?

For the mobility event is transparent to our specific application (sip phone).  I am confused. And I don't know which component (or which layer in the protocol stack) should be responsible to trigger the new NSIS signaling setup procedure after mobility.

B.R.

Wang
2007-06-07


--
Wang.bupt ------=_Part_49537_23145571.1181186829928-- --===============1467249496== 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 --===============1467249496==-- From nsis-bounces@ietf.org Thu Jun 07 06:49:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwFYs-0003gQ-Fm; Thu, 07 Jun 2007 06:49:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwFYq-0003gJ-W2 for nsis@ietf.org; Thu, 07 Jun 2007 06:49:48 -0400 Received: from mailer.gwdg.de ([134.76.10.26]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwFYq-0003UE-Bf for nsis@ietf.org; Thu, 07 Jun 2007 06:49:48 -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 1HwFYa-0000ra-K3; Thu, 07 Jun 2007 12:49:32 +0200 Received: from [192.168.0.21] (p54848805.dip0.t-ipconnect.de [84.132.136.5]) by smtp.stud.informatik.uni-goettingen.de (Postfix) with ESMTP; Thu, 7 Jun 2007 12:49:32 +0200 (CEST) Message-ID: <4667E2AC.1050706@cs.uni-goettingen.de> Date: Thu, 07 Jun 2007 12:49:16 +0200 From: Bernd Schloer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050920 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Hong Cheng Subject: Re: AW: [NSIS] QoS NSLP Abstract API: feedback wanted References: <4666E22D.6090707@roke.co.uk> <46676831.4060705@sg.panasonic.com> In-Reply-To: <46676831.4060705@sg.panasonic.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-Spam-Level: - X-Virus-Scanned: (clean) by exiscan+sophie X-Spam-Score: 0.0 (/) X-Scan-Signature: 0e9ebc0cbd700a87c0637ad0e2c91610 Cc: Andrew McDonald , "Kappler, Cornelia" , Jukka MJ Manner , NSIS Working Group X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi, please see inline. regards, Bernd Hong Cheng wrote: > Hi Andrew, >=20 > Regarding the proposal: >=20 >=20 >>b) RMF + application APIs - replace the current API proposal to change >>from the model of application/NSLP interaction being done purely via th= e >>RMF >=20 >=20 > Does this mean a (RMF-NSLP API) + a (Application-NSLP API), or a > (RMF/Application-NSLP API) as mentioned by Georgios earlier? >=20 From my understanding the b) case means a (RMF-NSLP API) + a (Application-NSLP API). >=20 >=20 >>(b) provides a more logical structure since it makes it clear whether >>the RMF is really involved or not. (In the (a) case it often has to >>forward opaque data between the application and NSLP.) >=20 >=20 > In the b) case, does the Application still have an interface to the RMF= , > or must it go via the NSLP now? Maybe a new architecture diagram will > help to understand the proposal better (obviously, it is different from= > Figure 2 in the draft now). In the b) case triggers from the client application could be treated like= incoming messages over the network. The architecture diagram would look like Local Appl. Network ^ Management I ^ I I v v QoS NSLP <---------> Resource ^ Management I v NTLP processing >=20 > Also, would like to know in the proposal what would be the > states/information managed by the NSLP. Jukka provided an operation > model for the current API and that seems OK. Similar explanation would > be helpful. For example, would the NSLP now need to forward opaque data= > between Application and RMF? >=20 > cheers >=20 > Cheng Hong >=20 >=20 >=20 > Andrew McDonald wrote: >=20 >>Hi Jukka, >> >>Jukka MJ Manner wrote: >> >>>I don't know of any application API. The main point was to try to >>>split the work into a simple and advanced RMF APIs, but looking at the= >>>current spec, it doesn't need to be split. >> >>It was a proposal we discussed, and you presented in the slides at >>Prague. Some discussion is also mentioned in the meeting minutes. >>See the last couple of slides of: >>http://www3.ietf.org/proceedings/07mar/slides/nsis-0.pdf >>The minutes say: >> >>>api: >>>probably needs to parts >>>rmf api >>>application api >>> >>>dave oran: >>>this is one way to look at it >>>the direction is different for the two >>>appplication to nslp >>>nslp to rmf >>>key point is that there are two parts and the directions are different= >> >>There were two general ideas we discussed (I think we discussed (a) mor= e >>off-line than in the WG meeting): >>a) simple + complex (rich) API - provide an API to do basic things, and= >>then extra bits to do clever things >>b) RMF + application APIs - replace the current API proposal to change >>from the model of application/NSLP interaction being done purely via th= e >>RMF >> >>I don't think (a) is particularly helpful in simplifying things overall= =2E >>In particular, it doesn't help in more precisely defining the interface= >>between the NSLP and RMF (which is one of the main points of the >>abstract API). The problem is that application/NSLP interactions that >>really have nothing to do with the RMF are all being done via the RMF. >> >>(b) provides a more logical structure since it makes it clear whether >>the RMF is really involved or not. (In the (a) case it often has to >>forward opaque data between the application and NSLP.) >> >>Andrew >> >> >>>On Fri, 1 Jun 2007, Kappler, Cornelia wrote: >>> >>> >>>>Dear all, >>>>from the minutes of the IETF in Prague I assumed the API would be >>>>split into a RMF API and an application API. Isnt this still planned?= >>>> >>>>Cornelia >>>> >>>>>-----Urspr=FCngliche Nachricht----- >>>>>Von: ext Jukka MJ Manner [mailto:jmanner@cs.Helsinki.FI] Gesendet: >>>>>Donnerstag, 31. Mai 2007 21:37 >>>>>An: NSIS Working Group >>>>>Betreff: [NSIS] QoS NSLP Abstract API: feedback wanted >>>>> >>>>> >>>>>Dear all, >>>>> >>>>>The last thing before a WGLC is to specify the abstract API for the >>>>>QoS NSLP. The current spec has our initial proposal, which after a >>>>>fresh re-read looks quite ok to me. Maybe some examples on the usage= >>>>>would help clarify the operation but in general the API looks quite >>>>>good. >>>>> >>>>>What do people feel? Is the abstract and informational API good >>>>>enough at this stage to go for WGLC? Or do we want to change it in >>>>>some way? >>>>> >>>>>Regards, >>>>>Jukka >> >> >>_______________________________________________ >>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 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Jun 08 11:35: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 1HwgUb-0000oS-TL; Fri, 08 Jun 2007 11:35:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwgUa-0000oH-KL for nsis@ietf.org; Fri, 08 Jun 2007 11:35:12 -0400 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwgUa-0001Rt-4t for nsis@ietf.org; Fri, 08 Jun 2007 11:35:12 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l58FZ6dc028518 for ; Fri, 8 Jun 2007 18:35:09 +0300 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Jun 2007 18:35:05 +0300 Received: from daebe103.NOE.Nokia.com ([10.241.35.24]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Jun 2007 10:35:01 -0500 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 8 Jun 2007 10:35:01 -0500 Message-ID: <071568CA7B789D4AA170CEF8C9613B4FAE395C@daebe103.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Internet-Drafts Submission Cutoff Dates for the 69th IETF Meeting in Chicago, IL, USA Thread-Index: AcepgccV+Xtq6//YQYKsVBnDQuP89gAYLK8Q From: To: X-OriginalArrivalTime: 08 Jun 2007 15:35:01.0563 (UTC) FILETIME=[9417A8B0:01C7A9E2] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Subject: [NSIS] FW: Internet-Drafts Submission Cutoff Dates for the 69th IETF Meeting in Chicago, IL, USA 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 FYI. Also, if you have a topic or draft you want to discuss in Chicago, please let us know. Martin & John=20 >-----Original Message----- >From: ext ietf-announce-bounces@ietf.org=20 >[mailto:ietf-announce-bounces@ietf.org]=20 >Sent: 07 June, 2007 21:00 >To: ietf-announce@ietf.org >Subject: Internet-Drafts Submission Cutoff Dates for the 69th=20 >IETF Meeting in Chicago, IL, USA=20 > > >There are two (2) Internet-Draft cutoff dates for the 69th=20 >IETF Meeting in Chicago, IL, USA: > >July 2nd: Cutoff Date for Initial (i.e., version -00)=20 >Internet-Draft Submissions=20 > >All initial Internet-Drafts (version -00) must be submitted by=20 >Monday, July 2nd at 9:00 AM ET. As always, all initial=20 >submissions with a filename beginning with "draft-ietf" must=20 >be approved by the appropriate WG Chair before they can be=20 >processed or announced. The Secretariat would appreciate=20 >receiving WG Chair approval by Monday, June 25th at 9:00 AM ET. > >July 9th: Cutoff Date for Revised (i.e., version -01 and=20 >higher) Internet-Draft Submissions=20 > >All revised Internet-Drafts (version -01 and higher) must be=20 >submitted by Monday, July 9th at 9:00 AM ET. > >Initial and revised Internet-Drafts received after their=20 >respective cutoff dates will not be made available in the=20 >Internet-Drafts directory or announced until on or after=20 >Monday, July 23rd at 9:00 AM ET, when Internet-Draft posting=20 >resumes. Please do not wait until the last minute to submit. > >Thank you for your understanding and cooperation. If you have=20 >any questions or concerns, then please send a message to=20 >internet-drafts@ietf.org. > >The IETF Secretariat > >FYI: The Internet-Draft cutoff dates as well as other=20 >significant dates for the 69th IETF Meeting can be found at=20 >http://www.ietf.org/meetings/cutoff_dates_69.html. > >_______________________________________________ >IETF-Announce mailing list >IETF-Announce@ietf.org >https://www1.ietf.org/mailman/listinfo/ietf-announce > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Jun 08 12:49: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 1Hwheq-0003xR-KB; Fri, 08 Jun 2007 12:49:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hwhep-0003xM-Lb for nsis@ietf.org; Fri, 08 Jun 2007 12:49:51 -0400 Received: from rsys001x.roke.co.uk ([193.118.201.108]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hwhem-0007Ll-32 for nsis@ietf.org; Fri, 08 Jun 2007 12:49:51 -0400 Received: from rsys005a.comm.ad.roke.co.uk ([193.118.193.85]) by rsys001x.roke.co.uk (8.13.1/8.13.1) with ESMTP id l58GnckJ003265; Fri, 8 Jun 2007 17:49:38 +0100 Received: from [127.0.0.1] ([193.118.192.66]) by rsys005a.comm.ad.roke.co.uk with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Jun 2007 17:49:37 +0100 Message-ID: <466988A1.7000302@roke.co.uk> Date: Fri, 08 Jun 2007 17:49:37 +0100 From: Andrew McDonald User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Bernd Schloer Subject: Re: AW: [NSIS] QoS NSLP Abstract API: feedback wanted References: <4666E22D.6090707@roke.co.uk> <46676831.4060705@sg.panasonic.com> <4667E2AC.1050706@cs.uni-goettingen.de> In-Reply-To: <4667E2AC.1050706@cs.uni-goettingen.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Jun 2007 16:49:37.0970 (UTC) FILETIME=[003D2920:01C7A9ED] 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: 8b431ad66d60be2d47c7bfeb879db82c Cc: "Kappler, Cornelia" , Hong Cheng , NSIS Working Group , Jukka MJ Manner 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 Bernd Schloer wrote: > Hong Cheng wrote: >> Regarding the proposal: >> >> >>> b) RMF + application APIs - replace the current API proposal to change >>> from the model of application/NSLP interaction being done purely via the >>> RMF >> >> >> Does this mean a (RMF-NSLP API) + a (Application-NSLP API), or a >> (RMF/Application-NSLP API) as mentioned by Georgios earlier? >> > > From my understanding the b) case means a (RMF-NSLP API) + a > (Application-NSLP API). Yes. >>> (b) provides a more logical structure since it makes it clear whether >>> the RMF is really involved or not. (In the (a) case it often has to >>> forward opaque data between the application and NSLP.) >> >> >> In the b) case, does the Application still have an interface to the RMF, >> or must it go via the NSLP now? Maybe a new architecture diagram will >> help to understand the proposal better (obviously, it is different from >> Figure 2 in the draft now). > > In the b) case triggers from the client application could be treated like > incoming messages over the network. The architecture diagram would look > like > > Local Appl. Network > ^ Management > I ^ > I I > v v > QoS NSLP <---------> Resource > ^ Management > I > v > NTLP > processing Yes. (And, yes, I agree this deviates from the 'model' in fig 2. However, I don't believe this involves any changes outside the API. i.e. no protocol changes.) Andrew _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Sun Jun 10 14:14:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxRvS-0002vx-J0; Sun, 10 Jun 2007 14:14:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxRvR-0002vs-3C for nsis@ietf.org; Sun, 10 Jun 2007 14:14:05 -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 1HxRvP-00089h-KF for nsis@ietf.org; Sun, 10 Jun 2007 14:14: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; Sun, 10 Jun 2007 21:14:03 +0300 id 001B833E.466C3F6B.000052EB Date: Sun, 10 Jun 2007 21:14:03 +0300 (EEST) From: Jukka MJ Manner To: NSIS Working Group Subject: Re: [NSIS] QoS NSLP final fixes for v.14 In-Reply-To: Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 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, A new draft has been submitted. Before it is available from the repository, you can find it here, and a diff against v.13. The changes were given below, in addition a few API changes were done, and Georgios and Roland added a functionality to support intra-domain operation, maybe the boys could tell a bit more about it. http://www.cs.helsinki.fi/u/jmanner/qos-nslp/ Regards, Jukka On Wed, 30 May 2007, Jukka MJ Manner wrote: > > Dear all, > > Here are the changes I have done to QoS NSLP spec. If I have missed some > comment, please forgive me, and send it again. > > There is still the question of the abstract API. The current version is > (very) complex, and one proposal was to divide it into a simple API, and a > more powerful API (mainly for those inter-intra domain cases). > > The changes: > > 1. > > Added Protocol Error: > > 0x0f - Incompatible QSPEC > (From Jerry & Andrew, Mar 14) > > 2. > > Moved Break-flag from message-specific flags to Generic Flags in the > Common Header. > (Suggested by Roland, Mar 21) > > 3. > > To support pre-emption mechanisms in QOSMs, we have added: > > * RESERVE and QUERY should be able to carry an INFO_SPEC object > > * BOUND_SESSION_ID that indicates the session that caused the > pre-emption. Note that the value of this BOUND_SESSION_ID will have a > new Binding Code value, which will have to be specified in the QOS-NSLP. > > and the section below: > > 4.2.12. Pre-emption > > The QoS NSLP provides building blocks to implement pre-emption. This > specification does not define how pre-emption should work, but only > provides signaling mechanisms that can be used by QoS Models. For > example, an INFO_SPEC object can be added to messages to indicate > that the signaled session was pre-empted. A BOUND_SESSION_ID object > can carry the Session ID of the flow that caused the pre-emption to > happen for the signaled session. How these are used by QoS Models is > out of scope of the QoS NSLP specification. > > > > When do we start WGLC? > > > Regards, > Jukka > > ps. By far the biggest change was to move from good-old nroff to xml... > took a while. ;) > > _______________________________________________ > 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 Sun Jun 10 16:22: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 1HxTvp-0008F7-TC; Sun, 10 Jun 2007 16:22:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxTvo-0008F0-QV for nsis@ietf.org; Sun, 10 Jun 2007 16:22:36 -0400 Received: from smtp2.dei.uc.pt ([193.137.203.231] helo=smtp.dei.uc.pt) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HxTvo-00018x-2E for nsis@ietf.org; Sun, 10 Jun 2007 16:22:36 -0400 Received: from [192.168.33.225] (gisttest1.dei.uc.pt [193.136.212.207]) (authenticated bits=0) by smtp.dei.uc.pt (8.13.8/8.13.8) with ESMTP id l5AKMM2h005279 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 10 Jun 2007 21:22:22 +0100 Message-ID: <466C5DA6.40103@student.dei.uc.pt> Date: Sun, 10 Jun 2007 21:23:02 +0100 From: David Palma User-Agent: Thunderbird 2.0.0.0 (X11/20070522) MIME-Version: 1.0 To: nsis@ietf.org Subject: Re: AW: [NSIS] QoS NSLP Abstract API: feedback wanted References: <4666E22D.6090707@roke.co.uk> <46676831.4060705@sg.panasonic.com> <4667E2AC.1050706@cs.uni-goettingen.de> <466988A1.7000302@roke.co.uk> In-Reply-To: <466988A1.7000302@roke.co.uk> X-FCTUC-DEI-SIC-MailScanner-Information: Please contact helpdesk@dei.uc.pt for more information X-FCTUC-DEI-SIC-MailScanner: Found to be clean X-FCTUC-DEI-SIC-MailScanner-SpamCheck: not spam (whitelisted), SpamAssassin (not cached, score=-38.098, required 2.9, autolearn=not spam, ALL_TRUSTED -1.80, AWL 13.74, BAYES_00 -1.50, HTML_MESSAGE 0.00, L_SMTP_AUTH -50.00, MIME_HTML_ONLY 1.46) X-FCTUC-DEI-SIC-MailScanner-From: palma@student.dei.uc.pt X-Spam-Status: No X-Spam-Score: 1.2 (+) X-Scan-Signature: f884eb1d4ec5a230688d7edc526ea665 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="===============0708735930==" Errors-To: nsis-bounces@ietf.org --===============0708735930== Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi all,

I'm from the University of Coimbra and I agree with the several APIs approach.  In our current implementation , the architecture is defined as shown bellow:

                              +---------------+
                              |     Local     |
                              |Applications or|
                              |Management (e.g|
                              |for aggregates)|
                              +---------------+
                                      ^
                                      V
                                      V
      +---------+               +----------+             +----------+
      | Policy  |               | QoS NSLP |             | Resource |
      | Control |<<<<<<<<>>>>>>>|Processing|<<<<<<>>>>>>>|Management|
      +---------+               +----------+             +----------+
                                 .  ^   |
                                 |  V   .
                              +----------+
                              |   NTLP   |
                              |Processing|
                              +----------+
 
(theres' a third API between QoS NSLP and the Policy Control)

Best Regards,
David Palma
UoCoimbra

PS: sorry for the late contribution

Andrew McDonald wrote:
Bernd Schloer wrote:
Hong Cheng wrote:
Regarding the proposal:


b) RMF + application APIs - replace the current API proposal to change
from the model of application/NSLP interaction being done purely via the
RMF


Does this mean a (RMF-NSLP API) + a (Application-NSLP API), or a
(RMF/Application-NSLP API) as mentioned by Georgios earlier?


 From my understanding the b) case means a (RMF-NSLP API) + a
(Application-NSLP API).

Yes.

(b) provides a more logical structure since it makes it clear whether
the RMF is really involved or not. (In the (a) case it often has to
forward opaque data between the application and NSLP.)


In the b) case, does the Application still have an interface to the RMF,
or  must it go via the NSLP now? Maybe a new architecture diagram will
help to understand the proposal better (obviously, it is different from
Figure 2 in the draft now).

In the b) case triggers from the client application could be treated like
incoming messages over the network. The architecture diagram would look
like

  Local Appl.            Network
     ^                 Management
     I                     ^
     I                     I
     v                     v
  QoS NSLP <---------> Resource
     ^                Management
     I
     v
   NTLP
 processing

Yes. (And, yes, I agree this deviates from the 'model' in fig 2. However, I don't believe this involves any changes outside the API. i.e. no protocol changes.)


Andrew

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


--===============0708735930== 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 --===============0708735930==-- From nsis-bounces@ietf.org Mon Jun 11 07:23:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hxhz9-0002mT-KR; Mon, 11 Jun 2007 07:22:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hxhz8-0002iw-0v for nsis@ietf.org; Mon, 11 Jun 2007 07:22:58 -0400 Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hxhz6-0006wM-CV for nsis@ietf.org; Mon, 11 Jun 2007 07:22:58 -0400 Received: from irams2.ira.uni-karlsruhe.de ([141.3.10.82]) by iramx2.ira.uni-karlsruhe.de with esmtps id 1Hxhyy-0001VS-Fy for ; Mon, 11 Jun 2007 13:22:55 +0200 Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5]) by irams2.ira.uni-karlsruhe.de with esmtps for id 1Hxhys-0005QF-RO; Mon, 11 Jun 2007 13:22:48 +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 1Hxhys-0002C5-7z; Mon, 11 Jun 2007 13:22:42 +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 1C77B2FC097 for ; Mon, 11 Jun 2007 13:22:41 +0200 (CEST) Received: from localhost ([127.0.0.1]) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.44) id 1Hxhyq-0003mG-O7 for nsis@ietf.org; Mon, 11 Jun 2007 13:22:40 +0200 Message-ID: <466D3080.8040303@tm.uka.de> Date: Mon, 11 Jun 2007 13:22:40 +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: NSIS Working Group Subject: Re: [NSIS] QoS NSLP final fixes for v.14 References: In-Reply-To: X-Enigmail-Version: 0.94.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-MS2-Spam-Status: No X-MS2-Spam-Score: -1.4 (-) X-MS2-Spam-Report: -1.4 ALL_TRUSTED Passed through trusted hosts only via SMTP 0.0 AWL AWL: From: address is in the auto white-list X-MS2-ATIS-Checksum: v3zoCAcc32ckk X-Spam-Status: No X-Spam-Score: -1.4 (-) X-Spam-Report: -1.4 ALL_TRUSTED Passed through trusted hosts only via SMTP 0.0 AWL AWL: From: address is in the auto white-list X-ATIS-Checksum: v3zoCAcc32ckk X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 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, Jukka MJ Manner wrote: > Dear all, > > A new draft has been submitted. Before it is available from the > repository, you can find it here, and a diff against v.13. The changes > were given below, in addition a few API changes were done, and Georgios > and Roland added a functionality to support intra-domain operation, maybe > the boys could tell a bit more about it. Not exactly related to intra-domain operation only. It's a feature that we call "message binding" and it allows to reduce session setup time in case you are using reservation aggregates. The basic idea is that you can start two signaling exchanges simultaneously, that have a dependency among each other. By using the message binding, you can let messages wait on other messages if there is such a dependency. So it would also be useful in inter-domain scenarios. Regards, Roland _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Jun 11 15:50: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 1Hxpuf-0003UV-Ta; Mon, 11 Jun 2007 15:50:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hxptr-00014Q-PI; Mon, 11 Jun 2007 15:50:03 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hxptr-0007W5-DD; Mon, 11 Jun 2007 15:50:03 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id E38A126EC5; Mon, 11 Jun 2007 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Hxptq-00057K-HE; Mon, 11 Jun 2007 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 11 Jun 2007 15:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: nsis@ietf.org Subject: [NSIS] I-D ACTION:draft-ietf-nsis-qos-nslp-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 : NSLP for Quality-of-Service Signaling Author(s) : J. Manner, et al. Filename : draft-ietf-nsis-qos-nslp-14.txt Pages : 97 Date : 2007-6-11 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-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-qos-nslp-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-qos-nslp-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-6-11123257.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nsis-qos-nslp-14.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nsis-qos-nslp-14.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-6-11123257.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 Jun 12 17:28: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 1HyDuE-0006X9-Cb; Tue, 12 Jun 2007 17:28:02 -0400 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1HyDuD-0006US-Dn for nsis-confirm+ok@megatron.ietf.org; Tue, 12 Jun 2007 17:28:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyDuD-0006S6-1l for nsis@ietf.org; Tue, 12 Jun 2007 17:28:01 -0400 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyDuC-0004Y2-HX for nsis@ietf.org; Tue, 12 Jun 2007 17:28:01 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l5CLRgin023782 for ; Wed, 13 Jun 2007 00:27:58 +0300 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 13 Jun 2007 00:27:49 +0300 Received: from daebe103.NOE.Nokia.com ([10.241.35.24]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 12 Jun 2007 16:27:48 -0500 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 12 Jun 2007 16:27:48 -0500 Message-ID: <071568CA7B789D4AA170CEF8C9613B4FB11B80@daebe103.NOE.Nokia.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WGLC:draft-ietf-nsis-qos-nslp-14.txt Thread-Index: AcesYeA263FpFqfbRPaAE0Du4t3kYQA1lktg References: From: To: X-OriginalArrivalTime: 12 Jun 2007 21:27:48.0403 (UTC) FILETIME=[862A2030:01C7AD38] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Subject: [NSIS] WGLC:draft-ietf-nsis-qos-nslp-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 Jukka has updated the draft. We would like to start a 2 week WGLC on the draft which will run through close of business on June 25th. Please review the draft, and comment if you feel that this draft is ready to be sent to the IESG. A simple mail saying that the draft is ready for publication would be great. Of course, if you read the draft and find open issues, then please send a summary of your issue with the current draft. thanks, Martin and John=20 >-----Original Message----- >From: ext nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org]=20 >Sent: 11 June, 2007 12:50 >To: i-d-announce@ietf.org >Cc: nsis@ietf.org >Subject: [NSIS] I-D ACTION:draft-ietf-nsis-qos-nslp-14.txt=20 > >A New Internet-Draft is available from the on-line=20 >Internet-Drafts directories. >This draft is a work item of the Next Steps in Signaling=20 >Working Group of the IETF. > > Title : NSLP for Quality-of-Service Signaling > Author(s) : J. Manner, et al. > Filename : draft-ietf-nsis-qos-nslp-14.txt > Pages : 97 > Date : 2007-6-11 >=09 >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. =20 >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-14.txt > >To remove yourself from the I-D Announcement list, send a=20 >message to i-d-announce-request@ietf.org with the word=20 >unsubscribe in the body of the message.=20 >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=20 >with the username "anonymous" and a password of your e-mail=20 >address. After logging in, type "cd internet-drafts" and then=20 >"get draft-ietf-nsis-qos-nslp-14.txt". > >A list of Internet-Drafts directories can be found in=20 >http://www.ietf.org/shadow.html or=20 >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-14.txt". >=09 >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=20 >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=20 >reader implementation to automatically retrieve the ASCII=20 >version of the Internet-Draft. > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Jun 13 15:03:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyY8I-00042A-49; Wed, 13 Jun 2007 15:03:54 -0400 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1HyY8G-00041v-Tc for nsis-confirm+ok@megatron.ietf.org; Wed, 13 Jun 2007 15:03:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyY8G-00041n-K7 for nsis@ietf.org; Wed, 13 Jun 2007 15:03:52 -0400 Received: from mailer.gwdg.de ([134.76.10.26]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyY8F-0000cz-B9 for nsis@ietf.org; Wed, 13 Jun 2007 15:03:52 -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 1HyY80-00011U-Hg; Wed, 13 Jun 2007 21:03:36 +0200 Received: from [192.168.0.21] (p54849FEC.dip0.t-ipconnect.de [84.132.159.236]) by smtp.stud.informatik.uni-goettingen.de (Postfix) with ESMTP; Wed, 13 Jun 2007 21:03:35 +0200 (CEST) Message-ID: <46703F7A.6010102@cs.uni-goettingen.de> Date: Wed, 13 Jun 2007 21:03:22 +0200 From: Bernd Schloer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050920 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Hong Cheng Subject: Re: AW: [NSIS] QoS NSLP Abstract API: feedback wanted References: <4666E22D.6090707@roke.co.uk> <46676831.4060705@sg.panasonic.com> In-Reply-To: <46676831.4060705@sg.panasonic.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Level: - X-Virus-Scanned: (clean) by exiscan+sophie X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: Andrew McDonald , "Kappler, Cornelia" , Jukka MJ Manner , NSIS Working Group X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi, > Also, would like to know in the proposal what would be the > states/information managed by the NSLP. Jukka provided an operation > model for the current API and that seems OK. I also think that the current API is ok and I withdraw my proposal. Best regards, Bernd _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Jun 14 04:37:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HykpO-0004Qz-Om; Thu, 14 Jun 2007 04:37:14 -0400 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1HykpN-0004Qq-HC for nsis-confirm+ok@megatron.ietf.org; Thu, 14 Jun 2007 04:37:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HykpN-0004Qi-3d for nsis@ietf.org; Thu, 14 Jun 2007 04:37:13 -0400 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HykpL-00037w-PY for nsis@ietf.org; Thu, 14 Jun 2007 04:37:13 -0400 Received: from [10.1.1.109] (mito.netlab.nec.de [195.37.70.39]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 2C74F13CF82 for ; Thu, 14 Jun 2007 10:37:07 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v752.3) To: nsis Message-Id: <36863C4B-B69B-4073-951A-46E75BFB5D53@netlab.nec.de> From: Martin Stiemerling Date: Thu, 14 Jun 2007 10:37:05 +0200 X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Subject: [NSIS] NSIS Agenda for IETF-69 X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: nsis-chairs@tools.ietf.org List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1722388245==" Errors-To: nsis-bounces@ietf.org --===============1722388245== Content-Type: multipart/alternative; boundary=Apple-Mail-3--507920925 --Apple-Mail-3--507920925 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hi all, If you are interested in having a slot at the NSIS meeting at the IETF, please send the following information to nsis- chairs@tools.ietf.org: Draft name Presenter's name Time slot needed. 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-3--507920925 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1
Hi = all,

If you are interested in having a slot at the NSIS = meeting at the IETF, please send the following information to nsis-chairs@tools.ietf.org:=

Draft name
Presenter's = name
Time slot needed.


=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-3--507920925-- --===============1722388245== 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 --===============1722388245==-- From nsis-bounces@ietf.org Mon Jun 18 05:30: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 1I0DYs-0003Ii-66; Mon, 18 Jun 2007 05:30:14 -0400 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1I0DYq-0003C8-6c for nsis-confirm+ok@megatron.ietf.org; Mon, 18 Jun 2007 05:30:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0DYp-0003C0-Qe for nsis@ietf.org; Mon, 18 Jun 2007 05:30:11 -0400 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0DYo-0000Wc-TK for nsis@ietf.org; Mon, 18 Jun 2007 05:30:11 -0400 Received: from [10.1.1.109] (mito.netlab.nec.de [195.37.70.39]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 563B613CF81 for ; Mon, 18 Jun 2007 11:30:10 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v752.3) To: nsis Message-Id: <19BF534A-064A-4F09-BF98-5354F7D8C04B@netlab.nec.de> References: <4664AF0F.5080709@qualcomm.com> From: Martin Stiemerling Date: Mon, 18 Jun 2007 11:30:09 +0200 X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 919b3965bd46f7460d234f848680b238 Subject: [NSIS] Fwd: Nomcom 2007-8: First Call for Volunteers 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="===============0576723881==" Errors-To: nsis-bounces@ietf.org --===============0576723881== Content-Type: multipart/alternative; boundary=Apple-Mail-45--159137107 --Apple-Mail-45--159137107 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hi all, Just FYI for people interested in helping to select new ADs, IAB and IAOC members. Martin Anfang der weitergeleiteten E-Mail: > Von: Lakshminath Dondeti > Datum: 5. Juni 2007 02:32:15 MESZ > An: ietf-announce@ietf.org > Betreff: Nomcom 2007-8: First Call for Volunteers > > Folks, > > If you have attended 3 out of the past 5 IETF meetings, you are > eligible > to serve on Nomcom 2007-2008. Please volunteer and you may become one > of the voting members of the committee that selects about half of the > members to the IESG and IAB and one IAOC member. RFC 3777 > describes the > process and the responsibilities in detail. Below is the list of > people > from the IESG, IAB and IAOC whose terms end during the March 2008 IETF > meeting. > > IAOC: > > Ed Juskevicius > > IAB: > > Leslie Daigle > Elwyn Davies > Kevin Fall > Olaf Kolkman > David Oran > Eric Rescorla > > IESG: > > Lisa Dusseault -- Applications Area Director > Jari Arkko -- Internet Area Director > Dan Romascanu -- Operations and Management Area Director > Cullen Jennings -- Real-time Applications and Infrastructure Area > Director > Ross Callon --- Routing Area Director > Sam Hartman -- Security Area Director > Magnus Westerlund -- Transport Area Director > > Before volunteering, please think about whether you want to be > considered for one of those positions instead. If you are already > convinced, please send an email before 12:00 noon ET (16:00 UTC/ > GMT) on > July 5, 2007 (otherwise, please read on) > > To: ldondeti@qualcomm.com > Subject: Nomcom 2007-8 Volunteer > Body: > > // As you enter in the IETF Registration Form, > // First/Given name followed by Last/ > Family Name > // typically what goes in the Company > field > // in the IETF > Registration Form > [] > // > // For confirmation if selected > > Please expect an email response from me within 1-2 days stating > whether you are qualified or not. If you don't receive anything, > please > re-send your email with the tag (duplicate) in the subject line. > > Not convinced yet? Please consider that nomcom members play an > important role in shaping the leadership of the IETF. If you are a > people person, you will enjoy meeting many of the active > contributors to > the IETF. If you prefer instead to read a lot of email, well, we have > that too. Being a nomcom member is also an important > responsibility: it > requires adherence to confidentiality rules and some time commitment > from the members. The term begins just prior to the Chicago > meeting and > we expect most of the work to be completed by January 2008. During > this > period, the nomcom members > > -- collect requirements from the community and interviews candidates > during the Chicago and Vancouver IETF meetings > -- review candidates' statements and weighs community feedback > -- participate in candidate selection deliberations (weekly > conferences > calls) > > Nomcom members are selected following a publicly verifiable random > selection method specified in RFC 3797. > > For the nomcom to work as it should, the pool from which the > volunteers > are chosen should be as large as possible. The more people who > volunteer, the better chance we have of choosing a random yet > representative cross section of the IETF population. > > Ensuring the leadership of the IETF is fair and balanced and comprised > of those who can lead the IETF in the right direction is an important > responsibility that rests on the IETF participants at large. > Volunteering > for the nomcom is a good way of contributing in that direction. So > please volunteer! > > thanks, > Lakshminath > > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf-announce stiemerling@netlab.nec.de NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 --Apple-Mail-45--159137107 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Hi all,

Just FYI for people = interested in helping to select new ADs, IAB and IAOC = members.=A0

=A0= Martin

Anfang der weitergeleiteten E-Mail:

Von: = Lakshminath Dondeti <ldondeti@qualcomm.com>=
Datum: 5. Juni 2007 02:32:15 = MESZ
An: ietf-announce@ietf.org
Betreff: Nomcom 2007-8: First Call for = Volunteers
Folks,

If you = have attended 3 out of the past 5 IETF meetings, you are = eligible
to serve on Nomcom = 2007-2008.=A0 Please = volunteer and you may become one
of the voting = members of the committee that selects about half of the
members to the IESG and IAB and one IAOC = member.=A0 RFC 3777 = describes the
process and the responsibilities = in detail.=A0 Below is the = list of people
from the IESG, IAB and IAOC = whose terms end during the March 2008 IETF

IAOC:

Ed Juskevicius


Leslie Daigle
Elwyn = Davies
Kevin Fall
Olaf Kolkman
David = Oran
Eric Rescorla


Lisa Dusseault -- Applications Area = Director
Jari Arkko -- Internet Area = Director
Dan Romascanu -- Operations and = Management Area Director
Cullen = Jennings -- Real-time Applications and Infrastructure Area = Director
Ross Callon --- Routing Area = Director
Sam Hartman -- Security Area = Director
Magnus Westerlund -- Transport = Area Director

Before volunteering, please think about whether you = want to be
considered for one of those = positions instead.=A0 If = you are already
convinced, please send an email = before 12:00 noon ET (16:00 UTC/GMT) on
July 5, = 2007 (otherwise, please read on)

Subject: Nomcom 2007-8 Volunteer
Body:

<Your Full Name> =A0 // As you enter in the IETF = Registration Form,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 // First/Given name followed by Last/Family = Name
<Current Primary = Affiliation> // typically what goes in the Company field
=A0=A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = //=A0 in the IETF = Registration Form
[<all email addresses used to = Register for the past 5 IETF meetings>]
=A0= //
<Telephone number> =A0 =A0 =A0 =A0 // For = confirmation if selected

Please expect an email response = from me within 1-2 days stating
whether you = are qualified or not.=A0 If = you don't receive anything, please
re-send your = email with the tag (duplicate) in the subject line.

Not = convinced yet?=A0 Please = consider that nomcom members play an
important = role in shaping the leadership of the IETF.=A0 If you are a
people person, you will enjoy meeting many of the = active contributors to
the IETF.=A0 If you prefer instead to read = a lot of email, well, we have
that = too.=A0 Being a nomcom = member is also an important responsibility: it
requires adherence to confidentiality rules and some = time commitment
from the members.=A0 The term begins just prior to = the Chicago meeting and
we expect = most of the work to be completed by January 2008.=A0 During this
period, the nomcom members

-- = collect requirements from the community and interviews = candidates
=A0 =A0 during the Chicago and = Vancouver IETF meetings
-- review = candidates' statements and weighs community feedback
-- participate in candidate selection deliberations = (weekly conferences
calls)

Nomcom = members are selected following a publicly verifiable random
selection method specified in RFC 3797.

For the = nomcom to work as it should, the pool from which the = volunteers
are chosen should be as large as = possible. The more people who
volunteer, = the better chance we have of choosing a random yet
representative cross section of the IETF = population.

Ensuring the leadership of the IETF is fair and = balanced and comprised
of those who can lead the = IETF in the right direction is an important
=A0 Volunteering
for the nomcom is a good way of contributing in that = direction.=A0 So
please volunteer!

Lakshminath


IETF-Announce mailing list
https://www1= .ietf.org/mailman/listinfo/ietf-announce
=

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

=

= --Apple-Mail-45--159137107-- --===============0576723881== 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 --===============0576723881==-- From nsis-bounces@ietf.org Mon Jun 18 05:36: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 1I0Df3-0004TK-GE; Mon, 18 Jun 2007 05:36:37 -0400 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1I0Df1-0004RP-Sz for nsis-confirm+ok@megatron.ietf.org; Mon, 18 Jun 2007 05:36:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0Df1-0004RH-C4 for nsis@ietf.org; Mon, 18 Jun 2007 05:36:35 -0400 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0Df0-0002Jx-5t for nsis@ietf.org; Mon, 18 Jun 2007 05:36:35 -0400 Received: from [10.1.1.109] (mito.netlab.nec.de [195.37.70.39]) by kyoto.netlab.nec.de (Postfix) with ESMTP id B99F413CF81 for ; Mon, 18 Jun 2007 11:36:33 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v752.3) To: nsis Message-Id: References: <457D2357.3060503@ericsson.com> From: Martin Stiemerling Date: Mon, 18 Jun 2007 11:36:32 +0200 X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: ff67cea9f7df2d77f61a364cea0926e8 Subject: [NSIS] Pending issue secdir review of draft-ietf-nsis-nslp-natfw-13.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: , Content-Type: multipart/mixed; boundary="===============1060202021==" Errors-To: nsis-bounces@ietf.org --===============1060202021== Content-Type: multipart/alternative; boundary=Apple-Mail-50--158753487 --Apple-Mail-50--158753487 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hi all, We still have the pending issue of handling the sec dir review of the NATFW NSLP form last December. My current intention is too follow the guidance and to rework the whole security section to get it shorten and focussed on the real challenges of the NATFW NSLP. Any further thoughts or objections? Thanks, Martin (for all NATFW NSLP authors) Anfang der weitergeleiteten E-Mail: > Von: Magnus Westerlund > Datum: 11. Dezember 2006 10:22:31 MEZ > An: NSIS > Kopie: meadows@itd.nrl.navy.mil > Betreff: [NSIS] [Fwd: secdir review of draft-ietf-nsis-nslp- > natfw-13.txt] > > Hi NSIS > > Many thanks to Catherine Meadows (CC) who has done the Security > Directorate review attached. It was done on my and the WG chairs > request through the security ADs to help check the security details > of the document. It contains the normal boilerplate for document > that are in IESG review, but as you know this document isn't in > that step yet. I hope this can help improve the document. > > Cheers > > Magnus Westerlund > > IETF Transport Area Director & TSVWG Chair > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVA/A > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 8 4048287 > Torshamsgatan 23 | Fax +46 8 7575550 > S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > > Von: Catherine Meadows > Datum: 10. Dezember 2006 15:32:45 MEZ > An: iesg@ietf.org, secdir@mit.edu, nsis-chairs@tools.ietf.org, > stiemerling@netlab.nec.de, hannes.tschofenig@siemens.com, > elwynd@dial.pipex.com > Kopie: Catherine Meadows > Betreff: secdir review of draft-ietf-nsis-nslp-natfw-13.txt > > > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. > > This ID describes a protocol by which hosts may signal along the > path used > for transport of data packets the information necessary to configure > NATs and firewalls > according to the needs of the > application data flows. Not surprisingly, the use of this protocol > by unauthorized > hosts could cause major security problems. The security > considerations considerations section of this document describes > the problems in detail, > and outlines recommendations for solutions. These are to have > security mechanisms providing data origin authentication, replay > protection, integrity protection, and optional confidentiality > protection. According to this document, uch security > mechanisms can be provided for neighboring nodes > by using a mutually authenticated > transport layer secured connection and by relying on authorization > by the > neighboring NATFW NSLP entities, as well as randomly generated > (that is, > unpredictable) session IDs. > > For non-neighboring nodes (presumably, this means nodes that do not > share > a security association) some sort of authorization is still > necessary. The document > discusses the possibility of using authorization tokens for this, > and also provides > some recommendations for protecting them (e.g. protection against > tampering > and confidentiality to protect against replay). The document does not > go into detail about this, apparently because the usage of > authorization tokens > in NPLS is covered in another document (referenced in this ID). > > This security strategy looks plausible, but I found the > justification for it very hard to follow. It starts with a number > of possible attacks that an unauthorized host could perform using > NSLP. Almost all of these attacks can be prevented by providing > authorization (the exceptions are one or two denial of service > attacks), and recommendations for authorizations are accordingly > provided. However, there > are two cases in which such recommendations are lacking. In one of > these > (5.2.3, data sender behind a firewall), no reason is given for the > lack of a recommendation. In the other (5.8, misuse of unreleased > sessions), it is claimed > that this will be addressed by the NATFW NSLP. This last confused me; > isn't that the protocol that this document describes? > > The list of attacks appears to have grown up over a period of time > as the document went through its various iterations. In its > current form, the list is not very helpful, especially as the end > of the security considerations section, in which the actual > recommendations are made do not reference them explicitly. > Instead, there > are somewhat vague comments such as > Almost all security threats at the > NATFW NSLP layer can be prevented by using a mutually authenticated > Transport Layer secured connection and by relying on > authorization by > the neighboring NATFW NSLP entities. > It would have been helpful for the reader to know what is meant by > "almost all" > without having to go back through the entire list of attacks. > > I would suggest that the authors provide a tightened up, condensed > account of the > security threats against NSLP. There is no need to try to have an > exhaustive list > of attacks; indeed such a list will be of limited use since one can > never be certain that all the possibilities can be exhaustive. > Instead, it would be more helpful to described classes of threats, > with some illustrative examples. > > In the final section, where the recommendations for security > mechanisms are > made, you need to be explicit about the types of threats that are > addressed. > In particular, some characterization of the types of threats that > are and are not addressed by authentication and authorization of > neighboring nodes needs to be provided, > > > I am wondering if it would not be a good idea to have a separate ID > describing the security mechanisms that need to be used by this > protocol. > The WG already seems to be halfway there, since they are already > working > on an ID for authentication tokens. > > Catherine Meadows > Head, Formal Methods Section > Center for High Assurance Computer Systems > Code 5540 > Naval Research Laboratory > Washington, DC 20375 > phone: +1-202-767-3490 > fax: +1-202-404-7942 > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis stiemerling@netlab.nec.de NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 --Apple-Mail-50--158753487 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Hi all,

We still have the pending = issue of handling the sec dir review of the NATFW NSLP form last = December.=A0

My= current intention is too follow the guidance and to rework the whole = security section to get it shorten and focussed on the real challenges = of the NATFW NSLP.=A0

Any further thoughts or = objections?

Thanks,

=A0 Martin (for all NATFW = NSLP authors)

Anfang der weitergeleiteten = E-Mail:

Von: Magnus Westerlund <magnus.westerlund@ericsson.= com>
Datum: 11. Dezember 2006 10:22:31 = MEZ
An: NSIS <nsis@ietf.org>
Betreff: [NSIS] [Fwd: secdir review of = draft-ietf-nsis-nslp-natfw-13.txt]

Hi = NSIS

Many thanks to Catherine Meadows (CC) who has done = the Security Directorate review attached. It was done on my and the WG = chairs request through the security ADs to help check the security = details of the document. It contains the normal boilerplate for document = that are in IESG review, but as you know this document isn't in that = step yet. I hope this can help improve the document.


Magnus Westerlund

IETF = Transport Area Director & TSVWG Chair
Multimedia Technologies, Ericsson Research = EAB/TVA/A
Ericsson AB=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | = Phone +46 8 4048287
Torshamsgatan 23 =A0 =A0 =A0 =A0 =A0 | Fax =A0 +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.= com
Von: Catherine Meadows <meadows@itd.nrl.navy.mil><= /FONT>
Datum: 10. Dezember 2006 15:32:45 = MEZ
An: iesg@ietf.org, secdir@mit.edu, nsis-chairs@tools.ietf.org,= stiemerling@netlab.nec.de, = hannes.tschofenig@siemens.co= m, elwynd@dial.pipex.com
Kopie: Catherine Meadows <meadows@itd.nrl.navy.mil><= /FONT>
Betreff: secdir review of = draft-ietf-nsis-nslp-natfw-13.txt=A0


I have = reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being = processed by the
IESG.=A0 These comments were = written primarily for the benefit of the
security = area directors.=A0 Document editors and WG chairs should treat
these comments just like any other last call = comments.

This = ID describes a protocol by which hosts may signal along the path = used
for transport of data packets the information necessary = to configure
NATs and firewalls=A0
according to the = needs of the
application data flows.=A0 Not surprisingly, the = use of this protocol by unauthorized
hosts could cause major = security problems.=A0 The security considerations considerations section = of this document describes the problems in detail,
and = outlines recommendations for solutions.=A0 These are to = have
security mechanisms providing data origin authentication, = replay protection, integrity protection, and optional confidentiality = protection.=A0 According to this document, uch = security
mechanisms can be provided for neighboring = nodes
by using a mutually authenticated
transport = layer secured connection and by relying on authorization by = the
neighboring NATFW NSLP entities, as well as randomly = generated (that is,
unpredictable) session = IDs.

For non-neighboring nodes (presumably, = this means nodes that do not share
a security association) = some sort of authorization is still necessary.=A0 The = document
discusses the possibility of using authorization = tokens for this, and also provides
some recommendations for = protecting them (e.g. protection against tampering
and = confidentiality to protect against replay).=A0 The document does = not
go into detail about this, apparently because the usage of = authorization tokens
in NPLS is covered in another document = (referenced in this ID).

This security strategy = looks plausible, but I found the justification for it very hard to = follow.=A0 It starts with a number of possible attacks that an = unauthorized host could perform using NSLP.=A0 Almost all of these = attacks can be prevented by providing authorization (the exceptions are = one or two denial of service attacks), and recommendations for = authorizations are accordingly provided. =A0 However, = there
are two cases in which such recommendations are = lacking.=A0 In one of these
(5.2.3, data sender behind a = firewall), no reason is given for the lack of a recommendation.=A0 In = the other (5.8, misuse of unreleased sessions), it is = claimed
that this will be addressed by the NATFW NSLP.=A0 This = last confused me;
isn't that the protocol that this document = describes?

The list of attacks appears to have = grown up over a period of time as the document went through its various = iterations.=A0 In its current form, the list is not very helpful, = especially as the end of the security considerations section, in which = the actual recommendations are made do not reference them explicitly.=A0 = Instead, there
are somewhat vague comments such = as=A0
=A0=A0 Almost all security threats at the
=A0=A0= NATFW NSLP layer can be prevented by using a mutually = authenticated
=A0=A0 Transport Layer secured connection and by = relying on authorization by
=A0=A0 the neighboring NATFW NSLP = entities.
It would have been helpful for the reader to know = what is meant by "almost all"
without having to go back = through the entire list of attacks.

I would = suggest that the authors provide a tightened up, condensed account of = the=A0
security threats against NSLP.=A0 There is no need to = try to have an exhaustive list
of attacks; indeed such a list = will be of limited use since one can never be certain that all the = possibilities can be exhaustive.=A0 Instead, it would be more helpful to = described classes of threats, with some illustrative = examples.

In the final section, where the = recommendations for security mechanisms are
made, you need to = be explicit about the types of threats that are addressed.
In = particular,=A0 some characterization of the types of threats that are = and are not addressed by=A0authentication and authorization of = neighboring nodes needs to be provided,


I am wondering if it would = not be a good idea to have a separate ID
describing the = security mechanisms that need to be used by this protocol.
The = WG already seems to be halfway there, since they are already = working
on an ID for authentication tokens.

Catherine Meadows
Head, = Formal Methods Section
Center = for High Assurance Computer Systems
Code = 5540
Naval Research = Laboratory
Washington, DC = 20375
phone: = +1-202-767-3490
fax: = +1-202-404-7942

nsis mailing list

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

=

= --Apple-Mail-50--158753487-- --===============1060202021== 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 --===============1060202021==-- From nsis-bounces@ietf.org Mon Jun 18 07:50:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0FkH-00015p-Vv; Mon, 18 Jun 2007 07:50:09 -0400 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1I0FkH-00015i-DP for nsis-confirm+ok@megatron.ietf.org; Mon, 18 Jun 2007 07:50:09 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0FkH-00015X-0p for nsis@ietf.org; Mon, 18 Jun 2007 07:50:09 -0400 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I0FkE-0007U9-3Y for nsis@ietf.org; Mon, 18 Jun 2007 07:50:08 -0400 Received: from [10.1.1.109] (mito.netlab.nec.de [195.37.70.39]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 3522713CF81 for ; Mon, 18 Jun 2007 13:50:05 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v752.3) To: nsis Message-Id: <892AE2E7-643F-492D-8695-609C87BE7DC4@netlab.nec.de> References: <071568CA7B789D4AA170CEF8C9613B4FB11B80@daebe103.NOE.Nokia.com> From: Martin Stiemerling Date: Mon, 18 Jun 2007 13:50:04 +0200 X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 28dc73ba51024f450a593b05aa945739 Subject: [NSIS] Reminder WGLC:draft-ietf-nsis-qos-nslp-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: , Content-Type: multipart/mixed; boundary="===============0997230439==" Errors-To: nsis-bounces@ietf.org --===============0997230439== Content-Type: multipart/alternative; boundary=Apple-Mail-57--150742375 --Apple-Mail-57--150742375 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Dear all, 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. Thanks, Martin Anfang der weitergeleiteten E-Mail: > Von: > Datum: 12. Juni 2007 23:27:48 MESZ > An: > Betreff: [NSIS] WGLC:draft-ietf-nsis-qos-nslp-14.txt > > Jukka has updated the draft. We would like to start a 2 week > WGLC on the draft which will run through close of business on > June 25th. > > Please review the draft, and comment if you feel that this draft > is ready to be sent to the IESG. A simple mail saying that the > draft is ready for publication would be great. > > Of course, if you read the draft and find open issues, then please > send a summary of your issue with the current draft. > > thanks, > Martin and John > >> -----Original Message----- >> From: ext nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] >> Sent: 11 June, 2007 12:50 >> To: i-d-announce@ietf.org >> Cc: nsis@ietf.org >> Subject: [NSIS] I-D ACTION:draft-ietf-nsis-qos-nslp-14.txt >> >> A New Internet-Draft is available from the on-line >> Internet-Drafts directories. >> This draft is a work item of the Next Steps in Signaling >> Working Group of the IETF. >> >> Title : NSLP for Quality-of-Service Signaling >> Author(s) : J. Manner, et al. >> Filename : draft-ietf-nsis-qos-nslp-14.txt >> Pages : 97 >> Date : 2007-6-11 >> >> 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-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-qos-nslp-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-qos-nslp-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. >> > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis stiemerling@netlab.nec.de NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 --Apple-Mail-57--150742375 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Dear all,

Just to remind you about = the currently running WGLC for the QoS NSLP.
A simple mail = saying that the=A0draft is ready for publication would be = great.

Thanks,

=A0 = Martin

Anfang der weitergeleiteten E-Mail:

Datum: 12. Juni 2007 23:27:48 = MESZ
Betreff: = [NSIS] WGLC:draft-ietf-nsis-qos-nslp-14.txt=A0

Jukka = has updated the draft.=A0 = We would like to start a 2 week
WGLC on = the draft which will run through close of business on
June 25th.

Please review the draft, and = comment if you feel that this draft
is ready to = be sent to the IESG.=A0 A = simple mail saying that the
draft is = ready for publication would be great.

Of course, if = you read the draft and find open issues, then please
send a summary of your issue with the current = draft.

thanks,
Martin and = John=A0

-----Original = Message-----
From: ext nsis-bounces@ietf.org = [mailto:nsis-bounces@ietf.org]=A0
Sent: 11 June, 2007 12:50
Subject: [NSIS] I-D = ACTION:draft-ietf-nsis-qos-nslp-14.txt=A0

A New = Internet-Draft is available from the on-line=A0
This draft is = a work item of the Next Steps in Signaling=A0
Working = Group of the IETF.
Title : NSLP for Quality-of-Service = Signaling
Author(s) : J. = Manner, et al.
Filename : = draft-ietf-nsis-qos-nslp-14.txt
= Pages = = : 97
Date : 2007-6-11


This = specification describes the NSIS Signaling Layer Protocol = (NSLP)
=A0 for signaling QoS = reservations in the Internet.=A0 = It is in accordance
=A0 with the framework and = requirements developed in NSIS. =A0
Together = with
=A0 GIST, it provides = functionality similar to RSVP and extends it.=A0 The
=A0 QoS = NSLP is independent of the underlying QoS specification or
=A0 = architecture and provides support for different reservation = models.
=A0 It is simplified by the = elimination of support for multicast flows.
=A0 This specification explains = the overall protocol approach, design
=A0 decisions made and provides = examples.=A0 It specifies = object, message
=A0 formats and processing = rules.

A URL for this Internet-Draft is:

To remove yourself from the I-D Announcement list, = send a=A0
message to i-d-announce-request@ietf.or= g with the word=A0
=A0
to = change your subscription settings.

Internet-Drafts are also = available by anonymous FTP. Login=A0
with the = username "anonymous" and a password of your e-mail=A0
address. = After logging in, type "cd internet-drafts" and then=A0
"get = draft-ietf-nsis-qos-nslp-14.txt".

A list of Internet-Drafts = directories can be found in=A0
Internet-Drafts can also be = obtained by e-mail.
Send a message to:
In the body type:
"FILE = /internet-drafts/draft-ietf-nsis-qos-nslp-14.txt".


NOTE: The mail = server at ietf.org can return the document in
MIME-encoded form by using the = "mpack" utility.=A0 To use = this
feature, insert the command = "ENCODING mime" before the "FILE"
= command.=A0 To = decode the response(s), you will need "munpack" or
a MIME-compliant mail = reader.=A0 Different = MIME-compliant=A0
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=A0
reader implementation to automatically retrieve the = ASCII=A0
version of the Internet-Draft.



nsis mailing list

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

=

= --Apple-Mail-57--150742375-- --===============0997230439== 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 --===============0997230439==-- From nsis-bounces@ietf.org Mon Jun 18 11:20:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0J25-0001qJ-8p; Mon, 18 Jun 2007 11:20:45 -0400 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1I0J23-0001kS-O9 for nsis-confirm+ok@megatron.ietf.org; Mon, 18 Jun 2007 11:20:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0J23-0001kH-E3 for nsis@ietf.org; Mon, 18 Jun 2007 11:20:43 -0400 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0J22-0003SM-31 for nsis@ietf.org; Mon, 18 Jun 2007 11:20:43 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l5IFKZ5g023848; Mon, 18 Jun 2007 18:20:40 +0300 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 Jun 2007 18:20:26 +0300 Received: from daebe103.NOE.Nokia.com ([10.241.35.24]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 Jun 2007 10:19:54 -0500 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [NSIS] Pending issue secdir review ofdraft-ietf-nsis-nslp-natfw-13.txt Date: Mon, 18 Jun 2007 10:19:09 -0500 Message-ID: <071568CA7B789D4AA170CEF8C9613B4FB639D8@daebe103.NOE.Nokia.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] Pending issue secdir review ofdraft-ietf-nsis-nslp-natfw-13.txt Thread-Index: AcexjDE/XHJSOpDWRc6h1TWIBuEzSwAL8HUw References: <457D2357.3060503@ericsson.com> From: To: , X-OriginalArrivalTime: 18 Jun 2007 15:19:54.0774 (UTC) FILETIME=[1FBC2360:01C7B1BC] X-Nokia-AV: Clean X-Spam-Score: 0.3 (/) X-Scan-Signature: 87e958510a39f65fbeb5ae8b5e360e3b Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0594207052==" Errors-To: nsis-bounces@ietf.org This is a multi-part message in MIME format. --===============0594207052== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7B1BC.0510465B" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7B1BC.0510465B Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Martin, =20 When do you think you will be able to do this? I agree that this is the right thing to do. =20 John ________________________________ From: ext Martin Stiemerling [mailto:stiemerling@netlab.nec.de]=20 Sent: 18 June, 2007 02:37 To: nsis Subject: [NSIS] Pending issue secdir review ofdraft-ietf-nsis-nslp-natfw-13.txt =09 =09 Hi all,=20 We still have the pending issue of handling the sec dir review of the NATFW NSLP form last December.=20 My current intention is too follow the guidance and to rework the whole security section to get it shorten and focussed on the real challenges of the NATFW NSLP.=20 Any further thoughts or objections? Thanks, Martin (for all NATFW NSLP authors) =09 Anfang der weitergeleiteten E-Mail: Von: Magnus Westerlund Datum: 11. Dezember 2006 10:22:31 MEZ An: NSIS Kopie: meadows@itd.nrl.navy.mil Betreff: [NSIS] [Fwd: secdir review of draft-ietf-nsis-nslp-natfw-13.txt] Hi NSIS Many thanks to Catherine Meadows (CC) who has done the Security Directorate review attached. It was done on my and the WG chairs request through the security ADs to help check the security details of the document. It contains the normal boilerplate for document that are in IESG review, but as you know this document isn't in that step yet. I hope this can help improve the document. Cheers Magnus Westerlund IETF Transport Area Director & TSVWG Chair =09 ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVA/A =09 ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com =09 ---------------------------------------------------------------------- =09 =09 Von: Catherine Meadows Datum: 10. Dezember 2006 15:32:45 MEZ An: iesg@ietf.org, secdir@mit.edu, nsis-chairs@tools.ietf.org, stiemerling@netlab.nec.de, hannes.tschofenig@siemens.com, elwynd@dial.pipex.com Kopie: Catherine Meadows Betreff: secdir review of draft-ietf-nsis-nslp-natfw-13.txt=20 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This ID describes a protocol by which hosts may signal along the path used for transport of data packets the information necessary to configure NATs and firewalls=20 according to the needs of the application data flows. Not surprisingly, the use of this protocol by unauthorized hosts could cause major security problems. The security considerations considerations section of this document describes the problems in detail, and outlines recommendations for solutions. These are to have security mechanisms providing data origin authentication, replay protection, integrity protection, and optional confidentiality protection. According to this document, uch security mechanisms can be provided for neighboring nodes by using a mutually authenticated transport layer secured connection and by relying on authorization by the neighboring NATFW NSLP entities, as well as randomly generated (that is, unpredictable) session IDs. For non-neighboring nodes (presumably, this means nodes that do not share a security association) some sort of authorization is still necessary. The document discusses the possibility of using authorization tokens for this, and also provides some recommendations for protecting them (e.g. protection against tampering and confidentiality to protect against replay). The document does not go into detail about this, apparently because the usage of authorization tokens in NPLS is covered in another document (referenced in this ID). This security strategy looks plausible, but I found the justification for it very hard to follow. It starts with a number of possible attacks that an unauthorized host could perform using NSLP. Almost all of these attacks can be prevented by providing authorization (the exceptions are one or two denial of service attacks), and recommendations for authorizations are accordingly provided. However, there are two cases in which such recommendations are lacking. In one of these (5.2.3, data sender behind a firewall), no reason is given for the lack of a recommendation. In the other (5.8, misuse of unreleased sessions), it is claimed that this will be addressed by the NATFW NSLP. This last confused me; isn't that the protocol that this document describes? The list of attacks appears to have grown up over a period of time as the document went through its various iterations. In its current form, the list is not very helpful, especially as the end of the security considerations section, in which the actual recommendations are made do not reference them explicitly. Instead, there are somewhat vague comments such as=20 Almost all security threats at the NATFW NSLP layer can be prevented by using a mutually authenticated Transport Layer secured connection and by relying on authorization by the neighboring NATFW NSLP entities. It would have been helpful for the reader to know what is meant by "almost all" without having to go back through the entire list of attacks. I would suggest that the authors provide a tightened up, condensed account of the=20 security threats against NSLP. There is no need to try to have an exhaustive list of attacks; indeed such a list will be of limited use since one can never be certain that all the possibilities can be exhaustive. Instead, it would be more helpful to described classes of threats, with some illustrative examples. In the final section, where the recommendations for security mechanisms are made, you need to be explicit about the types of threats that are addressed. In particular, some characterization of the types of threats that are and are not addressed by authentication and authorization of neighboring nodes needs to be provided, I am wondering if it would not be a good idea to have a separate ID describing the security mechanisms that need to be used by this protocol. The WG already seems to be halfway there, since they are already working on an ID for authentication tokens. Catherine Meadows Head, Formal Methods Section Center for High Assurance Computer Systems Code 5540 Naval Research Laboratory Washington, DC 20375 phone: +1-202-767-3490 fax: +1-202-404-7942 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis =09 stiemerling@netlab.nec.de NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 ------_=_NextPart_001_01C7B1BC.0510465B Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Martin,
 
When do you think you will be able to do this? = I agree that=20 this is the right thing to do.
 
John

From: ext Martin Stiemerling=20 [mailto:stiemerling@netlab.nec.de]
Sent: 18 June, 2007=20 02:37
To: nsis
Subject: [NSIS] Pending issue = secdir review=20 ofdraft-ietf-nsis-nslp-natfw-13.txt

Hi all,

We still have the pending issue of handling the sec dir review of = the=20 NATFW NSLP form last December. 

My current intention is too follow the guidance and to rework the = whole=20 security section to get it shorten and focussed on the real challenges = of the=20 NATFW NSLP. 

Any further thoughts or objections?

Thanks,

  Martin (for all NATFW NSLP authors)

Anfang der weitergeleiteten E-Mail:
Von: Magnus = Westerlund <magnus.westerlund@ericsson= .com>
Datum: 11. = Dezember 2006=20 10:22:31 MEZ
An: NSIS <nsis@ietf.org>
Kopie: meadows@itd.nrl.navy.mil
Betreff: = [NSIS] = [Fwd: secdir=20 review of draft-ietf-nsis-nslp-natfw-13.txt]

Hi NSIS

Many thanks to Catherine Meadows (CC) who = has done=20 the Security Directorate review attached. It was done on my and the = WG=20 chairs request through the security ADs to help check the security = details=20 of the document. It contains the normal boilerplate for document = that are in=20 IESG review, but as you know this document isn't in that step yet. I = hope=20 this can help improve the document.

Cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG=20 Chair
--------------------------------------------------------------------= --
Multimedia Technologies, Ericsson = Research=20 EAB/TVA/A
--------------------------------------------------------------------= --
Ericsson AB =20               | Phone +46 = 8=20 4048287
Torshamsgatan 23           = | Fax=20   +46 8 = 7575550
S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson= .com
--------------------------------------------------------------------= --

Von: Catherine Meadows <meadows@itd.nrl.navy.mil>=
Datum: 10. Dezember 2006 15:32:45 = MEZ
An: iesg@ietf.org, secdir@mit.edu, nsis-chairs@tools.ietf.org= , stiemerling@netlab.nec.de, = hannes.tschofenig@siemens.c= om,=20 elwynd@dial.pipex.com
Kopie: Catherine Meadows <meadows@itd.nrl.navy.mil>=
Betreff: secdir review of=20 draft-ietf-nsis-nslp-natfw-13.txt 


I have reviewed this document as part of = the=20 security directorate's
ongoing effort to review all IETF = documents being=20 processed by the
IESG.  These comments were written = primarily=20 for the benefit of the
security area directors.  Document = editors and=20 WG chairs should treat
these comments just like any other last = call=20 comments.

This ID describes a protocol by which hosts may signal along = the path=20 used
for transport of data packets the information necessary to=20 configure
NATs and firewalls 
according to the needs of the
application data flows.  Not surprisingly, the use of this = protocol by unauthorized
hosts could cause major security problems.  The security=20 considerations considerations section of this document describes the = problems in detail,
and outlines recommendations for solutions.  These are to=20 have
security mechanisms providing data origin authentication, = replay=20 protection, integrity protection, and optional confidentiality=20 protection.  According to this document, uch security
mechanisms can be provided for neighboring nodes
by using a mutually authenticated
transport layer secured connection and by relying on = authorization by=20 the
neighboring NATFW NSLP entities, as well as randomly generated = (that=20 is,
unpredictable) session IDs.

For non-neighboring nodes (presumably, this means nodes that do = not=20 share
a security association) some sort of authorization is still=20 necessary.  The document
discusses the possibility of using authorization tokens for = this, and=20 also provides
some recommendations for protecting them (e.g. protection = against=20 tampering
and confidentiality to protect against replay).  The = document does=20 not
go into detail about this, apparently because the usage of=20 authorization tokens
in NPLS is covered in another document (referenced in this = ID).

This security strategy looks plausible, but I found the = justification=20 for it very hard to follow.  It starts with a number of = possible=20 attacks that an unauthorized host could perform using NSLP.  = Almost all=20 of these attacks can be prevented by providing authorization (the = exceptions=20 are one or two denial of service attacks), and recommendations for=20 authorizations are accordingly provided.   However, there
are two cases in which such recommendations are lacking.  = In one=20 of these
(5.2.3, data sender behind a firewall), no reason is given for = the lack=20 of a recommendation.  In the other (5.8, misuse of unreleased=20 sessions), it is claimed
that this will be addressed by the NATFW NSLP.  This last = confused=20 me;
isn't that the protocol that this document describes?

The list of attacks appears to have grown up over a period of = time as=20 the document went through its various iterations.  In its = current form,=20 the list is not very helpful, especially as the end of the security=20 considerations section, in which the actual recommendations are made = do not=20 reference them explicitly.  Instead, there
are somewhat vague comments such as 
   Almost all security threats at the
   NATFW NSLP layer can be prevented by using a = mutually=20 authenticated
   Transport Layer secured connection and by relying = on=20 authorization by
   the neighboring NATFW NSLP entities.
It would have been helpful for the reader to know what is meant = by=20 "almost all"
without having to go back through the entire list of = attacks.

I would suggest that the authors provide a tightened up, = condensed=20 account of the 
security threats against NSLP.  There is no need to try to = have an=20 exhaustive list
of attacks; indeed such a list will be of limited use since one = can=20 never be certain that all the possibilities can be exhaustive.  = Instead, it would be more helpful to described classes of threats, = with some=20 illustrative examples.

In the final section, where the recommendations for security = mechanisms=20 are
made, you need to be explicit about the types of threats that = are=20 addressed.
In particular,  some characterization of the types of = threats that=20 are and are not addressed by authentication and authorization = of=20 neighboring nodes needs to be provided,


I am wondering if it would not be a good idea to have a = separate=20 ID
describing the security mechanisms that need to be used by this = protocol.
The WG already seems to be halfway there, since they are = already=20 working
on an ID for authentication tokens.

Catherine Meadows
Head, Formal Methods Section
Center for High Assurance Computer Systems
Code 5540
Naval Research Laboratory
Washington, DC 20375
phone: +1-202-767-3490
fax: +1-202-404-7942

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

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

------_=_NextPart_001_01C7B1BC.0510465B-- --===============0594207052== 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 --===============0594207052==-- From nsis-bounces@ietf.org Mon Jun 18 19:47: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 1I0QwM-00059y-91; Mon, 18 Jun 2007 19:47:22 -0400 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1I0QwK-000550-Lr for nsis-confirm+ok@megatron.ietf.org; Mon, 18 Jun 2007 19:47:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0QwK-00054s-CC for nsis@ietf.org; Mon, 18 Jun 2007 19:47:20 -0400 Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0QwI-0003rG-GY for nsis@ietf.org; Mon, 18 Jun 2007 19:47:20 -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 1I0QwF-0003Z2-8a; Tue, 19 Jun 2007 01:47:17 +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 163162FC1F2; Tue, 19 Jun 2007 01:47:15 +0200 (CEST) Received: from localhost ([127.0.0.1]) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.44) id 1I0QwE-00040Z-CN; Tue, 19 Jun 2007 01:47:14 +0200 Message-ID: <46771981.60907@tm.uka.de> Date: Tue, 19 Jun 2007 01:47:13 +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: "nsis@ietf.org" , nsis-chairs@tools.ietf.org X-Enigmail-Version: 0.94.1.1 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 8bit 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: 9af087f15dbdd4c64ae6bbcdbc5b1d44 Cc: Subject: [NSIS] NSIS Interop Summary Report from Karlsruhe X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi all, the WG chairs solicited feedback about the latest NSIS interop in Karlsruhe. So here it is (sorry for the long delay): Overview: ========= * Implementation teams: - University of Coimbra (GIST, QoS NSLP, NAT/FW) each Draft -13 - Uni Goettingen (GIST, QoS NSLP, NAT/FW) each Draft-13 - Uni Karlsruhe (GIST, QoS NSLP, NAT/FW) each Draft-13 - Siemens Roke Manor Research was planned to participate but could not make it. * We mainly concentrated on GIST tests, because this spec has to be off the table first. * We used test cases that were defined by Christian Dickmann (and discussed at last IETF among Christian, Alan Ford, Andrew McDonald and partially me). You can find the document here (though in a format of an internet-draft, it is not published as such yet) http://user.informatik.uni-goettingen.de/~cdickman/draft-dickmann-nsis-ntlp-interop-00.txt * Christian did a great job in setting up tools for performing automated tests. This sped up testing a lot. * GIST was quite thoroughly tested with Goettingen vs. Karlsruhe (in both directions, see below). We tested all the main protocol features like D-Mode, C-Mode, TLS+TCP, v4,v6, late state installation, etc. * The GIST Spec is implementable; we found no major issues with the GIST spec, only the need for some clarifications that can be found here in our tracker: https://projekte.tm.uka.de/trac/NSIS/report/10 (I entered some additional tickets after the interop event). * A major open issue is, however, NAT traversal functionality that could not be tested yet. * Interop URL: https://projekte.tm.uka.de/trac/NSIS/wiki/Interop-20070509 Details (as written in a mail from Christian) ================================================= Christian created a report based on the data collected by the Interop Tools. Take a look at: http://dickmann.homeunix.org/nsis/displayReportList.php --------------------------------------------------------------------- Christian's mail: Of course, this is only a subset of all tests that were made (and only the last run of each test case), but I guess we are close to 90 or 95% coverage. A lot of test cases come with captures so that you can look up the message exchange for successful or failed tests. I set the success-flag for most tests directly during the interop event once the test was completed. However, for some test cases I set the flag today based on my notes (and my memory). As you know the test cases were based on [1]. Each test case belongs into one of these categories: "normal operation", "recoverable problems", "unrecoverable problems". I analyzed the report based on these categories (notation "X vs. Y" means X is Initiator and Y is Responder): Normal operation: Goettingen vs. Karlsruhe: 3-Way Handshake: 7 PASSED, 10 run of 11 test cases Refresh of soft state: 2 PASSED, 2 run of 5 test cases Setup of multiple sessions: 3 PASSED, 3 run of 4 test cases Interception on NSIS forwarders: 3 PASSED, 4 run of 4 test cases GIST Stateless operation: 0 PASSED, 1 run of 2 test cases Karlsruhe vs. Goettingen: 3-Way Handshake: 8 PASSED, 9 run of 11 test cases Refresh of soft state: 0 PASSED, 1 run of 5 test cases Goettingen vs. Coimbra: 3-Way Handshake: 8 PASSED, 9 run of 11 test cases Refresh of soft state: 2 PASSED, 2 run of 5 test cases Coimbra vs. Goettingen: 3-Way Handshake: 2 PASSED, 3 run of 11 test cases Karlsruhe vs. Coimbra: 3-Way Handshake: 5 PASSED, 5 run of 11 test cases Recoverable problems: Goettingen vs. Karlsruhe: 3-Way Handshake: 2 PASSED, 3 run of 3 test cases Refresh of soft state: 4 PASSED, 4 run of 5 test cases Karlsruhe vs. Goettingen: 3-Way Handshake: 1 PASSED, 1 run of 3 test cases Goettingen vs. Coimbra: 3-Way Handshake: 2 PASSED, 2 run of 3 test cases Refresh of soft state: 4 PASSED, 4 run of 5 test cases Unrecoverable problems: Goettingen vs. Karlsruhe: 3-Way Handshake: 5 PASSED, 5 run of 5 test cases Karlsruhe vs. Goettingen: 3-Way Handshake: 3 PASSED, 4 run of 5 test cases Goettingen vs. Coimbra: 3-Way Handshake: 4 PASSED, 5 run of 5 test cases As we can see, we did not test all test cases, even for Goettingen vs. Karlsruhe. However, for Goe vs. Ka we can say that we covered a really good part of the GIST specification. In particular we tested all important features (except for NAT traversal and Stateless mode). This makes me very confident that the spec is implementable (except for NAT traversal, see NSIS mailing list). I think we tested Goettingen against Karlsruhe quite thoroughly (in both directions). We ran 47 test cases (IPv4 only) and passed 38 of these. That's a success rate of 80%. The tests against Coimbra were not as complete. We ran 25 test cases (IPv4 only) between Göttingen and Coimbra and passed 22 of them (= 88%). Thus, the test cases we tested were quite successful, but we ran only half of the test cases compared to Goe/Ka. Also note that we did only very few test cases with IPv6 and only with Göttingen vs. Karlsruhe. However, those were all successful. My personal lessons learned from this interop: - Even 3 days were not enough. Considering that we only had 3 GIST implementations to test, this sounds like we wasted too much time. I try to find reasons below. - I guess 70% of the problems we found between Göttingen and Karlsruhe were NOT related to interop problems. On the other hand, all bugs found in our (Göttingen) implementation (very few overall) were related to real interop issues. I guess the reason is quite simple: I ran ALL test cases defined in [1] with Göttingen vs. Göttingen and so found and fixed a lot of bugs before arriving in Karlsruhe. I suppose the other participants did not do internal tests as thorough as ours, which resulted in this rate of non-interop issues. - More internal tests (see above) but also remote tests before the actual interop event can save a lot of time. I did some remote tests with Karlsruhe and we were able to detect and fix some problems before meeting in person. With Coimbra I also performed some remote tests (just basic D-Mode and C-Mode, both failed), but not as thorough as with Karlsruhe. We ended up having problems with TLS for many hours during the interop event. We should do much more remote testing to avoid these lengthy debugging phases! - The interop draft [1] helped a lot. First, it has so many test cases that you would not think of during an interop event. Second, for complex tests the expected behavior and useful triggers are not always obvious. Having them written down with one or two rounds of review saves time and avoids mistakes during the interop event. Third, the interop draft now helps to write this report, as we can "measure" the success. - The interop tools helped a lot and saved a lot of time. I guess the tools saved roughly 50% of my time. Maybe even more. Considering that we are very short on time, this is a huge improvement. Besides that, many test cases are simply not feasible without tools (for example attack scenarios, corrupted objects, etc.). We should continue to use the tools and extend them so that they can become the default tool to do the interop. That would also help in remote testing. - The organization by Roland was very good. We had enough switches, cables, spare machines, space, etc. The network setup we discussed on this mailing list a week before the interop was well set up and avoided long setup and re-plugging phases. You can see that this is important when you look at Luis and Vitor who tried to configure their network on site to correspond to the network layout. It took them quite a while of debugging to configure their machines correctly. More preparation from all sides and an agreed-upon network setup help to avoid these kinds of delay. - Taking all these issues into account, I think that 3 days CAN be enough time, if and only if enough preparation is done in form of defining test cases, writing tools to help with testing, testing internally against the test cases, doing remote tests and organizing and preparing for the event itself. Overall I am quite satisfied with the interop. I think we made a big step ahead towards mature and interoperable implementations. We tested and discussed a good portion of the spec and found no (or very few and minor) real problems. And we tested quite a lot of test cases and had a reasonable success rate that is even going to improve with remote tests taking place in the next few weeks. Thank you all. I had a great time at the interop and special thanks go to Roland and the University of Karlsruhe for doing a very good job of hosting this interop event. Regards, Christian Dickmann [1] http://user.informatik.uni-goettingen.de/~cdickman/draft-dickmann-nsis-ntlp-interop-00.txt -------------------------------------------------------------------- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Jun 19 03:24:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0Y4v-0000tY-Qj; Tue, 19 Jun 2007 03:24:41 -0400 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1I0Y4u-0000s6-5G for nsis-confirm+ok@megatron.ietf.org; Tue, 19 Jun 2007 03:24:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0Y4t-0000ry-P8 for nsis@ietf.org; Tue, 19 Jun 2007 03:24:39 -0400 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0Y4s-0003HJ-12 for nsis@ietf.org; Tue, 19 Jun 2007 03:24:39 -0400 Received: from [10.1.1.109] (mito.netlab.nec.de [195.37.70.39]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 2056A13CF81; Tue, 19 Jun 2007 09:24:37 +0200 (CEST) In-Reply-To: <071568CA7B789D4AA170CEF8C9613B4FB639D8@daebe103.NOE.Nokia.com> References: <457D2357.3060503@ericsson.com> <071568CA7B789D4AA170CEF8C9613B4FB639D8@daebe103.NOE.Nokia.com> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <90F3A6F9-13F3-4763-9560-F339E10FB90F@netlab.nec.de> From: Martin Stiemerling Subject: Re: [NSIS] Pending issue secdir review ofdraft-ietf-nsis-nslp-natfw-13.txt Date: Tue, 19 Jun 2007 09:24:36 +0200 To: X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a0a5b57b7540919633bb8f7cd3cb4bd 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="===============1433678931==" Errors-To: nsis-bounces@ietf.org --===============1433678931== Content-Type: multipart/alternative; boundary=Apple-Mail-65--80270297 --Apple-Mail-65--80270297 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hi John, Yes I will be able to do this, I just want some feedback if the WG is fine with it. I also see this as the right approach, i.e., narrowing the security section down to the real issues that are still valid. Some of the issues are more less GIST issues which have been described in GIST itself. The current security section has grown over time, which is quite common for older drafts. Thanks, Martin Am 18.06.2007 um 17:19 schrieb : > Martin, > > When do you think you will be able to do this? I agree that this is > the > right thing to do. > > John > > > ________________________________ > > From: ext Martin Stiemerling [mailto:stiemerling@netlab.nec.de] > Sent: 18 June, 2007 02:37 > To: nsis > Subject: [NSIS] Pending issue secdir review > ofdraft-ietf-nsis-nslp-natfw-13.txt > > > Hi all, > > We still have the pending issue of handling the sec dir review > of the NATFW NSLP form last December. > > My current intention is too follow the guidance and to rework > the whole security section to get it shorten and focussed on the real > challenges of the NATFW NSLP. > > Any further thoughts or objections? > > Thanks, > > Martin (for all NATFW NSLP authors) > > > Anfang der weitergeleiteten E-Mail: > > > Von: Magnus Westerlund > Datum: 11. Dezember 2006 10:22:31 MEZ > An: NSIS > Kopie: meadows@itd.nrl.navy.mil > Betreff: [NSIS] [Fwd: secdir review of > draft-ietf-nsis-nslp-natfw-13.txt] > > Hi NSIS > > Many thanks to Catherine Meadows (CC) who has done the > Security Directorate review attached. It was done on my and the WG > chairs request through the security ADs to help check the security > details of the document. It contains the normal boilerplate for > document > that are in IESG review, but as you know this document isn't in that > step yet. I hope this can help improve the document. > > Cheers > > Magnus Westerlund > > IETF Transport Area Director & TSVWG Chair > > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVA/A > > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 8 4048287 > Torshamsgatan 23 | Fax +46 8 7575550 > S-164 80 Stockholm, Sweden | mailto: > magnus.westerlund@ericsson.com > > ---------------------------------------------------------------------- > > > Von: Catherine Meadows > Datum: 10. Dezember 2006 15:32:45 MEZ > An: iesg@ietf.org, secdir@mit.edu, > nsis-chairs@tools.ietf.org, stiemerling@netlab.nec.de, > hannes.tschofenig@siemens.com, elwynd@dial.pipex.com > Kopie: Catherine Meadows > Betreff: secdir review of > draft-ietf-nsis-nslp-natfw-13.txt > > > I have reviewed this document as part of the security > directorate's > ongoing effort to review all IETF documents being > processed by the > IESG. These comments were written primarily for the > benefit of the > security area directors. Document editors and WG chairs > should treat > these comments just like any other last call comments. > > This ID describes a protocol by which hosts may signal > along the path used > for transport of data packets the information necessary > to configure > NATs and firewalls > according to the needs of the > application data flows. Not surprisingly, the use of > this protocol by unauthorized > hosts could cause major security problems. The security > considerations considerations section of this document describes the > problems in detail, > and outlines recommendations for solutions. These are > to have > security mechanisms providing data origin > authentication, replay protection, integrity protection, and optional > confidentiality protection. According to this document, uch security > mechanisms can be provided for neighboring nodes > by using a mutually authenticated > transport layer secured connection and by relying on > authorization by the > neighboring NATFW NSLP entities, as well as randomly > generated (that is, > unpredictable) session IDs. > > For non-neighboring nodes (presumably, this means nodes > that do not share > a security association) some sort of authorization is > still necessary. The document > discusses the possibility of using authorization tokens > for this, and also provides > some recommendations for protecting them (e.g. > protection against tampering > and confidentiality to protect against replay). The > document does not > go into detail about this, apparently because the usage > of authorization tokens > in NPLS is covered in another document (referenced in > this ID). > > This security strategy looks plausible, but I found the > justification for it very hard to follow. It starts with a number of > possible attacks that an unauthorized host could perform using NSLP. > Almost all of these attacks can be prevented by providing > authorization > (the exceptions are one or two denial of service attacks), and > recommendations for authorizations are accordingly provided. > However, > there > are two cases in which such recommendations are lacking. > In one of these > (5.2.3, data sender behind a firewall), no reason is > given for the lack of a recommendation. In the other (5.8, misuse of > unreleased sessions), it is claimed > that this will be addressed by the NATFW NSLP. This > last confused me; > isn't that the protocol that this document describes? > > The list of attacks appears to have grown up over a > period of time as the document went through its various > iterations. In > its current form, the list is not very helpful, especially as the > end of > the security considerations section, in which the actual > recommendations > are made do not reference them explicitly. Instead, there > are somewhat vague comments such as > Almost all security threats at the > NATFW NSLP layer can be prevented by using a mutually > authenticated > Transport Layer secured connection and by relying on > authorization by > the neighboring NATFW NSLP entities. > It would have been helpful for the reader to know what > is meant by "almost all" > without having to go back through the entire list of > attacks. > > I would suggest that the authors provide a tightened up, > condensed account of the > security threats against NSLP. There is no need to try > to have an exhaustive list > of attacks; indeed such a list will be of limited use > since one can never be certain that all the possibilities can be > exhaustive. Instead, it would be more helpful to described classes of > threats, with some illustrative examples. > > In the final section, where the recommendations for > security mechanisms are > made, you need to be explicit about the types of threats > that are addressed. > In particular, some characterization of the types of > threats that are and are not addressed by authentication and > authorization of neighboring nodes needs to be provided, > > > I am wondering if it would not be a good idea to have a > separate ID > describing the security mechanisms that need to be used > by this protocol. > The WG already seems to be halfway there, since they are > already working > on an ID for authentication tokens. > > Catherine Meadows > Head, Formal Methods Section > Center for High Assurance Computer Systems > Code 5540 > Naval Research Laboratory > Washington, DC 20375 > phone: +1-202-767-3490 > fax: +1-202-404-7942 > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > > > > stiemerling@netlab.nec.de > NEC Europe Limited | Registered Office: NEC House, 1 Victoria > Road, London W3 6BL | Registered in England 2832014 > > > stiemerling@netlab.nec.de NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 --Apple-Mail-65--80270297 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Hi John,

Yes I will be able to do = this, I just want some feedback if the WG is fine with = it.=A0

I also = see this as the right approach, i.e., narrowing the security section = down to the real issues that are still valid. Some of the issues are = more less GIST issues which have been described in GIST = itself.

The = current security section has grown over time, which is quite=A0common = for older drafts.

Thanks,

=A0 = Martin

Am 18.06.2007 um 17:19 schrieb <john.loughney@nokia.com> = <john.loughney@nokia.com>:
Martin,

When do you think you will be = able to do this? I agree that this is the
right = thing to do.

John


________________________________

From: ext = Martin Stiemerling [mailto:stiemerling@netlab.nec.de= ]=A0
Sent: 18 June, 2007 = 02:37
To: nsis
Subject: [NSIS] Pending issue = secdir review


Hi = all,=A0

We still = have the pending issue of handling the sec dir review
of the NATFW NSLP form last December.=A0

My = current intention is too follow the guidance and to rework
the whole security section to get it shorten and = focussed on the real
challenges of the NATFW = NSLP.=A0

Any = further thoughts or objections?

Thanks,

=A0 Martin (for all NATFW NSLP = authors)

=


Anfang = der weitergeleiteten E-Mail:


Von: Magnus Westerlund <magnus.westerlund@ericsson.= com>
Datum: 11. Dezember 2006 10:22:31 = MEZ
An: NSIS <nsis@ietf.org>
Kopie: meadows@itd.nrl.navy.mil
Betreff: [NSIS] [Fwd: secdir = review of

Hi NSIS

Many = thanks to Catherine Meadows (CC) who has done the
Security Directorate review attached. It was done on = my and the WG
chairs request through the = security ADs to help check the security
details = of the document. It contains the normal boilerplate for = document
that are in IESG review, but as = you know this document isn't in that
step yet. I = hope this can help improve the document.

= Cheers

Magnus Westerlund

IETF = Transport Area Director & TSVWG Chair


Multimedia Technologies, Ericsson = Research EAB/TVA/A


Ericsson AB=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | = Phone +46 8 4048287
= Torshamsgatan 23 =A0 =A0 =A0 = =A0 =A0 | Fax =A0 = +46 8 7575550
S-164 80 = Stockholm, Sweden | mailto:

=

= =


Von: = Catherine Meadows <meadows@itd.nrl.navy.mil><= /DIV>
Datum: 10. Dezember 2006 15:32:45 = MEZ
nsis-chairs@tools.ietf.org,= stiemerling@netlab.nec.de,
Kopie: Catherine Meadows <meadows@itd.nrl.navy.mil><= /DIV>
Betreff: secdir review = of
draft-ietf-nsis-nslp-natfw-13.txt=A0


I have reviewed this document as = part of the security
directorate's
ongoing effort to review all IETF = documents being
processed by the
IESG.=A0 These comments were written = primarily for the
benefit of the
security area directors.=A0 Document editors and WG = chairs
should treat
these comments just like any = other last call comments.

This ID describes a protocol by = which hosts may signal
along the path = used
for transport of data packets the = information necessary
to configure
NATs and firewalls=A0
according = to the needs of the
= application data flows.=A0 = Not surprisingly, the use of
this protocol = by unauthorized
hosts could cause major security = problems.=A0 The = security
considerations considerations = section of this document describes the
problems = in detail,
and outlines recommendations for = solutions.=A0 These = are
to have
security mechanisms providing = data origin
authentication, replay = protection, integrity protection, and optional
confidentiality protection.=A0 According to this document, = uch security
mechanisms can be provided for = neighboring nodes
by using a mutually = authenticated
transport layer secured = connection and by relying on
authorization = by the
neighboring NATFW NSLP entities, = as well as randomly
generated (that = is,
unpredictable) session = IDs.

For non-neighboring nodes = (presumably, this means nodes
that do not = share
a security association) some sort = of authorization is
still necessary.=A0 The document
discusses the possibility of = using authorization tokens
for this, and = also provides
some recommendations for = protecting them (e.g.
protection against = tampering
and confidentiality to protect = against replay).=A0 = The
document does not
go into detail about this, = apparently because the usage
of = authorization tokens
in NPLS = is covered in another document (referenced in
this ID).

This security strategy looks = plausible, but I found the
justification = for it very hard to follow.=A0 = It starts with a number of
possible = attacks that an unauthorized host could perform using NSLP.
Almost all of these attacks can be prevented by = providing authorization
(the = exceptions are one or two denial of service attacks), and
recommendations for authorizations are accordingly = provided. =A0 = However,
there
are two cases in which such = recommendations are lacking.
In one of = these
(5.2.3, data sender behind a = firewall), no reason is
given for the = lack of a recommendation.=A0 = In the other (5.8, misuse of
unreleased = sessions), it is claimed
that this = will be addressed by the NATFW NSLP.=A0 This
last confused me;
isn't = that the protocol that this document describes?

The list = of attacks appears to have grown up over a
period = of time as the document went through its various iterations.=A0 In
its current form, the list is not very helpful, = especially as the end of
the security = considerations section, in which the actual recommendations
are made do not reference them explicitly.=A0 Instead, there
are somewhat vague comments such = as=A0
=A0 Almost all security threats = at the
=A0 NATFW NSLP layer can be = prevented by using a mutually
=A0 Transport Layer secured = connection and by relying on
authorization = by
=A0 the neighboring NATFW NSLP = entities.
It would have been helpful for = the reader to know what
is meant by = "almost all"
without having to go back through = the entire list of
attacks.

I would = suggest that the authors provide a tightened up,
condensed account of the=A0
security = threats against NSLP.=A0 = There is no need to try
to have an = exhaustive list
of attacks; indeed such a list = will be of limited use
since one can never be = certain that all the possibilities can be
=A0 Instead, = it would be more helpful to described classes of
threats, with some illustrative examples.

In the = final section, where the recommendations for
security mechanisms are
made, you = need to be explicit about the types of threats
that are addressed.
In = particular,=A0 some = characterization of the types of
threats that = are and are not addressed by authentication and
authorization of neighboring nodes needs to be = provided,


I am = wondering if it would not be a good idea to have a
separate ID
= describing the security mechanisms that need to be used
by this protocol.
The WG = already seems to be halfway there, since they are
already working
on an ID = for authentication tokens.

Catherine Meadows
Head, Formal Methods = Section
Center for High Assurance = Computer Systems
Code 5540
Naval Research = Laboratory
Washington, DC 20375
phone: +1-202-767-3490
fax: +1-202-404-7942

= _______________________________________________
nsis mailing list



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



=

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

=

= --Apple-Mail-65--80270297-- --===============1433678931== 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 --===============1433678931==-- From nsis-bounces@ietf.org Tue Jun 19 05:01: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 1I0Zak-0005gP-VH; Tue, 19 Jun 2007 05:01:38 -0400 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1I0Zaj-0005gA-Fz for nsis-confirm+ok@megatron.ietf.org; Tue, 19 Jun 2007 05:01:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0Zaj-0005fx-65 for nsis@ietf.org; Tue, 19 Jun 2007 05:01:37 -0400 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0ZaO-0004SL-H8 for nsis@ietf.org; Tue, 19 Jun 2007 05:01:37 -0400 Received: from [10.1.1.109] (mito.netlab.nec.de [195.37.70.39]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 0F2E513CF81 for ; Tue, 19 Jun 2007 11:01:16 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v752.3) To: nsis Message-Id: From: Martin Stiemerling Date: Tue, 19 Jun 2007 11:01:15 +0200 X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Subject: [NSIS] NSIS Session at 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="===============0586835377==" Errors-To: nsis-bounces@ietf.org --===============0586835377== Content-Type: multipart/alternative; boundary=Apple-Mail-2--74471229 --Apple-Mail-2--74471229 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hi all, Just to inform you in advance: Neither John nor me are going to be at the IETF-69 meeting in Chicago. However, there still will be an NSIS WG session and Jukka Manner is chairing it. I will be following the meeting remotely via Jabber, audio streams, and email, thus being available all time. Thanks to Jukka! Martin stiemerling@netlab.nec.de NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 --Apple-Mail-2--74471229 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Hi all,

Just to inform you in = advance: Neither John nor me are going to be at the IETF-69 meeting in = Chicago. However, there still will be an NSIS WG session and Jukka = Manner is chairing it.=A0

I will be following the = meeting remotely via Jabber, audio streams, and email, thus being = available all time.=A0

Thanks to = Jukka!

=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-2--74471229-- --===============0586835377== 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 --===============0586835377==-- From nsis-bounces@ietf.org Tue Jun 19 08:40: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 1I0d0g-0004V1-Ia; Tue, 19 Jun 2007 08:40:38 -0400 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1I0d0f-0004Uv-RO for nsis-confirm+ok@megatron.ietf.org; Tue, 19 Jun 2007 08:40:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0d0e-0004Un-VK for nsis@ietf.org; Tue, 19 Jun 2007 08:40:37 -0400 Received: from mx06.uni-tuebingen.de ([134.2.3.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0d0d-0004hu-6j for nsis@ietf.org; Tue, 19 Jun 2007 08:40:36 -0400 Received: from [127.0.0.1] (rouen.informatik.uni-tuebingen.de [134.2.11.152]) by mx06.uni-tuebingen.de (8.13.6/8.13.6) with ESMTP id l5JCeXTf026981; Tue, 19 Jun 2007 14:40:33 +0200 Message-ID: <4677CEC0.6080205@uni-tuebingen.de> Date: Tue, 19 Jun 2007 14:40:32 +0200 From: Ali Fessi User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Martin Stiemerling Subject: Re: [NSIS] Pending issue secdir review ofdraft-ietf-nsis-nslp-natfw-13.txt References: <457D2357.3060503@ericsson.com> <071568CA7B789D4AA170CEF8C9613B4FB639D8@daebe103.NOE.Nokia.com> <90F3A6F9-13F3-4763-9560-F339E10FB90F@netlab.nec.de> In-Reply-To: <90F3A6F9-13F3-4763-9560-F339E10FB90F@netlab.nec.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiVirus: checked by AntiVir MailGate (version: 2.1.2-11; AVE: 7.4.0.34; VDF: 6.39.0.33; host: mx06) X-Spam-Score: 0.0 (/) X-Scan-Signature: 453b1bfcf0292bffe4cab90ba115f503 Cc: "" , nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Martin, yes, I agree. The security section contains some text about security threats that is about 3 years old. It is necessary to update it. I can go through this section again when you are done with re-writing it. Cheers, Ali Martin Stiemerling wrote: > Hi John, > > Yes I will be able to do this, I just want some feedback if the WG is > fine with it. > > I also see this as the right approach, i.e., narrowing the security > section down to the real issues that are still valid. Some of the issues > are more less GIST issues which have been described in GIST itself. > > The current security section has grown over time, which is quite common > for older drafts. > > Thanks, > > Martin > > Am 18.06.2007 um 17:19 schrieb > >: > >> Martin, >> >> When do you think you will be able to do this? I agree that this is the >> right thing to do. >> >> John >> >> >> ________________________________ >> >> From: ext Martin Stiemerling [mailto:stiemerling@netlab.nec.de] >> Sent: 18 June, 2007 02:37 >> To: nsis >> Subject: [NSIS] Pending issue secdir review >> ofdraft-ietf-nsis-nslp-natfw-13.txt >> >> >> >> Hi all, >> >> We still have the pending issue of handling the sec dir review >> of the NATFW NSLP form last December. >> >> My current intention is too follow the guidance and to rework >> the whole security section to get it shorten and focussed on the real >> challenges of the NATFW NSLP. >> >> Any further thoughts or objections? >> >> Thanks, >> >> Martin (for all NATFW NSLP authors) >> >> >> >> Anfang der weitergeleiteten E-Mail: >> >> >> Von: Magnus Westerlund > > >> Datum: 11. Dezember 2006 10:22:31 MEZ >> An: NSIS > >> Kopie: meadows@itd.nrl.navy.mil >> Betreff: [NSIS] [Fwd: secdir review of >> draft-ietf-nsis-nslp-natfw-13.txt] >> >> Hi NSIS >> >> Many thanks to Catherine Meadows (CC) who has done the >> Security Directorate review attached. It was done on my and the WG >> chairs request through the security ADs to help check the security >> details of the document. It contains the normal boilerplate for document >> that are in IESG review, but as you know this document isn't in that >> step yet. I hope this can help improve the document. >> >> Cheers >> >> Magnus Westerlund >> >> IETF Transport Area Director & TSVWG Chair >> >> >> ---------------------------------------------------------------------- >> Multimedia Technologies, Ericsson Research EAB/TVA/A >> >> >> ---------------------------------------------------------------------- >> Ericsson AB | Phone +46 8 4048287 >> Torshamsgatan 23 | Fax +46 8 7575550 >> S-164 80 Stockholm, Sweden | mailto: >> magnus.westerlund@ericsson.com >> >> >> ---------------------------------------------------------------------- >> >> >> >> Von: Catherine Meadows > > >> Datum: 10. Dezember 2006 15:32:45 MEZ >> An: iesg@ietf.org , secdir@mit.edu >> , >> nsis-chairs@tools.ietf.org , >> stiemerling@netlab.nec.de , >> hannes.tschofenig@siemens.com , >> elwynd@dial.pipex.com >> Kopie: Catherine Meadows > > >> Betreff: secdir review of >> draft-ietf-nsis-nslp-natfw-13.txt >> >> >> I have reviewed this document as part of the security >> directorate's >> ongoing effort to review all IETF documents being >> processed by the >> IESG. These comments were written primarily for the >> benefit of the >> security area directors. Document editors and WG chairs >> should treat >> these comments just like any other last call comments. >> >> This ID describes a protocol by which hosts may signal >> along the path used >> for transport of data packets the information necessary >> to configure >> NATs and firewalls >> according to the needs of the >> application data flows. Not surprisingly, the use of >> this protocol by unauthorized >> hosts could cause major security problems. The security >> considerations considerations section of this document describes the >> problems in detail, >> and outlines recommendations for solutions. These are >> to have >> security mechanisms providing data origin >> authentication, replay protection, integrity protection, and optional >> confidentiality protection. According to this document, uch security >> mechanisms can be provided for neighboring nodes >> by using a mutually authenticated >> transport layer secured connection and by relying on >> authorization by the >> neighboring NATFW NSLP entities, as well as randomly >> generated (that is, >> unpredictable) session IDs. >> >> For non-neighboring nodes (presumably, this means nodes >> that do not share >> a security association) some sort of authorization is >> still necessary. The document >> discusses the possibility of using authorization tokens >> for this, and also provides >> some recommendations for protecting them (e.g. >> protection against tampering >> and confidentiality to protect against replay). The >> document does not >> go into detail about this, apparently because the usage >> of authorization tokens >> in NPLS is covered in another document (referenced in >> this ID). >> >> This security strategy looks plausible, but I found the >> justification for it very hard to follow. It starts with a number of >> possible attacks that an unauthorized host could perform using NSLP. >> Almost all of these attacks can be prevented by providing authorization >> (the exceptions are one or two denial of service attacks), and >> recommendations for authorizations are accordingly provided. However, >> there >> are two cases in which such recommendations are lacking. >> In one of these >> (5.2.3, data sender behind a firewall), no reason is >> given for the lack of a recommendation. In the other (5.8, misuse of >> unreleased sessions), it is claimed >> that this will be addressed by the NATFW NSLP. This >> last confused me; >> isn't that the protocol that this document describes? >> >> The list of attacks appears to have grown up over a >> period of time as the document went through its various iterations. In >> its current form, the list is not very helpful, especially as the end of >> the security considerations section, in which the actual recommendations >> are made do not reference them explicitly. Instead, there >> are somewhat vague comments such as >> Almost all security threats at the >> NATFW NSLP layer can be prevented by using a mutually >> authenticated >> Transport Layer secured connection and by relying on >> authorization by >> the neighboring NATFW NSLP entities. >> It would have been helpful for the reader to know what >> is meant by "almost all" >> without having to go back through the entire list of >> attacks. >> >> I would suggest that the authors provide a tightened up, >> condensed account of the >> security threats against NSLP. There is no need to try >> to have an exhaustive list >> of attacks; indeed such a list will be of limited use >> since one can never be certain that all the possibilities can be >> exhaustive. Instead, it would be more helpful to described classes of >> threats, with some illustrative examples. >> >> In the final section, where the recommendations for >> security mechanisms are >> made, you need to be explicit about the types of threats >> that are addressed. >> In particular, some characterization of the types of >> threats that are and are not addressed by authentication and >> authorization of neighboring nodes needs to be provided, >> >> >> I am wondering if it would not be a good idea to have a >> separate ID >> describing the security mechanisms that need to be used >> by this protocol. >> The WG already seems to be halfway there, since they are >> already working >> on an ID for authentication tokens. >> >> Catherine Meadows >> Head, Formal Methods Section >> Center for High Assurance Computer Systems >> Code 5540 >> Naval Research Laboratory >> Washington, DC 20375 >> phone: +1-202-767-3490 >> fax: +1-202-404-7942 >> >> _______________________________________________ >> nsis mailing list >> nsis@ietf.org >> https://www1.ietf.org/mailman/listinfo/nsis >> >> >> >> stiemerling@netlab.nec.de >> NEC Europe Limited | Registered Office: NEC House, 1 Victoria >> Road, London W3 6BL | Registered in England 2832014 >> >> >> > > stiemerling@netlab.nec.de > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, > London W3 6BL | Registered in England 2832014 > > > > ------------------------------------------------------------------------ > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis -- Ali Fessi Computer Networks and Internet University of Tuebingen, Germany Phone: +49 7071 29-70576 / Fax: +49 7071 29-5220 EMail: ali.fessi@uni-tuebingen.de Web: http://net.informatik.uni-tuebingen.de/~fessi/ _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Jun 20 05:01:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0w4W-0006pz-3L; Wed, 20 Jun 2007 05:01:52 -0400 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1I0w4U-0006os-Gv for nsis-confirm+ok@megatron.ietf.org; Wed, 20 Jun 2007 05:01:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0w4U-0006mn-3h for nsis@ietf.org; Wed, 20 Jun 2007 05:01:50 -0400 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0w4S-0003ku-B6 for nsis@ietf.org; Wed, 20 Jun 2007 05:01:50 -0400 Received: from [192.168.253.53] (unknown [195.37.70.252]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 7F81A13CF81 for ; Wed, 20 Jun 2007 11:01:47 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v752.3) To: nsis Message-Id: <44CA2310-0A0A-4F9F-B5D2-8A66EF6D51FB@netlab.nec.de> References: <36863C4B-B69B-4073-951A-46E75BFB5D53@netlab.nec.de> From: Martin Stiemerling Subject: Fwd: [NSIS] NSIS Agenda for IETF-69 Date: Wed, 20 Jun 2007 11:01:45 +0200 X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 1449ead51a2ff026dcb23465f5379250 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="===============1480348006==" Errors-To: nsis-bounces@ietf.org --===============1480348006== Content-Type: multipart/alternative; boundary=Apple-Mail-31-11959289 --Apple-Mail-31-11959289 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hi all, Just a friendly reminder to send your agenda requests. I have received some until now, but only one or two for WG items... Please send your agenda requests until Monday, June 25th, COB PST. Thanks, Martin Anfang der weitergeleiteten E-Mail: > Von: Martin Stiemerling > Datum: 14. Juni 2007 10:37:05 MESZ > An: nsis > Betreff: [NSIS] NSIS Agenda for IETF-69 > Antwort an: nsis-chairs@tools.ietf.org > > Hi all, > > If you are interested in having a slot at the NSIS meeting at the > IETF, please send the following information to nsis- > chairs@tools.ietf.org: > > Draft name > Presenter's name > Time slot needed. > > Thanks, > > Martin > > > stiemerling@netlab.nec.de > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, > London W3 6BL | Registered in England 2832014 > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis stiemerling@netlab.nec.de NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 --Apple-Mail-31-11959289 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Hi all,

Just a friendly reminder to = send your agenda requests. I have received some until now, but only one = or two for WG items...

Please send your agenda = requests until Monday, June 25th, COB PST.

Thanks,

=A0 = Martin

Anfang der weitergeleiteten E-Mail:

Von: = Martin Stiemerling <stiemerling@netlab.nec.de>= ;
Datum: 14. Juni 2007 10:37:05 = MESZ
An: nsis <nsis@ietf.org>
Betreff: = [NSIS] NSIS Agenda for IETF-69
Antwort an: = nsis-chairs@tools.ietf.org<= /FONT>

=
Hi all,

If you are interested in having = a slot at the NSIS meeting at the IETF, please send the following = information to nsis-chairs@tools.ietf.org:=

Draft name
Presenter's = name
Time slot needed.


=A0 = Martin


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


nsis mailing list

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

=

= --Apple-Mail-31-11959289-- --===============1480348006== 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 --===============1480348006==-- From nsis-bounces@ietf.org Thu Jun 21 15:50:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1Sg7-0005M4-TI; Thu, 21 Jun 2007 15:50:51 -0400 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1I1SfN-0003dt-7I for nsis-confirm+ok@megatron.ietf.org; Thu, 21 Jun 2007 15:50:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1SfM-0003dk-Nl; Thu, 21 Jun 2007 15:50:04 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1SfL-0001aS-Eh; Thu, 21 Jun 2007 15:50:04 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 0D32A26EA3; Thu, 21 Jun 2007 19:50:03 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1I1SfK-0000tP-HE; Thu, 21 Jun 2007 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 21 Jun 2007 15:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: nsis@ietf.org Subject: [NSIS] I-D ACTION:draft-ietf-nsis-rmd-10.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 : RMD-QOSM - The Resource Management in Diffserv QOS Model Author(s) : A. Bader, et al. Filename : draft-ietf-nsis-rmd-10.txt Pages : 95 Date : 2007-6-21 This document describes an NSIS QoS Model for networks that use the Resource Management in Diffserv (RMD) concept. RMD is a technique for adding admission control and pre-emption function to Differentiated Services (Diffserv) networks. The RMD QoS Model allows devices external to the RMD network to signal reservation requests to edge nodes in the RMD network. The RMD Ingress edge nodes classify the incoming flows into traffic classes and signals resource requests for the corresponding traffic class along the data path to the Egress edge nodes for each flow. Egress nodes reconstitute the original requests and continue forwarding them along the data path towards the final destination. In addition, RMD defines notification functions to indicate overload situations within the domain to the edge nodes. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nsis-rmd-10.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-rmd-10.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-rmd-10.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-6-21130622.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nsis-rmd-10.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nsis-rmd-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-6-21130622.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 Sat Jun 23 14:48: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 1I2Af6-0008Su-7f; Sat, 23 Jun 2007 14:48:44 -0400 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1I2Af5-0008Qu-23 for nsis-confirm+ok@megatron.ietf.org; Sat, 23 Jun 2007 14:48:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2Af4-0008Qm-Oj for nsis@ietf.org; Sat, 23 Jun 2007 14:48:42 -0400 Received: from rsys002x.roke.co.uk ([193.118.201.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I2Af3-0001yz-V3 for nsis@ietf.org; Sat, 23 Jun 2007 14:48:42 -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 l5NImU2t012083; Sat, 23 Jun 2007 19:48:31 +0100 Received: from ehlaptop ([193.118.192.66]) by rsys005a.comm.ad.roke.co.uk with Microsoft SMTPSVC(6.0.3790.1830); Sat, 23 Jun 2007 19:48:30 +0100 From: "Robert Hancock" To: "=?iso-8859-1?Q?'Lu=EDs_Cordeiro'?=" , "'Ford, Alan'" References: <2181C5F19DD0254692452BFF3EAF1D6802FE4F36@rsys005a.comm.ad.roke.co.uk> <4613D619.4050404@dei.uc.pt> Subject: RE: [NSIS] GIST Q-Mode Encapsulation Magic Number Date: Sat, 23 Jun 2007 19:48:47 +0100 Message-ID: <03b301c7b5c7$2262d410$0100c80a@comm.ad.roke.co.uk> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-reply-to: <4613D619.4050404@dei.uc.pt> Thread-Index: Acd22MZns3zrlDfsQX+kQHc+qpmVXg+7fhIg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-OriginalArrivalTime: 23 Jun 2007 18:48:30.0420 (UTC) FILETIME=[17B4E940:01C7B5C7] X-MailScanner-roke-co-uk: Found to be clean X-MailScanner-roke-co-uk-SpamCheck: X-MailScanner-From: robert.hancock@roke.co.uk X-Spam-Score: 0.1 (/) X-Scan-Signature: 36fb765c89ed47dab364ab702a78e8fd Cc: 'Martin Stiemerling' , 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="===============1796872879==" Errors-To: nsis-bounces@ietf.org This is a multi-part message in MIME format. --===============1796872879== Content-Type: multipart/alternative; boundary="----=_NextPart_000_03B4_01C7B5CF.84273C10" This is a multi-part message in MIME format. ------=_NextPart_000_03B4_01C7B5CF.84273C10 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable hi all, =20 just making the final updates for -14, wrong-magic-number is now handled = as 'silently ignore' which seems to be the consensus (and also makes good technical sense). =20 regarding the scenario Luis mentions below, I think it is going to be unusual for RAO values to be assigned for multiple (i.e. GIST and = non-GIST) protocols. indeed, the "rules" on RAO assignment may not even allow this (depending on how you read the relevant specifications). so the point = here is not so much to handle this sort of overlap; it is more just working = out the right way to handle a "should never happen" corner case. =20 cheers, =20 robert h. _____ =20 From: Lu=EDs Cordeiro [mailto:cordeiro@dei.uc.pt]=20 Sent: 04 April 2007 17:45 To: Ford, Alan Cc: Martin Stiemerling; nsis@ietf.org Subject: Re: [NSIS] GIST Q-Mode Encapsulation Magic Number Hi all, I agree with Alan, we should assume that if the magic number is = different the message received is not GIST, so no Error message should be sent. This would benefit GIST in a scenario where messages (with the same IP = RAO as GIST) flood the network. In this scenario GIST would not help the = flood. But on the other hand this would require the packets to have the same IP = RAO as GIST, is this usual? BR, Lu=EDs Cordeiro Ford, Alan wrote:=20 Hi all, =20 for the case where an end system receives a GIST message without the magic number, I am still unclear on whether to generate an error or silently discard. =20 I tend so say "send an error" message, given that the magic number =20 MUST be present anyway. =20 From an implementer's point-of-view, I'm not so sure. An error message includes the GIST common header, but the magic number precedes the common header. If I fail to parse the magic number, how can I give the common header in the error message? Surely a missing magic number is a mangled packet and should just be silently ignored? I think that this is particularly relevant given that the magic number is seen as part of the encapsulation, not the message. Regards, Alan _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis =20 ------=_NextPart_000_03B4_01C7B5CF.84273C10 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
hi all,
 
just making the final updates for -14, = wrong-magic-number=20 is now handled as 'silently ignore' which seems to be the consensus (and = also=20 makes good technical sense).
 
regarding the scenario Luis mentions below, I = think it is=20 going to be unusual for RAO values to be assigned for multiple (i.e. = GIST and=20 non-GIST) protocols. indeed, the "rules" on RAO assignment may not even = allow=20 this (depending on how you read the relevant specifications). so the = point here=20 is not so much to handle this sort of overlap; it is more just working = out the=20 right way to handle a "should never happen" corner = case.
 
cheers,
 
robert h.

From: Lu=EDs Cordeiro=20 [mailto:cordeiro@dei.uc.pt]
Sent: 04 April 2007 = 17:45
To:=20 Ford, Alan
Cc: Martin Stiemerling; = nsis@ietf.org
Subject:=20 Re: [NSIS] GIST Q-Mode Encapsulation Magic Number

Hi all,

I agree = with Alan, we=20 should assume that if the magic number is different the message = received is=20 not GIST, so no Error message should be sent.

This would = benefit GIST=20 in a scenario where messages (with the same IP RAO as GIST) flood the = network.=20 In this scenario GIST would not help the flood. But on the other hand = this=20 would require the packets to have the same IP RAO as GIST, is this=20 usual?

BR,
Lu=EDs Cordeiro

Ford, Alan = wrote:=20 
Hi all,

  
for the case where an end =
system receives a GIST message without
the magic number, I am still unclear on whether to generate an
error or silently discard.
      
I tend so say "send an error" =
message, given that the magic number =20
MUST be present anyway.
    

 From an implementer's point-of-view, I'm not so sure. An error message
includes the GIST common header, but the magic number precedes the
common header. If I fail to parse the magic number, how can I give the
common header in the error message? Surely a missing magic number is a
mangled packet and should just be silently ignored? I think that this is
particularly relevant given that the magic number is seen as part of the
encapsulation, not the message.

Regards,
Alan

_______________________________________________
nsis mailing list
nsis@ietf.org
https://www1.ietf.or=
g/mailman/listinfo/nsis
------=_NextPart_000_03B4_01C7B5CF.84273C10-- --===============1796872879== 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 --===============1796872879==-- From nsis-bounces@ietf.org Sun Jun 24 13:09:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2VaD-0001tA-Cq; Sun, 24 Jun 2007 13:09:05 -0400 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1I2VaB-0001t5-N3 for nsis-confirm+ok@megatron.ietf.org; Sun, 24 Jun 2007 13:09:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2VaB-0001sw-DO for nsis@ietf.org; Sun, 24 Jun 2007 13:09:03 -0400 Received: from mailer.gwdg.de ([134.76.10.26]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I2VaA-0002Fl-Tb for nsis@ietf.org; Sun, 24 Jun 2007 13:09:03 -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 1I2Va6-0006WC-GW; Sun, 24 Jun 2007 19:08:59 +0200 Received: from [192.168.0.29] (p5484AA82.dip0.t-ipconnect.de [84.132.170.130]) by smtp.stud.informatik.uni-goettingen.de (Postfix) with ESMTP; Sun, 24 Jun 2007 19:08:57 +0200 (CEST) Message-ID: <467EA4FC.5000409@cs.uni-goettingen.de> Date: Sun, 24 Jun 2007 19:08:12 +0200 From: Bernd Schloer User-Agent: Thunderbird 1.5.0.7 (X11/20061008) MIME-Version: 1.0 To: john.loughney@nokia.com Subject: Re: [NSIS] WGLC:draft-ietf-nsis-qos-nslp-14.txt References: <071568CA7B789D4AA170CEF8C9613B4FB11B80@daebe103.NOE.Nokia.com> In-Reply-To: <071568CA7B789D4AA170CEF8C9613B4FB11B80@daebe103.NOE.Nokia.com> 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: 5011df3e2a27abcc044eaa15befcaa87 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, I reviewed the draft and haven't found any open issues. I think this draft is ready for publication. Best regards, Bernd john.loughney@nokia.com wrote: > Jukka has updated the draft. We would like to start a 2 week > WGLC on the draft which will run through close of business on > June 25th. > > Please review the draft, and comment if you feel that this draft > is ready to be sent to the IESG. A simple mail saying that the > draft is ready for publication would be great. > > Of course, if you read the draft and find open issues, then please > send a summary of your issue with the current draft. > > thanks, > Martin and John > >> -----Original Message----- >> From: ext nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] >> Sent: 11 June, 2007 12:50 >> To: i-d-announce@ietf.org >> Cc: nsis@ietf.org >> Subject: [NSIS] I-D ACTION:draft-ietf-nsis-qos-nslp-14.txt >> >> A New Internet-Draft is available from the on-line >> Internet-Drafts directories. >> This draft is a work item of the Next Steps in Signaling >> Working Group of the IETF. >> >> Title : NSLP for Quality-of-Service Signaling >> Author(s) : J. Manner, et al. >> Filename : draft-ietf-nsis-qos-nslp-14.txt >> Pages : 97 >> Date : 2007-6-11 >> >> 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-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-qos-nslp-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-qos-nslp-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. >> > > > _______________________________________________ > 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 Jun 25 11:38:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2qeO-0005yZ-2Z; Mon, 25 Jun 2007 11:38:48 -0400 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1I2qeL-0005vL-SB for nsis-confirm+ok@megatron.ietf.org; Mon, 25 Jun 2007 11:38:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2qeL-0005tY-FW for nsis@ietf.org; Mon, 25 Jun 2007 11:38:45 -0400 Received: from smtp.mei.co.jp ([133.183.129.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I2qeK-0003Cf-NW for nsis@ietf.org; Mon, 25 Jun 2007 11:38:45 -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 l5PFcWBY006789; Tue, 26 Jun 2007 00:38:32 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx3) with ESMTP id l5PFcWb08341; Tue, 26 Jun 2007 00:38:32 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/phillies) with ESMTP id l5PFcWf13066; Tue, 26 Jun 2007 00:38:32 +0900 (JST) Received: from [127.0.0.1] ([10.239.16.35]) by pslexc01.psl.local with Microsoft SMTPSVC(6.0.3790.1830); Mon, 25 Jun 2007 23:38:32 +0800 Message-ID: <467FE11C.2030800@sg.panasonic.com> Date: Mon, 25 Jun 2007 23:37:00 +0800 From: Hong Cheng User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: nsis 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.95.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Jun 2007 15:38:32.0471 (UTC) FILETIME=[E2D36A70:01C7B73E] X-Spam-Score: 0.1 (/) X-Scan-Signature: 20f22c03b5c66958bff5ef54fcda6e48 Cc: Martin Stiemerling , jmanner@cs.Helsinki.FI 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 reviewed the draft. It seems good. Below are some of my comments. cheers Cheng Hong =============================== - Page 8 Figure 2: The figure needs to align with the decision made about the API discussion, i.e. whether the Local Application is talking to the QoS NSLP or to the RMF. - Page 18, section 3.2.10.3, paragraph 2, line 6, "similar to section 3.2.10.3". This section is referring to itself? Shouldn't it be "3.2.10.2"? - Page 31, section 4.4, paragraph 5, line 3 "Both directions of the flows are bound by inserting the BOUND_SESSION_ID object at the QNI and QNR". How does a QNR insert the BOUND_SESSION_ID? Maybe what it meant is "Both directions of the flows are bound to the other direction by inserting the BOUND_SESSION_ID object at the QNIs"? And, this would also require the QNI (A) know about the Session ID to be used for RESERVE-2 (Flow-2) at B beforehand. - Page 76, line 3, "If the RESERVE-INIT flag is included in an arrived QUERY." This seems not a proper condition for "The QNE must create a new RESERVE and send it to its next peer". Only the QNI, not any QNE, would send a RESERVE when receiving such a QUERY. And, that RESERVE is sent towards reverse direction of the QUERY, not the next peer. This was clearly stated in paragraph 4 or section 5.4.2 (page 76). - Page 78, second paragraph (section 5.4.3). There is another condition in which the QNE must send a RESPONSE: received a RESERVE or QUERY with the common header ACK-REQ-flag set. In this case, the RESPONSE message does not contain any RII object, and should not be forwarded further by the receiving QNE. Martin Stiemerling wrote: > Dear all, > > 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. > > Thanks, > > Martin > > Anfang der weitergeleiteten E-Mail: > >> *Von: *> >> *Datum: *12. Juni 2007 23:27:48 MESZ >> *An: *> >> *Betreff: **[NSIS] WGLC:draft-ietf-nsis-qos-nslp-14.txt * >> >> Jukka has updated the draft. We would like to start a 2 week >> WGLC on the draft which will run through close of business on >> June 25th. >> >> Please review the draft, and comment if you feel that this draft >> is ready to be sent to the IESG. A simple mail saying that the >> draft is ready for publication would be great. >> >> Of course, if you read the draft and find open issues, then please >> send a summary of your issue with the current draft. >> >> thanks, >> Martin and John >> >>> -----Original Message----- >>> From: ext nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] >>> Sent: 11 June, 2007 12:50 >>> To: i-d-announce@ietf.org >>> Cc: nsis@ietf.org >>> Subject: [NSIS] I-D ACTION:draft-ietf-nsis-qos-nslp-14.txt >>> >>> A New Internet-Draft is available from the on-line >>> Internet-Drafts directories. >>> This draft is a work item of the Next Steps in Signaling >>> Working Group of the IETF. >>> >>> Title : NSLP for Quality-of-Service Signaling >>> Author(s) : J. Manner, et al. >>> Filename : draft-ietf-nsis-qos-nslp-14.txt >>> Pages : 97 >>> Date : 2007-6-11 >>> >>> >>> 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-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-qos-nslp-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-qos-nslp-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. >>> >> >> >> _______________________________________________ >> nsis mailing list >> nsis@ietf.org >> https://www1.ietf.org/mailman/listinfo/nsis > > stiemerling@netlab.nec.de > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, > London W3 6BL | Registered in England 2832014 > > > ------------------------------------------------------------------------ > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Jun 26 05:52:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I37Zv-00039B-2f; Tue, 26 Jun 2007 05:43:19 -0400 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1I37Zt-00038r-5u for nsis-confirm+ok@megatron.ietf.org; Tue, 26 Jun 2007 05:43:17 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I37Zr-00038g-9P for nsis@ietf.org; Tue, 26 Jun 2007 05:43:16 -0400 Received: from rsys001x.roke.co.uk ([193.118.201.108]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I37Zq-00023d-Df for nsis@ietf.org; Tue, 26 Jun 2007 05:43:15 -0400 Received: from rsys005a.comm.ad.roke.co.uk ([193.118.193.85]) by rsys001x.roke.co.uk (8.13.1/8.13.1) with ESMTP id l5Q9gKc5024039; Tue, 26 Jun 2007 10:42:20 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] NSIS Interop Summary Report from Karlsruhe Date: Tue, 26 Jun 2007 10:42:36 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] NSIS Interop Summary Report from Karlsruhe Thread-Index: AceyAxPKGDco9a+fRmav6s8EcfbBkAF0tQ3g References: <46771981.60907@tm.uka.de> From: "Hancock, Robert" To: "Roland Bless" , , X-MailScanner-roke-co-uk: Found to be clean X-MailScanner-roke-co-uk-SpamCheck: X-MailScanner-From: robert.hancock@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: f8ee348dcc4be4a59bc395f7cd6343ad 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 folks, just a note to say that I've implemented fixes/clarications coming out of the interop event in draft-14; the extracts from the=20 change log are given below cross referenced, and I hope to post a sort of pre-draft later today. and my special thanks/congratulations (again) to the interop groups, especially Roland and Christian. not only did you achieve a lot in=20 the development and testing, but the issues were also really well=20 analysed and easy to follow. cheers, robert h. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 14. Clarified that rule 6 in Section 6.3 should include dropping the incoming data. [Interop ticket 36] 15. Modified the handling of the Stack-Proposal verification in Section 5.7.1 to say that the MA is only torn down if it is a new one; otherwise, the action is that the routing state for the MRI is deleted or never created. Added the verification of the Responder cookie to be included in the same set of checks. [Interop ticket 43, 49] 16. Clarified that the timer used to retransmit Responses follows the same rules as other timers in Section 5.3.3;also, in Section 6.3 stated that Expire_RNode should be reset to the initial value on a new Query, and its expiration overrides any outstanding No_Confirm timer. [Interop ticket 48] 17. Clarified in Section 5.6 that if the messaging association that should be used to deliver an Error message has been closed, this comes into the category of 'messages that cannot be sent'. [Interop ticket 50] 18. Amended the description of Confirm contents in Section 5.1 to note that the Stack-Proposal may not be present if it was not present in the Response. (This can only happen if the Response was sent over an existing MA; if a new MA is set up, a Stack- Proposal is required in the Response. Therefore, if the abbreviated SCD is sent in the Confirm, there will always be a Stack-Proposal to accompany it.) [Interop ticket 55] 19. Refined the definition of the Inactive_QNode timer in Section 6.2 to clarify that this is just to measure the activity in terms of NSLP traffic rather than GIST-internal traffic, and modified Rule 4 accordingly. [Interop ticket 64] 20. Deleted the term 'full handshake' as this implied mandatory use of the 3 message for (Q/R/C), whereas in the places the term was used the purpose was to highlight that the handshake was taking place in D-mode rather than partly in C-mode. Whether a Confirm is sent is under the control of the Responder. [Interop ticket 65] 21. Clarified in Section 3.4 and Section 5.1 that generation of a Confirm is controlled by the content of the Response, and that when a new MA is being set up the rules for content of a Response require a Confirm. [Interop ticket 66] =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > -----Original Message----- > From: Roland Bless [mailto:bless@tm.uka.de]=20 > Sent: 19 June 2007 00:47 > To: nsis@ietf.org; nsis-chairs@tools.ietf.org > Subject: [NSIS] NSIS Interop Summary Report from Karlsruhe >=20 > Hi all, >=20 > the WG chairs solicited feedback about the latest NSIS=20 > interop in Karlsruhe. So here it is (sorry for the long delay): >=20 > Overview: > =3D=3D=3D=3D=3D=3D=3D=3D=3D > * Implementation teams: > - University of Coimbra (GIST, QoS NSLP, NAT/FW) each Draft -13 > - Uni Goettingen (GIST, QoS NSLP, NAT/FW) each Draft-13 > - Uni Karlsruhe (GIST, QoS NSLP, NAT/FW) each Draft-13 > - Siemens Roke Manor Research was planned to participate but > could not make it. > * We mainly concentrated on GIST tests, because > this spec has to be off the table first. > * We used test cases that were defined by Christian Dickmann > (and discussed at last IETF among Christian, Alan Ford, Andrew > McDonald and partially me). You can find the document here > (though in a format of an internet-draft, it is not=20 > published as such > yet) > http://user.informatik.uni-goettingen.de/~cdickman/draft-dickm > ann-nsis-ntlp-interop-00.txt >=20 > * Christian did a great job in setting up tools for performing > automated tests. This sped up testing a lot. > * GIST was quite thoroughly tested with Goettingen vs. Karlsruhe > (in both directions, see below). > We tested all the main protocol features like D-Mode, C-Mode, > TLS+TCP, v4,v6, late state installation, etc. > * The GIST Spec is implementable; we found no major issues > with the GIST spec, only the need for > some clarifications that can be found here in our tracker: > https://projekte.tm.uka.de/trac/NSIS/report/10 > (I entered some additional tickets after the interop event). > * A major open issue is, however, NAT traversal functionality > that could not be tested yet. > * Interop URL:=20 > https://projekte.tm.uka.de/trac/NSIS/wiki/Interop-20070509 >=20 > Details (as written in a mail from Christian)=20 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Christian created a report based on the data collected by the=20 > Interop Tools. Take a look at: > http://dickmann.homeunix.org/nsis/displayReportList.php > --------------------------------------------------------------------- > Christian's mail: > Of course, this is only a subset of all tests that were made=20 > (and only the last run of each test case), but I guess we are=20 > close to 90 or 95% coverage. A lot of test cases come with=20 > captures so that you can look up the message exchange for=20 > successful or failed tests. I set the success-flag for most=20 > tests directly during the interop event once the test was=20 > completed. However, for some test cases I set the flag today=20 > based on my notes (and my memory). >=20 > As you know the test cases were based on [1]. > Each test case belongs into one of these categories: "normal=20 > operation", "recoverable problems", "unrecoverable problems". >=20 > I analyzed the report based on these categories (notation "X vs. Y" > means X is Initiator and Y is Responder): > Normal operation: > Goettingen vs. Karlsruhe: > 3-Way Handshake: 7 PASSED, 10 run of 11 test cases > Refresh of soft state: 2 PASSED, 2 run of 5 test cases > Setup of multiple sessions: 3 PASSED, 3 run of 4 test cases > Interception on NSIS forwarders: 3 PASSED, 4 run of 4 test cases > GIST Stateless operation: 0 PASSED, 1 run of 2 test cases > Karlsruhe vs. Goettingen: > 3-Way Handshake: 8 PASSED, 9 run of 11 test cases > Refresh of soft state: 0 PASSED, 1 run of 5 test cases > Goettingen vs. Coimbra: > 3-Way Handshake: 8 PASSED, 9 run of 11 test cases > Refresh of soft state: 2 PASSED, 2 run of 5 test cases > Coimbra vs. Goettingen: > 3-Way Handshake: 2 PASSED, 3 run of 11 test cases > Karlsruhe vs. Coimbra: > 3-Way Handshake: 5 PASSED, 5 run of 11 test cases >=20 > Recoverable problems: > Goettingen vs. Karlsruhe: > 3-Way Handshake: 2 PASSED, 3 run of 3 test cases > Refresh of soft state: 4 PASSED, 4 run of 5 test cases > Karlsruhe vs. Goettingen: > 3-Way Handshake: 1 PASSED, 1 run of 3 test cases > Goettingen vs. Coimbra: > 3-Way Handshake: 2 PASSED, 2 run of 3 test cases > Refresh of soft state: 4 PASSED, 4 run of 5 test cases >=20 > Unrecoverable problems: > Goettingen vs. Karlsruhe: > 3-Way Handshake: 5 PASSED, 5 run of 5 test cases > Karlsruhe vs. Goettingen: > 3-Way Handshake: 3 PASSED, 4 run of 5 test cases > Goettingen vs. Coimbra: > 3-Way Handshake: 4 PASSED, 5 run of 5 test cases >=20 >=20 >=20 > As we can see, we did not test all test cases, even for Goettingen vs. > Karlsruhe. > However, for Goe vs. Ka we can say that we covered a really=20 > good part of the GIST specification. In particular we tested=20 > all important features (except for NAT traversal and=20 > Stateless mode). This makes me very confident that the spec=20 > is implementable (except for NAT traversal, see NSIS mailing list). > I think we tested Goettingen against Karlsruhe quite=20 > thoroughly (in both directions). We ran 47 test cases (IPv4=20 > only) and passed 38 of these. > That's a success rate of 80%. The tests against Coimbra were=20 > not as complete. We ran 25 test cases (IPv4 only) between=20 > G=F6ttingen and Coimbra and passed 22 of them (=3D 88%). Thus,=20 > the test cases we tested were quite successful, but we ran=20 > only half of the test cases compared to Goe/Ka. >=20 > Also note that we did only very few test cases with IPv6 and=20 > only with G=F6ttingen vs. Karlsruhe. However, those were all = successful. >=20 > My personal lessons learned from this interop: > - Even 3 days were not enough. Considering that we only had 3=20 > GIST implementations to test, this sounds like we wasted too=20 > much time. I try to find reasons below. > - I guess 70% of the problems we found between G=F6ttingen and=20 > Karlsruhe were NOT related to interop problems. On the other=20 > hand, all bugs found in our (G=F6ttingen) implementation (very=20 > few overall) were related to real interop issues. I guess the=20 > reason is quite simple: I ran ALL test cases defined in [1]=20 > with G=F6ttingen vs. G=F6ttingen and so found and fixed a lot of=20 > bugs before arriving in Karlsruhe. I suppose the other=20 > participants did not do internal tests as thorough as ours,=20 > which resulted in this rate of non-interop issues. > - More internal tests (see above) but also remote tests=20 > before the actual interop event can save a lot of time. I did=20 > some remote tests with Karlsruhe and we were able to detect=20 > and fix some problems before meeting in person. With Coimbra=20 > I also performed some remote tests (just basic D-Mode and=20 > C-Mode, both failed), but not as thorough as with Karlsruhe.=20 > We ended up having problems with TLS for many hours during=20 > the interop event. We should do much more remote testing to=20 > avoid these lengthy debugging phases! > - The interop draft [1] helped a lot. First, it has so many=20 > test cases that you would not think of during an interop=20 > event. Second, for complex tests the expected behavior and=20 > useful triggers are not always obvious. > Having them written down with one or two rounds of review=20 > saves time and avoids mistakes during the interop event.=20 > Third, the interop draft now helps to write this report, as=20 > we can "measure" the success. > - The interop tools helped a lot and saved a lot of time. I=20 > guess the tools saved roughly 50% of my time. Maybe even=20 > more. Considering that we are very short on time, this is a=20 > huge improvement. Besides that, many test cases are simply=20 > not feasible without tools (for example attack scenarios,=20 > corrupted objects, etc.). We should continue to use the tools=20 > and extend them so that they can become the default tool to=20 > do the interop. That would also help in remote testing. > - The organization by Roland was very good. We had enough=20 > switches, cables, spare machines, space, etc. The network=20 > setup we discussed on this mailing list a week before the=20 > interop was well set up and avoided long setup and=20 > re-plugging phases. You can see that this is important when=20 > you look at Luis and Vitor who tried to configure their=20 > network on site to correspond to the network layout. It took=20 > them quite a while of debugging to configure their machines=20 > correctly. More preparation from all sides and an agreed-upon=20 > network setup help to avoid these kinds of delay. > - Taking all these issues into account, I think that 3 days=20 > CAN be enough time, if and only if enough preparation is done=20 > in form of defining test cases, writing tools to help with=20 > testing, testing internally against the test cases, doing=20 > remote tests and organizing and preparing for the event itself. >=20 > Overall I am quite satisfied with the interop. I think we=20 > made a big step ahead towards mature and interoperable=20 > implementations. We tested and discussed a good portion of=20 > the spec and found no (or very few and > minor) real problems. And we tested quite a lot of test cases=20 > and had a reasonable success rate that is even going to=20 > improve with remote tests taking place in the next few weeks. >=20 > Thank you all. I had a great time at the interop and special=20 > thanks go to Roland and the University of Karlsruhe for doing=20 > a very good job of hosting this interop event. >=20 > Regards, > Christian Dickmann >=20 > [1] > http://user.informatik.uni-goettingen.de/~cdickman/draft-dickm > ann-nsis-ntlp-interop-00.txt > -------------------------------------------------------------------- >=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 Jun 26 07:11:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I38mm-0006cQ-Ev; Tue, 26 Jun 2007 07:00:40 -0400 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1I38mk-0006cJ-R4 for nsis-confirm+ok@megatron.ietf.org; Tue, 26 Jun 2007 07:00:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I38mk-0006cB-HC for nsis@ietf.org; Tue, 26 Jun 2007 07:00:38 -0400 Received: from rsys001x.roke.co.uk ([193.118.201.108]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I38mV-0002FR-8b for nsis@ietf.org; Tue, 26 Jun 2007 07:00:38 -0400 Received: from rsys005a.comm.ad.roke.co.uk ([193.118.193.85]) by rsys001x.roke.co.uk (8.13.1/8.13.1) with ESMTP id l5QB0ICD028588 for ; Tue, 26 Jun 2007 12:00:18 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 26 Jun 2007 12:00:34 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: gist version -14 pre-draft Thread-Index: Ace34TiQWVGyCOflQpG/7UoILYHT9g== From: "Hancock, Robert" To: X-MailScanner-roke-co-uk: Found to be clean X-MailScanner-roke-co-uk-SpamCheck: X-MailScanner-From: robert.hancock@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Subject: [NSIS] gist version -14 pre-draft 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 prepared a candidate gist version 14, taking into account the last call discussions and interop issues. it is not yet submitted to the secretariat, but can be found on-line here: http://nsis.srmr.co.uk/nsis/draft-ietf-nsis-ntlp-14.txt the changes are, as ever, summarised in the change log. people might like to see if i have understood the points and implemented useful changes. (in several cases a last call comment was something like "does this mean X?", and if the answer is 'yes' i treat that as a no-op.) a couple of points which might still be open: - jukka has raised some issues about conditional peering. my feeling is that we have a basic capability already, and any further extensions required can be implemented as 100% backwards compatible extensions (mainly by changing the interface between NSLP and GIST). given the guidance we have been given on controlling complexity, i'd prefer to leave GIST as it is on this point. - roland has raised an issue about making the Hello-ID optional in MA-Hello messages (only needed if R!=3D0 in the message). i think this = is probably technically feasible, but not clear whether everyone thinks it makes things simpler and is happy to change message formats and rules at this stage. if there's a clear view otherwise, it's a relatively simple fix to make. i will be offline for the next few days, but intend to submit the real version 14 in time for the -0n cutoff taking into account any final comments up to then. cheers, robert h. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Jun 26 08:28:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3A9d-0007QV-CG; Tue, 26 Jun 2007 08:28:21 -0400 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1I3A9c-0007NX-Es for nsis-confirm+ok@megatron.ietf.org; Tue, 26 Jun 2007 08:28:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3A9c-0007NK-4k for nsis@ietf.org; Tue, 26 Jun 2007 08:28:20 -0400 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3A9O-00073d-4b for nsis@ietf.org; Tue, 26 Jun 2007 08:28:20 -0400 Received: from [10.1.1.109] (mito.netlab.nec.de [195.37.70.39]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 94DA513CF81; Tue, 26 Jun 2007 14:28:05 +0200 (CEST) In-Reply-To: <46771981.60907@tm.uka.de> References: <46771981.60907@tm.uka.de> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <5C9FFDAF-01A6-4920-BF9A-C3C735B9D911@netlab.nec.de> From: Martin Stiemerling Date: Tue, 26 Jun 2007 14:28:04 +0200 To: Roland Bless X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a78ee79e7121d5e3529be34866f161 Cc: nsis-chairs@tools.ietf.org, "nsis@ietf.org" Subject: [NSIS] Re: NSIS Interop Summary Report from Karlsruhe 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="===============0354765778==" Errors-To: nsis-bounces@ietf.org --===============0354765778== Content-Type: multipart/alternative; boundary=Apple-Mail-35-542738379 --Apple-Mail-35-542738379 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Hi Roland and all interop participants, Thanks a lot for the summary of the interop results. They read pretty =20= good giving the impression that GIST is mature enough to go ahead. Martin Am 19.06.2007 um 01:47 schrieb Roland Bless: > Hi all, > > the WG chairs solicited feedback about the latest NSIS interop in > Karlsruhe. So here it is (sorry for the long delay): > > Overview: > =3D=3D=3D=3D=3D=3D=3D=3D=3D > * Implementation teams: > - University of Coimbra (GIST, QoS NSLP, NAT/FW) each Draft -13 > - Uni Goettingen (GIST, QoS NSLP, NAT/FW) each Draft-13 > - Uni Karlsruhe (GIST, QoS NSLP, NAT/FW) each Draft-13 > - Siemens Roke Manor Research was planned to participate but > could not make it. > * We mainly concentrated on GIST tests, because > this spec has to be off the table first. > * We used test cases that were defined by Christian Dickmann > (and discussed at last IETF among Christian, Alan Ford, Andrew > McDonald and partially me). You can find the document here > (though in a format of an internet-draft, it is not published as =20 > such > yet) > http://user.informatik.uni-goettingen.de/~cdickman/draft-dickmann-=20 > nsis-ntlp-interop-00.txt > > * Christian did a great job in setting up tools for performing > automated tests. This sped up testing a lot. > * GIST was quite thoroughly tested with Goettingen vs. Karlsruhe > (in both directions, see below). > We tested all the main protocol features like D-Mode, C-Mode, > TLS+TCP, v4,v6, late state installation, etc. > * The GIST Spec is implementable; we found no major issues > with the GIST spec, only the need for > some clarifications that can be found here in our tracker: > https://projekte.tm.uka.de/trac/NSIS/report/10 > (I entered some additional tickets after the interop event). > * A major open issue is, however, NAT traversal functionality > that could not be tested yet. > * Interop URL: https://projekte.tm.uka.de/trac/NSIS/wiki/=20 > Interop-20070509 > > Details (as written in a mail from Christian) > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= > Christian created a report based on the data collected by the > Interop Tools. Take a look at: > http://dickmann.homeunix.org/nsis/displayReportList.php > --------------------------------------------------------------------- > Christian's mail: > Of course, this is only a subset of all tests that were made (and only > the last run of each test case), but I guess we are close to 90 or 95% > coverage. A lot of test cases come with captures so that you can =20 > look up > the message exchange for successful or failed tests. I set the > success-flag for most tests directly during the interop event once the > test was completed. However, for some test cases I set the flag today > based on my notes (and my memory). > > As you know the test cases were based on [1]. > Each test case belongs into one of these categories: "normal =20 > operation", > "recoverable problems", "unrecoverable problems". > > I analyzed the report based on these categories (notation "X vs. Y" > means X is Initiator and Y is Responder): > Normal operation: > Goettingen vs. Karlsruhe: > 3-Way Handshake: 7 PASSED, 10 run of 11 test cases > Refresh of soft state: 2 PASSED, 2 run of 5 test cases > Setup of multiple sessions: 3 PASSED, 3 run of 4 test cases > Interception on NSIS forwarders: 3 PASSED, 4 run of 4 test cases > GIST Stateless operation: 0 PASSED, 1 run of 2 test cases > Karlsruhe vs. Goettingen: > 3-Way Handshake: 8 PASSED, 9 run of 11 test cases > Refresh of soft state: 0 PASSED, 1 run of 5 test cases > Goettingen vs. Coimbra: > 3-Way Handshake: 8 PASSED, 9 run of 11 test cases > Refresh of soft state: 2 PASSED, 2 run of 5 test cases > Coimbra vs. Goettingen: > 3-Way Handshake: 2 PASSED, 3 run of 11 test cases > Karlsruhe vs. Coimbra: > 3-Way Handshake: 5 PASSED, 5 run of 11 test cases > > Recoverable problems: > Goettingen vs. Karlsruhe: > 3-Way Handshake: 2 PASSED, 3 run of 3 test cases > Refresh of soft state: 4 PASSED, 4 run of 5 test cases > Karlsruhe vs. Goettingen: > 3-Way Handshake: 1 PASSED, 1 run of 3 test cases > Goettingen vs. Coimbra: > 3-Way Handshake: 2 PASSED, 2 run of 3 test cases > Refresh of soft state: 4 PASSED, 4 run of 5 test cases > > Unrecoverable problems: > Goettingen vs. Karlsruhe: > 3-Way Handshake: 5 PASSED, 5 run of 5 test cases > Karlsruhe vs. Goettingen: > 3-Way Handshake: 3 PASSED, 4 run of 5 test cases > Goettingen vs. Coimbra: > 3-Way Handshake: 4 PASSED, 5 run of 5 test cases > > > > As we can see, we did not test all test cases, even for Goettingen vs. > Karlsruhe. > However, for Goe vs. Ka we can say that we covered a really good =20 > part of > the GIST specification. In particular we tested all important features > (except for NAT traversal and Stateless mode). This makes me very > confident that the spec is implementable (except for NAT traversal, =20= > see > NSIS mailing list). > I think we tested Goettingen against Karlsruhe quite thoroughly (in =20= > both > directions). We ran 47 test cases (IPv4 only) and passed 38 of these. > That's a success rate of 80%. The tests against Coimbra were not as > complete. We ran 25 test cases (IPv4 only) between G=F6ttingen and =20 > Coimbra > and passed 22 of them (=3D 88%). Thus, the test cases we tested were =20= > quite > successful, but we ran only half of the test cases compared to Goe/Ka. > > Also note that we did only very few test cases with IPv6 and only with > G=F6ttingen vs. Karlsruhe. However, those were all successful. > > My personal lessons learned from this interop: > - Even 3 days were not enough. Considering that we only had 3 GIST > implementations to test, this sounds like we wasted too much time. =20 > I try > to find reasons below. > - I guess 70% of the problems we found between G=F6ttingen and = Karlsruhe > were NOT related to interop problems. On the other hand, all bugs =20 > found > in our (G=F6ttingen) implementation (very few overall) were related to > real interop issues. I guess the reason is quite simple: I ran ALL =20 > test > cases defined in [1] with G=F6ttingen vs. G=F6ttingen and so found and = =20 > fixed > a lot of bugs before arriving in Karlsruhe. I suppose the other > participants did not do internal tests as thorough as ours, which > resulted in this rate of non-interop issues. > - More internal tests (see above) but also remote tests before the > actual interop event can save a lot of time. I did some remote tests > with Karlsruhe and we were able to detect and fix some problems before > meeting in person. With Coimbra I also performed some remote tests =20 > (just > basic D-Mode and C-Mode, both failed), but not as thorough as with > Karlsruhe. We ended up having problems with TLS for many hours during > the interop event. We should do much more remote testing to avoid =20 > these > lengthy debugging phases! > - The interop draft [1] helped a lot. First, it has so many test cases > that you would not think of during an interop event. Second, for =20 > complex > tests the expected behavior and useful triggers are not always =20 > obvious. > Having them written down with one or two rounds of review saves =20 > time and > avoids mistakes during the interop event. Third, the interop draft now > helps to write this report, as we can "measure" the success. > - The interop tools helped a lot and saved a lot of time. I guess the > tools saved roughly 50% of my time. Maybe even more. Considering =20 > that we > are very short on time, this is a huge improvement. Besides that, many > test cases are simply not feasible without tools (for example attack > scenarios, corrupted objects, etc.). We should continue to use the =20 > tools > and extend them so that they can become the default tool to do the > interop. That would also help in remote testing. > - The organization by Roland was very good. We had enough switches, > cables, spare machines, space, etc. The network setup we discussed on > this mailing list a week before the interop was well set up and =20 > avoided > long setup and re-plugging phases. You can see that this is important > when you look at Luis and Vitor who tried to configure their =20 > network on > site to correspond to the network layout. It took them quite a =20 > while of > debugging to configure their machines correctly. More preparation from > all sides and an agreed-upon network setup help to avoid these =20 > kinds of > delay. > - Taking all these issues into account, I think that 3 days CAN be > enough time, if and only if enough preparation is done in form of > defining test cases, writing tools to help with testing, testing > internally against the test cases, doing remote tests and =20 > organizing and > preparing for the event itself. > > Overall I am quite satisfied with the interop. I think we made a big > step ahead towards mature and interoperable implementations. We tested > and discussed a good portion of the spec and found no (or very few and > minor) real problems. And we tested quite a lot of test cases and =20 > had a > reasonable success rate that is even going to improve with remote =20 > tests > taking place in the next few weeks. > > Thank you all. I had a great time at the interop and special thanks go > to Roland and the University of Karlsruhe for doing a very good job of > hosting this interop event. > > Regards, > Christian Dickmann > > [1] > http://user.informatik.uni-goettingen.de/~cdickman/draft-dickmann-=20 > nsis-ntlp-interop-00.txt > -------------------------------------------------------------------- > stiemerling@netlab.nec.de NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, =20 London W3 6BL | Registered in England 2832014 --Apple-Mail-35-542738379 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Hi Roland and all interop = participants,

Thanks = a lot for the summary of the interop results. They read pretty good = giving the impression that GIST is mature enough to go = ahead.=A0

=A0 = Martin

Am 19.06.2007 um 01:47 schrieb Roland = Bless:

Hi all,

the WG = chairs solicited feedback about the latest NSIS interop in
Karlsruhe. So here it is (sorry for the long = delay):

Overview:
* = Implementation teams:
=A0 - University of Coimbra = (GIST, QoS NSLP, NAT/FW) each Draft -13
=A0 - Uni Goettingen (GIST, QoS = NSLP, NAT/FW) each Draft-13
=A0 - Uni Karlsruhe (GIST, QoS = NSLP, NAT/FW) each Draft-13
=A0 - Siemens Roke Manor Research = was planned to participate but
=A0 =A0 could not make = it.
* We mainly concentrated on GIST = tests, because
=A0 this spec has to be off the = table first.
* We used test cases that were = defined by Christian Dickmann
=A0 (and discussed at last IETF = among Christian, Alan Ford, Andrew
=A0 McDonald and partially me). = You can find the document here
=A0 (though in a format of an = internet-draft, it is not published as such
=A0 yet)

* = Christian did a great job in setting up tools for performing
=A0 = automated tests. This sped up testing a lot.
* GIST=A0 = was quite thoroughly tested with Goettingen vs. = Karlsruhe
=A0 (in both directions, see = below).
=A0 We tested all the main = protocol features like D-Mode, C-Mode,
=A0 TLS+TCP, v4,v6, late state = installation, etc.
* The GIST Spec is = implementable; we found no major issues
=A0 with the GIST spec, only the = need for
=A0 some clarifications that can = be found here in our tracker:
=A0 (I entered some additional = tickets after the interop event).
* A major = open issue is, however, NAT traversal functionality
=A0 = that could not be tested yet.

Details = (as written in a mail from Christian)
Christian created a report based on the data = collected by the
Interop Tools. Take a look = at:
Christian's mail:
Of = course, this is only a subset of all tests that were made (and = only
the last run of each test case), = but I guess we are close to 90 or 95%
the message exchange for successful or failed = tests. I set the
success-flag for most tests = directly during the interop event once the
test was = completed. However, for some test cases I set the flag today
based on my notes (and my memory).

As you = know the test cases were based on [1].
Each = test case belongs into one of these categories: "normal = operation",
"recoverable problems", = "unrecoverable problems".

I analyzed the report based on = these categories (notation "X vs. Y"
means X is = Initiator and Y is Responder):
Normal = operation:
=A0 Goettingen vs. = Karlsruhe:
=A0 =A0 3-Way Handshake: 7 = PASSED, 10 run of 11 test cases
=A0 =A0 Refresh of soft state: 2 = PASSED, 2 run of 5 test cases
=A0 =A0 Setup of multiple = sessions: 3 PASSED, 3 run of 4 test cases
=A0 =A0 Interception on NSIS = forwarders: 3 PASSED, 4 run of 4 test cases
=A0 =A0 GIST Stateless operation: = 0 PASSED, 1 run of 2 test cases
=A0 Karlsruhe vs. = Goettingen:
=A0 =A0 3-Way Handshake: 8 = PASSED, 9 run of 11 test cases
=A0 =A0 Refresh of soft state: 0 = PASSED, 1 run of 5 test cases
=A0 Goettingen vs. = Coimbra:
=A0 =A0 3-Way Handshake: 8 = PASSED, 9 run of 11 test cases
=A0 =A0 Refresh of soft state: 2 = PASSED, 2 run of 5 test cases
=A0 Coimbra vs. = Goettingen:
=A0 =A0 3-Way Handshake: 2 = PASSED, 3 run of 11 test cases
=A0 Karlsruhe vs. = Coimbra:
=A0 =A0 3-Way Handshake: 5 = PASSED, 5 run of 11 test cases

Recoverable problems:
=A0 = Goettingen vs. Karlsruhe:
=A0 =A0 3-Way Handshake: 2 = PASSED, 3 run of 3 test cases
=A0 =A0 Refresh of soft state: 4 = PASSED, 4 run of 5 test cases
=A0 Karlsruhe vs. = Goettingen:
=A0 =A0 3-Way Handshake: 1 = PASSED, 1 run of 3 test cases
=A0 Goettingen vs. = Coimbra:
=A0 =A0 3-Way Handshake: 2 = PASSED, 2 run of 3 test cases
=A0 =A0 Refresh of soft state: 4 = PASSED, 4 run of 5 test cases

Unrecoverable = problems:
=A0 Goettingen vs. = Karlsruhe:
=A0 =A0 3-Way Handshake: 5 = PASSED, 5 run of 5 test cases
=A0 Karlsruhe vs. = Goettingen:
=A0 =A0 3-Way Handshake: 3 = PASSED, 4 run of 5 test cases
=A0 Goettingen vs. = Coimbra:
=A0 =A0 3-Way Handshake: 4 = PASSED, 5 run of 5 test cases



As we = can see, we did not test all test cases, even for Goettingen = vs.
Karlsruhe.
However, for Goe vs. Ka we can say that we covered a = really good part of
the GIST specification. In = particular we tested all important features
(except = for NAT traversal and Stateless mode). This makes me very
confident that the spec is implementable (except for = NAT traversal, see
NSIS mailing = list).
I think we tested Goettingen = against Karlsruhe quite thoroughly (in both
That's a success rate of 80%. = The tests against Coimbra were not as
and passed 22 of them (=3D 88%). = Thus, the test cases we tested were quite

Also note that we did only very few test cases with = IPv6 and only with
G=F6ttingen vs. Karlsruhe. = However, those were all successful.

My personal lessons learned from = this interop:
- Even 3 days were not enough. = Considering that we only had 3 GIST
to find reasons below.
- I guess 70% of the problems we found between = G=F6ttingen and Karlsruhe
were NOT = related to interop problems. On the other hand, all bugs found
in our (G=F6ttingen) implementation (very few = overall) were related to
real interop = issues. I guess the reason is quite simple: I ran ALL test
cases defined in [1] with G=F6ttingen vs. G=F6ttingen = and so found and fixed
a lot of bugs before = arriving in Karlsruhe. I suppose the other
resulted in this rate of = non-interop issues.
- More internal tests (see = above) but also remote tests before the
actual = interop event can save a lot of time. I did some remote tests
with Karlsruhe and we were able to detect and fix = some problems before
meeting in person. With = Coimbra I also performed some remote tests (just
basic D-Mode and C-Mode, both failed), but not as = thorough as with
Karlsruhe. We ended up having = problems with TLS for many hours during
the = interop event. We should do much more remote testing to avoid = these
lengthy debugging = phases!
- The interop draft [1] helped a = lot. First, it has so many test cases
that you = would not think of during an interop event. Second, for = complex
tests the expected behavior and = useful triggers are not always obvious.
Having = them written down with one or two rounds of review saves time = and
avoids mistakes during the = interop event. Third, the interop draft now
helps = to write this report, as we can "measure" the success.
- The interop tools helped a lot and saved a lot of = time. I guess the
tools saved roughly 50% of my = time. Maybe even more. Considering that we
are very = short on time, this is a huge improvement. Besides that, many
test cases are simply not feasible without tools = (for example attack
scenarios, corrupted = objects, etc.). We should continue to use the tools
and extend them so that they can become the default = tool to do the
interop. That would also help in = remote testing.
- The organization by Roland was = very good. We had enough switches,
cables, spare = machines, space, etc. The network setup we discussed on
this mailing list a week before the interop was well = set up and avoided
long setup and re-plugging = phases. You can see that this is important
when you = look at Luis and Vitor who tried to configure their network on
site to correspond to the network layout. It took = them quite a while of
debugging to configure = their machines correctly. More preparation from
all sides and an agreed-upon network setup help to = avoid these kinds of
delay.
- Taking all these issues into account, I think that = 3 days CAN be
enough time, if and only if = enough preparation is done in form of
defining = test cases, writing tools to help with testing, testing
internally against the test cases, doing remote = tests and organizing and
preparing for = the event itself.

Overall I am quite satisfied with the interop. I = think we made a big
step ahead towards mature = and interoperable implementations. We tested
and discussed a good portion of the spec and found = no (or very few and
minor) real problems. And = we tested quite a lot of test cases and had a
reasonable success rate that is even going to = improve with remote tests
taking place = in the next few weeks.
Thank you all. I had a great = time at the interop and special thanks go
to = Roland and the University of Karlsruhe for doing a very good job = of
hosting this interop event.

Christian Dickmann


=

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

=

= --Apple-Mail-35-542738379-- --===============0354765778== 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 --===============0354765778==-- From nsis-bounces@ietf.org Tue Jun 26 08:30: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 1I3ABo-000146-Pi; Tue, 26 Jun 2007 08:30:36 -0400 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1I3ABn-000140-Cl for nsis-confirm+ok@megatron.ietf.org; Tue, 26 Jun 2007 08:30:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3ABn-00013r-31 for nsis@ietf.org; Tue, 26 Jun 2007 08:30:35 -0400 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3ABD-0007FD-EL for nsis@ietf.org; Tue, 26 Jun 2007 08:30:35 -0400 Received: from [10.1.1.109] (mito.netlab.nec.de [195.37.70.39]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 075D413CF81 for ; Tue, 26 Jun 2007 14:29:59 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <071568CA7B789D4AA170CEF8C9613B4FB11B80@daebe103.NOE.Nokia.com> References: <071568CA7B789D4AA170CEF8C9613B4FB11B80@daebe103.NOE.Nokia.com> Message-Id: From: Martin Stiemerling Subject: Re: [NSIS] WGLC:draft-ietf-nsis-qos-nslp-14.txt Date: Tue, 26 Jun 2007 14:29:58 +0200 To: nsis X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 6fc5b1c74c5bed09a3a9da2884900dec 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="===============2019841497==" Errors-To: nsis-bounces@ietf.org --===============2019841497== Content-Type: multipart/alternative; boundary=Apple-Mail-36-542851933 --Apple-Mail-36-542851933 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed [writing chair's hat off] Hi all, I have read the draft and think it is ready to take the next steps. Martin Am 12.06.2007 um 23:27 schrieb : > Jukka has updated the draft. We would like to start a 2 week > WGLC on the draft which will run through close of business on > June 25th. > > Please review the draft, and comment if you feel that this draft > is ready to be sent to the IESG. A simple mail saying that the > draft is ready for publication would be great. > > Of course, if you read the draft and find open issues, then please > send a summary of your issue with the current draft. > > thanks, > Martin and John > >> -----Original Message----- >> From: ext nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] >> Sent: 11 June, 2007 12:50 >> To: i-d-announce@ietf.org >> Cc: nsis@ietf.org >> Subject: [NSIS] I-D ACTION:draft-ietf-nsis-qos-nslp-14.txt >> >> A New Internet-Draft is available from the on-line >> Internet-Drafts directories. >> This draft is a work item of the Next Steps in Signaling >> Working Group of the IETF. >> >> Title : NSLP for Quality-of-Service Signaling >> Author(s) : J. Manner, et al. >> Filename : draft-ietf-nsis-qos-nslp-14.txt >> Pages : 97 >> Date : 2007-6-11 >> >> 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-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-qos-nslp-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-qos-nslp-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. >> > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis stiemerling@netlab.nec.de NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 --Apple-Mail-36-542851933 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1
[writing chair's hat = off]
Hi all,

I = have read the draft and think it is ready to take the next = steps.

=A0 = Martin

Am 12.06.2007 um 23:27 schrieb <john.loughney@nokia.com> = <john.loughney@nokia.com>:
Jukka has updated the draft.=A0 We would like to start a 2 = week
WGLC on the draft which will run = through close of business on
June = 25th.

Please review the draft, and comment if you feel = that this draft
is ready to be sent to the = IESG.=A0 A simple mail = saying that the
draft is ready for publication = would be great.

Of course, if you read the draft and find open = issues, then please
send a summary of your = issue with the current draft.

thanks,
Martin and John=A0

-----Original Message-----
From: ext nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org]=A0
Sent: 11 June, 2007 12:50
Subject: [NSIS] I-D = ACTION:draft-ietf-nsis-qos-nslp-14.txt=A0

A New = Internet-Draft is available from the on-line=A0
This draft is = a work item of the Next Steps in Signaling=A0
Working = Group of the IETF.
Title : NSLP for Quality-of-Service = Signaling
Author(s) : J. = Manner, et al.
Filename : = draft-ietf-nsis-qos-nslp-14.txt
= Pages = = : 97
Date : 2007-6-11


This = specification describes the NSIS Signaling Layer Protocol = (NSLP)
=A0 for signaling QoS = reservations in the Internet.=A0 = It is in accordance
=A0 with the framework and = requirements developed in NSIS. =A0
Together = with
=A0 GIST, it provides = functionality similar to RSVP and extends it.=A0 The
=A0 QoS = NSLP is independent of the underlying QoS specification or
=A0 = architecture and provides support for different reservation = models.
=A0 It is simplified by the = elimination of support for multicast flows.
=A0 This specification explains = the overall protocol approach, design
=A0 decisions made and provides = examples.=A0 It specifies = object, message
=A0 formats and processing = rules.

A URL for this Internet-Draft is:

To remove yourself from the I-D Announcement list, = send a=A0
message to i-d-announce-request@ietf.or= g with the word=A0
=A0
to = change your subscription settings.

Internet-Drafts are also = available by anonymous FTP. Login=A0
with the = username "anonymous" and a password of your e-mail=A0
address. = After logging in, type "cd internet-drafts" and then=A0
"get = draft-ietf-nsis-qos-nslp-14.txt".

A list of Internet-Drafts = directories can be found in=A0
Internet-Drafts can also be = obtained by e-mail.
Send a message to:
In the body type:
"FILE = /internet-drafts/draft-ietf-nsis-qos-nslp-14.txt".


NOTE: The mail = server at ietf.org can return the document in
MIME-encoded form by using the = "mpack" utility.=A0 To use = this
feature, insert the command = "ENCODING mime" before the "FILE"
= command.=A0 To = decode the response(s), you will need "munpack" or
a MIME-compliant mail = reader.=A0 Different = MIME-compliant=A0
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=A0
reader implementation to automatically retrieve the = ASCII=A0
version of the Internet-Draft.



nsis mailing list

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

=

= --Apple-Mail-36-542851933-- --===============2019841497== 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 --===============2019841497==-- From nsis-bounces@ietf.org Tue Jun 26 08:43: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 1I3ANv-0003l2-1k; Tue, 26 Jun 2007 08:43:07 -0400 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1I3ANs-0003c2-VH for nsis-confirm+ok@megatron.ietf.org; Tue, 26 Jun 2007 08:43:04 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3ANs-0003bt-L6 for nsis@ietf.org; Tue, 26 Jun 2007 08:43:04 -0400 Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I3ANs-0000ao-Co for nsis@ietf.org; Tue, 26 Jun 2007 08:43:04 -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 1I3ANJ-0001KC-FV; Tue, 26 Jun 2007 14:42:31 +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 466892FC097; Tue, 26 Jun 2007 14:42:29 +0200 (CEST) Received: from localhost ([127.0.0.1]) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.44) id 1I3ANI-0006bF-SM; Tue, 26 Jun 2007 14:42:28 +0200 Message-ID: <468109B4.2070102@tm.uka.de> Date: Tue, 26 Jun 2007 14:42:28 +0200 From: Roland Bless Organization: Institute of Telematics, University of Karlsruhe User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060111 Thunderbird/1.5 Mnenhy/0.7.3.0 MIME-Version: 1.0 To: Martin Stiemerling Subject: Re: [NSIS] WGLC:draft-ietf-nsis-qos-nslp-14.txt References: <071568CA7B789D4AA170CEF8C9613B4FB11B80@daebe103.NOE.Nokia.com> In-Reply-To: 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: 68c8cc8a64a9d0402e43b8eee9fc4199 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, Martin Stiemerling wrote: > [writing chair's hat off] > I have read the draft and think it is ready to take the next steps. I'm still reading the draft completely and will provide comments ASAP (scheduled for tomorrow). Sorry for not being able to make it in the WGLC time frame... Regards, Roland _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Jun 26 09:47: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 1I3BNm-0008Od-UJ; Tue, 26 Jun 2007 09:47:02 -0400 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1I3BNm-0008OY-6g for nsis-confirm+ok@megatron.ietf.org; Tue, 26 Jun 2007 09:47:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3BNl-0008OQ-TP for nsis@ietf.org; Tue, 26 Jun 2007 09:47:01 -0400 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3BN1-0005RU-HE for nsis@ietf.org; Tue, 26 Jun 2007 09:47:01 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l5QDQ3HO018056; Tue, 26 Jun 2007 16:26:22 +0300 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 Jun 2007 16:26:02 +0300 Received: from daebe104.NOE.Nokia.com ([10.241.36.13]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 Jun 2007 08:26:00 -0500 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 08:25:56 -0500 Message-ID: <19EBBEC503C3B5469070E0A6674A533A39B060@daebe104.NOE.Nokia.com> In-Reply-To: <468109B4.2070102@tm.uka.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] WGLC:draft-ietf-nsis-qos-nslp-14.txt Thread-Index: Ace375U6bCF2rcn7T/qPbAOyjEIsDwABedIw References: <071568CA7B789D4AA170CEF8C9613B4FB11B80@daebe103.NOE.Nokia.com> <468109B4.2070102@tm.uka.de> From: To: , X-OriginalArrivalTime: 26 Jun 2007 13:26:00.0030 (UTC) FILETIME=[8936F7E0:01C7B7F5] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org That's OK. =20 Anyone else who is still reading the draft? John=20 >-----Original Message----- >From: ext Roland Bless [mailto:bless@tm.uka.de]=20 >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 next steps. > >I'm still reading the draft completely and will provide=20 >comments ASAP (scheduled for tomorrow). Sorry for not being=20 >able to make it in the WGLC time frame... > >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 Tue Jun 26 09:58:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3BYo-0000rh-EV; Tue, 26 Jun 2007 09:58:26 -0400 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1I3BYn-0000rU-7r for nsis-confirm+ok@megatron.ietf.org; Tue, 26 Jun 2007 09:58:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3BYm-0000rL-US for nsis@ietf.org; Tue, 26 Jun 2007 09:58:24 -0400 Received: from mail.uc.pt ([193.137.200.38] helo=mail-2.ci.uc.pt) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3BYC-0003DK-Kk for nsis@ietf.org; Tue, 26 Jun 2007 09:58:24 -0400 Received: from mail-2.ci.uc.pt (mail.uc.pt [127.0.0.1]) by localhost.mail.uc.pt (Postfix) with ESMTP id 8FBB388DE35; Tue, 26 Jun 2007 14:57:43 +0100 (WEST) Received: from [127.0.0.1] (dhcp-eucpii-244.ci.uc.pt [193.136.207.244]) (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 70F4488DE30; Tue, 26 Jun 2007 14:57:43 +0100 (WEST) Message-ID: <46811B40.5090108@dei.uc.pt> Date: Tue, 26 Jun 2007 14:57:20 +0100 From: =?ISO-8859-1?Q?Lu=EDs_Cordeiro?= User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: john.loughney@nokia.com Subject: Re: [NSIS] WGLC:draft-ietf-nsis-qos-nslp-14.txt References: <071568CA7B789D4AA170CEF8C9613B4FB11B80@daebe103.NOE.Nokia.com> <468109B4.2070102@tm.uka.de> <19EBBEC503C3B5469070E0A6674A533A39B060@daebe104.NOE.Nokia.com> In-Reply-To: <19EBBEC503C3B5469070E0A6674A533A39B060@daebe104.NOE.Nokia.com> X-Spam-Score: 1.3 (+) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: stiemerling@netlab.nec.de, bless@tm.uka.de, nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0663276317==" Errors-To: nsis-bounces@ietf.org --===============0663276317== Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I am reading it. I will try also to give feedback tomorrow morning.

BR,
Luís Cordeiro

john.loughney@nokia.com wrote: 
That's OK.  

Anyone else who is still reading the draft?

John 

  
-----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 next steps.
      
I'm still reading the draft completely and will provide 
comments ASAP (scheduled for tomorrow). Sorry for not being 
able to make it in the WGLC time frame...

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
--===============0663276317== 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 --===============0663276317==-- From nsis-bounces@ietf.org Tue Jun 26 09:59: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 1I3BZf-00011n-39; Tue, 26 Jun 2007 09:59:19 -0400 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1I3BZd-00011i-Q1 for nsis-confirm+ok@megatron.ietf.org; Tue, 26 Jun 2007 09:59:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3BZd-00011a-GT for nsis@ietf.org; Tue, 26 Jun 2007 09:59:17 -0400 Received: from rsys001x.roke.co.uk ([193.118.201.108]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3BYo-0003Tm-JE for nsis@ietf.org; Tue, 26 Jun 2007 09:59:17 -0400 Received: from rsys005a.comm.ad.roke.co.uk ([193.118.193.85]) by rsys001x.roke.co.uk (8.13.1/8.13.1) with ESMTP id l5QDwM5j006900; Tue, 26 Jun 2007 14:58:22 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] WGLC:draft-ietf-nsis-qos-nslp-14.txt Date: Tue, 26 Jun 2007 14:58:39 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] WGLC:draft-ietf-nsis-qos-nslp-14.txt Thread-Index: Ace375U6bCF2rcn7T/qPbAOyjEIsDwABedIwAAEbbFA= References: <071568CA7B789D4AA170CEF8C9613B4FB11B80@daebe103.NOE.Nokia.com><468109B4.2070102@tm.uka.de> <19EBBEC503C3B5469070E0A6674A533A39B060@daebe104.NOE.Nokia.com> From: "Hancock, Robert" To: , , X-MailScanner-roke-co-uk: Found to be clean X-MailScanner-roke-co-uk-SpamCheck: X-MailScanner-From: robert.hancock@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab 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 all, 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). cheers, robert h.=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 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 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 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Jun 28 05:29: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 1I3qJJ-0001H7-UE; Thu, 28 Jun 2007 05:29:09 -0400 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1I3qJJ-0001H0-4h for nsis-confirm+ok@megatron.ietf.org; Thu, 28 Jun 2007 05:29:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3qJI-0001GE-9W for nsis@ietf.org; Thu, 28 Jun 2007 05:29:08 -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 1I3qIz-0003LJ-UN for nsis@ietf.org; Thu, 28 Jun 2007 05:29:08 -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; Thu, 28 Jun 2007 12:28:48 +0300 id 0005FEAF.46837F50.00000A6E Date: Thu, 28 Jun 2007 12:28:48 +0300 (EEST) From: Jukka MJ Manner To: "Hancock, Robert" Subject: Re: [NSIS] gist version -14 pre-draft In-Reply-To: Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab 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, about the conditional peering, we are fine with leaving it out of the current base spec. This is a somewhat more complex issue, and we have written a separate I-D about it: http://tools.ietf.org/wg/nsis/draft-manner-nsis-peering-data-00.txt If time permits, I'd like to present the work in Chicago. Regards, Jukka On Tue, 26 Jun 2007, Hancock, Robert wrote: > hi all, > > i have prepared a candidate gist version 14, taking into account the > last call discussions and interop issues. it is not yet submitted to the > secretariat, but can be found on-line here: > http://nsis.srmr.co.uk/nsis/draft-ietf-nsis-ntlp-14.txt > > the changes are, as ever, summarised in the change log. people might > like to see if i have understood the points and implemented useful > changes. (in several cases a last call comment was something like "does > this mean X?", and if the answer is 'yes' i treat that as a no-op.) > > a couple of points which might still be open: > > - jukka has raised some issues about conditional peering. my feeling is > that we have a basic capability already, and any further extensions > required can be implemented as 100% backwards compatible extensions > (mainly by changing the interface between NSLP and GIST). given the > guidance we have been given on controlling complexity, i'd prefer to > leave GIST as it is on this point. > > - roland has raised an issue about making the Hello-ID optional in > MA-Hello messages (only needed if R!=0 in the message). i think this is > probably technically feasible, but not clear whether everyone thinks it > makes things simpler and is happy to change message formats and rules at > this stage. if there's a clear view otherwise, it's a relatively simple > fix to make. > > i will be offline for the next few days, but intend to submit the real > version 14 in time for the -0n cutoff taking into account any final > comments up to then. > > cheers, > > robert h. > > > _______________________________________________ > 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 Jun 28 06:28:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3rEa-0004td-27; Thu, 28 Jun 2007 06:28:20 -0400 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1I3rEY-0004tE-Fz for nsis-confirm+ok@megatron.ietf.org; Thu, 28 Jun 2007 06:28:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3rEX-0004t6-Ga for nsis@ietf.org; Thu, 28 Jun 2007 06:28:17 -0400 Received: from web27808.mail.ukl.yahoo.com ([217.146.182.13]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I3rDg-0005qr-E5 for nsis@ietf.org; Thu, 28 Jun 2007 06:28:17 -0400 Received: (qmail 77975 invoked by uid 60001); 28 Jun 2007 10:20:43 -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:MIME-Version:Content-Type:Message-ID; b=RJhSid6g2sFrPBqppF5bngnSzPAqrEqEjeSvkotqYjVP3iFcQ/q2B5EhjIOgz/z0rbdSDBa7cPjrizS/svrGQarlMHRF0r95ZShc3qjJsgRfNS1UOGu0OQmqHJ9gQsw38xMSBJihsnfmB/OlIHqXMrYkc5cPou4xI2burSygaK0=; X-YMail-OSG: mAzKP8sVM1kzi59UGaPpzIq24F0ovWMjVRM.fH04SOBgX3P7yVzDAoGVpKo3niyeTh6CSJhr1MWUccmgX9X3QQiFcfvImzCdN6b9Q1rP3aHqGgxWyxXkxOF4Mo8- Received: from [192.35.17.21] by web27808.mail.ukl.yahoo.com via HTTP; Thu, 28 Jun 2007 10:20:43 GMT X-Mailer: YahooMailRC/651.29 YahooMailWebService/0.7.41.16 Date: Thu, 28 Jun 2007 10:20:43 +0000 (GMT) From: Mehmet Ersue Subject: RE: [NSIS] WGLC:draft-ietf-nsis-qos-nslp-14.txt To: nsis@ietf.org MIME-Version: 1.0 Message-ID: <347896.77489.qm@web27808.mail.ukl.yahoo.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 3971661e40967acfc35f708dd5f33760 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="===============1987504794==" Errors-To: nsis-bounces@ietf.org --===============1987504794== Content-Type: multipart/alternative; boundary="0-167812810-1183026043=:77489" --0-167812810-1183026043=:77489 Content-Type: text/plain; charset=ascii 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 > -----Original Message----- > From: Hancock, Robert [mailto:robert.hancock@roke.co.uk] > Sent: Tuesday, June 26, 2007 3:59 PM > To: john.loughney@nokia.com; bless@tm.uka.de; > stiemerling@netlab.nec.de > Cc: nsis@ietf.org > Subject: RE: [NSIS] WGLC:draft-ietf-nsis-qos-nslp-14.txt > > hi all, > > 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). > > cheers, > > robert h. > > > -----Original Message----- > > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > > 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 > > > > That's OK. > > > > Anyone else who is still reading the draft? > > > > John > > > > >-----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 > next steps. > > > > > >I'm still reading the draft completely and will provide > > comments ASAP > > >(scheduled for tomorrow). Sorry for not being able to make > it in the > > >WGLC time frame... > > > > > >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 > > > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > __________________________________ BE A BETTER WELTENBUMMLER: Jetzt Frage stellen und einen von 44 iPods gewinnen! www.yahoo.de/clever --0-167812810-1183026043=:77489 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable

Hi All,

just got through the QoS NSLP specification. It is re= adable and
reasonably complete. I can second Roberts statement not toput everything into one document.

Mehmet
 

> ---= --Original Message-----
> From: Hancock, Robert [mailto:robert.hancoc= k@roke.co.uk]
> Sent: Tuesday, June 26, 2007 3:59 PM
> To: joh= n.loughney@nokia.com; bless@tm.uka.de;
> stiemerling@netlab.nec.de> Cc: nsis@ietf.org
> Subject: RE: [NSIS] WGLC:draft-ietf-nsis-q= os-nslp-14.txt
>
> hi all,
>
> i've read the draf= t. basically i think it is ready to ship.
> we could all certainly th= ink of things to add, but I think actually
> as a core protocol it has the right balance b= etween completeness
> and conciseness; AFAICT anything i'd like to ad= d can be done as
> an extension (which is probably a good approach an= yway).
>
> cheers,
>
> robert h.
>
>= ; > -----Original Message-----
> > From: john.loughney@nokia.co= m [mailto:john.loughney@nokia.com]
> > 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-ns= lp-14.txt
> >
> > That's OK. 
> >
>= ; > Anyone else who is still reading the draft?
> >
> &g= t; John
> >
> > >-----Original Message-----
> = > >From: ext Roland Bless [mailto:bless@tm.uka.de]
> > >S= ent: 26 June, 2007 05:42
> > >To: Martin Stiemerling
> &g= t; >Cc: nsis
> > >Subject: Re: [NSIS] WGLC:draft-ietf-nsis-qos-nslp-14= .txt
> > >
> > >Hi,
> > >
> > = >Martin Stiemerling wrote:
> > >> [writing chair's hat of= f]
> > >> I have read the draft and think it is ready to tak= e the
> next steps.
> > >
> > >I'm still rea= ding the draft completely and will provide
> > comments ASAP
= > > >(scheduled for tomorrow). Sorry for not being able to make > it in the
> > >WGLC time frame...
> > >
= > > >Regards,
> > > Roland
> > >
> &= gt; >
> > >_______________________________________________> > >nsis mailing list
> > >nsis@ietf.org
&= gt; > >https://www1.ietf.org/mailman/listinfo/nsis
> = > >
> >
> >
> > _________________________________________= ______
> > nsis mailing list
> > nsis@ietf.org
&= gt; > https://www1.ietf.org/mailman/listinfo/nsis
> >=
>
>
> _______________________________________________=
> nsis mailing list
> nsis@ietf.org
> https://www1.= ietf.org/mailman/listinfo/nsis
>


=0A
Die besten Tipps und Tricks f=FCrs Grillen. = =0A=0ABE A BETTE= R GRILLMEISTER! --0-167812810-1183026043=:77489-- --===============1987504794== 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 --===============1987504794==-- From nsis-bounces@ietf.org Thu Jun 28 08:13: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 1I3ss5-0003xK-SO; Thu, 28 Jun 2007 08:13:13 -0400 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1I3ss3-0003wt-Q2 for nsis-confirm+ok@megatron.ietf.org; Thu, 28 Jun 2007 08:13:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3ss3-0003wh-GJ for nsis@ietf.org; Thu, 28 Jun 2007 08:13:11 -0400 Received: from smtp.mei.co.jp ([133.183.129.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3sry-0001Pm-TO for nsis@ietf.org; Thu, 28 Jun 2007 08:13:11 -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 l5SCD3Ih006141 for ; Thu, 28 Jun 2007 21:13:03 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx3) with ESMTP id l5SCD6w10880 for ; Thu, 28 Jun 2007 21:13:06 +0900 (JST) Received: from epochmail.jp.panasonic.com (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/astros) with ESMTP id l5SCD4T19749 for ; Thu, 28 Jun 2007 21:13:04 +0900 (JST) Received: by epochmail.jp.panasonic.com (8.12.11.20060308/3.7W/soml28) id l5SCD44g022036 for nsis@ietf.org; Thu, 28 Jun 2007 21:13:04 +0900 (JST) Received: from [10.68.136.102] by soml28.jp.panasonic.com (8.12.11.20060308/3.7W) with ESMTP id l5SCD2Th022019 for ; Thu, 28 Jun 2007 21:13:03 +0900 (JST) Date: Thu, 28 Jun 2007 21:14:18 +0900 From: Takako Sanda To: nsis@ietf.org Message-Id: <20070628204538.1246.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.24.02 [ja] X-Spam-Score: 0.1 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Subject: [NSIS] Request comments for Mobility draft 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, 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 From nsis-bounces@ietf.org Thu Jun 28 16:30: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 1I40dN-0004zH-8o; Thu, 28 Jun 2007 16:30:33 -0400 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1I40dM-0004zB-1p for nsis-confirm+ok@megatron.ietf.org; Thu, 28 Jun 2007 16:30:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I40dL-0004z3-OI for nsis@ietf.org; Thu, 28 Jun 2007 16:30:31 -0400 Received: from amailer.gwdg.de ([134.76.10.18]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I40cm-0006wB-Bi for nsis@ietf.org; Thu, 28 Jun 2007 16:30:31 -0400 Received: from p5b03a01e.dip0.t-ipconnect.de ([91.3.160.30] helo=[192.168.0.183]) by mailer.gwdg.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.66) (envelope-from ) id 1I40cf-0002tY-Sq; Thu, 28 Jun 2007 22:29:50 +0200 Message-ID: <46841A3A.1000500@cs.uni-goettingen.de> Date: Thu, 28 Jun 2007 22:29:46 +0200 From: Xiaoming Fu User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Martin Stiemerling 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> 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: 2beba50d0fcdeee5f091c59f204d4365 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, I have read the doc and think its reasonable to publish. Xiaoming Martin Stiemerling wrote: > Dear all, > > 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. > > Thanks, > > Martin > > Anfang der weitergeleiteten E-Mail: > >> *Von: *> >> *Datum: *12. Juni 2007 23:27:48 MESZ >> *An: *> >> *Betreff: **[NSIS] WGLC:draft-ietf-nsis-qos-nslp-14.txt * >> >> Jukka has updated the draft. We would like to start a 2 week >> WGLC on the draft which will run through close of business on >> June 25th. >> >> Please review the draft, and comment if you feel that this draft >> is ready to be sent to the IESG. A simple mail saying that the >> draft is ready for publication would be great. >> >> Of course, if you read the draft and find open issues, then please >> send a summary of your issue with the current draft. >> >> thanks, >> Martin and John >> >>> -----Original Message----- >>> From: ext nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] >>> Sent: 11 June, 2007 12:50 >>> To: i-d-announce@ietf.org >>> Cc: nsis@ietf.org >>> Subject: [NSIS] I-D ACTION:draft-ietf-nsis-qos-nslp-14.txt >>> >>> A New Internet-Draft is available from the on-line >>> Internet-Drafts directories. >>> This draft is a work item of the Next Steps in Signaling >>> Working Group of the IETF. >>> >>> Title : NSLP for Quality-of-Service Signaling >>> Author(s) : J. Manner, et al. >>> Filename : draft-ietf-nsis-qos-nslp-14.txt >>> Pages : 97 >>> Date : 2007-6-11 >>> >>> >>> 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-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-qos-nslp-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-qos-nslp-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. >>> >> >> >> _______________________________________________ >> nsis mailing list >> nsis@ietf.org >> https://www1.ietf.org/mailman/listinfo/nsis > > stiemerling@netlab.nec.de > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, > London W3 6BL | Registered in England 2832014 > > > ------------------------------------------------------------------------ > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Jun 29 07:30:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4EgK-0000mu-Br; Fri, 29 Jun 2007 07:30:32 -0400 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1I4EgJ-0000mp-FI for nsis-confirm+ok@megatron.ietf.org; Fri, 29 Jun 2007 07:30:31 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4EgJ-0000mh-42 for nsis@ietf.org; Fri, 29 Jun 2007 07:30:31 -0400 Received: from wa-out-1112.google.com ([209.85.146.181]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I4EgI-000204-KB for nsis@ietf.org; Fri, 29 Jun 2007 07:30:31 -0400 Received: by wa-out-1112.google.com with SMTP id k17so1317698waf for ; Fri, 29 Jun 2007 04:30:05 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:reply-to:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=Wan+wdA9Hm5uU3ELoOpKoCHY2ttx3gwE4GencyiMcInXBQscFjxFsk92ZurBrNaw/1+CxA6WEMKW/uFgT21AevUWl0Z23d3pYMHlcIvMIy+0biKLMA7/pvmDPSQzzNUymP6KYGdEGb/DJXw4Hh/V8cvk7fxE/1FF1fkx818XFgE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:reply-to:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=S7f5s5e6teMX8hKgEmb4Ck9ErekjX/2D59Rtfh3cpyDK2FRSW/gL5XWO2thN7rLYN+cyiXOyNk+1uxhhwt5A/O80dZCOhwg49DMd6XXGyCXNkAixyFRQgL81dJ3j+cND0rwYFDS3VHSMlrZUInRLHBP3xgat0pRLaV7pIAZSvlY= Received: by 10.115.89.1 with SMTP id r1mr2536704wal.1183116604634; Fri, 29 Jun 2007 04:30:04 -0700 (PDT) Received: by 10.114.175.7 with HTTP; Fri, 29 Jun 2007 04:30:04 -0700 (PDT) Message-ID: <515197b00706290430x10722d52qb11fd74fe2c5b945@mail.gmail.com> Date: Fri, 29 Jun 2007 12:30:04 +0100 From: "Vitor Bernardo" To: "Hancock, Robert" Subject: Re: [NSIS] gist version -14 pre-draft In-Reply-To: MIME-Version: 1.0 References: X-Google-Sender-Auth: 948d8b9d833a8b05 X-Spam-Score: 0.5 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: vmbern@student.dei.uc.pt List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0176688872==" Errors-To: nsis-bounces@ietf.org --===============0176688872== Content-Type: multipart/alternative; boundary="----=_Part_53765_8612326.1183116604579" ------=_Part_53765_8612326.1183116604579 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Robert, I was reading the candidate GISTv14. In my opinion, the document becomes easier to understand. For example, the new picture describing "Example of Operation" will certainly help the people who read the draft for the first time. All the clarifications will be also helpfully to prevent ambiguous implementations of GIST. *MA-Hello open issue:* As you said, making the Hello-ID always presents in MA-Hello messages seems to be technically feasible. On the other hand, make the Hello-ID optional it's very simple. So, if GIST can works without this "overhead", I think that it could improve the protocol. Congratulations for the good job! Let's go to IESG! -- BR, Vitor Bernardo On 6/26/07, Hancock, Robert wrote: > > hi all, > > i have prepared a candidate gist version 14, taking into account the > last call discussions and interop issues. it is not yet submitted to the > secretariat, but can be found on-line here: > http://nsis.srmr.co.uk/nsis/draft-ietf-nsis-ntlp-14.txt > > the changes are, as ever, summarised in the change log. people might > like to see if i have understood the points and implemented useful > changes. (in several cases a last call comment was something like "does > this mean X?", and if the answer is 'yes' i treat that as a no-op.) > > a couple of points which might still be open: > > - jukka has raised some issues about conditional peering. my feeling is > that we have a basic capability already, and any further extensions > required can be implemented as 100% backwards compatible extensions > (mainly by changing the interface between NSLP and GIST). given the > guidance we have been given on controlling complexity, i'd prefer to > leave GIST as it is on this point. > > - roland has raised an issue about making the Hello-ID optional in > MA-Hello messages (only needed if R!=0 in the message). i think this is > probably technically feasible, but not clear whether everyone thinks it > makes things simpler and is happy to change message formats and rules at > this stage. if there's a clear view otherwise, it's a relatively simple > fix to make. > > i will be offline for the next few days, but intend to submit the real > version 14 in time for the -0n cutoff taking into account any final > comments up to then. > > cheers, > > robert h. > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > ------=_Part_53765_8612326.1183116604579 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

Hi Robert,

I was reading the candidate GISTv14. In my opinion, the document becomes easier to understand. For example, the new picture describing "Example of Operation" will certainly help the people who read the draft for the first time. All the clarifications will be also helpfully to prevent ambiguous implementations of GIST.

MA-Hello open issue:

As you said, making the Hello-ID always presents in MA-Hello messages seems to be technically feasible. On the other hand, make the Hello-ID optional it's very simple. So, if GIST can works without this "overhead", I think that it could improve the protocol.


Congratulations for the good job! Let's go to IESG!

--
BR,
Vitor Bernardo



On 6/26/07, Hancock, Robert <robert.hancock@roke.co.uk> wrote:
hi all,

i have prepared a candidate gist version 14, taking into account the
last call discussions and interop issues. it is not yet submitted to the
secretariat, but can be found on-line here:
http://nsis.srmr.co.uk/nsis/draft-ietf-nsis-ntlp-14.txt

the changes are, as ever, summarised in the change log. people might
like to see if i have understood the points and implemented useful
changes. (in several cases a last call comment was something like "does
this mean X?", and if the answer is 'yes' i treat that as a no-op.)

a couple of points which might still be open:

- jukka has raised some issues about conditional peering. my feeling is
that we have a basic capability already, and any further extensions
required can be implemented as 100% backwards compatible extensions
(mainly by changing the interface between NSLP and GIST). given the
guidance we have been given on controlling complexity, i'd prefer to
leave GIST as it is on this point.

- roland has raised an issue about making the Hello-ID optional in
MA-Hello messages (only needed if R!=0 in the message). i think this is
probably technically feasible, but not clear whether everyone thinks it
makes things simpler and is happy to change message formats and rules at
this stage. if there's a clear view otherwise, it's a relatively simple
fix to make.

i will be offline for the next few days, but intend to submit the real
version 14 in time for the -0n cutoff taking into account any final
comments up to then.

cheers,

robert h.


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




------=_Part_53765_8612326.1183116604579-- --===============0176688872== 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 --===============0176688872==-- From nsis-bounces@ietf.org Fri Jun 29 07:32: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 1I4Eig-0007ho-2m; Fri, 29 Jun 2007 07:32:58 -0400 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1I4Eie-0007hZ-J6 for nsis-confirm+ok@megatron.ietf.org; Fri, 29 Jun 2007 07:32:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4Eie-0007hR-9Y for nsis@ietf.org; Fri, 29 Jun 2007 07:32:56 -0400 Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I4EiG-0005BQ-3E for nsis@ietf.org; Fri, 29 Jun 2007 07:32:56 -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 1I4EiD-00055y-MS; Fri, 29 Jun 2007 13:32:31 +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 8656E2FC097; Fri, 29 Jun 2007 13:32:29 +0200 (CEST) Received: from localhost ([127.0.0.1]) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.44) id 1I4EiD-0002uy-7d; Fri, 29 Jun 2007 13:32:29 +0200 Message-ID: <4684EDCC.4040902@tm.uka.de> Date: Fri, 29 Jun 2007 13:32:28 +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: 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.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: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Takako, Takako Sanda wrote: > 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 ;-) I'm also half through the draft and will give comments later since there are also some mistakes in section 4, e.g. the SII is not contained in any message... (but first I have to give comments to the QoS NSLP today). Regards, Roland _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis