From Sebastian.Kiesel@nw.neclab.eu Mon Jul 6 03:03:07 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 AB05C3A6C6C for ; Mon, 6 Jul 2009 03:03:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.561 X-Spam-Level: X-Spam-Status: No, score=-2.561 tagged_above=-999 required=5 tests=[AWL=0.038, 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 ZITeJ4SFBWBp for ; Mon, 6 Jul 2009 03:03:06 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id BEDD33A6832 for ; Mon, 6 Jul 2009 03:03:06 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id B2D642C02049F for ; Mon, 6 Jul 2009 11:35:40 +0200 (CEST) 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 1-uDfgz0uCEx for ; Mon, 6 Jul 2009 11:35:40 +0200 (CEST) Received: from VENUS.office (mx2.office [192.168.24.15]) by smtp0.neclab.eu (Postfix) with ESMTP id 92F5E2C0004E5 for ; Mon, 6 Jul 2009 11:35:35 +0200 (CEST) Received: from foo.nw.neclab.eu ([10.1.6.240]) by VENUS.office with Microsoft SMTPSVC(6.0.3790.3959); Mon, 6 Jul 2009 11:35:30 +0200 Received: by foo.nw.neclab.eu (sSMTP sendmail emulation); Mon, 06 Jul 2009 11:35:29 +0200 Date: Mon, 6 Jul 2009 11:35:29 +0200 From: Sebastian Kiesel To: NSIS Working Group Message-ID: <20090706093529.GB23298@foo.nw.neclab.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.18 (2008-05-17) X-OriginalArrivalTime: 06 Jul 2009 09:35:30.0687 (UTC) FILETIME=[1A6170F0:01C9FE1D] Subject: [NSIS] fwd: New Version Notification for draft-kiesel-mmusic-firewall-sip-00 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, 06 Jul 2009 10:03:07 -0000 Dear NSIS WG members, (announcement sent to NSIS and MMUSIC lists) this draft examines how the NSIS NATFW NSLP (and other firewall control protocols) work together with SIP, especially if something goes wrong. The conclusion is basically that the normal SIP mechanisms are not sufficient to handle all error conditions in a reasonable way, and therefore a new SIP precondition should be standardized. This would be the turf of the mmusic WG, therefore comments should go to the mmusic list. Thanks, Sebastian ----- Forwarded message from IETF I-D Submission Tool ----- From: IETF I-D Submission Tool To: sebastian.kiesel@nw.neclab.eu Subject: New Version Notification for draft-kiesel-mmusic-firewall-sip-00 Date: Mon, 6 Jul 2009 01:26:17 -0700 (PDT) A new version of I-D, draft-kiesel-mmusic-firewall-sip-00.txt has been successfuly submitted by Sebastian Kiesel and posted to the IETF repository. Filename: draft-kiesel-mmusic-firewall-sip Revision: 00 Title: Interaction of dynamic firewall control protocols and SIP Creation_date: 2009-07-06 WG ID: Independent Submission Number_of_pages: 21 Abstract: SIP-based multimedia applications dynamically negotiate parameters for the related media streams, such as UDP port numbers. Therefore, firewalls that want to inspect these streams have to interact with the session signaling. Several architectures and protocols have been developed for the dynamic control of firewalls on the media path, e. g., MIDCOM, SIMCO, and the NSIS NAT/FW NSLP. This document investigates problems with the interaction of standard SIP (as of RFC 3261) and these firewall control protocols, especially with respect to error handling. It will be pointed out how existing SIP extensions can be used for improving the interaction, and which additional mechanisms need to be specified. While the actual specification of such additional mechanisms is out of the scope of this document, it solicits feedback and discussion. The IETF Secretariat. ----- End forwarded message ----- -- Sebastian Kiesel mailto:sebastian.kiesel@nw.neclab.eu Network Research Division tel:+49-6221-4342-232 fax:+49-6221-4342-155 NEC Laboratories Europe Kurfuerstenanlage 36, 69115 Heidelberg, Germany -- NEC Europe Limited Registered in England 2832014 Registered Office NEC House, 1 Victoria Road, London W3 6BL From root@core3.amsl.com Fri Jul 10 02: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 DBC1C3A6A24; Fri, 10 Jul 2009 02: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: <20090710094501.DBC1C3A6A24@core3.amsl.com> Date: Fri, 10 Jul 2009 02:45:01 -0700 (PDT) Cc: nsis@ietf.org Subject: [NSIS] I-D Action:draft-ietf-nsis-rmd-15.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, 10 Jul 2009 09: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 : RMD-QOSM - The Resource Management in Diffserv QOS Model Author(s) : A. Bader, et al. Filename : draft-ietf-nsis-rmd-15.txt Pages : 101 Date : 2009-07-10 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-15.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-15.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-07-10023851.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Mon Jul 13 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 8FC193A6D67; Mon, 13 Jul 2009 04: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: <20090713111501.8FC193A6D67@core3.amsl.com> Date: Mon, 13 Jul 2009 04:15:01 -0700 (PDT) Cc: nsis@ietf.org Subject: [NSIS] I-D Action:draft-ietf-nsis-applicability-mobility-signaling-13.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, 13 Jul 2009 11: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 : Applicability Statement of NSIS Protocols in Mobile Environments Author(s) : T. Sanda, et al. Filename : draft-ietf-nsis-applicability-mobility-signaling-13.txt Pages : 50 Date : 2009-07-13 Mobility of an IP-based node affects routing paths, and as a result, can have a significant effect on the protocol operation and state management. This draft discusses the effects mobility can cause to the NSIS protocol suite, and how the protocols operate in different scenarios, with mobility management protocols. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nsis-applicability-mobility-signaling-13.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-13.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-07-13040354.I-D@ietf.org> --NextPart-- From elwynd@dial.pipex.com Mon Jul 13 08:29:17 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 F3CBC3A6A2D for ; Mon, 13 Jul 2009 08:29:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.795 X-Spam-Level: X-Spam-Status: No, score=-101.795 tagged_above=-999 required=5 tests=[AWL=0.804, 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 nHvMj7VOIGWt for ; Mon, 13 Jul 2009 08:29:15 -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 A33073A6E12 for ; Mon, 13 Jul 2009 08:29:04 -0700 (PDT) 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 1MQNT8-0000AZ-On; Mon, 13 Jul 2009 16:29:31 +0100 Message-ID: <4A5B5307.3010208@dial.pipex.com> Date: Mon, 13 Jul 2009 16:30:15 +0100 From: Elwyn Davies User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Nuutti Varis References: <547F018265F92642B577B986577D671C7FDDBE@VENUS.office> <2E59A86C-AFBE-4E76-8BF5-EB914AE0A26B@cs.helsinki.fi> In-Reply-To: <2E59A86C-AFBE-4E76-8BF5-EB914AE0A26B@cs.helsinki.fi> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: nsis@ietf.org Subject: Re: [NSIS] WGLC for Using and Extending the NSIS Protocol Family (draft-ietf-nsis-ext-02) 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, 13 Jul 2009 15:29:17 -0000 Hi. Thanks for the comments and apologies for the long delay in acking your helpful review! I was waiting for the outcome of the IESG discussiojns and then got tied up in other work. Anyway I have now submitted a new version (JIT!). A couple of your comments have been OBE (back to RAO), but I trust my fixes will suit. Regards, Elwyn Nuutti Varis wrote: > Read the draft, comments below. > > Overall, there are some issues that I feel should be resolved in the > draft (see comments below). Also note that I skipped the parts that I > am not familiar with, i.e. the Qos and NAT/FW NSLP parts of the draft. > > > General: > > It seems to me that there are various terms used when talking about > NSIS related entities, for example: > > For the NSIS framework as a whole, we have: "NSIS", "NSIS suite", > "NSIS protocol suite", "protocol suite", > "NSIS framework", "NSIS protocols" > > For the signaling application layer, we have : "signaling layer", > "application layer", "signaling application > layer", "NSLP layer", "service layer" > > And for the transport layer, we have: "transport layer", "NTLP (GIST) > layer", "GIST layer" > > Finding some coherency between the three separate entities might be a > good idea, as people new to the NSIS > world may not be able to instantly recognize varied terms relating to > the same entity. I fixed these up as I thought appropriate.. preferring NSIS protocol suite and signaling application layer. The NTLP/GIST one seemed mostly OK to me. > > Other things: > > Page 4,5: > > Second paragraph has a long sentence: "While GIST is only concerned > with transporting NSLP messages hop-by-hop > between pairs of signalling nodes, the end-to-end signaling > functionality is provided by the NSLP protocols if > needed - not all NSLP protocols need to perform end-to-end signaling, > even the current protocols have features > to confine the signaling to a limited path." OK.. plus path -> part of path. > > also, "Two NSLP protocols are currently standardized: ..." -> "Two > NSLP applications are currently being > standardized ..."? NO.. when this is finished they will be standardized. > > Page 5, second paragraph: > > The paragraph first talks about "NSIS capable nodes", but then drops > the capable later on. Should this be > added in to make it clear that we are still talking about the NSIS > capable nodes, or is it clear without the > distinction? added capable to the second instance in the para. > > Page 5, third paragraph: > > "Unlike RSVP, signaling is normally ..." -> "Unlike RSVP, NSIS > signaling is normally ..."? Left this one alone. > > Page 6, chapter 3, first paragraph: > > "Applications can indicate the desired reliability, ..." > > Should that use "transport attributes" instead of "reliability", > something like: > > "Applications can indicate the desired transport attributes for the > signaling flow, which causes GIST to > select the appropriate transport protocol(s) for the flow. By default, > GIST specifies UDP for unreliable, TCP > for reliable and TLS on top of TCP for secure (and reliable) signaling > flows." > OK. I did something close to this. > Page 8, second paragraph: > > "When an NSLP application wants to send a message to its next peer > ..." -> "When an NSLP application wants to > send a message towards a flow endpoint"? OK > > > Page 9, second paragraph: > > s/recognised/recognized/ (whereas other places there are > "standardized" "authorized" and so on) This one is done both ways (especially in the UK.. I like s) > > Page 10, bullet 2: > > "GIST reuses already established signaling relationships and messaging > associations to peers if the signaling > flows traverse the same next signaling hop." > > What does the "already established signaling relationships" mean in > this multiplexing context? As far as I > understand, GIST only multiplexes messaging associations between > signaling flows that traverse between the > same peers. The problem is the last part.. new version: "GIST reuses already established signaling relationships and messaging associations to next hop peers if the signaling transport attributes are the sane for the signalong flows." > > Page 10, bullet 6: > > Should it be clarified here that the MTU restriction (and thus, the > GIST message size restriction) only > affects unreliable signaling flows? Also, the automatic elevation to a > reliable flow can not be originated > from the responding node. Added UDP and Query mesaage Didn't action the second part.. seems too detailed for this doc. > > Page 13, Chapter 6.1, first paragraph: > > "However, the removal of dependence on RAO makes it more likely that > NSIS Query packets can be forwarded > through nodes that are not NSIS aware." -> s/NSIS Query/GIST Query/ OBE: Completely new text in this section due to resurgence of RAO. > > Page 15, first paragraph: > > "GIST infrastructure" -> "NSIS infrastructure" I think this is right as it stands, > > Page 15, third paragraph: > > "Nodes that do not (yet) support the application will forward it > without complaint ..." -> "Nodes that do not > (yet) support the application will forward it's signaling messages > without complaint ..." > OK > Page 20, chapter 8.6 > > "Designing a new NSLP is both challenging and easy." .. Some reasoning > here would be good as to why? > .. that is what the rest of the section does (I think)! > Page 21, bullet 2: > > "GIST-NSLP API" is referenced earlier as a "service layer API", which > may not be obvious to someone new to > NSIS that they mean the same thing. Previous fixes make this clearer I hope. > > Page 21, bullet 5: > > "... is the source of the signaling flow, or an intermediate node on > the signaling." -> "... is the source of > the signaling flow, or an intermediate node on the signaling path."? > OK From root@core3.amsl.com Mon Jul 13 08:30: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 479933A6B87; Mon, 13 Jul 2009 08:30:00 -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: <20090713153001.479933A6B87@core3.amsl.com> Date: Mon, 13 Jul 2009 08:30:01 -0700 (PDT) Cc: nsis@ietf.org Subject: [NSIS] I-D Action:draft-ietf-nsis-ext-03.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, 13 Jul 2009 15:30: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-03.txt Pages : 28 Date : 2009-07-13 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-03.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-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-07-13081540.I-D@ietf.org> --NextPart-- From elwynd@dial.pipex.com Mon Jul 13 09:58:17 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 C5A2228C49F for ; Mon, 13 Jul 2009 09:58:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.956 X-Spam-Level: X-Spam-Status: No, score=-101.956 tagged_above=-999 required=5 tests=[AWL=0.643, 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 1YoCbX5VhH+x for ; Mon, 13 Jul 2009 09:58:16 -0700 (PDT) Received: from c.painless.aaisp.net.uk (c.painless.aaisp.net.uk [IPv6:2001:8b0:0:30::51bb:1e35]) by core3.amsl.com (Postfix) with ESMTP id 61F0828C4E1 for ; Mon, 13 Jul 2009 09:58:16 -0700 (PDT) Received: from 247.254.187.81.in-addr.arpa ([81.187.254.247]) by c.painless.aaisp.net.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1MQOrR-00007A-EN; Mon, 13 Jul 2009 17:58:41 +0100 Message-ID: <4A5B67EC.40305@dial.pipex.com> Date: Mon, 13 Jul 2009 17:59:24 +0100 From: Elwyn Davies User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Magnus Westerlund References: <547F018265F92642B577B986577D671C7FDDBE@VENUS.office> <49D5F48C.4050208@ericsson.com> In-Reply-To: <49D5F48C.4050208@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: nsis@ietf.org Subject: Re: [NSIS] WGLC for Using and Extending the NSIS Protocol Family (draft-ietf-nsis-ext-02) 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, 13 Jul 2009 16:58:17 -0000 Hi. I have just submitted a new version of the extensibility draft which I hope addresses all these comments, and has also been resynched with the RAO story as per mtlp version 20. Thanks for the helpful review. Not sure if this will need another WGLC due to RAO changes. Regards, Elwyn Magnus Westerlund wrote: > Hi, > > I have reviewed the document and have some comments. > > 1. First of all I wonder if all the WG history really need to be in this > document. I don't see a purpose for it in most cases. > > 2. The introduction could be more explicit about the purpose of this > document. > > 3. I think the topic of RAO could be a bit more clear about the issues > with deploying it, due to adminstrative filtering at domain borders etc. > Also the suggestions that RAO might be used, should probably > informatively reference the draft for RAO with NSIS. In addition be > clear on that this is likely only for limited deployements. > > 4. Section 6.1. Are you really certain that there will be need for > hardware replacement to implement GIST with UDP port filtering to > capture query packets. It seems that on a number of platforms this is > likely not needed. So I think a balanced view here that it might, or > might not be needed depending on the actual hardware in place is the > right message. > > 5. I think especially section 8 could use some work on the layout. The > text is very dense. I do understand why bullets are used, but I think > forcing some line breaks between them could make it more readable. > > Cheers > > Magnus > > Martin Stiemerling skrev: > >> Dear all, >> >> The draft draft-ietf-nsis-ext-02 seems to be ready for WGLC. >> >> We start a WGLC today for two weeks, i.e., until April 17, 2009. >> >> Please read the draft and send your comments about it. >> >> Comments includes, but are not limited to (just as a reminder): >> - what's wrong >> - what's right >> - stating that the draft ready for sending it to the IESG >> - stating that the draft is not ready for sending it to the IESG and why it is not. >> >> 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 >> >> > > > From fu@cs.uni-goettingen.de Fri Jul 17 15:12:20 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 2D2F13A6B50 for ; Fri, 17 Jul 2009 15:12:20 -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 cLHFu3e1WMZA for ; Fri, 17 Jul 2009 15:12:18 -0700 (PDT) Received: from amailer.gwdg.de (amailer.gwdg.de [134.76.10.18]) by core3.amsl.com (Postfix) with ESMTP id 7537E3A6A82 for ; Fri, 17 Jul 2009 15:12:17 -0700 (PDT) Received: from p5b03d0bf.dip.t-dialin.net ([91.3.208.191] helo=[192.168.0.187]) by mailer.gwdg.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1MRvfc-0001AG-LF; Sat, 18 Jul 2009 00:12:48 +0200 Message-ID: <4A60F75F.9030100@cs.uni-goettingen.de> Date: Sat, 18 Jul 2009 00:12:47 +0200 From: Xiaoming Fu Organization: University of Goettingen, Germany User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Jukka MJ Manner References: In-Reply-To: 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 Working Group Subject: Re: [NSIS] Working Group Last Call for NTLP State Machine 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, 17 Jul 2009 22:12:20 -0000 Hi Jukka, all, Thanks for your review. We have corrected the nits - although we cannot upload the new version to the IETF site before the deadline, you may find it in http://user.informatik.uni-goettingen.de/~fu/nsis/statemachine/ntlp/draft-ietf-nsis-ntlp-statemachine-07.pdf .txt Xiaoming Jukka MJ Manner wrote: > Dear all, > > I don't seem to find a WGLC on the State machine, thus I'll issue a > two-week WGLC starting today and ends on Friday July 10th. There are at > least a few ID nits to be handled - consider this as my own WGLC review. > > http://tools.ietf.org/wg/nsis/draft-ietf-nsis-ntlp-statemachine/ > > Regards, > Jukka > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www.ietf.org/mailman/listinfo/nsis > From jmanner@cs.helsinki.fi Thu Jul 23 03:54: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 397EB3A6A21 for ; Thu, 23 Jul 2009 03:54:28 -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 N22uItcC9dc0 for ; Thu, 23 Jul 2009 03:54:27 -0700 (PDT) Received: from mail.cs.helsinki.fi (courier.cs.helsinki.fi [128.214.9.1]) by core3.amsl.com (Postfix) with ESMTP id 8539F3A6A2E for ; Thu, 23 Jul 2009 03:53:51 -0700 (PDT) Received: from [130.233.154.59] (pc59.netlab.hut.fi [130.233.154.59]) (AUTH: PLAIN jmanner, SSL: TLSv1/SSLv3,256bits,AES256-SHA) by mail.cs.helsinki.fi with esmtp; Thu, 23 Jul 2009 13:46:48 +0300 id 0007047F.4A683F98.000079FD Message-ID: <4A683F97.7010805@cs.helsinki.fi> Date: Thu, 23 Jul 2009 13:46:47 +0300 From: Jukka Manner User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: NSIS Working Group References: <4A60F75F.9030100@cs.uni-goettingen.de> In-Reply-To: <4A60F75F.9030100@cs.uni-goettingen.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [NSIS] Working Group Last Call for NTLP State Machine 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, 23 Jul 2009 10:54:28 -0000 Dear all, Since there were no further comments to the draft, I consider it to have passed WGLC and is ready to go forward. Regards, Jukka Xiaoming Fu wrote: > Hi Jukka, all, > > Thanks for your review. We have corrected the nits - although we cannot > upload the new version to the IETF site before the deadline, you may > find it in > http://user.informatik.uni-goettingen.de/~fu/nsis/statemachine/ntlp/draft-ietf-nsis-ntlp-statemachine-07.pdf > .txt > Xiaoming > Jukka MJ Manner wrote: >> Dear all, >> >> I don't seem to find a WGLC on the State machine, thus I'll issue a >> two-week WGLC starting today and ends on Friday July 10th. There are >> at least a few ID nits to be handled - consider this as my own WGLC >> review. >> >> http://tools.ietf.org/wg/nsis/draft-ietf-nsis-ntlp-statemachine/ >> >> Regards, >> Jukka >> _______________________________________________ >> nsis mailing list >> nsis@ietf.org >> https://www.ietf.org/mailman/listinfo/nsis >> From magnus.westerlund@ericsson.com Thu Jul 23 04:46:36 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 EBE7C3A67E7; Thu, 23 Jul 2009 04:46:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.749 X-Spam-Level: X-Spam-Status: No, score=-3.749 tagged_above=-999 required=5 tests=[AWL=-1.500, BAYES_00=-2.599, HELO_EQ_SE=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 SsIZBwF4YbZ2; Thu, 23 Jul 2009 04:46:36 -0700 (PDT) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id B201E3A63EB; Thu, 23 Jul 2009 04:46:35 -0700 (PDT) X-AuditID: c1b4fb24-b7c01ae00000498b-02-4a68486a2620 Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw5.ericsson.se (Symantec Brightmail Gateway) with SMTP id 99.6E.18827.A68486A4; Thu, 23 Jul 2009 13:24:26 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 23 Jul 2009 13:23:33 +0200 Received: from [153.88.44.243] ([153.88.44.243]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 23 Jul 2009 13:23:32 +0200 Message-ID: <4A684831.1060303@ericsson.com> Date: Thu, 23 Jul 2009 13:23:29 +0200 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: IESG Secretary X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 23 Jul 2009 11:23:32.0852 (UTC) FILETIME=[03131340:01CA0B88] X-Brightmail-Tracker: AAAAAA== Cc: NSIS Subject: [NSIS] Approved: draft-ietf-nsis-ntlp-20 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, 23 Jul 2009 11:46:37 -0000 GIST: General Internet Signalling Transport (draft-ietf-nsis-ntlp-20) with one RFC-editor note is approved for publication as experimental RFC. Cheers Magnus Westerlund IETF Transport Area Director ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From bless@tm.uka.de Thu Jul 23 06:08: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 610C93A6983 for ; Thu, 23 Jul 2009 06:08:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.248 X-Spam-Level: X-Spam-Status: No, score=-6.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, 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 2Sfku2w3N9Np for ; Thu, 23 Jul 2009 06:08:43 -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 DF3D93A6A86 for ; Thu, 23 Jul 2009 06:08:37 -0700 (PDT) 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 1MTy1o-0001WV-VF for ; Thu, 23 Jul 2009 15:08:17 +0200 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 1E6CC2FC008 for ; Thu, 23 Jul 2009 15:08:08 +0200 (CEST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by vorta.tm.uka.de (Postfix) with ESMTP id 0A3291035C for ; Thu, 23 Jul 2009 15:08:08 +0200 (CEST) Message-ID: <4A6860B7.20207@tm.uka.de> Date: Thu, 23 Jul 2009 15:08:07 +0200 From: Roland Bless Organization: Institute of Telematics, University of Karlsruhe User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060111 Thunderbird/1.5 Mnenhy/0.7.3.0 MIME-Version: 1.0 To: "nsis@ietf.org" X-Enigmail-Version: 0.95.0 Content-Type: multipart/mixed; boundary="------------060905050902000707060305" X-ATIS-AV: ClamAV (iramx2.ira.uni-karlsruhe.de) X-ATIS-AV: Kaspersky (iramx2.ira.uni-karlsruhe.de) X-ATIS-Timestamp: iramx2.ira.uni-karlsruhe.de 1248354498.210606000 Subject: [NSIS] [Fwd: [Int-area] Call for comment on draft-rahman-rtg-router-alert-considerations-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: Thu, 23 Jul 2009 13:08:44 -0000 This is a multi-part message in MIME format. --------------060905050902000707060305 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi, I think that this is highly relevant to NSIS, too. Regards, Roland --------------060905050902000707060305 Content-Type: message/rfc822; name="[Int-area] Call for comment on draft-rahman-rtg-router-alert-considerations-02.txt.eml" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename*0="[Int-area] Call for comment on draft-rahman-rtg-router-alert"; filename*1="-considerations-02.txt.eml" Return-Path: Received: from vorta.tm.uka.de ([unix socket]) by vorta (Cyrus v2.2.13-Debian-2.2.13-13ubuntu3) with LMTPA; Thu, 23 Jul 2009 11:17:46 +0200 X-Sieve: CMU Sieve 2.2 Received: from vorta (localhost [127.0.0.1]) by vorta.tm.uka.de (Postfix) with ESMTP id CA8481035C for ; Thu, 23 Jul 2009 11:17:46 +0200 (CEST) Envelope-to: bless@ira.uka.de Delivery-date: Thu, 23 Jul 2009 11:15:15 +0200 Received: from irams1.ira.uni-karlsruhe.de [141.3.10.5] by vorta with POP3 (fetchmail-6.3.8) for (single-drop); Thu, 23 Jul 2009 11:17:46 +0200 (CEST) Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81]) by irams1.ira.uni-karlsruhe.de with esmtps id 1MTuOR-0003ou-Sv; Thu, 23 Jul 2009 11:15:15 +0200 Received: from mail.ietf.org ([64.170.98.32]) by iramx2.ira.uni-karlsruhe.de with esmtp id 1MTuNg-00083x-Q0; Thu, 23 Jul 2009 11:15:15 +0200 Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 44CCF28C11C; Thu, 23 Jul 2009 02:11:06 -0700 (PDT) X-Original-To: int-area@core3.amsl.com Delivered-To: int-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 006743A6B0A for ; Thu, 23 Jul 2009 02:11:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.598 X-Spam-Level: X-Spam-Status: No, score=-8.598 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 MIHn6ntEu0Nk for ; Thu, 23 Jul 2009 02:11:02 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id C8C5B3A6AAF for ; Thu, 23 Jul 2009 02:11:01 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: An8AAMbFZ0qQ/uCKe2dsb2JhbACCJhUYlx4BARYkBp0jiCWQdwWEDQ X-IronPort-AV: E=Sophos;i="4.43,253,1246838400"; d="scan'208,217";a="45658028" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 23 Jul 2009 09:10:51 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n6N9Apin004949 for ; Thu, 23 Jul 2009 11:10:51 +0200 Received: from xbh-ams-102.cisco.com (xbh-ams-102.cisco.com [144.254.73.132]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n6N9ApUX016523 for ; Thu, 23 Jul 2009 09:10:51 GMT Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 23 Jul 2009 11:10:51 +0200 Received: from ams-flefauch-8716.cisco.com ([10.55.161.199]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 23 Jul 2009 11:10:50 +0200 Message-Id: <75DB09D8-DD8C-4874-99CB-423FB85B7FD0@cisco.com> From: Francois Le Faucheur IMAP To: int-area@ietf.org Mime-Version: 1.0 (Apple Message framework v935.3) Date: Thu, 23 Jul 2009 11:10:49 +0200 X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 23 Jul 2009 09:10:51.0146 (UTC) FILETIME=[798726A0:01CA0B75] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=8862; t=1248340251; x=1249204251; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=flefauch@cisco.com; z=From:=20Francois=20Le=20Faucheur=20IMAP=20 |Subject:=20Call=20for=20comment=20on=20draft-rahman-rtg-ro uter-alert-considerations-02.txt |Sender:=20; bh=s/3WFGO2qnwLoIv1iHyqUuVg3wlLi0il+DusUO3VayU=; b=hBu5h1hZgwmAKdZRlo+Znf1FY0Q0Q4y0kqYXENYGs7SaPfCBQlldoD0zDQ IhC86T/Gwu1yiaSbtcj7e90cxISs2FI0bOtcnwZuQ/lzwHZMi0luFaoKL1ts sbd+FsqAwe; Authentication-Results: ams-dkim-1; header.From=flefauch@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Subject: [Int-area] Call for comment on draft-rahman-rtg-router-alert-considerations-02.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1300465893==" Sender: int-area-bounces@ietf.org Errors-To: int-area-bounces@ietf.org X-ATIS-AV: ClamAV (iramx2.ira.uni-karlsruhe.de) X-ATIS-AV: Kaspersky (iramx2.ira.uni-karlsruhe.de) X-ATIS-Spam-Status: No X-ATIS-Spam-Score: -2.0 (--) X-ATIS-Spam-Report: 0.5 HTML_MESSAGE BODY: HTML included in message -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] 0.1 RDNS_NONE Delivered to trusted network by a host with no rDNS X-ATIS-Spam-Host: iramx2.ira.uni-karlsruhe.de X-ATIS-Checksum: v3zoCAcc32ckk X-ATIS-Timestamp: iramx2.ira.uni-karlsruhe.de 1248340515.780943000 X-ATIS-Timestamp: irams1.ira.uni-karlsruhe.de 1248340515.983018000 --===============1300465893== Content-Type: multipart/alternative; boundary=Apple-Mail-3--549890250 --Apple-Mail-3--549890250 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hello, The Routing, Transport and Internet area directors have agreed to move the work on Router Alert option (that started in Routing Area) into the Internet Area. Therefore, we would appreciate feedback from this list on the new version of draft-rahman-rtg-router-alert-considerations. Thank you Francois Begin forwarded message: > From: Internet-Drafts@ietf.org > Date: 3 July 2009 19:15:02 CEDT > To: i-d-announce@ietf.org > Subject: I-D Action:draft-rahman-rtg-router-alert- > considerations-02.txt > Reply-To: internet-drafts@ietf.org > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : IP Router Alert Considerations and Usage > Author(s) : F. Le Faucheur > Filename : draft-rahman-rtg-router-alert-considerations-02.txt > Pages : 18 > Date : 2009-07-03 > > The IP Router Alert Option is an IP option that alerts transit > routers to more closely examine the contents of an IP packet. RSVP, > PGM, IGMP/MLD and MRD are some of the protocols which make use of the > IP Router Alert option. This document discusses security aspects, > common practices and usage guidelines around the use of the current > IP Router Alert option. Specifically, it provides recommendations on > the use of Router Alert by new protocols, discusses controlled > environments where existing protocols depending on Router Alert can > be used effectively and discusses protection approaches for Service > Providers. Finally it provides brief guidelines for Router Alert > implementation on routers. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-rahman-rtg-router-alert-considerations-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. Content-Type: text/plain
Content-ID: <2009-07-03101229.I-D@ietf.org >

> _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --Apple-Mail-3--549890250 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable
Date: 3 July 2009 19:15:02 CEDT
To: i-d-announce@ietf.org
Subject: I-D = Action:draft-rahman-rtg-router-alert-considerations-02.txt 

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

Title =           : IP Router = Alert Considerations and Usage
Author(s) =       : F. Le Faucheur
Filename =        : = draft-rahman-rtg-router-alert-considerations-02.txt
Pages =           : = 18
= Date =            : = 2009-07-03

The IP Router Alert Option is an IP option that alerts = transit
routers to more closely examine the contents of an IP packet. =  RSVP,
PGM, IGMP/MLD and MRD are some of the protocols which = make use of the
IP Router Alert option.  This document discusses = security aspects,
common practices and usage guidelines around the = use of the current
IP Router Alert option.  Specifically, it = provides recommendations on
the use of Router Alert by new protocols, = discusses controlled
environments where existing protocols depending = on Router Alert can
be used effectively and discusses protection = approaches for Service
Providers.  Finally it provides brief = guidelines for Router Alert
implementation on routers.

A URL = for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-rahman-rt= g-router-alert-considerations-02.txt

Internet-Drafts are also = available by anonymous FTP at:
ftp://ftp.ietf.org/internet-d= rafts/

Below is the data which will enable a MIME compliant = mail reader
implementation to automatically retrieve the ASCII = version of = the
Internet-Draft.
Content-Type: = text/plain<BR>Content-ID: &lt;2009-07-03101229.I-D@ietf.or= g&gt;<BR><BR>
_______________________________________________
I-D-= Announce mailing list
I-D-Announce@ietf.org
https://www.ie= tf.org/mailman/listinfo/i-d-announce
Internet-Draft = directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf= /1shadow-sites.txt

= --Apple-Mail-3--549890250-- --===============1300465893== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area --===============1300465893==-- --------------060905050902000707060305-- From Adrian.Farrel@huawei.com Thu Jul 23 07:29:43 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 EB4873A6A38 for ; Thu, 23 Jul 2009 07:29:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] 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 yNiX4az4OP4Z for ; Thu, 23 Jul 2009 07:29:43 -0700 (PDT) Received: from lhrga03-in.huawei.com (lhrga03-in.huawei.com [195.33.106.148]) by core3.amsl.com (Postfix) with ESMTP id ECF103A682B for ; Thu, 23 Jul 2009 07:29:42 -0700 (PDT) Received: from huawei.com (localhost [127.0.0.1]) by lhrga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KN800I7LO87OC@lhrga03-in.huawei.com> for nsis@ietf.org; Thu, 23 Jul 2009 15:28:55 +0100 (BST) Received: from your029b8cecfe (bgp-ext.core.365-24.net [217.151.192.10]) by lhrga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KN8005VUO85IQ@lhrga03-in.huawei.com> for nsis@ietf.org; Thu, 23 Jul 2009 15:28:54 +0100 (BST) Date: Thu, 23 Jul 2009 15:28:41 +0100 From: Adrian Farrel To: nsis@ietf.org Message-id: <66CE636A0DCB48469A10F1E4328EC284@your029b8cecfe> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Mailer: Microsoft Outlook Express 6.00.2900.5512 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <307784.7860.qm@web63607.mail.re1.yahoo.com> Subject: Re: [NSIS] Approved: draft-ietf-nsis-ntlp-20 X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian Farrel List-Id: Next Steps in Signaling List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2009 14:29:44 -0000 Hi, With the approval of draft-ietf-nsis-ntlp-20 as an Experimental I-D, I wanted to give my own personal view of why this is a good thing, how we might have made progress that the working group might have found more acceptable, and what could happen going forward. Firstly, it is important to understand that an Experimantal status is not perjorative. In fact, many good and widely deployed protocols grew up as Experimental, benefitted from cautious deployment and feedback, and were taken forward on the Standards Track. In some cases the protocols went forward largely unchanged and in some cases significant updates were made. I believe it is really important that GIST will now be published as an RFC. This will open up the implementation base and allow people to understand that they are implementing a stable specification. In as much as the choice of Experimental Status has enabled the log-jam to be broken and publication achieved, it cannot be anything except a good thing. My own view is that we could have reached this stage at least two years ago. I am not interested in the who or why we did not, but IMHO we could have reached the approved status by either: - going straight to Experimental status - clarifying the intended deployment scope. The latter case needs some clarification. We hear talk of "walled gardens" and what is meant is that some protocols are not necessarily suitable (or intended) for deployment in every conceivable network. Of particular interest are the distinctions between all-new nodes and new/legacy mixes, enterprise and service provider networks, sinle domain and multi-domain networks, and contained networks and "the Internet". I believe that had we made these statements of intent and scope in the GIST spec up front and in 14pt type, we would have made far better progress. Of course, the value of this information is now moot. I am not sure it is worth discussion as it is picking over old bones. But maybe we can learn for next time. The NSIS working group already has some work on applicability. I think it would be really helpful to pursue that thread with further applicability stetements that caveat the environments in which GIST should be applied and those in which it is not intended to be applied. (This is clearly a choice for the WG and the responsible ADs, and not for me!) I also hope that the folks who have built and deployed GIST will come back (possibly in a relatively short period) to discuss their deployment experience. Hopefully they will be able to tell us about the extent of their deployments in live networks and report on the issues and successes they had. The combination of these discussions and the applicability statements could possibly be a revision of the GIST RFC that includes statements about any deployment limits or advice, any protocol fixes and clarification, and movement onto the standards track. Cheers, Adrian PS Caveat! I am just one AD. This is my apple-pie view of the world. From Stiemerling@nw.neclab.eu Thu Jul 23 13:40:35 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 02F103A6AFE for ; Thu, 23 Jul 2009 13:40:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.034 X-Spam-Level: X-Spam-Status: No, score=-2.034 tagged_above=-999 required=5 tests=[AWL=0.565, 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 a2a9Fsh1gVuE for ; Thu, 23 Jul 2009 13:40:34 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id DC1253A68AC for ; Thu, 23 Jul 2009 13:40:33 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 2A9F32C0012C6; Thu, 23 Jul 2009 21:19:01 +0200 (CEST) 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 qjlc3cQJy6fe; Thu, 23 Jul 2009 21:19:01 +0200 (CEST) Received: from VENUS.office (mx1.office [192.168.24.3]) by smtp0.neclab.eu (Postfix) with ESMTP id 0BD082C0012C4; Thu, 23 Jul 2009 21:18:51 +0200 (CEST) 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: Thu, 23 Jul 2009 21:18:50 +0200 Message-ID: <547F018265F92642B577B986577D671CA70389@VENUS.office> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Cancled NSIS session thread-index: AcoLymjajxhPVPZ4Rka6/nTEpsKJZQ== From: "Martin Stiemerling" To: "NSIS" Subject: [NSIS] Cancled NSIS session 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, 23 Jul 2009 20:40:35 -0000 Dear all, Jukka and me decided to cancel the NSIS session at the upcoming IETF = meeting. There was no request for agenda time and we actually have no = issue to discuss right now f2f, i.e., all issues can be done on the = mailing list.=20 Jukka and I will report the WG status to the WG soon. Thanks, 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 wwwrun@core3.amsl.com Thu Jul 23 16:16:26 2009 Return-Path: X-Original-To: nsis@ietf.org Delivered-To: nsis@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 65F0628C126; Thu, 23 Jul 2009 16:16:26 -0700 (PDT) X-idtracker: yes From: The IESG To: IETF-Announce Message-Id: <20090723231626.65F0628C126@core3.amsl.com> Date: Thu, 23 Jul 2009 16:16:26 -0700 (PDT) Cc: Internet Architecture Board , nsis chair , nsis mailing list , RFC Editor Subject: [NSIS] Document Action: 'GIST: General Internet Signalling Transport' to Experimental RFC 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, 23 Jul 2009 23:16:26 -0000 The IESG has approved the following document: - 'GIST: General Internet Signalling Transport ' as an Experimental RFC This document is the product of the Next Steps in Signaling Working Group. The IESG contact persons are Magnus Westerlund and Lars Eggert. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nsis-ntlp-20.txt Technical Summary This draft proposes a general signaling transport protocol. It is based on the use of existing transport and security protocols under a common messaging layer. GIST does not handle signaling application state itself; in that crucial respect, it differs from application signaling protocols such as SIP, RTSP, and the control component of FTP, but this follows the basic NSIS 2-layer signaling model defined in RFC 4080. Working Group Summary This document was previously sent back from the IESG. The WG has now addressed the issue raised by the IESG review and thinks it ready to progress. Protocol Quality Magnus Westerlund was the responsible AD. This document was reviewed by the working group chair as well as the WG. There are 6 or more independent implementations of GIST, and there was an interop event prior to the Paris IETF meeting. IETF Last call comments was received and has been incorporated. Then it was sent back to the WG to take care of a number of important to resolve issues. It has now gone through the WG process, and a second IETF last call. RFC-editor Note Section 5.1, third paragraph: OLD: Messages with missing, duplicate or invalid objects for the message type MUST be rejected with an "Object Type Error" message with the appropriate subcode (Appendix A.4.4.9). NEW: Messages with missing, duplicate or invalid objects for the message type MUST be rejected with an "Object Type Error" message with the appropriate subcode (Appendix A.4.4.9). Note that unknown objects indicate explicitly how they should be treated and are not covered by the above statement. From root@core3.amsl.com Tue Jul 28 01: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 31C603A69AE; Tue, 28 Jul 2009 01:00:00 -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: <20090728080001.31C603A69AE@core3.amsl.com> Date: Tue, 28 Jul 2009 01:00:01 -0700 (PDT) Cc: nsis@ietf.org Subject: [NSIS] I-D Action:draft-ietf-nsis-ntlp-statemachine-08.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, 28 Jul 2009 08: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 : GIST State Machine Author(s) : T. Tsenov, et al. Filename : draft-ietf-nsis-ntlp-statemachine-08.txt Pages : 22 Date : 2009-07-28 This document describes the state machines for the General Internet Signaling Transport (GIST). The states of GIST nodes for a given flow and their transitions are presented in order to illustrate how GIST may be implemented. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nsis-ntlp-statemachine-08.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-statemachine-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-07-28005325.I-D@ietf.org> --NextPart--