From Stiemerling@nw.neclab.eu Tue Mar 3 02:08:26 2009 Return-Path: X-Original-To: nsis@core3.amsl.com Delivered-To: nsis@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F9DC3A6A15 for ; Tue, 3 Mar 2009 02:08:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.574 X-Spam-Level: X-Spam-Status: No, score=-2.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id py+47J2gZ6ZJ for ; Tue, 3 Mar 2009 02:08:25 -0800 (PST) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 392873A682E for ; Tue, 3 Mar 2009 02:08:25 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id D44102C01C95B for ; Tue, 3 Mar 2009 11:08:51 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CRFm6jOCYeuX for ; Tue, 3 Mar 2009 11:08:51 +0100 (CET) Received: from VENUS.office (mx1.office [192.168.24.3]) by smtp0.neclab.eu (Postfix) with ESMTP id B56A82C0004DA for ; Tue, 3 Mar 2009 11:08:46 +0100 (CET) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 3 Mar 2009 11:08:46 +0100 Message-ID: <547F018265F92642B577B986577D671C700536@VENUS.office> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Call for agenda items (IETF#74) Thread-Index: Acmb6AoQHUpaSzyQRHGSjhrSIa/ATA== From: "Martin Stiemerling" To: Subject: [NSIS] Call for agenda items (IETF#74) X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2009 10:08:26 -0000 Hi, The NSIS session has been scheduled for=20 1510-1610 Afternoon Session II Franciscan A TSV nsis Next Steps in Signaling WG Please let me know until March 5th 5PM CET if you need a slot in this = NSIS session. Martin stiemerling@nw.neclab.eu NEC Laboratories Europe - Network Research Division NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, = London W3 6BL | Registered in England 2832014=20 From elwynd@dial.pipex.com Tue Mar 3 16:49:25 2009 Return-Path: X-Original-To: nsis@core3.amsl.com Delivered-To: nsis@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D5DA3A6A2A for ; Tue, 3 Mar 2009 16:49:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.929 X-Spam-Level: X-Spam-Status: No, score=-99.929 tagged_above=-999 required=5 tests=[AWL=2.670, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6tkeMApg3QPn for ; Tue, 3 Mar 2009 16:49:24 -0800 (PST) Received: from a.painless.aaisp.net.uk (a.painless.aaisp.net.uk [IPv6:2001:8b0:0:30::51bb:1e33]) by core3.amsl.com (Postfix) with ESMTP id 128F73A67B4 for ; Tue, 3 Mar 2009 16:49:24 -0800 (PST) Received: from 247.254.187.81.in-addr.arpa ([81.187.254.247]) by a.painless.aaisp.net.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1LefIz-0004Cw-Gt; Wed, 04 Mar 2009 00:49:49 +0000 Message-ID: <49ADD17A.6050907@dial.pipex.com> Date: Wed, 04 Mar 2009 00:55:22 +0000 From: Elwyn Davies User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Martin Stiemerling References: <547F018265F92642B577B986577D671C5DC63F@VENUS.office><547F018265F92642B577B986577D671C5DC6D3@VENUS.office><4989DAFD.3060603@dial.pipex.com> <547F018265F92642B577B986577D671C698F13@VENUS.office> In-Reply-To: <547F018265F92642B577B986577D671C698F13@VENUS.office> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: nsis@ietf.org Subject: Re: [NSIS] Getting started on NSIS extensibilty draft X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2009 00:49:25 -0000 I am working on this and should have a new version out tomorrow. It appears to me that interception classes could benefit from an IANA registry since they need to be common across multiple imstantiations, although it is not strictly necessary as they never appear on the wire and are only used to communicate acros the API to GIST locally in each router. I guess we can do without but it might be good to ad a sentence to GIST to the effect that a registry is not needed. /Elwym Martin Stiemerling wrote: > Hi, > > We need especially fulfil the dependency of the GIST draft mentioned in Section 5.3.2.5. Q-Mode Interception Extensibility of GIST. > > The text there says: > Guidelines on defining interception classes are given in [13]. > > Where [13] is the extensibility document. > > Martin > > stiemerling@nw.neclab.eu > > NEC Laboratories Europe - Network Research Division > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 > > >> -----Original Message----- >> From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] On Behalf Of >> Jukka MJ Manner >> Sent: Friday, February 20, 2009 1:02 PM >> To: NSIS Working Group >> Subject: Re: [NSIS] Getting started on NSIS extensibilty draft >> >> >> Dear all, >> >> We would really need feedback to this draft to finalize it. I would >> like >> to issue a WGLC very soon, thus, one round of comments would be good to >> have before that. >> >> Alternatively, we can also issue a WGLC now, and discuss the comments >> in >> SF. Still, I'd rather see one round of comments before a WGLC. >> >> Regards, >> Jukka >> >> On Wed, 4 Feb 2009, Elwyn Davies wrote: >> >> >>> Hi, Magnus. >>> >>> At the last IETF you offered to provide me some guidance on the way >>> forward with this document. >>> >>> Since as I understand it, the IESG wants to see this document at the >>> same time as GIST this is urgent. >>> >>> The only suggestion I have stemming from comments at the meeting is >>> >> to >> >>> 'separate the rules and guidelines.' >>> >>> Any input gratefully received. >>> In the meantime I will try to make a 'null' update just to change the >>> title. >>> >>> Regards, >>> Elwyn >>> >>> Martin Stiemerling wrote: >>> >>>> The new file name should basically read this way (copy'n'paste >>>> >> error): >> >>>> draft-ietf-nsis-ext-00.txt. >>>> >>>> Thanks to Hannes for pointing this >>>> >>>> Martin >>>> >>>> stiemerling@nw.neclab.eu >>>> >>>> NEC Laboratories Europe - Network Research Division >>>> NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, >>>> >> London W3 6BL | Registered in England 2832014 >> >>>> >>>>> -----Original Message----- >>>>> From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] On >>>>> >> Behalf Of >> >>>>> Martin Stiemerling >>>>> Sent: Monday, January 26, 2009 3:05 PM >>>>> To: nsis@ietf.org >>>>> Subject: [NSIS] Getting started on NSIS extensibilty draft >>>>> >>>>> Dear all, >>>>> >>>>> We have a draft to be completed urgently :) >>>>> >>>>> Using and Extending the NSIS Protocol Family >>>>> draft-nsis-ext-02.txt >>>>> >>>>> http://tools.ietf.org/html/draft-nsis-ext-02 >>>>> >>>>> >>>>> First thing to do is changing the file name to draft-ietf-nsis- >>>>> >> ext- >> >>>>> 02.txt. >>>>> >>>>> Please review it and send your comments. >>>>> >>>>> Martin >>>>> >>>>> >>>>> stiemerling@nw.neclab.eu >>>>> >>>>> NEC Laboratories Europe - Network Research Division >>>>> NEC Europe Limited | Registered Office: NEC House, 1 Victoria >>>>> >> Road, >> >>>>> London W3 6BL | Registered in England 2832014 >>>>> >>>>> _______________________________________________ >>>>> nsis mailing list >>>>> nsis@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/nsis >>>>> >>>>> >>>> _______________________________________________ >>>> nsis mailing list >>>> nsis@ietf.org >>>> https://www.ietf.org/mailman/listinfo/nsis >>>> >>>> >>>> >>> _______________________________________________ >>> nsis mailing list >>> nsis@ietf.org >>> https://www.ietf.org/mailman/listinfo/nsis >>> >>> >> _______________________________________________ >> nsis mailing list >> nsis@ietf.org >> https://www.ietf.org/mailman/listinfo/nsis >> > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www.ietf.org/mailman/listinfo/nsis > > From root@core3.amsl.com Wed Mar 4 06:15:02 2009 Return-Path: X-Original-To: nsis@ietf.org Delivered-To: nsis@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id EE0B23A6C80; Wed, 4 Mar 2009 06:15:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090304141501.EE0B23A6C80@core3.amsl.com> Date: Wed, 4 Mar 2009 06:15:01 -0800 (PST) Cc: nsis@ietf.org Subject: [NSIS] I-D Action:draft-ietf-nsis-ext-01.txt X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2009 14:15:02 -0000 --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 : Using and Extending the NSIS Protocol Family Author(s) : J. Manner, et al. Filename : draft-ietf-nsis-ext-01.txt Pages : 25 Date : 2009-03-04 This document gives an overview of the Next Steps in Signaling (NSIS) framework and protocol suite created by the NSIS working group during the period 2001-2009 together with suggestions on how the industry can make use of the new protocols, and how the community can exploit the extensibility of both the framework and existing protocols to address future signaling needs. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nsis-ext-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-nsis-ext-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-03-04060350.I-D@ietf.org> --NextPart-- From elwynd@dial.pipex.com Wed Mar 4 06:16:44 2009 Return-Path: X-Original-To: nsis@core3.amsl.com Delivered-To: nsis@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C04BA28C2F3 for ; Wed, 4 Mar 2009 06:16:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.263 X-Spam-Level: X-Spam-Status: No, score=-100.263 tagged_above=-999 required=5 tests=[AWL=2.336, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ctl9wDAJ8Mk1 for ; Wed, 4 Mar 2009 06:16:44 -0800 (PST) Received: from b.painless.aaisp.net.uk (b.painless.aaisp.net.uk [IPv6:2001:8b0:0:30::51bb:1e34]) by core3.amsl.com (Postfix) with ESMTP id B664F3A6C7D for ; Wed, 4 Mar 2009 06:16:43 -0800 (PST) Received: from 247.254.187.81.in-addr.arpa ([81.187.254.247]) by b.painless.aaisp.net.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1LeruH-0003pN-24; Wed, 04 Mar 2009 14:17:09 +0000 Message-ID: <49AE8EB2.4040609@dial.pipex.com> Date: Wed, 04 Mar 2009 14:22:42 +0000 From: Elwyn Davies User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: nsis Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "Loughney John \(Nokia-NRC/Helsinki\)" , Roland Bless , MARTIN Stiemerling , Jukka MJ Manner Subject: [NSIS] Updated version of NSIS extensibility draft submitted (draft-ietf-nsis-ext-01) X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2009 14:16:44 -0000 Hi. I have updated the NSIS extensibility draft to take account of the comments from Martin and Hannes, plus making sure that it is clear what the IANA/IETF requirements ae for various types of extensions as well as providing guidelines. This last exercise is (I hope) in line with Magnus' comments at the last IETF. http://www.ietf.org/internet-drafts/draft-ietf-nsis-ext-01.txt Otherwise, the major change is to greatly extend the commentary on packet interception mechanism extensions. Please take a look: I think it is probably ready for WGLC, but if anybody has immediate concerns I can cycle another set of changes through before the draft deadline. Unfortunately I will not be at the nsis meeting (scheduled for Thursday) in San Francisco as I have to leave on Wednesday. Regards, Elwyn From gash5107@yahoo.com Wed Mar 4 09:30:27 2009 Return-Path: X-Original-To: nsis@core3.amsl.com Delivered-To: nsis@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C0C028C415 for ; Wed, 4 Mar 2009 09:30:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.264 X-Spam-Level: X-Spam-Status: No, score=-2.264 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BYyVqenvf+Kt for ; Wed, 4 Mar 2009 09:30:26 -0800 (PST) Received: from web63602.mail.re1.yahoo.com (web63602.mail.re1.yahoo.com [69.147.97.72]) by core3.amsl.com (Postfix) with SMTP id 3496328C3D7 for ; Wed, 4 Mar 2009 09:30:24 -0800 (PST) Received: (qmail 27866 invoked by uid 60001); 4 Mar 2009 17:30:52 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1236187852; bh=iLJCvomXdx5ucWlFqClmaMN1IbwpC15GuTRHNj3heL4=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=UmC1f64V6qiJRzruin5efffJ6kKXSS9E0sMCKYz3llIhkyH4ZgMt17ISoib9/beKZotJpeUfZBs4Ypmon4B7UOCxZxuOwekYfPqbJsZQLBWiJnDz5CABPNIUkd8iv5wGFON8itUg72EPmr7N78Am6J0+nTIoVWn1oXbhVG7qI4k= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=o63Hz3XGgLOsJ7CPHBG6UIiVmqLbe5t30CZCAFm1oImLMw/3JjLMoni4Nyy2ekZ0uqJloB8pzbyTBszubg0IVXQi4kVxwPebLX722r5zPaCSSpv4U5RE8ftpxfrVoJykL/Sd0S/82Om5+6CxQ8VMFq5Wg0oyy7TK9MvHmB0f4Ec=; Message-ID: <475082.26519.qm@web63602.mail.re1.yahoo.com> X-YMail-OSG: XJaExNsVM1l6ja3B6Mj7yEj9brciiwSY65OAxiqwIKpIIXvYfP5mMhkAKIkYFvSjJr3uqOkJbpJaFm9geYULJ4eqVOtDzEMhcspLbHa2d_CkoBS0xStVR_1DjjlD4Mg6tJlpqds40MasGoLuVUUILSr1FUMbMNdCj5Carw8YtXMtWMlCfQTqxheTb2SGrBVPdShUGjJ1IzkoOtqVfgDdc3PiIg-- Received: from [76.19.255.157] by web63602.mail.re1.yahoo.com via HTTP; Wed, 04 Mar 2009 09:30:52 PST X-Mailer: YahooMailWebService/0.7.289.1 Date: Wed, 4 Mar 2009 09:30:52 -0800 (PST) From: Gerald Ash To: nsis , Elwyn Davies In-Reply-To: <49AE8EB2.4040609@dial.pipex.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-480597616-1236187852=:26519" Subject: Re: [NSIS] Updated version of NSIS extensibility draft submitted (draft-ietf-nsis-ext-01) X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: gash5107@yahoo.com List-Id: Next Steps in Signaling List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2009 17:30:28 -0000 --0-480597616-1236187852=:26519 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Draft looks=A0good.=A0 Two comments: =A0 1. Section 8.4, last paragraph: =A0 "=A0 The QSpec Template supports situations where the QoS parameters need =A0=A0 to be fine-grained, specifically targeted to an individual flow in =A0=A0 one part of the network (typically the edge or access part) but migh= t =A0=A0 need to be more coarse-grained, where the flow is part of an =A0=A0 aggregate (typically in the core of the network)." =A0 This may be true, but=A0a) it's not explicitly discussed=A0in the QSPEC doc= ument, and b) it's not clear what it has to do with extensibility.=A0 Sugge= st that you substitute=A0some words more related to extensibility,=A0e.g., = the text in Section 3.2 regarding new versions of the qspec: =A0 "=A0 The QSPEC consists of a QSPEC version number and QSPEC objects.=A0 IAN= A =A0=A0 assigns a new QSPEC version number when changes that are not =A0=A0 backwards compatible are made to the QSPEC and this document is =A0=A0 reissued.=A0 Note that a new QSPEC version number is not needed when =A0=A0 new QSPEC parameters are specified.=A0 Later QSPEC versions MUST be =A0=A0 backward compatible with earlier QSPEC versions.=A0 That is, a versi= on =A0=A0 n+1 device must support QSPEC version n (or earlier).=A0 On the othe= r =A0=A0 hand, if a QSPEC version n (or earlier) device receives an NSLP =A0=A0 message specifying QSPEC version n+1, then the version n device =A0=A0 responds with an 'Incompatible QSPEC' error code (0x0f) response, as =A0=A0 discussed in Section 4.2.3, allowing the QNE that sent the NSLP =A0=A0 message to retry with a lower QSPEC version." =A0 2. Section 12.1 =A0 "=A0 [I-D.ietf-nsis-qspec] =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Bader, A., Kappler, C., and D. Oran= , "QoS NSLP QSPEC =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Template", draft-ietf-nsis-qspec-21= (work in progress), =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 November 2008." =A0 Please update to include the first=A0co-author (G. Ash) in that reference := -)=A0 I realized that the "automatic" pick-up in IETF tools doesn't work, a= nd they don't seem able to fix it.=A0 So please update it manually. =A0 Thanks, Jerry --- On Wed, 3/4/09, Elwyn Davies wrote: From: Elwyn Davies Subject: [NSIS] Updated version of NSIS extensibility draft submitted (draf= t-ietf-nsis-ext-01) To: "nsis" Cc: "Loughney John (Nokia-NRC/Helsinki)" , "Roland= Bless" , "MARTIN Stiemerling" ,= "Jukka MJ Manner" Date: Wednesday, March 4, 2009, 9:22 AM Hi. I have updated the NSIS extensibility draft to take account of the comments from Martin and Hannes, plus making sure that it is clear what the IANA/IETF requirements ae for various types of extensions as well as providing guidelines. This last exercise is (I hope) in line with Magnus' comments at the last IETF. http://www.ietf.org/internet-drafts/draft-ietf-nsis-ext-01.txt Otherwise, the major change is to greatly extend the commentary on packet interception mechanism extensions. Please take a look: I think it is probably ready for WGLC, but if anybody has immediate concerns I can cycle another set of changes through before the draft deadline. Unfortunately I will not be at the nsis meeting (scheduled for Thursday) in San Francisco as I have to leave on Wednesday. Regards, Elwyn _______________________________________________ nsis mailing list nsis@ietf.org https://www.ietf.org/mailman/listinfo/nsis =0A=0A=0A --0-480597616-1236187852=:26519 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Draft looks good.  Two comment= s:
 
1. Section 8.4, last paragraph:
 
"  The QSpec Template supports situations where the QoS parameter= s need
   to be fine-grained, specifically targeted to an indi= vidual flow in
   one part of the network (typically the edge = or access part) but might
   need to be more coarse-grained, w= here the flow is part of an
   aggregate (typically in the cor= e of the network)."
 
This may be true, but a) it's not explicitly discussed in th= e QSPEC document, and b) it's not clear what it has to do with extensibilit= y.  Suggest that you substitute some words more related to extens= ibility, e.g., the text in Section 3.2 regarding new versions of the q= spec:
 
"  The QSPEC consists of a QSPEC ver= sion number and QSPEC objects.  IANA

 &= nbsp; assigns a new QSPEC version number when changes that are not

 &= nbsp; backwards compatible are made to the QSPEC and this document i= s

 &= nbsp; reissued.  Note = that a new QSPEC version number is not needed when=

 &= nbsp; new QSPEC parameters are specified.  Later QSPEC versions MUST be<= /DIV>

 &= nbsp; backward compatible with earlier QSPEC versions.  That is, a version

 &= nbsp; n+1 device must support QSPEC version n (or earlier).  On the other

 &= nbsp; hand, if a QSPEC version n (or earlier) device receives an NSL= P

 &= nbsp; message specifying QSPEC version n+1, then the version n devic= e

 &= nbsp; responds with an 'Incompatible QSPEC' error code (0x0f) respon= se, as

 &= nbsp; discussed in Section 4.2.3, allowing the QNE that sent the NSL= P

 &= nbsp; message to retry with a lower QSPEC version."

 
2. Section 12.1
 
"  [I-D.ietf-nsis-qspec]
      &= nbsp;       Bader, A., Kappler, C., and D. Or= an, "QoS NSLP QSPEC
        &nbs= p;     Template", draft-ietf-nsis-qspec-21 (work in pro= gress),
          &nbs= p;   November 2008."
 
Please update to include the first co-author (G. Ash) in that ref= erence :-)  I realized that the "automatic" pick-up in IETF tools does= n't work, and they don't seem able to fix it.  So please update it man= ually.
 
Thanks,
Jerry

--- On Wed, 3/4/09, Elwyn Davies <elwynd@dial.pi= pex.com> wrote:
From: Elwyn Davies <elwynd@dial.pipex.com>
S= ubject: [NSIS] Updated version of NSIS extensibility draft submitted (draft= -ietf-nsis-ext-01)
To: "nsis" <nsis@ietf.org>
Cc: "Loughney Joh= n (Nokia-NRC/Helsinki)" <john.loughney@nokia.com>, "Roland Bless" <= ;bless@tm.uka.de>, "MARTIN Stiemerling" <stiemerling@nw.neclab.eu>= , "Jukka MJ Manner" <jmanner@cc.hut.fi>
Date: Wednesday, March 4, = 2009, 9:22 AM

Hi.

I have updated the NSIS extensibility draft to take account of the
comments from Martin and Hannes, plus making sure that it is clear what
the IANA/IETF requirements ae for various types of extensions as well as
providing guidelines.  This last exercise is (I hope) in line with
Magnus' comments at the last IETF.
http://www.ietf.org/internet-drafts/draft-ietf-nsis-ext-01.txt

Otherwise, the major change is to greatly extend the commentary on
packet interception mechanism extensions.

Please take a look:  I think it is probably ready for WGLC, but if
anybody has immediate concerns I can cycle another set of changes
through before the draft deadline.

Unfortunately I will not be at the nsis meeting (scheduled for Thursday)
in San Francisco as I have to leave on Wednesday.

Regards,
Elwyn
_______________________________________________
nsis mailing list
nsis@ietf.org
https://www.ietf.org/mailman/listinfo/nsis

=0A=0A --0-480597616-1236187852=:26519-- From Hannes.Tschofenig@gmx.net Wed Mar 4 10:12:29 2009 Return-Path: X-Original-To: nsis@core3.amsl.com Delivered-To: nsis@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A246928C413 for ; Wed, 4 Mar 2009 10:12:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.348 X-Spam-Level: X-Spam-Status: No, score=-2.348 tagged_above=-999 required=5 tests=[AWL=0.251, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QwRAKZj2uDy3 for ; Wed, 4 Mar 2009 10:12:28 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id EE84F28C407 for ; Wed, 4 Mar 2009 10:12:27 -0800 (PST) Received: (qmail invoked by alias); 04 Mar 2009 18:12:54 -0000 Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp036) with SMTP; 04 Mar 2009 19:12:54 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18NiY9bPRkNHUa6oy/MYnjDvar62jSn8SEady03WY U+jZPQGAxjxLgj From: "Hannes Tschofenig" To: "'Elwyn Davies'" , "'Martin Stiemerling'" References: <547F018265F92642B577B986577D671C5DC63F@VENUS.office><547F018265F92642B577B986577D671C5DC6D3@VENUS.office><4989DAFD.3060603@dial.pipex.com> <547F018265F92642B577B986577D671C698F13@VENUS.office> <49ADD17A.6050907@dial.pipex.com> Date: Wed, 4 Mar 2009 20:13:56 +0200 Message-ID: <00a401c99cf4$fc626570$0201a8c0@nsnintra.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 In-Reply-To: <49ADD17A.6050907@dial.pipex.com> Thread-Index: AcmcYyMF4cIm1KqRRwyRfgxvbX1cOgAkKP9A X-Y-GMX-Trusted: 0 X-FuHaFi: 0.53 Cc: nsis@ietf.org Subject: Re: [NSIS] Getting started on NSIS extensibilty draft X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2009 18:12:29 -0000 Hi Elwyn, Thanks for the draft update. The changes look good to me. Only a minor comment: 7. Security Features Basic security functions are provided at the GIST layer, e.g., protection against some blind or denial-of-service attacks. These security features are available with the the path-coupled MRM in the GIST specification. Other MRMs might provide different security features. Conceptually it is difficult to protect against on-path attacker and man-in-the-middle attacks, because a basic functionality of GIST is to discover yet unknown signaling peers. This is also only true for the path-coupled MRM. While GIST is handling authentication of peer nodes, more fine ... and basic authorization grained authentication may be required in the NSLP protocols. s/authentication/authorization There is currently an ongoing work to specify common authorization mechanisms to be used in NSLP protocols [I-D.manner-nsis-nslp-auth], thus allowing, e.g., per-user and per-service authorization. Ciao Hannes >-----Original Message----- >From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] On >Behalf Of Elwyn Davies >Sent: 04 March, 2009 02:55 >To: Martin Stiemerling >Cc: nsis@ietf.org >Subject: Re: [NSIS] Getting started on NSIS extensibilty draft > >I am working on this and should have a new version out tomorrow. > >It appears to me that interception classes could benefit from >an IANA registry since they need to be common across multiple >imstantiations, although it is not strictly necessary as they >never appear on the wire and are only used to communicate >acros the API to GIST locally in each router. I guess we can >do without but it might be good to ad a sentence to GIST to >the effect that a registry is not needed. > >/Elwym > >Martin Stiemerling wrote: >> Hi, >> >> We need especially fulfil the dependency of the GIST draft >mentioned in Section 5.3.2.5. Q-Mode Interception >Extensibility of GIST. >> >> The text there says: >> Guidelines on defining interception classes are given in [13]. >> >> Where [13] is the extensibility document. >> >> Martin >> >> stiemerling@nw.neclab.eu >> >> NEC Laboratories Europe - Network Research Division NEC >Europe Limited >> | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | >> Registered in England 2832014 >> >> >>> -----Original Message----- >>> From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] >On Behalf >>> Of Jukka MJ Manner >>> Sent: Friday, February 20, 2009 1:02 PM >>> To: NSIS Working Group >>> Subject: Re: [NSIS] Getting started on NSIS extensibilty draft >>> >>> >>> Dear all, >>> >>> We would really need feedback to this draft to finalize it. I would >>> like to issue a WGLC very soon, thus, one round of comments >would be >>> good to have before that. >>> >>> Alternatively, we can also issue a WGLC now, and discuss >the comments >>> in SF. Still, I'd rather see one round of comments before a WGLC. >>> >>> Regards, >>> Jukka >>> >>> On Wed, 4 Feb 2009, Elwyn Davies wrote: >>> >>> >>>> Hi, Magnus. >>>> >>>> At the last IETF you offered to provide me some guidance >on the way >>>> forward with this document. >>>> >>>> Since as I understand it, the IESG wants to see this >document at the >>>> same time as GIST this is urgent. >>>> >>>> The only suggestion I have stemming from comments at the meeting is >>>> >>> to >>> >>>> 'separate the rules and guidelines.' >>>> >>>> Any input gratefully received. >>>> In the meantime I will try to make a 'null' update just to change >>>> the title. >>>> >>>> Regards, >>>> Elwyn >>>> >>>> Martin Stiemerling wrote: >>>> >>>>> The new file name should basically read this way (copy'n'paste >>>>> >>> error): >>> >>>>> draft-ietf-nsis-ext-00.txt. >>>>> >>>>> Thanks to Hannes for pointing this >>>>> >>>>> Martin >>>>> >>>>> stiemerling@nw.neclab.eu >>>>> >>>>> NEC Laboratories Europe - Network Research Division NEC Europe >>>>> Limited | Registered Office: NEC House, 1 Victoria Road, >>>>> >>> London W3 6BL | Registered in England 2832014 >>> >>>>> >>>>>> -----Original Message----- >>>>>> From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] On >>>>>> >>> Behalf Of >>> >>>>>> Martin Stiemerling >>>>>> Sent: Monday, January 26, 2009 3:05 PM >>>>>> To: nsis@ietf.org >>>>>> Subject: [NSIS] Getting started on NSIS extensibilty draft >>>>>> >>>>>> Dear all, >>>>>> >>>>>> We have a draft to be completed urgently :) >>>>>> >>>>>> Using and Extending the NSIS Protocol Family >draft-nsis-ext-02.txt >>>>>> >>>>>> http://tools.ietf.org/html/draft-nsis-ext-02 >>>>>> >>>>>> >>>>>> First thing to do is changing the file name to draft-ietf-nsis- >>>>>> >>> ext- >>> >>>>>> 02.txt. >>>>>> >>>>>> Please review it and send your comments. >>>>>> >>>>>> Martin >>>>>> >>>>>> >>>>>> stiemerling@nw.neclab.eu >>>>>> >>>>>> NEC Laboratories Europe - Network Research Division NEC Europe >>>>>> Limited | Registered Office: NEC House, 1 Victoria >>>>>> >>> Road, >>> >>>>>> London W3 6BL | Registered in England 2832014 >>>>>> >>>>>> _______________________________________________ >>>>>> nsis mailing list >>>>>> nsis@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/nsis >>>>>> >>>>>> >>>>> _______________________________________________ >>>>> nsis mailing list >>>>> nsis@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/nsis >>>>> >>>>> >>>>> >>>> _______________________________________________ >>>> nsis mailing list >>>> nsis@ietf.org >>>> https://www.ietf.org/mailman/listinfo/nsis >>>> >>>> >>> _______________________________________________ >>> nsis mailing list >>> nsis@ietf.org >>> https://www.ietf.org/mailman/listinfo/nsis >>> >> _______________________________________________ >> nsis mailing list >> nsis@ietf.org >> https://www.ietf.org/mailman/listinfo/nsis >> >> >_______________________________________________ >nsis mailing list >nsis@ietf.org >https://www.ietf.org/mailman/listinfo/nsis > From root@core3.amsl.com Thu Mar 5 04:15:01 2009 Return-Path: X-Original-To: nsis@ietf.org Delivered-To: nsis@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 809AD3A69FA; Thu, 5 Mar 2009 04:15:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090305121501.809AD3A69FA@core3.amsl.com> Date: Thu, 5 Mar 2009 04:15:01 -0800 (PST) Cc: nsis@ietf.org Subject: [NSIS] I-D Action:draft-ietf-nsis-rmd-14.txt X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2009 12:15:01 -0000 --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-14.txt Pages : 99 Date : 2009-03-05 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-14.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-nsis-rmd-14.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-03-05040548.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Sun Mar 8 15:00:01 2009 Return-Path: X-Original-To: nsis@ietf.org Delivered-To: nsis@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id C3BE83A6A17; Sun, 8 Mar 2009 15:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090308220001.C3BE83A6A17@core3.amsl.com> Date: Sun, 8 Mar 2009 15:00:01 -0700 (PDT) Cc: nsis@ietf.org Subject: [NSIS] I-D Action:draft-ietf-nsis-ntlp-sctp-06.txt X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Mar 2009 22:00:01 -0000 --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 : General Internet Signaling Transport (GIST) over SCTP and Datagram TLS Author(s) : X. Fu, et al. Filename : draft-ietf-nsis-ntlp-sctp-06.txt Pages : 10 Date : 2009-03-08 The General Internet Signaling Transport (GIST) protocol currently uses TCP or TLS over TCP for connection mode operation. This document describes the usage of GIST over the Stream Control Transmission Protocol (SCTP) and Datagram Transport Layer Security (DTLS). The use of SCTP can take advantage of features provided by SCTP, namely streaming-based transport, support of multiple streams to avoid head of line blocking, the support of multi-homing to provide network level fault tolerance, as well as partial reliability extension for partially reliable data transmission. This document also specifies how to establish GIST security over datagram transport protocols using an extension to DTLS. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nsis-ntlp-sctp-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-nsis-ntlp-sctp-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-03-08145838.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Sun Mar 8 16:15:01 2009 Return-Path: X-Original-To: nsis@ietf.org Delivered-To: nsis@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 3C6393A68BA; Sun, 8 Mar 2009 16:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090308231501.3C6393A68BA@core3.amsl.com> Date: Sun, 8 Mar 2009 16:15:01 -0700 (PDT) Cc: nsis@ietf.org Subject: [NSIS] I-D Action:draft-ietf-nsis-ntlp-sctp-07.txt X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Mar 2009 23:15:01 -0000 --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 : General Internet Signaling Transport (GIST) over SCTP and Datagram TLS Author(s) : X. Fu, et al. Filename : draft-ietf-nsis-ntlp-sctp-07.txt Pages : 11 Date : 2009-03-08 The General Internet Signaling Transport (GIST) protocol currently uses TCP or TLS over TCP for connection mode operation. This document describes the usage of GIST over the Stream Control Transmission Protocol (SCTP) and Datagram Transport Layer Security (DTLS). The use of SCTP can take advantage of features provided by SCTP, namely streaming-based transport, support of multiple streams to avoid head of line blocking, the support of multi-homing to provide network level fault tolerance, as well as partial reliability extension for partially reliable data transmission. This document also specifies how to establish GIST security over datagram transport protocols using an extension to DTLS. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nsis-ntlp-sctp-07.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-nsis-ntlp-sctp-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-03-08160115.I-D@ietf.org> --NextPart-- From fu@cs.uni-goettingen.de Sun Mar 8 16:15:40 2009 Return-Path: X-Original-To: nsis@core3.amsl.com Delivered-To: nsis@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8EA0928C124 for ; Sun, 8 Mar 2009 16:15:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.649 X-Spam-Level: X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_34=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jKuIEPGqZqCE for ; Sun, 8 Mar 2009 16:15:39 -0700 (PDT) Received: from amailer.gwdg.de (amailer.gwdg.de [134.76.10.18]) by core3.amsl.com (Postfix) with ESMTP id 62B9A28C0E7 for ; Sun, 8 Mar 2009 16:15:39 -0700 (PDT) Received: from p5b039e62.dip0.t-ipconnect.de ([91.3.158.98] helo=[192.168.0.187]) by mailer.gwdg.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1LgSDu-0007Jm-T2; Mon, 09 Mar 2009 00:15:59 +0100 Message-ID: <49B452FD.1060005@cs.uni-goettingen.de> Date: Mon, 09 Mar 2009 00:21:33 +0100 From: Xiaoming Fu Organization: University of Goettingen, Germany User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Roland Bless References: <547F018265F92642B577B986577D671C5DC639@VENUS.office> <499A8542.9060504@tm.uka.de> In-Reply-To: <499A8542.9060504@tm.uka.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated: Id:xfu X-Virus-Scanned: (clean) by exiscan+sophie Cc: nsis@ietf.org Subject: Re: [NSIS] Starting WGLC on draft-ietf-nsis-ntlp-sctp-05.txt X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Mar 2009 23:15:40 -0000 Hi all, I just posted a latest update (v7) which hopefully addresses almost all (if not all) WGLC comments, including Roland's. Thanks for all your insightful reviews! Additional remarks to Roland's comments below: Roland Bless wrote: > Section 1: > * In the introduction: > - not clear whether one should also mention > the advantage of message-oriented transport by SCTP instead of > using the byte stream oriented TCP where one must provide its own > framing mechanisms. > - not clear at the end of the 2nd paragraph whether DTLS over SCTP > is also in scope of the draft or not. Fixed. > * typo s/extention/extension Fixed. > * PR-SCTP seems to be contradicting to the C-mode (reliable) transport > requirements of GIST at first. This must be clarified. C-mode does not need to be reliable: Per ntlp-17: Connection Mode (C-mode): A mode of sending GIST messages directly between nodes using point-to-point messaging associations (see below). Connection mode allows the re-use of existing transport and security protocols where such functionality is required. But yes, PR-SCTP is used for delivering C-mode messages. Clarified > Section 2: > SCTP Association: it could be mentioned in parentheses that the > transport addresses also contain the port number (same remark > as in RFC 4960) or that for an SCTP endpoint the following holds: > All transport addresses used by an SCTP endpoint must use the same > port number, but can use multiple IP addresses. A transport > address used by an SCTP endpoint must not be used by another SCTP > endpoint. In other words, a transport address is unique to an > SCTP endpoint. Ok > > > Section 3.1.1: > TLS as protocol specifier is not useful alone. It can only be specified > together with another protocol, e.g., Forwards-TCP+TLS. I think this is already clear from GIST spec itself, which we don't need to repeat here (?) > > Section 3.1.2: > "The destination information MUST..." it is not very clear which > destination information is meant, should be clarified that the > destination for establishing the SCTP association is meant here > (or SCTP endpoint destination). Fixed > > Section 3.3.: > It should be clarified under which circumstances the reliability > requirements for GIST C-mode messages are still met when PR-SCTP > is used. As far as I understood, the "timed reliability" > service is only one potential/special use case of PR-SCTP. Added clarification. > > Section 5.1: > To me it makes sense for the path-coupled MRI to limit the available > SCTP transport addresses to exactly the one from the NLI, so that > only this IP address is used for establishing the SCTP association. > This should also be mentioned in Section 3.1.2. Any text suggestion? The main concern is that a path-coupled MRI contains only one interface-address field? The interface-address must be routable, i.e. it MUST be usable as a destination IP address for packets to be sent back to the node generating the signalling message, whether in D-mode or C-mode. [ntlp-17] > > Section 6: > "For securing _a_ GIST over SCTP channel" > A little bit too short to discuss DTLS over SCTP. Forwards-DTLS > should be mentioned and motivated and why TLS+SCTP would be different. > It is not clear to me whether DTLS over SCTP is still "reliable". > DTLS would qualify as being secure but not reliable (GIST would require > to establish an MA for this, but I guess it also implies C-mode => > reliability?). clarified > > And finally: > What about NAT traversal issues with SCTP? IMHO there should be a short > section on discussing this. Can one simply use the NAT traversal object > of GIST etc.? Is there anything special? Tentatively added one section 6 (may be moved as subsection 5.3): however I'm not sure whether this is too heavy to have such section in this document. Any comments from other WG members? Xiaoming From Hannes.Tschofenig@gmx.net Mon Mar 9 02:34:28 2009 Return-Path: X-Original-To: nsis@core3.amsl.com Delivered-To: nsis@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E62683A6A64 for ; Mon, 9 Mar 2009 02:34:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[AWL=0.398, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rZ2A4FNkGrBF for ; Mon, 9 Mar 2009 02:34:28 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id AD4193A68DF for ; Mon, 9 Mar 2009 02:34:27 -0700 (PDT) Received: (qmail invoked by alias); 09 Mar 2009 09:35:00 -0000 Received: from unknown (EHLO 4FIL42860) [192.100.124.156] by mail.gmx.net (mp005) with SMTP; 09 Mar 2009 10:35:00 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18k/E1rc2wkVAbwjcxEsZ5dEHDg6pd2GErtL2THJT hzzUy18Lt8UArj From: "Hannes Tschofenig" To: Date: Mon, 9 Mar 2009 11:36:04 +0200 Message-ID: <058d01c9a09a$781a7f60$0201a8c0@nsnintra.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acmgem16oTjdU+YSR5m70yTxY08SLgAH5iFQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Y-GMX-Trusted: 0 X-FuHaFi: 0.5 Cc: nsis@ietf.org Subject: [NSIS] FW: I-D Action:draft-moore-nat-xc-02.txt X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2009 09:34:29 -0000 Hey Keith, Instead of defininig your own protocol you could the NSIS NATFW NSLP for this purpose. Running code is available. Here is the link: http://www.ietf.org/internet-drafts/draft-ietf-nsis-nslp-natfw-20.txt You might need to extend the NATFW NSLP based on your additional requirements. Ciao Hannes PS: Martin might have the link with the implementations for you. >-----Original Message----- >From: i-d-announce-bounces@ietf.org >[mailto:i-d-announce-bounces@ietf.org] On Behalf Of >Internet-Drafts@ietf.org >Sent: 09 March, 2009 07:45 >To: i-d-announce@ietf.org >Subject: I-D Action:draft-moore-nat-xc-02.txt > >A New Internet-Draft is available from the on-line >Internet-Drafts directories. > > Title : IPv4/v6 NAT With Explicit Control (NAT-XC) > Author(s) : K. Moore > Filename : draft-moore-nat-xc-02.txt > Pages : 38 > Date : 2009-03-08 > >This document describes a mechanism called NAT-XC (for NAT >with Explicit Control) for translating between IPv4 and IPv6. >NAT-XC is distinguished from other IPv4/IPv6 translations >schemes in that it separates the translation between IPv4 and >IPv6 from the management of address bindings for such a >translation; and is designed to allow applications to be >explicitly aware of, and control, their address bindings. >NAT-XC can be used by both IPv4 clients wishing to communicate >via IPv6, and IPv6 clients wishing to communicate via IPv4. >NAT-XC appears to be usable in a wide variety of scenarios >requiring communication across IPv4/IPv6 boundaries. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-moore-nat-xc-02.txt > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >Below is the data which will enable a MIME compliant mail >reader implementation to automatically retrieve the ASCII >version of the Internet-Draft. > From root@core3.amsl.com Mon Mar 9 03:45:06 2009 Return-Path: X-Original-To: nsis@ietf.org Delivered-To: nsis@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 68B7D3A6BF0; Mon, 9 Mar 2009 03:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090309104506.68B7D3A6BF0@core3.amsl.com> Date: Mon, 9 Mar 2009 03:45:01 -0700 (PDT) Cc: nsis@ietf.org Subject: [NSIS] I-D Action:draft-ietf-nsis-applicability-mobility-signaling-12.txt X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2009 10:45:06 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Next Steps in Signaling Working Group of the IETF. Title : Applicability Statement of NSIS Protocols in Mobile Environments Author(s) : T. Sanda, et al. Filename : draft-ietf-nsis-applicability-mobility-signaling-12.txt Pages : 50 Date : 2009-03-09 Mobility of an IP-based node affects routing paths, and as a result, can have a significant effect on the protocol operation and state management. This draft discusses the effects mobility can cause to the NSIS protocol suite, and how the protocols operate in different scenarios, with mobility management protocols. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nsis-applicability-mobility-signaling-12.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-nsis-applicability-mobility-signaling-12.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-03-09033451.I-D@ietf.org> --NextPart-- From jmanner@cs.Helsinki.FI Mon Mar 9 04:20:15 2009 Return-Path: X-Original-To: nsis@core3.amsl.com Delivered-To: nsis@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 03FFF3A6991 for ; Mon, 9 Mar 2009 04:20:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gwYPkJ6Brl9r for ; Mon, 9 Mar 2009 04:20:14 -0700 (PDT) Received: from mail.cs.helsinki.fi (courier.cs.helsinki.fi [128.214.9.1]) by core3.amsl.com (Postfix) with ESMTP id D59B63A6C1B for ; Mon, 9 Mar 2009 04:20:13 -0700 (PDT) Received: from melkki.cs.helsinki.fi (melkki.cs.helsinki.fi [128.214.9.98]) (TLS: TLSv1/SSLv3,256bits,AES256-SHA) by mail.cs.helsinki.fi with esmtp; Mon, 09 Mar 2009 13:20:45 +0200 id 00144152.49B4FB8D.00005328 Date: Mon, 9 Mar 2009 13:20:45 +0200 (EET) From: Jukka MJ Manner To: NSIS Working Group Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [NSIS] Errats on RFC 4230 X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2009 11:20:15 -0000 Dear all, Our WG has an open action point to fix some comments on our published RFC 4230 RSVP Security Properties. There are some editorial things, but a few technical comments. The authors of RFC 4230 should make the changes, but the WG could provide feedback: http://www.rfc-editor.org/errata_search.php?rfc=4230&rec_status=15&presentation=records ----------------------------------- Errata ID: 976 Status: Reported Type: Technical Reported By: Alfred Hoenes Date Reported: 2007-05-16 Section 3.2 says: The sending system needs to maintain the following attributes in such a security association [1]: [...] o Latest sequence number (received with this key identifier) It should say: The sending system needs to maintain the following attributes in such a security association [1]: [...] o Latest sequence number (sent with this key identifier) Notes: received --> sent ----------------------- Errata ID: 977 Status: Reported Type: Technical Reported By: Alfred Hoenes Date Reported: 2007-05-16 Section 3.4 says: [...]. The RSVP INTEGRITY object (outer object) covers the entire RSVP message, whereas the POLICY_DATA INTEGRITY object only covers objects within the POLICY_DATA element. It should say: [not submitted] Notes: The subsequent Figure 1 (on top of page 10) does *not* depict this security relevant object at all. Has there something been fost from Figure 1 ? --------------------------------- Regards, Jukka From root@core3.amsl.com Mon Mar 9 07:45:02 2009 Return-Path: X-Original-To: nsis@ietf.org Delivered-To: nsis@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 1EA873A6C55; Mon, 9 Mar 2009 07:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090309144502.1EA873A6C55@core3.amsl.com> Date: Mon, 9 Mar 2009 07:45:02 -0700 (PDT) Cc: nsis@ietf.org Subject: [NSIS] I-D Action:draft-ietf-nsis-ntlp-18.txt X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2009 14:45:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Next Steps in Signaling Working Group of the IETF. Title : GIST: General Internet Signalling Transport Author(s) : H. Schulzrinne, M. Stiemerling Filename : draft-ietf-nsis-ntlp-18.txt Pages : 153 Date : 2009-03-09 This document specifies protocol stacks for the routing and transport of per-flow signalling messages along the path taken by that flow through the network. The design uses existing transport and security protocols under a common messaging layer, the General Internet Signalling Transport (GIST), which provides a common service for diverse signalling applications. GIST does not handle signalling application state itself, but manages its own internal state and the configuration of the underlying transport and security protocols to enable the transfer of messages in both directions along the flow path. The combination of GIST and the lower layer transport and security protocols provides a solution for the base protocol component of the "Next Steps in Signalling" framework. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nsis-ntlp-18.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-nsis-ntlp-18.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-03-09073607.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Mon Mar 9 11:45:01 2009 Return-Path: X-Original-To: nsis@ietf.org Delivered-To: nsis@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id D55A03A6A8A; Mon, 9 Mar 2009 11:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090309184501.D55A03A6A8A@core3.amsl.com> Date: Mon, 9 Mar 2009 11:45:01 -0700 (PDT) Cc: nsis@ietf.org Subject: [NSIS] I-D Action:draft-ietf-nsis-ext-02.txt X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2009 18:45:01 -0000 --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 : Using and Extending the NSIS Protocol Family Author(s) : J. Manner, et al. Filename : draft-ietf-nsis-ext-02.txt Pages : 26 Date : 2009-03-09 This document gives an overview of the Next Steps in Signaling (NSIS) framework and protocol suite created by the NSIS working group during the period 2001-2009 together with suggestions on how the industry can make use of the new protocols, and how the community can exploit the extensibility of both the framework and existing protocols to address future signaling needs. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nsis-ext-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-nsis-ext-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-03-09113103.I-D@ietf.org> --NextPart-- From fu@cs.uni-goettingen.de Tue Mar 10 10:38:12 2009 Return-Path: X-Original-To: nsis@core3.amsl.com Delivered-To: nsis@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6BD343A68CC for ; Tue, 10 Mar 2009 10:38:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MncS-1hSZU5t for ; Tue, 10 Mar 2009 10:38:11 -0700 (PDT) Received: from amailer.gwdg.de (amailer.gwdg.de [134.76.10.18]) by core3.amsl.com (Postfix) with ESMTP id 649103A6825 for ; Tue, 10 Mar 2009 10:38:00 -0700 (PDT) Received: from s5.ifi.informatik.uni-goettingen.de ([134.76.81.25] helo=[172.23.0.1]) by mailer.gwdg.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1Lh5uT-0001GS-PN for nsis@ietf.org; Tue, 10 Mar 2009 18:38:33 +0100 Message-ID: <49B6A6DC.9090906@cs.uni-goettingen.de> Date: Tue, 10 Mar 2009 18:43:56 +0100 From: Xiaoming Fu Organization: University of Goettingen, Germany User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: nsis@ietf.org References: <20090309184501.D55A03A6A8A@core3.amsl.com> In-Reply-To: <20090309184501.D55A03A6A8A@core3.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated: Id:xfu X-Virus-Scanned: (clean) by exiscan+sophie Subject: Re: [NSIS] I-D Action:draft-ietf-nsis-ext-02.txt X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2009 17:38:12 -0000 Just a quick comment: I would envision an update of the extensibility document could consider potential use for off-path signaling, especially in the GIST section. Xiaoming Internet-Drafts@ietf.org wrote: > 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 : Using and Extending the NSIS Protocol Family > Author(s) : J. Manner, et al. > Filename : draft-ietf-nsis-ext-02.txt > Pages : 26 > Date : 2009-03-09 > > This document gives an overview of the Next Steps in Signaling (NSIS) > framework and protocol suite created by the NSIS working group during > the period 2001-2009 together with suggestions on how the industry > can make use of the new protocols, and how the community can exploit > the extensibility of both the framework and existing protocols to > address future signaling needs. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-nsis-ext-02.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > 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://www.ietf.org/mailman/listinfo/nsis From Hannes.Tschofenig@gmx.net Tue Mar 10 11:07:06 2009 Return-Path: X-Original-To: nsis@core3.amsl.com Delivered-To: nsis@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E14743A6407 for ; Tue, 10 Mar 2009 11:07:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.351 X-Spam-Level: X-Spam-Status: No, score=-2.351 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pFtSk63i1qoJ for ; Tue, 10 Mar 2009 11:07:06 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id A5D793A6A49 for ; Tue, 10 Mar 2009 11:07:04 -0700 (PDT) Received: (qmail invoked by alias); 10 Mar 2009 18:07:38 -0000 Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp057) with SMTP; 10 Mar 2009 19:07:38 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+LU7p00eaLG96EjbDAasP/xRnRhlJ7cnh9eynm9u QmbA0CkVLZ6+Wi From: "Hannes Tschofenig" To: References: <20090309184501.D55A03A6A8A@core3.amsl.com> Date: Tue, 10 Mar 2009 20:08:43 +0200 Message-ID: <082301c9a1ab$40303330$0201a8c0@nsnintra.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <20090309184501.D55A03A6A8A@core3.amsl.com> Thread-Index: Acmg59p4saqOlcoERkaEBkIKC306CQAwz0MQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Y-GMX-Trusted: 0 X-FuHaFi: 0.55 Subject: Re: [NSIS] I-D Action:draft-ietf-nsis-ext-02.txt X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2009 18:07:07 -0000 This version of the document addresses my comments. Thanks for the quick update, Elwyn. Ciao Hannes >-----Original Message----- >From: i-d-announce-bounces@ietf.org >[mailto:i-d-announce-bounces@ietf.org] On Behalf Of >Internet-Drafts@ietf.org >Sent: 09 March, 2009 20:45 >To: i-d-announce@ietf.org >Cc: nsis@ietf.org >Subject: I-D Action:draft-ietf-nsis-ext-02.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 : Using and Extending the NSIS Protocol Family > Author(s) : J. Manner, et al. > Filename : draft-ietf-nsis-ext-02.txt > Pages : 26 > Date : 2009-03-09 > >This document gives an overview of the Next Steps in Signaling >(NSIS) framework and protocol suite created by the NSIS >working group during the period 2001-2009 together with >suggestions on how the industry can make use of the new >protocols, and how the community can exploit the extensibility >of both the framework and existing protocols to address future >signaling needs. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-nsis-ext-02.txt > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >Below is the data which will enable a MIME compliant mail >reader implementation to automatically retrieve the ASCII >version of the Internet-Draft. > From elwynd@dial.pipex.com Tue Mar 10 11:24:40 2009 Return-Path: X-Original-To: nsis@core3.amsl.com Delivered-To: nsis@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E3D1328C1CD for ; Tue, 10 Mar 2009 11:24:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.917 X-Spam-Level: X-Spam-Status: No, score=-95.917 tagged_above=-999 required=5 tests=[AWL=-1.750, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_DYNAMIC_SPLIT_IP=3.493, HELO_EQ_IP_ADDR=1.119, RCVD_NUMERIC_HELO=2.067, RDNS_DYNAMIC=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id biDhQ2pQq9SI for ; Tue, 10 Mar 2009 11:24:40 -0700 (PDT) Received: from a.painless.aaisp.net.uk (a.painless.aaisp.net.uk [IPv6:2001:8b0:0:30::51bb:1e33]) by core3.amsl.com (Postfix) with ESMTP id 6A3DC28C1C5 for ; Tue, 10 Mar 2009 11:24:36 -0700 (PDT) Received: from 251.254.187.81.in-addr.arpa ([81.187.254.251]) by a.painless.aaisp.net.uk with esmtp (Exim 4.69) (envelope-from ) id 1Lh6dZ-0001xP-FB; Tue, 10 Mar 2009 18:25:09 +0000 Message-ID: <49B6B083.9090804@dial.pipex.com> Date: Tue, 10 Mar 2009 18:25:07 +0000 From: Elwyn Davies User-Agent: Thunderbird 2.0.0.14 (X11/20080421) MIME-Version: 1.0 To: Xiaoming Fu References: <20090309184501.D55A03A6A8A@core3.amsl.com> <49B6A6DC.9090906@cs.uni-goettingen.de> In-Reply-To: <49B6A6DC.9090906@cs.uni-goettingen.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: nsis@ietf.org Subject: Re: [NSIS] I-D Action:draft-ietf-nsis-ext-02.txt X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2009 18:24:41 -0000 Xiaoming Fu wrote: > Just a quick comment: I would envision an update of the extensibility > document could consider potential use for off-path signaling, > especially in the GIST section. > Xiaoming Hi. Thanks for the input. How much of a discussion would you think we should have? We have had considerable discussion of the possibilities of off-path signaling at least among the authors of the NATFW NSLP, but it would be a major change to how GIST works. I think we could make a 'passing mention' but going into too much detail is probably out of scope. The question is how elastic is extensibility? Regards, Elwyn > > Internet-Drafts@ietf.org wrote: >> 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 : Using and Extending the NSIS Protocol Family >> Author(s) : J. Manner, et al. >> Filename : draft-ietf-nsis-ext-02.txt >> Pages : 26 >> Date : 2009-03-09 >> >> This document gives an overview of the Next Steps in Signaling (NSIS) >> framework and protocol suite created by the NSIS working group during >> the period 2001-2009 together with suggestions on how the industry >> can make use of the new protocols, and how the community can exploit >> the extensibility of both the framework and existing protocols to >> address future signaling needs. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-nsis-ext-02.txt >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> 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://www.ietf.org/mailman/listinfo/nsis > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www.ietf.org/mailman/listinfo/nsis From jmanner@cs.Helsinki.FI Wed Mar 11 03:06:00 2009 Return-Path: X-Original-To: nsis@core3.amsl.com Delivered-To: nsis@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 473DF3A68E5 for ; Wed, 11 Mar 2009 03:06:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JPci7WYcoOvu for ; Wed, 11 Mar 2009 03:05:59 -0700 (PDT) Received: from mail.cs.helsinki.fi (courier.cs.helsinki.fi [128.214.9.1]) by core3.amsl.com (Postfix) with ESMTP id EDE683A67FF for ; Wed, 11 Mar 2009 03:05:58 -0700 (PDT) Received: from melkki.cs.helsinki.fi (melkki.cs.helsinki.fi [128.214.9.98]) (TLS: TLSv1/SSLv3,256bits,AES256-SHA) by mail.cs.helsinki.fi with esmtp; Wed, 11 Mar 2009 12:06:32 +0200 id 000D7B3F.49B78D29.000014D6 Date: Wed, 11 Mar 2009 12:06:32 +0200 (EET) From: Jukka MJ Manner To: NSIS Working Group Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [NSIS] NSLPs and Information (Code) Objects X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2009 10:06:00 -0000 Dear all, I was looking at the NSLP specs (out with Magnus, though) and the so-called Information Object in both NSLPs are rather close to each other. - Both have a 4-bit error class - Error code in QoS is 16 bits, Response code in NATFW is 8 bits - Many of error class-specific situations are alike 1. Would it make sense, when (if) the NSLPs are being accepted, to create a common IANA repository for NSLP error codes, e.g., an 8-bit value, and also the error class could be unified? 2. The QoS NSLP allows carrying the address of the node that noticed the error, and also send the erroneous object back to the sender. Would this functionality be needed in the NATFW, too? These are not big changes as such, but might we worth considering. Any feedback from the WG? Regards, Jukka From thuovila@cs.helsinki.fi Wed Mar 11 05:42:44 2009 Return-Path: X-Original-To: nsis@core3.amsl.com Delivered-To: nsis@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 817A03A68CF for ; Wed, 11 Mar 2009 05:42:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_64=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T6j02mndG6wv for ; Wed, 11 Mar 2009 05:42:43 -0700 (PDT) Received: from svm-13.cs.helsinki.fi (melkinpaasi.cs.helsinki.fi [128.214.11.93]) by core3.amsl.com (Postfix) with ESMTP id 8D27E3A6980 for ; Wed, 11 Mar 2009 05:42:42 -0700 (PDT) Received: by svm-13.cs.helsinki.fi (Postfix, from userid 52520) id E590914E9B2; Wed, 11 Mar 2009 14:43:10 +0200 (EET) Received: from localhost (localhost [127.0.0.1]) by svm-13.cs.helsinki.fi (Postfix) with ESMTP id DBBB514E9B1; Wed, 11 Mar 2009 14:43:10 +0200 (EET) Date: Wed, 11 Mar 2009 14:43:10 +0200 (EET) From: Teemu Huovila X-X-Sender: thuovila@localhost.localdomain To: Elwyn Davies In-Reply-To: <49B6B083.9090804@dial.pipex.com> Message-ID: References: <20090309184501.D55A03A6A8A@core3.amsl.com> <49B6A6DC.9090906@cs.uni-goettingen.de> <49B6B083.9090804@dial.pipex.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: nsis@ietf.org Subject: Re: [NSIS] I-D Action:draft-ietf-nsis-ext-02.txt X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2009 12:42:44 -0000 Hello I have read the -02 ext-draft. Predominantly it looks good to me. Only a couple of small issues and a bunch of possible typos caught my eye. The first issue is with the use of "MRMs" on page 6. The the abbreviation MRM (or even the concept of different message routing methods) is not explained anywhere earlier in the text. My suggestion is that, either remove the "MRMs" and use rest of the bullet as is, or somehow change it so that Message Routing Method is spelled out. Perhaps something like: "Initial focus on path-coupled signaling: GIST transports messages towards an identified unicast data flow destination based on the signaling application request. This is called the Path Coupled Message Routing Method (PC MRM). The framework also supports a "Loose-End" message routing method (i.e. LE MRM) used to discover GIST nodes with particular properties in the direction of a given address, for example the NAT/FW NSLP uses this method to discover a NAT along the upstream data path. GIST does not directly support path-decoupled signaling, e.g., QoS signaling to a bandwidth broker or other off-path resource manager." The second issue I have is with almost the whole section 8.6. The section does point out many central issues in NSLP design and implementation, but it is extremely vague. Many complicated concepts are only briefly mentioned or hinted at. Some of the more vague points might cause more confusion, than shed light. Finding a suitable level of abstraction for the descriptions is admittedly very difficult. To create any new, more than trivial, NSLP, I think one would have to understand large parts of the GIST spec, like the API, the MRMs, the MRI and flow identification and GIST peering. I would change at least the third to last bullet, e.g. "Source IP address: ...". It could say something more like: "MRI processing: It is sometimes challenging to find out at the NSLP, what the source IP address in the MRI should be, especially when a node has multiple interfaces. Moreover, the role of the source IP address may differ if the node processing an NSLP message is the source of the signaling flow, or an intermediate node on the signaling path. A node processing a received NSLP message also needs to take into account the MRI flow direction. So in many cases an NSLP application needs to be aware of its position and role on the signaling path and have some (,external to GIST,) means of finding out local IP addresses that are suitable for use in the signaling." Thanks to Lauri and Nuutti for their help on the new text. The other possible errors or typos are less important, so Ill just list them below: Page 5, second paragraph: "This is achieved by routing signaling massages.." refers to multiple messages, but later in the sentence and paragraph a single message is described. I suggest using message or messages consistently throughout the paragraph. Page 7, second line: "request also" --> "also request" Page 8, third paragraph: "requested by the new MA." Should this be "requested by the new flow." or "required by the potential new MA."? Page 8, last paragraph + page 9 first: The beginning of this paragraph is one extremely long sentence. It looks like it could benefit from being two or three separate ones. "Concerns were raised" clashes with "as well as discovery of", at least in my ear. Could it be written as: "Late in the development of GIST serious concerns were raised in the IETF about the security risks and performance implications of extensive usage of the RAO [I-D.rahman-rtg-router-alert-dangerous]. It was also discovered that several existing implementations of RAO were inconsistent with the standards and would not support the NSIS usage." Page 9, fourth paragraph: "NSIS state is held both at the signaling application layer and in the transport layer.." I would add "signaling" before "transport layer", since it is used before the "application". Then it becomes clearer, that the ntlp layer is the referred transport layer. Page 10, last paragraph: should the "support of" bits be "support for"? Page 12, fourth paragraph: "signalled" --> "signaled" (or change two other signaled in the document to signalled"?) Page 16, second bullet: The DCCP draft is mentioned, but not the SCTP one. The SCTP draft is not even referenced in this document. Page 17: is "interception scheme" the same as "interception class mechanism" or "interception mechanism". Could one expression be used consistently through the text describing interception schemes and classes? Page 21, first paragraph: "Yet, on the other hand" --> "Yet" or "On the other hand" Page 21, second bullet: "than can from GIST" --> "that can arrive from GIST" Page 21, last bullet: "defines currently" --> "currently defines". Page 22, bullet at top of page: "and prevent" --> "and to prevent" Several places(page 6 and 15) in the text use the expression "in future". I am not certain, but should it not be "in the future" in these contexts? br, Teemu -- Teemu Huovila From bless@tm.uka.de Wed Mar 11 11:38:47 2009 Return-Path: X-Original-To: nsis@core3.amsl.com Delivered-To: nsis@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B1DC93A6A74 for ; Wed, 11 Mar 2009 11:38:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.949 X-Spam-Level: X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OqfDLNl8uV9D for ; Wed, 11 Mar 2009 11:38:47 -0700 (PDT) Received: from iramx2.ira.uni-karlsruhe.de (iramx2.ira.uni-karlsruhe.de [141.3.10.81]) by core3.amsl.com (Postfix) with ESMTP id D72A53A684C for ; Wed, 11 Mar 2009 11:38:46 -0700 (PDT) Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5]) by iramx2.ira.uni-karlsruhe.de with esmtps id 1LhTKn-0006zF-Bt; Wed, 11 Mar 2009 19:39:22 +0100 Received: from i72ms.tm.uni-karlsruhe.de ([141.3.70.5] helo=smtp.ipv6.tm.uni-karlsruhe.de) by irams1.ira.uni-karlsruhe.de with esmtps id 1LhTKn-0006qG-6i; Wed, 11 Mar 2009 19:39:17 +0100 Received: from vorta.tm.uka.de (vorta.ipv6.tm.uni-karlsruhe.de [IPv6:2001:638:204:6:21b:fcff:fe96:fe02]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id 1ED8F2FC037; Wed, 11 Mar 2009 19:39:17 +0100 (CET) Received: from [127.0.0.1] (localhost [127.0.0.1]) by vorta.tm.uka.de (Postfix) with ESMTP id E27E110236; Wed, 11 Mar 2009 19:39:16 +0100 (CET) Message-ID: <49B80554.5040805@tm.uka.de> Date: Wed, 11 Mar 2009 19:39:16 +0100 From: Roland Bless Organization: Institute of Telematics, University of Karlsruhe User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060111 Thunderbird/1.5 Mnenhy/0.7.3.0 MIME-Version: 1.0 To: Xiaoming Fu References: <20090309184501.D55A03A6A8A@core3.amsl.com> <49B6A6DC.9090906@cs.uni-goettingen.de> In-Reply-To: <49B6A6DC.9090906@cs.uni-goettingen.de> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ATIS-AV: ClamAV (irams1.ira.uni-karlsruhe.de) X-ATIS-AV: ClamAV (iramx2.ira.uni-karlsruhe.de) X-ATIS-AV: Kaspersky (iramx2.ira.uni-karlsruhe.de) Cc: nsis@ietf.org Subject: Re: [NSIS] I-D Action:draft-ietf-nsis-ext-02.txt X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2009 18:38:47 -0000 Hi Xiaomin, Xiaoming Fu wrote: > Just a quick comment: I would envision an update of the extensibility > document could consider potential use for off-path signaling, especially > in the GIST section. > Xiaoming This should be already covered: Section 8.2: o Use of different Message Routing Methods: currently only two message routing methods are supported (Path-coupled MRM and Loose- End MRM), but further MRMs may be defined in the future. See Section 3.8. One possible additional MRM under development is documented in [I-D.bless-nsis-est-mrm]. EST-MRM is effectively a path-decoupled MRM. Section 8.3: Another current proposal seeks to extend the whole NSIS framework towards path-decoupled signaling and QoS reservations [I-D.cordeiro-nsis-hypath]. Or what is missing from your point of view? Regards, Roland From fu@cs.uni-goettingen.de Fri Mar 13 10:28:22 2009 Return-Path: X-Original-To: nsis@core3.amsl.com Delivered-To: nsis@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 20E633A67F5 for ; Fri, 13 Mar 2009 10:28:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VLqlbyotT5Dw for ; Fri, 13 Mar 2009 10:28:21 -0700 (PDT) Received: from amailer.gwdg.de (amailer.gwdg.de [134.76.10.18]) by core3.amsl.com (Postfix) with ESMTP id 5D6ED3A688B for ; Fri, 13 Mar 2009 10:28:21 -0700 (PDT) Received: from s5.ifi.informatik.uni-goettingen.de ([134.76.81.25] helo=[172.23.0.1]) by mailer.gwdg.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1LiBBm-0005bO-74; Fri, 13 Mar 2009 18:28:54 +0100 Message-ID: <49BA9919.40204@cs.uni-goettingen.de> Date: Fri, 13 Mar 2009 18:34:17 +0100 From: Xiaoming Fu Organization: University of Goettingen, Germany User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Roland Bless References: <20090309184501.D55A03A6A8A@core3.amsl.com> <49B6A6DC.9090906@cs.uni-goettingen.de> <49B80554.5040805@tm.uka.de> In-Reply-To: <49B80554.5040805@tm.uka.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated: Id:xfu X-Virus-Scanned: (clean) by exiscan+sophie Cc: nsis@ietf.org Subject: Re: [NSIS] I-D Action:draft-ietf-nsis-ext-02.txt X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2009 17:28:22 -0000 Roland Bless wrote: > Hi Xiaomin, > > Xiaoming Fu wrote: >> Just a quick comment: I would envision an update of the extensibility >> document could consider potential use for off-path signaling, especially >> in the GIST section. >> Xiaoming > > This should be already covered: > Section 8.2: > > o Use of different Message Routing Methods: currently only two > message routing methods are supported (Path-coupled MRM and Loose- > End MRM), but further MRMs may be defined in the future. See > Section 3.8. One possible additional MRM under development is > documented in [I-D.bless-nsis-est-mrm]. > > EST-MRM is effectively a path-decoupled MRM. maybe worth making it clearer: firstly tell what does a path-decoupled MRM basically mean, then possibly an example... (comparison: while talking about path-coupled and loosely-coupled ones there is some text) Xiaoming > > Section 8.3: > > Another current proposal > seeks to extend the whole NSIS framework towards path-decoupled > signaling and QoS reservations [I-D.cordeiro-nsis-hypath]. > > Or what is missing from your point of view? > > Regards, > Roland From bless@tm.uka.de Sun Mar 22 11:28:28 2009 Return-Path: X-Original-To: nsis@core3.amsl.com Delivered-To: nsis@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED42D28C117 for ; Sun, 22 Mar 2009 11:28:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.499 X-Spam-Level: X-Spam-Status: No, score=-4.499 tagged_above=-999 required=5 tests=[AWL=-1.450, BAYES_50=0.001, HELO_EQ_DE=0.35, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nHzJzEvUK0NW for ; Sun, 22 Mar 2009 11:28:28 -0700 (PDT) Received: from iramx2.ira.uni-karlsruhe.de (iramx2.ira.uni-karlsruhe.de [141.3.10.81]) by core3.amsl.com (Postfix) with ESMTP id 5A09128C18F for ; Sun, 22 Mar 2009 11:28:08 -0700 (PDT) Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5]) by iramx2.ira.uni-karlsruhe.de with esmtps id 1LlSPl-0007YX-Pp for ; Sun, 22 Mar 2009 19:28:56 +0100 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 1LlSPl-00015e-ME; Sun, 22 Mar 2009 19:28:53 +0100 Received: from vorta.tm.uka.de (vorta.ipv6.tm.uni-karlsruhe.de [IPv6:2001:638:204:6:21b:fcff:fe96:fe02]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id 973062FC037 for ; Sun, 22 Mar 2009 19:28:53 +0100 (CET) Received: from [127.0.0.1] (localhost [127.0.0.1]) by vorta.tm.uka.de (Postfix) with ESMTP id 2CEA01043C for ; Sun, 22 Mar 2009 19:28:52 +0100 (CET) Message-ID: <49C68363.4010206@tm.uka.de> Date: Sun, 22 Mar 2009 19:28:51 +0100 From: Roland Bless Organization: Institute of Telematics, University of Karlsruhe User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060111 Thunderbird/1.5 Mnenhy/0.7.3.0 MIME-Version: 1.0 To: "nsis@ietf.org" X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-ATIS-AV: ClamAV (irams1.ira.uni-karlsruhe.de) X-ATIS-AV: ClamAV (iramx2.ira.uni-karlsruhe.de) X-ATIS-AV: Kaspersky (iramx2.ira.uni-karlsruhe.de) Subject: [NSIS] NSIS mobility X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2009 18:28:29 -0000 Hi, just to spread some positive news: we got running code for using QoS NSLP with mobile nodes (using MobileIPv6 as mobility protocol). One of the main motivations for NSIS was that RSVP is not really capable of working well in mobile environments whereas we showed now that GIST+QoS NSLP are able to work just fine. Our forthcoming paper "QoS Support for Mobile Users using NSIS" at Networking 2009 provides an overview: http://www.networking-2009.org/programme/programme.html#session-1_4 We also have more details (e.g., a technical report) available at http://nsis-ka.org/ Regards, Roland From bless@tm.uka.de Sun Mar 22 13:23:58 2009 Return-Path: X-Original-To: nsis@core3.amsl.com Delivered-To: nsis@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 08AC93A68EC for ; Sun, 22 Mar 2009 13:23:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.616 X-Spam-Level: X-Spam-Status: No, score=-5.616 tagged_above=-999 required=5 tests=[AWL=0.633, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kDwDLZ9HrnN2 for ; Sun, 22 Mar 2009 13:23:57 -0700 (PDT) Received: from iramx2.ira.uni-karlsruhe.de (iramx2.ira.uni-karlsruhe.de [141.3.10.81]) by core3.amsl.com (Postfix) with ESMTP id 3BA513A6888 for ; Sun, 22 Mar 2009 13:23:57 -0700 (PDT) Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5]) by iramx2.ira.uni-karlsruhe.de with esmtps id 1LlUDr-0004Oq-EF for ; Sun, 22 Mar 2009 21:24:45 +0100 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 1LlUDr-0006eT-Av; Sun, 22 Mar 2009 21:24:43 +0100 Received: from vorta.tm.uka.de (vorta.ipv6.tm.uni-karlsruhe.de [IPv6:2001:638:204:6:21b:fcff:fe96:fe02]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id 4156C2FC037 for ; Sun, 22 Mar 2009 21:24:43 +0100 (CET) Received: from [127.0.0.1] (localhost [127.0.0.1]) by vorta.tm.uka.de (Postfix) with ESMTP id BEA821043D for ; Sun, 22 Mar 2009 21:24:42 +0100 (CET) Message-ID: <49C69E89.1050201@tm.uka.de> Date: Sun, 22 Mar 2009 21:24:41 +0100 From: Roland Bless Organization: Institute of Telematics, University of Karlsruhe User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060111 Thunderbird/1.5 Mnenhy/0.7.3.0 MIME-Version: 1.0 To: "nsis@ietf.org" X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-ATIS-AV: ClamAV (irams1.ira.uni-karlsruhe.de) X-ATIS-AV: ClamAV (iramx2.ira.uni-karlsruhe.de) X-ATIS-AV: Kaspersky (iramx2.ira.uni-karlsruhe.de) Subject: [NSIS] Ad-hoc interop X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2009 20:23:58 -0000 Hi, I'm in SF right now, so if someone wants to have a small GIST interop, I'd be happy to exchange some packets. Just stop by if you see me or contact me via jabber (same address as my mail) or mail. Regards, Roland From root@core3.amsl.com Mon Mar 23 14:45:01 2009 Return-Path: X-Original-To: nsis@ietf.org Delivered-To: nsis@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id DDBA13A69FA; Mon, 23 Mar 2009 14:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090323214501.DDBA13A69FA@core3.amsl.com> Date: Mon, 23 Mar 2009 14:45:01 -0700 (PDT) Cc: nsis@ietf.org Subject: [NSIS] I-D Action:draft-ietf-nsis-ntlp-19.txt X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2009 21:45:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Next Steps in Signaling Working Group of the IETF. Title : GIST: General Internet Signalling Transport Author(s) : H. Schulzrinne, M. Stiemerling Filename : draft-ietf-nsis-ntlp-19.txt Pages : 153 Date : 2009-03-23 This document specifies protocol stacks for the routing and transport of per-flow signalling messages along the path taken by that flow through the network. The design uses existing transport and security protocols under a common messaging layer, the General Internet Signalling Transport (GIST), which provides a common service for diverse signalling applications. GIST does not handle signalling application state itself, but manages its own internal state and the configuration of the underlying transport and security protocols to enable the transfer of messages in both directions along the flow path. The combination of GIST and the lower layer transport and security protocols provides a solution for the base protocol component of the "Next Steps in Signalling" framework. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nsis-ntlp-19.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-nsis-ntlp-19.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-03-23143349.I-D@ietf.org> --NextPart--