From exim@www1.ietf.org Wed Oct 1 05:08:02 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04384 for ; Wed, 1 Oct 2003 05:08:02 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4cxO-0002eQ-TB for nsis-archive@odin.ietf.org; Wed, 01 Oct 2003 05:07:39 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9197cm7010171 for nsis-archive@odin.ietf.org; Wed, 1 Oct 2003 05:07:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4cwn-0002TF-8y; Wed, 01 Oct 2003 05:07:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4cwN-0002Sd-Am for nsis@optimus.ietf.org; Wed, 01 Oct 2003 05:06:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04343 for ; Wed, 1 Oct 2003 05:06:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4cwJ-0004Pd-00 for nsis@ietf.org; Wed, 01 Oct 2003 05:06:31 -0400 Received: from mailsrv.psl.com.sg ([202.14.153.3]) by ietf-mx with esmtp (Exim 4.12) id 1A4cwI-0004Oo-00 for nsis@ietf.org; Wed, 01 Oct 2003 05:06:30 -0400 Received: from netpronote3 ([10.81.113.70]) by mailsrv.psl.com.sg (8.12.9/8.12.9) with SMTP id h918wIRn019104; Wed, 1 Oct 2003 16:58:22 +0800 (SGT) From: "Cheng Hong" To: Cc: Subject: RE: [NSIS] Re: qos-nslp-00 Date: Wed, 1 Oct 2003 17:09:19 +0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200 In-Reply-To: Importance: Normal Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Sven, The model of operation in Figure 1 shows that the data flow would go through the "Outgoing Interface Selection (Forwarding)" block before entering the "Traffic Control" block. Does this mean that the traffic control in the model would only apply on the outgoing interface? I noticed it's somehow different from the figure in RFC2205. Is this change intentional? Thanks. Cheng ============================================ Network Team/AV Networks Office Panasonic Singapore Laboratories Pte. Ltd. Tel: +65-65505477 Fax: +65-65505459 E-mail: hcheng@psl.com.sg ============================================ _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Wed Oct 1 10:33:03 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15363 for ; Wed, 1 Oct 2003 10:33:03 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4i1w-0003e7-9Z for nsis-archive@odin.ietf.org; Wed, 01 Oct 2003 10:32:40 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h91EWerD014014 for nsis-archive@odin.ietf.org; Wed, 1 Oct 2003 10:32:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4i1J-0003Zg-A1; Wed, 01 Oct 2003 10:32:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4i1G-0003Z6-Jc for nsis@optimus.ietf.org; Wed, 01 Oct 2003 10:31:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15323 for ; Wed, 1 Oct 2003 10:31:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4i1D-0007fK-00 for nsis@ietf.org; Wed, 01 Oct 2003 10:31:55 -0400 Received: from thoth.sbs.de ([192.35.17.2]) by ietf-mx with esmtp (Exim 4.12) id 1A4i1C-0007fH-00 for nsis@ietf.org; Wed, 01 Oct 2003 10:31:55 -0400 Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by thoth.sbs.de (8.11.7/8.11.7) with ESMTP id h91EVr529651; Wed, 1 Oct 2003 16:31:53 +0200 (MEST) Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail1.siemens.de (8.11.7/8.11.7) with ESMTP id h91EVr616113; Wed, 1 Oct 2003 16:31:53 +0200 (MEST) Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2653.19) id ; Wed, 1 Oct 2003 16:31:47 +0200 Message-ID: <2A8DB02E3018D411901B009027FD3A3F03BC0267@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: "'Hancock, Robert'" , "'Geib, Ruediger'" , nsis@ietf.org Subject: RE: [NSIS] Reliability and Security Date: Wed, 1 Oct 2003 16:31:49 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , hi robert, sorry for the late reply - i had to rejoin the army (=> no wlan coverage in the austrian mountains :-)). thank you for your response. i also like your text but it does not completely address my issues. i know that there are several ways to implement the "Bypassing Intermediate Nodes" procedure. an interesting draft by bob lindell and bob braden have already discussed these issues some time ago (see draft-lindell-waypoint-00.txt). ping pan addressed the performance implications in his work (e.g. see ). for security (and in particular for security association establishment) the following issues are of importance: - node A has to learn that a security association has to be established to some node C. node A and C support NSLP X; node B only NSLP Y how and when is this information obtained? - at which layer are messages protected? (ntlp/nslp) we have seen a number of protocol proposals in the past. there it can easily be seen that differences exist which have an impact on security. it is important to make the default mode of operation very clear and precise. ciao hannes > -----Original Message----- > From: Hancock, Robert [mailto:robert.hancock@roke.co.uk] > Sent: Tuesday, September 23, 2003 3:01 PM > To: 'Geib, Ruediger'; Tschofenig Hannes; nsis@ietf.org > Subject: RE: [NSIS] Reliability and Security > > > dear colleagues, > > there is actually a really hard set of questions here. as well > as the security and transport issues hannes mentions (of which > my favourite is actually congestion/flow control), there is > also a more basic point about fast-path bypassing of NSIS > messages inside aggregation regions, which we can't ignore. > > there is also the problem of how to achieve this in the case where the > intermediate node wants to some nearly-minimal processing on > some bits of the signalling message payload (e.g. address > translation, or some of the tricks that the RMD people want > to play when using reservation-based PHRs). > > about the only thing I am certain of here is that fw-03 is > wrong on the matter. i have written some replacement text for > fw-04 partially based on fw-03 section 3.2.1. it is attached > below. (basically it says there are some problems the NTLP > designers will have to worry about...) > > cheers, > > r. > > ============================================================== > 3.x.x Bypassing Intermediate Nodes > > Because the NSIS problem includes multiple signaling > applications, it is very likely that a particular NSLP will > only be implemented on a subset of the NSIS-aware nodes on a > path, as shown in Figure 5. In addition, a node inside an > aggregation region will still wish to ignore signaling > messages which are per-flow, even if they are for a > signaling application which the node is able to process in > general. > > +------+ +------+ +------+ +------+ > | NE | | NE | | NE | | NE | > |+----+| | | |+----+| |+----+| > ||NSLP|| | | ||NSLP|| ||NSLP|| > || 1 || | | || 2 || || 1 || > |+----+| | | |+----+| |+----+| > | || | | | | | | || | > |+----+| |+----+| |+----+| |+----+| > ====||NTLP||====||NTLP||====||NTLP||====||NTLP||==== > |+----+| |+----+| |+----+| |+----+| > +------+ +------+ +------+ +------+ > > Figure 5: Signaling with Heterogeneous NSLPs > > Where signaling messages traverse such NSIS-aware > intermediate nodes, it is desirable to process them at the > lowest level possible (in particular, on the fastest path). > In order to offer a non-trivial message transfer service > (in terms of security, reliability and so on) to the peer > NSLP nodes, it is important that NTLP at intermediate nodes > is as transparent as possible, that is, it carries out > minimal processing. In addition, if intermediate nodes have > to do slow-path processing of all NSIS messages, this > eliminates many of the scaling benefits of aggregation, > unless tunneling is used. > > Considering first the case of messages sent with the router > alert option, there are two complementary methods to achieve > this bypassing of intermediate NEs: > > *) At the IP layer, a set of protocol numbers can be used, > or a range of values in the router alert option. In this > way, messages can be marked with an implied granularity, and > routers can choose to apply further slow-path processing > only to configured subsets of messages. This is the method > used in [3175] to distinguish per-flow and per-aggregate signaling. > > *) The NTLP could process the message but determine that > there was no local signaling application it was relevant to. > At this stage, the message can be returned unchanged to the > IP layer for normal forwarding; the intermediate NE has > effectively chosen to be transparent to the message in question. > > In both cases, the existence of the intermediate NE is > totally hidden from the NSLP nodes. If later stages of the > signaling use directly addressed messages (e.g. for reverse > routing), they will not involved the intermediate NE at all, > except perhaps as a normal router. > > There may be cases where the intermediate NE would like to > do some restricted protocol processing, for example: > *) Translating addresses in message payloads (compare > section 4.6.1); note this would have to be done to messages > passing both directions through a node. > *) Updating signaling application payloads with local status > information (e.g. path property measurement inside a domain). > If this can be done without fully terminating the NSIS > protocols, this would allow a more lightweight > implementation of the intermediate NE, and a more direct > 'end-to-end' NTLP association between the peer NSLPs where > the signaling application is fully processed. On the other > hand, this is only possible with a limited class of possible > NTLP designs, and makes it harder for the NTLP to offer a > security service (since messages have to be partially > protected). The feasibility of this approach will be > evaluated during the NTLP design. > > ====================================================== > > > -----Original Message----- > > From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] > > Sent: Wednesday, September 17, 2003 12:59 > > To: Hannes.Tschofenig@siemens.com; nsis@ietf.org > > Subject: RE: [NSIS] Reliability and Security > > > > > > Hello Hannes, > > > > sorry, I've hit the wrong keys earlier. So I bother you again... > > > > [snip] > > |Is > > | > > | NE 1 NE 2 NE 3 > > | NE 4 > > | > > |the same as > > | > > | NE 1 NE 4 > > |? > > | > > |My perception is that it is not necessarily the same, as > > also argued in > > |[Han] concerning reliability. > > > > I share your view, this isn't the same. And your conclusion > > is correct: > > > > |If the working group thinks that this is not the same then > > it would be > > |necessary to provide additional security between neighboring > > |NSLP peers. > > | > > |As a consequence a discovery mechanism is needed at the NSLP > > |to learn the next NSLP node along the path. This is > necessary to be > > |able to secure signaling messages efficiently (i.e. using > symmetric > > |cryptography). Hence avoiding the discovery procedure at the NTLP > > |was not really beneficial. > > |Without efficient mechanism it is likely that the mechanisms > > |would not be used at all. > > | > > |Securing signaling messages at the NTLP and the NSLP might > > |seem to be an overkill to some people. Securing signaling > messages > > |only at the NSLP layer does not seem to be sufficient as recently > > |discussed (see NSIS ML discussion [NSIS-ML]). > > > > Looks as if there's no solution for having a flexible architecture > > combined with security across NTLP and NSLP. > > > > I don't think that we must protect NSLP messages. To protect > > against "simple" NSLP DoS attacks then the first NTLP node would > > have to check whether the sender of an NTLP message is allowed > > to signal for a specific NSLP (given that he's allowed to > use NTLP). > > This would hold even if this NSLP isn't supported locally. Some > > policy communication is required then. > > > > But no matter how the solution looks like: two peering nodes > > shouldn't have to support completely separate security instances > > per NTLP/NSLP stack as a consequence of NTLP only handling messages > > with specific NSLPs. > > > > Regards, Rudiger > > > > |4. Reference > > | > > |[Han] R. Hancock: "Reliability Functions in the NSIS > Transport Layer > > |Protocol", , (work in > > |progress), > > |August 2003 > > | > > |[NSIS-ML] IETF NSIS Mailing List, "[NSIS] ntlp security > > |thoughts, Date: Sun, > > |13 Jul 2003 14:47:51 +0200", Available at: > > |http://www1.ietf.org/mail-archive/working-groups/nsis/current/m > > |sg03106.html, > > |(Sep. 2003). > > | > > | > > |ciao > > |Hannes > > | > > | > > |_______________________________________________ > > |nsis mailing list > > |nsis@ietf.org > > |https://www1.ietf.org/mailman/listinfo/nsis > > | > > > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > > > > -- > Registered Office: Roke Manor Research Ltd, Siemens House, > Oldbury, Bracknell, > Berkshire. RG12 8FZ > > The information contained in this e-mail and any attachments > is confidential to > Roke Manor Research Ltd and must not be passed to any third > party without > permission. This communication is for information only and > shall not create or > change any contractual relationship. > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu Oct 2 03:08:02 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05573 for ; Thu, 2 Oct 2003 03:08:02 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4xYq-0002q4-QN for nsis-archive@odin.ietf.org; Thu, 02 Oct 2003 03:07:41 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9277eka010898 for nsis-archive@odin.ietf.org; Thu, 2 Oct 2003 03:07:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4xYD-0002fX-Mt; Thu, 02 Oct 2003 03:07:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4xXX-0002eN-6F for nsis@optimus.ietf.org; Thu, 02 Oct 2003 03:06:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05519 for ; Thu, 2 Oct 2003 03:06:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4xXT-0003tw-00 for nsis@ietf.org; Thu, 02 Oct 2003 03:06:15 -0400 Received: from mail1.telekom.de ([62.225.183.202]) by ietf-mx with esmtp (Exim 4.12) id 1A4xXS-0003tV-00 for nsis@ietf.org; Thu, 02 Oct 2003 03:06:14 -0400 Received: from g8pbr.blf01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Thu, 2 Oct 2003 09:05:43 +0200 Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Thu, 2 Oct 2003 09:05:43 +0200 Message-Id: <9F8582E37B2EE5498E76392AEDDCD3FE03DBB63D@G8PQD.blf01.telekom.de> From: "Geib, Ruediger" To: hannes.tschofenig@siemens.com Cc: nsis@ietf.org Subject: RE: [NSIS] Reliability and Security Date: Thu, 2 Oct 2003 09:05:42 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hannes, What are the options we have? - NTLP and NSLP security are combined. This would result=20 in chains of trust. Complex. - NTLP has no security, security is done by NSLP. Bad idea,=20 DoS attacks should be inhibited at the lowest possible=20 level. - NTLP and NSLP have separated security mechanisms. Not very=20 nice if operators must locate errors. If possible,=20 separate instances of the same security mechanism. - If you look at the example I've added below, NSLP may=20 benefit from chains of trust. Is there a smart way of=20 organising them? - We'll have to agree which protection is required at what=20 level (I'm e.g favouring NTLP with authentication only). - There may be more options. Let's try to classify solutions=20 in terms of security, complexity and scaleability.=20 The WG must take decisions and opinions will be split.=20 But I think it's time to make some progress on the security=20 issue. Regards, R=FCdiger |for security (and in particular for security association=20 |establishment) the following issues are of importance:=20 | |- node A has to learn that a security association has to be=20 | established to some node C.=20 | node A and C support NSLP X; node B only NSLP Y | how and when is this information obtained? wouldn't your example have to be extended to nodes X, Y and Z all support NSLP A and peer in the order shown.=20 The are separated by an unknown number of NTLP hops. In=20 some cases, it may be desireable for NSLP Z to directly=20 signal to NSLP X. |- at which layer are messages protected? (ntlp/nslp) | |we have seen a number of protocol proposals in the past. there=20 |it can easily be seen that differences exist which have an=20 |impact on security. it is important to make the default mode=20 |of operation very clear and precise. | |ciao |hannes _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu Oct 2 14:13:03 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17735 for ; Thu, 2 Oct 2003 14:13:03 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A57wQ-0000xX-1s for nsis-archive@odin.ietf.org; Thu, 02 Oct 2003 14:12:42 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h92ICgJ7003683 for nsis-archive@odin.ietf.org; Thu, 2 Oct 2003 14:12:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A57vl-0000ub-OX; Thu, 02 Oct 2003 14:12:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A57vS-0000uL-Av for nsis@optimus.ietf.org; Thu, 02 Oct 2003 14:11:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17535 for ; Thu, 2 Oct 2003 14:11:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A57vP-0004ZE-00 for nsis@ietf.org; Thu, 02 Oct 2003 14:11:39 -0400 Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx with esmtp (Exim 4.12) id 1A57vP-0004Xu-00 for nsis@ietf.org; Thu, 02 Oct 2003 14:11:39 -0400 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Thu, 2 Oct 2003 19:11:01 +0100 Message-ID: From: "Hancock, Robert" To: Tschofenig Hannes , "'Geib, Ruediger'" , nsis@ietf.org Subject: RE: [NSIS] Reliability and Security Date: Thu, 2 Oct 2003 19:11:04 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , hi hannes, > -----Original Message----- > From: Tschofenig Hannes [mailto:hannes.tschofenig@siemens.com] > sorry for the late reply - i had to rejoin the army (=> no > wlan coverage in > the austrian mountains :-)). so we shall maybe see some more firepower applied to the NSIS security issues ;-) > > thank you for your response. i also like your text but it does not > completely address my issues. i know that there are several ways to > implement the "Bypassing Intermediate Nodes" procedure. an > interesting draft > by bob lindell and bob braden have already discussed these > issues some time > ago (see draft-lindell-waypoint-00.txt). ping pan addressed > the performance > implications in his work (e.g. see > ). i think there is a fairly well defined question about how to enforce 'complete' bypass for e2e addressed packets while still using fast-path processing. my assumption at the moment is that if this is wanted, then something based on Router Alert is the right way to go - provided the values in the option field are sensible assigned, RA is very simple to process and there doesn't seem to be a good alternative (as you know, I don't like using the TTL as a scoping mechanism). i don't believe there are specific security issues here. > > for security (and in particular for security association > establishment) the > following issues are of importance: > > - node A has to learn that a security association has to be > established to > some node C. > node A and C support NSLP X; node B only NSLP Y > how and when is this information obtained? my view here is that - provided the packet is marked in such a way that NSLP B can tell by packet inspection that it has no interest - then this situation between A and C should be handled as though node B was not there at all, i.e. it should take no part at all in the signalling exchange. how A and C negotiate their relationship is of course open, but adding B doesn't make it a different question. > > - at which layer are messages protected? (ntlp/nslp) i believe that the NTLP should offer a channel security mechanism supporting confidentiality, integrity etc. and allowing the re-use of standard mutual authentication between A and C. whether the NSLP chooses to depend on this or do something extra/instead is up to the NSLP designers. the hard problem arises where we would like node B to do something to the message but not to have complete access to it (e.g. to translate addresses or to mutate a measurement field). one way to do this would be for the NTLP channel security mechanism between A and C to protect only some of the payload. i think anything more complex than that will be over-complex; in particular, if you want different levels of protection for different parts of the message then nodes A, B and C will all have to implement the NSLP and the NSLP will have to define the different protection levels beyond what can be done by the NTLP. > > we have seen a number of protocol proposals in the past. > there it can easily > be seen that differences exist which have an impact on security. it is > important to make the default mode of operation very clear > and precise. quite true. r. > > ciao > hannes _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Fri Oct 3 04:37:07 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27346 for ; Fri, 3 Oct 2003 04:37:07 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5LQa-00039P-Iw for nsis-archive@odin.ietf.org; Fri, 03 Oct 2003 04:36:45 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h938ai8d012096 for nsis-archive@odin.ietf.org; Fri, 3 Oct 2003 04:36:44 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5LPu-00034d-S0; Fri, 03 Oct 2003 04:36:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5LPN-00034A-4u for nsis@optimus.ietf.org; Fri, 03 Oct 2003 04:35:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27301 for ; Fri, 3 Oct 2003 04:35:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5LPJ-0005XV-00 for nsis@ietf.org; Fri, 03 Oct 2003 04:35:25 -0400 Received: from rsys002a.roke.co.uk ([193.118.192.251]) by ietf-mx with esmtp (Exim 4.12) id 1A5LPJ-0005XI-00 for nsis@ietf.org; Fri, 03 Oct 2003 04:35:25 -0400 Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Fri, 3 Oct 2003 09:34:56 +0100 Message-ID: From: "McDonald, Andrew" To: "'Cheng Hong'" , sven.van_den_bosch@alcatel.be Cc: nsis@ietf.org Subject: RE: [NSIS] Re: qos-nslp-00 Date: Fri, 3 Oct 2003 09:34:56 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Hi Cheng, Cheng Hong wrote: > The model of operation in Figure 1 shows that the data flow would go > through the "Outgoing Interface Selection (Forwarding)" block before > entering the "Traffic Control" block. Does this mean that the traffic > control in the model would only apply on the outgoing interface? Figure 1 is only for guidance, to help give a visual idea of the different elements involved and their relationship to one another. It doesn't constrain the possible implementations. (Maybe an additional sentence is needed to clarify this.) Since there is an implicit assumption that we are specifying QoS for a flow through the router, it makes sense to control the QoS for the two interfaces (input, output) together, i.e. once the output interface is known. A natural implementation would be to do as much as possible of the traffic control on the output interface, but this is not compelled. In theory you could use a resource specification which separately defined the input resources and output resources, in which case it might be more natural to do traffic control in both places. (But you could still implement it all on the output anyway.) > I noticed it's somehow different from the figure in RFC2205. Is this > change intentional? Yes, although it was originally based on Figure 1 from RFC2205, it is different. This is mainly to reflect the NSIS layer split, but also, hopefully, to improve clarity. Are there any particular elements that aren't clear, or need explaining? Andrew _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Fri Oct 3 05:05:59 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27948 for ; Fri, 3 Oct 2003 05:05:59 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5LsX-000465-JD for nsis-archive@odin.ietf.org; Fri, 03 Oct 2003 05:05:38 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9395bHK015749 for nsis-archive@odin.ietf.org; Fri, 3 Oct 2003 05:05:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5Lry-00041k-1u; Fri, 03 Oct 2003 05:05:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5Lr0-00040K-54 for nsis@optimus.ietf.org; Fri, 03 Oct 2003 05:04:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27914 for ; Fri, 3 Oct 2003 05:03:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5Lqw-0005k5-00 for nsis@ietf.org; Fri, 03 Oct 2003 05:03:58 -0400 Received: from rsys002a.roke.co.uk ([193.118.192.251]) by ietf-mx with esmtp (Exim 4.12) id 1A5Lqw-0005jq-00 for nsis@ietf.org; Fri, 03 Oct 2003 05:03:58 -0400 Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Fri, 3 Oct 2003 10:03:29 +0100 Message-ID: From: "Hancock, Robert" To: "Geib, Ruediger" , hannes.tschofenig@siemens.com Cc: nsis@ietf.org Subject: RE: [NSIS] Reliability and Security Date: Fri, 3 Oct 2003 10:03:26 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable hi all, > - NTLP and NSLP security are combined. This would result=20 > in chains of trust. Complex. i think this depends on what you mean by 'combined'. (see later). > - NTLP has no security, security is done by NSLP. Bad idea,=20 > DoS attacks should be inhibited at the lowest possible=20 > level. this i entirely agree on. one of the benefits of allowing the use of a well known transport protocol in the NTLP is that you can inherit the DoS protection techniques that have been thought out for the newer protocols (sctp/dccp). > - NTLP and NSLP have separated security mechanisms. Not very=20 > nice if operators must locate errors. If possible,=20 > separate instances of the same security mechanism. i don't really see the problem here. provided the failing layer reports errors in a helpful way, what do you see going wrong? > - If you look at the example I've added below, NSLP may=20 > benefit from chains of trust. Is there a smart way of=20 > organising them? i'm sorry but i didn't really follow it. the node names and nslp names seem to get swapped between hannes and your text? > - We'll have to agree which protection is required at what=20 > level (I'm e.g favouring NTLP with authentication only). if you mean 'authentication and key exchange which enables message protection (integrity, confidentiality) but no authorisation aspects' then I agree also (and this is also what the framework says). a particular question (this is *my* scenario with *my* terminology): suppose nodes A and B both implement NSLP Q and are communicating over a direct NTLP connection which has been set up with mutual authentication and message integrity protection, IF node B's authorisation policy is 'I will do anything that node A asks if I can actually do it' does that require an NSLP level security association to secure that authorisation, or can it be inferred from the underlying NTLP association? r. > - There may be more options. Let's try to classify solutions=20 > in terms of security, complexity and scaleability.=20 >=20 > The WG must take decisions and opinions will be split.=20 > But I think it's time to make some progress on the security=20 > issue. >=20 > Regards, R=FCdiger >=20 >=20 > |for security (and in particular for security association=20 > |establishment) the following issues are of importance:=20 > | > |- node A has to learn that a security association has to be=20 > | established to some node C.=20 > | node A and C support NSLP X; node B only NSLP Y > | how and when is this information obtained? >=20 > wouldn't your example have to be extended to nodes X, > Y and Z all support NSLP A and peer in the order shown.=20 > The are separated by an unknown number of NTLP hops. In=20 > some cases, it may be desireable for NSLP Z to directly=20 > signal to NSLP X. >=20 > |- at which layer are messages protected? (ntlp/nslp) > | > |we have seen a number of protocol proposals in the past. there=20 > |it can easily be seen that differences exist which have an=20 > |impact on security. it is important to make the default mode=20 > |of operation very clear and precise. > | > |ciao > |hannes >=20 > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Fri Oct 3 12:15:00 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14141 for ; Fri, 3 Oct 2003 12:15:00 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5SZh-0006Dw-0d for nsis-archive@odin.ietf.org; Fri, 03 Oct 2003 12:14:39 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h93GEak3023918 for nsis-archive@odin.ietf.org; Fri, 3 Oct 2003 12:14:36 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5SZ7-00067I-6f; Fri, 03 Oct 2003 12:14:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5SY3-00065t-Nz for nsis@optimus.ietf.org; Fri, 03 Oct 2003 12:13:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14066 for ; Fri, 3 Oct 2003 12:12:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5SY2-0002mV-00 for nsis@ietf.org; Fri, 03 Oct 2003 12:12:54 -0400 Received: from david.siemens.de ([192.35.17.14]) by ietf-mx with esmtp (Exim 4.12) id 1A5SY1-0002mS-00 for nsis@ietf.org; Fri, 03 Oct 2003 12:12:53 -0400 Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by david.siemens.de (8.11.7/8.11.7) with ESMTP id h93GCqb17333; Fri, 3 Oct 2003 18:12:52 +0200 (MEST) Received: from joe ([139.25.62.7]) by mail1.siemens.de (8.11.7/8.11.7) with ESMTP id h93GCon03425; Fri, 3 Oct 2003 18:12:50 +0200 (MEST) From: "Hannes Tschofenig" To: "'Hancock, Robert'" , "'Geib, Ruediger'" Cc: Subject: RE: [NSIS] Reliability and Security Date: Fri, 3 Oct 2003 18:12:37 +0200 Message-ID: <000f01c389c9$29c935b0$010aa8c0@joe> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: quoted-printable Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable hi robert,=20 hi ruediger,=20 > hi all, >=20 > > - NTLP and NSLP security are combined. This would result=20 > > in chains of trust. Complex. > i think this depends on what you mean by 'combined'. > (see later). >=20 > > - NTLP has no security, security is done by NSLP. Bad idea,=20 > > DoS attacks should be inhibited at the lowest possible=20 > > level. > this i entirely agree on. one of the benefits of allowing the=20 > use of a well known transport protocol in the NTLP is that=20 > you can inherit the DoS protection techniques that have been=20 > thought out for the newer protocols (sctp/dccp). do you think it is sufficient to rely on the mechanisms offered by newer transport layer protocols from a security point of view?=20 >=20 > > - NTLP and NSLP have separated security mechanisms. Not very=20 > > nice if operators must locate errors. If possible,=20 > > separate instances of the same security mechanism. > i don't really see the problem here. provided the failing=20 > layer reports errors in a helpful way, what do you see going wrong? i don't see this as a problem too. you have to be more specific here to address your concern.=20 >=20 > > - If you look at the example I've added below, NSLP may=20 > > benefit from chains of trust. Is there a smart way of=20 > > organising them? > i'm sorry but i didn't really follow it. the node names and=20 > nslp names seem to get swapped between hannes and your text? please clarify.=20 >=20 > > - We'll have to agree which protection is required at what=20 > > level (I'm e.g favouring NTLP with authentication only). > if you mean 'authentication and key exchange which enables=20 > message protection (integrity, confidentiality) but no=20 > authorisation aspects' then I agree also (and this is also=20 > what the framework says). i guess i have to explain this in more detail - i will provide some = text.=20 many authorization issues which we have described so far in our = nsis-authz and nsis-aaa drafts are concerned with a user requesting a qos = resource. there are, however, other authorization issues here.=20 anyway, some authorization decisions can only be made at the nslp layer where some additional information is available.=20 however, it does not mean that you do not provide security at a lower = layer (such as integrity, replay and confidentiality protection). an example: = rsvp provides integrity and replay protection with the rsvp integrity object which protects the entire message. unfortunately an authentication and = key exchange protocol is missing which provides the keys for this security association. an authorization decision can be made with the identity = used in such an authentication and key exchange protocol. with the user identity representation rfc some additional mechanism have been added which aim = to provide information about the user identity.=20 >=20 > a particular question (this is *my* scenario with *my* > terminology): > suppose nodes A and B both implement NSLP Q and are=20 > communicating over a direct NTLP connection which has been=20 > set up with mutual authentication and message integrity=20 > protection, IF node B's authorisation policy is 'I will do=20 > anything that node A asks if I can actually do it' does that=20 > require an NSLP level security association to secure that=20 > authorisation, or can it be inferred from the underlying NTLP=20 > association? i guess it would be good to clarify what it means to have a security association at a particular layer.=20 to me it means which parts of the nsis message are covered by a = particular security association. if, however, the entities terminate a different physical entities then it is difficult to pass the identity up to the = nslp for additional authorization. i will provide some more details on this. = ciao hannes >=20 > r. >=20 > > - There may be more options. Let's try to classify solutions=20 > > in terms of security, complexity and scaleability. > >=20 > > The WG must take decisions and opinions will be split. > > But I think it's time to make some progress on the security=20 > > issue. > >=20 > > Regards, R=FCdiger > >=20 > >=20 > > |for security (and in particular for security association > > |establishment) the following issues are of importance:=20 > > | > > |- node A has to learn that a security association has to be > > | established to some node C.=20 > > | node A and C support NSLP X; node B only NSLP Y > > | how and when is this information obtained? > >=20 > > wouldn't your example have to be extended to nodes X, > > Y and Z all support NSLP A and peer in the order shown. > > The are separated by an unknown number of NTLP hops. In=20 > > some cases, it may be desireable for NSLP Z to directly=20 > > signal to NSLP X. > >=20 > > |- at which layer are messages protected? (ntlp/nslp) > > | > > |we have seen a number of protocol proposals in the past. there > > |it can easily be seen that differences exist which have an=20 > > |impact on security. it is important to make the default mode=20 > > |of operation very clear and precise. > > | > > |ciao > > |hannes > >=20 > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > >=20 >=20 > -- > Registered Office: Roke Manor Research Ltd, Siemens House,=20 > Oldbury, Bracknell, Berkshire. RG12 8FZ >=20 > The information contained in this e-mail and any attachments=20 > is confidential to Roke Manor Research Ltd and must not be=20 > passed to any third party without permission. This=20 > communication is for information only and shall not create or=20 > change any contractual relationship. >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Fri Oct 3 12:15:58 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14191 for ; Fri, 3 Oct 2003 12:15:58 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5Saf-0006J8-Mm for nsis-archive@odin.ietf.org; Fri, 03 Oct 2003 12:15:37 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h93GFbxP024230 for nsis-archive@odin.ietf.org; Fri, 3 Oct 2003 12:15:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5Sa6-0006F4-Fn; Fri, 03 Oct 2003 12:15:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5SZA-00069n-Q5 for nsis@optimus.ietf.org; Fri, 03 Oct 2003 12:14:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14110 for ; Fri, 3 Oct 2003 12:13:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5SZ9-0002nK-00 for nsis@ietf.org; Fri, 03 Oct 2003 12:14:03 -0400 Received: from david.siemens.de ([192.35.17.14]) by ietf-mx with esmtp (Exim 4.12) id 1A5SZ8-0002nB-00 for nsis@ietf.org; Fri, 03 Oct 2003 12:14:02 -0400 Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by david.siemens.de (8.11.7/8.11.7) with ESMTP id h93GE1b17846; Fri, 3 Oct 2003 18:14:01 +0200 (MEST) Received: from joe ([139.25.62.7]) by mail1.siemens.de (8.11.7/8.11.7) with ESMTP id h93GE0n03911; Fri, 3 Oct 2003 18:14:00 +0200 (MEST) From: "Hannes Tschofenig" To: "'Geib, Ruediger'" Cc: Subject: RE: [NSIS] Reliability and Security Date: Fri, 3 Oct 2003 18:13:46 +0200 Message-ID: <001001c389c9$531c20d0$010aa8c0@joe> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal In-Reply-To: <2A8DB02E3018D411901B009027FD3A3F03BC0285@mchp905a.mch.sbs.de> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: quoted-printable Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable hi ruediger,=20 thank you for your reponse.=20 =20 i see two basic approaches:=20 =20 a) the ntlp does not contain a discovery procedure which=20 allows to learn the next ntlp node which supports nslp X.=20 =20 b) the ntlp supports such a discover procedure.=20 =20 in case (a) you can never be sure that a node implementing=20 nslp X has access to authentication information (since=20 another nslp could be somewhere in the middle). in this case=20 you would have to do a discovery at the nslp layer to learn=20 the next nslp aware node to (possibly) secure nslp messages=20 between these two nodes (if necessary).=20 in case of (b) you would know that the next node you are=20 addressing is actually a node which supports nslp X.=20 from a security point of view i have the following impression:=20 =20 - you need to provide some security at the ntlp layer.=20 - you need to provide some security at the nslp layer at the nslp additional security protection should be done=20 only for certain objects if there is a good reason (e.g. some=20 reasons have been described in the nat/firewall case).=20 - but if you have a configuration like the one described in=20 figure 1 then you might not want to secure messages at the=20 ntlp and at the nslp (particularly if this is the default signaling = case). i am not saying that performance should be considered first but it = should also be considered.=20 =20 +------+ +------+ | NE | | NE | |+----+| |+----+| ||NSLP|| NSLP Security ||NSLP|| || 1 || - - - - - - - - - - - - - || 1 || |+----+| |+----+| | || | | || | |+----+| NTLP Security |+----+| = =3D=3D=3D=3D||NTLP||=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D||NTLP||=3D=3D=3D=3D |+----+| |+----+| +------+ +------+ figure 1: nslp & ntlp security thanks again, ruediger, for pointing to the issues. i will=20 try to write a short summary on the different options we have.=20 =20 ciao hannes >=20 =20 > >=20 > > Hannes, > >=20 > >=20 > > What are the options we have? > >=20 > > - NTLP and NSLP security are combined. This would result=20 > > in chains of trust. Complex. > > - NTLP has no security, security is done by NSLP. Bad idea,=20 > > DoS attacks should be inhibited at the lowest possible=20 > > level. > > - NTLP and NSLP have separated security mechanisms. Not very=20 > > nice if operators must locate errors. If possible,=20 > > separate instances of the same security mechanism. > > - If you look at the example I've added below, NSLP may=20 > > benefit from chains of trust. Is there a smart way of=20 > > organising them? > > - We'll have to agree which protection is required at what=20 > > level (I'm e.g favouring NTLP with authentication only). > > - There may be more options. Let's try to classify solutions=20 > > in terms of security, complexity and scaleability. > >=20 > > The WG must take decisions and opinions will be split. > > But I think it's time to make some progress on the security=20 > > issue. > >=20 > > Regards, R=FCdiger > >=20 > >=20 > > |for security (and in particular for security association > > |establishment) the following issues are of importance:=20 > > | > > |- node A has to learn that a security association has to be > > | established to some node C.=20 > > | node A and C support NSLP X; node B only NSLP Y > > | how and when is this information obtained? > >=20 > > wouldn't your example have to be extended to nodes X, > > Y and Z all support NSLP A and peer in the order shown. > > The are separated by an unknown number of NTLP hops. In=20 > > some cases, it may be desireable for NSLP Z to directly=20 > > signal to NSLP X. > >=20 > > |- at which layer are messages protected? (ntlp/nslp) > > | > > |we have seen a number of protocol proposals in the past. there > > |it can easily be seen that differences exist which have an=20 > > |impact on security. it is important to make the default mode=20 > > |of operation very clear and precise. > > | > > |ciao > > |hannes > >=20 > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > >=20 >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Fri Oct 3 12:32:57 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15425 for ; Fri, 3 Oct 2003 12:32:57 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5Sr6-0007IS-Sh for nsis-archive@odin.ietf.org; Fri, 03 Oct 2003 12:32:36 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h93GWa3E028032 for nsis-archive@odin.ietf.org; Fri, 3 Oct 2003 12:32:36 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5SqX-0007Bx-CQ; Fri, 03 Oct 2003 12:32:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5Spt-0007AD-Ia for nsis@optimus.ietf.org; Fri, 03 Oct 2003 12:31:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15306 for ; Fri, 3 Oct 2003 12:31:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5Spr-0003G3-00 for nsis@ietf.org; Fri, 03 Oct 2003 12:31:19 -0400 Received: from thoth.sbs.de ([192.35.17.2]) by ietf-mx with esmtp (Exim 4.12) id 1A5Spr-0003Fx-00 for nsis@ietf.org; Fri, 03 Oct 2003 12:31:19 -0400 Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by thoth.sbs.de (8.11.7/8.11.7) with ESMTP id h93GVHj12838; Fri, 3 Oct 2003 18:31:17 +0200 (MEST) Received: from joe ([139.25.62.7]) by mail1.siemens.de (8.11.7/8.11.7) with ESMTP id h93GVGn12111; Fri, 3 Oct 2003 18:31:16 +0200 (MEST) From: "Hannes Tschofenig" To: "'Hancock, Robert'" , "'Geib, Ruediger'" , Subject: RE: [NSIS] Reliability and Security Date: Fri, 3 Oct 2003 18:31:03 +0200 Message-ID: <001101c389cb$bce35f90$010aa8c0@joe> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit hi robert, thanks for your comments. > hi hannes, > > > -----Original Message----- > > From: Tschofenig Hannes [mailto:hannes.tschofenig@siemens.com] > > > sorry for the late reply - i had to rejoin the army (=> no > > wlan coverage in > > the austrian mountains :-)). > > so we shall maybe see some more firepower applied to the NSIS > security issues ;-) i have never seen it that way? > > > > > thank you for your response. i also like your text but it does not > > completely address my issues. i know that there are several ways to > > implement the "Bypassing Intermediate Nodes" procedure. an > interesting > > draft by bob lindell and bob braden have already discussed these > > issues some time > > ago (see draft-lindell-waypoint-00.txt). ping pan addressed > > the performance > > implications in his work (e.g. see > > ). > > i think there is a fairly well defined question about how to > enforce 'complete' bypass for e2e addressed packets while > still using fast-path > processing. my assumption at the moment is that if this is wanted, > then something based on Router Alert is the right way to go - > provided the values in the option field are sensible > assigned, RA is very simple to process and there doesn't seem > to be a good alternative (as you > know, I don't like using the TTL as a scoping mechanism). i > don't believe there are specific security issues here. i agree that the router alert option is a good choice. with regard to the discovery there is still some degree of freedom here. > > > > > for security (and in particular for security association > > establishment) the > > following issues are of importance: > > > > - node A has to learn that a security association has to be > > established to > > some node C. > > node A and C support NSLP X; node B only NSLP Y > > how and when is this information obtained? > > my view here is that - provided the packet is marked > in such a way that NSLP B can tell by packet inspection > that it has no interest - then this situation between > A and C should be handled as though node B was not there > at all, i.e. it should take no part at all in the signalling > exchange. how A and C negotiate their relationship is of > course open, but adding B doesn't make it a different question. this mechanism can be provided by a separate discovery mechanism. i don't know what the status of the current ntlp discussions with regard to the path-coupled discovery is. > > > > > - at which layer are messages protected? (ntlp/nslp) > > i believe that the NTLP should offer a channel security > mechanism supporting confidentiality, integrity etc. > and allowing the re-use of standard mutual authentication > between A and C. whether the NSLP chooses to depend on this > or do something extra/instead is up to the NSLP designers. this answeres a question to you in a previous mail. > > the hard problem arises where we would like node B to do > something to the message but not to have complete access to > it (e.g. to translate addresses or to mutate a measurement > field). one way to do this would be for the NTLP channel > security mechanism between A and C to protect only some of > the payload. this is one possibility. another one would be to treat this node as a node with a virtual nslp implementation (which effectively does nothing except for changing the fields). with some security mechanisms (such as ipsec or tls) you cannot skip an intermediate node. if you have nslp implementation X on node A and C then you need to address these nodes directly - without an intermediate node B. i am not saying that we should tailor our solution to support these protocols. i rather would like to point to the security implications to this design decision. > i think anything more complex than that will be over-complex; > in particular, if you want different levels of protection for > different parts of the message then nodes A, B and C will all > have to implement the NSLP and the NSLP will have to define > the different protection levels beyond what can be done by the NTLP. > > > > > we have seen a number of protocol proposals in the past. > > there it can easily > > be seen that differences exist which have an impact on > security. it is > > important to make the default mode of operation very clear > > and precise. > > quite true. > ciao hannes > r. > > > > > ciao > > hannes > > -- > Registered Office: Roke Manor Research Ltd, Siemens House, > Oldbury, Bracknell, Berkshire. RG12 8FZ > > The information contained in this e-mail and any attachments > is confidential to Roke Manor Research Ltd and must not be > passed to any third party without permission. This > communication is for information only and shall not create or > change any contractual relationship. > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Sun Oct 5 23:38:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04313 for ; Sun, 5 Oct 2003 23:38:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6MCE-0000zi-MO for nsis-archive@odin.ietf.org; Sun, 05 Oct 2003 23:38:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h963c6Uo003816 for nsis-archive@odin.ietf.org; Sun, 5 Oct 2003 23:38:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6MC8-0000zQ-8D; Sun, 05 Oct 2003 23:38:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6MBa-0000ok-5A for nsis@optimus.ietf.org; Sun, 05 Oct 2003 23:37:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04285 for ; Sun, 5 Oct 2003 23:37:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A6MBX-0000LV-00 for nsis@ietf.org; Sun, 05 Oct 2003 23:37:23 -0400 Received: from mailsrv.psl.com.sg ([202.14.153.3]) by ietf-mx with esmtp (Exim 4.12) id 1A6MBW-0000Kk-00 for nsis@ietf.org; Sun, 05 Oct 2003 23:37:22 -0400 Received: from netpronote3 ([10.81.113.70]) by mailsrv.psl.com.sg (8.12.9/8.12.9) with SMTP id h963SxRn022082; Mon, 6 Oct 2003 11:29:01 +0800 (SGT) From: "Cheng Hong" To: "McDonald, Andrew" , Cc: Subject: RE: [NSIS] Re: qos-nslp-00 Date: Mon, 6 Oct 2003 11:40:05 +0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200 Importance: Normal In-Reply-To: Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Andrew, Thanks a lot for the detail explanation. You are right that most of the implementations would choose to work only on the output interface, since it's simpler. But, due to other considerations, e.g. efficiency, etc, an implementation could choose to do it in a different way. For example, one of the popular QoS implementations ALTQ (http://www.csl.sony.co.jp/person/kjc/kjc/software.html#ALTQ ) actually has the traffic conditioner on the ingress interface in its DiffServ module. Since the QoS-NSLP is meant to be agnostic to QoS models, I would prefer the logical model also be neutral. Maybe some text for clarification is necessary in the section. Or, could we do something like the RFC2205, where the routing process is put at a position not implying the processing sequence? Best regards Cheng > -----Original Message----- > From: McDonald, Andrew [mailto:andrew.mcdonald@roke.co.uk] > Sent: Friday, October 03, 2003 4:35 PM > To: 'Cheng Hong'; sven.van_den_bosch@alcatel.be > Cc: nsis@ietf.org > Subject: RE: [NSIS] Re: qos-nslp-00 > > > Hi Cheng, > > Cheng Hong wrote: > > The model of operation in Figure 1 shows that the data flow would go > > through the "Outgoing Interface Selection (Forwarding)" block before > > entering the "Traffic Control" block. Does this mean that the traffic > > control in the model would only apply on the outgoing interface? > > Figure 1 is only for guidance, to help give a visual idea of the > different elements involved and their relationship to one > another. It doesn't constrain the possible implementations. > (Maybe an additional sentence is needed to clarify this.) > > Since there is an implicit assumption that we are specifying QoS > for a flow through the router, it makes sense to control the QoS > for the two interfaces (input, output) together, i.e. once the > output interface is known. A natural implementation would be to > do as much as possible of the traffic control on the output > interface, but this is not compelled. > > In theory you could use a resource specification which separately > defined the input resources and output resources, in which case > it might be more natural to do traffic control in both places. > (But you could still implement it all on the output anyway.) > > > I noticed it's somehow different from the figure in RFC2205. Is this > > change intentional? > > Yes, although it was originally based on Figure 1 from RFC2205, > it is different. This is mainly to reflect the NSIS layer split, > but also, hopefully, to improve clarity. Are there any particular > elements that aren't clear, or need explaining? > > > Andrew > > -- > Registered Office: Roke Manor Research Ltd, Siemens House, > Oldbury, Bracknell, > Berkshire. RG12 8FZ > > The information contained in this e-mail and any attachments is > confidential to > Roke Manor Research Ltd and must not be passed to any third party without > permission. This communication is for information only and shall > not create or > change any contractual relationship. > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Mon Oct 6 03:04:24 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20087 for ; Mon, 6 Oct 2003 03:04:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6PPX-0008Vv-9I for nsis-archive@odin.ietf.org; Mon, 06 Oct 2003 03:04:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h96743Ff032727 for nsis-archive@odin.ietf.org; Mon, 6 Oct 2003 03:04:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6PPV-0008Vg-7F; Mon, 06 Oct 2003 03:04:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6POl-0008Ur-6h for nsis@optimus.ietf.org; Mon, 06 Oct 2003 03:03:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20078 for ; Mon, 6 Oct 2003 03:03:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A6POh-0001hi-00 for nsis@ietf.org; Mon, 06 Oct 2003 03:03:11 -0400 Received: from mail1.telekom.de ([62.225.183.202]) by ietf-mx with esmtp (Exim 4.12) id 1A6POg-0001hZ-00 for nsis@ietf.org; Mon, 06 Oct 2003 03:03:10 -0400 Received: from g8pbr.blf01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Mon, 6 Oct 2003 09:02:29 +0200 Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id <4LDZPPYA>; Mon, 6 Oct 2003 09:02:29 +0200 Message-Id: <9F8582E37B2EE5498E76392AEDDCD3FE03DBB646@G8PQD.blf01.telekom.de> From: "Geib, Ruediger" To: Hannes.Tschofenig@siemens.com Cc: nsis@ietf.org Subject: RE: [NSIS] Reliability and Security Date: Mon, 6 Oct 2003 09:02:28 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi Hannes, if I understood you right, here you address the=20 issue of adjacent NTLP nodes both supporting the=20 same NSLP. It would of course be great if in=20 this case NSLP would not need to run security=20 features already provided by NTLP. This requires NTLP to be aware of NSLP adjacencies=20 and required protection as you describe.=20 If this doesn't require complicated specification,=20 it may be a useful feature. Regards, R=FCdiger |-----Original Message----- |From: Hannes Tschofenig [mailto:Hannes.Tschofenig@siemens.com] |Sent: Friday, October 03, 2003 6:14 PM |To: Geib, R=FCdiger |Cc: nsis@ietf.org |Subject: RE: [NSIS] Reliability and Security | | |hi ruediger,=20 | |thank you for your reponse.=20 |=20 |i see two basic approaches:=20 |=20 |a) the ntlp does not contain a discovery procedure which=20 |allows to learn the next ntlp node which supports nslp X.=20 |=20 |b) the ntlp supports such a discover procedure.=20 |=20 |in case (a) you can never be sure that a node implementing=20 |nslp X has access to authentication information (since=20 |another nslp could be somewhere in the middle). in this case=20 |you would have to do a discovery at the nslp layer to learn=20 |the next nslp aware node to (possibly) secure nslp messages=20 |between these two nodes (if necessary).=20 | |in case of (b) you would know that the next node you are=20 |addressing is actually a node which supports nslp X.=20 | |from a security point of view i have the following impression:=20 |=20 |- you need to provide some security at the ntlp layer.=20 |- you need to provide some security at the nslp layer |at the nslp additional security protection should be done=20 |only for certain objects if there is a good reason (e.g. some=20 |reasons have been described in the nat/firewall case).=20 |- but if you have a configuration like the one described in=20 |figure 1 then you might not want to secure messages at the=20 |ntlp and at the nslp (particularly if this is the default=20 |signaling case). |i am not saying that performance should be considered first=20 |but it should |also be considered.=20 |=20 | +------+ +------+ | | NE | | NE | | |+----+| |+----+| | ||NSLP|| NSLP Security ||NSLP|| | || 1 || - - - - - - - - - - - - - || 1 || | |+----+| |+----+| | | || | | || | | |+----+| NTLP Security |+----+| | = =3D=3D=3D=3D||NTLP||=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D||NTLP||=3D=3D=3D=3D | |+----+| |+----+| | +------+ +------+ | figure 1: nslp & ntlp security | |thanks again, ruediger, for pointing to the issues. i will=20 |try to write a short summary on the different options we have.=20 |=20 |ciao |hannes |>=20 |=20 |> >=20 |> > Hannes, |> >=20 |> >=20 |> > What are the options we have? |> >=20 |> > - NTLP and NSLP security are combined. This would result=20 |> > in chains of trust. Complex. |> > - NTLP has no security, security is done by NSLP. Bad idea,=20 |> > DoS attacks should be inhibited at the lowest possible=20 |> > level. |> > - NTLP and NSLP have separated security mechanisms. Not very=20 |> > nice if operators must locate errors. If possible,=20 |> > separate instances of the same security mechanism. |> > - If you look at the example I've added below, NSLP may=20 |> > benefit from chains of trust. Is there a smart way of=20 |> > organising them? |> > - We'll have to agree which protection is required at what=20 |> > level (I'm e.g favouring NTLP with authentication only). |> > - There may be more options. Let's try to classify solutions=20 |> > in terms of security, complexity and scaleability. |> >=20 |> > The WG must take decisions and opinions will be split. |> > But I think it's time to make some progress on the security=20 |> > issue. |> >=20 |> > Regards, R=FCdiger |> >=20 |> >=20 |> > |for security (and in particular for security association |> > |establishment) the following issues are of importance:=20 |> > | |> > |- node A has to learn that a security association has to be |> > | established to some node C.=20 |> > | node A and C support NSLP X; node B only NSLP Y |> > | how and when is this information obtained? |> >=20 |> > wouldn't your example have to be extended to nodes X, |> > Y and Z all support NSLP A and peer in the order shown. |> > The are separated by an unknown number of NTLP hops. In=20 |> > some cases, it may be desireable for NSLP Z to directly=20 |> > signal to NSLP X. |> >=20 |> > |- at which layer are messages protected? (ntlp/nslp) |> > | |> > |we have seen a number of protocol proposals in the past. there |> > |it can easily be seen that differences exist which have an=20 |> > |impact on security. it is important to make the default mode=20 |> > |of operation very clear and precise. |> > | |> > |ciao |> > |hannes |> >=20 |> > _______________________________________________ |> > nsis mailing list |> > nsis@ietf.org |> > https://www1.ietf.org/mailman/listinfo/nsis |> >=20 |>=20 | _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Mon Oct 6 03:26:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20409 for ; Mon, 6 Oct 2003 03:26:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6Pks-0000u2-Ew for nsis-archive@odin.ietf.org; Mon, 06 Oct 2003 03:26:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h967Q5OA003449 for nsis-archive@odin.ietf.org; Mon, 6 Oct 2003 03:26:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6Pkp-0000tJ-QR; Mon, 06 Oct 2003 03:26:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6Pjy-0000sP-6E for nsis@optimus.ietf.org; Mon, 06 Oct 2003 03:25:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20397 for ; Mon, 6 Oct 2003 03:25:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A6Pjv-0001qA-00 for nsis@ietf.org; Mon, 06 Oct 2003 03:25:07 -0400 Received: from mail1.telekom.de ([62.225.183.202]) by ietf-mx with esmtp (Exim 4.12) id 1A6Pjv-0001pt-00 for nsis@ietf.org; Mon, 06 Oct 2003 03:25:07 -0400 Received: from g8pbr.blf01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Mon, 6 Oct 2003 09:24:10 +0200 Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id <4LDZPR26>; Mon, 6 Oct 2003 09:24:10 +0200 Message-Id: <9F8582E37B2EE5498E76392AEDDCD3FE03DBB647@G8PQD.blf01.telekom.de> From: "Geib, Ruediger" To: Hannes.Tschofenig@siemens.com, robert.hancock@roke.co.uk Cc: nsis@ietf.org Subject: RE: [NSIS] Reliability and Security Date: Mon, 6 Oct 2003 09:24:04 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi Hannes, hi Robert my clarifications on three of my remarks in line. Regards, R=FCdiger [RG] - NTLP and NSLP have separated security mechanisms. Not very=20 [RG] nice if operators must locate errors. If possible,=20 [RG] separate instances of the same security mechanism. [rh] i don't really see the problem here. provided the failing=20 [rh] layer reports errors in a helpful way, what do you see going = wrong? [HT]i don't see this as a problem too. you have to be more specific=20 [HT]here to address your concern. Operating networks is simplified if the overall number of operational=20 protocol stacks and mechanisms is minimised. It would be less desirable if NTLP operates security protocol A, while NSLP1 operates B and=20 NSLP2 C and so on. The ideal solution is they all using the same basic security mechanism. = Which may not be applied to full extent for NTLP, as there e.g.=20 authorisation isn't required.=20 =20 [RG] - If you look at the example I've added below, NSLP may=20 [RG] benefit from chains of trust. Is there a smart way of=20 [RG] organising them? [rh] i'm sorry but i didn't really follow it. the node names and=20 [rh] nslp names seem to get swapped between hannes and your text? [HT] please clarify.=20 Captiol letters: nodes with the same NSLP,=20 ->- signaling relations: A ->- B ->- C for some reason, A and C may benefit from a direct signaling=20 relation (if e.g. an earlier signaled "NSLP tunnel" allows=20 them to administrate dedicated resources).=20 A ->->- C. B's interaction with signaling isn't required. Does NSIS allow=20 for this? And if yes, how's authentication arranged between=20 A and C? [RG] - We'll have to agree which protection is required at what=20 [RG] level (I'm e.g favouring NTLP with authentication only). [rh] if you mean 'authentication and key exchange which enables=20 [rh] message protection (integrity, confidentiality) but no=20 [rh] authorisation aspects' then I agree also (and this is also=20 [rh] what the framework says). I'd look at authentication and integrity as mandatory NTLP=20 features. Would optional confidentiality on NTLP level be=20 suitable? _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Mon Oct 6 04:06:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21262 for ; Mon, 6 Oct 2003 04:06:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6QNY-0002Wq-OT for nsis-archive@odin.ietf.org; Mon, 06 Oct 2003 04:06:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h96864Jf009689 for nsis-archive@odin.ietf.org; Mon, 6 Oct 2003 04:06:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6QNW-0002W2-Lr; Mon, 06 Oct 2003 04:06:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6QMh-0002UM-TT for nsis@optimus.ietf.org; Mon, 06 Oct 2003 04:05:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21248 for ; Mon, 6 Oct 2003 04:05:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A6QMf-00029S-00 for nsis@ietf.org; Mon, 06 Oct 2003 04:05:09 -0400 Received: from lmr1.uibk.ac.at ([138.232.1.142] helo=smtp.uibk.ac.at) by ietf-mx with esmtp (Exim 4.12) id 1A6QMe-00029B-00 for nsis@ietf.org; Mon, 06 Oct 2003 04:05:08 -0400 Received: from lap10-c703.uibk.ac.at (lap10-c703.uibk.ac.at [138.232.65.57]) by smtp.uibk.ac.at (8.12.10/8.12.9/F1) with ESMTP id h9684XIf017461 for ; Mon, 6 Oct 2003 10:04:33 +0200 From: Michael Welzl To: nsis@ietf.org Content-Type: text/plain Organization: University of Innsbruck Message-Id: <1065427408.4795.30.camel@lap10-c703.uibk.ac.at> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) Date: 06 Oct 2003 10:03:29 +0200 Content-Transfer-Encoding: 7bit X-Spam-Score: -5.4 () RCV_UIBK,USER_AGENT_XIMIAN X-Scanned-By: MIMEDefang 2.35 at uibk.ac.at Content-Transfer-Encoding: 7bit Subject: [NSIS] Comments about draft-hancock-nsis-reliability-00 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi all, I just read the "Reliability Functions in the NSIS Transport Layer Protocol" draft; I generally think it is a very good work. However, having noticed the very short "congestion control" section, I would like to comment on a few things: Obviously, some signaling messages have important delay requirements. To some degree, this is certainly true for Refresh messages. Same for triggers - we should not forget that in the (theoretical :) ) case of a full-featured totally QoS-aware network, accounting will probably be coupled with QoS setup and QoS teardown messages ... thus, a user will pay more if they are delayed. I would therefore take the delay requirement in account for the congestion control section. So here are my recommendations: First, I would recommend using a rate-based instead of a window-based approach; especially over long-delay links, window based congestion control can lead to a stop-and-go behavior that would clearly be unwanted. This does not necessarily lead to a problem with TCP-friendliness as there are rate-based congestion control protocols that are TCP-friendly (e.g. RAP). Second, I would comment on the possibility of limiting signaling traffic by making it a fraction of the related data stream. If I remember things correctly, this has been done for RTCP/RTP... If, for instance, each node in a network generates only 3 % of signaling traffic, the whole signaling traffic in the network will always scale linearly with traffic. I'm not arguing for the use of a "magic number", but this general signaling property could be mentioned so messages can scale well, at least within one application. This may be unnecessary if the NTLP is congestion controlled, though ... Third, I would mandate an interface to specify requirements to the NTLP protocol. Maybe just delay, but maybe something else too?! The idea is: if you specify a delay requirement and use reliable transport, the sender transport protocol can use aging on its buffer - get rid of a message that would be transmitted for the 3rd time but has an exceeded delay limit, thereby freeing space for a new message. I know that what I propose here doesn't sound like it could be applied to existing transport protocol standards. The question is whether this is the right place for such a "wish list"... Cheers, Michael _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Mon Oct 6 11:18:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06979 for ; Mon, 6 Oct 2003 11:18:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6X7d-0002SV-R6 for nsis-archive@odin.ietf.org; Mon, 06 Oct 2003 11:18:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h96FI5vg009447 for nsis-archive@odin.ietf.org; Mon, 6 Oct 2003 11:18:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6X7Z-0002SD-6a; Mon, 06 Oct 2003 11:18:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6X6g-0002Rc-Ps for nsis@optimus.ietf.org; Mon, 06 Oct 2003 11:17:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06923 for ; Mon, 6 Oct 2003 11:16:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A6X6f-00071Z-00 for nsis@ietf.org; Mon, 06 Oct 2003 11:17:05 -0400 Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx with esmtp (Exim 4.12) id 1A6X6f-0006z3-00 for nsis@ietf.org; Mon, 06 Oct 2003 11:17:05 -0400 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Mon, 6 Oct 2003 16:16:33 +0100 Message-ID: From: "Hancock, Robert" To: "'Michael Welzl'" , nsis@ietf.org Subject: RE: [NSIS] Comments about draft-hancock-nsis-reliability-00 Date: Mon, 6 Oct 2003 16:16:33 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , hi michael, see below: > -----Original Message----- > From: Michael Welzl [mailto:michael.welzl@uibk.ac.at] > Sent: Monday, October 06, 2003 09:03 > To: nsis@ietf.org > Subject: [NSIS] Comments about draft-hancock-nsis-reliability-00 > > > Hi all, > > I just read the "Reliability Functions in the NSIS Transport > Layer Protocol" draft; I generally think it is a very good work. > However, having noticed the very short "congestion control" > section, I would like to comment on a few things: [aside: people joining the conversation late might need directing towards the companion work http://www.ietf.org/internet-drafts/draft-hancock-nsis-overload-00.txt which we discussed earlier.] anyway, i'm glad you liked it. > > Obviously, some signaling messages have important delay > requirements. To some degree, this is certainly true > for Refresh messages. Same for triggers - we should not > forget that in the (theoretical :) ) case of a > full-featured totally QoS-aware network, accounting will > probably be coupled with QoS setup and QoS teardown > messages ... thus, a user will pay more if they are > delayed. I would therefore take the delay requirement > in account for the congestion control section. So here > are my recommendations: > > > First, I would recommend using a rate-based instead of a > window-based approach; especially over long-delay links, > window based congestion control can lead to a > stop-and-go behavior that would clearly be unwanted. > This does not necessarily lead to a problem with > TCP-friendliness as there are rate-based congestion control > protocols that are TCP-friendly (e.g. RAP). you are right that, even if the decision is made to incorporate congestion control in the NTLP, choosing the right specific behaviour is still an important design choice. i see advantages to using protocols which allow more freedom in selecting congestion response (e.g. dccp); maybe you could even use TFRC (rfc3448) with sctp (or even tcp). i think I would see this as an NTLP design issue (or even implementation issue) rather than a framework issue. > > Second, I would comment on the possibility of limiting > signaling traffic by making it a fraction of the related > data stream. If I remember things correctly, this has > been done for RTCP/RTP... > If, for instance, each node in a network generates only > 3 % of signaling traffic, the whole signaling traffic > in the network will always scale linearly with traffic. > I'm not arguing for the use of a "magic number", but this > general signaling property could be mentioned so messages > can scale well, at least within one application. This > may be unnecessary if the NTLP is congestion controlled, > though ... aha, a non-magic number ... this property is an interesting part of the story, but so far as I can see it can't be relied on always being true. for example, any threshold could be exceeded during a re-routing event taking place in the network. therefore we need congestion control anyway, and so thresholding is then not necessary to consider formally. basically, what we would like to think of is some way to take advantage of the fact that 'signalling is *normally* only a small fraction N% of overall traffic and so should never *normally* cause a problem' without trying to define different protocol behaviours for 'normally' and 'non-normally'. one way to do this would be to point out to network engineers that they can configure N% of reserved capacity for high priority traffic and mark signalling as such; then, provided you guess right and the signalling traffic really is 'normal' it will never see any problems. again, this would be an implementation (or even deployment) issue. > > Third, I would mandate an interface to specify requirements > to the NTLP protocol. Maybe just delay, but maybe > something else too?! > > The idea is: if you specify a delay requirement and use > reliable transport, the sender transport protocol can use > aging on its buffer - get rid of a message that would be > transmitted for the 3rd time but has an exceeded delay > limit, thereby freeing space for a new message. this is not unreasonable. many reliable radio L2s have a 'transfer delay' attribute which can be controlled. again, it is to some extent an implementation issue. > > > I know that what I propose here doesn't sound like > it could be applied to existing transport protocol > standards. The question is whether this is the > right place for such a "wish list"... I think for the NTLP we will do what we can with what is already available (which is actually quite a lot - I'd be interested to know the official status of whether TFRC can be used in reality with TCP or SCTP, however). The correct place for a wish list is probably somewhere else... > > > Cheers, > Michael > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Mon Oct 6 14:34:22 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16227 for ; Mon, 6 Oct 2003 14:34:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6aBF-0003X2-GU for nsis-archive@odin.ietf.org; Mon, 06 Oct 2003 14:34:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h96IY1K5013571 for nsis-archive@odin.ietf.org; Mon, 6 Oct 2003 14:34:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6aBE-0003Wm-S8; Mon, 06 Oct 2003 14:34:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6aAd-0003V2-FK for nsis@optimus.ietf.org; Mon, 06 Oct 2003 14:33:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16203 for ; Mon, 6 Oct 2003 14:33:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A6aAa-000252-00 for nsis@ietf.org; Mon, 06 Oct 2003 14:33:20 -0400 Received: from viefep12-int.chello.at ([213.46.255.25]) by ietf-mx with esmtp (Exim 4.12) id 1A6aAZ-00024g-00 for nsis@ietf.org; Mon, 06 Oct 2003 14:33:19 -0400 Received: from work ([80.109.142.58]) by viefep15-int.chello.at (InterMail vM.5.01.05.17 201-253-122-126-117-20021021) with SMTP id <20031006160412.CDRI17534.viefep15-int.chello.at@work>; Mon, 6 Oct 2003 18:04:12 +0200 From: "Michael Welzl" To: "Hancock, Robert" , "'Michael Welzl'" , Subject: AW: [NSIS] Comments about draft-hancock-nsis-reliability-00 Date: Mon, 6 Oct 2003 18:07:12 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, > > I just read the "Reliability Functions in the NSIS Transport > > Layer Protocol" draft; I generally think it is a very good work. > > However, having noticed the very short "congestion control" > > section, I would like to comment on a few things: > > [aside: people joining the conversation late might need directing > towards the companion work > http://www.ietf.org/internet-drafts/draft-hancock-nsis-overload-00.txt > which we discussed earlier.] Okay ... I was a bit hesitant to comment at first - I've been subscribed to NSIS for a while but actually gave up following all the discussions at a certain point because it just became too much. Sorry for missing this. > > First, I would recommend using a rate-based instead of a > > window-based approach; especially over long-delay links, > > window based congestion control can lead to a > > stop-and-go behavior that would clearly be unwanted. > > This does not necessarily lead to a problem with > > TCP-friendliness as there are rate-based congestion control > > protocols that are TCP-friendly (e.g. RAP). > > you are right that, even if the decision is made to incorporate > congestion control in the NTLP, choosing the right specific > behaviour is still an important design choice. i see advantages > to using protocols which allow more freedom in selecting > congestion response (e.g. dccp); maybe you could even > use TFRC (rfc3448) with sctp (or even tcp). Hmm... I don't think so (TFRC+SCTP) - see below. That would be great, though. > i think I would see this as an NTLP design issue (or even > implementation issue) rather than a framework issue. Okay, I see. > > Second, I would comment on the possibility of limiting > > signaling traffic by making it a fraction of the related > > data stream. If I remember things correctly, this has > > been done for RTCP/RTP... > > If, for instance, each node in a network generates only > > 3 % of signaling traffic, the whole signaling traffic > > in the network will always scale linearly with traffic. > > I'm not arguing for the use of a "magic number", but this > > general signaling property could be mentioned so messages > > can scale well, at least within one application. This > > may be unnecessary if the NTLP is congestion controlled, > > though ... > > aha, a non-magic number ... > > this property is an interesting part of the story, but so > far as I can see it can't be relied on always being true. > for example, any threshold could be exceeded during a re-routing > event taking place in the network. therefore we need congestion > control anyway, and so thresholding is then not necessary to > consider formally. All right - I was approaching a similar conclusion anyway (need congestion control, therefore unnecessary). > > Third, I would mandate an interface to specify requirements > > to the NTLP protocol. Maybe just delay, but maybe > > something else too?! > > > > The idea is: if you specify a delay requirement and use > > reliable transport, the sender transport protocol can use > > aging on its buffer - get rid of a message that would be > > transmitted for the 3rd time but has an exceeded delay > > limit, thereby freeing space for a new message. > > this is not unreasonable. many reliable radio L2s have a 'transfer > delay' attribute which can be controlled. again, it is > to some extent an implementation issue. Hmmm ... is it? Not so sure about this one. It needs to be specified SOMEWHERE. > > I know that what I propose here doesn't sound like > > it could be applied to existing transport protocol > > standards. The question is whether this is the > > right place for such a "wish list"... > > I think for the NTLP we will do what we can with what > is already available (which is actually quite a lot - I'd > be interested to know the official status of whether TFRC > can be used in reality with TCP or SCTP, however). > > The correct place for a wish list is probably somewhere else... Well - my intention was to "open things up" a bit; I disagree that we can already do QUITE a lot. I doubt that something like the delay-specification interface will ever see the light of day unless somebody specifies and recommends it. NSIS is where this functionality would be required, so I think this is where a recommendation should go. DCCP is great because it provides a framework for congestion control mechanisms, but it is for unreliable transport only. I (sadly) don't know of such a framework for reliable transport, and I don't think that TFRC could easily be integrated in either TCP oder SCTP. Mechanisms arise from the desire to use something that is not yet available. I can't think of many applications that would need reliable transport with congestion control that would differ from TCP/SCTP - but NSIS appears to be a candidate. Cheers, Michael _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Oct 7 00:00:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA04565 for ; Tue, 7 Oct 2003 00:00:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6j14-0000Yc-GD for nsis-archive@odin.ietf.org; Tue, 07 Oct 2003 00:00:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h97406jf002128 for nsis-archive@odin.ietf.org; Tue, 7 Oct 2003 00:00:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6j10-0000Xy-TL; Tue, 07 Oct 2003 00:00:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6j04-0000X8-L7 for nsis@optimus.ietf.org; Mon, 06 Oct 2003 23:59:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04504 for ; Mon, 6 Oct 2003 23:58:54 -0400 (EDT) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A6j02-0000CV-00 for nsis@ietf.org; Mon, 06 Oct 2003 23:59:02 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1A6j01-0000CS-00 for nsis@ietf.org; Mon, 06 Oct 2003 23:59:01 -0400 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.6) with ESMTP id h973x2606790 for ; Tue, 7 Oct 2003 06:59:02 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Tue, 7 Oct 2003 06:59:01 +0300 Received: from esebe020.NOE.Nokia.com ([172.21.138.59]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 7 Oct 2003 06:59:01 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe020.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 7 Oct 2003 06:59:01 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 7 Oct 2003 06:59:01 +0300 Message-ID: Thread-Topic: [NSIS] I-D ACTION:draft-ietf-nsis-fw-04.txt Thread-Index: AcOGwWTc+6Q935r6TzW0ZGSHHOlOqgFxazVw To: X-OriginalArrivalTime: 07 Oct 2003 03:59:01.0503 (UTC) FILETIME=[579F30F0:01C38C87] Content-Transfer-Encoding: quoted-printable Subject: [NSIS] WG Last Called on draft-ietf-nsis-fw-04.txt Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi all, I discussed with the editor of the draft, and it was felt that work has been more-or-less complete on this document. I would like to start a working last call on this draft, starting Wednesday October 8th, running through October 22nd. I believe Robert has set-up a tracking tool for issues raised; I will let him handle the details for submitting issues, etc. Thanks, John=09 -----Original Message----- From: ext Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: 29 September, 2003 22:38 Cc: nsis@ietf.org Subject: [NSIS] I-D ACTION:draft-ietf-nsis-fw-04.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 : Next Steps in Signaling: Framework Author(s) : R. Hancock et al. Filename : draft-ietf-nsis-fw-04.txt Pages : 47 Date : 2003-9-29 =09 The Next Steps in Signaling working group is considering protocols=20 for signaling information about a data flow along its path in the=20 network. Based on existing work on signaling requirements, this=20 document proposes an architectural framework for such signaling=20 protocols.=20 This document provides a model for the network entities that take=20 part in such signaling, and the relationship between signaling and=20 the rest of network operation. We decompose the overall signaling=20 protocol suite into a generic (lower) layer, with a separate upper=20 layers for each specific signaling application. An initial proposal=20 for the split between these layers is given, describing the overall=20 functionality of the lower layer, and discussing the ways that upper=20 layer behavior can be adapted to specific signaling application=20 requirements.=20 This framework also considers the general interactions between=20 signaling and other network layer functions, specifically routing and=20 mobility. The different routing and mobility events that impact=20 signaling operation are described, along with how their handling=20 should be divided between the generic and application-specific=20 layers. Finally, an example signaling application (for Quality of=20 Service) is described in more detail. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nsis-fw-04.txt To remove yourself from the IETF Announcement list, send a message to=20 ietf-announce-request with the word unsubscribe in the body of the = message. Internet-Drafts are also available by anonymous FTP. Login with the = username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-nsis-fw-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html=20 or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-nsis-fw-04.txt". =09 NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. =09 =09 Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Oct 7 04:07:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22658 for ; Tue, 7 Oct 2003 04:07:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6ms9-0004B7-PM for nsis-archive@odin.ietf.org; Tue, 07 Oct 2003 04:07:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9787901016049 for nsis-archive@odin.ietf.org; Tue, 7 Oct 2003 04:07:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6ms3-0004AE-Ay; Tue, 07 Oct 2003 04:07:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6mrz-00049p-Bc for nsis@optimus.ietf.org; Tue, 07 Oct 2003 04:06:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22653 for ; Tue, 7 Oct 2003 04:06:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A6mrw-0002Sp-00 for nsis@ietf.org; Tue, 07 Oct 2003 04:06:56 -0400 Received: from utrhcs.cs.utwente.nl ([130.89.10.247]) by ietf-mx with esmtp (Exim 4.12) id 1A6mrv-0002Sm-00 for nsis@ietf.org; Tue, 07 Oct 2003 04:06:55 -0400 Received: from utip105 (utip105.cs.utwente.nl [130.89.13.76]) by utrhcs.cs.utwente.nl (8.12.10/8.12.9) with SMTP id h9786qaK010814; Tue, 7 Oct 2003 10:06:52 +0200 (MET DST) Message-ID: <003501c38ca9$f99418e0$4c0d5982@dynamic.cs.utwente.nl> From: "Georgios Karagiannis" To: "Hannes Tschofenig" , "'Hancock, Robert'" , References: <001101c389cb$bce35f90$010aa8c0@joe> Subject: Re: [NSIS] Reliability and Security Date: Tue, 7 Oct 2003 10:06:53 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4922.1500 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4925.2800 Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Hannes and Robert Please see some comments in line > > > > i think there is a fairly well defined question about how to > > enforce 'complete' bypass for e2e addressed packets while > > still using fast-path > > processing. my assumption at the moment is that if this is wanted, > > then something based on Router Alert is the right way to go - > > provided the values in the option field are sensible > > assigned, RA is very simple to process and there doesn't seem > > to be a good alternative (as you > > know, I don't like using the TTL as a scoping mechanism). i > > don't believe there are specific security issues here. > > i agree that the router alert option is a good choice. with regard to the > discovery there is still some degree of freedom here. Georgios>> Router alert option is a good choice but for the moment I think that it should be seen as one of the possible options. Probably, there are also other options that could be used. Therefore, for the time being I would appreciate to let it open. > > > > > > > > for security (and in particular for security association > > > establishment) the > > > following issues are of importance: > > > > > > - node A has to learn that a security association has to be > > > established to > > > some node C. > > > node A and C support NSLP X; node B only NSLP Y > > > how and when is this information obtained? > > > > my view here is that - provided the packet is marked > > in such a way that NSLP B can tell by packet inspection > > that it has no interest - then this situation between > > A and C should be handled as though node B was not there > > at all, i.e. it should take no part at all in the signalling > > exchange. how A and C negotiate their relationship is of > > course open, but adding B doesn't make it a different question. > > this mechanism can be provided by a separate discovery mechanism. i don't > know what the status of the current ntlp discussions with regard to the > path-coupled discovery is. Georgios>> I think that in many situations this can be done by network configuration. For example, a domain administrator can configure a node as an interior node that should operate as your node B. > > > > > > > > > > - at which layer are messages protected? (ntlp/nslp) > > > > i believe that the NTLP should offer a channel security > > mechanism supporting confidentiality, integrity etc. > > and allowing the re-use of standard mutual authentication > > between A and C. whether the NSLP chooses to depend on this > > or do something extra/instead is up to the NSLP designers. > > this answeres a question to you in a previous mail. Georgios>> We have to discuss more on this issue. > > > i think anything more complex than that will be over-complex; > > in particular, if you want different levels of protection for > > different parts of the message then nodes A, B and C will all > > have to implement the NSLP and the NSLP will have to define > > the different protection levels beyond what can be done by the NTLP. > > > > > > > > we have seen a number of protocol proposals in the past. > > > there it can easily > > > be seen that differences exist which have an impact on > > security. it is > > > important to make the default mode of operation very clear > > > and precise. > > > > quite true. Georgios>> I also agree! Best regards, Georgios _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Oct 7 05:29:23 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24349 for ; Tue, 7 Oct 2003 05:29:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6o9O-0007VR-Eb for nsis-archive@odin.ietf.org; Tue, 07 Oct 2003 05:29:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h979T2vj028854 for nsis-archive@odin.ietf.org; Tue, 7 Oct 2003 05:29:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6o9N-0007Uv-38; Tue, 07 Oct 2003 05:29:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6o8j-0007Tu-TR for nsis@optimus.ietf.org; Tue, 07 Oct 2003 05:28:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24341 for ; Tue, 7 Oct 2003 05:28:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A6o8g-00037Z-00 for nsis@ietf.org; Tue, 07 Oct 2003 05:28:18 -0400 Received: from rsys002a.roke.co.uk ([193.118.192.251]) by ietf-mx with esmtp (Exim 4.12) id 1A6o8f-00036p-00 for nsis@ietf.org; Tue, 07 Oct 2003 05:28:18 -0400 Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Tue, 7 Oct 2003 10:27:45 +0100 Message-ID: From: "Hancock, Robert" To: "'john.loughney@nokia.com'" , nsis@ietf.org Cc: "Lang, Christopher" Subject: RE: [NSIS] WG Last Called on draft-ietf-nsis-fw-04.txt Date: Tue, 7 Oct 2003 10:27:43 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , hi john, all, we would like to use an issue tracking tool for this process, and you can find it at http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-issues/index use of the tool should be pretty self explanatory: - make sure you browse and add issues for the right document (v4, not v3!) - you can browse issues anonymously, but to take part you have to create yourself a username (the 'Register' link at the left) - you will find that once an issue has been created, some changes in status can only be made by the editor (that's me, btw) i will poll the tool fairly frequently to see what is going on. ideally i'd like to keep the discussion of particular issues within the tool (since that's easier for me to decode than N interleaved email threads with misleading subject lines). the tool is a locally customised version of Roundup, which has been/is being used in several other IETF groups. if you have comments or queries about the way the tool is being used, or other problems, you can send them to me and chris lang (who set it up), (off the list, I guess). there is more information on roundup at http://roundup.sourceforge.net. cheers, robert h. > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > Sent: Tuesday, October 07, 2003 04:59 > To: nsis@ietf.org > Subject: [NSIS] WG Last Called on draft-ietf-nsis-fw-04.txt > > > Hi all, > > I discussed with the editor of the draft, and it was felt that work > has been more-or-less complete on this document. I would like to > start a working last call on this draft, starting Wednesday October > 8th, running through October 22nd. I believe Robert has set-up a > tracking tool for issues raised; I will let him handle the details > for submitting issues, etc. > > Thanks, > John > > -----Original Message----- > From: ext Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > Sent: 29 September, 2003 22:38 > Cc: nsis@ietf.org > Subject: [NSIS] I-D ACTION:draft-ietf-nsis-fw-04.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 : Next Steps in Signaling: Framework > Author(s) : R. Hancock et al. > Filename : draft-ietf-nsis-fw-04.txt > Pages : 47 > Date : 2003-9-29 > > The Next Steps in Signaling working group is considering protocols > for signaling information about a data flow along its path in the > network. Based on existing work on signaling requirements, this > document proposes an architectural framework for such signaling > protocols. > This document provides a model for the network entities that take > part in such signaling, and the relationship between signaling and > the rest of network operation. We decompose the overall signaling > protocol suite into a generic (lower) layer, with a separate upper > layers for each specific signaling application. An initial proposal > for the split between these layers is given, describing the overall > functionality of the lower layer, and discussing the ways that upper > layer behavior can be adapted to specific signaling application > requirements. > This framework also considers the general interactions between > signaling and other network layer functions, specifically routing and > mobility. The different routing and mobility events that impact > signaling operation are described, along with how their handling > should be divided between the generic and application-specific > layers. Finally, an example signaling application (for Quality of > Service) is described in more detail. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-nsis-fw-04.txt > > To remove yourself from the IETF Announcement list, send a message to > ietf-announce-request with the word unsubscribe in the body > of the message. > > Internet-Drafts are also available by anonymous FTP. Login > with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-nsis-fw-04.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-nsis-fw-04.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant > mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Oct 7 23:02:24 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA02557 for ; Tue, 7 Oct 2003 23:02:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A74aS-0006qg-IF for nsis-archive@odin.ietf.org; Tue, 07 Oct 2003 23:02:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h98324xX026309 for nsis-archive@odin.ietf.org; Tue, 7 Oct 2003 23:02:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A74aP-0006qE-2S; Tue, 07 Oct 2003 23:02:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A74Zh-0006kI-Ty for nsis@optimus.ietf.org; Tue, 07 Oct 2003 23:01:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA02538 for ; Tue, 7 Oct 2003 23:01:06 -0400 (EDT) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A74Ze-000716-00 for nsis@ietf.org; Tue, 07 Oct 2003 23:01:14 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1A74Zd-00070y-00 for nsis@ietf.org; Tue, 07 Oct 2003 23:01:13 -0400 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.6) with ESMTP id h9831D620999 for ; Wed, 8 Oct 2003 06:01:13 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 8 Oct 2003 06:01:12 +0300 Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 8 Oct 2003 06:01:12 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe018.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 8 Oct 2003 06:01:11 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 8 Oct 2003 06:01:10 +0300 Message-ID: Thread-Topic: Reminder: Internet-Draft cutoff dates for Minneapolis IETF Thread-Index: AcONFmPeH3NItOu6RBaHBECNYen27gAMgBBw X-Priority: 1 Priority: Urgent Importance: high To: X-OriginalArrivalTime: 08 Oct 2003 03:01:11.0753 (UTC) FILETIME=[6DE71B90:01C38D48] Content-Transfer-Encoding: quoted-printable Subject: [NSIS] Reminder: Internet-Draft cutoff dates for Minneapolis IETF Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Please note I-D cutoff dates: October 13, Monday Date by which Secretariat wants warning about = impending WG -00 documents from WG chairs. That means you should warn the chairs about impending WG -00 docs before the 13th. October 20, Monday Internet Draft Cut-off for initial document (-00) submission at 09:00 ET October 27, Monday Internet Draft final submission cut-off at 09:00 ET _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Wed Oct 8 12:58:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27496 for ; Wed, 8 Oct 2003 12:58:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7Hda-0002ej-JN for nsis-archive@odin.ietf.org; Wed, 08 Oct 2003 12:58:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h98GwAt2010208 for nsis-archive@odin.ietf.org; Wed, 8 Oct 2003 12:58:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7HdR-0002Yf-CM; Wed, 08 Oct 2003 12:58:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7Hcg-0002W7-EM for nsis@optimus.ietf.org; Wed, 08 Oct 2003 12:57:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27388 for ; Wed, 8 Oct 2003 12:57:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7Hce-00019Q-00 for nsis@ietf.org; Wed, 08 Oct 2003 12:57:12 -0400 Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx with esmtp (Exim 4.12) id 1A7Hce-00018i-00 for nsis@ietf.org; Wed, 08 Oct 2003 12:57:12 -0400 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Wed, 8 Oct 2003 17:56:36 +0100 Message-ID: From: "McDonald, Andrew" To: "'Geib, Ruediger'" , cornelia.kappler@siemens.com Cc: nsis@ietf.org Subject: RE: [NSIS] qos-nslp-00 Date: Wed, 8 Oct 2003 17:56:42 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi R=FCdiger, Geib, Ruediger wrote: > it is not clear to me how the local node reacts once it learns > that it maintains stale state. If the only answer is "not at all" > I can't see a benefit of the RSN method against session ID based > refreshes. On the opposite, the state you have to maintain > locally will increase (besides session ID you will have to store > incoming and outgoing RSN). I think we may have got some confusion here on what a 'session ID' identifies and what an 'RSN' identifies. The RSN is interpreted in the context of a session identifier. i.e. 'Session-ID + RSN' can be used to identify some state in a node. 'RSN' on its own could belong to any one = of many sessions. Similarly, the QoS reservation may change within a given session, so I don't believe that session ID could be used on its own = since it doesn't identify which version of the reservation state it is = referring to. Regarding what to do with a message containing an RSN that isn't for = the currently installed state, an example: (Remembering that RSN is a *sequence* number that increments when the reservation changes). a) -------------------------------> Full Reserve SID #55, RSN #1 b) <------------------------------- ACK SID #55, RSN #1 c) -------------------------------> Full Reserve SID #55, RSN #2 d) <------------------------------- ACK SID #55, RSN #2 e) -------------------------------> Srefresh SID #55, RSN #1 f) -------------------------------> Srefresh SID #55, RSN #2 g) -------------------------------> Srefresh SID #55, RSN #3 h) -------------------------------> Srefresh SID #31, RSN #2 Message (a) installs some state. Message (b) acknowledges that state = was successful installed (and can be referred to by subsequent summary refreshes). Message (c) installs some new state (e.g. asking for = different resources) which replaces that which was installed by message (a). = Message (d) acknowledges that state was successful installed. Message (e) refers to 'old' state (message RSN < current state RSN). Possibly the messages got reordered between the nodes. We might just be = able to discard this refresh message silently. Message (f) refers to our currently installed state, so we refresh it = as requested. Message (g) refers to some future state that we haven't got (message = RSN > current state RSN). We need to signal an error back (since our = neighbour thinks we've got state we haven't, and will probably carry on trying to = just refresh it unless told otherwise). I guess one possibility is that = there has been some oscillation in the route (i.e. the Full Reserve for SID #55, = RSN #3 went to a different node but that wasn't the route for long enough = for us to time out our soft state). Message (h) refers to some state for a SID we don't know about. = Possibly the route has changed. Again, we need to signal an error back to get a full refresh of our state. Does that help to give a clearer picture? Regards, Andrew _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu Oct 9 05:03:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12609 for ; Thu, 9 Oct 2003 05:03:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7WhL-0006tq-5b for nsis-archive@odin.ietf.org; Thu, 09 Oct 2003 05:03:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h99933Z6026522 for nsis-archive@odin.ietf.org; Thu, 9 Oct 2003 05:03:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7WhJ-0006t1-9b; Thu, 09 Oct 2003 05:03:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7Wga-0006rm-W8 for nsis@optimus.ietf.org; Thu, 09 Oct 2003 05:02:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12554 for ; Thu, 9 Oct 2003 05:02:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7WgX-0003pU-00 for nsis@ietf.org; Thu, 09 Oct 2003 05:02:13 -0400 Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx with esmtp (Exim 4.12) id 1A7WgT-0003oe-00 for nsis@ietf.org; Thu, 09 Oct 2003 05:02:10 -0400 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Thu, 9 Oct 2003 10:01:32 +0100 Message-ID: From: "Hancock, Robert" To: "'Michael Welzl'" , nsis@ietf.org Subject: RE: [NSIS] Comments about draft-hancock-nsis-reliability-00 Date: Thu, 9 Oct 2003 10:01:38 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , hi michael, [nb with a question to the Chair at the end.] i concentrate on your last point since it seems to be the open one. the basic question is a combination of a) whether it is necessary to impose transfer delay bounds on reliable delivery (i.e. 'deliver in X seconds or tell me you have failed') b) whether it is necessary to use a reliable transfer mechanism with a 'smooth' congestion response like TFRC c) whether NSIS is unique in these requirements d) whether they can already be satisfied with existing protocols. In order: a) seems to be a 'nice to have if easy' facility; you would need partial reliability in the transport protocol (e.g. pr-sctp). however, a lot of the potential problems in this area are solved if you have multiplexing which allows relative misordering between streams (like base sctp does). in any case, whether we need to standardise the service interface between NTLP and NSLP to configure such delay bounds or multiplexing is much less clear to me. I would see it as being at most accompanying work rather than part of the base specifications. b) seems to be desirable. c) i think the answer is 'not really'. at least the timeliness requirement for signalling messages (which relates to both transfer delay and congestion issues) would seem to be common to many other signalling applications traditionally implemented in SS7 networks. rfc2719 (to me) points in this direction, for example. of course, there's no harm in adding our voice to the requirement (if it is currently unsatisfied). d) is the main point. on the transfer delay front you need pr-sctp or home-made partial reliability above dccp (if multiplexing alone isn't good enough). on the congestion response front, i guess the difficulty I have is understanding what it actually means for 3448 to be a standards track protocol document. if it means that you still need additional standards actions to be allowed to use it in a concrete protocol, then that work would seem to me to be worth doing, but (xref [c] above) i don't think of that work as being NSIS-specific. maybe john would like to comment on that last point. robert h. > -----Original Message----- > From: Michael Welzl [mailto:michael.welzl@uibk.ac.at] > Sent: Monday, October 06, 2003 17:07 > To: Hancock, Robert; 'Michael Welzl'; nsis@ietf.org > Subject: AW: [NSIS] Comments about draft-hancock-nsis-reliability-00 > > > Hi, > > > > > I just read the "Reliability Functions in the NSIS Transport > > > Layer Protocol" draft; I generally think it is a very good work. > > > However, having noticed the very short "congestion control" > > > section, I would like to comment on a few things: > > > > [aside: people joining the conversation late might need directing > > towards the companion work > > > http://www.ietf.org/internet-drafts/draft-hancock-nsis-overload-00.txt > > which we discussed earlier.] > > Okay ... I was a bit hesitant to comment at first - I've been > subscribed to NSIS for a while but actually gave up following > all the discussions at a certain point because it just became > too much. Sorry for missing this. > > > > > First, I would recommend using a rate-based instead of a > > > window-based approach; especially over long-delay links, > > > window based congestion control can lead to a > > > stop-and-go behavior that would clearly be unwanted. > > > This does not necessarily lead to a problem with > > > TCP-friendliness as there are rate-based congestion control > > > protocols that are TCP-friendly (e.g. RAP). > > > > you are right that, even if the decision is made to incorporate > > congestion control in the NTLP, choosing the right specific > > behaviour is still an important design choice. i see advantages > > to using protocols which allow more freedom in selecting > > congestion response (e.g. dccp); maybe you could even > > use TFRC (rfc3448) with sctp (or even tcp). > > Hmm... I don't think so (TFRC+SCTP) - see below. > That would be great, though. > > > > i think I would see this as an NTLP design issue (or even > > implementation issue) rather than a framework issue. > > Okay, I see. > > > > > Second, I would comment on the possibility of limiting > > > signaling traffic by making it a fraction of the related > > > data stream. If I remember things correctly, this has > > > been done for RTCP/RTP... > > > If, for instance, each node in a network generates only > > > 3 % of signaling traffic, the whole signaling traffic > > > in the network will always scale linearly with traffic. > > > I'm not arguing for the use of a "magic number", but this > > > general signaling property could be mentioned so messages > > > can scale well, at least within one application. This > > > may be unnecessary if the NTLP is congestion controlled, > > > though ... > > > > aha, a non-magic number ... > > > > this property is an interesting part of the story, but so > > far as I can see it can't be relied on always being true. > > for example, any threshold could be exceeded during a re-routing > > event taking place in the network. therefore we need congestion > > control anyway, and so thresholding is then not necessary to > > consider formally. > > All right - I was approaching a similar conclusion > anyway (need congestion control, therefore unnecessary). > > > > > Third, I would mandate an interface to specify requirements > > > to the NTLP protocol. Maybe just delay, but maybe > > > something else too?! > > > > > > The idea is: if you specify a delay requirement and use > > > reliable transport, the sender transport protocol can use > > > aging on its buffer - get rid of a message that would be > > > transmitted for the 3rd time but has an exceeded delay > > > limit, thereby freeing space for a new message. > > > > this is not unreasonable. many reliable radio L2s have a 'transfer > > delay' attribute which can be controlled. again, it is > > to some extent an implementation issue. > > Hmmm ... is it? Not so sure about this one. It needs > to be specified SOMEWHERE. > > > > > I know that what I propose here doesn't sound like > > > it could be applied to existing transport protocol > > > standards. The question is whether this is the > > > right place for such a "wish list"... > > > > I think for the NTLP we will do what we can with what > > is already available (which is actually quite a lot - I'd > > be interested to know the official status of whether TFRC > > can be used in reality with TCP or SCTP, however). > > > > The correct place for a wish list is probably somewhere else... > > Well - my intention was to "open things up" a bit; > I disagree that we can already do QUITE a lot. I doubt that > something like the delay-specification interface will ever > see the light of day unless somebody specifies and recommends > it. NSIS is where this functionality would be required, so I > think this is where a recommendation should go. > > DCCP is great because it provides a framework for congestion > control mechanisms, but it is for unreliable transport only. > I (sadly) don't know of such a framework for reliable transport, > and I don't think that TFRC could easily be integrated in > either TCP oder SCTP. > > Mechanisms arise from the desire to use something that > is not yet available. I can't think of many applications > that would need reliable transport with congestion control > that would differ from TCP/SCTP - but NSIS appears to be a > candidate. > > Cheers, > Michael > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu Oct 9 05:33:23 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13469 for ; Thu, 9 Oct 2003 05:33:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7XAM-0008WV-CB for nsis-archive@odin.ietf.org; Thu, 09 Oct 2003 05:33:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h999X2Zf032757 for nsis-archive@odin.ietf.org; Thu, 9 Oct 2003 05:33:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7XAL-0008Vs-H1; Thu, 09 Oct 2003 05:33:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7X9p-0008VK-U4 for nsis@optimus.ietf.org; Thu, 09 Oct 2003 05:32:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13458 for ; Thu, 9 Oct 2003 05:32:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7X9m-0004HR-00 for nsis@ietf.org; Thu, 09 Oct 2003 05:32:26 -0400 Received: from lmr1.uibk.ac.at ([138.232.1.142] helo=smtp.uibk.ac.at) by ietf-mx with esmtp (Exim 4.12) id 1A7X9l-0004H1-00 for nsis@ietf.org; Thu, 09 Oct 2003 05:32:25 -0400 Received: from lap10-c703.uibk.ac.at (lap10-c703.uibk.ac.at [138.232.65.57]) by smtp.uibk.ac.at (8.12.10/8.12.9/F1) with ESMTP id h999VrIf016790; Thu, 9 Oct 2003 11:31:55 +0200 Subject: RE: [NSIS] Comments about draft-hancock-nsis-reliability-00 From: Michael Welzl To: "Hancock, Robert" Cc: nsis@ietf.org In-Reply-To: References: Content-Type: text/plain Organization: University of Innsbruck Message-Id: <1065691847.4788.135.camel@lap10-c703.uibk.ac.at> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) Date: 09 Oct 2003 11:30:47 +0200 Content-Transfer-Encoding: 7bit X-Spam-Score: -7.4 () IN_REP_TO,QUOTED_EMAIL_TEXT,RCV_UIBK,REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_XIMIAN X-Scanned-By: MIMEDefang 2.35 at uibk.ac.at Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit hi, > the basic question is a combination of > a) whether it is necessary to impose transfer delay bounds on reliable > delivery (i.e. 'deliver in X seconds or tell me you have failed') > b) whether it is necessary to use a reliable transfer mechanism with > a 'smooth' congestion response like TFRC > c) whether NSIS is unique in these requirements > d) whether they can already be satisfied with existing protocols. I agree - that's a very clear and good way to put it. > In order: > a) seems to be a 'nice to have if easy' facility; you would need > partial reliability in the transport protocol (e.g. pr-sctp). however, > a lot of the potential problems in this area are solved if you have > multiplexing which allows relative misordering between streams (like > base sctp does). in any case, whether we need to standardise the > service interface between NTLP and NSLP to configure such delay bounds > or multiplexing is much less clear to me. I would see it as being at > most accompanying work rather than part of the base specifications. I agree in every aspect (in particular, this includes the last two sentences). I am in the "let's write a recommendation" camp, though. > b) seems to be desirable. I agree - but note that to me, the key issue is its rate based nature rather than it's (still desirable) smoothness. > c) i think the answer is 'not really'. at least the timeliness requirement > for signalling messages (which relates to both transfer delay and > congestion issues) would seem to be common to many other signalling > applications traditionally implemented in SS7 networks. rfc2719 (to me) > points in this direction, for example. of course, there's no harm in > adding our voice to the requirement (if it is currently unsatisfied). I agree (no harm in adding our voice). As a side note, it recently occured to me that the requirements should be similar for Grid transport. > d) is the main point. on the transfer delay front you need pr-sctp > or home-made partial reliability above dccp (if multiplexing alone > isn't good enough). on the congestion response front, i guess the > difficulty I have is understanding what it actually means for 3448 to be a > standards track protocol document. if it means that you still need Easy answer: a quote from 3448. Instead of specifying a complete protocol, this document simply specifies a congestion control mechanism that could be used in a transport protocol such as RTP [7], in an application incorporating end-to-end congestion control at the application level, or in the context of endpoint congestion management [1]. This document does not discuss packet formats or reliability. I am sure that it would be really difficult to integrate TFRC in TCP oder SCTP - mainly because TFRC is rate-based. > additional standards actions to be allowed to use it in a concrete > protocol, then that work would seem to me to be worth doing, but > (xref [c] above) i don't think of that work as being NSIS-specific. I think it would be worth doing for the sake of signaling and Grid transport - an equivalent of DCCP for reliable transport, if you will, with different (more appropriate) CC mechanisms to choose from ... but this should be research at this point, not standardization. However, as something like this seems to be desirable for NSIS, I am in favor of writing a recommendation. Otherwise, nobody may ever want to take up this kind of work... Cheers, Michael _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Fri Oct 10 18:40:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27718 for ; Fri, 10 Oct 2003 18:40:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A85vd-0001vU-Uu for nsis-archive@odin.ietf.org; Fri, 10 Oct 2003 18:40:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9AMe9Dw007387 for nsis-archive@odin.ietf.org; Fri, 10 Oct 2003 18:40:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A85vX-0001uM-9q; Fri, 10 Oct 2003 18:40:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7wI2-0006yG-JJ for nsis@optimus.ietf.org; Fri, 10 Oct 2003 08:22:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23930 for ; Fri, 10 Oct 2003 08:22:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7wI1-0002E4-00 for nsis@ietf.org; Fri, 10 Oct 2003 08:22:37 -0400 Received: from mail.di.fc.ul.pt ([194.117.21.40]) by ietf-mx with esmtp (Exim 4.12) id 1A7wI0-0002E1-00 for nsis@ietf.org; Fri, 10 Oct 2003 08:22:36 -0400 Received: from di.fc.ul.pt (globdata01.di.fc.ul.pt [194.117.20.216]) by mail.di.fc.ul.pt (8.11.6/8.11.6) with ESMTP id h9ACMI530594 for ; Fri, 10 Oct 2003 13:22:18 +0100 Message-ID: <3F86A470.9020709@di.fc.ul.pt> Date: Fri, 10 Oct 2003 13:22:08 +0100 From: Nuno Carvalho User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3.1) Gecko/20030428 X-Accept-Language: en-us, en MIME-Version: 1.0 To: nsis@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-mail: Found to be clean X-SpamCheck-mail: not spam (whitelisted), SpamAssassin (score=-0.8, required 8, SPAM_PHRASE_01_02, USER_AGENT, USER_AGENT_MOZILLA_UA, X_ACCEPT_LANG) Content-Transfer-Encoding: 7bit Subject: [NSIS] RSVP implementation Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, I'm starting to work with QoS reservations and I'm looking for a RSVP implementation. Does anybody know about an implementation of RSVP or other protocol that is being used know? Thank you. Best regards, Nuno Carvalho _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Mon Oct 13 02:07:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA19387 for ; Mon, 13 Oct 2003 02:07:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A8vrK-0006bR-Me for nsis-archive@odin.ietf.org; Mon, 13 Oct 2003 02:07:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9D679vG025336 for nsis-archive@odin.ietf.org; Mon, 13 Oct 2003 02:07:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A8vrB-0006ZZ-ND; Mon, 13 Oct 2003 02:07:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A8vr1-0006Ye-MJ for nsis@optimus.ietf.org; Mon, 13 Oct 2003 02:06:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18483 for ; Mon, 13 Oct 2003 02:06:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A8vqx-00079u-00 for nsis@ietf.org; Mon, 13 Oct 2003 02:06:47 -0400 Received: from courier.cs.helsinki.fi ([128.214.9.1] helo=mail.cs.helsinki.fi) by ietf-mx with esmtp (Exim 4.12) id 1A8vqx-00079r-00 for nsis@ietf.org; Mon, 13 Oct 2003 02:06:47 -0400 Received: from mannersaari.cs.Helsinki.FI (mannersaari.cs.helsinki.fi [::ffff:128.214.11.173]) (IDENT: jmanner, TLS: TLSv1/SSLv3,168bits,DES-CBC3-SHA) by mail.cs.helsinki.fi with esmtp; Mon, 13 Oct 2003 09:06:47 +0300 Date: Mon, 13 Oct 2003 09:06:47 +0300 (EEST) From: Jukka MJ Manner To: Nuno Carvalho cc: nsis@ietf.org Subject: Re: [NSIS] RSVP implementation In-Reply-To: <3F86A470.9020709@di.fc.ul.pt> Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Nuno, you may want to check out the KOM RSVP daemon. It is quite a huge package. More information can be found at: http://www.kom.e-technik.tu-darmstadt.de/rsvp/ Regards, Jukka Research Scientist, Ph.Lic Department of Computer Science University of Helsinki, Finland http://www.cs.Helsinki.Fi/u/jmanner/ On Fri, 10 Oct 2003, Nuno Carvalho wrote: > Hi, > > I'm starting to work with QoS reservations and I'm looking for a RSVP > implementation. > Does anybody know about an implementation of RSVP or other protocol that > is being used know? > > Thank you. > Best regards, > Nuno Carvalho > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Mon Oct 13 04:31:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26550 for ; Mon, 13 Oct 2003 04:31:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A8y6b-00055u-94 for nsis-archive@odin.ietf.org; Mon, 13 Oct 2003 04:31:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9D8V4fR019565 for nsis-archive@odin.ietf.org; Mon, 13 Oct 2003 04:31:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A8y6Y-00054G-ID; Mon, 13 Oct 2003 04:31:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A8y5c-00051x-Af for nsis@optimus.ietf.org; Mon, 13 Oct 2003 04:30:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26508 for ; Mon, 13 Oct 2003 04:29:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A8y5Z-0000J3-00 for nsis@ietf.org; Mon, 13 Oct 2003 04:30:01 -0400 Received: from rsys002a.roke.co.uk ([193.118.192.251]) by ietf-mx with esmtp (Exim 4.12) id 1A8y5Y-0000Iq-00 for nsis@ietf.org; Mon, 13 Oct 2003 04:30:00 -0400 Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id <4Z79W22C>; Mon, 13 Oct 2003 09:29:24 +0100 Message-ID: From: "Hancock, Robert" To: nsis@ietf.org Subject: minor clarification on: RE: [NSIS] WG Last Called on draft-ietf-n sis-fw-04.txt Date: Mon, 13 Oct 2003 09:29:30 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , dear all, some people have asked whether they can still make last call comments on the mailing list on this draft. the answer is: yes (in which case I will enter them myself). the tracking tool is intended to be a convenience for the editor and anyone else trying to disentangle N parallel conversations, it's not intended to restrict the discussion in any way. sorry for any confusion. robert h. > -----Original Message----- > From: Hancock, Robert > Sent: Tuesday, October 07, 2003 10:28 > To: 'john.loughney@nokia.com'; nsis@ietf.org > Cc: Lang, Christopher > Subject: RE: [NSIS] WG Last Called on draft-ietf-nsis-fw-04.txt > > > hi john, all, > > we would like to use an issue tracking tool for this process, and > you can find it at > http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-issues/index > > use of the tool should be pretty self explanatory: > - make sure you browse and add issues for the right document (v4, > not v3!) > - you can browse issues anonymously, but to take part you have to > create yourself a username (the 'Register' link at the left) > - you will find that once an issue has been created, some changes > in status can only be made by the editor (that's me, btw) > > i will poll the tool fairly frequently to see what is going on. > ideally i'd like to keep the discussion of particular issues > within the tool (since that's easier for me to decode than N > interleaved email threads with misleading subject lines). > > the tool is a locally customised version of Roundup, which has > been/is being used in several other IETF groups. if you have > comments or queries about the way the tool is being used, or other > problems, you can send them to me and chris lang (who set it up), > (off the list, I guess). there is more information on roundup at > http://roundup.sourceforge.net. > > cheers, > > robert h. > > > -----Original Message----- > > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > > Sent: Tuesday, October 07, 2003 04:59 > > To: nsis@ietf.org > > Subject: [NSIS] WG Last Called on draft-ietf-nsis-fw-04.txt > > > > > > Hi all, > > > > I discussed with the editor of the draft, and it was felt that work > > has been more-or-less complete on this document. I would like to > > start a working last call on this draft, starting Wednesday October > > 8th, running through October 22nd. I believe Robert has set-up a > > tracking tool for issues raised; I will let him handle the details > > for submitting issues, etc. > > > > Thanks, > > John > > > > -----Original Message----- > > From: ext Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > > Sent: 29 September, 2003 22:38 > > Cc: nsis@ietf.org > > Subject: [NSIS] I-D ACTION:draft-ietf-nsis-fw-04.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 : Next Steps in Signaling: Framework > > Author(s) : R. Hancock et al. > > Filename : draft-ietf-nsis-fw-04.txt > > Pages : 47 > > Date : 2003-9-29 > > > > The Next Steps in Signaling working group is considering protocols > > for signaling information about a data flow along its path in the > > network. Based on existing work on signaling requirements, this > > document proposes an architectural framework for such signaling > > protocols. > > This document provides a model for the network entities that take > > part in such signaling, and the relationship between signaling and > > the rest of network operation. We decompose the overall signaling > > protocol suite into a generic (lower) layer, with a separate upper > > layers for each specific signaling application. An initial proposal > > for the split between these layers is given, describing the overall > > functionality of the lower layer, and discussing the ways > that upper > > layer behavior can be adapted to specific signaling application > > requirements. > > This framework also considers the general interactions between > > signaling and other network layer functions, specifically > routing and > > mobility. The different routing and mobility events that impact > > signaling operation are described, along with how their handling > > should be divided between the generic and application-specific > > layers. Finally, an example signaling application (for Quality of > > Service) is described in more detail. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-nsis-fw-04.txt > > > > To remove yourself from the IETF Announcement list, send a > message to > > ietf-announce-request with the word unsubscribe in the body > > of the message. > > > > Internet-Drafts are also available by anonymous FTP. Login > > with the username > > "anonymous" and a password of your e-mail address. After logging in, > > type "cd internet-drafts" and then > > "get draft-ietf-nsis-fw-04.txt". > > > > A list of Internet-Drafts directories can be found in > > http://www.ietf.org/shadow.html > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > > > Internet-Drafts can also be obtained by e-mail. > > > > Send a message to: > > mailserv@ietf.org. > > In the body type: > > "FILE /internet-drafts/draft-ietf-nsis-fw-04.txt". > > > > NOTE: The mail server at ietf.org can return the document in > > MIME-encoded form by using the "mpack" utility. To use this > > feature, insert the command "ENCODING mime" before the "FILE" > > command. To decode the response(s), you will need "munpack" or > > a MIME-compliant mail reader. Different MIME-compliant > > mail readers > > exhibit different behavior, especially when dealing with > > "multipart" MIME messages (i.e. documents which have been split > > up into multiple messages), so check your local documentation on > > how to manipulate these messages. > > > > > > Below is the data which will enable a MIME compliant mail reader > > implementation to automatically retrieve the ASCII version of the > > Internet-Draft. > > > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Mon Oct 13 06:06:21 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28863 for ; Mon, 13 Oct 2003 06:06:21 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A8zaT-0000TZ-Nt for nsis-archive@odin.ietf.org; Mon, 13 Oct 2003 06:06:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9DA61GH001812 for nsis-archive@odin.ietf.org; Mon, 13 Oct 2003 06:06:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A8zaT-0000T7-5T; Mon, 13 Oct 2003 06:06:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A8zaP-0000SY-IY for nsis@optimus.ietf.org; Mon, 13 Oct 2003 06:05:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28843 for ; Mon, 13 Oct 2003 06:05:46 -0400 (EDT) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A8zaL-00014O-00 for nsis@ietf.org; Mon, 13 Oct 2003 06:05:53 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1A8zaK-00014L-00 for nsis@ietf.org; Mon, 13 Oct 2003 06:05:53 -0400 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id h9DA5pv22198 for ; Mon, 13 Oct 2003 13:05:51 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Mon, 13 Oct 2003 13:05:49 +0300 Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 13 Oct 2003 13:05:48 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe018.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 13 Oct 2003 13:05:48 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 13 Oct 2003 13:05:48 +0300 Message-ID: Thread-Topic: [NSIS] RSVP implementation Thread-Index: AcORVycnJoahie+MRt67gf5OxLtFcgAGdwZw To: X-OriginalArrivalTime: 13 Oct 2003 10:05:48.0509 (UTC) FILETIME=[934C50D0:01C39171] Content-Transfer-Encoding: quoted-printable Subject: [NSIS] NSIS WG Secretary Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi all, It has been suggested by some that WGs might want to utilize the notion of the WG secretary as discussed in RFC 2518: http://www.ietf.org/rfc/rfc2418.txt?number=3D2418 6.2. WG Secretary Taking minutes and editing working group documents often is performed by a specifically-designated participant or set of participants. In this role, the Secretary's job is to record WG decisions, rather than to perform basic specification. What this means is that someone (possibly more than one) would be = appointed WG secretary (duely noted on the NSIS WG page at ietf.org) who would be responsible for mintues, jabber logs, issue tracking, etc. I would = not expect that the secretary would do all this by his/her self, but be = responsible for making sure that these are done. Does anyone disapprove of the idea of WG secretary? If so, why? If = someone is interested in this position, please contact me off-list. thanks, John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Mon Oct 13 23:04:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA11112 for ; Mon, 13 Oct 2003 23:04:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9FTl-0007oZ-CM for nsis-archive@odin.ietf.org; Mon, 13 Oct 2003 23:04:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9E348uD030016 for nsis-archive@odin.ietf.org; Mon, 13 Oct 2003 23:04:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9FTe-0007kT-Kz; Mon, 13 Oct 2003 23:04:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A8xS3-0003VN-29 for nsis@optimus.ietf.org; Mon, 13 Oct 2003 03:49:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25803 for ; Mon, 13 Oct 2003 03:49:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A8xS0-000029-00 for nsis@ietf.org; Mon, 13 Oct 2003 03:49:08 -0400 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 1A8xRz-000026-00 for nsis@ietf.org; Mon, 13 Oct 2003 03:49:07 -0400 Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id h9D7n642008047; Mon, 13 Oct 2003 09:49:06 +0200 (MEST) Received: from lt.eth.ericsson.se ([164.48.158.205]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id 43DSP4AZ; Mon, 13 Oct 2003 09:49:22 +0200 Received: from eth.ericsson.se by lt.eth.ericsson.se (8.8.8+Sun/SMI-SVR4) id JAA08257; Mon, 13 Oct 2003 09:49:03 +0200 (MET DST) Message-ID: <3F8A58EE.1000009@eth.ericsson.se> Date: Mon, 13 Oct 2003 09:49:02 +0200 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Gergely Pongracz User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.4) Gecko/20030701 X-Accept-Language: en-us, en, hu MIME-Version: 1.0 To: nsis@ietf.org, nunomrc@di.fc.ul.pt CC: =?ISO-8859-1?Q?=22Attila_B=E1der_=28IJ/ETH=29=22?= , =?ISO-8859-1?Q?=22R=F3bert_Szab=F3_=28I?= =?ISO-8859-1?Q?J/ETH=29=22?= , "'Andras Csaszar (ETH) ' (E-mail)" , "'Attila Takacs (ETH) ' (E-mail)" Subject: Re: FW: [NSIS] RSVP implementation References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi! We've some experience with the ISI RSVP implementation, 4.2a4. It can be downloaded from ftp://ftp.isi.edu/rsvp/release You may need some additional patches, in this case, feel free to contact me. Regards, Gergely Pongracz _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Oct 14 03:47:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29150 for ; Tue, 14 Oct 2003 03:47:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9Jtb-0004x6-DY for nsis-archive@odin.ietf.org; Tue, 14 Oct 2003 03:47:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9E7l78n019035 for nsis-archive@odin.ietf.org; Tue, 14 Oct 2003 03:47:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9JtW-0004ws-Ev; Tue, 14 Oct 2003 03:47:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9JtB-0004wG-Vl for nsis@optimus.ietf.org; Tue, 14 Oct 2003 03:46:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29136 for ; Tue, 14 Oct 2003 03:46:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9Jt9-0006zy-00 for nsis@ietf.org; Tue, 14 Oct 2003 03:46:39 -0400 Received: from mail4.telekom.de ([195.243.210.197]) by ietf-mx with esmtp (Exim 4.12) id 1A9Jt8-0006zc-00 for nsis@ietf.org; Tue, 14 Oct 2003 03:46:38 -0400 Received: from g8pbr.blf01.telekom.de by mail2.dmz.telekom.de with ESMTP; Tue, 14 Oct 2003 09:45:58 +0200 Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id <4ZRHXNBS>; Tue, 14 Oct 2003 09:46:07 +0200 Message-Id: <9F8582E37B2EE5498E76392AEDDCD3FE03DBB66B@G8PQD.blf01.telekom.de> From: "Geib, Ruediger" To: andrew.mcdonald@roke.co.uk Cc: nsis@ietf.org Subject: RE: [NSIS] qos-nslp-00 Date: Tue, 14 Oct 2003 09:46:05 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi Andrew, thanks, your example explains two things I couldn't find in the draft: - that session IDs still need to be present and aren't replaced=20 by RSNs. - how QoS-NSLP could react once it notes that it maintains stale state. I'm having another question. The RSN is valid only between local=20 NSLP peers. Would a single RSN be used per NSLP message or per=20 session ID? Picking up your example, would it be=20 a) one RSN per NSLP message Srefresh [RSN #1, SID #55, SID #105, SID #751] b) one RSN per SID Srefresh [RSN #1, SID #55; RSN #78, SID #105; RSN #12, SID #751] There's no difference if a single message carries data of a single session. Otherwise, method a) reduces the amount of maintained=20 state and signaling load. Regards, R=FCdiger |Geib, Ruediger wrote: |> it is not clear to me how the local node reacts once it learns |> that it maintains stale state. If the only answer is "not at all" |> I can't see a benefit of the RSN method against session ID based |> refreshes. On the opposite, the state you have to maintain |> locally will increase (besides session ID you will have to store |> incoming and outgoing RSN). | |I think we may have got some confusion here on what a 'session ID' |identifies and what an 'RSN' identifies. The RSN is interpreted in the |context of a session identifier. i.e. 'Session-ID + RSN' can be used = to |identify some state in a node. 'RSN' on its own could belong=20 |to any one of many sessions. Similarly, the QoS reservation may change = |within a given session, so I don't believe that session ID could be=20 |used on its own since it doesn't identify which version of the=20 |reservation state it is referring to. | |Regarding what to do with a message containing an RSN that=20 |isn't for the currently installed state, an example: |(Remembering that RSN is a *sequence* number that increments when the |reservation changes). | |a) -------------------------------> | Full Reserve SID #55, RSN #1 | |b) <------------------------------- | ACK SID #55, RSN #1 | |c) -------------------------------> | Full Reserve SID #55, RSN #2 | |d) <------------------------------- | ACK SID #55, RSN #2 | |e) -------------------------------> | Srefresh SID #55, RSN #1 | |f) -------------------------------> | Srefresh SID #55, RSN #2 | |g) -------------------------------> | Srefresh SID #55, RSN #3 | |h) -------------------------------> | Srefresh SID #31, RSN #2 | |Message (a) installs some state. Message (b) acknowledges that=20 |state was successful installed (and can be referred to by=20 |subsequent summary refreshes). Message (c) installs some new=20 |state (e.g. asking for different resources) which replaces that=20 |which was installed by message (a). Message (d) acknowledges=20 |that state was successful installed. | |Message (e) refers to 'old' state (message RSN < current state=20 |RSN). Possibly the messages got reordered between the nodes. We=20 |might just be able to discard this refresh message silently. | |Message (f) refers to our currently installed state, so we=20 |refresh it as requested. | |Message (g) refers to some future state that we haven't got=20 |(message RSN > current state RSN). We need to signal an error=20 |back (since our neighbour thinks we've got state we haven't,=20 |and will probably carry on trying to just refresh it unless=20 |told otherwise). I guess one possibility is that there has |been some oscillation in the route (i.e. the Full Reserve for=20 |SID #55, RSN #3 went to a different node but that wasn't the=20 |route for long enough for us to time out our soft state). | |Message (h) refers to some state for a SID we don't know=20 |about. Possibly the route has changed. Again, we need to signal=20 |an error back to get a full refresh of our state. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Wed Oct 15 06:19:04 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23500 for ; Wed, 15 Oct 2003 06:19:04 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9ijr-0003jO-7l for nsis-archive@odin.ietf.org; Wed, 15 Oct 2003 06:18:43 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9FAIhVO014326 for nsis-archive@odin.ietf.org; Wed, 15 Oct 2003 06:18:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9ijC-0003c3-3u; Wed, 15 Oct 2003 06:18:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9iix-0003bO-9M for nsis@optimus.ietf.org; Wed, 15 Oct 2003 06:17:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23450 for ; Wed, 15 Oct 2003 06:17:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9iit-0002NN-00 for nsis@ietf.org; Wed, 15 Oct 2003 06:17:43 -0400 Received: from rsys002a.roke.co.uk ([193.118.192.251]) by ietf-mx with esmtp (Exim 4.12) id 1A9iis-0002Mx-00 for nsis@ietf.org; Wed, 15 Oct 2003 06:17:42 -0400 Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id <4Z79WKJG>; Wed, 15 Oct 2003 11:17:07 +0100 Message-ID: From: "McDonald, Andrew" To: "'Geib, Ruediger'" Cc: nsis@ietf.org Subject: RE: [NSIS] qos-nslp-00 Date: Wed, 15 Oct 2003 11:17:06 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi R=FCdiger, Geib, Ruediger wrote: > thanks, your example explains two things I couldn't find in the = draft: > - that session IDs still need to be present and aren't replaced > by RSNs. > - how QoS-NSLP could react once it notes that it maintains stale > state. Ok. Clearly we'll need some updates in those areas. > I'm having another question. The RSN is valid only between local > NSLP peers. Would a single RSN be used per NSLP message or per > session ID? Picking up your example, would it be >=20 > a) one RSN per NSLP message > Srefresh [RSN #1, SID #55, SID #105, SID #751] >=20 > b) one RSN per SID > Srefresh [RSN #1, SID #55; RSN #78, SID #105; RSN #12, SID #751] >=20 > There's no difference if a single message carries data of a single > session. Otherwise, method a) reduces the amount of maintained > state and signaling load. I think it would be (b). (To make sure I'm clear, I believe this = message says "I want to refresh reservation #1 for SID #55, reservation = #78 for SID #105 and reservation #12 for SID #751".) I'm not sure how you would do (a). Since the original RESERVEs may = happen at different times for the three SIDs, and they may be updated = independently I think they each need their own RSN number-space. Andrew _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Wed Oct 15 06:19:58 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23521 for ; Wed, 15 Oct 2003 06:19:58 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9ikj-0003oa-ED for nsis-archive@odin.ietf.org; Wed, 15 Oct 2003 06:19:38 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9FAJb4A014648 for nsis-archive@odin.ietf.org; Wed, 15 Oct 2003 06:19:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9ik9-0003kL-34; Wed, 15 Oct 2003 06:19:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9ijS-0003do-Gx for nsis@optimus.ietf.org; Wed, 15 Oct 2003 06:18:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23483 for ; Wed, 15 Oct 2003 06:18:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9ijO-0002O9-00 for nsis@ietf.org; Wed, 15 Oct 2003 06:18:14 -0400 Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx with esmtp (Exim 4.12) id 1A9ijO-0002NO-00 for nsis@ietf.org; Wed, 15 Oct 2003 06:18:14 -0400 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Wed, 15 Oct 2003 11:17:44 +0100 Message-ID: From: "McDonald, Andrew" To: "'Cheng Hong'" , sven.van_den_bosch@alcatel.be Cc: nsis@ietf.org Subject: RE: [NSIS] Re: qos-nslp-00 Date: Wed, 15 Oct 2003 11:17:47 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Hi Cheng, Cheng Hong wrote: > You are right that most of the implementations would choose to work > only on the output interface, since it's simpler. But, due to other > considerations, e.g. efficiency, etc, an implementation could choose > to do it in a different way. For example, one of the popular QoS > implementations ALTQ > (http://www.csl.sony.co.jp/person/kjc/kjc/software.html#ALTQ ) > actually has the traffic conditioner on the ingress interface in its > DiffServ module. > > Since the QoS-NSLP is meant to be agnostic to QoS models, I would > prefer the logical model also be neutral. Maybe some text for > clarification is necessary in the section. Or, could we do something > like the RFC2205, where the routing process is put at a position not > implying the processing sequence? I'm not sure how best to change the diagram without making it more confusing (and hence less useful in general). One of the difficulties comes from trying to show the signaling/data flows in a single summary picture. I think the best thing is probably some clarifying text along the lines of: This diagram shows an example implementation scenario where QoS conditioning is performed on the output interface. However, this does not limit the possible implementations. For example, in some cases traffic conditioning may be performed on the incoming interface, or it may be split over the input and output interfaces. How does that sound. Does it capture all the key points? Andrew _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Wed Oct 15 09:12:08 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28512 for ; Wed, 15 Oct 2003 09:12:07 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9lRE-0005AZ-1p for nsis-archive@odin.ietf.org; Wed, 15 Oct 2003 09:11:45 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9FDBec8019865 for nsis-archive@odin.ietf.org; Wed, 15 Oct 2003 09:11:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9lQc-000565-M4; Wed, 15 Oct 2003 09:11:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9lPs-00054g-4L for nsis@optimus.ietf.org; Wed, 15 Oct 2003 09:10:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28486 for ; Wed, 15 Oct 2003 09:10:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9lPq-0004AC-00 for nsis@ietf.org; Wed, 15 Oct 2003 09:10:14 -0400 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 1A9lPp-0004A9-00 for nsis@ietf.org; Wed, 15 Oct 2003 09:10:13 -0400 Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id h9FDACI2018417; Wed, 15 Oct 2003 15:10:12 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id <45JQMB3S>; Wed, 15 Oct 2003 15:10:42 +0200 Message-ID: From: =?iso-8859-1?Q?Attila_B=E1der_=28IJ/ETH=29?= To: "McDonald, Andrew" , "'Geib, Ruediger'" , nsis@ietf.org Subject: RE: [NSIS] qos-nslp-00 Date: Wed, 15 Oct 2003 15:09:42 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi Andrew and R=FCdiger, I also think b) is correct in a summary refresh. Some clarification may = be needed in the text of QoS NSLP draft that RSN indicates the sequence = of Reserve messages per sessions sent to the next NSLP hop.=20 I am also wonderng if RSN=3DMIN can be the flag in RESERVE for creating = new reserevation and, in the same way, RSN=3DMAX for removing state?=20 Best regards, Attila > -----Original Message----- > From: McDonald, Andrew [mailto:andrew.mcdonald@roke.co.uk] > Sent: Wednesday, October 15, 2003 12:17 PM > To: 'Geib, Ruediger' > Cc: nsis@ietf.org > Subject: RE: [NSIS] qos-nslp-00 >=20 >=20 > Hi R=FCdiger, >=20 > Geib, Ruediger wrote: > > thanks, your example explains two things I couldn't find in=20 > the draft: > > - that session IDs still need to be present and aren't replaced > > by RSNs. > > - how QoS-NSLP could react once it notes that it maintains stale > > state. >=20 > Ok. Clearly we'll need some updates in those areas. >=20 > > I'm having another question. The RSN is valid only between local > > NSLP peers. Would a single RSN be used per NSLP message or per > > session ID? Picking up your example, would it be > >=20 > > a) one RSN per NSLP message > > Srefresh [RSN #1, SID #55, SID #105, SID #751] > >=20 > > b) one RSN per SID > > Srefresh [RSN #1, SID #55; RSN #78, SID #105; RSN #12, SID #751] > >=20 > > There's no difference if a single message carries data of a single > > session. Otherwise, method a) reduces the amount of maintained > > state and signaling load. >=20 > I think it would be (b). (To make sure I'm clear, I believe=20 > this message says "I want to refresh reservation #1 for SID=20 > #55, reservation #78 for SID #105 and reservation #12 for SID #751".) >=20 > I'm not sure how you would do (a). Since the original=20 > RESERVEs may happen at different times for the three SIDs,=20 > and they may be updated independently I think they each need=20 > their own RSN number-space. >=20 >=20 > Andrew >=20 > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu Oct 16 08:24:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00198 for ; Thu, 16 Oct 2003 08:24:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AA7Ak-0002jB-U2 for nsis-archive@odin.ietf.org; Thu, 16 Oct 2003 08:24:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9GCO691010481 for nsis-archive@odin.ietf.org; Thu, 16 Oct 2003 08:24:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AA7Af-0002fl-Kd; Thu, 16 Oct 2003 08:24:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AA7AH-0002e4-IM for nsis@optimus.ietf.org; Thu, 16 Oct 2003 08:23:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00170 for ; Thu, 16 Oct 2003 08:23:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AA7AG-00045l-00 for nsis@ietf.org; Thu, 16 Oct 2003 08:23:36 -0400 Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81]) by ietf-mx with esmtp (Exim 4.12) id 1AA7AF-00045i-00 for nsis@ietf.org; Thu, 16 Oct 2003 08:23:35 -0400 Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5] helo=irams1.ira.uka.de) by iramx2.ira.uni-karlsruhe.de with esmtp (Exim 3.30 #10 (Debian)) id 1AA7AC-0000Jr-00; Thu, 16 Oct 2003 14:23:32 +0200 Received: from i72ms1.tm.uni-karlsruhe.de ([141.3.70.16] helo=smtp.ipv6.tm.uni-karlsruhe.de ident=8) by irams1.ira.uka.de with esmtp (Exim 3.30 #7 (Debian)) id 1AA7AB-0001IM-00; Thu, 16 Oct 2003 14:23:31 +0200 Received: from vorta.ipv6.tm.uni-karlsruhe.de ([3ffe:400:20:6:2e0:29ff:fe3e:c87] ident=mail) by smtp.ipv6.tm.uni-karlsruhe.de with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.12) id 1AA7A8-0007b4-00; Thu, 16 Oct 2003 14:23:28 +0200 Received: from localhost ([::1] helo=vorta.ipv6.tm.uni-karlsruhe.de ident=bless) by vorta.ipv6.tm.uni-karlsruhe.de with smtp (Exim 4.05) id 1AA7A7-0008DK-00; Thu, 16 Oct 2003 14:23:27 +0200 Date: Thu, 16 Oct 2003 14:23:27 +0200 From: Roland Bless To: "Hancock, Robert" Cc: nsis@ietf.org Message-Id: <20031016142327.195aac54.bless@tm.uka.de> In-Reply-To: References: Organization: Institute of Telematics, University of Karlsruhe X-Mailer: Sylpheed version 0.9.3claws (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [NSIS] normative/informative references Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Robert, On Mon, 13 Oct 2003 09:29:30 +0100 "Hancock, Robert" wrote: > some people have asked whether they can still make last call > comments on the mailing list on this draft. the answer is: > yes (in which case I will enter them myself). the tracking > tool is intended to be a convenience for the editor and anyone > else trying to disentangle N parallel conversations, it's not > intended to restrict the discussion in any way. Mainly an editorial related comment. The tracking tool lists as open issue: ] Deferred from v3: ] ] References should be split normative and informative ] (according to some criteria, presumably). ] ] We need to decide which in-progress WG documents to refer to ] as background (e.g. midcom and qos NSLP drafts?) I'd like at least to give a hint to the RFC editor's criteria below. According to my perception of the distinction between normative and informative references (from the definition below), there are nearly no normative references in the framework (except for the requirements doc). Quoting from http://www.rfc-editor.org/policy.html#policy.refs: Normative references specify documents that must be read to understand or implement the technology in the new RFC, or whose technology must be present for the technology in the new RFC to work. An informative reference is not normative; rather, it only provides additional information. For example, an informative reference might provide background or historical information. Informative references are not required to implement the technology in the RFC. Regards, Roland _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu Oct 16 09:20:23 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02168 for ; Thu, 16 Oct 2003 09:20:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AA82t-0001aN-J0 for nsis-archive@odin.ietf.org; Thu, 16 Oct 2003 09:20:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9GDK3YF006089 for nsis-archive@odin.ietf.org; Thu, 16 Oct 2003 09:20:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AA82s-0001a5-GI; Thu, 16 Oct 2003 09:20:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AA82M-0001ZD-QF for nsis@optimus.ietf.org; Thu, 16 Oct 2003 09:19:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02146 for ; Thu, 16 Oct 2003 09:19:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AA82L-0004lK-00 for nsis@ietf.org; Thu, 16 Oct 2003 09:19:29 -0400 Received: from rsys002a.roke.co.uk ([193.118.192.251]) by ietf-mx with esmtp (Exim 4.12) id 1AA82K-0004ka-00 for nsis@ietf.org; Thu, 16 Oct 2003 09:19:28 -0400 Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Thu, 16 Oct 2003 14:18:56 +0100 Message-ID: From: "Hancock, Robert" To: Roland Bless Cc: nsis@ietf.org Date: Thu, 16 Oct 2003 14:19:03 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [NSIS] RE: normative/informative references Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , hi roland, my view is that even the requirements doc is not normative - you don't need to understand the requirements document to 'implement' the framework (whatever 'implement' means in this context). you might want to read the requirements document to understand why the framework addresses the problems it does (i.e. the requirements are informative). in other words, my view is that the framework has no normative references. but i'm waiting for w.g. chair guidance on that. cheers, r. > -----Original Message----- > From: Roland Bless [mailto:bless@tm.uka.de] > Sent: Thursday, October 16, 2003 14:23 > To: Hancock, Robert > Cc: nsis@ietf.org > Subject: normative/informative references > > > Hi Robert, > > On Mon, 13 Oct 2003 09:29:30 +0100 "Hancock, Robert" > wrote: > > > some people have asked whether they can still make last call > > comments on the mailing list on this draft. the answer is: > > yes (in which case I will enter them myself). the tracking > > tool is intended to be a convenience for the editor and anyone > > else trying to disentangle N parallel conversations, it's not > > intended to restrict the discussion in any way. > > Mainly an editorial related comment. > > The tracking tool lists as open issue: > ] Deferred from v3: > ] > ] References should be split normative and informative > ] (according to some criteria, presumably). > ] > ] We need to decide which in-progress WG documents to refer to > ] as background (e.g. midcom and qos NSLP drafts?) > > I'd like at least to give a hint to the RFC editor's criteria below. > According to my perception of the distinction between normative and > informative references (from the definition below), there are > nearly no > normative references in the framework (except for the > requirements doc). > > Quoting from http://www.rfc-editor.org/policy.html#policy.refs: > Normative references specify documents that must be read to understand > or implement the technology in the new RFC, or whose > technology must be > present for the technology in the new RFC to work. An informative > reference is not normative; rather, it only provides additional > information. For example, an informative reference might provide > background or historical information. Informative references are not > required to implement the technology in the RFC. > > Regards, > Roland > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Fri Oct 17 01:27:24 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07272 for ; Fri, 17 Oct 2003 01:27:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAN8g-0006au-W1 for nsis-archive@odin.ietf.org; Fri, 17 Oct 2003 01:27:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9H5R2LU025339 for nsis-archive@odin.ietf.org; Fri, 17 Oct 2003 01:27:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAN8f-0006aC-MQ; Fri, 17 Oct 2003 01:27:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAN87-0006Zj-1q for nsis@optimus.ietf.org; Fri, 17 Oct 2003 01:26:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07259 for ; Fri, 17 Oct 2003 01:26:17 -0400 (EDT) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAN83-0006gi-00 for nsis@ietf.org; Fri, 17 Oct 2003 01:26:23 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AAN82-0006ge-00 for nsis@ietf.org; Fri, 17 Oct 2003 01:26:23 -0400 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id h9H5QMd18517 for ; Fri, 17 Oct 2003 08:26:23 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Fri, 17 Oct 2003 08:26:22 +0300 Received: from esebe006.NOE.Nokia.com ([172.21.138.46]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 17 Oct 2003 08:26:22 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe006.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 17 Oct 2003 08:26:22 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 17 Oct 2003 08:26:21 +0300 Message-ID: Thread-Topic: WG Chairs Training in Minneapolis Thread-Index: AcOUKSZYaOVAQKTiQhOdYDFbz1DMvQARdkCQ To: X-OriginalArrivalTime: 17 Oct 2003 05:26:22.0281 (UTC) FILETIME=[337FF390:01C3946F] Content-Transfer-Encoding: quoted-printable Subject: [NSIS] New Editor's Training in Minneapolis Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi all, In Minneapolis, there is a new editor's training session. I encourage the current set of document authors / editors to attend this, if they can. thanks, John Sunday, November 10, 2003 = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= 1330-1500 Editor's Training -- Conrad C Training for current or aspiring IETF document editors. Covers the roles and responsibilities=20 of a document editor, and includes advice on=20 producing a high-quality IETF specification. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Fri Oct 17 03:11:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21830 for ; Fri, 17 Oct 2003 03:11:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAOlO-0003xH-U9 for nsis-archive@odin.ietf.org; Fri, 17 Oct 2003 03:11:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9H7B67U015197 for nsis-archive@odin.ietf.org; Fri, 17 Oct 2003 03:11:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAOlL-0003wr-KT; Fri, 17 Oct 2003 03:11:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAOlC-0003vK-Ux for nsis@optimus.ietf.org; Fri, 17 Oct 2003 03:10:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21817 for ; Fri, 17 Oct 2003 03:10:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAOl8-0007bI-00 for nsis@ietf.org; Fri, 17 Oct 2003 03:10:50 -0400 Received: from mailsrv.psl.com.sg ([202.14.153.3]) by ietf-mx with esmtp (Exim 4.12) id 1AAOl7-0007bF-00 for nsis@ietf.org; Fri, 17 Oct 2003 03:10:49 -0400 Received: from netpronote3 (netpronote3.psl.com.sg [10.81.113.71]) by mailsrv.psl.com.sg (8.12.9/8.12.9) with SMTP id h9H72HRn016741; Fri, 17 Oct 2003 15:02:19 +0800 (SGT) From: "Cheng Hong" To: "McDonald, Andrew" , Cc: Subject: RE: [NSIS] Re: qos-nslp-00 Date: Fri, 17 Oct 2003 15:13:32 +0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200 Importance: Normal In-Reply-To: Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Andrew, Your proposed text is fine with me. It did clarify the issue, and we could save some time for remaking the ASCII art:-> Best regards Cheng > -----Original Message----- > From: nsis-admin@ietf.org [mailto:nsis-admin@ietf.org]On Behalf Of > McDonald, Andrew > Sent: Wednesday, October 15, 2003 6:18 PM > To: 'Cheng Hong'; sven.van_den_bosch@alcatel.be > Cc: nsis@ietf.org > Subject: RE: [NSIS] Re: qos-nslp-00 > > > Hi Cheng, > > Cheng Hong wrote: > > You are right that most of the implementations would choose to work > > only on the output interface, since it's simpler. But, due to other > > considerations, e.g. efficiency, etc, an implementation could choose > > to do it in a different way. For example, one of the popular QoS > > implementations ALTQ > > (http://www.csl.sony.co.jp/person/kjc/kjc/software.html#ALTQ ) > > actually has the traffic conditioner on the ingress interface in its > > DiffServ module. > > > > Since the QoS-NSLP is meant to be agnostic to QoS models, I would > > prefer the logical model also be neutral. Maybe some text for > > clarification is necessary in the section. Or, could we do something > > like the RFC2205, where the routing process is put at a position not > > implying the processing sequence? > > I'm not sure how best to change the diagram without making it > more confusing > (and hence less useful in general). One of the difficulties comes from > trying to show the signaling/data flows in a single summary picture. > > I think the best thing is probably some clarifying text along the > lines of: > This diagram shows an example implementation scenario where QoS > conditioning > is performed on the output interface. However, this does not limit the > possible implementations. For example, in some cases traffic conditioning > may be performed on the incoming interface, or it may be split over the > input and output interfaces. > > How does that sound. Does it capture all the key points? > > > Andrew > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Fri Oct 17 05:31:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25645 for ; Fri, 17 Oct 2003 05:31:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAQws-0002FP-D7 for nsis-archive@odin.ietf.org; Fri, 17 Oct 2003 05:31:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9H9V63t008638 for nsis-archive@odin.ietf.org; Fri, 17 Oct 2003 05:31:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAQwo-0002Em-0b; Fri, 17 Oct 2003 05:31:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAQwF-0002E0-9U for nsis@optimus.ietf.org; Fri, 17 Oct 2003 05:30:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25620 for ; Fri, 17 Oct 2003 05:30:16 -0400 (EDT) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAQwB-0001Fx-00 for nsis@ietf.org; Fri, 17 Oct 2003 05:30:23 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AAQwA-0001Fu-00 for nsis@ietf.org; Fri, 17 Oct 2003 05:30:23 -0400 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id h9H9UMX24905 for ; Fri, 17 Oct 2003 12:30:22 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 17 Oct 2003 12:30:22 +0300 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 17 Oct 2003 12:30:22 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe013.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 17 Oct 2003 12:30:21 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] RE: normative/informative references Date: Fri, 17 Oct 2003 12:30:21 +0300 Message-ID: Thread-Topic: [NSIS] RE: normative/informative references Thread-Index: AcOT6GsGbL5E2QqCSreViM/zLyoKbgApfYMg To: , Cc: X-OriginalArrivalTime: 17 Oct 2003 09:30:21.0817 (UTC) FILETIME=[4957DE90:01C39491] Content-Transfer-Encoding: quoted-printable Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi all, If I were to split the references, I would do it as follows. This is a = suggestion, your milage may vary. (note - the two normative documents are documents that I think are needed to understand why certain decisions have been made in the framework). John Normative 2 Brunner, M., "Requirements for Signaling Protocols", draft-ietf- nsis-req-09.txt (work in progress), August 2003=20 =20 7 Tschofenig, H., "RSVP Security Properties", draft-ietf-nsis-rsvp- sec-properties-02.txt (work in progress), June 2003=20 =20 Non-Normative 1 Braden, R., L. Zhang, S. Berson, S. Herzog, S. Jamin, "Resource=20 ReSerVation Protocol (RSVP) -- Version 1 Functional=20 Specification", RFC 2205, September 1997=20 =20 3 Tschofenig, H. and D. Kroeselberg, "Security Threats for NSIS",=20 draft-ietf-nsis-threats-02.txt (work in progress), June 2003=20 =20 4 Chaskar, H. (editor), " Requirements of a Quality of Service (QoS) = Solution for Mobile IP", RFC 3583, September 2003=20 =20 5 Swale, R. P., P. A. Mart, P. Sijben, S. Brim, M. Shore, "Middlebox = Communications (midcom) Protocol Requirements", RFC 3304, August=20 2002=20 =20 6 Manner, J., X. Fu, P. Pan, "Analysis of Existing Quality of=20 Service Signaling Protocols", draft-ietf-nsis-signalling-analysis- 02.txt (work in progress), June 2003=20 =20 8 Katz, D., "IP Router Alert Option", RFC2113, February 1997=20 =20 9 Partridge, C., A. Jackson, "IPv6 Router Alert Option", RFC 2711,=20 October 1999=20 =20 10 Baker, F., C. Iturralde, F. Le Faucheur, B. Davie, "Aggregation of = RSVP for IPv4 and IPv6 Reservations", RFC 3175, September 2001=20 =20 11 Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on=20 Security Considerations", RFC 3552, July 2003=20 =20 12 Tschofenig, H., M. Buechli, S. Van den Bosch, H. Schulzrinne,=20 "NSIS Authentication, Authorization and Accounting Issues", draft- tschofenig-nsis-aaa-issues-01.txt (work in progress), March 2003=20 =20 13 Berger, L., D. Gan, G. Swallow, P. Pan, F. Tommasi, S. Molendini,=20 "RSVP Refresh Overhead Reduction Extensions", RFC2961, April 2001=20 =20 14 Ji, P., Z. Ge, J. Kurose, D. Townsley, "A Comparison of Hard-State = and Soft-State Signaling Protocols", Computer Communication=20 Review, Volume 33, Number 4, October 2003=20 =20 15 Floyd, S., "Congestion Control Principles", RFC 2914, September=20 2000=20 =20 16 Apostolopoulos, G., D. Williams, S. Kamat, R. Guerin, A. Orda,=20 T. Przygienda, "QoS Routing Mechanisms and OSPF Extensions", RFC=20 2676, August 1999=20 =20 17 Knight, S., D. Weaver, D. Whipple, R. Hinden, D. Mitzel, P. Hunt,=20 P. Higginson, M. Shand, A. Lindem, "Virtual Router Redundancy=20 Protocol", RFC2338, April 1998=20 =20 18 Heijenk, G., G. Karagiannis, V. Rexhepi, L. Westberg, "DiffServ=20 Resource Management in IP-based Radio Access Networks",=20 Proceedings of 4th International Symposium on Wireless Personal=20 Multimedia Communications-WPMC'01, September 9 - 12, 2001=20 =20 19 Manner, J., A. Lopez, A. Mihailovic, H. Velayos, E. Hepworth, Y.=20 Khouaja, "Evaluation of Mobility and QoS Interaction", Computer=20 Networks, Volume 38, Issue 2, 5 February 2002, pp 137-163=20 =20 20 Johnson, D., C. Perkins, J. Arkko, "Mobility Support in IPv6",=20 draft-ietf-mobileip-ipv6-24.txt (work in progress), June 2003=20 =20 21 Trossen, D., G. Krishnamurthi, H. Chaskar, J. Kempf, "Issues in=20 candidate access router discovery for seamless IP-level handoffs", = draft-ietf-seamoby-cardiscovery-issues-04.txt (work in progress),=20 October 2002=20 =20 22 Kempf, J., "Problem Description: Reasons For Performing Context=20 Transfers Between Nodes in an IP Access Network", RFC3374,=20 September 2002=20 =20 23 Srisuresh, P. and M. Holdrege, "IP Network Address Translator=20 (NAT) Terminology and Considerations", RFC2663, August 1999=20 =20 24 Nordmark, E., "Stateless IP/ICMP Translation Algorithm (SIIT)",=20 RFC2765, February 2000=20 =20 25 Rosenberg, J., J. Weinberger, C. Huitema, R. Mahy, "STUN - Simple=20 Traversal of User Datagram Protocol (UDP) Through Network Address=20 Translators (NATs)", RFC3489, March 2003=20 =20 26 Terzis, A., J. Krawczyk, J. Wroclawski, L. Zhang, "RSVP Operation=20 Over IP Tunnels", RFC 2746, January 2000=20 =20 27 Braden, R., D. Clark, S. Shenker, "Integrated Services in the=20 Internet Architecture: an Overview", RFC 1633, June 1994=20 =20 28 Westberg, L., Csaszar, A., Karagiannis, G., Marquetant, A.,=20 Partain, D., Pop, O., Rexhepi, V., Szabo, R., Takacs, A.,=20 "Resource Management in Diffserv (RMD): A Functionality and=20 Performance Behavior Overview", Seventh International Workshop on=20 Protocols for High-Speed networks - PfHSN 2002, 22 - 24 April 2002 = =20 29 Ferrari, D., A. Banerjea, H. Zhang, "Network Support for=20 Multimedia - A Discussion of the Tenet Approach", Berkeley TR-92- 072, November 1992=20 =20 30 Nichols, K., V. Jacobson, L. Zhang, "A Two-bit Differentiated=20 Services Architecture for the Internet", RFC 2638, July 1999=20 =20 31 Brunner, M., M. Stiemerling, M. Martin, H. Tschofenig, H.=20 Schulzrinne, "NSIS NAT/FW NSLP: Problem Statement and Framework",=20 draft-brunner-nsis-midcom-ps-00.txt (work in progress), June 2003=20 =20 32 Aoun, C., "NSIS Network Address Translator implications", draft- aoun-nsis-nat-imps-01.txt (work in progress), March 2003=20 > -----Original Message----- > From: ext Hancock, Robert [mailto:robert.hancock@roke.co.uk] > Sent: 16 October, 2003 16:19 > To: Roland Bless > Cc: nsis@ietf.org > Subject: [NSIS] RE: normative/informative references >=20 >=20 > hi roland, >=20 > my view is that even the requirements doc is not normative -=20 > you don't need to understand the requirements document to > 'implement' the framework (whatever 'implement' means in this > context). you might want to read the requirements document > to understand why the framework addresses the problems it > does (i.e. the requirements are informative). >=20 > in other words, my view is that the framework has no=20 > normative references. but i'm waiting for w.g. chair guidance > on that. >=20 > cheers, >=20 > r. >=20 > > -----Original Message----- > > From: Roland Bless [mailto:bless@tm.uka.de] > > Sent: Thursday, October 16, 2003 14:23 > > To: Hancock, Robert > > Cc: nsis@ietf.org > > Subject: normative/informative references > >=20 > >=20 > > Hi Robert, > >=20 > > On Mon, 13 Oct 2003 09:29:30 +0100 "Hancock, Robert"=20 > > wrote: > >=20 > > > some people have asked whether they can still make last call > > > comments on the mailing list on this draft. the answer is: > > > yes (in which case I will enter them myself). the tracking > > > tool is intended to be a convenience for the editor and anyone > > > else trying to disentangle N parallel conversations, it's not > > > intended to restrict the discussion in any way. > >=20 > > Mainly an editorial related comment. > >=20 > > The tracking tool lists as open issue: > > ] Deferred from v3: > > ] > > ] References should be split normative and informative > > ] (according to some criteria, presumably). > > ] > > ] We need to decide which in-progress WG documents to refer to > > ] as background (e.g. midcom and qos NSLP drafts?) > >=20 > > I'd like at least to give a hint to the RFC editor's criteria below. > > According to my perception of the distinction between normative and > > informative references (from the definition below), there are=20 > > nearly no=20 > > normative references in the framework (except for the=20 > > requirements doc). > >=20 > > Quoting from http://www.rfc-editor.org/policy.html#policy.refs: > > Normative references specify documents that must be read to=20 > understand > > or implement the technology in the new RFC, or whose=20 > > technology must be > > present for the technology in the new RFC to work. An informative > > reference is not normative; rather, it only provides additional > > information. For example, an informative reference might provide > > background or historical information. Informative references are not > > required to implement the technology in the RFC. > >=20 > > Regards, > > Roland > >=20 >=20 > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Fri Oct 17 07:24:37 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27898 for ; Fri, 17 Oct 2003 07:24:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AASiG-0006SH-P7 for nsis-archive@odin.ietf.org; Fri, 17 Oct 2003 07:24:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9HBO809024799 for nsis-archive@odin.ietf.org; Fri, 17 Oct 2003 07:24:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AASi9-0006RR-I7; Fri, 17 Oct 2003 07:24:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAShb-0006Qw-0D for nsis@optimus.ietf.org; Fri, 17 Oct 2003 07:23:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27861 for ; Fri, 17 Oct 2003 07:23:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AASha-0002KY-00 for nsis@ietf.org; Fri, 17 Oct 2003 07:23:26 -0400 Received: from courier.cs.helsinki.fi ([128.214.9.1] helo=mail.cs.helsinki.fi) by ietf-mx with esmtp (Exim 4.12) id 1AAShZ-0002KV-00 for nsis@ietf.org; Fri, 17 Oct 2003 07:23:26 -0400 Received: from mannersaari.cs.Helsinki.FI (mannersaari.cs.helsinki.fi [::ffff:128.214.11.173]) (IDENT: jmanner, TLS: TLSv1/SSLv3,168bits,DES-CBC3-SHA) by mail.cs.helsinki.fi with esmtp; Fri, 17 Oct 2003 14:23:23 +0300 Date: Fri, 17 Oct 2003 14:23:22 +0300 (EEST) From: Jukka MJ Manner To: nsis@ietf.org Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [NSIS] Next steps for the analysis document Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi all, I would need to make (hopefully final) changes to the Analysis draft. I'm trying to figure out what needs to be done. I would need the WG's view (yes, that means you, too) on what is missing (needs work) in the draft. At least issues 1,2 and 3 would need the WGs view as a whole, other items are more or less directed to certain individuals or the draft editors. Here is a list of issues: 1) Remove the Appendix? Was there some comments about keeping it, I think someone liked it in Vienna? Or was it clear to remove it? 2) Add a short review of SICAP, a protocol similar to BGRP? (See Helena Rute Sofia's email on July 16th 2003) (SICAP description July 17th 2003) 3) What about adding an RMD evaluation? Or any other text? (see Georgios' email on July 17 2003) (some discussions July 17th -> July 22nd, Sep 5) 4) Hannes to review the security section? A short summary and pointers to his documents? 5) Section 3.5 needed more proof, need to ask Ping to review the text. See John's email on July 7th 2003. 6) Is there text that could be taken from Michael Thomas' draft on mobility issues? 7) Add a reference that shows how YESSIR is as good as claimed in Section 6.2.1 (Ping?) 8) Add reference to Tenet (mail from Alejandro Avella Jul 12 2003): (Page 20, Section 6.1) Anindo Banerjea, Domenico Ferrari, Bruce A. Mah, Mark Moran, Dinesh C. Verma, Hui Zhang The Tenet Real-Time Protocol Suite: Design, Implementation, and Experiences (1996) IEEE ACM Transactions on Networking http://citeseer.nj.nec.com/banerjea96tenet.html 9) Split the references into (only?) "Non-Normative" 10) Add a summary Regards, Jukka _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Fri Oct 17 07:36:23 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28270 for ; Fri, 17 Oct 2003 07:36:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAStl-0007UQ-SS for nsis-archive@odin.ietf.org; Fri, 17 Oct 2003 07:36:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9HBa1ko028755 for nsis-archive@odin.ietf.org; Fri, 17 Oct 2003 07:36:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAStl-0007Th-Lm; Fri, 17 Oct 2003 07:36:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AASsu-0007PX-Fs for nsis@optimus.ietf.org; Fri, 17 Oct 2003 07:35:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28250 for ; Fri, 17 Oct 2003 07:35:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AASst-0002SQ-00 for nsis@ietf.org; Fri, 17 Oct 2003 07:35:07 -0400 Received: from thoth.sbs.de ([192.35.17.2]) by ietf-mx with esmtp (Exim 4.12) id 1AASst-0002SN-00 for nsis@ietf.org; Fri, 17 Oct 2003 07:35:07 -0400 Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by thoth.sbs.de (8.11.7/8.11.7) with ESMTP id h9HBZ5710241; Fri, 17 Oct 2003 13:35:05 +0200 (MEST) Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail1.siemens.de (8.11.7/8.11.7) with ESMTP id h9HBZ4x29866; Fri, 17 Oct 2003 13:35:05 +0200 (MEST) Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2653.19) id <4DN1RJ2N>; Fri, 17 Oct 2003 13:34:54 +0200 Message-ID: <2A8DB02E3018D411901B009027FD3A3F03BC02EF@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: "'Jukka MJ Manner'" , nsis@ietf.org Subject: RE: [NSIS] Next steps for the analysis document Date: Fri, 17 Oct 2003 13:34:57 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , hi jukka, i will re-read the document again to address the security issues. i have once read all the described protocols with respect to security. unfortunately, the security considerations in many of these protocols is lacking a useful level of detail. ciao hannes > -----Original Message----- > From: Jukka MJ Manner [mailto:jmanner@cs.Helsinki.FI] > Sent: Friday, October 17, 2003 1:23 PM > To: nsis@ietf.org > Subject: [NSIS] Next steps for the analysis document > > > > Hi all, > > I would need to make (hopefully final) changes to the > Analysis draft. I'm > trying to figure out what needs to be done. I would need the WG's view > (yes, that means you, too) on what is missing (needs work) in > the draft. > At least issues 1,2 and 3 would need the WGs view as a whole, > other items > are more or less directed to certain individuals or the draft > editors. > Here is a list of issues: > > > 1) Remove the Appendix? Was there some comments about keeping > it, I think > someone liked it in Vienna? Or was it clear to remove it? > > > 2) Add a short review of SICAP, a protocol similar to BGRP? > (See Helena > Rute Sofia's email on July 16th 2003) (SICAP description July > 17th 2003) > > > 3) What about adding an RMD evaluation? Or any other text? > (see Georgios' > email on July 17 2003) (some discussions July 17th -> July > 22nd, Sep 5) > > > 4) Hannes to review the security section? A short summary and pointers > to his documents? > > > 5) Section 3.5 needed more proof, need to ask Ping to review > the text. > See John's email on July 7th 2003. > > > 6) Is there text that could be taken from Michael Thomas' draft on > mobility issues? > > > 7) Add a reference that shows how YESSIR is as good as > claimed in Section > 6.2.1 (Ping?) > > > 8) Add reference to Tenet (mail from Alejandro Avella Jul 12 2003): > (Page 20, Section 6.1) > Anindo Banerjea, Domenico Ferrari, Bruce A. Mah, Mark Moran, > Dinesh C. > Verma, Hui Zhang > The Tenet Real-Time Protocol Suite: Design, Implementation, and > Experiences (1996) > IEEE ACM Transactions on Networking > http://citeseer.nj.nec.com/banerjea96tenet.html > > > 9) Split the references into (only?) "Non-Normative" > > > 10) Add a summary > > > Regards, > Jukka > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Fri Oct 17 07:42:24 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28426 for ; Fri, 17 Oct 2003 07:42:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AASza-0007yQ-Lm for nsis-archive@odin.ietf.org; Fri, 17 Oct 2003 07:42:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9HBg2P6030633 for nsis-archive@odin.ietf.org; Fri, 17 Oct 2003 07:42:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AASza-0007xy-Ey; Fri, 17 Oct 2003 07:42:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AASzI-0007x1-Oj for nsis@optimus.ietf.org; Fri, 17 Oct 2003 07:41:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28398 for ; Fri, 17 Oct 2003 07:41:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AASzI-0002VE-00 for nsis@ietf.org; Fri, 17 Oct 2003 07:41:44 -0400 Received: from courier.cs.helsinki.fi ([128.214.9.1] helo=mail.cs.helsinki.fi) by ietf-mx with esmtp (Exim 4.12) id 1AASzH-0002VB-00 for nsis@ietf.org; Fri, 17 Oct 2003 07:41:43 -0400 Received: from mannersaari.cs.Helsinki.FI (mannersaari.cs.helsinki.fi [::ffff:128.214.11.173]) (IDENT: jmanner, TLS: TLSv1/SSLv3,168bits,DES-CBC3-SHA) by mail.cs.helsinki.fi with esmtp; Fri, 17 Oct 2003 14:41:42 +0300 Date: Fri, 17 Oct 2003 14:41:42 +0300 (EEST) From: Jukka MJ Manner To: Tschofenig Hannes cc: nsis@ietf.org Subject: RE: [NSIS] Next steps for the analysis document In-Reply-To: <2A8DB02E3018D411901B009027FD3A3F03BC02EF@mchp905a.mch.sbs.de> Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Hannes, It is true that most protocols do not consider security at all or expect some weird things, or even rely on someone else to do security. At least some overall security section is needed, perhaps our dear Chair can provide feedback to your review. Cheers, Jukka On Fri, 17 Oct 2003, Tschofenig Hannes wrote: > hi jukka, > > i will re-read the document again to address the security issues. > i have once read all the described protocols with respect to security. > unfortunately, the security considerations in many of these protocols is > lacking a useful level of detail. > > ciao > hannes > > > > -----Original Message----- > > From: Jukka MJ Manner [mailto:jmanner@cs.Helsinki.FI] > > Sent: Friday, October 17, 2003 1:23 PM > > To: nsis@ietf.org > > Subject: [NSIS] Next steps for the analysis document > > > > > > > > Hi all, > > > > I would need to make (hopefully final) changes to the > > Analysis draft. I'm > > trying to figure out what needs to be done. I would need the WG's view > > (yes, that means you, too) on what is missing (needs work) in > > the draft. > > At least issues 1,2 and 3 would need the WGs view as a whole, > > other items > > are more or less directed to certain individuals or the draft > > editors. > > Here is a list of issues: > > > > > > 1) Remove the Appendix? Was there some comments about keeping > > it, I think > > someone liked it in Vienna? Or was it clear to remove it? > > > > > > 2) Add a short review of SICAP, a protocol similar to BGRP? > > (See Helena > > Rute Sofia's email on July 16th 2003) (SICAP description July > > 17th 2003) > > > > > > 3) What about adding an RMD evaluation? Or any other text? > > (see Georgios' > > email on July 17 2003) (some discussions July 17th -> July > > 22nd, Sep 5) > > > > > > 4) Hannes to review the security section? A short summary and pointers > > to his documents? > > > > > > 5) Section 3.5 needed more proof, need to ask Ping to review > > the text. > > See John's email on July 7th 2003. > > > > > > 6) Is there text that could be taken from Michael Thomas' draft on > > mobility issues? > > > > > > 7) Add a reference that shows how YESSIR is as good as > > claimed in Section > > 6.2.1 (Ping?) > > > > > > 8) Add reference to Tenet (mail from Alejandro Avella Jul 12 2003): > > (Page 20, Section 6.1) > > Anindo Banerjea, Domenico Ferrari, Bruce A. Mah, Mark Moran, > > Dinesh C. > > Verma, Hui Zhang > > The Tenet Real-Time Protocol Suite: Design, Implementation, and > > Experiences (1996) > > IEEE ACM Transactions on Networking > > http://citeseer.nj.nec.com/banerjea96tenet.html > > > > > > 9) Split the references into (only?) "Non-Normative" > > > > > > 10) Add a summary > > > > > > Regards, > > Jukka > > > > > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Fri Oct 17 07:47:24 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28534 for ; Fri, 17 Oct 2003 07:47:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAT4Q-0008Ay-8q for nsis-archive@odin.ietf.org; Fri, 17 Oct 2003 07:47:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9HBl2Sw031385 for nsis-archive@odin.ietf.org; Fri, 17 Oct 2003 07:47:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAT4P-0008A7-Vn; Fri, 17 Oct 2003 07:47:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAT3X-00088z-Df for nsis@optimus.ietf.org; Fri, 17 Oct 2003 07:46:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28512 for ; Fri, 17 Oct 2003 07:45:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAT3W-0002YE-00 for nsis@ietf.org; Fri, 17 Oct 2003 07:46:06 -0400 Received: from goliath.siemens.de ([192.35.17.28]) by ietf-mx with esmtp (Exim 4.12) id 1AAT3V-0002YB-00 for nsis@ietf.org; Fri, 17 Oct 2003 07:46:06 -0400 Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by goliath.siemens.de (8.11.7/8.11.7) with ESMTP id h9HBk2h06525; Fri, 17 Oct 2003 13:46:03 +0200 (MEST) Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail1.siemens.de (8.11.7/8.11.7) with ESMTP id h9HBk1x19720; Fri, 17 Oct 2003 13:46:01 +0200 (MEST) Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2653.19) id <4DN1RJQW>; Fri, 17 Oct 2003 13:45:50 +0200 Message-ID: <2A8DB02E3018D411901B009027FD3A3F03BC02F1@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: "'Jukka MJ Manner'" Cc: nsis@ietf.org Subject: RE: [NSIS] Next steps for the analysis document Date: Fri, 17 Oct 2003 13:45:54 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , i will do my best. > -----Original Message----- > From: Jukka MJ Manner [mailto:jmanner@cs.Helsinki.FI] > Sent: Friday, October 17, 2003 1:42 PM > To: Tschofenig Hannes > Cc: nsis@ietf.org > Subject: RE: [NSIS] Next steps for the analysis document > > > > Hi Hannes, > > It is true that most protocols do not consider security at > all or expect > some weird things, or even rely on someone else to do > security. At least > some overall security section is needed, perhaps our dear Chair can > provide feedback to your review. > > Cheers, > Jukka > > On Fri, 17 Oct 2003, Tschofenig Hannes wrote: > > > hi jukka, > > > > i will re-read the document again to address the security issues. > > i have once read all the described protocols with respect > to security. > > unfortunately, the security considerations in many of > these protocols is > > lacking a useful level of detail. > > > > ciao > > hannes > > > > > > > -----Original Message----- > > > From: Jukka MJ Manner [mailto:jmanner@cs.Helsinki.FI] > > > Sent: Friday, October 17, 2003 1:23 PM > > > To: nsis@ietf.org > > > Subject: [NSIS] Next steps for the analysis document > > > > > > > > > > > > Hi all, > > > > > > I would need to make (hopefully final) changes to the > > > Analysis draft. I'm > > > trying to figure out what needs to be done. I would need > the WG's view > > > (yes, that means you, too) on what is missing (needs work) in > > > the draft. > > > At least issues 1,2 and 3 would need the WGs view as a whole, > > > other items > > > are more or less directed to certain individuals or the draft > > > editors. > > > Here is a list of issues: > > > > > > > > > 1) Remove the Appendix? Was there some comments about keeping > > > it, I think > > > someone liked it in Vienna? Or was it clear to remove it? > > > > > > > > > 2) Add a short review of SICAP, a protocol similar to BGRP? > > > (See Helena > > > Rute Sofia's email on July 16th 2003) (SICAP description July > > > 17th 2003) > > > > > > > > > 3) What about adding an RMD evaluation? Or any other text? > > > (see Georgios' > > > email on July 17 2003) (some discussions July 17th -> July > > > 22nd, Sep 5) > > > > > > > > > 4) Hannes to review the security section? A short summary > and pointers > > > to his documents? > > > > > > > > > 5) Section 3.5 needed more proof, need to ask Ping to review > > > the text. > > > See John's email on July 7th 2003. > > > > > > > > > 6) Is there text that could be taken from Michael Thomas' > draft on > > > mobility issues? > > > > > > > > > 7) Add a reference that shows how YESSIR is as good as > > > claimed in Section > > > 6.2.1 (Ping?) > > > > > > > > > 8) Add reference to Tenet (mail from Alejandro Avella Jul > 12 2003): > > > (Page 20, Section 6.1) > > > Anindo Banerjea, Domenico Ferrari, Bruce A. Mah, Mark Moran, > > > Dinesh C. > > > Verma, Hui Zhang > > > The Tenet Real-Time Protocol Suite: Design, Implementation, and > > > Experiences (1996) > > > IEEE ACM Transactions on Networking > > > http://citeseer.nj.nec.com/banerjea96tenet.html > > > > > > > > > 9) Split the references into (only?) "Non-Normative" > > > > > > > > > 10) Add a summary > > > > > > > > > Regards, > > > Jukka > > > > > > > > > _______________________________________________ > > > nsis mailing list > > > nsis@ietf.org > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Fri Oct 17 07:54:23 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28721 for ; Fri, 17 Oct 2003 07:54:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AATBB-0008OJ-QO for nsis-archive@odin.ietf.org; Fri, 17 Oct 2003 07:54:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9HBs1q3032239 for nsis-archive@odin.ietf.org; Fri, 17 Oct 2003 07:54:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AATBB-0008NO-20; Fri, 17 Oct 2003 07:54:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AATAq-0008Ms-Gs for nsis@optimus.ietf.org; Fri, 17 Oct 2003 07:53:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28675 for ; Fri, 17 Oct 2003 07:53:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AATAp-0002bb-00 for nsis@ietf.org; Fri, 17 Oct 2003 07:53:39 -0400 Received: from infres.enst.fr ([137.194.192.1]) by ietf-mx with esmtp (Exim 4.12) id 1AATAo-0002bX-00 for nsis@ietf.org; Fri, 17 Oct 2003 07:53:38 -0400 Received: from pcluu (pcluu.enst.fr [137.194.7.121]) by infres.enst.fr (Postfix) with SMTP id 6BD891B02; Fri, 17 Oct 2003 13:53:25 +0200 (MEST) Message-ID: <005c01c394a5$8090e500$7907c289@pcluu> From: "Thanh Tra LUU" To: "Jukka MJ Manner" Cc: References: Subject: Re: [NSIS] Next steps for the analysis document Date: Fri, 17 Oct 2003 13:55:02 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit hi Jukka, I agree with you. However, it seems difficult to see all security aspects when writing a document. I think it will be better if we (readers, or someone are security experts) can send authors the feedback of security when we see the security problems. After that, the authors can update their documents. Best regards Nary Tra ----- Original Message ----- From: "Jukka MJ Manner" To: "Tschofenig Hannes" Cc: Sent: Friday, October 17, 2003 1:41 PM Subject: RE: [NSIS] Next steps for the analysis document > > Hi Hannes, > > It is true that most protocols do not consider security at all or expect > some weird things, or even rely on someone else to do security. At least > some overall security section is needed, perhaps our dear Chair can > provide feedback to your review. > > Cheers, > Jukka > > On Fri, 17 Oct 2003, Tschofenig Hannes wrote: > > > hi jukka, > > > > i will re-read the document again to address the security issues. > > i have once read all the described protocols with respect to security. > > unfortunately, the security considerations in many of these protocols is > > lacking a useful level of detail. > > > > ciao > > hannes > > > > > > > -----Original Message----- > > > From: Jukka MJ Manner [mailto:jmanner@cs.Helsinki.FI] > > > Sent: Friday, October 17, 2003 1:23 PM > > > To: nsis@ietf.org > > > Subject: [NSIS] Next steps for the analysis document > > > > > > > > > > > > Hi all, > > > > > > I would need to make (hopefully final) changes to the > > > Analysis draft. I'm > > > trying to figure out what needs to be done. I would need the WG's view > > > (yes, that means you, too) on what is missing (needs work) in > > > the draft. > > > At least issues 1,2 and 3 would need the WGs view as a whole, > > > other items > > > are more or less directed to certain individuals or the draft > > > editors. > > > Here is a list of issues: > > > > > > > > > 1) Remove the Appendix? Was there some comments about keeping > > > it, I think > > > someone liked it in Vienna? Or was it clear to remove it? > > > > > > > > > 2) Add a short review of SICAP, a protocol similar to BGRP? > > > (See Helena > > > Rute Sofia's email on July 16th 2003) (SICAP description July > > > 17th 2003) > > > > > > > > > 3) What about adding an RMD evaluation? Or any other text? > > > (see Georgios' > > > email on July 17 2003) (some discussions July 17th -> July > > > 22nd, Sep 5) > > > > > > > > > 4) Hannes to review the security section? A short summary and pointers > > > to his documents? > > > > > > > > > 5) Section 3.5 needed more proof, need to ask Ping to review > > > the text. > > > See John's email on July 7th 2003. > > > > > > > > > 6) Is there text that could be taken from Michael Thomas' draft on > > > mobility issues? > > > > > > > > > 7) Add a reference that shows how YESSIR is as good as > > > claimed in Section > > > 6.2.1 (Ping?) > > > > > > > > > 8) Add reference to Tenet (mail from Alejandro Avella Jul 12 2003): > > > (Page 20, Section 6.1) > > > Anindo Banerjea, Domenico Ferrari, Bruce A. Mah, Mark Moran, > > > Dinesh C. > > > Verma, Hui Zhang > > > The Tenet Real-Time Protocol Suite: Design, Implementation, and > > > Experiences (1996) > > > IEEE ACM Transactions on Networking > > > http://citeseer.nj.nec.com/banerjea96tenet.html > > > > > > > > > 9) Split the references into (only?) "Non-Normative" > > > > > > > > > 10) Add a summary > > > > > > > > > Regards, > > > Jukka > > > > > > > > > _______________________________________________ > > > nsis mailing list > > > nsis@ietf.org > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Fri Oct 17 08:05:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29105 for ; Fri, 17 Oct 2003 08:05:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AATLr-0000XK-Nw for nsis-archive@odin.ietf.org; Fri, 17 Oct 2003 08:05:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9HC53fB002043 for nsis-archive@odin.ietf.org; Fri, 17 Oct 2003 08:05:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AATLr-0000Wr-Hg; Fri, 17 Oct 2003 08:05:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AATLT-0000W8-Ju for nsis@optimus.ietf.org; Fri, 17 Oct 2003 08:04:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29081 for ; Fri, 17 Oct 2003 08:04:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AATLS-0002iK-00 for nsis@ietf.org; Fri, 17 Oct 2003 08:04:38 -0400 Received: from courier.cs.helsinki.fi ([128.214.9.1] helo=mail.cs.helsinki.fi) by ietf-mx with esmtp (Exim 4.12) id 1AATLR-0002iH-00 for nsis@ietf.org; Fri, 17 Oct 2003 08:04:38 -0400 Received: from mannersaari.cs.Helsinki.FI (mannersaari.cs.helsinki.fi [::ffff:128.214.11.173]) (IDENT: jmanner, TLS: TLSv1/SSLv3,168bits,DES-CBC3-SHA) by mail.cs.helsinki.fi with esmtp; Fri, 17 Oct 2003 15:04:37 +0300 Date: Fri, 17 Oct 2003 15:04:35 +0300 (EEST) From: Jukka MJ Manner To: Thanh Tra LUU cc: nsis@ietf.org Subject: Re: [NSIS] Next steps for the analysis document In-Reply-To: <005c01c394a5$8090e500$7907c289@pcluu> Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, The more I try (start) to understand protocols, the more I start to think that security is THE thing that most protocol designers just don't really consider and think that it is easy to do. I would almost claim that quite a few protocols would be rendered totally useless or would work very, very badly, if they were made secure. Thus, I tend to think that protocol specifications should concentrate first on making the initial design secure, and not think that security could be added later. Security must not be "an additional option if someone wants it", unless the protocol is meant for a tightly closed system that does not require security and everyone using the system is a "good guy". Regards, Jukka On Fri, 17 Oct 2003, Thanh Tra LUU wrote: > hi Jukka, > > I agree with you. However, it seems difficult to see all security aspects > when writing a document. I think it will be better if we (readers, or > someone are security experts) can send authors the feedback of security > when we see the security problems. After that, the authors can update their > documents. > > Best regards > > Nary Tra > > > > ----- Original Message ----- > From: "Jukka MJ Manner" > To: "Tschofenig Hannes" > Cc: > Sent: Friday, October 17, 2003 1:41 PM > Subject: RE: [NSIS] Next steps for the analysis document > > > > > > Hi Hannes, > > > > It is true that most protocols do not consider security at all or expect > > some weird things, or even rely on someone else to do security. At least > > some overall security section is needed, perhaps our dear Chair can > > provide feedback to your review. > > > > Cheers, > > Jukka > > > > On Fri, 17 Oct 2003, Tschofenig Hannes wrote: > > > > > hi jukka, > > > > > > i will re-read the document again to address the security issues. > > > i have once read all the described protocols with respect to security. > > > unfortunately, the security considerations in many of these protocols > is > > > lacking a useful level of detail. > > > > > > ciao > > > hannes > > > > > > > > > > -----Original Message----- > > > > From: Jukka MJ Manner [mailto:jmanner@cs.Helsinki.FI] > > > > Sent: Friday, October 17, 2003 1:23 PM > > > > To: nsis@ietf.org > > > > Subject: [NSIS] Next steps for the analysis document > > > > > > > > > > > > > > > > Hi all, > > > > > > > > I would need to make (hopefully final) changes to the > > > > Analysis draft. I'm > > > > trying to figure out what needs to be done. I would need the WG's view > > > > (yes, that means you, too) on what is missing (needs work) in > > > > the draft. > > > > At least issues 1,2 and 3 would need the WGs view as a whole, > > > > other items > > > > are more or less directed to certain individuals or the draft > > > > editors. > > > > Here is a list of issues: > > > > > > > > > > > > 1) Remove the Appendix? Was there some comments about keeping > > > > it, I think > > > > someone liked it in Vienna? Or was it clear to remove it? > > > > > > > > > > > > 2) Add a short review of SICAP, a protocol similar to BGRP? > > > > (See Helena > > > > Rute Sofia's email on July 16th 2003) (SICAP description July > > > > 17th 2003) > > > > > > > > > > > > 3) What about adding an RMD evaluation? Or any other text? > > > > (see Georgios' > > > > email on July 17 2003) (some discussions July 17th -> July > > > > 22nd, Sep 5) > > > > > > > > > > > > 4) Hannes to review the security section? A short summary and pointers > > > > to his documents? > > > > > > > > > > > > 5) Section 3.5 needed more proof, need to ask Ping to review > > > > the text. > > > > See John's email on July 7th 2003. > > > > > > > > > > > > 6) Is there text that could be taken from Michael Thomas' draft on > > > > mobility issues? > > > > > > > > > > > > 7) Add a reference that shows how YESSIR is as good as > > > > claimed in Section > > > > 6.2.1 (Ping?) > > > > > > > > > > > > 8) Add reference to Tenet (mail from Alejandro Avella Jul 12 2003): > > > > (Page 20, Section 6.1) > > > > Anindo Banerjea, Domenico Ferrari, Bruce A. Mah, Mark Moran, > > > > Dinesh C. > > > > Verma, Hui Zhang > > > > The Tenet Real-Time Protocol Suite: Design, Implementation, and > > > > Experiences (1996) > > > > IEEE ACM Transactions on Networking > > > > http://citeseer.nj.nec.com/banerjea96tenet.html > > > > > > > > > > > > 9) Split the references into (only?) "Non-Normative" > > > > > > > > > > > > 10) Add a summary > > > > > > > > > > > > Regards, > > > > Jukka > > > > > > > > > > > > _______________________________________________ > > > > nsis mailing list > > > > nsis@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > > > > > > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > > > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Fri Oct 17 08:16:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29358 for ; Fri, 17 Oct 2003 08:16:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AATWV-00018w-Ff for nsis-archive@odin.ietf.org; Fri, 17 Oct 2003 08:16:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9HCG3c2004353 for nsis-archive@odin.ietf.org; Fri, 17 Oct 2003 08:16:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AATWU-000185-4H; Fri, 17 Oct 2003 08:16:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AATVZ-000178-9o for nsis@optimus.ietf.org; Fri, 17 Oct 2003 08:15:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29335 for ; Fri, 17 Oct 2003 08:14:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AATVY-0002nk-00 for nsis@ietf.org; Fri, 17 Oct 2003 08:15:04 -0400 Received: from david.siemens.de ([192.35.17.14]) by ietf-mx with esmtp (Exim 4.12) id 1AATVX-0002nh-00 for nsis@ietf.org; Fri, 17 Oct 2003 08:15:03 -0400 Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by david.siemens.de (8.11.7/8.11.7) with ESMTP id h9HCF1k11540; Fri, 17 Oct 2003 14:15:01 +0200 (MEST) Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail1.siemens.de (8.11.7/8.11.7) with ESMTP id h9HCF0x14821; Fri, 17 Oct 2003 14:15:00 +0200 (MEST) Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2653.19) id <4DN1RKD2>; Fri, 17 Oct 2003 14:14:51 +0200 Message-ID: <2A8DB02E3018D411901B009027FD3A3F03BC02F3@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: "'Thanh Tra LUU'" , Jukka MJ Manner Cc: nsis@ietf.org Subject: RE: [NSIS] Next steps for the analysis document Date: Fri, 17 Oct 2003 14:14:54 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , hi nary, the analysis document does not have a security consideration section addressing the content of the draft. instead the security consideration section and some sections within the document touch the security of the protocols discussed in the document. for many of the protocols it was really difficult to figure out how a security solution could work. some protocols provide a one-line guidance on security. hence you can only speculate. at the helsinki interim meeting i have given some examples of protocols. you can find the slides attached to the meeting minutes. for rsvp things are difference and hence we were able to write an entire draft on this issue (btw, comments are still welcome). i think it is still useful to look at the protocols described in the document again and to verify what was said in the draft (particularly since some additional protocols will be added). i will not be able to provide "major" input within the next two weeks (since i have to incorporate changes into some other drafts) but we can discuss some of these issues at the next ietf (if someone is interested). ciao hannes > -----Original Message----- > From: Thanh Tra LUU [mailto:luu@enst.fr] > Sent: Friday, October 17, 2003 1:55 PM > To: Jukka MJ Manner > Cc: nsis@ietf.org > Subject: Re: [NSIS] Next steps for the analysis document > > > hi Jukka, > > I agree with you. However, it seems difficult to see all > security aspects > when writing a document. I think it will be better if we (readers, or > someone are security experts) can send authors the feedback > of security > when we see the security problems. After that, the authors > can update their > documents. > > Best regards > > Nary Tra > > > > ----- Original Message ----- > From: "Jukka MJ Manner" > To: "Tschofenig Hannes" > Cc: > Sent: Friday, October 17, 2003 1:41 PM > Subject: RE: [NSIS] Next steps for the analysis document > > > > > > Hi Hannes, > > > > It is true that most protocols do not consider security at > all or expect > > some weird things, or even rely on someone else to do > security. At least > > some overall security section is needed, perhaps our dear Chair can > > provide feedback to your review. > > > > Cheers, > > Jukka > > > > On Fri, 17 Oct 2003, Tschofenig Hannes wrote: > > > > > hi jukka, > > > > > > i will re-read the document again to address the security issues. > > > i have once read all the described protocols with respect > to security. > > > unfortunately, the security considerations in many of > these protocols > is > > > lacking a useful level of detail. > > > > > > ciao > > > hannes > > > > > > > > > > -----Original Message----- > > > > From: Jukka MJ Manner [mailto:jmanner@cs.Helsinki.FI] > > > > Sent: Friday, October 17, 2003 1:23 PM > > > > To: nsis@ietf.org > > > > Subject: [NSIS] Next steps for the analysis document > > > > > > > > > > > > > > > > Hi all, > > > > > > > > I would need to make (hopefully final) changes to the > > > > Analysis draft. I'm > > > > trying to figure out what needs to be done. I would > need the WG's view > > > > (yes, that means you, too) on what is missing (needs work) in > > > > the draft. > > > > At least issues 1,2 and 3 would need the WGs view as a whole, > > > > other items > > > > are more or less directed to certain individuals or the draft > > > > editors. > > > > Here is a list of issues: > > > > > > > > > > > > 1) Remove the Appendix? Was there some comments about keeping > > > > it, I think > > > > someone liked it in Vienna? Or was it clear to remove it? > > > > > > > > > > > > 2) Add a short review of SICAP, a protocol similar to BGRP? > > > > (See Helena > > > > Rute Sofia's email on July 16th 2003) (SICAP description July > > > > 17th 2003) > > > > > > > > > > > > 3) What about adding an RMD evaluation? Or any other text? > > > > (see Georgios' > > > > email on July 17 2003) (some discussions July 17th -> July > > > > 22nd, Sep 5) > > > > > > > > > > > > 4) Hannes to review the security section? A short > summary and pointers > > > > to his documents? > > > > > > > > > > > > 5) Section 3.5 needed more proof, need to ask Ping to review > > > > the text. > > > > See John's email on July 7th 2003. > > > > > > > > > > > > 6) Is there text that could be taken from Michael > Thomas' draft on > > > > mobility issues? > > > > > > > > > > > > 7) Add a reference that shows how YESSIR is as good as > > > > claimed in Section > > > > 6.2.1 (Ping?) > > > > > > > > > > > > 8) Add reference to Tenet (mail from Alejandro Avella > Jul 12 2003): > > > > (Page 20, Section 6.1) > > > > Anindo Banerjea, Domenico Ferrari, Bruce A. Mah, Mark Moran, > > > > Dinesh C. > > > > Verma, Hui Zhang > > > > The Tenet Real-Time Protocol Suite: Design, Implementation, and > > > > Experiences (1996) > > > > IEEE ACM Transactions on Networking > > > > http://citeseer.nj.nec.com/banerjea96tenet.html > > > > > > > > > > > > 9) Split the references into (only?) "Non-Normative" > > > > > > > > > > > > 10) Add a summary > > > > > > > > > > > > Regards, > > > > Jukka > > > > > > > > > > > > _______________________________________________ > > > > nsis mailing list > > > > nsis@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > > > > > > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Fri Oct 17 08:33:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29722 for ; Fri, 17 Oct 2003 08:33:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AATmz-000238-BC for nsis-archive@odin.ietf.org; Fri, 17 Oct 2003 08:33:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9HCX5cq007872 for nsis-archive@odin.ietf.org; Fri, 17 Oct 2003 08:33:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AATmv-00022r-Iw; Fri, 17 Oct 2003 08:33:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AATmJ-00022E-GY for nsis@optimus.ietf.org; Fri, 17 Oct 2003 08:32:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29716 for ; Fri, 17 Oct 2003 08:32:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AATmI-0002w2-00 for nsis@ietf.org; Fri, 17 Oct 2003 08:32:22 -0400 Received: from utrhcs.cs.utwente.nl ([130.89.10.247]) by ietf-mx with esmtp (Exim 4.12) id 1AATmH-0002vz-00 for nsis@ietf.org; Fri, 17 Oct 2003 08:32:21 -0400 Received: from utip105 (utip105.cs.utwente.nl [130.89.13.76]) by utrhcs.cs.utwente.nl (8.12.10/8.12.9) with SMTP id h9HCWBSd019167; Fri, 17 Oct 2003 14:32:11 +0200 (MET DST) Message-ID: <008401c394aa$b0e42a00$4c0d5982@dynamic.cs.utwente.nl> From: "Georgios Karagiannis" To: "Jukka MJ Manner" , References: Subject: Re: [NSIS] Next steps for the analysis document Date: Fri, 17 Oct 2003 14:32:12 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4922.1500 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4925.2800 Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Jukka Regarding point 3) we have had some discussions within the WG. Hopefully I have had provided the required information. Best regards, Georgios ----- Original Message ----- From: "Jukka MJ Manner" To: Sent: Friday, October 17, 2003 1:23 PM Subject: [NSIS] Next steps for the analysis document > > Hi all, > > I would need to make (hopefully final) changes to the Analysis draft. I'm > trying to figure out what needs to be done. I would need the WG's view > (yes, that means you, too) on what is missing (needs work) in the draft. > At least issues 1,2 and 3 would need the WGs view as a whole, other items > are more or less directed to certain individuals or the draft editors. > Here is a list of issues: > > > 1) Remove the Appendix? Was there some comments about keeping it, I think > someone liked it in Vienna? Or was it clear to remove it? > > > 2) Add a short review of SICAP, a protocol similar to BGRP? (See Helena > Rute Sofia's email on July 16th 2003) (SICAP description July 17th 2003) > > > 3) What about adding an RMD evaluation? Or any other text? (see Georgios' > email on July 17 2003) (some discussions July 17th -> July 22nd, Sep 5) > > > 4) Hannes to review the security section? A short summary and pointers > to his documents? > > > 5) Section 3.5 needed more proof, need to ask Ping to review the text. > See John's email on July 7th 2003. > > > 6) Is there text that could be taken from Michael Thomas' draft on > mobility issues? > > > 7) Add a reference that shows how YESSIR is as good as claimed in Section > 6.2.1 (Ping?) > > > 8) Add reference to Tenet (mail from Alejandro Avella Jul 12 2003): > (Page 20, Section 6.1) > Anindo Banerjea, Domenico Ferrari, Bruce A. Mah, Mark Moran, Dinesh C. > Verma, Hui Zhang > The Tenet Real-Time Protocol Suite: Design, Implementation, and > Experiences (1996) > IEEE ACM Transactions on Networking > http://citeseer.nj.nec.com/banerjea96tenet.html > > > 9) Split the references into (only?) "Non-Normative" > > > 10) Add a summary > > > Regards, > Jukka > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Fri Oct 17 08:47:22 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00057 for ; Fri, 17 Oct 2003 08:47:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAU0S-0002co-RW for nsis-archive@odin.ietf.org; Fri, 17 Oct 2003 08:47:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9HCl0UN010071 for nsis-archive@odin.ietf.org; Fri, 17 Oct 2003 08:47:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAU0S-0002cL-Jt; Fri, 17 Oct 2003 08:47:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAU00-0002bu-Hk for nsis@optimus.ietf.org; Fri, 17 Oct 2003 08:46:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00025 for ; Fri, 17 Oct 2003 08:46:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AATzz-00032x-00 for nsis@ietf.org; Fri, 17 Oct 2003 08:46:31 -0400 Received: from courier.cs.helsinki.fi ([128.214.9.1] helo=mail.cs.helsinki.fi) by ietf-mx with esmtp (Exim 4.12) id 1AATzy-00032u-00 for nsis@ietf.org; Fri, 17 Oct 2003 08:46:30 -0400 Received: from mannersaari.cs.Helsinki.FI (mannersaari.cs.helsinki.fi [::ffff:128.214.11.173]) (IDENT: jmanner, TLS: TLSv1/SSLv3,168bits,DES-CBC3-SHA) by mail.cs.helsinki.fi with esmtp; Fri, 17 Oct 2003 15:46:29 +0300 Date: Fri, 17 Oct 2003 15:46:29 +0300 (EEST) From: Jukka MJ Manner To: Georgios Karagiannis cc: nsis@ietf.org Subject: Re: [NSIS] Next steps for the analysis document In-Reply-To: <008401c394aa$b0e42a00$4c0d5982@dynamic.cs.utwente.nl> Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Georgios, I know there has been some discussions, that is why I put those pointers to some of them. I was still wondering whether people want to see the RMD stuff added, whether it makes the draft better by adding new insights, for example? Regards, Jukka On Fri, 17 Oct 2003, Georgios Karagiannis wrote: > Hi Jukka > > Regarding point 3) we have had some discussions within the WG. > Hopefully I have had provided the required information. > > Best regards, > Georgios > > > ----- Original Message ----- > From: "Jukka MJ Manner" > To: > Sent: Friday, October 17, 2003 1:23 PM > Subject: [NSIS] Next steps for the analysis document > > > > > > Hi all, > > > > I would need to make (hopefully final) changes to the Analysis draft. I'm > > trying to figure out what needs to be done. I would need the WG's view > > (yes, that means you, too) on what is missing (needs work) in the draft. > > At least issues 1,2 and 3 would need the WGs view as a whole, other items > > are more or less directed to certain individuals or the draft editors. > > Here is a list of issues: > > > > > > 1) Remove the Appendix? Was there some comments about keeping it, I think > > someone liked it in Vienna? Or was it clear to remove it? > > > > > > 2) Add a short review of SICAP, a protocol similar to BGRP? (See Helena > > Rute Sofia's email on July 16th 2003) (SICAP description July 17th 2003) > > > > > > 3) What about adding an RMD evaluation? Or any other text? (see Georgios' > > email on July 17 2003) (some discussions July 17th -> July 22nd, Sep 5) > > > > > > 4) Hannes to review the security section? A short summary and pointers > > to his documents? > > > > > > 5) Section 3.5 needed more proof, need to ask Ping to review the text. > > See John's email on July 7th 2003. > > > > > > 6) Is there text that could be taken from Michael Thomas' draft on > > mobility issues? > > > > > > 7) Add a reference that shows how YESSIR is as good as claimed in Section > > 6.2.1 (Ping?) > > > > > > 8) Add reference to Tenet (mail from Alejandro Avella Jul 12 2003): > > (Page 20, Section 6.1) > > Anindo Banerjea, Domenico Ferrari, Bruce A. Mah, Mark Moran, Dinesh C. > > Verma, Hui Zhang > > The Tenet Real-Time Protocol Suite: Design, Implementation, and > > Experiences (1996) > > IEEE ACM Transactions on Networking > > http://citeseer.nj.nec.com/banerjea96tenet.html > > > > > > 9) Split the references into (only?) "Non-Normative" > > > > > > 10) Add a summary > > > > > > Regards, > > Jukka > > > > > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > > > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Fri Oct 17 09:07:24 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00545 for ; Fri, 17 Oct 2003 09:07:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAUJr-0003GS-6s for nsis-archive@odin.ietf.org; Fri, 17 Oct 2003 09:07:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9HD73VL012528 for nsis-archive@odin.ietf.org; Fri, 17 Oct 2003 09:07:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAUJq-0003Fb-4B; Fri, 17 Oct 2003 09:07:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAUIr-0003EA-3K for nsis@optimus.ietf.org; Fri, 17 Oct 2003 09:06:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00506 for ; Fri, 17 Oct 2003 09:05:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAUIp-0003CC-00 for nsis@ietf.org; Fri, 17 Oct 2003 09:05:59 -0400 Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx with esmtp (Exim 4.12) id 1AAUIo-0003C9-00 for nsis@ietf.org; Fri, 17 Oct 2003 09:05:59 -0400 Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id h9HD5uoq015606; Fri, 17 Oct 2003 15:05:56 +0200 Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id <45JRALZ0>; Fri, 17 Oct 2003 15:06:34 +0200 Message-ID: From: =?iso-8859-1?Q?Attila_B=E1der_=28IJ/ETH=29?= To: Jukka MJ Manner , Georgios Karagiannis Cc: nsis@ietf.org Subject: RE: [NSIS] Next steps for the analysis document Date: Fri, 17 Oct 2003 15:05:50 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Hi Jukka, RMD is an example of stateless/reduced state operation mode discussed in QoS-NSLP draft, so, I think, it would be useful if it is mentioned in the analysis draft in this context. Best regards, Attila > -----Original Message----- > From: Jukka MJ Manner [mailto:jmanner@cs.Helsinki.FI] > Sent: Friday, October 17, 2003 2:46 PM > To: Georgios Karagiannis > Cc: nsis@ietf.org > Subject: Re: [NSIS] Next steps for the analysis document > > > > Hi Georgios, > > I know there has been some discussions, that is why I put > those pointers > to some of them. I was still wondering whether people want to > see the RMD > stuff added, whether it makes the draft better by adding new > insights, for > example? > > Regards, > Jukka > > On Fri, 17 Oct 2003, Georgios Karagiannis wrote: > > > Hi Jukka > > > > Regarding point 3) we have had some discussions within the WG. > > Hopefully I have had provided the required information. > > > > Best regards, > > Georgios > > > > > > ----- Original Message ----- > > From: "Jukka MJ Manner" > > To: > > Sent: Friday, October 17, 2003 1:23 PM > > Subject: [NSIS] Next steps for the analysis document > > > > > > > > > > Hi all, > > > > > > I would need to make (hopefully final) changes to the > Analysis draft. I'm > > > trying to figure out what needs to be done. I would need > the WG's view > > > (yes, that means you, too) on what is missing (needs > work) in the draft. > > > At least issues 1,2 and 3 would need the WGs view as a > whole, other items > > > are more or less directed to certain individuals or the > draft editors. > > > Here is a list of issues: > > > > > > > > > 1) Remove the Appendix? Was there some comments about > keeping it, I think > > > someone liked it in Vienna? Or was it clear to remove it? > > > > > > > > > 2) Add a short review of SICAP, a protocol similar to > BGRP? (See Helena > > > Rute Sofia's email on July 16th 2003) (SICAP description > July 17th 2003) > > > > > > > > > 3) What about adding an RMD evaluation? Or any other > text? (see Georgios' > > > email on July 17 2003) (some discussions July 17th -> > July 22nd, Sep 5) > > > > > > > > > 4) Hannes to review the security section? A short summary > and pointers > > > to his documents? > > > > > > > > > 5) Section 3.5 needed more proof, need to ask Ping to > review the text. > > > See John's email on July 7th 2003. > > > > > > > > > 6) Is there text that could be taken from Michael Thomas' draft on > > > mobility issues? > > > > > > > > > 7) Add a reference that shows how YESSIR is as good as > claimed in Section > > > 6.2.1 (Ping?) > > > > > > > > > 8) Add reference to Tenet (mail from Alejandro Avella Jul > 12 2003): > > > (Page 20, Section 6.1) > > > Anindo Banerjea, Domenico Ferrari, Bruce A. Mah, Mark > Moran, Dinesh C. > > > Verma, Hui Zhang > > > The Tenet Real-Time Protocol Suite: Design, Implementation, and > > > Experiences (1996) > > > IEEE ACM Transactions on Networking > > > http://citeseer.nj.nec.com/banerjea96tenet.html > > > > > > > > > 9) Split the references into (only?) "Non-Normative" > > > > > > > > > 10) Add a summary > > > > > > > > > Regards, > > > Jukka > > > > > > > > > _______________________________________________ > > > nsis mailing list > > > nsis@ietf.org > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Fri Oct 17 09:23:22 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01122 for ; Fri, 17 Oct 2003 09:23:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAUZJ-0004Dj-MZ for nsis-archive@odin.ietf.org; Fri, 17 Oct 2003 09:23:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9HDN1r4016205 for nsis-archive@odin.ietf.org; Fri, 17 Oct 2003 09:23:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAUZJ-0004DG-Dy; Fri, 17 Oct 2003 09:23:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAUYj-00046k-ST for nsis@optimus.ietf.org; Fri, 17 Oct 2003 09:22:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01069 for ; Fri, 17 Oct 2003 09:22:15 -0400 (EDT) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAUYi-0003JU-00 for nsis@ietf.org; Fri, 17 Oct 2003 09:22:24 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AAUYg-0003Ig-00 for nsis@ietf.org; Fri, 17 Oct 2003 09:22:22 -0400 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id h9HDLnX02584 for ; Fri, 17 Oct 2003 16:21:51 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 17 Oct 2003 16:21:48 +0300 Received: from esebe011.NOE.Nokia.com ([172.21.138.50]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 17 Oct 2003 16:21:48 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe011.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 17 Oct 2003 16:21:47 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] Next steps for the analysis document Date: Fri, 17 Oct 2003 16:21:46 +0300 Message-ID: Thread-Topic: [NSIS] Next steps for the analysis document Thread-Index: AcOUo+xL674F5Z0qSZyscjcD90X6YgADWrYg To: , Cc: X-OriginalArrivalTime: 17 Oct 2003 13:21:47.0731 (UTC) FILETIME=[9DFE3230:01C394B1] Content-Transfer-Encoding: quoted-printable Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi Jukka, > It is true that most protocols do not consider security at all or = expect=20 > some weird things, or even rely on someone else to do security. At = least=20 > some overall security section is needed, perhaps our dear Chair can=20 > provide feedback to your review. I don't think that we can do an exhaustive review of the security of the protocols. However, if there are any security sections or references, they should be explicitly cited. If no security = considerations can be found, than that needs to be explicitly stated. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Fri Oct 17 09:33:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01593 for ; Fri, 17 Oct 2003 09:33:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAUiz-0004rR-OZ for nsis-archive@odin.ietf.org; Fri, 17 Oct 2003 09:33:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9HDX1iE018666 for nsis-archive@odin.ietf.org; Fri, 17 Oct 2003 09:33:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAUiz-0004qx-4Z; Fri, 17 Oct 2003 09:33:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAUi6-0004pw-2K for nsis@optimus.ietf.org; Fri, 17 Oct 2003 09:32:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01548 for ; Fri, 17 Oct 2003 09:31:56 -0400 (EDT) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAUi4-0003Px-00 for nsis@ietf.org; Fri, 17 Oct 2003 09:32:04 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AAUi3-0003Pu-00 for nsis@ietf.org; Fri, 17 Oct 2003 09:32:03 -0400 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id h9HDW2d27348 for ; Fri, 17 Oct 2003 16:32:02 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 17 Oct 2003 16:32:02 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 17 Oct 2003 16:32:02 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe019.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 17 Oct 2003 16:32:02 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] Next steps for the analysis document Date: Fri, 17 Oct 2003 16:32:01 +0300 Message-ID: Thread-Topic: [NSIS] Next steps for the analysis document Thread-Index: AcOUqw9ubMPzEkHAT3C0ZPuA7AScOQAB5hDg To: , X-OriginalArrivalTime: 17 Oct 2003 13:32:02.0270 (UTC) FILETIME=[0C4967E0:01C394B3] Content-Transfer-Encoding: quoted-printable Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi all, > 2) Add a short review of SICAP, a protocol similar to BGRP? (See = Helena > Rute Sofia's email on July 16th 2003) (SICAP description July 17th = 2003) >=20 > 3) What about adding an RMD evaluation? Or any other text? (see = Georgios' > email on July 17 2003) (some discussions July 17th -> July 22nd, Sep = 5) I prefer to have some people, other than the backers of these protocols, = to=20 speak up on behalf of their inclusion into the analysis document. If = noone=20 else in the WG is interested in these protocols, then it seems that = there is no interest in these protocols. thanks, John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Fri Oct 17 09:44:21 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01904 for ; Fri, 17 Oct 2003 09:44:21 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAUtd-0005bV-BZ for nsis-archive@odin.ietf.org; Fri, 17 Oct 2003 09:44:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9HDi1RK021524 for nsis-archive@odin.ietf.org; Fri, 17 Oct 2003 09:44:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAUtc-0005b3-Qr; Fri, 17 Oct 2003 09:44:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAUtY-0005as-Uf for nsis@optimus.ietf.org; Fri, 17 Oct 2003 09:43:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01887 for ; Fri, 17 Oct 2003 09:43:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAUtX-0003Xb-00 for nsis@ietf.org; Fri, 17 Oct 2003 09:43:55 -0400 Received: from utrhcs.cs.utwente.nl ([130.89.10.247]) by ietf-mx with esmtp (Exim 4.12) id 1AAUtW-0003XY-00 for nsis@ietf.org; Fri, 17 Oct 2003 09:43:54 -0400 Received: from utip105 (utip105.cs.utwente.nl [130.89.13.76]) by utrhcs.cs.utwente.nl (8.12.10/8.12.9) with SMTP id h9HDhnSd022509; Fri, 17 Oct 2003 15:43:49 +0200 (MET DST) Message-ID: <009f01c394b4$b32311f0$4c0d5982@dynamic.cs.utwente.nl> From: "Georgios Karagiannis" To: , , References: Subject: Re: [NSIS] Next steps for the analysis document Date: Fri, 17 Oct 2003 15:43:51 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4922.1500 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4925.2800 Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi John We have had discussed the provided RMD text within the WG. There was also a consensus on this afterwards. Thus for RMD, your request is fulfilled. Best regards, Georgios ----- Original Message ----- From: To: ; Sent: Friday, October 17, 2003 3:32 PM Subject: RE: [NSIS] Next steps for the analysis document > Hi all, > > > 2) Add a short review of SICAP, a protocol similar to BGRP? (See Helena > > Rute Sofia's email on July 16th 2003) (SICAP description July 17th 2003) > > > > 3) What about adding an RMD evaluation? Or any other text? (see Georgios' > > email on July 17 2003) (some discussions July 17th -> July 22nd, Sep 5) > > I prefer to have some people, other than the backers of these protocols, to > speak up on behalf of their inclusion into the analysis document. If noone > else in the WG is interested in these protocols, then it seems that there > is no interest in these protocols. > > thanks, > John > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Fri Oct 17 10:12:23 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03534 for ; Fri, 17 Oct 2003 10:12:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAVKl-0007BO-I5 for nsis-archive@odin.ietf.org; Fri, 17 Oct 2003 10:12:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9HEC3aC027604 for nsis-archive@odin.ietf.org; Fri, 17 Oct 2003 10:12:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAVKk-0007Al-3M; Fri, 17 Oct 2003 10:12:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAVJu-00079m-1F for nsis@optimus.ietf.org; Fri, 17 Oct 2003 10:11:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03376 for ; Fri, 17 Oct 2003 10:10:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAVJr-0003lE-00 for nsis@ietf.org; Fri, 17 Oct 2003 10:11:07 -0400 Received: from infres.enst.fr ([137.194.192.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAVJr-0003l9-00 for nsis@ietf.org; Fri, 17 Oct 2003 10:11:07 -0400 Received: from pcluu (pcluu.enst.fr [137.194.7.121]) by infres.enst.fr (Postfix) with SMTP id DA3D71930; Fri, 17 Oct 2003 16:11:04 +0200 (MEST) Message-ID: <00c601c394b8$ba316b00$7907c289@pcluu> From: "Thanh Tra LUU" To: "Georgios Karagiannis" , Cc: References: <009f01c394b4$b32311f0$4c0d5982@dynamic.cs.utwente.nl> Subject: Re: [NSIS] Next steps for the analysis document Date: Fri, 17 Oct 2003 16:12:40 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit hi Geogios, I am really interested in this draft. For me, it is the first one which proposes a complete and concrete stateless signaling application in the NSIS WG. Moreover, the QoS-NSLP is the "most important" application in NSIS. Nary Tra ENST, Paris ----- Original Message ----- From: "Georgios Karagiannis" To: ; ; Sent: Friday, October 17, 2003 3:43 PM Subject: Re: [NSIS] Next steps for the analysis document > Hi John > > We have had discussed the provided RMD text within the WG. > There was also a consensus on this afterwards. > Thus for RMD, your request is fulfilled. > > Best regards, > Georgios > > > ----- Original Message ----- > From: > To: ; > Sent: Friday, October 17, 2003 3:32 PM > Subject: RE: [NSIS] Next steps for the analysis document > > > > Hi all, > > > > > 2) Add a short review of SICAP, a protocol similar to BGRP? (See Helena > > > Rute Sofia's email on July 16th 2003) (SICAP description July 17th 2003) > > > > > > 3) What about adding an RMD evaluation? Or any other text? (see > Georgios' > > > email on July 17 2003) (some discussions July 17th -> July 22nd, Sep 5) > > > > I prefer to have some people, other than the backers of these protocols, > to > > speak up on behalf of their inclusion into the analysis document. If > noone > > else in the WG is interested in these protocols, then it seems that there > > is no interest in these protocols. > > > > thanks, > > John > > > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Fri Oct 17 22:00:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03279 for ; Fri, 17 Oct 2003 22:00:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAgNz-0007Ag-Ku for nsis-archive@odin.ietf.org; Fri, 17 Oct 2003 22:00:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9I207Rq027529 for nsis-archive@odin.ietf.org; Fri, 17 Oct 2003 22:00:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAgNy-00079h-0X; Fri, 17 Oct 2003 22:00:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAgNn-00078V-VX for nsis@optimus.ietf.org; Fri, 17 Oct 2003 21:59:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03230 for ; Fri, 17 Oct 2003 21:59:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAgNk-0004Eb-00 for nsis@ietf.org; Fri, 17 Oct 2003 21:59:52 -0400 Received: from rsys002a.roke.co.uk ([193.118.192.251]) by ietf-mx with esmtp (Exim 4.12) id 1AAgNk-0004EY-00 for nsis@ietf.org; Fri, 17 Oct 2003 21:59:52 -0400 Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Sat, 18 Oct 2003 02:59:17 +0100 Message-ID: From: "Hancock, Robert" To: john.loughney@nokia.com, jmanner@cs.Helsinki.FI, nsis@ietf.org Subject: RE: [NSIS] Next steps for the analysis document Date: Sat, 18 Oct 2003 02:59:25 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , hi all, personally, i would be very interested to see a summary of the sort of requirements and tradeoffs that people have taken into account in building protocols that support inter-domain aggregation of some sort (which is basically BGRP and SICAP, AFAIK). since both these protocols are somewhat experimental, i would find a high-level comparison with commonalities and differences more enlightening than a detailed description of one or the other. i won't go so far as to say that understading RFC3175 changed my life, but it was certainly an interesting experience. i would expect the interdomain case to be likewise. such a comparison is non-trivial work, of course. it may be that a reference to the appropriate papers covers most of the ground. r. > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > Sent: Friday, October 17, 2003 14:32 > To: jmanner@cs.Helsinki.FI; nsis@ietf.org > Subject: RE: [NSIS] Next steps for the analysis document > > > Hi all, > > > 2) Add a short review of SICAP, a protocol similar to BGRP? > (See Helena > > Rute Sofia's email on July 16th 2003) (SICAP description > July 17th 2003) > > > > 3) What about adding an RMD evaluation? Or any other text? > (see Georgios' > > email on July 17 2003) (some discussions July 17th -> July > 22nd, Sep 5) > > I prefer to have some people, other than the backers of these > protocols, to > speak up on behalf of their inclusion into the analysis > document. If noone > else in the WG is interested in these protocols, then it > seems that there > is no interest in these protocols. > > thanks, > John > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Sun Oct 19 06:28:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04928 for ; Sun, 19 Oct 2003 06:28:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABAnA-0005rh-Qt for nsis-archive@odin.ietf.org; Sun, 19 Oct 2003 06:28:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9JAS8L0022512 for nsis-archive@odin.ietf.org; Sun, 19 Oct 2003 06:28:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABAn3-0005q8-Nu; Sun, 19 Oct 2003 06:28:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABAmA-0005iQ-9L for nsis@optimus.ietf.org; Sun, 19 Oct 2003 06:27:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04905 for ; Sun, 19 Oct 2003 06:26:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABAm6-0004JU-00 for nsis@ietf.org; Sun, 19 Oct 2003 06:27:02 -0400 Received: from goliath.siemens.de ([192.35.17.28]) by ietf-mx with esmtp (Exim 4.12) id 1ABAm5-0004JR-00 for nsis@ietf.org; Sun, 19 Oct 2003 06:27:01 -0400 Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by goliath.siemens.de (8.11.7/8.11.7) with ESMTP id h9JAQw210628; Sun, 19 Oct 2003 12:26:58 +0200 (MEST) Received: from joe ([139.25.62.15]) by mail2.siemens.de (8.11.7/8.11.7) with ESMTP id h9JAQvN16180; Sun, 19 Oct 2003 12:26:57 +0200 (MEST) From: "Hannes Tschofenig" To: "'Geib, Ruediger'" , "Hannes.Tschofenig@siemens.com"@mail2.siemens.de Cc: Subject: RE: [NSIS] Reliability and Security Date: Sun, 19 Oct 2003 12:26:22 +0200 Message-ID: <000a01c3962b$71b47d80$010aa8c0@joe> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal In-Reply-To: <9F8582E37B2EE5498E76392AEDDCD3FE03DBB646@G8PQD.blf01.telekom.de> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: quoted-printable Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable hi ruediger,=20 sorry for the late resonse.=20 > Hi Hannes, >=20 > if I understood you right, here you address the=20 > issue of adjacent NTLP nodes both supporting the=20 > same NSLP. It would of course be great if in=20 > this case NSLP would not need to run security=20 > features already provided by NTLP. you are fully right with your observation. i argue that this is the = default case at=20 trust boundaries. typically would you place a firewall at a trust = boundary and the=20 same is true for qos nodes (they first nodes start the edge and not in = the middle of=20 the network).=20 based on rsvp and the two security mechanisms offered there (rsvp = integrity object and the user identity representation) i observed that it is very useful to combine the two mechanisms e.g. windows 2000 uses kerberos for user identity representation (inside the=20 policy_data object and reuses the key for the integrity object. this = make simply sense.=20 >=20 > This requires NTLP to be aware of NSLP adjacencies=20 > and required protection as you describe.=20 >=20 > If this doesn't require complicated specification,=20 > it may be a useful feature. >=20 > Regards, R=FCdiger ciao hannes >=20 > |-----Original Message----- > |From: Hannes Tschofenig [mailto:Hannes.Tschofenig@siemens.com] > |Sent: Friday, October 03, 2003 6:14 PM > |To: Geib, R=FCdiger > |Cc: nsis@ietf.org > |Subject: RE: [NSIS] Reliability and Security > | > | > |hi ruediger, > | > |thank you for your reponse. > |=20 > |i see two basic approaches: > |=20 > |a) the ntlp does not contain a discovery procedure which > |allows to learn the next ntlp node which supports nslp X.=20 > |=20 > |b) the ntlp supports such a discover procedure. > |=20 > |in case (a) you can never be sure that a node implementing > |nslp X has access to authentication information (since=20 > |another nslp could be somewhere in the middle). in this case=20 > |you would have to do a discovery at the nslp layer to learn=20 > |the next nslp aware node to (possibly) secure nslp messages=20 > |between these two nodes (if necessary).=20 > | > |in case of (b) you would know that the next node you are > |addressing is actually a node which supports nslp X.=20 > | > |from a security point of view i have the following impression: > |=20 > |- you need to provide some security at the ntlp layer. > |- you need to provide some security at the nslp layer > |at the nslp additional security protection should be done=20 > |only for certain objects if there is a good reason (e.g. some=20 > |reasons have been described in the nat/firewall case).=20 > |- but if you have a configuration like the one described in=20 > |figure 1 then you might not want to secure messages at the=20 > |ntlp and at the nslp (particularly if this is the default=20 > |signaling case). > |i am not saying that performance should be considered first=20 > |but it should > |also be considered.=20 > |=20 > | +------+ +------+ > | | NE | | NE | > | |+----+| |+----+| > | ||NSLP|| NSLP Security ||NSLP|| > | || 1 || - - - - - - - - - - - - - || 1 || > | |+----+| |+----+| > | | || | | || | > | |+----+| NTLP Security |+----+| > | = =3D=3D=3D=3D||NTLP||=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D||NTLP||=3D=3D=3D=3D > | |+----+| |+----+| > | +------+ +------+ > | figure 1: nslp & ntlp security > | > |thanks again, ruediger, for pointing to the issues. i will > |try to write a short summary on the different options we have.=20 > |=20 > |ciao > |hannes > |>=20 > |=20 > |> >=20 > |> > Hannes, > |> >=20 > |> >=20 > |> > What are the options we have? > |> >=20 > |> > - NTLP and NSLP security are combined. This would result=20 > |> > in chains of trust. Complex. > |> > - NTLP has no security, security is done by NSLP. Bad idea,=20 > |> > DoS attacks should be inhibited at the lowest possible=20 > |> > level. > |> > - NTLP and NSLP have separated security mechanisms. Not very=20 > |> > nice if operators must locate errors. If possible,=20 > |> > separate instances of the same security mechanism. > |> > - If you look at the example I've added below, NSLP may=20 > |> > benefit from chains of trust. Is there a smart way of=20 > |> > organising them? > |> > - We'll have to agree which protection is required at what=20 > |> > level (I'm e.g favouring NTLP with authentication only). > |> > - There may be more options. Let's try to classify solutions=20 > |> > in terms of security, complexity and scaleability. > |> >=20 > |> > The WG must take decisions and opinions will be split. > |> > But I think it's time to make some progress on the security > |> > issue. > |> >=20 > |> > Regards, R=FCdiger > |> >=20 > |> >=20 > |> > |for security (and in particular for security association > |> > |establishment) the following issues are of importance: > |> > | > |> > |- node A has to learn that a security association has to be > |> > | established to some node C. > |> > | node A and C support NSLP X; node B only NSLP Y > |> > | how and when is this information obtained? > |> >=20 > |> > wouldn't your example have to be extended to nodes X, > |> > Y and Z all support NSLP A and peer in the order shown. The are=20 > |> > separated by an unknown number of NTLP hops. In some=20 > cases, it may=20 > |> > be desireable for NSLP Z to directly signal to NSLP X. > |> >=20 > |> > |- at which layer are messages protected? (ntlp/nslp) > |> > | > |> > |we have seen a number of protocol proposals in the=20 > past. there it=20 > |> > |can easily be seen that differences exist which have an=20 > impact on=20 > |> > |security. it is important to make the default mode of operation=20 > |> > |very clear and precise. > |> > | > |> > |ciao > |> > |hannes > |> >=20 > |> > _______________________________________________ > |> > nsis mailing list > |> > nsis@ietf.org > |> > https://www1.ietf.org/mailman/listinfo/nsis > |> >=20 > |>=20 > | >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Mon Oct 20 07:34:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22018 for ; Mon, 20 Oct 2003 07:34:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABYIb-0003JU-QX for nsis-archive@odin.ietf.org; Mon, 20 Oct 2003 07:34:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9KBY9Uc012723 for nsis-archive@odin.ietf.org; Mon, 20 Oct 2003 07:34:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABYIT-0003HB-WB; Mon, 20 Oct 2003 07:34:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABYIC-0003Dq-Sa for nsis@optimus.ietf.org; Mon, 20 Oct 2003 07:33:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21996 for ; Mon, 20 Oct 2003 07:33:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABYIA-00073j-00 for nsis@ietf.org; Mon, 20 Oct 2003 07:33:42 -0400 Received: from lmr1.uibk.ac.at ([138.232.1.142] helo=smtp.uibk.ac.at) by ietf-mx with esmtp (Exim 4.12) id 1ABYI9-00073I-00 for nsis@ietf.org; Mon, 20 Oct 2003 07:33:41 -0400 Received: from lap10-c703.uibk.ac.at (lap10-c703.uibk.ac.at [138.232.65.57]) by smtp.uibk.ac.at (8.12.10/8.12.9/F1) with ESMTP id h9KBX3If029875 for ; Mon, 20 Oct 2003 13:33:04 +0200 Subject: Re: [NSIS] Next steps for the analysis document From: Michael Welzl To: nsis@ietf.org In-Reply-To: References: Content-Type: text/plain Organization: University of Innsbruck Message-Id: <1066649510.20014.55.camel@lap10-c703.uibk.ac.at> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) Date: 20 Oct 2003 13:31:50 +0200 Content-Transfer-Encoding: 7bit X-Spam-Score: -6.4 () IN_REP_TO,RCV_UIBK,REFERENCES,USER_AGENT_XIMIAN X-Scanned-By: MIMEDefang 2.35 at uibk.ac.at Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi all, I have a request with regard to this document. There's this abstract about my own work: Michael Welzl organized a special session "ABR to the Internet" in SCI 2001, and gathered some inputs for requesting an "ABR to the Internet" BOF in IETF#51, which was intended to introduce explicit rate feedback related mechanisms for the Internet (e2e, edge2edge) but failed because of "missing community interest" (http://www.tk.uni-linz.ac.at/~michael/abr-internet/). Please remove this outdated URL. It would be great if you could change the paragraph as follows: Michael Welzl organized a special session "ABR to the Internet" in SCI 2001, and gathered some inputs for requesting an "ABR to the Internet" BOF in IETF#51, which was intended to introduce explicit rate feedback related mechanisms for the Internet (e2e, edge2edge) but failed because of "missing community interest". His continued efforts are documented at http://www.welzl.at/ptp. I still put effort into my protocol, which _IS_ a signaling protocol that somehow relates to QoS, but it is more closely related to ABR-like ("performance") signaling. I have been approached several times by colleagues who recommended to propose my work in NSIS - however, as PTP does not set up state of any kind but only retrieves performance parameters, I don't think that it fits in the NSIS framework. I think it is worth mentioning, though, and this update would just be all right. Best regards, Michael _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Mon Oct 20 08:05:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22808 for ; Mon, 20 Oct 2003 08:05:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABYmV-0002qD-Ta for nsis-archive@odin.ietf.org; Mon, 20 Oct 2003 08:05:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9KC53Ui010905 for nsis-archive@odin.ietf.org; Mon, 20 Oct 2003 08:05:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABYmV-0002pl-0D; Mon, 20 Oct 2003 08:05:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABYll-0002St-3Q for nsis@optimus.ietf.org; Mon, 20 Oct 2003 08:04:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22778 for ; Mon, 20 Oct 2003 08:04:08 -0400 (EDT) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABYlj-0007HR-00 for nsis@ietf.org; Mon, 20 Oct 2003 08:04:15 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1ABYli-0007Gs-00 for nsis@ietf.org; Mon, 20 Oct 2003 08:04:15 -0400 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id h9KC3Hd27812 for ; Mon, 20 Oct 2003 15:03:17 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Mon, 20 Oct 2003 15:03:00 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 20 Oct 2003 15:02:31 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 20 Oct 2003 15:02:22 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Date: Mon, 20 Oct 2003 15:02:22 +0300 Message-ID: Thread-Topic: [NSIS] Next steps for the analysis document Thread-Index: AcOW/i2GwrqZirfUQ7qf8cAzN3eXfwAA7Y4A To: X-OriginalArrivalTime: 20 Oct 2003 12:02:22.0813 (UTC) FILETIME=[051EA8D0:01C39702] Content-Transfer-Encoding: quoted-printable Subject: [NSIS] Call for Agenda items for the IETF meeting in MPLS Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi all, If you have an agenda item for the AAA WG meeting at IETF 58, please = send it to me. We have 2 slots. thanks, John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Mon Oct 20 08:12:24 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23009 for ; Mon, 20 Oct 2003 08:12:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABYtG-00051X-SL for nsis-archive@odin.ietf.org; Mon, 20 Oct 2003 08:12:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9KCC2o4019277 for nsis-archive@odin.ietf.org; Mon, 20 Oct 2003 08:12:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABYtG-00050Z-6U; Mon, 20 Oct 2003 08:12:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABYsS-0004iC-5I for nsis@optimus.ietf.org; Mon, 20 Oct 2003 08:11:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22984 for ; Mon, 20 Oct 2003 08:11:03 -0400 (EDT) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABYsR-0007L6-00 for nsis@ietf.org; Mon, 20 Oct 2003 08:11:11 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1ABYsQ-0007L2-00 for nsis@ietf.org; Mon, 20 Oct 2003 08:11:10 -0400 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id h9KCApd07900 for ; Mon, 20 Oct 2003 15:10:51 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Mon, 20 Oct 2003 15:10:50 +0300 Received: from esebe002.NOE.Nokia.com ([172.21.138.17]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 20 Oct 2003 15:10:49 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 20 Oct 2003 15:10:49 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Date: Mon, 20 Oct 2003 15:10:49 +0300 Message-ID: Thread-Topic: [NSIS] Next steps for the analysis document Thread-Index: AcOW/i2GwrqZirfUQ7qf8cAzN3eXfwAA7Y4AAABNH0A= To: X-OriginalArrivalTime: 20 Oct 2003 12:10:49.0777 (UTC) FILETIME=[334B3A10:01C39703] Content-Transfer-Encoding: quoted-printable Subject: [NSIS] RESEND: Call for Agenda items for the IETF meeting in Minneapolis Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi all, I'll try again!=20 If you have an agenda item for the NSIS WG meeting at IETF 58,=20 please send it to me. We have 2 slots. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Mon Oct 20 15:46:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22584 for ; Mon, 20 Oct 2003 15:46:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABfyi-00021T-B4 for nsis-archive@odin.ietf.org; Mon, 20 Oct 2003 15:46:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9KJk8DO007774 for nsis-archive@odin.ietf.org; Mon, 20 Oct 2003 15:46:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABfyc-0001zG-Nv; Mon, 20 Oct 2003 15:46:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABfxy-0001mL-0h for nsis@optimus.ietf.org; Mon, 20 Oct 2003 15:45:22 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22144; Mon, 20 Oct 2003 15:45:12 -0400 (EDT) Message-Id: <200310201945.PAA22144@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: nsis@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Mon, 20 Oct 2003 15:45:12 -0400 Subject: [NSIS] I-D ACTION:draft-ietf-nsis-nslp-natfw-00.txt Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , --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 : A NAT/Firewall NSIS Signaling Layer Protocol (NSLP) Author(s) : M. Stiemerling, et. al. Filename : draft-ietf-nsis-nslp-natfw-00.txt Pages : 83 Date : 2003-10-20 This draft describes scenarios, problems and solutions for path-coupled Network Address Translator and Firewall signaling. This is one of the two NSIS Signaling Layer Protocols (NSLPs) the working group will address during its work. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nsis-nslp-natfw-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-nsis-nslp-natfw-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-nsis-nslp-natfw-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-10-20145303.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nsis-nslp-natfw-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nsis-nslp-natfw-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-20145303.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Oct 21 08:46:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15920 for ; Tue, 21 Oct 2003 08:46:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABvtq-0007Op-Aw for nsis-archive@odin.ietf.org; Tue, 21 Oct 2003 08:46:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9LCkA7f028438 for nsis-archive@odin.ietf.org; Tue, 21 Oct 2003 08:46:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABvti-0007NC-1w; Tue, 21 Oct 2003 08:46:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABvso-00077m-4q for nsis@optimus.ietf.org; Tue, 21 Oct 2003 08:45:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15876 for ; Tue, 21 Oct 2003 08:44:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABvsm-00037o-00 for nsis@ietf.org; Tue, 21 Oct 2003 08:45:04 -0400 Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81]) by ietf-mx with esmtp (Exim 4.12) id 1ABvsl-00037j-00 for nsis@ietf.org; Tue, 21 Oct 2003 08:45:04 -0400 Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5] helo=irams1.ira.uka.de) by iramx2.ira.uni-karlsruhe.de with esmtp (Exim 3.30 #10 (Debian)) id 1ABvsd-0000Gw-00; Tue, 21 Oct 2003 14:44:55 +0200 Received: from i72ms1.tm.uni-karlsruhe.de ([141.3.70.16] helo=smtp.ipv6.tm.uni-karlsruhe.de ident=8) by irams1.ira.uka.de with esmtp (Exim 3.30 #7 (Debian)) id 1ABvsd-0002Bv-00; Tue, 21 Oct 2003 14:44:55 +0200 Received: from vorta.ipv6.tm.uni-karlsruhe.de ([3ffe:400:20:6:2e0:29ff:fe3e:c87] ident=mail) by smtp.ipv6.tm.uni-karlsruhe.de with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.12) id 1ABvsc-0002Bq-00; Tue, 21 Oct 2003 14:44:54 +0200 Received: from localhost ([::1] helo=vorta.ipv6.tm.uni-karlsruhe.de ident=bless) by vorta.ipv6.tm.uni-karlsruhe.de with smtp (Exim 4.05) id 1ABvsc-0007JX-00; Tue, 21 Oct 2003 14:44:54 +0200 Date: Tue, 21 Oct 2003 14:44:53 +0200 From: Roland Bless To: "Hancock, Robert" Cc: john.loughney@nokia.com, jmanner@cs.Helsinki.FI, nsis@ietf.org Subject: Re: [NSIS] Next steps for the analysis document Message-Id: <20031021144453.1373fc72.bless@tm.uka.de> In-Reply-To: References: Organization: Institute of Telematics, University of Karlsruhe X-Mailer: Sylpheed version 0.9.3claws (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Robert, > personally, i would be very interested to see a summary of the > sort of requirements and tradeoffs that people have taken into > account in building protocols that support inter-domain > aggregation of some sort (which is basically BGRP and SICAP, > AFAIK). since both these protocols are somewhat experimental, > i would find a high-level comparison with commonalities and differences > more enlightening than a detailed description of one or the other. This sounds reasonable. Inter-domain aggregation is not easy but IMHO important, and, as I understood one of the early NSIS charters, inter-domain signaling was one of the major missing pieces. I also did some research in this area (dynamic hierarchical reservation aggregation at AS level, similar to SICAP but even more flexible). Though this is surely experimental work (so far simulated in a real AS topology of 5500 ASes) it may give some hints to problems and solutions in inter-domain aggregation issues. The signaling protocol uses optimized signaling procedures for aggregate establishment and adaptation in order to reduce the overall signaling/reservation setup latency. Thus, the signaling protocol could be designed to provide optimized support for aggregation. > i won't go so far as to say that understading RFC3175 changed > my life, but it was certainly an interesting experience. > i would expect the interdomain case to be likewise. Definitely. > such a comparison is non-trivial work, of course. it may be > that a reference to the appropriate papers covers most of the > ground. Regards, Roland _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Oct 21 09:38:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17065 for ; Tue, 21 Oct 2003 09:38:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABwi3-0004js-Ah for nsis-archive@odin.ietf.org; Tue, 21 Oct 2003 09:38:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9LDc3sK018198 for nsis-archive@odin.ietf.org; Tue, 21 Oct 2003 09:38:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABwi2-0004j7-At; Tue, 21 Oct 2003 09:38:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABwhK-0004K4-8E for nsis@optimus.ietf.org; Tue, 21 Oct 2003 09:37:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16986 for ; Tue, 21 Oct 2003 09:37:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABwhG-0003RT-00 for nsis@ietf.org; Tue, 21 Oct 2003 09:37:14 -0400 Received: from saturno.fccn.pt ([193.136.7.107]) by ietf-mx with smtp (Exim 4.12) id 1ABwhG-0003R9-00 for nsis@ietf.org; Tue, 21 Oct 2003 09:37:14 -0400 Received: (qmail 39290 invoked from network); 21 Oct 2003 13:36:41 -0000 Received: (ofmipd unknown); 21 Oct 2003 13:36:19 -0000 Date: 21 Oct 2003 14:36:54 +0000 Message-ID: <3F954486.3020609@seas.upenn.edu> From: "Rute Sofia" To: "Hancock, Robert" Cc: john.loughney@nokia.com, jmanner@cs.Helsinki.FI, nsis@ietf.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: pt, en-us, en MIME-Version: 1.0 Subject: Re: [NSIS] Next steps for the analysis document References: <20031021144453.1373fc72.bless@tm.uka.de> In-Reply-To: <20031021144453.1373fc72.bless@tm.uka.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit All, Inter-domain signaling is no doubt important and according to the current NSLP-QoS signaling draft, it is a necessary step, to be approached as future work. In such context, it is also necessary to have some survey about approaches that analysed that problem up to now. In terms of state required, signaling load, and bandwidth, the more "concrete" proposals are BGRP (and consequent updates, e.g., BGRP+) or SICAP. By "concrete" I mean that these proposals are currently the only ones approaching the problem considering not only algorithmic/optimization issues but also design issues (message types and format; how to get information from BGP, border routers; will that scale; which information; etc.). So, it is my (possibly biased :) ) opinion that it is important to address such work as inter-domain aggregation "related work", and the right place to do so is the analysis draft. I fully agree with Robert when he states that a comparison of the proposals is interesting and needed. We did compare SICAP and BGRP up to a good extent; we created ns2 modules for both protocols, created several scenarios and tried to use data as close as possible to reality. So, such comparison is addressed in any of the papers SICAP gave rise to. The comparison was performed in terms of state information required at border routers, signaling load and bandwidth usage efficiency. So, perhaps a reference to the proper papers, as Robert mentioned, is enough. Regards, Rute _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Oct 21 11:14:24 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22734 for ; Tue, 21 Oct 2003 11:14:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AByCw-0005wO-Dr for nsis-archive@odin.ietf.org; Tue, 21 Oct 2003 11:14:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9LFE2dV022819 for nsis-archive@odin.ietf.org; Tue, 21 Oct 2003 11:14:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AByCv-0005vn-6j; Tue, 21 Oct 2003 11:14:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AByCg-0005tB-Jt for nsis@optimus.ietf.org; Tue, 21 Oct 2003 11:13:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22711 for ; Tue, 21 Oct 2003 11:13:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AByCf-0004pA-00 for nsis@IETF.ORG; Tue, 21 Oct 2003 11:13:45 -0400 Received: from saturno.fccn.pt ([193.136.7.107]) by ietf-mx with smtp (Exim 4.12) id 1AByCe-0004ob-00 for nsis@IETF.ORG; Tue, 21 Oct 2003 11:13:45 -0400 Received: (qmail 44549 invoked from network); 21 Oct 2003 15:13:12 -0000 Received: (ofmipd unknown); 21 Oct 2003 15:12:50 -0000 Date: 21 Oct 2003 16:13:25 +0000 Message-ID: <3F955B25.2080909@seas.upenn.edu> From: "Rute Sofia" To: "H.DeMeer" Cc: "Hancock, Robert" , john.loughney@nokia.com, jmanner@cs.helsinki.fi, nsis@ietf.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: pt, en-us, en MIME-Version: 1.0 Subject: Re: [NSIS] Next steps for the analysis document References: <20031021144453.1373fc72.bless@tm.uka.de> <20031021144453.1373fc72.bless@tm.uka.de> <5.1.1.6.0.20031021161407.02125168@pop1.ee.ucl.ac.uk> In-Reply-To: <5.1.1.6.0.20031021161407.02125168@pop1.ee.ucl.ac.uk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > > this sounds quite interesting. > do you have the results in document you could make available? Sure, SICAP papers are available at: - http://einstein.seas.upenn.edu/mnlab/paper/hpsr03_paper3743.pdf (sicap's design, BGRP comparison) - http://einstein.seas.upenn.edu/mnlab/paper/tr_or_230703.pdf (optimizing the signaling load of both BGRP and SICAP) Furthermore, the full set of papers and corresponding technical reports is available at: http://rutesofia.no.sapo.pt/researche.html Regards, Rute > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Oct 21 16:00:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04719 for ; Tue, 21 Oct 2003 16:00:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC2fs-0000qV-Fq for nsis-archive@odin.ietf.org; Tue, 21 Oct 2003 16:00:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9LK0CKL003233 for nsis-archive@odin.ietf.org; Tue, 21 Oct 2003 16:00:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC2fi-0000ZP-KB; Tue, 21 Oct 2003 16:00:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC2ep-0000DO-9P for nsis@optimus.ietf.org; Tue, 21 Oct 2003 15:59:07 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04318; Tue, 21 Oct 2003 15:58:56 -0400 (EDT) Message-Id: <200310211958.PAA04318@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: nsis@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 21 Oct 2003 15:58:56 -0400 Subject: [NSIS] I-D ACTION:draft-fu-nsis-mobility-01.txt,.pdf Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Mobility Issues in Next Steps in Signaling (NSIS) Author(s) : X. Fu, et. al. Filename : draft-fu-nsis-mobility-01.txt,.pdf Pages : 29 Date : 2003-10-21 This document attempts to identify the various problems with signaling in the data path for the mobile node's on-going flows after it moves to a new point of attachment, and analyzes emerging issues with mobility support in the two-layer Next Steps in Signaling (NSIS) architecture. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-fu-nsis-mobility-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-fu-nsis-mobility-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-fu-nsis-mobility-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-10-21153656.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-fu-nsis-mobility-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-fu-nsis-mobility-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-21153656.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Wed Oct 22 03:18:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27347 for ; Wed, 22 Oct 2003 03:18:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACDFs-0001Cv-H5 for nsis-archive@odin.ietf.org; Wed, 22 Oct 2003 03:18:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9M7I4ah004626 for nsis-archive@odin.ietf.org; Wed, 22 Oct 2003 03:18:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACDFp-0001Bc-3V; Wed, 22 Oct 2003 03:18:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACDFG-00016Q-RT for nsis@optimus.ietf.org; Wed, 22 Oct 2003 03:17:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27328 for ; Wed, 22 Oct 2003 03:17:17 -0400 (EDT) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACDFE-0001Og-00 for nsis@ietf.org; Wed, 22 Oct 2003 03:17:24 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1ACDEy-0001OZ-00 for nsis@ietf.org; Wed, 22 Oct 2003 03:17:23 -0400 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id h9M7H8w21327 for ; Wed, 22 Oct 2003 10:17:09 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 22 Oct 2003 10:17:08 +0300 Received: from esebe006.NOE.Nokia.com ([172.21.138.46]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 22 Oct 2003 10:17:08 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe006.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 22 Oct 2003 10:17:07 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: [NSIS] Next steps for the analysis document Date: Wed, 22 Oct 2003 10:17:07 +0300 Message-ID: Thread-Topic: [NSIS] Next steps for the analysis document Thread-Index: AcOX5d03NoWnFWhtQ26cQOamASJr7AAho0VQ To: , Cc: , , X-OriginalArrivalTime: 22 Oct 2003 07:17:07.0867 (UTC) FILETIME=[80A4A6B0:01C3986C] Content-Transfer-Encoding: quoted-printable Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi Rute, Perhaps it would be nice if you could work with Jukka on suggesting some text for the analysis document on this topic. thanks, John > -----Original Message----- > From: ext Rute Sofia [mailto:rsofia@seas.upenn.edu] > Sent: 21 October, 2003 19:13 > To: H.DeMeer > Cc: Hancock, Robert; Loughney John (NRC/Helsinki); > jmanner@cs.helsinki.fi; nsis@IETF.ORG > Subject: Re: [NSIS] Next steps for the analysis document >=20 >=20 > > > > this sounds quite interesting. > > do you have the results in document you could make available? >=20 >=20 > Sure, >=20 > SICAP papers are available at: > - http://einstein.seas.upenn.edu/mnlab/paper/hpsr03_paper3743.pdf > (sicap's design, BGRP comparison) > - http://einstein.seas.upenn.edu/mnlab/paper/tr_or_230703.pdf > (optimizing the signaling load of both BGRP and SICAP) >=20 > Furthermore, the full set of papers and corresponding=20 > technical reports=20 > is available at: > http://rutesofia.no.sapo.pt/researche.html >=20 > Regards, > Rute >=20 > > >=20 >=20 >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Wed Oct 22 09:27:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07878 for ; Wed, 22 Oct 2003 09:27:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACJ0x-0007W5-JK for nsis-archive@odin.ietf.org; Wed, 22 Oct 2003 09:27:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9MDR3IL028859 for nsis-archive@odin.ietf.org; Wed, 22 Oct 2003 09:27:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACJ0v-0007UF-B9; Wed, 22 Oct 2003 09:27:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACJ0Q-0007N0-99 for nsis@optimus.ietf.org; Wed, 22 Oct 2003 09:26:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07854 for ; Wed, 22 Oct 2003 09:26:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACJ0O-00054G-00 for nsis@ietf.org; Wed, 22 Oct 2003 09:26:28 -0400 Received: from saturno.fccn.pt ([193.136.7.107]) by ietf-mx with smtp (Exim 4.12) id 1ACJ0N-00053s-00 for nsis@ietf.org; Wed, 22 Oct 2003 09:26:27 -0400 Received: (qmail 73917 invoked from network); 22 Oct 2003 13:25:53 -0000 Received: (ofmipd unknown); 22 Oct 2003 13:25:31 -0000 Date: 22 Oct 2003 14:26:03 +0000 Message-ID: <3F96937B.7020706@seas.upenn.edu> From: "Rute Sofia" To: john.loughney@nokia.com Cc: demeer@fmi.uni-passau.de, robert.hancock@roke.co.uk, jmanner@cs.helsinki.fi, nsis@ietf.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: pt, en-us, en MIME-Version: 1.0 Subject: Re: [NSIS] Next steps for the analysis document References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi John, >Perhaps it would be nice if you could work with Jukka on suggesting >some text for the analysis document on this topic. > > > Sure, that can be easily done. I'll get in touch with Jukka then :) Rute _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu Oct 23 04:58:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09092 for ; Thu, 23 Oct 2003 04:58:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACbIG-0001zp-Bl for nsis-archive@odin.ietf.org; Thu, 23 Oct 2003 04:58:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9N8w86c007656 for nsis-archive@odin.ietf.org; Thu, 23 Oct 2003 04:58:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACbI9-0001vm-JO; Thu, 23 Oct 2003 04:58:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACbHf-0001nE-W3 for nsis@optimus.ietf.org; Thu, 23 Oct 2003 04:57:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09023 for ; Thu, 23 Oct 2003 04:57:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACbHc-0003rP-00 for nsis@ietf.org; Thu, 23 Oct 2003 04:57:28 -0400 Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx with esmtp (Exim 4.12) id 1ACbHc-0003rE-00 for nsis@ietf.org; Thu, 23 Oct 2003 04:57:28 -0400 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Thu, 23 Oct 2003 09:56:57 +0100 Message-ID: From: "Hancock, Robert" To: nsis@ietf.org Date: Thu, 23 Oct 2003 09:57:00 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [NSIS] NTLP draft Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Dear all, You will (I hope) be pleased to know that there is now a wg -00 NTLP draft. While it works through the i-d editor queue, you can find a copy at http://nsis.srmr.co.uk/~reh/draft-ietf-nsis-ntlp-00.txt This can be seen as a development of the ideas in the drafts that were presented in Vienna and the subsequent discussion (actually, it is still called GIMPS but the name is actually the first in the list of open issues). The main point is that the protocol is (hopefully now very clearly) structured as - something RFC2205-like, which also supports - use of existing transport&security protocols to achieve the functionality that RSVP has in 2747 & 2961 The view has been expressed that this is a good approach to investigate, but that there are some consequences which have to be worried over. We hope that the description now in the draft is clear enough to allow the WG to make its mind up on the matter. In particular, section 5.3 describes the problems and some possible cures (some people may find some of the cures worse than the problems). There is also more discussion of other aspects of operation as requested (e.g. v4/v6 stuff and supporting material) and some examples for clarification. There is also a bit more on routing interactions (although I believe this needs more analysis before we can decide exactly what we want the protocol to do). As a general point, this version is long (very long) on explanation and discussion, and short on actual specification. In fact, my impression is that GIMPS (or whatever we call it) is actually a rather simple protocol, which can behave in a number of very complicated ways and has a number of very complicated interactions with other protocols. So, in the longer term, we may need to think about how to structure the specification to reflect this (somewhat unusual) situation. enjoy, robert h. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu Oct 23 10:48:23 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26870 for ; Thu, 23 Oct 2003 10:48:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACgku-0006dG-6z for nsis-archive@odin.ietf.org; Thu, 23 Oct 2003 10:48:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9NEm4fp025477 for nsis-archive@odin.ietf.org; Thu, 23 Oct 2003 10:48:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACgkr-0006cN-2J; Thu, 23 Oct 2003 10:48:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACgkB-0006YF-SD for nsis@optimus.ietf.org; Thu, 23 Oct 2003 10:47:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26824 for ; Thu, 23 Oct 2003 10:47:08 -0400 (EDT) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACgk9-0001aO-00 for nsis@ietf.org; Thu, 23 Oct 2003 10:47:17 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1ACgk8-0001aL-00 for nsis@ietf.org; Thu, 23 Oct 2003 10:47:16 -0400 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id h9NElFI13918 for ; Thu, 23 Oct 2003 17:47:15 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 23 Oct 2003 17:47:13 +0300 Received: from esebe008.NOE.Nokia.com ([172.21.138.48]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 23 Oct 2003 17:47:15 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe008.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 23 Oct 2003 17:47:15 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Date: Thu, 23 Oct 2003 17:47:00 +0300 Message-ID: Thread-Topic: [NSIS] NTLP draft Thread-Index: AcOZQ9R6RWWdi4iSTvSUUol1S67d6gAMH0AA To: X-OriginalArrivalTime: 23 Oct 2003 14:47:15.0265 (UTC) FILETIME=[8CB84B10:01C39974] Content-Transfer-Encoding: quoted-printable Subject: [NSIS] RMD in the Analysis draft Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi all, I am concerned that only one person has spoken up in favor of adding RMD in the Analysis draft (besides the backers of the technology). Unless there is sufficient interest in the subject, I propose we do not add it to the Analysis draft. thanks, John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu Oct 23 11:38:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00082 for ; Thu, 23 Oct 2003 11:38:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AChXL-00014M-6E for nsis-archive@odin.ietf.org; Thu, 23 Oct 2003 11:38:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9NFc6Rs003840 for nsis-archive@odin.ietf.org; Thu, 23 Oct 2003 11:38:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AChXJ-0000xm-CT; Thu, 23 Oct 2003 11:38:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AChXB-0000uS-R4 for nsis@optimus.ietf.org; Thu, 23 Oct 2003 11:37:57 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29987; Thu, 23 Oct 2003 11:37:47 -0400 (EDT) Message-Id: <200310231537.LAA29987@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: nsis@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Thu, 23 Oct 2003 11:37:46 -0400 Subject: [NSIS] I-D ACTION:draft-aoun-nsis-nslp-natfw-migration-00.txt Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : NATFirewall NSLP migration and intra-realm communication considerations Author(s) : C. Aoun, M. Brunner, M. Stiemerling, M. Martin, H. Tschofenig Filename : draft-aoun-nsis-nslp-natfw-migration-00.txt Pages : 31 Date : 2003-10-23 This document discusses NAT/FW migration to support the NSIS NAT/FW NSLP as well as intra-realm communications considerations. The document will serve as input to the NSIS NATFW NSLP document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-aoun-nsis-nslp-natfw-migration-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-aoun-nsis-nslp-natfw-migration-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-aoun-nsis-nslp-natfw-migration-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-10-23113719.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-aoun-nsis-nslp-natfw-migration-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-aoun-nsis-nslp-natfw-migration-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-23113719.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu Oct 23 11:44:21 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00945 for ; Thu, 23 Oct 2003 11:44:21 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AChd3-00029a-2j for nsis-archive@odin.ietf.org; Thu, 23 Oct 2003 11:44:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9NFi13l008261 for nsis-archive@odin.ietf.org; Thu, 23 Oct 2003 11:44:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AChd2-000298-Sd; Thu, 23 Oct 2003 11:44:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AChci-000271-1k for nsis@optimus.ietf.org; Thu, 23 Oct 2003 11:43:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00839 for ; Thu, 23 Oct 2003 11:43:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AChcg-0002oy-00 for nsis@ietf.org; Thu, 23 Oct 2003 11:43:38 -0400 Received: from utrhcs.cs.utwente.nl ([130.89.10.247]) by ietf-mx with esmtp (Exim 4.12) id 1AChcf-0002ob-00 for nsis@ietf.org; Thu, 23 Oct 2003 11:43:37 -0400 Received: from utip105 (utip105.cs.utwente.nl [130.89.13.76]) by utrhcs.cs.utwente.nl (8.12.10/8.12.9) with SMTP id h9NFhSSd008422; Thu, 23 Oct 2003 17:43:28 +0200 (MET DST) Message-ID: <003301c3997c$6872e320$4c0d5982@dynamic.cs.utwente.nl> From: "Georgios Karagiannis" To: Cc: References: <009f01c394b4$b32311f0$4c0d5982@dynamic.cs.utwente.nl> <00c601c394b8$ba316b00$7907c289@pcluu> Subject: Re: [NSIS] Next steps for the analysis document Date: Thu, 23 Oct 2003 17:43:30 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4922.1500 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4925.2800 Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi John As I already mentioned we have had a discussion on this draft on the NSIS mailing list. Moreover, below you can also find someone that is interested in it. Moreover, the authors of the QoS-NSLP draft are also interested in the RMD concept. Therefore, I would very much appreciate if it will be included in the NSIS analysis draft. best Regards, Georgios ----- Original Message ----- From: "Thanh Tra LUU" To: "Georgios Karagiannis" ; Cc: Sent: Friday, October 17, 2003 4:12 PM Subject: Re: [NSIS] Next steps for the analysis document > hi Geogios, > > I am really interested in this draft. For me, it is the first one which > proposes a complete and concrete stateless signaling application in the NSIS > WG. Moreover, the QoS-NSLP is the "most important" application in NSIS. > > Nary Tra > ENST, Paris > > > > ----- Original Message ----- > From: "Georgios Karagiannis" > To: ; ; > Sent: Friday, October 17, 2003 3:43 PM > Subject: Re: [NSIS] Next steps for the analysis document > > > > Hi John > > > > We have had discussed the provided RMD text within the WG. > > There was also a consensus on this afterwards. > > Thus for RMD, your request is fulfilled. > > > > Best regards, > > Georgios > > > > > > ----- Original Message ----- > > From: > > To: ; > > Sent: Friday, October 17, 2003 3:32 PM > > Subject: RE: [NSIS] Next steps for the analysis document > > > > > > > Hi all, > > > > > > > 2) Add a short review of SICAP, a protocol similar to BGRP? (See > Helena > > > > Rute Sofia's email on July 16th 2003) (SICAP description July 17th > 2003) > > > > > > > > 3) What about adding an RMD evaluation? Or any other text? (see > > Georgios' > > > > email on July 17 2003) (some discussions July 17th -> July 22nd, Sep > 5) > > > > > > I prefer to have some people, other than the backers of these protocols, > > to > > > speak up on behalf of their inclusion into the analysis document. If > > noone > > > else in the WG is interested in these protocols, then it seems that > there > > > is no interest in these protocols. > > > > > > thanks, > > > John > > > > > > _______________________________________________ > > > nsis mailing list > > > nsis@ietf.org > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Fri Oct 24 02:39:24 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18474 for ; Fri, 24 Oct 2003 02:39:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACvbE-0008CN-B7 for nsis-archive@odin.ietf.org; Fri, 24 Oct 2003 02:39:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9O6d4Fj031497 for nsis-archive@odin.ietf.org; Fri, 24 Oct 2003 02:39:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACvbD-0008Bs-2o; Fri, 24 Oct 2003 02:39:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACvaX-00087l-B6 for nsis@optimus.ietf.org; Fri, 24 Oct 2003 02:38:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18446 for ; Fri, 24 Oct 2003 02:38:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACvaT-0006VT-00 for nsis@ietf.org; Fri, 24 Oct 2003 02:38:17 -0400 Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx with esmtp (Exim 4.12) id 1ACvaS-0006VQ-00 for nsis@ietf.org; Fri, 24 Oct 2003 02:38:16 -0400 Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id h9O6cHoq009543; Fri, 24 Oct 2003 08:38:17 +0200 Received: from era.ericsson.se (E00104B7F41BB.ki.sw.ericsson.se [147.214.194.44]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id 43DW6349; Fri, 24 Oct 2003 08:39:06 +0200 Message-ID: <3F98C829.C69F8133@era.ericsson.se> Date: Fri, 24 Oct 2003 08:35:21 +0200 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: "Lars.Westberg" X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: john.loughney@nokia.com CC: nsis@ietf.org Subject: Re: [NSIS] RMD in the Analysis draft References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi! Do you have a list of how many people that is in favour of each proposal in the analsysis draft ? I have not seen any voting in the working group regarding which proposal that should be included. Should we inittiate such discussion ? - Lasse john.loughney@nokia.com wrote: > Hi all, > > I am concerned that only one person has spoken up in favor of > adding RMD in the Analysis draft (besides the backers of the > technology). Unless there is sufficient interest in the subject, > I propose we do not add it to the Analysis draft. > > thanks, > John > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Fri Oct 24 03:27:24 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19604 for ; Fri, 24 Oct 2003 03:27:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACwLe-0006MX-If for nsis-archive@odin.ietf.org; Fri, 24 Oct 2003 03:27:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9O7R2Eu024434 for nsis-archive@odin.ietf.org; Fri, 24 Oct 2003 03:27:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACwLd-0006Ly-Om; Fri, 24 Oct 2003 03:27:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACwLY-0006LJ-1j for nsis@optimus.ietf.org; Fri, 24 Oct 2003 03:26:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19589 for ; Fri, 24 Oct 2003 03:26:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACwLV-0006z8-00 for nsis@ietf.org; Fri, 24 Oct 2003 03:26:53 -0400 Received: from courier.cs.helsinki.fi ([128.214.9.1] helo=mail.cs.helsinki.fi) by ietf-mx with esmtp (Exim 4.12) id 1ACwLV-0006z5-00 for nsis@ietf.org; Fri, 24 Oct 2003 03:26:53 -0400 Received: from mannersaari.cs.Helsinki.FI (mannersaari.cs.helsinki.fi [::ffff:128.214.11.173]) (IDENT: jmanner, TLS: TLSv1/SSLv3,168bits,DES-CBC3-SHA) by mail.cs.helsinki.fi with esmtp; Fri, 24 Oct 2003 10:26:53 +0300 Date: Fri, 24 Oct 2003 10:26:52 +0300 (EEST) From: Jukka MJ Manner To: "Lars.Westberg" cc: John Loughney , nsis@ietf.org Subject: Re: [NSIS] RMD in the Analysis draft In-Reply-To: <3F98C829.C69F8133@era.ericsson.se> Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I knew this type of comment was coming... I knew it, I knew it... :) Lasse, AFAIK, there is no voting in the IETF, only rough consensus. The Analysis draft is now a year old and it should be closed pretty soon now. We need to put an end to constantly editing the document, otherwise we will never, ever, get it done. Thus, I understood that John was clearly asking the WG consensus on what is still needed to be included into the document. There is no problem what so ever to include more protocols, including RMD and many, many others, and do more analysis, if there is a rough consensus that more work is needed. AFAIK, rough consensus is not fulfilled if only a group with a subjective view of an issue support it. To me, it sounds like there is a rough consensus about the current set of protocols. I base this view on the fact that the draft has been out for a year now and there has not been comments about removing existing evaluations, although, from the initial list of protocols, ITSUMO was dropped. Cheers, Jukka On Fri, 24 Oct 2003, Lars.Westberg wrote: > Hi! > Do you have a list of how many people > that is in favour of each proposal in the analsysis draft ? > I have not seen any voting in the working group regarding which proposal > that should be included. Should we inittiate such discussion ? > > - Lasse > john.loughney@nokia.com wrote: > > > Hi all, > > > > I am concerned that only one person has spoken up in favor of > > adding RMD in the Analysis draft (besides the backers of the > > technology). Unless there is sufficient interest in the subject, > > I propose we do not add it to the Analysis draft. > > > > thanks, > > John > > > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Fri Oct 24 03:40:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19966 for ; Fri, 24 Oct 2003 03:40:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACwYN-0000Fb-Vo for nsis-archive@odin.ietf.org; Fri, 24 Oct 2003 03:40:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9O7eBYA000929 for nsis-archive@odin.ietf.org; Fri, 24 Oct 2003 03:40:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACwYG-0000DF-HP; Fri, 24 Oct 2003 03:40:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACwXo-00008p-Sl for nsis@optimus.ietf.org; Fri, 24 Oct 2003 03:39:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19921 for ; Fri, 24 Oct 2003 03:39:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACwXm-00077S-00 for nsis@ietf.org; Fri, 24 Oct 2003 03:39:34 -0400 Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx with esmtp (Exim 4.12) id 1ACwXl-00077P-00 for nsis@ietf.org; Fri, 24 Oct 2003 03:39:33 -0400 Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id h9O7dUoq023988; Fri, 24 Oct 2003 09:39:34 +0200 Received: from era.ericsson.se (E00104B7F41BB.ki.sw.ericsson.se [147.214.194.44]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id 43DW7FJC; Fri, 24 Oct 2003 09:40:16 +0200 Message-ID: <3F98D67E.9A7E45D7@era.ericsson.se> Date: Fri, 24 Oct 2003 09:36:30 +0200 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: "Lars.Westberg" X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Jukka MJ Manner CC: John Loughney , nsis@ietf.org Subject: Re: [NSIS] RMD in the Analysis draft References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Thanks, this was a good explanation. I know that we have been "slow" to generate the text to the document. Is RMD the only proposed addition to the draft ? regards Lasse Jukka MJ Manner wrote: > I knew this type of comment was coming... I knew it, I knew it... :) > > Lasse, > > AFAIK, there is no voting in the IETF, only rough consensus. The Analysis > draft is now a year old and it should be closed pretty soon now. We need > to put an end to constantly editing the document, otherwise we will never, > ever, get it done. Thus, I understood that John was clearly asking the WG > consensus on what is still needed to be included into the document. There > is no problem what so ever to include more protocols, including RMD and > many, many others, and do more analysis, if there is a rough consensus > that more work is needed. AFAIK, rough consensus is not fulfilled if only > a group with a subjective view of an issue support it. > > To me, it sounds like there is a rough consensus about the current set of > protocols. I base this view on the fact that the draft has been out for a > year now and there has not been comments about removing existing > evaluations, although, from the initial list of protocols, ITSUMO was > dropped. > > Cheers, > Jukka > > On Fri, 24 Oct 2003, Lars.Westberg wrote: > > > Hi! > > Do you have a list of how many people > > that is in favour of each proposal in the analsysis draft ? > > I have not seen any voting in the working group regarding which proposal > > that should be included. Should we inittiate such discussion ? > > > > - Lasse > > john.loughney@nokia.com wrote: > > > > > Hi all, > > > > > > I am concerned that only one person has spoken up in favor of > > > adding RMD in the Analysis draft (besides the backers of the > > > technology). Unless there is sufficient interest in the subject, > > > I propose we do not add it to the Analysis draft. > > > > > > thanks, > > > John > > > > > > _______________________________________________ > > > nsis mailing list > > > nsis@ietf.org > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Fri Oct 24 03:53:23 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20213 for ; Fri, 24 Oct 2003 03:53:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACwko-00026x-Lk for nsis-archive@odin.ietf.org; Fri, 24 Oct 2003 03:53:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9O7r2Pr008097 for nsis-archive@odin.ietf.org; Fri, 24 Oct 2003 03:53:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACwkn-00026T-Tu; Fri, 24 Oct 2003 03:53:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACwkK-00022v-6h for nsis@optimus.ietf.org; Fri, 24 Oct 2003 03:52:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20203 for ; Fri, 24 Oct 2003 03:52:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACwkH-0007F6-00 for nsis@ietf.org; Fri, 24 Oct 2003 03:52:29 -0400 Received: from courier.cs.helsinki.fi ([128.214.9.1] helo=mail.cs.helsinki.fi) by ietf-mx with esmtp (Exim 4.12) id 1ACwkG-0007F3-00 for nsis@ietf.org; Fri, 24 Oct 2003 03:52:28 -0400 Received: from mannersaari.cs.Helsinki.FI (mannersaari.cs.helsinki.fi [::ffff:128.214.11.173]) (IDENT: jmanner, TLS: TLSv1/SSLv3,168bits,DES-CBC3-SHA) by mail.cs.helsinki.fi with esmtp; Fri, 24 Oct 2003 10:52:29 +0300 Date: Fri, 24 Oct 2003 10:52:29 +0300 (EEST) From: Jukka MJ Manner To: "Lars.Westberg" cc: John Loughney , nsis@ietf.org Subject: Re: [NSIS] RMD in the Analysis draft In-Reply-To: <3F98D67E.9A7E45D7@era.ericsson.se> Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Lasse, Several people requested discussions about inter-domain issues, enhancements to BGRP, for example. I should get all such text by Monday morning my time. Apart from that, I will only be doing editorial stuff, and trying to write some summary. FYI, I have received several personal (subjective) requests to add "this and that" protocol into the document, but I have turned all such requests down, and asked to get the rough consensus from the NSIS list before yet another protocol is added. From your point of view, RMD can be added as a reference, would be a good idea anyway, but to include a full analysis would require the rough consensus from the WG - at least that is how I see it... maybe I'm wrong, and someone, please, correct me. I am trying to follow the rough consensus of the whole WG and work according to that. Cheers, Jukka On Fri, 24 Oct 2003, Lars.Westberg wrote: > Thanks, this was a good explanation. I know that we have been "slow" to > generate the text to the document. > Is RMD the only proposed addition to the draft ? > > regards Lasse > > > Jukka MJ Manner wrote: > > > I knew this type of comment was coming... I knew it, I knew it... :) > > > > Lasse, > > > > AFAIK, there is no voting in the IETF, only rough consensus. The Analysis > > draft is now a year old and it should be closed pretty soon now. We need > > to put an end to constantly editing the document, otherwise we will never, > > ever, get it done. Thus, I understood that John was clearly asking the WG > > consensus on what is still needed to be included into the document. There > > is no problem what so ever to include more protocols, including RMD and > > many, many others, and do more analysis, if there is a rough consensus > > that more work is needed. AFAIK, rough consensus is not fulfilled if only > > a group with a subjective view of an issue support it. > > > > To me, it sounds like there is a rough consensus about the current set of > > protocols. I base this view on the fact that the draft has been out for a > > year now and there has not been comments about removing existing > > evaluations, although, from the initial list of protocols, ITSUMO was > > dropped. > > > > Cheers, > > Jukka > > > > On Fri, 24 Oct 2003, Lars.Westberg wrote: > > > > > Hi! > > > Do you have a list of how many people > > > that is in favour of each proposal in the analsysis draft ? > > > I have not seen any voting in the working group regarding which proposal > > > that should be included. Should we inittiate such discussion ? > > > > > > - Lasse > > > john.loughney@nokia.com wrote: > > > > > > > Hi all, > > > > > > > > I am concerned that only one person has spoken up in favor of > > > > adding RMD in the Analysis draft (besides the backers of the > > > > technology). Unless there is sufficient interest in the subject, > > > > I propose we do not add it to the Analysis draft. > > > > > > > > thanks, > > > > John > > > > > > > > _______________________________________________ > > > > nsis mailing list > > > > nsis@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > > > _______________________________________________ > > > nsis mailing list > > > nsis@ietf.org > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Fri Oct 24 03:55:23 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20282 for ; Fri, 24 Oct 2003 03:55:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACwmk-0002RT-Ve for nsis-archive@odin.ietf.org; Fri, 24 Oct 2003 03:55:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9O7t25G009302 for nsis-archive@odin.ietf.org; Fri, 24 Oct 2003 03:55:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACwmj-0002Pt-VU; Fri, 24 Oct 2003 03:55:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACwmT-0002NU-Ke for nsis@optimus.ietf.org; Fri, 24 Oct 2003 03:54:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20262 for ; Fri, 24 Oct 2003 03:54:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACwmQ-0007GX-00 for nsis@ietf.org; Fri, 24 Oct 2003 03:54:42 -0400 Received: from utrhcs.cs.utwente.nl ([130.89.10.247]) by ietf-mx with esmtp (Exim 4.12) id 1ACwmP-0007GR-00 for nsis@ietf.org; Fri, 24 Oct 2003 03:54:41 -0400 Received: from utip105 (utip105.cs.utwente.nl [130.89.13.76]) by utrhcs.cs.utwente.nl (8.12.10/8.12.9) with SMTP id h9O7sZSd010636; Fri, 24 Oct 2003 09:54:35 +0200 (MET DST) Message-ID: <001501c39a04$12442b70$4c0d5982@dynamic.cs.utwente.nl> From: "Georgios Karagiannis" To: "Jukka MJ Manner" Cc: "John Loughney" , References: Subject: Re: [NSIS] RMD in the Analysis draft Date: Fri, 24 Oct 2003 09:54:37 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4922.1500 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4925.2800 Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Jukka What I found very strange is that during the last IETf meeting you have asked me to send the RMD text to the NSIS WG list. The sent text has been commented and after that there were no objections of including the RMD text into the analysis draft. One week before the deadline a new criterion on this is introduced. I think that the people that are following the NSIS WG list have had no time to react on this new criterion. By the way if we want to be fair in this WG then the criterion that is requested to be used for RMD it should also be used for all other proposals included in the analysis draft. Best regards, Georgios ----- Original Message ----- From: "Jukka MJ Manner" To: "Lars.Westberg" Cc: "John Loughney" ; Sent: Friday, October 24, 2003 9:26 AM Subject: Re: [NSIS] RMD in the Analysis draft > > I knew this type of comment was coming... I knew it, I knew it... :) > > Lasse, > > AFAIK, there is no voting in the IETF, only rough consensus. The Analysis > draft is now a year old and it should be closed pretty soon now. We need > to put an end to constantly editing the document, otherwise we will never, > ever, get it done. Thus, I understood that John was clearly asking the WG > consensus on what is still needed to be included into the document. There > is no problem what so ever to include more protocols, including RMD and > many, many others, and do more analysis, if there is a rough consensus > that more work is needed. AFAIK, rough consensus is not fulfilled if only > a group with a subjective view of an issue support it. > > To me, it sounds like there is a rough consensus about the current set of > protocols. I base this view on the fact that the draft has been out for a > year now and there has not been comments about removing existing > evaluations, although, from the initial list of protocols, ITSUMO was > dropped. > > Cheers, > Jukka > > On Fri, 24 Oct 2003, Lars.Westberg wrote: > > > Hi! > > Do you have a list of how many people > > that is in favour of each proposal in the analsysis draft ? > > I have not seen any voting in the working group regarding which proposal > > that should be included. Should we inittiate such discussion ? > > > > - Lasse > > john.loughney@nokia.com wrote: > > > > > Hi all, > > > > > > I am concerned that only one person has spoken up in favor of > > > adding RMD in the Analysis draft (besides the backers of the > > > technology). Unless there is sufficient interest in the subject, > > > I propose we do not add it to the Analysis draft. > > > > > > thanks, > > > John > > > > > > _______________________________________________ > > > nsis mailing list > > > nsis@ietf.org > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Fri Oct 24 03:59:22 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20407 for ; Fri, 24 Oct 2003 03:59:21 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACwqb-0003JT-JD for nsis-archive@odin.ietf.org; Fri, 24 Oct 2003 03:59:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9O7x1Uk012718 for nsis-archive@odin.ietf.org; Fri, 24 Oct 2003 03:59:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACwqb-0003J1-5q; Fri, 24 Oct 2003 03:59:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACwqM-0003Gn-HH for nsis@optimus.ietf.org; Fri, 24 Oct 2003 03:58:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20393 for ; Fri, 24 Oct 2003 03:58:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACwqJ-0007Ju-00 for nsis@ietf.org; Fri, 24 Oct 2003 03:58:43 -0400 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 1ACwqJ-0007Jr-00 for nsis@ietf.org; Fri, 24 Oct 2003 03:58:43 -0400 Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id h9O7wfI2026823; Fri, 24 Oct 2003 09:58:41 +0200 (MEST) Received: from era.ericsson.se (E00104B7F41BB.ki.sw.ericsson.se [147.214.194.44]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id 45JTCAK1; Fri, 24 Oct 2003 09:59:44 +0200 Message-ID: <3F98DB01.DC27137A@era.ericsson.se> Date: Fri, 24 Oct 2003 09:55:45 +0200 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: "Lars.Westberg" X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Jukka MJ Manner CC: John Loughney , nsis@ietf.org Subject: Re: [NSIS] RMD in the Analysis draft References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Rough consensus should be from the persons partizipating in the group not dependent if he has partizipate in a certain work or not. I agree that we may not need a full-fledge analysis. What I thought was reasonable is short description of it. regards Lasse Jukka MJ Manner wrote: > Hi Lasse, > > Several people requested discussions about inter-domain issues, > enhancements to BGRP, for example. I should get all such text by Monday > morning my time. Apart from that, I will only be doing editorial stuff, > and trying to write some summary. > > FYI, I have received several personal (subjective) requests to add "this > and that" protocol into the document, but I have turned all such requests > down, and asked to get the rough consensus from the NSIS list before yet > another protocol is added. > > >From your point of view, RMD can be added as a reference, would be a good > idea anyway, but to include a full analysis would require the rough > consensus from the WG - at least that is how I see it... maybe I'm wrong, > and someone, please, correct me. > > I am trying to follow the rough consensus of the whole WG and work > according to that. > > Cheers, > Jukka > > On Fri, 24 Oct 2003, Lars.Westberg wrote: > > > Thanks, this was a good explanation. I know that we have been "slow" to > > generate the text to the document. > > Is RMD the only proposed addition to the draft ? > > > > regards Lasse > > > > > > Jukka MJ Manner wrote: > > > > > I knew this type of comment was coming... I knew it, I knew it... :) > > > > > > Lasse, > > > > > > AFAIK, there is no voting in the IETF, only rough consensus. The Analysis > > > draft is now a year old and it should be closed pretty soon now. We need > > > to put an end to constantly editing the document, otherwise we will never, > > > ever, get it done. Thus, I understood that John was clearly asking the WG > > > consensus on what is still needed to be included into the document. There > > > is no problem what so ever to include more protocols, including RMD and > > > many, many others, and do more analysis, if there is a rough consensus > > > that more work is needed. AFAIK, rough consensus is not fulfilled if only > > > a group with a subjective view of an issue support it. > > > > > > To me, it sounds like there is a rough consensus about the current set of > > > protocols. I base this view on the fact that the draft has been out for a > > > year now and there has not been comments about removing existing > > > evaluations, although, from the initial list of protocols, ITSUMO was > > > dropped. > > > > > > Cheers, > > > Jukka > > > > > > On Fri, 24 Oct 2003, Lars.Westberg wrote: > > > > > > > Hi! > > > > Do you have a list of how many people > > > > that is in favour of each proposal in the analsysis draft ? > > > > I have not seen any voting in the working group regarding which proposal > > > > that should be included. Should we inittiate such discussion ? > > > > > > > > - Lasse > > > > john.loughney@nokia.com wrote: > > > > > > > > > Hi all, > > > > > > > > > > I am concerned that only one person has spoken up in favor of > > > > > adding RMD in the Analysis draft (besides the backers of the > > > > > technology). Unless there is sufficient interest in the subject, > > > > > I propose we do not add it to the Analysis draft. > > > > > > > > > > thanks, > > > > > John > > > > > > > > > > _______________________________________________ > > > > > nsis mailing list > > > > > nsis@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > > > > > > _______________________________________________ > > > > nsis mailing list > > > > nsis@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Fri Oct 24 04:18:23 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20866 for ; Fri, 24 Oct 2003 04:18:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACx90-00069A-PU for nsis-archive@odin.ietf.org; Fri, 24 Oct 2003 04:18:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9O8I2EA023612 for nsis-archive@odin.ietf.org; Fri, 24 Oct 2003 04:18:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACx8z-00068D-D5; Fri, 24 Oct 2003 04:18:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACx8H-000611-Hh for nsis@optimus.ietf.org; Fri, 24 Oct 2003 04:17:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20771 for ; Fri, 24 Oct 2003 04:17:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACx8E-0007Um-00 for nsis@ietf.org; Fri, 24 Oct 2003 04:17:14 -0400 Received: from courier.cs.helsinki.fi ([128.214.9.1] helo=mail.cs.helsinki.fi) by ietf-mx with esmtp (Exim 4.12) id 1ACx8D-0007Uj-00 for nsis@ietf.org; Fri, 24 Oct 2003 04:17:13 -0400 Received: from mannersaari.cs.Helsinki.FI (mannersaari.cs.helsinki.fi [::ffff:128.214.11.173]) (IDENT: jmanner, TLS: TLSv1/SSLv3,168bits,DES-CBC3-SHA) by mail.cs.helsinki.fi with esmtp; Fri, 24 Oct 2003 11:17:13 +0300 Date: Fri, 24 Oct 2003 11:17:12 +0300 (EEST) From: Jukka MJ Manner To: Georgios Karagiannis cc: John Loughney , nsis@ietf.org Subject: Re: [NSIS] RMD in the Analysis draft In-Reply-To: <001501c39a04$12442b70$4c0d5982@dynamic.cs.utwente.nl> Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Georgios, a few quick comments, a) re-read the 2nd paragraph of my email, b) see my follow-up email about adding new stuff, and c) AFAIK, "no objections" != "yes" Cheers, Jukka On Fri, 24 Oct 2003, Georgios Karagiannis wrote: > Hi Jukka > > What I found very strange is that during the last IETf meeting > you have asked me to send the RMD text to the NSIS WG list. > The sent text has been commented and after that there were no objections > of including the > RMD text into the analysis draft. > > One week before the deadline a new criterion on this is introduced. > I think that the people that are following the NSIS WG list have had no > time to react on this new criterion. > > By the way if we want to be fair in this WG then the criterion that is > requested to be > used for RMD it should also be used for all other proposals included in the > analysis draft. > > Best regards, > Georgios > > ----- Original Message ----- > From: "Jukka MJ Manner" > To: "Lars.Westberg" > Cc: "John Loughney" ; > Sent: Friday, October 24, 2003 9:26 AM > Subject: Re: [NSIS] RMD in the Analysis draft > > > > > > I knew this type of comment was coming... I knew it, I knew it... :) > > > > Lasse, > > > > AFAIK, there is no voting in the IETF, only rough consensus. The Analysis > > draft is now a year old and it should be closed pretty soon now. We need > > to put an end to constantly editing the document, otherwise we will never, > > ever, get it done. Thus, I understood that John was clearly asking the WG > > consensus on what is still needed to be included into the document. There > > is no problem what so ever to include more protocols, including RMD and > > many, many others, and do more analysis, if there is a rough consensus > > that more work is needed. AFAIK, rough consensus is not fulfilled if only > > a group with a subjective view of an issue support it. > > > > To me, it sounds like there is a rough consensus about the current set of > > protocols. I base this view on the fact that the draft has been out for a > > year now and there has not been comments about removing existing > > evaluations, although, from the initial list of protocols, ITSUMO was > > dropped. > > > > Cheers, > > Jukka > > > > On Fri, 24 Oct 2003, Lars.Westberg wrote: > > > > > Hi! > > > Do you have a list of how many people > > > that is in favour of each proposal in the analsysis draft ? > > > I have not seen any voting in the working group regarding which proposal > > > that should be included. Should we inittiate such discussion ? > > > > > > - Lasse > > > john.loughney@nokia.com wrote: > > > > > > > Hi all, > > > > > > > > I am concerned that only one person has spoken up in favor of > > > > adding RMD in the Analysis draft (besides the backers of the > > > > technology). Unless there is sufficient interest in the subject, > > > > I propose we do not add it to the Analysis draft. > > > > > > > > thanks, > > > > John > > > > > > > > _______________________________________________ > > > > nsis mailing list > > > > nsis@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > > > _______________________________________________ > > > nsis mailing list > > > nsis@ietf.org > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > > > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Fri Oct 24 04:22:22 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20939 for ; Fri, 24 Oct 2003 04:22:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACxCs-000722-Rw for nsis-archive@odin.ietf.org; Fri, 24 Oct 2003 04:22:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9O8M212026991 for nsis-archive@odin.ietf.org; Fri, 24 Oct 2003 04:22:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACxCs-00071E-E5; Fri, 24 Oct 2003 04:22:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACxCW-0006xr-8q for nsis@optimus.ietf.org; Fri, 24 Oct 2003 04:21:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20934 for ; Fri, 24 Oct 2003 04:21:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACxCT-0007Y7-00 for nsis@ietf.org; Fri, 24 Oct 2003 04:21:37 -0400 Received: from utrhcs.cs.utwente.nl ([130.89.10.247]) by ietf-mx with esmtp (Exim 4.12) id 1ACxCS-0007Y4-00 for nsis@ietf.org; Fri, 24 Oct 2003 04:21:36 -0400 Received: from utip105 (utip105.cs.utwente.nl [130.89.13.76]) by utrhcs.cs.utwente.nl (8.12.10/8.12.9) with SMTP id h9O8LYSd012164; Fri, 24 Oct 2003 10:21:34 +0200 (MET DST) Message-ID: <004801c39a07$d7524ed0$4c0d5982@dynamic.cs.utwente.nl> From: "Georgios Karagiannis" To: "Jukka MJ Manner" Cc: "John Loughney" , References: Subject: Re: [NSIS] RMD in the Analysis draft Date: Fri, 24 Oct 2003 10:21:36 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4922.1500 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4925.2800 Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Jukka I see this as a new defined criterion (during last week) and therefore, I would very much appreciate if we could discuss it during the next IETF meeting. Best Regards, Georgios ----- Original Message ----- From: "Jukka MJ Manner" To: "Georgios Karagiannis" Cc: "John Loughney" ; Sent: Friday, October 24, 2003 10:17 AM Subject: Re: [NSIS] RMD in the Analysis draft > > Hi Georgios, > > a few quick comments, > > a) re-read the 2nd paragraph of my email, > > b) see my follow-up email about adding new stuff, and > > c) AFAIK, "no objections" != "yes" > > Cheers, > Jukka > > On Fri, 24 Oct 2003, Georgios Karagiannis wrote: > > > Hi Jukka > > > > What I found very strange is that during the last IETf meeting > > you have asked me to send the RMD text to the NSIS WG list. > > The sent text has been commented and after that there were no objections > > of including the > > RMD text into the analysis draft. > > > > One week before the deadline a new criterion on this is introduced. > > I think that the people that are following the NSIS WG list have had no > > time to react on this new criterion. > > > > By the way if we want to be fair in this WG then the criterion that is > > requested to be > > used for RMD it should also be used for all other proposals included in the > > analysis draft. > > > > Best regards, > > Georgios > > > > ----- Original Message ----- > > From: "Jukka MJ Manner" > > To: "Lars.Westberg" > > Cc: "John Loughney" ; > > Sent: Friday, October 24, 2003 9:26 AM > > Subject: Re: [NSIS] RMD in the Analysis draft > > > > > > > > > > I knew this type of comment was coming... I knew it, I knew it... :) > > > > > > Lasse, > > > > > > AFAIK, there is no voting in the IETF, only rough consensus. The Analysis > > > draft is now a year old and it should be closed pretty soon now. We need > > > to put an end to constantly editing the document, otherwise we will never, > > > ever, get it done. Thus, I understood that John was clearly asking the WG > > > consensus on what is still needed to be included into the document. There > > > is no problem what so ever to include more protocols, including RMD and > > > many, many others, and do more analysis, if there is a rough consensus > > > that more work is needed. AFAIK, rough consensus is not fulfilled if only > > > a group with a subjective view of an issue support it. > > > > > > To me, it sounds like there is a rough consensus about the current set of > > > protocols. I base this view on the fact that the draft has been out for a > > > year now and there has not been comments about removing existing > > > evaluations, although, from the initial list of protocols, ITSUMO was > > > dropped. > > > > > > Cheers, > > > Jukka > > > > > > On Fri, 24 Oct 2003, Lars.Westberg wrote: > > > > > > > Hi! > > > > Do you have a list of how many people > > > > that is in favour of each proposal in the analsysis draft ? > > > > I have not seen any voting in the working group regarding which proposal > > > > that should be included. Should we inittiate such discussion ? > > > > > > > > - Lasse > > > > john.loughney@nokia.com wrote: > > > > > > > > > Hi all, > > > > > > > > > > I am concerned that only one person has spoken up in favor of > > > > > adding RMD in the Analysis draft (besides the backers of the > > > > > technology). Unless there is sufficient interest in the subject, > > > > > I propose we do not add it to the Analysis draft. > > > > > > > > > > thanks, > > > > > John > > > > > > > > > > _______________________________________________ > > > > > nsis mailing list > > > > > nsis@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > > > > > > _______________________________________________ > > > > nsis mailing list > > > > nsis@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > > > > > > > _______________________________________________ > > > nsis mailing list > > > nsis@ietf.org > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Fri Oct 24 04:34:22 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21234 for ; Fri, 24 Oct 2003 04:34:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACxOU-0000Gq-IY for nsis-archive@odin.ietf.org; Fri, 24 Oct 2003 04:34:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9O8Y2hd001039 for nsis-archive@odin.ietf.org; Fri, 24 Oct 2003 04:34:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACxOT-0000GF-Bt; Fri, 24 Oct 2003 04:34:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACxO0-0000B3-S9 for nsis@optimus.ietf.org; Fri, 24 Oct 2003 04:33:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21179 for ; Fri, 24 Oct 2003 04:33:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACxNx-0007dU-00 for nsis@ietf.org; Fri, 24 Oct 2003 04:33:29 -0400 Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx with esmtp (Exim 4.12) id 1ACxNx-0007dR-00 for nsis@ietf.org; Fri, 24 Oct 2003 04:33:29 -0400 Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id h9O8XPoq005471; Fri, 24 Oct 2003 10:33:29 +0200 Received: from era.ericsson.se (E00104B7F41BB.ki.sw.ericsson.se [147.214.194.44]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id 43DP9VPX; Fri, 24 Oct 2003 10:33:24 +0200 Message-ID: <3F98E324.4982325@era.ericsson.se> Date: Fri, 24 Oct 2003 10:30:29 +0200 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: "Lars.Westberg" X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Jukka MJ Manner CC: Georgios Karagiannis , John Loughney , nsis@ietf.org Subject: Re: [NSIS] RMD in the Analysis draft References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I as a group member, proposing to add a short desription of RMD in the analysis. A full-fledge analysis is not required. regards Lasse Jukka MJ Manner wrote: > Hi Georgios, > > a few quick comments, > > a) re-read the 2nd paragraph of my email, > > b) see my follow-up email about adding new stuff, and > > c) AFAIK, "no objections" != "yes" > > Cheers, > Jukka > > On Fri, 24 Oct 2003, Georgios Karagiannis wrote: > > > Hi Jukka > > > > What I found very strange is that during the last IETf meeting > > you have asked me to send the RMD text to the NSIS WG list. > > The sent text has been commented and after that there were no objections > > of including the > > RMD text into the analysis draft. > > > > One week before the deadline a new criterion on this is introduced. > > I think that the people that are following the NSIS WG list have had no > > time to react on this new criterion. > > > > By the way if we want to be fair in this WG then the criterion that is > > requested to be > > used for RMD it should also be used for all other proposals included in the > > analysis draft. > > > > Best regards, > > Georgios > > > > ----- Original Message ----- > > From: "Jukka MJ Manner" > > To: "Lars.Westberg" > > Cc: "John Loughney" ; > > Sent: Friday, October 24, 2003 9:26 AM > > Subject: Re: [NSIS] RMD in the Analysis draft > > > > > > > > > > I knew this type of comment was coming... I knew it, I knew it... :) > > > > > > Lasse, > > > > > > AFAIK, there is no voting in the IETF, only rough consensus. The Analysis > > > draft is now a year old and it should be closed pretty soon now. We need > > > to put an end to constantly editing the document, otherwise we will never, > > > ever, get it done. Thus, I understood that John was clearly asking the WG > > > consensus on what is still needed to be included into the document. There > > > is no problem what so ever to include more protocols, including RMD and > > > many, many others, and do more analysis, if there is a rough consensus > > > that more work is needed. AFAIK, rough consensus is not fulfilled if only > > > a group with a subjective view of an issue support it. > > > > > > To me, it sounds like there is a rough consensus about the current set of > > > protocols. I base this view on the fact that the draft has been out for a > > > year now and there has not been comments about removing existing > > > evaluations, although, from the initial list of protocols, ITSUMO was > > > dropped. > > > > > > Cheers, > > > Jukka > > > > > > On Fri, 24 Oct 2003, Lars.Westberg wrote: > > > > > > > Hi! > > > > Do you have a list of how many people > > > > that is in favour of each proposal in the analsysis draft ? > > > > I have not seen any voting in the working group regarding which proposal > > > > that should be included. Should we inittiate such discussion ? > > > > > > > > - Lasse > > > > john.loughney@nokia.com wrote: > > > > > > > > > Hi all, > > > > > > > > > > I am concerned that only one person has spoken up in favor of > > > > > adding RMD in the Analysis draft (besides the backers of the > > > > > technology). Unless there is sufficient interest in the subject, > > > > > I propose we do not add it to the Analysis draft. > > > > > > > > > > thanks, > > > > > John > > > > > > > > > > _______________________________________________ > > > > > nsis mailing list > > > > > nsis@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > > > > > > _______________________________________________ > > > > nsis mailing list > > > > nsis@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > > > > > > > _______________________________________________ > > > nsis mailing list > > > nsis@ietf.org > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Fri Oct 24 04:37:23 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21334 for ; Fri, 24 Oct 2003 04:37:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACxRP-0000lV-8h for nsis-archive@odin.ietf.org; Fri, 24 Oct 2003 04:37:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9O8b27k002884 for nsis-archive@odin.ietf.org; Fri, 24 Oct 2003 04:37:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACxRO-0000kM-8k; Fri, 24 Oct 2003 04:37:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACxRL-0000j7-6c for nsis@optimus.ietf.org; Fri, 24 Oct 2003 04:36:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21328 for ; Fri, 24 Oct 2003 04:36:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACxRI-0007h1-00 for nsis@ietf.org; Fri, 24 Oct 2003 04:36:56 -0400 Received: from courier.cs.helsinki.fi ([128.214.9.1] helo=mail.cs.helsinki.fi) by ietf-mx with esmtp (Exim 4.12) id 1ACxRH-0007gy-00 for nsis@ietf.org; Fri, 24 Oct 2003 04:36:55 -0400 Received: from mannersaari.cs.Helsinki.FI (mannersaari.cs.helsinki.fi [::ffff:128.214.11.173]) (IDENT: jmanner, TLS: TLSv1/SSLv3,168bits,DES-CBC3-SHA) by mail.cs.helsinki.fi with esmtp; Fri, 24 Oct 2003 11:36:56 +0300 Date: Fri, 24 Oct 2003 11:36:49 +0300 (EEST) From: Jukka MJ Manner To: Georgios Karagiannis cc: John Loughney , nsis@ietf.org Subject: Re: [NSIS] RMD in the Analysis draft In-Reply-To: <004801c39a07$d7524ed0$4c0d5982@dynamic.cs.utwente.nl> Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Georgios, This is the last email I will write about this subject, I hope. I agree that a short description of a new protocol e.g. RMD could be ok. Should there be other protocols added, too? Anyone? As an editor of the draft, I don't want to be pressured from individual groups supporting their protocols (no offense intended, and you are not the only one trying to pressure me), but rather want to see the WG ask for new content to the draft. I am trying to do what the whole WG, or most of the people, some rough consensus, wants. I am happy to do what the WG, the Chair, or the ADs want to be done. I am not happy to do what small individual groups with their own agenda want me to do. I sincerely hope you understand my situation. Cheers, Jukka On Fri, 24 Oct 2003, Georgios Karagiannis wrote: > Hi Jukka > > I see this as a new defined criterion (during last week) > and therefore, I would very much appreciate if we could discuss it > during the next IETF meeting. > > Best Regards, > Georgios > > > ----- Original Message ----- > From: "Jukka MJ Manner" > To: "Georgios Karagiannis" > Cc: "John Loughney" ; > Sent: Friday, October 24, 2003 10:17 AM > Subject: Re: [NSIS] RMD in the Analysis draft > > > > > > Hi Georgios, > > > > a few quick comments, > > > > a) re-read the 2nd paragraph of my email, > > > > b) see my follow-up email about adding new stuff, and > > > > c) AFAIK, "no objections" != "yes" > > > > Cheers, > > Jukka > > > > On Fri, 24 Oct 2003, Georgios Karagiannis wrote: > > > > > Hi Jukka > > > > > > What I found very strange is that during the last IETf meeting > > > you have asked me to send the RMD text to the NSIS WG list. > > > The sent text has been commented and after that there were no objections > > > of including the > > > RMD text into the analysis draft. > > > > > > One week before the deadline a new criterion on this is introduced. > > > I think that the people that are following the NSIS WG list have had no > > > time to react on this new criterion. > > > > > > By the way if we want to be fair in this WG then the criterion that is > > > requested to be > > > used for RMD it should also be used for all other proposals included in > the > > > analysis draft. > > > > > > Best regards, > > > Georgios > > > > > > ----- Original Message ----- > > > From: "Jukka MJ Manner" > > > To: "Lars.Westberg" > > > Cc: "John Loughney" ; > > > Sent: Friday, October 24, 2003 9:26 AM > > > Subject: Re: [NSIS] RMD in the Analysis draft > > > > > > > > > > > > > > I knew this type of comment was coming... I knew it, I knew it... :) > > > > > > > > Lasse, > > > > > > > > AFAIK, there is no voting in the IETF, only rough consensus. The > Analysis > > > > draft is now a year old and it should be closed pretty soon now. We > need > > > > to put an end to constantly editing the document, otherwise we will > never, > > > > ever, get it done. Thus, I understood that John was clearly asking the > WG > > > > consensus on what is still needed to be included into the document. > There > > > > is no problem what so ever to include more protocols, including RMD > and > > > > many, many others, and do more analysis, if there is a rough consensus > > > > that more work is needed. AFAIK, rough consensus is not fulfilled if > only > > > > a group with a subjective view of an issue support it. > > > > > > > > To me, it sounds like there is a rough consensus about the current set > of > > > > protocols. I base this view on the fact that the draft has been out > for a > > > > year now and there has not been comments about removing existing > > > > evaluations, although, from the initial list of protocols, ITSUMO was > > > > dropped. > > > > > > > > Cheers, > > > > Jukka > > > > > > > > On Fri, 24 Oct 2003, Lars.Westberg wrote: > > > > > > > > > Hi! > > > > > Do you have a list of how many people > > > > > that is in favour of each proposal in the analsysis draft ? > > > > > I have not seen any voting in the working group regarding which > proposal > > > > > that should be included. Should we inittiate such discussion ? > > > > > > > > > > - Lasse > > > > > john.loughney@nokia.com wrote: > > > > > > > > > > > Hi all, > > > > > > > > > > > > I am concerned that only one person has spoken up in favor of > > > > > > adding RMD in the Analysis draft (besides the backers of the > > > > > > technology). Unless there is sufficient interest in the subject, > > > > > > I propose we do not add it to the Analysis draft. > > > > > > > > > > > > thanks, > > > > > > John > > > > > > > > > > > > _______________________________________________ > > > > > > nsis mailing list > > > > > > nsis@ietf.org > > > > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > > > > > > > > > _______________________________________________ > > > > > nsis mailing list > > > > > nsis@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > > > > > > > > > > > _______________________________________________ > > > > nsis mailing list > > > > nsis@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > > > > > > > > > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > > > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Fri Oct 24 10:51:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05379 for ; Fri, 24 Oct 2003 10:51:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AD3HY-0002Zb-WA for nsis-archive@odin.ietf.org; Fri, 24 Oct 2003 10:51:17 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9OEpGex009887 for nsis-archive@odin.ietf.org; Fri, 24 Oct 2003 10:51:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AD3HL-0002WM-Nt; Fri, 24 Oct 2003 10:51:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AD3Gl-0002T6-Kj for nsis@optimus.ietf.org; Fri, 24 Oct 2003 10:50:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05182 for ; Fri, 24 Oct 2003 10:50:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AD3Gi-0004KT-00 for nsis@ietf.org; Fri, 24 Oct 2003 10:50:24 -0400 Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx with esmtp (Exim 4.12) id 1AD3Gh-0004KJ-00 for nsis@ietf.org; Fri, 24 Oct 2003 10:50:24 -0400 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Fri, 24 Oct 2003 15:49:35 +0100 Message-ID: From: "McDonald, Andrew" To: "'Geib, Ruediger'" Cc: nsis@ietf.org Subject: RE: [NSIS] qos-nslp-00 Date: Fri, 24 Oct 2003 15:49:43 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi R=FCdiger, I wrote: > Geib, Ruediger wrote: >> thanks, your example explains two things I couldn't find in the >> draft:=20 >> - that session IDs still need to be present and aren't replaced by >> RSNs.=20 >> - how QoS-NSLP could react once it notes that it maintains stale >> state. >=20 > Ok. Clearly we'll need some updates in those areas. So, here they are. My suggested updates to provide clarification on = these points: Change last paragraph on page 13 (section 3.1): ... A RSN is an identifier that indicates the order in which state modifying actions are performed by a QNE. ... to: ... An RSN is an incrementing sequence number that indicates the order in which state modifying actions are performed by a QNE. ... Section 4.2, add a new last paragraph: When a QNE receives a partial refresh message it compares the RSN against that of the currently installed reservation. If it matches then the state is refreshed. If the RSN in the message is less than that of the currently installed state (i.e. it refers to 'old' state) then the message is discarded (possibly the messages got reordered between the nodes). If the RSN in the message is greater than that of the currently installed state then an error MUST be signalled back. It means that the peer QNE believes that state is installed when it is not. If not informed it would continue to attempt to refresh the non-existent state. A partial refresh containing either an unknown session identifier or flow identifier MUST also be responded to with an error message (this is likely to occur following a rerouting event). Section 3.1, insert new paragraph before final one: A Flow Identifier groups together state items for a single flow. The RSN is one of these state items, and is used to identify reordering of messages and to allow the use of partial refresh messages. The state items for a number of flows can be linked together and identified as part of a single reservation using a Session Identifier. The identifiers play complementary roles in the management of QoS NSLP state. [NB: this is slightly different from what I said before - my previous e-mail ignored the issue that flow identifiers can change in a given session.] Andrew --=20 Andrew McDonald Roke Manor Research Ltd, Romsey, Hants SO51 0ZN Phone +44 1794 833833 Fax +44 1794 833434 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Fri Oct 24 10:52:22 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05569 for ; Fri, 24 Oct 2003 10:52:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AD3II-0002nX-CR for nsis-archive@odin.ietf.org; Fri, 24 Oct 2003 10:52:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9OEq1lx010709 for nsis-archive@odin.ietf.org; Fri, 24 Oct 2003 10:52:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AD3IH-0002mW-KU; Fri, 24 Oct 2003 10:52:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AD3HT-0002Y8-Np for nsis@optimus.ietf.org; Fri, 24 Oct 2003 10:51:11 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05263; Fri, 24 Oct 2003 10:50:59 -0400 (EDT) Message-Id: <200310241450.KAA05263@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: nsis@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Fri, 24 Oct 2003 10:50:59 -0400 Subject: [NSIS] I-D ACTION:draft-ietf-nsis-ntlp-00.txt Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , --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 : GIMPS: General Internet Messaging Protocol for Signaling Author(s) : H. Schulzrinne Filename : draft-ietf-nsis-ntlp-00.txt Pages : 54 Date : 2003-10-23 This document specifies protocol stacks for the routing and transport of per-flow signaling messages along the path taken by that flow through the network. The solution uses existing transport and security protocols under a common messaging layer, the Generic Internet Messaging Protocol for Signaling (GIMPS), which provides a universal service for diverse signaling applications. GIMPS does not handle signaling application state itself, but manages its own internal state and the configuration of the underlying transport and security protocols to enable the transfer of messages in both directions along the flow path. The combination of GIMPS and the lower layer protocols provides a solution for the base protocol component of the 'Next Steps in Signaling' framework. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nsis-ntlp-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-nsis-ntlp-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-nsis-ntlp-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-10-24103653.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nsis-ntlp-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nsis-ntlp-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-24103653.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Fri Oct 24 11:08:24 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07470 for ; Fri, 24 Oct 2003 11:08:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AD3Xo-0006Yz-Fk for nsis-archive@odin.ietf.org; Fri, 24 Oct 2003 11:08:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9OF83FM025208 for nsis-archive@odin.ietf.org; Fri, 24 Oct 2003 11:08:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AD3Xm-0006YT-Dm; Fri, 24 Oct 2003 11:08:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AD3Xc-0006Uv-Tq for nsis@optimus.ietf.org; Fri, 24 Oct 2003 11:07:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07375 for ; Fri, 24 Oct 2003 11:07:40 -0400 (EDT) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AD3Xa-00050c-00 for nsis@ietf.org; Fri, 24 Oct 2003 11:07:50 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AD3XZ-00050Y-00 for nsis@ietf.org; Fri, 24 Oct 2003 11:07:49 -0400 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id h9OF7lI21926 for ; Fri, 24 Oct 2003 18:07:47 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 24 Oct 2003 18:07:47 +0300 Received: from esebe017.NOE.Nokia.com ([172.21.138.56]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 24 Oct 2003 18:07:46 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe017.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 24 Oct 2003 18:07:45 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: [NSIS] Comments about draft-hancock-nsis-reliability-00 Date: Fri, 24 Oct 2003 18:07:45 +0300 Message-ID: Thread-Topic: [NSIS] Comments about draft-hancock-nsis-reliability-00 Thread-Index: AcOORDTuf1vxQoRUSsWUtA7NKJLD3AL25F4w To: , , X-OriginalArrivalTime: 24 Oct 2003 15:07:45.0791 (UTC) FILETIME=[949568F0:01C39A40] Content-Transfer-Encoding: quoted-printable Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi Robert, Jumping in: > d) is the main point. on the transfer delay front you need pr-sctp > or home-made partial reliability above dccp (if multiplexing alone > isn't good enough).=20 Well, you could do something at the application layer, set timers (less than something like 3xRTT) which may mitigate TCP retransission induced latencies, but I think this would really get ugly quickly ... > on the congestion response front, i guess the > difficulty I have is understanding what it actually means for 3448 to = be a > standards track protocol document. if it means that you still need=20 > additional standards actions to be allowed to use it in a concrete=20 > protocol, then that work would seem to me to be worth doing, but=20 > (xref [c] above) i don't think of that work as being NSIS-specific.=20 >=20 > maybe john would like to comment on that last point. specifically on Michael's last point: > > Mechanisms arise from the desire to use something that > > is not yet available. I can't think of many applications > > that would need reliable transport with congestion control > > that would differ from TCP/SCTP - but NSIS appears to be a > > candidate. If we want to go this way, it might be nice if someone could document why NSIS would appear to be a candidate. I think I understand where you are going with this, but actually seeing the reasons down in black & white might clarify things. thanks, John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Fri Oct 24 11:28:22 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09262 for ; Fri, 24 Oct 2003 11:28:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AD3r7-0002qA-DZ for nsis-archive@odin.ietf.org; Fri, 24 Oct 2003 11:28:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9OFS1H3010878 for nsis-archive@odin.ietf.org; Fri, 24 Oct 2003 11:28:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AD3r7-0002pL-4a; Fri, 24 Oct 2003 11:28:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AD3qt-0002nB-P1 for nsis@optimus.ietf.org; Fri, 24 Oct 2003 11:27:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09208 for ; Fri, 24 Oct 2003 11:27:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AD3qs-0005dd-00 for nsis@ietf.org; Fri, 24 Oct 2003 11:27:46 -0400 Received: from utrhcs.cs.utwente.nl ([130.89.10.247]) by ietf-mx with esmtp (Exim 4.12) id 1AD3qr-0005da-00 for nsis@ietf.org; Fri, 24 Oct 2003 11:27:45 -0400 Received: from utip105 (utip105.cs.utwente.nl [130.89.13.76]) by utrhcs.cs.utwente.nl (8.12.10/8.12.9) with SMTP id h9OFRdSd003696; Fri, 24 Oct 2003 17:27:39 +0200 (MET DST) Message-ID: <00b801c39a43$5d59fa10$4c0d5982@dynamic.cs.utwente.nl> From: "Georgios Karagiannis" To: "Lars.Westberg" , "Jukka MJ Manner" Cc: References: <3F98E324.4982325@era.ericsson.se> Subject: Re: [NSIS] RMD in the Analysis draft Date: Fri, 24 Oct 2003 17:27:41 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4922.1500 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4925.2800 Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I am also a group member of this WG and I am proposing to add a short description of RMD in the analysis draft. Best regards, Georgios ----- Original Message ----- From: "Lars.Westberg" To: "Jukka MJ Manner" Cc: "Georgios Karagiannis" ; "John Loughney" ; Sent: Friday, October 24, 2003 10:30 AM Subject: Re: [NSIS] RMD in the Analysis draft > I as a group member, proposing to add a short desription of RMD in the analysis. A > full-fledge analysis is not required. > > regards Lasse > > Jukka MJ Manner wrote: > > > Hi Georgios, > > > > a few quick comments, > > > > a) re-read the 2nd paragraph of my email, > > > > b) see my follow-up email about adding new stuff, and > > > > c) AFAIK, "no objections" != "yes" > > > > Cheers, > > Jukka > > > > On Fri, 24 Oct 2003, Georgios Karagiannis wrote: > > > > > Hi Jukka > > > > > > What I found very strange is that during the last IETf meeting > > > you have asked me to send the RMD text to the NSIS WG list. > > > The sent text has been commented and after that there were no objections > > > of including the > > > RMD text into the analysis draft. > > > > > > One week before the deadline a new criterion on this is introduced. > > > I think that the people that are following the NSIS WG list have had no > > > time to react on this new criterion. > > > > > > By the way if we want to be fair in this WG then the criterion that is > > > requested to be > > > used for RMD it should also be used for all other proposals included in the > > > analysis draft. > > > > > > Best regards, > > > Georgios > > > > > > ----- Original Message ----- > > > From: "Jukka MJ Manner" > > > To: "Lars.Westberg" > > > Cc: "John Loughney" ; > > > Sent: Friday, October 24, 2003 9:26 AM > > > Subject: Re: [NSIS] RMD in the Analysis draft > > > > > > > > > > > > > > I knew this type of comment was coming... I knew it, I knew it... :) > > > > > > > > Lasse, > > > > > > > > AFAIK, there is no voting in the IETF, only rough consensus. The Analysis > > > > draft is now a year old and it should be closed pretty soon now. We need > > > > to put an end to constantly editing the document, otherwise we will never, > > > > ever, get it done. Thus, I understood that John was clearly asking the WG > > > > consensus on what is still needed to be included into the document. There > > > > is no problem what so ever to include more protocols, including RMD and > > > > many, many others, and do more analysis, if there is a rough consensus > > > > that more work is needed. AFAIK, rough consensus is not fulfilled if only > > > > a group with a subjective view of an issue support it. > > > > > > > > To me, it sounds like there is a rough consensus about the current set of > > > > protocols. I base this view on the fact that the draft has been out for a > > > > year now and there has not been comments about removing existing > > > > evaluations, although, from the initial list of protocols, ITSUMO was > > > > dropped. > > > > > > > > Cheers, > > > > Jukka > > > > > > > > On Fri, 24 Oct 2003, Lars.Westberg wrote: > > > > > > > > > Hi! > > > > > Do you have a list of how many people > > > > > that is in favour of each proposal in the analsysis draft ? > > > > > I have not seen any voting in the working group regarding which proposal > > > > > that should be included. Should we inittiate such discussion ? > > > > > > > > > > - Lasse > > > > > john.loughney@nokia.com wrote: > > > > > > > > > > > Hi all, > > > > > > > > > > > > I am concerned that only one person has spoken up in favor of > > > > > > adding RMD in the Analysis draft (besides the backers of the > > > > > > technology). Unless there is sufficient interest in the subject, > > > > > > I propose we do not add it to the Analysis draft. > > > > > > > > > > > > thanks, > > > > > > John > > > > > > > > > > > > _______________________________________________ > > > > > > nsis mailing list > > > > > > nsis@ietf.org > > > > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > > > > > > > > > _______________________________________________ > > > > > nsis mailing list > > > > > nsis@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > > > > > > > > > > > _______________________________________________ > > > > nsis mailing list > > > > nsis@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > > > > > > > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Fri Oct 24 12:37:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15822 for ; Fri, 24 Oct 2003 12:37:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AD4vz-0000BE-SU for nsis-archive@odin.ietf.org; Fri, 24 Oct 2003 12:37:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9OGb75Z000642 for nsis-archive@odin.ietf.org; Fri, 24 Oct 2003 12:37:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AD4vs-00007k-TL; Fri, 24 Oct 2003 12:37:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AD4vo-00006O-5m for nsis@optimus.ietf.org; Fri, 24 Oct 2003 12:36:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15783 for ; Fri, 24 Oct 2003 12:36:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AD4vm-00009j-00 for nsis@ietf.org; Fri, 24 Oct 2003 12:36:54 -0400 Received: from deprox.docomolab-euro.com ([212.119.9.186]) by ietf-mx with smtp (Exim 4.12) id 1AD4vl-00008t-00 for nsis@ietf.org; Fri, 24 Oct 2003 12:36:53 -0400 Received: from 192.168.0.23 by deprox.docomolab-euro.com (InterScan E-Mail VirusWall NT); Fri, 24 Oct 2003 18:36:06 +0200 Received: from docomolab-euro.com ([192.168.0.127]) by deex.docomolab-euro.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 24 Oct 2003 18:36:06 +0200 Message-ID: <3F995519.6040809@docomolab-euro.com> Date: Fri, 24 Oct 2003 18:36:41 +0200 From: Paulo Mendes User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us, en MIME-Version: 1.0 To: sven.van_den_bosch@alcatel.be CC: nsis@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Oct 2003 16:36:06.0461 (UTC) FILETIME=[EC0776D0:01C39A4C] Content-Transfer-Encoding: 7bit Subject: [NSIS] QoS-NSLP comments Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Sven, Some general comments about the QoS-NSLP draft: a) Terminology: - Why isn't a reduced-state QNE defined? - Policy Object: Policy in QoS related issues leads me to think more about dropping of packets that do not comply with some QoS profile, than with authentication issues. b) On section 1.1 it is said that "The design of QoS-NSLP is conceptually similar to RSVP...". How can these two concepts be similar when QoS-NSLP uses peer-to-peer messages and RSVP uses end-to-end messages? c) On section 2.5 it is said "In order to allow some local selection of which QoS Model to use without destroying all end-to-end aspects of the signalling QoS-NSLP allows a nesting of QoS Models by 'stacking' more than one pair of Control Information / QSpec object within a message". Shouldn't this sentence be more general to allow the stacking of QSpec instances within the same QoS model? For example, in DiffServ type of QoS models, one statefull edge router might use the same message to signal another statefull edge router, while signalling all reduced-state interior routers in the path. Since QSpec to signal edge routers might be different from the one to signal interior routers, these models might need to stack edge-QSpec inside interior-QSpec. Another question about this issue is: How much related with section 7.3.2 (tunnel management) is section 2.5 (nested protocol operation)? d) Reverse Path State: On section 2.7 it is said that a stateless and reduced state QNEs will be able to provide the underlying NTLP with some information, namely reverse path state. How can this be done in the case of stateless operation, in which QNEs are supposed to keep no state? Why can't QNEs operating in a statefull mode provide also the NTLP with such information? e) Peer-to-peer routing of NSLP messages: On section 6.2 it is said "There are several circumstances where it is necessary for a QNE to identify the adjacent QNE peer...". Shouldn't this knowledge be useful in any circumstances? Since the next QNE can be more than one hop away, information about the next QNE needs to be kept by the QNE: not only the SII to identify the source of the application message but also the identification of the downstream peer. Considering that the next QNE can also be more than one NTLP hope away, why should SII be kept by the NTLP, as said in section 3.1? Also about this topic, nothing is said about the discovery of next-peer QNE. Cheers Paulo -- Paulo Mendes DoCoMo Communications Laboratories Europe GmbH Landsberger Str. 312 80687 Munich, Germany Tel. +49-89-56824-226 Fax. +49-89-56824-300 E-mail: mendes@docomolab-euro.com http://www.docomoeurolabs.de/ _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Fri Oct 24 12:45:24 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16588 for ; Fri, 24 Oct 2003 12:45:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AD53e-0001ry-Vl for nsis-archive@odin.ietf.org; Fri, 24 Oct 2003 12:45:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9OGj2qR007167 for nsis-archive@odin.ietf.org; Fri, 24 Oct 2003 12:45:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AD53e-0001rV-Ga; Fri, 24 Oct 2003 12:45:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AD53C-0001oM-Ql for nsis@optimus.ietf.org; Fri, 24 Oct 2003 12:44:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16478 for ; Fri, 24 Oct 2003 12:44:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AD53B-0000OT-00 for nsis@ietf.org; Fri, 24 Oct 2003 12:44:33 -0400 Received: from deprox.docomolab-euro.com ([212.119.9.186]) by ietf-mx with smtp (Exim 4.12) id 1AD53A-0000Ln-00 for nsis@ietf.org; Fri, 24 Oct 2003 12:44:32 -0400 Received: from 192.168.0.23 by deprox.docomolab-euro.com (InterScan E-Mail VirusWall NT); Fri, 24 Oct 2003 18:43:52 +0200 Received: from docomolab-euro.com ([192.168.0.127]) by deex.docomolab-euro.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 24 Oct 2003 18:43:52 +0200 Message-ID: <3F9956EA.90908@docomolab-euro.com> Date: Fri, 24 Oct 2003 18:44:26 +0200 From: Paulo Mendes User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Rute C. Sofia" CC: sven.van_den_bosch@alcatel.be, nsis@ietf.org Subject: Re: [NSIS] Re: qos-nslp-00 References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Oct 2003 16:43:52.0039 (UTC) FILETIME=[01890770:01C39A4E] Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi all, >* would change "it is simplified by the elimination of support for >multicast" to something as "it does not address multicast support" (which >you actually say a couple of paragraphs after) > > I agree with this point, which leads me to a question: Will some future version of this draft address the issue of multicast? If not, should be referred somewhere in this draft that multicast support should be analysed in a different document? A lack of any comment about this issue might be understood as an indication that the future NSIS protocol will not be able to handle QoS multicast services. Cheers, Paulo -- Paulo Mendes DoCoMo Communications Laboratories Europe GmbH Landsberger Str. 312 80687 Munich, Germany Tel. +49-89-56824-226 Fax. +49-89-56824-300 E-mail: mendes@docomolab-euro.com http://www.docomoeurolabs.de/ _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Fri Oct 24 13:05:23 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18090 for ; Fri, 24 Oct 2003 13:05:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AD5N0-0005PK-G1 for nsis-archive@odin.ietf.org; Fri, 24 Oct 2003 13:05:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9OH52Ec020783 for nsis-archive@odin.ietf.org; Fri, 24 Oct 2003 13:05:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AD5Mz-0005P2-KM; Fri, 24 Oct 2003 13:05:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AD5MP-0005GR-T1 for nsis@optimus.ietf.org; Fri, 24 Oct 2003 13:04:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17963 for ; Fri, 24 Oct 2003 13:04:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AD5MK-0000tw-00 for nsis@ietf.org; Fri, 24 Oct 2003 13:04:20 -0400 Received: from deprox.docomolab-euro.com ([212.119.9.186]) by ietf-mx with smtp (Exim 4.12) id 1AD5MK-0000su-00 for nsis@ietf.org; Fri, 24 Oct 2003 13:04:20 -0400 Received: from 192.168.0.23 by deprox.docomolab-euro.com (InterScan E-Mail VirusWall NT); Fri, 24 Oct 2003 19:03:28 +0200 Received: from docomolab-euro.com ([192.168.0.127]) by deex.docomolab-euro.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 24 Oct 2003 19:03:28 +0200 Message-ID: <3F995B83.6050404@docomolab-euro.com> Date: Fri, 24 Oct 2003 19:04:03 +0200 From: Paulo Mendes User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "McDonald, Andrew" CC: "'Cheng Hong'" , sven.van_den_bosch@alcatel.be, nsis@ietf.org Subject: Re: [NSIS] Re: qos-nslp-00 References: In-Reply-To: Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-06721279-f830-428e-8279-5cb8ecdaccff" X-OriginalArrivalTime: 24 Oct 2003 17:03:28.0430 (UTC) FILETIME=[BEB80CE0:01C39A50] Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , ------=_NextPartTM-000-06721279-f830-428e-8279-5cb8ecdaccff Content-Type: multipart/alternative; boundary="------------000308040701070200050007" --------------000308040701070200050007 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi Andrew, I don't see why a description of a traffic conditioner has to be included in this draft, since its goal is to describe how QoS sessions should be signalled and not to how QoS should be implemented in each QNE (QoS models agnostic). Furthermore, keeping figure 1 as it is leads to some confusion. For instance, why isn't a traffic shaper and a marker included in the traffic conditioner? Therefore, it makes more sense to refer to traffic conditioning as a "black box". Probably it is enough to place a "black" traffic control box at each interface mentioning that the implementation of such boxes is dependent of the used QoS model. Cheers, Paulo McDonald, Andrew wrote: >Hi Cheng, > >Cheng Hong wrote: > > >>You are right that most of the implementations would choose to work >>only on the output interface, since it's simpler. But, due to other >>considerations, e.g. efficiency, etc, an implementation could choose >>to do it in a different way. For example, one of the popular QoS >>implementations ALTQ >>(http://www.csl.sony.co.jp/person/kjc/kjc/software.html#ALTQ ) >>actually has the traffic conditioner on the ingress interface in its >>DiffServ module. >> >>Since the QoS-NSLP is meant to be agnostic to QoS models, I would >>prefer the logical model also be neutral. Maybe some text for >>clarification is necessary in the section. Or, could we do something >>like the RFC2205, where the routing process is put at a position not >>implying the processing sequence? >> >> > >I'm not sure how best to change the diagram without making it more confusing >(and hence less useful in general). One of the difficulties comes from >trying to show the signaling/data flows in a single summary picture. > >I think the best thing is probably some clarifying text along the lines of: >This diagram shows an example implementation scenario where QoS conditioning >is performed on the output interface. However, this does not limit the >possible implementations. For example, in some cases traffic conditioning >may be performed on the incoming interface, or it may be split over the >input and output interfaces. > >How does that sound. Does it capture all the key points? > > >Andrew > >_______________________________________________ >nsis mailing list >nsis@ietf.org >https://www1.ietf.org/mailman/listinfo/nsis > > > > -- Paulo Mendes DoCoMo Communications Laboratories Europe GmbH Landsberger Str. 312 80687 Munich, Germany Tel. +49-89-56824-226 Fax. +49-89-56824-300 E-mail: mendes@docomolab-euro.com http://www.docomoeurolabs.de/ --------------000308040701070200050007 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Andrew,

I don't see why a description of a traffic conditioner has to be included in this draft, since its goal is to describe how QoS sessions should be signalled and not to how QoS should be implemented in each QNE (QoS models agnostic).  Furthermore, keeping figure 1 as it is leads to some confusion. For instance, why isn't a traffic shaper and a marker included in the traffic conditioner?
Therefore, it makes more sense to refer to traffic conditioning as a "black box". Probably it is enough to place a "black" traffic control box at each interface mentioning that the implementation of such boxes is dependent of the used QoS model.

Cheers,
Paulo

McDonald, Andrew wrote:
Hi Cheng,

Cheng Hong wrote:
  
You are right that most of the implementations would choose to work
only on the output interface, since it's simpler. But, due to other
considerations, e.g. efficiency, etc, an implementation could choose
to do it in a different way. For example, one of the popular QoS
implementations ALTQ
(http://www.csl.sony.co.jp/person/kjc/kjc/software.html#ALTQ )
actually has the traffic conditioner on the ingress interface in its
DiffServ module.  

Since the QoS-NSLP is meant to be agnostic to QoS models, I would
prefer the logical model also be neutral. Maybe some text for
clarification is necessary in the section. Or, could we do something
like the RFC2205, where the routing process is put at a position not
implying the processing sequence?
    

I'm not sure how best to change the diagram without making it more confusing
(and hence less useful in general). One of the difficulties comes from
trying to show the signaling/data flows in a single summary picture.

I think the best thing is probably some clarifying text along the lines of:
This diagram shows an example implementation scenario where QoS conditioning
is performed on the output interface. However, this does not limit the
possible implementations. For example, in some cases traffic conditioning
may be performed on the incoming interface, or it may be split over the
input and output interfaces.

How does that sound. Does it capture all the key points?


Andrew

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


  


-- 
Paulo Mendes
DoCoMo Communications Laboratories Europe GmbH
Landsberger Str. 312
80687 Munich, Germany
Tel. +49-89-56824-226
Fax. +49-89-56824-300
E-mail: mendes@docomolab-euro.com
http://www.docomoeurolabs.de/
--------------000308040701070200050007-- ------=_NextPartTM-000-06721279-f830-428e-8279-5cb8ecdaccff-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Fri Oct 24 13:11:21 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18488 for ; Fri, 24 Oct 2003 13:11:21 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AD5So-0007Bo-M5 for nsis-archive@odin.ietf.org; Fri, 24 Oct 2003 13:11:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9OHB2ht027557 for nsis-archive@odin.ietf.org; Fri, 24 Oct 2003 13:11:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AD5So-0007AI-3E; Fri, 24 Oct 2003 13:11:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AD5S0-0006xN-GR for nsis@optimus.ietf.org; Fri, 24 Oct 2003 13:10:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18434 for ; Fri, 24 Oct 2003 13:10:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AD5Ry-00014b-00 for nsis@ietf.org; Fri, 24 Oct 2003 13:10:10 -0400 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1AD5Rx-00014M-00 for nsis@ietf.org; Fri, 24 Oct 2003 13:10:09 -0400 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h9OH8qv04174; Fri, 24 Oct 2003 13:08:53 -0400 (EDT) Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard309.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id VR2R4P4A; Fri, 24 Oct 2003 13:08:53 -0400 Received: from nortelnetworks.com (acart1b2.ca.nortel.com [47.129.129.12]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id SZW5NGXR; Fri, 24 Oct 2003 13:08:53 -0400 Message-ID: <3F995CA3.2080006@nortelnetworks.com> Date: Fri, 24 Oct 2003 13:08:51 -0400 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Georgios Karagiannis CC: Jukka MJ Manner , John Loughney , nsis@ietf.org Subject: Re: [NSIS] RMD in the Analysis draft References: <004801c39a07$d7524ed0$4c0d5982@dynamic.cs.utwente.nl> In-Reply-To: <004801c39a07$d7524ed0$4c0d5982@dynamic.cs.utwente.nl> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Just remember that what happens at meetings is not definitive -- it's what is decided on the list that counts. Georgios Karagiannis wrote: > Hi Jukka > > I see this as a new defined criterion (during last week) > and therefore, I would very much appreciate if we could discuss it > during the next IETF meeting. > > Best Regards, > Georgios > > > ----- Original Message ----- > From: "Jukka MJ Manner" > To: "Georgios Karagiannis" > Cc: "John Loughney" ; > Sent: Friday, October 24, 2003 10:17 AM > Subject: Re: [NSIS] RMD in the Analysis draft > > > >>Hi Georgios, >> >>a few quick comments, >> >>a) re-read the 2nd paragraph of my email, >> >>b) see my follow-up email about adding new stuff, and >> >>c) AFAIK, "no objections" != "yes" >> >>Cheers, >>Jukka >> >>On Fri, 24 Oct 2003, Georgios Karagiannis wrote: >> >> >>>Hi Jukka >>> >>>What I found very strange is that during the last IETf meeting >>>you have asked me to send the RMD text to the NSIS WG list. >>>The sent text has been commented and after that there were no objections >>>of including the >>>RMD text into the analysis draft. >>> >>>One week before the deadline a new criterion on this is introduced. >>>I think that the people that are following the NSIS WG list have had no >>>time to react on this new criterion. >>> >>>By the way if we want to be fair in this WG then the criterion that is >>>requested to be >>>used for RMD it should also be used for all other proposals included in > > the > >>>analysis draft. >>> >>>Best regards, >>>Georgios >>> >>>----- Original Message ----- >>>From: "Jukka MJ Manner" >>>To: "Lars.Westberg" >>>Cc: "John Loughney" ; >>>Sent: Friday, October 24, 2003 9:26 AM >>>Subject: Re: [NSIS] RMD in the Analysis draft >>> >>> >>> >>>>I knew this type of comment was coming... I knew it, I knew it... :) >>>> >>>>Lasse, >>>> >>>>AFAIK, there is no voting in the IETF, only rough consensus. The > > Analysis > >>>>draft is now a year old and it should be closed pretty soon now. We > > need > >>>>to put an end to constantly editing the document, otherwise we will > > never, > >>>>ever, get it done. Thus, I understood that John was clearly asking the > > WG > >>>>consensus on what is still needed to be included into the document. > > There > >>>>is no problem what so ever to include more protocols, including RMD > > and > >>>>many, many others, and do more analysis, if there is a rough consensus >>>>that more work is needed. AFAIK, rough consensus is not fulfilled if > > only > >>>>a group with a subjective view of an issue support it. >>>> >>>>To me, it sounds like there is a rough consensus about the current set > > of > >>>>protocols. I base this view on the fact that the draft has been out > > for a > >>>>year now and there has not been comments about removing existing >>>>evaluations, although, from the initial list of protocols, ITSUMO was >>>>dropped. >>>> >>>>Cheers, >>>>Jukka >>>> >>>>On Fri, 24 Oct 2003, Lars.Westberg wrote: >>>> >>>> >>>>>Hi! >>>>>Do you have a list of how many people >>>>>that is in favour of each proposal in the analsysis draft ? >>>>>I have not seen any voting in the working group regarding which > > proposal > >>>>>that should be included. Should we inittiate such discussion ? >>>>> >>>>>- Lasse >>>>>john.loughney@nokia.com wrote: >>>>> >>>>> >>>>>>Hi all, >>>>>> >>>>>>I am concerned that only one person has spoken up in favor of >>>>>>adding RMD in the Analysis draft (besides the backers of the >>>>>>technology). Unless there is sufficient interest in the subject, >>>>>>I propose we do not add it to the Analysis draft. >>>>>> >>>>>>thanks, >>>>>>John >>>>>> >>>>>>_______________________________________________ >>>>>>nsis mailing list >>>>>>nsis@ietf.org >>>>>>https://www1.ietf.org/mailman/listinfo/nsis >>>>> >>>>> >>>>>_______________________________________________ >>>>>nsis mailing list >>>>>nsis@ietf.org >>>>>https://www1.ietf.org/mailman/listinfo/nsis >>>>> >>>> >>>> >>>>_______________________________________________ >>>>nsis mailing list >>>>nsis@ietf.org >>>>https://www1.ietf.org/mailman/listinfo/nsis >>>> >>> >>> >> >>_______________________________________________ >>nsis mailing list >>nsis@ietf.org >>https://www1.ietf.org/mailman/listinfo/nsis >> > > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Fri Oct 24 15:13:20 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24636 for ; Fri, 24 Oct 2003 15:13:20 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AD7Mp-0003ua-HL for nsis-archive@odin.ietf.org; Fri, 24 Oct 2003 15:13:00 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9OJCxHu015032 for nsis-archive@odin.ietf.org; Fri, 24 Oct 2003 15:12:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AD7Mo-0003u5-SG; Fri, 24 Oct 2003 15:12:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AD7MV-0003pb-Lw for nsis@optimus.ietf.org; Fri, 24 Oct 2003 15:12:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24541 for ; Fri, 24 Oct 2003 15:12:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AD7MU-0002t9-00 for nsis@ietf.org; Fri, 24 Oct 2003 15:12:38 -0400 Received: from rsys002a.roke.co.uk ([193.118.192.251]) by ietf-mx with esmtp (Exim 4.12) id 1AD7MT-0002sX-00 for nsis@ietf.org; Fri, 24 Oct 2003 15:12:38 -0400 Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Fri, 24 Oct 2003 20:12:03 +0100 Message-ID: From: "Hancock, Robert" To: Paulo Mendes Cc: nsis@ietf.org Subject: RE: [NSIS] Re: qos-nslp-00 Date: Fri, 24 Oct 2003 20:12:10 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , hi paulo, i (for one) would be quite happy to see it clarified that no future version of this draft will ever consider multicast. there are a number of reasons for this to do with missing parts of the multicast story in the Internet as a whole and also the fact that we would have to revisit multicast in the whole NSIS requirements and framework. however, the main point is that I'm pretty sure that if you tried to invent a multicast NSIS you would end up with something nearly identical to RSVP (which of course we do not need to invent again). there is no reason why a resource manager shouldn't be able to handle unicast traffic with nsis and multicast with rsvp; and, IMHO, the overlap between unicast and multicast functionality in the signalling protocol is rather limited. (at least, this is true if you consider traditional IP multicast in its full glory. the situation for things like SSM or xcast is probably different, since these are much easier to handle. all we need is someone to want these supported strongly enough...) cheers, r. > -----Original Message----- > From: Paulo Mendes [mailto:mendes@docomolab-euro.com] > Sent: Friday, October 24, 2003 17:44 > To: Rute C. Sofia > Cc: sven.van_den_bosch@alcatel.be; nsis@ietf.org > Subject: Re: [NSIS] Re: qos-nslp-00 > > > Hi all, > > >* would change "it is simplified by the elimination of support for > >multicast" to something as "it does not address multicast > support" (which > >you actually say a couple of paragraphs after) > > > > > I agree with this point, which leads me to a question: Will > some future > version of this draft address the issue of multicast? If not, > should be > referred somewhere in this draft that multicast support should be > analysed in a different document? A lack of any comment about > this issue > might be understood as an indication that the future NSIS > protocol will > not be able to handle QoS multicast services. > > Cheers, > Paulo > > -- > Paulo Mendes > DoCoMo Communications Laboratories Europe GmbH > Landsberger Str. 312 > 80687 Munich, Germany > Tel. +49-89-56824-226 > Fax. +49-89-56824-300 > E-mail: mendes@docomolab-euro.com > http://www.docomoeurolabs.de/ > > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Fri Oct 24 15:26:24 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25540 for ; Fri, 24 Oct 2003 15:26:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AD7ZT-0006QH-Sw for nsis-archive@odin.ietf.org; Fri, 24 Oct 2003 15:26:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9OJQ3m1024673 for nsis-archive@odin.ietf.org; Fri, 24 Oct 2003 15:26:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AD7ZS-0006Oo-9L; Fri, 24 Oct 2003 15:26:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AD7Yy-0006Jw-HV for nsis@optimus.ietf.org; Fri, 24 Oct 2003 15:25:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25483 for ; Fri, 24 Oct 2003 15:25:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AD7Yx-00031Z-00 for nsis@ietf.org; Fri, 24 Oct 2003 15:25:31 -0400 Received: from ckmso2.att.com ([209.219.209.75] helo=ckmso2.proxy.att.com) by ietf-mx with esmtp (Exim 4.12) id 1AD7Yw-00030z-00 for nsis@ietf.org; Fri, 24 Oct 2003 15:25:30 -0400 Received: from attrh5i.attrh.att.com ([135.38.62.12]) by ckmso2.proxy.att.com (AT&T IPNS/MSO-5.0) with ESMTP id h9OJ8KJT028046 for ; Fri, 24 Oct 2003 15:24:59 -0400 Received: from KCCLUST06EVS1.ugd.att.com (135.38.164.89) by attrh5i.attrh.att.com (6.5.032) id 3F307C6C014D03D3 for nsis@ietf.org; Fri, 24 Oct 2003 15:24:42 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 24 Oct 2003 14:24:59 -0500 Message-ID: <9473683187ADC049A855ED2DA739ABCA0201EEE4@KCCLUST06EVS1.ugd.att.com> Thread-Topic: I-D ACTION:draft-ietf-nsis-qos-nslp-00.txt Thread-Index: AcOBRBcPl1Qg7D7aQICHHEx/AeBG9wXbK5+wACwH+VAAQIFfIA== From: "Ash, Gerald R (Jerry), ALABS" To: Cc: "Ash, Gerald R (Jerry), ALABS" Content-Transfer-Encoding: quoted-printable Subject: [NSIS] RE: I-D ACTION:draft-ietf-nsis-qos-nslp-00.txt Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Nice document, well done IMO. I'd like to clarify a point in the draft: Section 2.2 defines a 'QoS model' and Section 2.1 states that the QSpec = object contains the QoS parameters defined in the QoS model. Also = Section 2.2 proposes a QSpec template that would allow specification of = common QoS parameters in different QoS models. It seems that this NSLP model envisions multiple QoS models being = defined for use by the NSLP. Is that correct? If so, are there any = examples yet of proposed QoS models, and if so, is there an I-D defining = the QoS model? =20 Also, is it intended that folks would now start to propose Standards = Track QoS Models in the NSIS working group? Or if not, what is the = intention to develop QoS models? Thanks in advance, Jerry Ash AT&T -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: Monday, September 22, 2003 2:46 PM Cc: nsis@ietf.org Subject: I-D ACTION:draft-ietf-nsis-qos-nslp-00.txt A New Internet-Draft is available from the on-line Internet-Drafts = directories. This draft is a work item of the Next Steps in Signaling Working Group = of the IETF. Title : NSLP for Quality-of-Service signaling Author(s) : S. Van den Bosch et al. Filename : draft-ietf-nsis-qos-nslp-00.txt Pages : 30 Date : 2003-9-22 =09 This draft describes an NSIS Signaling Layer Protocol (NSLP) for=20 signaling QoS reservations in the Internet. It is in accordance with=20 the framework and requirements developed in NSIS.=20 Together with the NTLP, it provides functionality similar to RSVP and=20 extends it. The QoS-NSLP is independent of the underlying QoS=20 specification or architecture and provides support for different=20 reservation models. It is simplified by the elimination of support=20 for multicast flows.=20 This version of the draft focuses on the basic protocol structure. It=20 identifies the different message types and describes the basic=20 operation of the protocol to create, refresh, modify and teardown a=20 reservation or to obtain information on the characteristics of the=20 associated data path. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nsis-qos-nslp-00.txt _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Sat Oct 25 00:28:03 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA12497 for ; Sat, 25 Oct 2003 00:28:03 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADG10-0008Nn-00 for nsis-archive@odin.ietf.org; Sat, 25 Oct 2003 00:27:44 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9P4R1vJ032222 for nsis-archive@odin.ietf.org; Sat, 25 Oct 2003 00:27:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADG0z-0008NL-2A; Sat, 25 Oct 2003 00:27:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABx9I-000465-1U for nsis@optimus.ietf.org; Tue, 21 Oct 2003 10:06:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18167 for ; Tue, 21 Oct 2003 10:06:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABx9F-0003k1-00 for nsis@IETF.ORG; Tue, 21 Oct 2003 10:06:09 -0400 Received: from yoda.fmi.uni-passau.de ([132.231.1.30]) by ietf-mx with esmtp (Exim 4.12) id 1ABx9E-0003jp-00 for nsis@IETF.ORG; Tue, 21 Oct 2003 10:06:09 -0400 Received: from ARIES.fmi.uni-passau.de (aries [132.231.13.141]) by yoda.fmi.uni-passau.de (8.12.2/8.12.9) with ESMTP id h9LE5jop020252; Tue, 21 Oct 2003 16:05:46 +0200 (MEST) Message-Id: <5.1.1.6.0.20031021161407.02125168@pop1.ee.ucl.ac.uk> X-Sender: demeer@yoda.fmi.uni-passau.de X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Tue, 21 Oct 2003 16:15:35 +0200 To: "Rute Sofia" , "Hancock, Robert" From: "H.DeMeer" Subject: Re: [NSIS] Next steps for the analysis document Cc: john.loughney@nokia.com, jmanner@cs.helsinki.fi, nsis@ietf.org In-Reply-To: <3F954486.3020609@seas.upenn.edu> References: <20031021144453.1373fc72.bless@tm.uka.de> <20031021144453.1373fc72.bless@tm.uka.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Rute, At 14:36 21/10/2003 +0000, Rute Sofia wrote: >All, > >Inter-domain signaling is no doubt important and according to the current >NSLP-QoS signaling draft, it is a necessary step, to be approached as >future work. In such context, it is also necessary to have some survey >about approaches that analysed that problem up to now. In terms of state >required, signaling load, and bandwidth, the more "concrete" proposals are >BGRP (and consequent updates, e.g., BGRP+) or SICAP. By "concrete" I mean >that these proposals are currently the only ones approaching the problem >considering not only algorithmic/optimization issues but also design >issues (message types and format; how to get information from BGP, border >routers; will that scale; which information; etc.). > >So, it is my (possibly biased :) ) opinion that it is important to address >such work as inter-domain aggregation "related work", and the right place >to do so is the analysis draft. > >I fully agree with Robert when he states that a comparison of the >proposals is interesting and needed. We did compare SICAP and BGRP up to a >good extent; we created ns2 modules for both protocols, created several >scenarios and tried to use data as close as possible to reality. So, such >comparison is addressed in any of the papers SICAP gave rise to. The >comparison was performed in terms of state information required at border >routers, signaling load and bandwidth usage efficiency. So, perhaps a >reference to the proper papers, as Robert mentioned, is enough. this sounds quite interesting. do you have the results in document you could make available? Regards, Hermann >Regards, >Rute > > > > >_______________________________________________ >nsis mailing list >nsis@ietf.org >https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Sat Oct 25 03:15:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28059 for ; Sat, 25 Oct 2003 03:15:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADIdc-0008HT-LI for nsis-archive@odin.ietf.org; Sat, 25 Oct 2003 03:15:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9P7F4AU031823 for nsis-archive@odin.ietf.org; Sat, 25 Oct 2003 03:15:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADIda-0008H5-LC; Sat, 25 Oct 2003 03:15:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADIch-0008FN-FX for nsis@optimus.ietf.org; Sat, 25 Oct 2003 03:14:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28029 for ; Sat, 25 Oct 2003 03:13:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ADIcf-00024h-00 for nsis@ietf.org; Sat, 25 Oct 2003 03:14:05 -0400 Received: from utrhcs.cs.utwente.nl ([130.89.10.247]) by ietf-mx with esmtp (Exim 4.12) id 1ADIce-00024e-00 for nsis@ietf.org; Sat, 25 Oct 2003 03:14:04 -0400 Received: from zeus.cs.utwente.nl (zeus.cs.utwente.nl [130.89.10.12]) by utrhcs.cs.utwente.nl (8.12.10/8.12.9) with ESMTP id h9P7DYSd004328; Sat, 25 Oct 2003 09:13:34 +0200 (MET DST) Received: from janus.cs.utwente.nl (janus [130.89.10.26]) by zeus.cs.utwente.nl (8.12.10/8.12.9) with ESMTP id h9P7DWFx011493; Sat, 25 Oct 2003 09:13:32 +0200 (MEST) Received: (from nobody@localhost) by janus.cs.utwente.nl (8.11.7+Sun/8.10.2) id h9P7DW625138; Sat, 25 Oct 2003 09:13:32 +0200 (MEST) Date: Sat, 25 Oct 2003 09:13:32 +0200 (MEST) Message-Id: <200310250713.h9P7DW625138@janus.cs.utwente.nl> X-Authentication-Warning: janus.cs.utwente.nl: nobody set sender to karagian using -f To: taylor@nortelnetworks.com Subject: Re: [NSIS] RMD in the Analysis draft Received: from 195.241.169.43 (auth. user karagian@imap2.cs.utwente.nl) by webmail.cs.utwente.nl with HTTP; Sat, 25 Oct 2003 07:13:31 +0000 X-IlohaMail-Blah: karagian@ewi.utwente.nl X-IlohaMail-Method: mail() [mem] X-IlohaMail-Dummy: moo X-Mailer: IlohaMail/0.8.10 (On: webmail.cs.utwente.nl) In-Reply-To: <3F995CA3.2080006@nortelnetworks.com> From: karagiannis Bounce-To: karagiannis CC: nsis@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Of course, but at the IETF meeting we could discuss the used rejection method On 10/24/2003, "Tom Taylor" wrote: >Just remember that what happens at meetings is not definitive -- it's >what is decided on the list that counts. > >Georgios Karagiannis wrote: > >> Hi Jukka >> >> I see this as a new defined criterion (during last week) >> and therefore, I would very much appreciate if we could discuss it >> during the next IETF meeting. >> >> Best Regards, >> Georgios >> >> >> ----- Original Message ----- >> From: "Jukka MJ Manner" >> To: "Georgios Karagiannis" >> Cc: "John Loughney" ; >> Sent: Friday, October 24, 2003 10:17 AM >> Subject: Re: [NSIS] RMD in the Analysis draft >> >> >> >>>Hi Georgios, >>> >>>a few quick comments, >>> >>>a) re-read the 2nd paragraph of my email, >>> >>>b) see my follow-up email about adding new stuff, and >>> >>>c) AFAIK, "no objections" != "yes" >>> >>>Cheers, >>>Jukka >>> >>>On Fri, 24 Oct 2003, Georgios Karagiannis wrote: >>> >>> >>>>Hi Jukka >>>> >>>>What I found very strange is that during the last IETf meeting >>>>you have asked me to send the RMD text to the NSIS WG list. >>>>The sent text has been commented and after that there were no objections >>>>of including the >>>>RMD text into the analysis draft. >>>> >>>>One week before the deadline a new criterion on this is introduced. >>>>I think that the people that are following the NSIS WG list have had no >>>>time to react on this new criterion. >>>> >>>>By the way if we want to be fair in this WG then the criterion that is >>>>requested to be >>>>used for RMD it should also be used for all other proposals included in >> >> the >> >>>>analysis draft. >>>> >>>>Best regards, >>>>Georgios >>>> >>>>----- Original Message ----- >>>>From: "Jukka MJ Manner" >>>>To: "Lars.Westberg" >>>>Cc: "John Loughney" ; >>>>Sent: Friday, October 24, 2003 9:26 AM >>>>Subject: Re: [NSIS] RMD in the Analysis draft >>>> >>>> >>>> >>>>>I knew this type of comment was coming... I knew it, I knew it... :) >>>>> >>>>>Lasse, >>>>> >>>>>AFAIK, there is no voting in the IETF, only rough consensus. The >> >> Analysis >> >>>>>draft is now a year old and it should be closed pretty soon now. We >> >> need >> >>>>>to put an end to constantly editing the document, otherwise we will >> >> never, >> >>>>>ever, get it done. Thus, I understood that John was clearly asking the >> >> WG >> >>>>>consensus on what is still needed to be included into the document. >> >> There >> >>>>>is no problem what so ever to include more protocols, including RMD >> >> and >> >>>>>many, many others, and do more analysis, if there is a rough consensus >>>>>that more work is needed. AFAIK, rough consensus is not fulfilled if >> >> only >> >>>>>a group with a subjective view of an issue support it. >>>>> >>>>>To me, it sounds like there is a rough consensus about the current set >> >> of >> >>>>>protocols. I base this view on the fact that the draft has been out >> >> for a >> >>>>>year now and there has not been comments about removing existing >>>>>evaluations, although, from the initial list of protocols, ITSUMO was >>>>>dropped. >>>>> >>>>>Cheers, >>>>>Jukka >>>>> >>>>>On Fri, 24 Oct 2003, Lars.Westberg wrote: >>>>> >>>>> >>>>>>Hi! >>>>>>Do you have a list of how many people >>>>>>that is in favour of each proposal in the analsysis draft ? >>>>>>I have not seen any voting in the working group regarding which >> >> proposal >> >>>>>>that should be included. Should we inittiate such discussion ? >>>>>> >>>>>>- Lasse >>>>>>john.loughney@nokia.com wrote: >>>>>> >>>>>> >>>>>>>Hi all, >>>>>>> >>>>>>>I am concerned that only one person has spoken up in favor of >>>>>>>adding RMD in the Analysis draft (besides the backers of the >>>>>>>technology). Unless there is sufficient interest in the subject, >>>>>>>I propose we do not add it to the Analysis draft. >>>>>>> >>>>>>>thanks, >>>>>>>John >>>>>>> >>>>>>>_______________________________________________ >>>>>>>nsis mailing list >>>>>>>nsis@ietf.org >>>>>>>https://www1.ietf.org/mailman/listinfo/nsis >>>>>> >>>>>> >>>>>>_______________________________________________ >>>>>>nsis mailing list >>>>>>nsis@ietf.org >>>>>>https://www1.ietf.org/mailman/listinfo/nsis >>>>>> >>>>> >>>>> >>>>>_______________________________________________ >>>>>nsis mailing list >>>>>nsis@ietf.org >>>>>https://www1.ietf.org/mailman/listinfo/nsis >>>>> >>>> >>>> >>> >>>_______________________________________________ >>>nsis mailing list >>>nsis@ietf.org >>>https://www1.ietf.org/mailman/listinfo/nsis >>> >> >> >> >> _______________________________________________ >> nsis mailing list >> nsis@ietf.org >> https://www1.ietf.org/mailman/listinfo/nsis >> > > >_______________________________________________ >nsis mailing list >nsis@ietf.org >https://www1.ietf.org/mailman/listinfo/nsis Dr. ir. Georgios Karagiannis Group: Design and Analysis of Communication Systems (DACS) University of Twente The Netherlands _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Sat Oct 25 07:52:24 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03294 for ; Sat, 25 Oct 2003 07:52:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADMxe-0006Q1-CX for nsis-archive@odin.ietf.org; Sat, 25 Oct 2003 07:52:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9PBq2QR024667 for nsis-archive@odin.ietf.org; Sat, 25 Oct 2003 07:52:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADMxc-0006PM-Sz; Sat, 25 Oct 2003 07:52:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADMwp-0006N2-PB for nsis@optimus.ietf.org; Sat, 25 Oct 2003 07:51:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03283 for ; Sat, 25 Oct 2003 07:51:02 -0400 (EDT) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ADMwo-0004N2-00 for nsis@ietf.org; Sat, 25 Oct 2003 07:51:10 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1ADMwo-0004Mz-00 for nsis@ietf.org; Sat, 25 Oct 2003 07:51:10 -0400 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id h9PBp8I21376 for ; Sat, 25 Oct 2003 14:51:08 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Sat, 25 Oct 2003 14:51:04 +0300 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Sat, 25 Oct 2003 14:51:08 +0300 Received: from esebe002.NOE.Nokia.com ([172.21.138.17]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Sat, 25 Oct 2003 14:51:07 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Sat, 25 Oct 2003 14:51:07 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: [NSIS] RMD in the Analysis draft Date: Sat, 25 Oct 2003 14:51:05 +0300 Message-ID: Thread-Topic: [NSIS] RMD in the Analysis draft Thread-Index: AcOZ+ZIQOIRHh2RQRR2nQE8x/u5eVAA9JSgg To: Cc: X-OriginalArrivalTime: 25 Oct 2003 11:51:07.0555 (UTC) FILETIME=[46B33730:01C39AEE] Content-Transfer-Encoding: quoted-printable Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi Lars, > Do you have a list of how many people > that is in favour of each proposal in the analsysis draft ? > I have not seen any voting in the working group regarding=20 > which proposal > that should be included. Should we inittiate such discussion ? If you feel that anything in the analysis should be removed, then please speak up. I want to avoid having material in the analysis which would be of no use for the working group. thanks, John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Sat Oct 25 07:55:24 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03402 for ; Sat, 25 Oct 2003 07:55:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADN0Y-0006si-ML for nsis-archive@odin.ietf.org; Sat, 25 Oct 2003 07:55:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9PBt23P026407 for nsis-archive@odin.ietf.org; Sat, 25 Oct 2003 07:55:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADN0Y-0006rZ-Ab; Sat, 25 Oct 2003 07:55:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADN0J-0006lp-IP for nsis@optimus.ietf.org; Sat, 25 Oct 2003 07:54:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03364 for ; Sat, 25 Oct 2003 07:54:38 -0400 (EDT) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ADN0I-0004Ou-00 for nsis@ietf.org; Sat, 25 Oct 2003 07:54:46 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1ADN0I-0004Or-00 for nsis@ietf.org; Sat, 25 Oct 2003 07:54:46 -0400 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id h9PBsjI29269 for ; Sat, 25 Oct 2003 14:54:45 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Sat, 25 Oct 2003 14:54:44 +0300 Received: from esebe015.NOE.Nokia.com ([172.21.138.54]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Sat, 25 Oct 2003 14:54:44 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe015.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Sat, 25 Oct 2003 14:54:44 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: [NSIS] RMD in the Analysis draft Date: Sat, 25 Oct 2003 14:54:43 +0300 Message-ID: Thread-Topic: [NSIS] RMD in the Analysis draft Thread-Index: AcOaCg9wk0ouPI5fTDGljJtZYz7SuQA5EHuA To: Cc: X-OriginalArrivalTime: 25 Oct 2003 11:54:44.0405 (UTC) FILETIME=[C7F3E650:01C39AEE] Content-Transfer-Encoding: quoted-printable Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi Jukka, > As an editor of the draft, I don't want to be pressured from = individual > groups supporting their protocols (no offense intended, and you are = not > the only one trying to pressure me), but rather want to see the WG ask = for > new content to the draft. I am trying to do what the whole WG, or most = of > the people, some rough consensus, wants. I am happy to do what the WG, = the > Chair, or the ADs want to be done. I am not happy to do what small > individual groups with their own agenda want me to do. This is a WG draft, meaning that the contents are bound by consensus. = If there is not consensus to support material in the document, I am not sure it should be included. Generally, I feel that the material should be useful and of interest to the working group. I have been asking the WG to = consider several proposals, and if it is of interest to the WG. Thanks for trying to work your way through this issue. thanks, John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Sun Oct 26 06:30:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15096 for ; Sun, 26 Oct 2003 06:30:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADj5y-000266-1q for nsis-archive@odin.ietf.org; Sun, 26 Oct 2003 06:30:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9QBU6T1008058 for nsis-archive@odin.ietf.org; Sun, 26 Oct 2003 06:30:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADj5u-00025M-F8; Sun, 26 Oct 2003 06:30:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADj56-00022e-TO for nsis@optimus.ietf.org; Sun, 26 Oct 2003 06:29:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15030 for ; Sun, 26 Oct 2003 06:29:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ADj52-0002VP-00 for nsis@ietf.org; Sun, 26 Oct 2003 06:29:08 -0500 Received: from utrhcs.cs.utwente.nl ([130.89.10.247]) by ietf-mx with esmtp (Exim 4.12) id 1ADj51-0002VL-00 for nsis@ietf.org; Sun, 26 Oct 2003 06:29:08 -0500 Received: from utip105 (utip105.cs.utwente.nl [130.89.13.76]) by utrhcs.cs.utwente.nl (8.12.10/8.12.9) with SMTP id h9QBSWSd023239; Sun, 26 Oct 2003 12:28:32 +0100 (MET) Message-ID: <004c01c39bb4$4a9c1f30$4c0d5982@dynamic.cs.utwente.nl> From: "Georgios Karagiannis" To: Cc: References: Subject: Re: [NSIS] RMD in the Analysis draft Date: Sun, 26 Oct 2003 12:28:34 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4922.1500 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4925.2800 Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi John Please note that another analysis draft has been proposed to the WG long ago, the draft: draft-demeer-nsis-analysis-03.txt See also: http://www.ietf.org/mail-archive/ietf-announce/Current/msg21225.html That draft have been written by several NSIS members, not only by the inventors of the RMD concept. During the last WG meeting that we have discussed the "demeer" draft it was proposed to co-operate with Jukka on writing the WG analysis draft. At that time, (and among other issues), we did not have time to proceed on this. Best Regards, Georgios ----- Original Message ----- From: To: Cc: Sent: Saturday, October 25, 2003 12:54 PM Subject: RE: [NSIS] RMD in the Analysis draft > Hi Jukka, > > > As an editor of the draft, I don't want to be pressured from individual > > groups supporting their protocols (no offense intended, and you are not > > the only one trying to pressure me), but rather want to see the WG ask for > > new content to the draft. I am trying to do what the whole WG, or most of > > the people, some rough consensus, wants. I am happy to do what the WG, the > > Chair, or the ADs want to be done. I am not happy to do what small > > individual groups with their own agenda want me to do. > > This is a WG draft, meaning that the contents are bound by consensus. If there > is not consensus to support material in the document, I am not sure it > should be included. Generally, I feel that the material should be useful > and of interest to the working group. I have been asking the WG to consider > several proposals, and if it is of interest to the WG. Thanks > for trying to work your way through this issue. > > thanks, > John > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Sun Oct 26 15:20:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27331 for ; Sun, 26 Oct 2003 15:20:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADrMw-0001Fu-Hs for nsis-archive@odin.ietf.org; Sun, 26 Oct 2003 15:20:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9QKK91W004810 for nsis-archive@odin.ietf.org; Sun, 26 Oct 2003 15:20:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADrMp-0001EO-7a; Sun, 26 Oct 2003 15:20:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADrM1-0001B2-0c for nsis@optimus.ietf.org; Sun, 26 Oct 2003 15:19:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27253 for ; Sun, 26 Oct 2003 15:19:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ADrLz-0000M6-00 for nsis@ietf.org; Sun, 26 Oct 2003 15:19:11 -0500 Received: from infres.enst.fr ([137.194.192.1]) by ietf-mx with esmtp (Exim 4.12) id 1ADrLz-0000M3-00 for nsis@ietf.org; Sun, 26 Oct 2003 15:19:11 -0500 Received: from pcluu (pcluu.enst.fr [137.194.7.121]) by infres.enst.fr (Postfix) with SMTP id 47D851906 for ; Sun, 26 Oct 2003 21:19:10 +0100 (MET) Message-ID: <008101c39bfe$6b63b1c0$7907c289@pcluu> From: "Thanh Tra LUU" To: Date: Sun, 26 Oct 2003 21:19:06 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_007E_01C39C06.CA0B9780" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: [NSIS] draft-luu-ntlp-con-imp-00 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_007E_01C39C06.CA0B9780 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear all, We have written a draft of NTLP as an effort to contribute to the NSIS = working group. We tried to synthesise the discussions in our group and = develop the ideas to write this draft. You can reach it at = http://www.ietf.org/internet-drafts/draft-luu-ntlp-con-imp-00.txt Best regards and thank you for your attention. Nary Tra ----- Original Message -----=20 From: Thanh Tra LUU=20 To: internet-drafts@ietf.org=20 Cc: john.loughney@nokia.com=20 Sent: Thursday, October 16, 2003 8:04 PM Subject: draft-luu-ntlp-con-imp-00 Title : NTLP Considerations and Implementation Author(s) : Thanh Tra Luu et al. Filename : draft-luu-ntlp-con-imp-00.txt Pages : 43 Date : 2003-10-16 Abstract : The working group NSIS (Next Step In Signaling) is created with the ambition to define a new signaling protocol. This signaling = protocol will be generic and applicable to the most of present and future signaling applications. Some of these signaling applications are resource reservation, communication protocol for middlebox, VPN, = etc. The intention of NSIS is to re-use, where appropriate, the protocol mechanisms of RSVP while at the same time simplifying it and = applying a more general signaling model. =20 NSIS signaling protocol is composed of two layers. NTLP (NSIS Transport Layer Protocol) layer is responsible for transporting signaling messages. NSLP (NSIS Signaling Layer Protocol) is the = upper layer which contains functionality such as message formats and sequences, specific to a particular signaling application. =20 This document outlines the proposal of implementation for NTLP which can satisfy the requirements defined in the NSIS working group. ------=_NextPart_000_007E_01C39C06.CA0B9780 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Dear all,
 
We have written a draft of NTLP as = an effort=20 to contribute to the NSIS working group. We tried=20 to synthesise the discussions in our group and develop the = ideas to=20 write this draft.
 
You can reach it at http://www.ietf.org/internet-drafts/draft-luu-ntlp-con-imp-00.txt
 
Best regards and thank you for your=20 attention.
 
Nary Tra
----- Original Message -----
From:=20 Thanh Tra LUU =
Sent: Thursday, October 16, = 2003 8:04=20 PM
Subject: = draft-luu-ntlp-con-imp-00

 
Title : NTLP=20 Considerations and Implementation
Author(s) : Thanh Tra = Luu et=20 al.
Filename : draft-luu-ntlp-con-imp-00.txt
Pages : 43
Date = :=20 2003-10-16
 

 Abstract = :

 

 The working group NSIS (Next = Step In=20 Signaling) is created with the

 =20 ambition to define a new signaling protocol.  This signaling=20 protocol

 =20 will be generic and applicable to the most of present and=20 future

 =20 signaling applications. Some of these signaling applications=20 are

 =20 resource reservation, communication protocol for middlebox, = VPN,=20 etc.

 =20 The intention of NSIS is to re-use, where appropriate, the=20 protocol

 =20 mechanisms of RSVP while at the same time simplifying it and=20 applying

 =20 a more general signaling = model.

 

 =20 NSIS signaling protocol is composed of two layers. NTLP=20 (NSIS

 =20 Transport Layer Protocol) layer is responsible for=20 transporting

 =20 signaling messages. NSLP (NSIS Signaling Layer Protocol) is the = upper

 =20 layer which contains functionality such as message formats=20 and

 =20 sequences, specific to a particular signaling=20 application.

 

 =20 This document outlines the proposal of implementation for NTLP=20 which

  can satisfy the requirements = defined in=20 the NSIS working=20 group.

------=_NextPart_000_007E_01C39C06.CA0B9780-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Mon Oct 27 04:10:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02358 for ; Mon, 27 Oct 2003 04:10:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AE3O1-0001lF-EW for nsis-archive@odin.ietf.org; Mon, 27 Oct 2003 04:10:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9R9A53W006770 for nsis-archive@odin.ietf.org; Mon, 27 Oct 2003 04:10:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AE3O0-0001l0-13; Mon, 27 Oct 2003 04:10:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AE3NC-0001fo-2j for nsis@optimus.ietf.org; Mon, 27 Oct 2003 04:09:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02315 for ; Mon, 27 Oct 2003 04:09:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AE3N9-0001Rx-00 for nsis@ietf.org; Mon, 27 Oct 2003 04:09:11 -0500 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 1AE3N8-0001Ru-00 for nsis@ietf.org; Mon, 27 Oct 2003 04:09:10 -0500 Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id h9R999Ss027153; Mon, 27 Oct 2003 10:09:10 +0100 (MET) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Mon, 27 Oct 2003 10:08:52 +0100 Message-ID: From: =?ISO-8859-1?Q?Attila_B=E1der_=28IJ/ETH=29?= To: john.loughney@nokia.com, jmanner@cs.Helsinki.FI Cc: nsis@ietf.org Subject: RE: [NSIS] RMD in the Analysis draft Date: Mon, 27 Oct 2003 09:49:39 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="ISO-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Hi All, My understanding was that there was consensus in the last IETF meeting to include RMD in the analysis draft, after which we proposed a text for it. QoS-NSLP draft, which will be one of the basic NSIS documents, contains RMD concept, that is why I think it is important to include it in the Analysis draft. Of course until we do not get more feedback from independent persons, positive or negative, it is difficult to decide if there is consensus. Best regards, Attila > -----Original Message----- > From: nsis-admin@ietf.org [mailto:nsis-admin@ietf.org]On Behalf Of > john.loughney@nokia.com > Sent: Saturday, October 25, 2003 1:55 PM > To: jmanner@cs.Helsinki.FI > Cc: nsis@ietf.org > Subject: RE: [NSIS] RMD in the Analysis draft > > > Hi Jukka, > > > As an editor of the draft, I don't want to be pressured > from individual > > groups supporting their protocols (no offense intended, and > you are not > > the only one trying to pressure me), but rather want to see > the WG ask for > > new content to the draft. I am trying to do what the whole > WG, or most of > > the people, some rough consensus, wants. I am happy to do > what the WG, the > > Chair, or the ADs want to be done. I am not happy to do what small > > individual groups with their own agenda want me to do. > > This is a WG draft, meaning that the contents are bound by > consensus. If there > is not consensus to support material in the document, I am not sure it > should be included. Generally, I feel that the material > should be useful > and of interest to the working group. I have been asking the > WG to consider > several proposals, and if it is of interest to the WG. Thanks > for trying to work your way through this issue. > > thanks, > John > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Mon Oct 27 04:34:22 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03465 for ; Mon, 27 Oct 2003 04:34:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AE3lD-0003jL-JE for nsis-archive@odin.ietf.org; Mon, 27 Oct 2003 04:34:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9R9Y3Vk014309 for nsis-archive@odin.ietf.org; Mon, 27 Oct 2003 04:34:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AE3lB-0003iY-CU; Mon, 27 Oct 2003 04:34:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AE3kj-0003cd-Nd for nsis@optimus.ietf.org; Mon, 27 Oct 2003 04:33:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03435 for ; Mon, 27 Oct 2003 04:33:22 -0500 (EST) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AE3kg-0001si-00 for nsis@ietf.org; Mon, 27 Oct 2003 04:33:30 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AE3kg-0001sY-00 for nsis@ietf.org; Mon, 27 Oct 2003 04:33:30 -0500 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id h9R9XUI02441 for ; Mon, 27 Oct 2003 11:33:30 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 27 Oct 2003 11:33:29 +0200 Received: from esebe003.NOE.Nokia.com ([172.21.138.39]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 27 Oct 2003 11:33:28 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 27 Oct 2003 11:33:27 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: [NSIS] RE: I-D ACTION:draft-ietf-nsis-qos-nslp-00.txt Date: Mon, 27 Oct 2003 11:33:26 +0200 Message-ID: Thread-Topic: I-D ACTION:draft-ietf-nsis-qos-nslp-00.txt Thread-Index: AcOBRBcPl1Qg7D7aQICHHEx/AeBG9wXbK5+wACwH+VAAQIFfIACCfTKw To: , X-OriginalArrivalTime: 27 Oct 2003 09:33:27.0697 (UTC) FILETIME=[60446810:01C39C6D] Content-Transfer-Encoding: quoted-printable Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi Jerry, > Section 2.2 defines a 'QoS model' and Section 2.1 states that=20 > the QSpec object contains the QoS parameters defined in the=20 > QoS model. Also Section 2.2 proposes a QSpec template that=20 > would allow specification of common QoS parameters in=20 > different QoS models. >=20 > It seems that this NSLP model envisions multiple QoS models=20 > being defined for use by the NSLP. Is that correct? If so,=20 > are there any examples yet of proposed QoS models, and if so,=20 > is there an I-D defining the QoS model? =20 >=20 > Also, is it intended that folks would now start to propose=20 > Standards Track QoS Models in the NSIS working group? Or if=20 > not, what is the intention to develop QoS models? My opinion about this is that there are already a number of QoS models specified outside of the IETF, for example the=20 ITU, 3GPP, etc. I do not think it wise for the IETF to make there own QoS model, but to allow consenting peers to use the QoS NSLP=20 with particular QoS models. I think one way to acheive this is to use IANA registries to register QoS models, and the QoS NSLP to signal these. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Mon Oct 27 05:05:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04610 for ; Mon, 27 Oct 2003 05:05:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AE4FH-0006DP-7Q for nsis-archive@odin.ietf.org; Mon, 27 Oct 2003 05:05:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9RA57kX023876 for nsis-archive@odin.ietf.org; Mon, 27 Oct 2003 05:05:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AE4FB-0006CB-Gq; Mon, 27 Oct 2003 05:05:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AE4EG-00069R-0N for nsis@optimus.ietf.org; Mon, 27 Oct 2003 05:04:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04554 for ; Mon, 27 Oct 2003 05:03:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AE4EC-0002CZ-00 for nsis@ietf.org; Mon, 27 Oct 2003 05:04:00 -0500 Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81]) by ietf-mx with esmtp (Exim 4.12) id 1AE4EC-0002CV-00 for nsis@ietf.org; Mon, 27 Oct 2003 05:04:00 -0500 Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5] helo=irams1.ira.uka.de) by iramx2.ira.uni-karlsruhe.de with esmtp (Exim 3.30 #10 (Debian)) id 1AE4E3-0004EB-00; Mon, 27 Oct 2003 11:03:51 +0100 Received: from i72ms1.tm.uni-karlsruhe.de ([141.3.70.16] helo=smtp.ipv6.tm.uni-karlsruhe.de ident=8) by irams1.ira.uka.de with esmtp (Exim 3.30 #7 (Debian)) id 1AE4E3-0003pS-00; Mon, 27 Oct 2003 11:03:51 +0100 Received: from vorta.ipv6.tm.uni-karlsruhe.de ([3ffe:400:20:6:2e0:29ff:fe3e:c87] ident=mail) by smtp.ipv6.tm.uni-karlsruhe.de with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.12) id 1AE4E1-0007BU-00; Mon, 27 Oct 2003 11:03:49 +0100 Received: from localhost ([::1] helo=vorta.ipv6.tm.uni-karlsruhe.de ident=bless) by vorta.ipv6.tm.uni-karlsruhe.de with smtp (Exim 4.05) id 1AE4E1-0003X3-00; Mon, 27 Oct 2003 11:03:49 +0100 Date: Mon, 27 Oct 2003 11:03:49 +0100 From: Roland Bless To: Paulo Mendes Cc: sven.van_den_bosch@alcatel.be, nsis@ietf.org Subject: Re: [NSIS] QoS-NSLP comments Message-Id: <20031027110349.68fba2bd.bless@tm.uka.de> In-Reply-To: <3F995519.6040809@docomolab-euro.com> References: <3F995519.6040809@docomolab-euro.com> Organization: Institute of Telematics, University of Karlsruhe X-Mailer: Sylpheed version 0.9.6claws (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Paulo, > - Policy Object: Policy in QoS related issues leads me to think more > about dropping of packets that do not comply with some QoS profile, > than with authentication issues. What you think of is _policing_ (at the network edge), not policy. While policing is part of traffic conditioning (DiffServ terminology), policy is important to let providers express their administrative preferences by a rule set. Thus, you have to consider not only resource based-admission control, but also policy-based admission control (see also rap WG). The latter determines whether the user has administrative permission to make a reservation (see policy control definition in nslp draft). For example: customer A is not allowed to make reservations for a certain service class X, but is allowed to make a reservation for service class Y from 08:00 till 18:00. Therefore, you also need to know the user's identity and that's where authentication comes in. Regards, Roland _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Mon Oct 27 06:16:21 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06932 for ; Mon, 27 Oct 2003 06:16:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AE5Lw-0005Z9-6e for nsis-archive@odin.ietf.org; Mon, 27 Oct 2003 06:16:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9RBG4M8021384 for nsis-archive@odin.ietf.org; Mon, 27 Oct 2003 06:16:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AE5Lu-0005YX-DP; Mon, 27 Oct 2003 06:16:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AE5Lk-0005Xh-KZ for nsis@optimus.ietf.org; Mon, 27 Oct 2003 06:15:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06918 for ; Mon, 27 Oct 2003 06:15:39 -0500 (EST) From: sven.van_den_bosch@alcatel.be Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AE5Lg-00038M-00 for nsis@ietf.org; Mon, 27 Oct 2003 06:15:48 -0500 Received: from [195.207.101.250] (helo=bt0g2p.god.bel.alcatel.be) by ietf-mx with esmtp (Exim 4.12) id 1AE5Lg-00038J-00 for nsis@ietf.org; Mon, 27 Oct 2003 06:15:48 -0500 Received: from bemail04.net.alcatel.be (bemail04.net.alcatel.be [138.203.144.6]) by bt0g2p.god.bel.alcatel.be (8.12.10/8.12.10) with ESMTP id h9R9IUr2029695; Mon, 27 Oct 2003 10:18:30 +0100 Subject: Re: [NSIS] RE: I-D ACTION:draft-ietf-nsis-qos-nslp-00.txt To: "Ash, Gerald R (Jerry), ALABS" Cc: , "Ash, Gerald R (Jerry), ALABS" X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: Date: Mon, 27 Oct 2003 12:15:14 +0100 X-MIMETrack: Serialize by Router on BEMAIL04/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 10/27/2003 12:15:17 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Scanned-By: MIMEDefang 2.37 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Hi Jerry, Thanks for your comment. I have replied inline. Best regards, Sven "Ash, Gerald R (Jerry), ALABS" @ietf.org on 24/10/2003 21:24:59 Sent by: nsis-admin@ietf.org To: cc: "Ash, Gerald R (Jerry), ALABS" Subject: [NSIS] RE: I-D ACTION:draft-ietf-nsis-qos-nslp-00.txt Nice document, well done IMO. I'd like to clarify a point in the draft: Section 2.2 defines a 'QoS model' and Section 2.1 states that the QSpec object contains the QoS parameters defined in the QoS model. Also Section 2.2 proposes a QSpec template that would allow specification of common QoS parameters in different QoS models. It seems that this NSLP model envisions multiple QoS models being defined for use by the NSLP. Is that correct? If so, are there any examples yet of proposed QoS models, and if so, is there an I-D defining the QoS model? Sven>> Correct. We want the QoS-NSLP to be capable of signaling for multiple (all?) QoS models. There are essentially two ways to support multiple QoS models: 1. By example: with every new QoS models that is defined, new parameters and extensions are needed for QoS NSLP 2. By template: we define a framework now in which currently known QoS models (IntServ, DiffServ, RMD, ...) can be fit. Hopefully, this will reduce or eliminate the need for extensions later on. Currently, there is an QoS model appendix in the draft. The QoS model itself is not a part of the QoS-NSLP specification per se but I believe the NSIS QoS work is not finished without it. Until we get a better feel of the WG preference on this, we intend to keep it as an appendix. Also, is it intended that folks would now start to propose Standards Track QoS Models in the NSIS working group? Or if not, what is the intention to develop QoS models? Sven>> This is WG/chair/charter discussion. We haven't gone there (yet). Thanks in advance, Jerry Ash AT&T -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: Monday, September 22, 2003 2:46 PM Cc: nsis@ietf.org Subject: I-D ACTION:draft-ietf-nsis-qos-nslp-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Next Steps in Signaling Working Group of the IETF. Title : NSLP for Quality-of-Service signaling Author(s) : S. Van den Bosch et al. Filename : draft-ietf-nsis-qos-nslp-00.txt Pages : 30 Date : 2003-9-22 This draft describes an NSIS Signaling Layer Protocol (NSLP) for signaling QoS reservations in the Internet. It is in accordance with the framework and requirements developed in NSIS. Together with the NTLP, it provides functionality similar to RSVP and extends it. The QoS-NSLP is independent of the underlying QoS specification or architecture and provides support for different reservation models. It is simplified by the elimination of support for multicast flows. This version of the draft focuses on the basic protocol structure. It identifies the different message types and describes the basic operation of the protocol to create, refresh, modify and teardown a reservation or to obtain information on the characteristics of the associated data path. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nsis-qos-nslp-00.txt _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Mon Oct 27 06:27:17 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07366 for ; Mon, 27 Oct 2003 06:27:17 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AE5WV-0006S0-Vf for nsis-archive@odin.ietf.org; Mon, 27 Oct 2003 06:27:00 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9RBQx9q024778 for nsis-archive@odin.ietf.org; Mon, 27 Oct 2003 06:26:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AE5WV-0006RY-OM; Mon, 27 Oct 2003 06:26:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AE5Vf-0006Ol-Rh for nsis@optimus.ietf.org; Mon, 27 Oct 2003 06:26:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07335 for ; Mon, 27 Oct 2003 06:25:54 -0500 (EST) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AE5Vb-0003Eq-00 for nsis@ietf.org; Mon, 27 Oct 2003 06:26:03 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AE5Vb-0003Em-00 for nsis@ietf.org; Mon, 27 Oct 2003 06:26:03 -0500 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id h9RBQ4I14095 for ; Mon, 27 Oct 2003 13:26:04 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 27 Oct 2003 13:26:05 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 27 Oct 2003 13:26:03 +0200 Received: from esebe010.NOE.Nokia.com ([172.21.138.49]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 27 Oct 2003 13:26:03 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe010.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 27 Oct 2003 13:19:38 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: [NSIS] RE: I-D ACTION:draft-ietf-nsis-qos-nslp-00.txt Date: Mon, 27 Oct 2003 13:19:38 +0200 Message-ID: Thread-Topic: [NSIS] RE: I-D ACTION:draft-ietf-nsis-qos-nslp-00.txt Thread-Index: AcOce+Vc3d5WSUB2TGWXjeqPC0BDJwAAC5OA To: , Cc: , X-OriginalArrivalTime: 27 Oct 2003 11:19:39.0063 (UTC) FILETIME=[35E5B470:01C39C7C] Content-Transfer-Encoding: quoted-printable Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi, Some comments: > > Also, is it intended that folks would now start to propose Standards = Track > > QoS Models in the NSIS working group? Or if not, what is the = intention to > > develop QoS models? >=20 > Sven>> This is WG/chair/charter discussion. We haven't gone=20 > there (yet). Right now, NSIS is not chartered to work on QoS models. After we have = achieved our initial charter goals, rechartering to do new work is always = possible. thanks, John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Mon Oct 27 06:31:22 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07588 for ; Mon, 27 Oct 2003 06:31:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AE5aT-0006rH-GE for nsis-archive@odin.ietf.org; Mon, 27 Oct 2003 06:31:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9RBV5ZI026346 for nsis-archive@odin.ietf.org; Mon, 27 Oct 2003 06:31:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AE5aQ-0006qE-ML; Mon, 27 Oct 2003 06:31:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AE5aG-0006oy-GJ for nsis@optimus.ietf.org; Mon, 27 Oct 2003 06:30:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07548 for ; Mon, 27 Oct 2003 06:30:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AE5aC-0003JK-00 for nsis@ietf.org; Mon, 27 Oct 2003 06:30:48 -0500 Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx with esmtp (Exim 4.12) id 1AE5aB-0003It-00 for nsis@ietf.org; Mon, 27 Oct 2003 06:30:47 -0500 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Mon, 27 Oct 2003 11:30:16 -0000 Message-ID: From: "Hancock, Robert" To: "'john.loughney@nokia.com'" , gash@att.com, nsis@ietf.org Subject: RE: [NSIS] RE: I-D ACTION:draft-ietf-nsis-qos-nslp-00.txt Date: Mon, 27 Oct 2003 11:30:19 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , hi john, jerry, all, my personal view is that there is not a big value in the ietf repeating the (very extensive) QoS definition work that has been done in other bodies. *however*, working out how to support this work using the protocols defined by NSIS may not be a totally trivial activity. to give one example, there is some requirements work which identifies the need to indicate qos ranges, or to indicate pre-emption, etc. should those requirements be mapped into the NSLP, or into the QoS model? in other words, while I agree that the standardisation aspects of this problem should be soluble by having the right IANA considerations defined in the NSLP, there is actually a very important validation activity (which ideally should take place during NSLP design) to make sure that it is feasible to use the NSLP to signal these things - in other words, that the IANA considerations have been written correctly in the first place (e.g we have the right registries available). how, when and where this validation should be done is of course another question. robert h. > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > Sent: Monday, October 27, 2003 09:33 > To: gash@att.com; nsis@ietf.org > Subject: RE: [NSIS] RE: I-D ACTION:draft-ietf-nsis-qos-nslp-00.txt > > > Hi Jerry, > > > Section 2.2 defines a 'QoS model' and Section 2.1 states that > > the QSpec object contains the QoS parameters defined in the > > QoS model. Also Section 2.2 proposes a QSpec template that > > would allow specification of common QoS parameters in > > different QoS models. > > > > It seems that this NSLP model envisions multiple QoS models > > being defined for use by the NSLP. Is that correct? If so, > > are there any examples yet of proposed QoS models, and if so, > > is there an I-D defining the QoS model? > > > > Also, is it intended that folks would now start to propose > > Standards Track QoS Models in the NSIS working group? Or if > > not, what is the intention to develop QoS models? > > My opinion about this is that there are already a number of > QoS models specified outside of the IETF, for example the > ITU, 3GPP, etc. I do not think it wise for the IETF to make > there own QoS model, but to allow consenting peers to use the > QoS NSLP > with particular QoS models. I think one way to acheive this is to > use IANA registries to register QoS models, and the QoS NSLP > to signal these. > > John > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Mon Oct 27 09:55:23 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17183 for ; Mon, 27 Oct 2003 09:55:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AE8lq-0002RL-TL for nsis-archive@odin.ietf.org; Mon, 27 Oct 2003 09:55:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9REt2TW009362 for nsis-archive@odin.ietf.org; Mon, 27 Oct 2003 09:55:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AE8lq-0002QV-6F; Mon, 27 Oct 2003 09:55:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AE8lN-0002OG-9j for nsis@optimus.ietf.org; Mon, 27 Oct 2003 09:54:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17144 for ; Mon, 27 Oct 2003 09:54:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AE8lL-00066m-00 for nsis@ietf.org; Mon, 27 Oct 2003 09:54:31 -0500 Received: from courier.cs.helsinki.fi ([128.214.9.1] helo=mail.cs.helsinki.fi) by ietf-mx with esmtp (Exim 4.12) id 1AE8lK-00066j-00 for nsis@ietf.org; Mon, 27 Oct 2003 09:54:30 -0500 Received: from mannersaari.cs.Helsinki.FI (mannersaari.cs.helsinki.fi [::ffff:128.214.11.173]) (IDENT: jmanner, TLS: TLSv1/SSLv3,168bits,DES-CBC3-SHA) by mail.cs.helsinki.fi with esmtp; Mon, 27 Oct 2003 16:54:29 +0200 Date: Mon, 27 Oct 2003 16:54:25 +0200 (EET) From: Jukka MJ Manner To: nsis@ietf.org Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [NSIS] Analysis draft version -03 changes Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi all, The new version of the analysis document was submitted in time. Here is the list of changes done for the -03 version. I'll now try to go through the whole document with time and see whether there is something that still needs more work. If I don't find, and neither anyone else, major issues, my only question for the meeting in Minneapolis will be "To keep or not to keep the Appendix about RSVP vs. NSIS Requirements" If there are other issues, like missing protocols or subjective text, let me know. The summary needs more work, but that shouldn't be an issue for the Minneapolis meeting itself. Regards, Jukka - Changed the "Michael Welzl" reference to: Michael Welzl organized a special session "ABR to the Internet" in SCI 2001, and gathered some inputs for requesting an "ABR to the Internet" BOF in IETF#51, which was intended to introduce explicit rate feedback related mechanisms for the Internet (e2e, edge2edge) but failed because of "missing community interest". - The link ("His continued efforts are documented at http://www.welzl.at/ptp.") was not added because I couldn't find anything relevant from the given web page. - Issue 1 about what to do with the Appendix: nothing was done (=kept) since there was no input from the list. - Added the proposed texts about inter-domain issues, nanely SICAP and DARIS. - Issue 7, added a reference that shows the performance of YESSIR in Section 6.2.1. The reference was actually mentioned in the references-list, but not in the text. - Added a reference to Tenet - Splitted the references into Normative and Non-Normative - Added a summary (soft of) _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Mon Oct 27 11:55:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24747 for ; Mon, 27 Oct 2003 11:55:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEAe2-0006i2-AZ for nsis-archive@odin.ietf.org; Mon, 27 Oct 2003 11:55:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9RGt6D7025773 for nsis-archive@odin.ietf.org; Mon, 27 Oct 2003 11:55:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEAdy-0006ge-HC; Mon, 27 Oct 2003 11:55:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEAd9-0006d6-Tq for nsis@optimus.ietf.org; Mon, 27 Oct 2003 11:54:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24692 for ; Mon, 27 Oct 2003 11:53:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEAd8-0000Ig-00 for nsis@ietf.org; Mon, 27 Oct 2003 11:54:10 -0500 Received: from tokyo.netlab.nec.de ([195.37.70.2] helo=tokyo.ccrle.nec.de) by ietf-mx with esmtp (Exim 4.12) id 1AEAd8-0000I7-00 for nsis@ietf.org; Mon, 27 Oct 2003 11:54:10 -0500 Received: from tokyo.ccrle.nec.de (localhost [127.0.0.1]) by tokyo.ccrle.nec.de (8.12.9-20030927/8.12.9) with ESMTP id h9RGrZ2o003871 for ; Mon, 27 Oct 2003 17:53:35 +0100 (CET) Received: (from defang@localhost) by tokyo.ccrle.nec.de (8.12.9-20030927/8.12.8/Submit) id h9RGmXvs003615 for ; Mon, 27 Oct 2003 17:48:33 +0100 (CET) X-Authentication-Warning: tokyo.ccrle.nec.de: defang set sender to using -f Received: from venus.office (venus.office [10.1.1.11]) by pluto.office (8.12.9/8.12.9+MIMEDefang) with ESMTP id h9RGmW2o003612; Mon, 27 Oct 2003 17:48:33 +0100 (CET) Received: from [10.1.1.130] (brunner.office [10.1.1.130]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 828C3A980D; Mon, 27 Oct 2003 17:13:14 +0100 (CET) Date: Mon, 27 Oct 2003 17:48:31 +0100 From: Marcus Brunner Reply-To: Marcus Brunner To: =?ISO-8859-1?Q?Attila_B=E1der_=28IJ=2FETH=29?= , john.loughney@nokia.com, jmanner@cs.Helsinki.FI Cc: nsis@ietf.org Subject: RE: [NSIS] RMD in the Analysis draft Message-ID: <33090020.1067276911@[10.1.1.130]> In-Reply-To: References: X-Mailer: Mulberry/3.0.2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: MIMEDefang 2.35 Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > My understanding was that there was consensus in the last IETF meeting to > include RMD in the analysis draft, That was my understanding as well. Marcus _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Oct 28 00:54:21 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13691 for ; Tue, 28 Oct 2003 00:54:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEMns-0004pd-5Z for nsis-archive@odin.ietf.org; Tue, 28 Oct 2003 00:54:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9S5s4uI018553 for nsis-archive@odin.ietf.org; Tue, 28 Oct 2003 00:54:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEMno-0004oT-Vj; Tue, 28 Oct 2003 00:54:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEMnK-0004mF-IF for nsis@optimus.ietf.org; Tue, 28 Oct 2003 00:53:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13664 for ; Tue, 28 Oct 2003 00:53:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEMnH-00008T-00 for nsis@ietf.org; Tue, 28 Oct 2003 00:53:27 -0500 Received: from courier.cs.helsinki.fi ([128.214.9.1] helo=mail.cs.helsinki.fi) by ietf-mx with esmtp (Exim 4.12) id 1AEMnH-00008Q-00 for nsis@ietf.org; Tue, 28 Oct 2003 00:53:27 -0500 Received: from mannersaari.cs.Helsinki.FI (mannersaari.cs.helsinki.fi [::ffff:128.214.11.173]) (IDENT: jmanner, TLS: TLSv1/SSLv3,168bits,DES-CBC3-SHA) by mail.cs.helsinki.fi with esmtp; Tue, 28 Oct 2003 07:53:27 +0200 Date: Tue, 28 Oct 2003 07:53:27 +0200 (EET) From: Jukka MJ Manner To: nsis@ietf.org Subject: RE: [NSIS] RMD in the Analysis draft In-Reply-To: <33090020.1067276911@[10.1.1.130]> Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit (I'm REALLY getting tired of this...) Hi, from the official NSIS meeting minutes: Georgios: - Could we add RMD to the draft? Jukka: - Please send text to the mailing list. Have been asking for text for months. There was a request to submit text and see whether people are interested. Nothing was said about actually putting that straight into the analysis document. Regards, Jukka On Mon, 27 Oct 2003, Marcus Brunner wrote: > > My understanding was that there was consensus in the last IETF meeting to > > include RMD in the analysis draft, > > That was my understanding as well. > > Marcus > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Oct 28 03:00:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06223 for ; Tue, 28 Oct 2003 03:00:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEOlt-0002nu-6a for nsis-archive@odin.ietf.org; Tue, 28 Oct 2003 03:00:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9S806SI010751 for nsis-archive@odin.ietf.org; Tue, 28 Oct 2003 03:00:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEOll-0002me-1o; Tue, 28 Oct 2003 03:00:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEOlS-0002lj-Py for nsis@optimus.ietf.org; Tue, 28 Oct 2003 02:59:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06123 for ; Tue, 28 Oct 2003 02:59:25 -0500 (EST) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEOlJ-00047Z-00 for nsis@ietf.org; Tue, 28 Oct 2003 02:59:33 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AEOlI-00047Q-00 for nsis@ietf.org; Tue, 28 Oct 2003 02:59:33 -0500 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id h9S7xXI23835 for ; Tue, 28 Oct 2003 09:59:33 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 28 Oct 2003 09:59:31 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 28 Oct 2003 09:59:31 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] RMD in the Analysis draft Date: Tue, 28 Oct 2003 09:59:31 +0200 Message-ID: Thread-Topic: [NSIS] RMD in the Analysis draft Thread-Index: AcOdF/ZJGl8YvCSlQOGwAKkeT7og0AAEPPRw To: , X-OriginalArrivalTime: 28 Oct 2003 07:59:31.0374 (UTC) FILETIME=[6B2B84E0:01C39D29] Content-Transfer-Encoding: quoted-printable Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi all, > from the official NSIS meeting minutes: >=20 > > Georgios:=20 > - Could we add RMD to the draft? >=20 > Jukka: > - Please send text to the mailing list. Have been asking for text for=20 > months. > >=20 > There was a request to submit text and see whether people are = interested.=20 > Nothing was said about actually putting that straight into the = analysis=20 > document. On a procedural note, all decisions made during IETF meetings need to confirmed on the mailing list. =20 Specifically, I am still looking to see what level of interest there is=20 for the NSIS WG for RMD text in the Analysis draft. For example, does=20 this provide useful information that will help the authors of the NSIS=20 protocols in making design decisions? Does the community consider RMD a significant signaling protocol for us to consider? I think this criterial should also apply for all of the protocols = covered in the Analysis draft. thanks, John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Oct 28 04:17:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11152 for ; Tue, 28 Oct 2003 04:17:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEPyM-0001nz-Mq for nsis-archive@odin.ietf.org; Tue, 28 Oct 2003 04:17:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9S9H6NR006931 for nsis-archive@odin.ietf.org; Tue, 28 Oct 2003 04:17:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEPyJ-0001nB-7t; Tue, 28 Oct 2003 04:17:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEPyB-0001mS-Ct for nsis@optimus.ietf.org; Tue, 28 Oct 2003 04:16:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11125 for ; Tue, 28 Oct 2003 04:16:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEPy8-000648-00 for nsis@ietf.org; Tue, 28 Oct 2003 04:16:52 -0500 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 1AEPy7-000642-00 for nsis@ietf.org; Tue, 28 Oct 2003 04:16:51 -0500 Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id h9S9GeI2027340; Tue, 28 Oct 2003 10:16:44 +0100 (MET) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Tue, 28 Oct 2003 10:16:44 +0100 Message-ID: From: =?ISO-8859-1?Q?Attila_B=E1der_=28IJ/ETH=29?= To: Paulo Mendes Cc: nsis@ietf.org, sven.van_den_bosch@alcatel.be Subject: RE: [NSIS] QoS-NSLP comments Date: Tue, 28 Oct 2003 10:16:52 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="ISO-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Hi Paulo, I tried to answer some of your points, please see my comments inline. Best regards, Attila > -----Original Message----- > From: Paulo Mendes [mailto:mendes@docomolab-euro.com] > Sent: Friday, October 24, 2003 6:37 PM > To: sven.van_den_bosch@alcatel.be > Cc: nsis@ietf.org > Subject: [NSIS] QoS-NSLP comments > > > Hi Sven, > > Some general comments about the QoS-NSLP draft: > > a) Terminology: > - Why isn't a reduced-state QNE defined? I think it is, 4th from last. > - Policy Object: Policy in QoS related issues leads me to > think more about dropping of packets that do not comply with > some QoS profile, than with authentication issues. > > b) On section 1.1 it is said that "The design of QoS-NSLP is > conceptually similar to RSVP...". How can these two concepts > be similar when QoS-NSLP uses peer-to-peer messages and RSVP > uses end-to-end messages? > > c) On section 2.5 it is said "In order to allow some local > selection of which QoS Model to use without destroying all > end-to-end aspects of the signalling QoS-NSLP allows a > nesting of QoS Models by 'stacking' more than one pair of > Control Information / QSpec object within a message". > Shouldn't this sentence be more general to allow the stacking > of QSpec instances within the same QoS model? For example, in > DiffServ type of QoS models, one statefull edge router might > use the same message to signal another statefull edge router, > while signalling all reduced-state interior routers in the > path. Since QSpec to signal edge routers might be different > from the one to signal interior routers, these models might > need to stack edge-QSpec inside interior-QSpec. > Another question about this issue is: How much related with > section 7.3.2 (tunnel management) is section 2.5 (nested > protocol operation)? > Well you are right, it could be better formulated. I think the description is based on the assumption that QoS model is defined by QSpec and Control Info. I think both nesting of QoS models and nesting of QSpec objects are needed. The connection with tunnel management is that QoS model or QSpec object, used outside the tunnel, can be tunneled. > d) Reverse Path State: On section 2.7 it is said that a > stateless and reduced state QNEs will be able to provide the > underlying NTLP with some information, namely reverse path > state. How can this be done in the case of stateless > operation, in which QNEs are supposed to keep no state? Why > can't QNEs operating in a statefull mode provide also the > NTLP with such information? > I think it is not said. It is said that QNEs provide info about the NSLP stateless (reduced state) situation. > e) Peer-to-peer routing of NSLP messages: On section 6.2 it > is said "There are several circumstances where it is > necessary for a QNE to identify the adjacent QNE peer...". > Shouldn't this knowledge be useful in any circumstances? > Since the next QNE can be more than one hop away, information > about the next QNE needs to be kept by the QNE: not only the > SII to identify the source of the application message but > also the identification of the downstream peer. Considering > that the next QNE can also be more than one NTLP hope away, > why should SII be kept by the NTLP, as said in section 3.1? > Also about this topic, nothing is said about the discovery of > next-peer QNE. > > Cheers > Paulo > > > > -- > Paulo Mendes > DoCoMo Communications Laboratories Europe GmbH > Landsberger Str. 312 > 80687 Munich, Germany > Tel. +49-89-56824-226 > Fax. +49-89-56824-300 > E-mail: mendes@docomolab-euro.com > http://www.docomoeurolabs.de/ > > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Oct 28 04:22:24 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11343 for ; Tue, 28 Oct 2003 04:22:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEQ39-0002Nq-ID for nsis-archive@odin.ietf.org; Tue, 28 Oct 2003 04:22:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9S9M3l7009127 for nsis-archive@odin.ietf.org; Tue, 28 Oct 2003 04:22:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEQ38-0002MY-1W; Tue, 28 Oct 2003 04:22:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEQ2f-0002KY-9U for nsis@optimus.ietf.org; Tue, 28 Oct 2003 04:21:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11321 for ; Tue, 28 Oct 2003 04:21:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEQ2c-00067p-00 for nsis@ietf.org; Tue, 28 Oct 2003 04:21:30 -0500 Received: from utrhcs.cs.utwente.nl ([130.89.10.247]) by ietf-mx with esmtp (Exim 4.12) id 1AEQ2b-00067k-00 for nsis@ietf.org; Tue, 28 Oct 2003 04:21:29 -0500 Received: from utip105 (utip105.cs.utwente.nl [130.89.13.76]) by utrhcs.cs.utwente.nl (8.12.10/8.12.9) with SMTP id h9S9LNSd006242; Tue, 28 Oct 2003 10:21:23 +0100 (MET) Message-ID: <003801c39d34$dbd95720$4c0d5982@dynamic.cs.utwente.nl> From: "Georgios Karagiannis" To: , References: Subject: Re: [NSIS] RMD in the Analysis draft Date: Tue, 28 Oct 2003 10:21:24 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4922.1500 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4925.2800 Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi John In my opinion, several concepts can be used in designing the NSIS protocols. Some solution hints used in the RMD concept, can be usefull in designing the NSIS protocols. Therefore, I am in favour of including a RMD short description (with references) into the NSIS analysis draft. Best Regards, Georgios ----- Original Message ----- From: To: ; Sent: Tuesday, October 28, 2003 8:59 AM Subject: RE: [NSIS] RMD in the Analysis draft > Hi all, > > > from the official NSIS meeting minutes: > > > > > > Georgios: > > - Could we add RMD to the draft? > > > > Jukka: > > - Please send text to the mailing list. Have been asking for text for > > months. > > > > > > There was a request to submit text and see whether people are interested. > > Nothing was said about actually putting that straight into the analysis > > document. > > On a procedural note, all decisions made during IETF meetings need > to confirmed on the mailing list. > > Specifically, I am still looking to see what level of interest there is > for the NSIS WG for RMD text in the Analysis draft. For example, does > this provide useful information that will help the authors of the NSIS > protocols in making design decisions? Does the community consider > RMD a significant signaling protocol for us to consider? > > I think this criterial should also apply for all of the protocols covered > in the Analysis draft. > > thanks, > John > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Oct 28 05:09:22 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11344 for ; Tue, 28 Oct 2003 04:22:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEQ3A-0002Oj-N1 for nsis-archive@odin.ietf.org; Tue, 28 Oct 2003 04:22:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9S9M441009181 for nsis-archive@odin.ietf.org; Tue, 28 Oct 2003 04:22:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEQ39-0002Np-PU; Tue, 28 Oct 2003 04:22:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEQ33-0002M5-RN for nsis@optimus.ietf.org; Tue, 28 Oct 2003 04:21:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11326 for ; Tue, 28 Oct 2003 04:21:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEQ2o-000683-00 for nsis@ietf.org; Tue, 28 Oct 2003 04:21:42 -0500 Received: from utrhcs.cs.utwente.nl ([130.89.10.247]) by ietf-mx with esmtp (Exim 4.12) id 1AEQ2o-000680-00 for nsis@ietf.org; Tue, 28 Oct 2003 04:21:42 -0500 Received: from utip105 (utip105.cs.utwente.nl [130.89.13.76]) by utrhcs.cs.utwente.nl (8.12.10/8.12.9) with SMTP id h9S9LfSd006275; Tue, 28 Oct 2003 10:21:41 +0100 (MET) Message-ID: <003901c39d34$e698ce20$4c0d5982@dynamic.cs.utwente.nl> From: "Georgios Karagiannis" To: , References: Subject: Re: [NSIS] RMD in the Analysis draft Date: Tue, 28 Oct 2003 10:21:42 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4922.1500 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4925.2800 Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi John In my opinion, several concepts can be used in designing the NSIS protocols. Some solution hints used in the RMD concept, can be usefull in designing the NSIS protocols. Therefore, I am in favour of including a RMD short description (with references) into the NSIS analysis draft. Best Regards, Georgios ----- Original Message ----- From: To: ; Sent: Tuesday, October 28, 2003 8:59 AM Subject: RE: [NSIS] RMD in the Analysis draft > Hi all, > > > from the official NSIS meeting minutes: > > > > > > Georgios: > > - Could we add RMD to the draft? > > > > Jukka: > > - Please send text to the mailing list. Have been asking for text for > > months. > > > > > > There was a request to submit text and see whether people are interested. > > Nothing was said about actually putting that straight into the analysis > > document. > > On a procedural note, all decisions made during IETF meetings need > to confirmed on the mailing list. > > Specifically, I am still looking to see what level of interest there is > for the NSIS WG for RMD text in the Analysis draft. For example, does > this provide useful information that will help the authors of the NSIS > protocols in making design decisions? Does the community consider > RMD a significant signaling protocol for us to consider? > > I think this criterial should also apply for all of the protocols covered > in the Analysis draft. > > thanks, > John > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Oct 28 10:24:24 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29329 for ; Tue, 28 Oct 2003 10:24:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEVhW-0002aI-38 for nsis-archive@odin.ietf.org; Tue, 28 Oct 2003 10:24:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9SFO6kd009933 for nsis-archive@odin.ietf.org; Tue, 28 Oct 2003 10:24:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEVhR-0002Ze-15; Tue, 28 Oct 2003 10:24:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEVgi-0002R5-Me for nsis@optimus.ietf.org; Tue, 28 Oct 2003 10:23:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29263 for ; Tue, 28 Oct 2003 10:22:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEVgb-0005XL-00 for nsis@ietf.org; Tue, 28 Oct 2003 10:23:09 -0500 Received: from [202.20.142.13] (helo=ns.sait.samsung.co.kr) by ietf-mx with esmtp (Exim 4.12) id 1AEVga-0005WQ-00 for nsis@ietf.org; Tue, 28 Oct 2003 10:23:08 -0500 Received: from LocalHost (localhost [127.0.0.1]) by ns.sait.samsung.co.kr (8.12.10/8.12.1) with SMTP id h9SFMZlr015587 for ; Wed, 29 Oct 2003 00:22:35 +0900 (KST) From: "Sung Hycuk Lee" To: Date: Wed, 29 Oct 2003 00:22:44 +0900 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0002_01C39DB2.C5BF6460" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: [NSIS] Mobility Functions in the NTLP/QoS-NSLP Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_0002_01C39DB2.C5BF6460 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 DQpIaSBKb2huIGFuZCBhbGwsDQoNCkkgc3VibWl0dGVkIHRoZSBmb2xsb3dpbmcgdXBkYXRlZCBk cmFmdHMgY29uY2VybmluZw0KICJNb2JpbGl0eSBGdW5jdGlvbnMgaW4gdGhlIE5UTFAvUW9TLU5T TFAiOg0KIA0KIC0gZHJhZnQtamVvbmctbnNpcy1tb2JpbGl0eS1udGxwLTAxLnR4dA0KIC0gZHJh ZnQtbGVlLW5zaXMtbW9iaWxpdHktbnNscC0wMS50eHQNCg0KVGhlc2UgZHJhZnRzIGRpc2N1c3Nl ZCB0aGUgZm9sbG93aW5nIGlzc3VlcyBpbiBlYWNoIGxheWVyOg0KDQoxLiBJbnRlcmFjdGlvbnMg d2l0aCB0aGUgTlRMUCBhbmQgdGhlIE5TTFAgaW4gbW9iaWxpdHkgc3VwcG9ydA0KICAgQS4gV2hh dCBzaG91bGQgdGhlIE5UTFAgZG8gZm9yIHRoZSBOU0xQIE5PVCB0byB0cmlnZ2VyIGFuIGVycm9y IG1lc3NhZ2UgDQogICAgICAgaW5kaWNhdGluZyCRQ2FuLU5vdC1CZS1Gb3J3YXJkZWQtdG8tdGhl LUxBU1RfTk9ERSAoZS5nLiwgTU4pkiBhZnRlciBoYW5kb3Zlcj8NCiAgIEIuIFdoYXQgc2hvdWxk IHRoZSBOVExQIGRvIGZvciB0aGUgTlNMUCB0byBpbW1lZGlhdGVseSByZS1lc3RhYmxpc2ggaXRz IHN0YXRlcyANCiAgICAgICBhZnRlciBoYW5kb3Zlcj8NCiAgIEMuIFdoYXQgc2hvdWxkIHRoZSBO VExQIGRvIGZvciB0aGUgTlNMUCB0byB0ZWFyZG93biB0aGUgb2xkIHN0YXRlcyANCiAgICAgICBv biB0aGUgb2Jzb2xldGUgcGF0aCBhZnRlciBoYW5kb3Zlcj8NCg0KMi4gQ3Jvc3NvdmVyIE5vZGUg RGlzY292ZXJ5DQogICBBLiBJZiB0aGUgbWVyZ2luZyBwb2ludCBvZiB0aGUgb2xkIGFuZCBuZXcg cGF0aHMgY2FuIG5vdCBwZXJmb3JtIE5TSVMgZnVuY3Rpb25hbGl0eSwgDQogICAgICAgaG93IGRv ZXMgdGhlIE5UTFAgZmluZCB0aGUgTlNJUy1hd2FyZSBjcm9zc292ZXIgTm9kZSANCiAgICAgICBv biB0aGUgam9pbnRlZC9jb21tb24gcGF0aD8NCiAgIEIuIEhvdyBkb2VzIHRoZSBOVExQIG9mIGEg Q2FuZGlkYXRlIEFjY2VzcyBSb3V0ZXIgKEFSKSBmaW5kIHRoZSBjYW5kaWRhdGUgICAgDQogICAg ICAgQ3Jvc3NvdmVyIE5vZGUgdG8gZmFzdCByZS1lc3RhYmxpc2ggdGhlIGV4aXN0aW5nIE5TTFAg c3RhdGUgZHVyaW5nIGhhbmRvdmVyPw0KDQozLiAgRGVhZCBQZWVyIERpc2NvdmVyeQ0KICAgQS4g SWYgdGhlIGNyb3Nzb3ZlciBub2RlIGZhaWxzLCBob3cgZG9lcyB0aGUgTlRMUCBkZXRlY3QgZmFp bHVyZSBvZiB0aGUgQ3Jvc3NvdmVyIE5vZGUgDQogICAgICAgYW5kIGZpbmQgYW4gYXBwcm9wcmlh dGUgbmV3IENyb3Nzb3ZlciBOb2RlPw0KIA0KNC4gSW50ZXJ3b3JraW5nIHdpdGggTW9iaWxpdHkg cHJvdG9jb2xzDQogIEEuIEhvdyBkb2VzIHRoZSBOVExQIGluIHRoZSBjdXJyZW50IEFSIGludGVy YWN0IHdpdGggQ0FSRA0KICAgICAgdG8gZmFzdCByZS1lc3RhYmxpc2ggaXRzIGFzc29jaWF0ZWQg TlNMUCBzdGF0ZXM/DQogIEIuIEhvdyBkb2VzIHRoZSBOVExQIGluIEN1cnJlbnQgQVIgaW50ZXJh Y3Qgd2l0aCBDVCANCiAgICAgIHRvIHNlbmQgaXRzIGFzc29jaWF0ZWQgZXhpc3RpbmcgTlNMUCBz dGF0ZXMgdG8gdGhlIGNhbmRpZGF0ZSBBUj8NCg0KNS4gU3RhdGUgTWFuYWdlbWVudA0KICBBLiBI b3cgKGFuZCB3aGVuKSBjYW4gdGhlIFFvUy1OU0xQIGFkanVzdCB0aGUgcmVmcmVzaCB0aW1lciB2 YWx1ZSBhY2NvcmRpbmcNCiAgICAgdG8gbmV0d29yayBlbnZpcm9ubWVudD8NCiAgQi4gSXMgaXQg bmVjZXNzYXJ5IHRvIHNldCB0aGUgcmVmcmVzaCB0aW1lciB2YWx1ZSBpbiBhIHdpcmVsZXNzIG5l dHdvcmsgdG8gYSBzbWFsbGVyIA0KICAgICAgdmFsdWUgdGhhbiB0aGF0IGluIHRoZSBjb3JlICh3 aXJlZCkgbmV0d29yaz8NCg0KNi4gUW9TLU5TTFAgc3RhdGUgUmUtZXN0YWJsaXNobWVudA0KICBB LiBIb3cgZG9lcyB0aGUgUW9TLU5TTFAgaW50ZXJhY3Qgd2l0aCB0aGUgTlRMUCB0byBmYXN0IHJl LWVzdGFibGlzaCB0aGUgUW9TLU5TTFAgDQogICAgICBzdGF0ZXMgYWZ0ZXIgaGFuZG92ZXI/DQog IEIuIEhvdyBjYW4gdGhlIGRlbGF5ZWQgc2lnbmFsaW5nIHByb2JsZW0gYmUgc29sdmVkIGluIGEg cmVjZWl2ZXItaW5pdGlhdGVkIGFwcHJvYWNoPw0KDQogUGxlYXNlLCBjb21tZW50IGluIG91ciBk cmFmdHMsDQoNClRoYW5rcyBhbmQgUmVnYXJkcywNCg0KU3VuZy1IeXVjayBMZWUvIFNlb25nLUhv IEplb25nDQo= ------=_NextPart_000_0002_01C39DB2.C5BF6460 Content-Type: application/x-zip-compressed; name="draft-jeong-nsis-mobility-ntlp-01.zip" Content-Disposition: attachment; filename="draft-jeong-nsis-mobility-ntlp-01.zip" Content-Transfer-Encoding: base64 UEsDBBQABAAIANJeXC9rgO4ZPSYAAEuCAAAlAAAAZHJhZnQtamVvbmctbnNpcy1tb2JpbGl0eS1u dGxwLTAxLnR4dNU92XLbSJLvHdv/UOGXFmNJWofvfRlKpmy6JVpLyuPpdTgmimCRRAsE2Dgks79+ 86oDICi5Z6yIXSncLRJAVlZW3plV+Pmnn38aDa/P1dh8K9W0NJtCxamaxstUJ3G6VN/xM+2rDyZL lz//9DnLb/Chd3lWbR56bM/P+0/nU8ApLU2emrL3NteL8qFn2n4Aqwtjfv5p+G0T56Z4owabPE7U 8YuuOj48fPbQ4/7nQ1+dapzdQzc+/HP6gXF66L57f6aDy+mn8Ts1GF3/65A+RmU2M7k6fknkOPn5 J/xtvfUym8VJXG7VeZVGZZylxCHlyqjx9cVVy0NzXLLe78gSvbSIi95aIPTSMtn0Do/65bcSh5uW uqwKlS0AWlyoS7POBItr/DzPompt0lLB3zpVDZbQ6RwvACqLKklUlKWLLF/rNDLqLi5XBEbDhU2e 3cYFoQ0DTQ1NQR0d4qfJ+dnx4fGLvoxaHwEGzQGWsLRFRtA17mY1TJdxakweC49c6+JGnWc5IHKA otXpqpiB6aLLaMNHC3eJolL01TgrDcDVpcoAek6Q+Jpa6y3MpMjUPC7KPJ5VZRtaumjif9+0aI2C p29B2ucKKKg0jPctXldrnGgRf1PrLC1XBdMTkEdsZkZVm7kuzbyrcrNJdIR/wcPZrMgSA9+r2ZYn EmKIi7YlQGW8Nn01KnkF9QYWCaRTIwkyVRVmF+cCBlqY3MD6EoQ13AxPJDgqPBPFRD6zllGBkik+ 9AQJhUwCIyxBDRT9J47FjEqAoDjNqMpzZLTmqBEAgbnqKIInYVIwg1VZbt48fUog7u7u+rEpF/0s Xz7FP54exfOensEq6QjoD2zebxmtwcjTlZ5nd+otaCkQyjw2beMSEBm7NmxBT/dX5Trph8LTGOQu BlEwpAoVsH9dF9KDZ9lmm8fLVYmsGCOVCZj/+uCsQ9NwjD/NIkBjqw5QgXT6agBDTPDWQk1MYfJb MyfIAyFISIrsDhZpaVKTwxImegufrFKZjqa4WmUWZYkqKljYLhAkSYAO9jrDyXVabLK8VBf0/JV9 5gD1Ekod8lZp0jk+mbEimANV7bjMiQ4KYgzzJiEonP1bwwropQEJ/ZgaK/uA07pAOsIHgmKXdm4K oDAIkgHNBuxGwKyqRISsKoSJbXDUPq0WwfDqbg7/jRfICJusKOJZYvxzizYljJyS5XOrgWCyeMU9 k5s/KkCLpRAxWlSIXTBLS2/WGf6X7HpXwWLrpB/qeLGqDxnVL1dAO3X09eef/mOPTb/fujhAzl45 W3WtkS5A87MMF7kshL2O+qTx8mxesarv/+VfdSKQjtS1yddxmiXZcqsefG4vpOO+aGEtU0QLJdwM k3wICkF6TpBO4K+3oGB5amjCMjQHZ6DugNBnuipY9zqytkB6QZCewV9nOfBXdgt0HWcgGQdnk3EH FFER4XdtzzYgvSRIzwknPVdXYAWDxw/eXr3tfB/V1GuC9MLSyZo3opObi5Xw4h5IR0cE6SVAAltf 5fgccEgBQpVrJv6D2AikY4L0CiFV67XO/yUOIEgnzkuaWCN23xzugfTMQRpU5SrLi1/UYD5Hw/YX IR49d5CQ4qBeo7ICXQw03pgciIa23it/dNVEgexAelnXGf/e74/ROMePoXFAs4SKBb9S32fOdhVt 3bCx1rZ3/8uGjZ1GweL7DRvOQNPqE4DdW8hjZLjo2qFQwuzAgAFyPFn3DLuJm00SRyxtsJQ6WqmV vkWI6PlmdynP0weZ9XkSjAPUjB315fgrI7jW5OnzimlaPzHG1rSW5CCT7rFYOK+SxktBxxXE13ir SeJbw8a5ZcZsQtfWpbpsmG0cLxKtgv4ZOgPOO9hxAvh7AkTIfjnpgk6Af8+BiY/gH08yDHl0CeK2 KQkR8QfYc25xBChqQLccohCaG7iOgid8Dngb+ZdCrZq/0a07C+0OBjnf1rFwtxCcu1UMC4wsQsYH 7rFEcjDjtCEHvKbWu6lP7KCXmwQZrbMHlziNkgr4PW5a1ECMLq66sA6BnczJTkZsJyNnJ+2oIInW FhIU5BXHTluEBfZtg/Zt7u2b6S/7csk9TU8yfe2NKLE7Rs1N17leHBtCmJelbV4hCkCyJagVaXvn G8ZFURmMj4hquAAkcgHX3b+4fVZuNWdH+H4weaMGFIWwo5HL92eDyds34G6k8xjDwPo93gWwd4/h 3gxCLNBHKTIzuRv2YjZASDmJj9gye2mCD9Z8FHvl+g37fd9KVpcLhxo4HW/a3BEryQCSpNmE8MbD N8yhQ5C00t47PpdvIZq/0/ncjTEeyYVRGpegYLL8MYzYyWMYMfgSpePNQyrYaas39xsluROJ3krv q7fg8/wB/AlEeoNpnPFQNEYBBgzUMd6R8x1W/YaPMss0HoVI2YD2LmjCu8+zICF4gqOUvw/BFaYx 0H9n054lChAP7SR85YlTX9x///fHsMezx2CP4/49gQreoJQ1IkBhuqmr7oyzUaSVSLpq2nlmyjtj GllDssROW/PKYuaDcl2Y/kA3gi3YmiW2iEyq8zgDp2WQEgywBdka+bfhZ1lOoLzHIs6BOWao9zdo kec0NCheTq8QILAF3kwO0i0DtGAC3Yp3adBIUUzfEMewJajxUoeHhkE3uij8o3T/bayRnwdXI7XI s3WoiQHEJ+BRYvGNNV4a8EkzzAmwV0VJL3DMl7B2NQDdYK0AEjoE7BiZCD1EdL9S1Jkzgw4ZJuxS 65P1Ucsp802vN4npOtNh51NzMDj5568VGB3AWlAG1iIYs240ggnSGmMoyxJFhV4Dmq11dot5vIXK kjkJXk7ZIwZEoNlJJUBiweFu4mS+7FOkliptq4Rpwhx8MsMrxZOgtCUsr9GFX2Y/KZdEva7DZp51 AsUcFpAbPQ9aNnnIusbmFmOoXVozGMmtUmYDwFiXG5SkHRtEXDwU8W6A18n/03UPZ14RBGf4V+ii RpTnnNfdwAgmzih4VB3fh4vu3S6/zHoGgxIY8EgK742iOY/XG1hrdrMQfIgf+39E5pi0OEuz6Gfy alALE9siPrvsYxNrbhSLAMuQA09SuMMaRO1ACoOAwA3F09oXGrAccbLSiNtneeUzzAfz6Jb4tOiO 4TUsRjonj0Y8yIUG5nFfxkwLcVJGV7cvOhzxsTjNPb88ZT5dZRUIDobtnEAXUvbAIgInxQUrcJEU nWTEMjiBO9BNJeH0RxVHN+Bdau9WMh3Picww/KbK4Ypwyo7nDdTXMN3AmxVebgj/QWGMq8E8l1xk XlKdwJQ6TooOlQWI7zLS2bUgAWhfm5hMSuhYxFj94bnZEYGlsiqPJIgFmGx6bmEsTiCmNWJ0nHCI YMSllUob1hGDl0E8x8vghH9pfMgt40hgw1iKhiOsQmTopg5aOz2/pToWUGdmgEY8J88gGHui5igl wW753bMEk8XRCbCWeaKKpUUXrpkZVsBiBeP12syRy5AXUNXUyB0L5+xlJbakhsIrN5zcLQPKqmI0 A+udki3eKoRk8j5q2TnzLy6Bt2ZsBHdDekPuujoYDzuWvLtxXIfNQ3GzYxWu2SpY0Qc1a8DNxwSF VYClxQYGHBZNKjaZxakWmexNmt2BY2NyBwi9Ula2zZEsaKmgMfzH9SCfP4YHedL/Swlq71M2fbxu 06Yd5AY/AxfyipI9s5aOk18NlUuiKsU0AIIqC+zbn94meW8CP43EL+Ug1DEUKI5etui5ryFi7XTI X/E5H1zWTRZjfjRwBmHky3HHoehEuK8u4vQG5ZvyDAuQf6zHHMAXa53C0mDEb9MgBIm1Oy5Dxzs7 LGe6YVnfZ3cw+7zLjGnzB2zrJWWFjAwSHj5XNF0GO7y4LNZ8+Xn9Uvj5yCoOHkqzBGqH/Re/FOxH ZXnDYrBrSX4bxRo1r408x/7usKm1PG6Qu1UQfYg2gXByEWMMCg87rS6gSn0DDwBqzFeLBAQZfSge Ym55A26IVia6sZrRhSNkIRc6Mh1UagTDpmnJ2us5hCLsQ6FNqy0EWsWNzss4qhKNhrEAnpdsqtdG gb8IghlYZDbIIimNyp5iS1EjF4tK63KQ81Qi6WYuu8cYNFzhUKu6kNG5hD5DGPiEbiZ17v3sFmpK aUcJ9PW+eCe27icupGcbDllc/rpmqXhAh+bKJBvgiBplHUMnJTDscrWDaMDbO45e4PkEOeIiXse4 nNZ9RB86qcGURCwmuufxImx2cHNueUocaGCrKOBiYlhXSGah8rInzRtKbkbLFqe3WXLbsnyeeAQE 6Nwrsx7qu6CqQbaQjLfyhrueE+Xqog8s1yZf0rOoNa0aRcOKsTkuUx08wHT4s2hLoglQpuir6/MJ IuL4N4zpPbMFp/FgxUirEBgJZa0Vtt5omeGdTFnuKHEa3sr+2bjjw9LmmIIrqWmy+doFyfD/JGHR r9t+0XzWKw8e+j5nwSHDrjQQRpLFLlJrWxafzxZDuciqVLxBHmWRJcBNuBCS8dnrlvxoB+XFYzgo z/oP1L29S7KT5hKCqhVIFzJULCyHSw6j29qbcCKBybPEhJxxADEuhLXAA1QX4WjA+9hoq4GvPhvX 8oUDsgGxCX+0+tictRNz2RDz7BrtIybpXZwMQ9fEZgv2nkL9pg2X4LUtmxBEruR7FaHH66TV2nC6 5OJjPy4nZzk+8iFRZ4cKDZ2VZBHA/1NyEWu0pugsahdeIVzQBlUUFPQIBg67MnpOGkpHqxjUdKCm AnGdmVCt2KA4sFVsc8LEZTAFyft5WGKynFH1mgJXZTencWDXr40pgkiVucEqCaccJIO2mz1rVRed MMBnKgT1riJb1zM9nP2xfs7lx9PRxej6N6bv7HcQkW7NaHjTw9837JGnofWYROGI12R1EdrY0HGx 48qYPjRfUCgZKgCrKmV93o0ur6ZCuG2S6XkH+YiSqlsKQRtG3HzDGnZcJtt+28hswmB0sPAYx6pb jFmqYtd9hukmcy+aiJ+Von9iTocNPN7kaGJh/JNQ+WcEChlDcbqJsalB4Avsb+jQVQsmYWcqucIw l+ASS05yyUNly9PkQinG34Ng6H5bPCQfinNDonC2i8aXOA3k8jaL59TFW3l7RUBs/GztKN4TW7Z0 eX5yMUEdY4bcSBbS8vVKwpYZliDIvEm5vdxuSJPWQTJPodcQBg6XY4V5EobE7oFwPDzNHstg0pJA iYmXIOzkrh9PewHE4iH5Y4LhvD2U5sGkW8uo1ORUHClxXexjdYwoWsxz8KIVKIokJq9di6sY1IhD FFpZ3sedLRJHmVxOXGrn6t7pbUuGBBsPnYokPUOighpwFW9koXy5qIGF678mIQ81cagndtWQFQ0y QUDMRZU423hf8Z7SkR7fZZLNyHRXafxHxZVG4DqzMVzYdovQyCVwxIkMzL4wKyVMDpS+wUMUojji MgcCY3QRJ6yahK10I3dxlg1azDR9kjUlQNJyvcZKrrYZEksH8Ai0Kzkp8Is16e2aZmc97cmKQTFl ZSluoRv1muQxMW2an1LAsshwpVMvJ7RFkQjO4cI6l2PFYL2bg8AcOVRKtk4JOSrrWnQNkJn/EQRS glUJDY2O2iKOWt2VuLBlZ9ScsuwECTxVbPVoFHn0DpJiPgrpHUbNtp5JpM+GFXw8ShMDN1lO6ob5 gNr3yIo0BHhEJrHSiPWD3kwjDQSvQpRfGzpWvF0nD1EgiNUDSa1JqeXz2mqKcEqw9SMDg5ePERgo tet0Nby7PVax4/IF83mMQyLj2VJJMyO0S+j9PnqZLQ2qTC8OondaFFzsYwwp7bFmHE17+g6TLw9G 3BRng8LjK3I7+0z0CElVGYLEJ0Gx/lKiD8vFLRifZ56CuUFTf1ATjhoSnRAWKUafqfk9QwPzFKi3 ztKnsJSSeXN1BmoVCEb1JcGGBm3L0u9xO4O6U8NG1OxuaJEJQnMaRCmpamCC6AHKM42Z+tdoIbHo 02W2dWhzGsIvuEtQoyA31HLXm82P4p1r21zWqTGguDmS17MzJAQbiQIJIu5bl/tiyJZkcBhEIn0D zzEHH2aZ2lQ9lrt0boMP8y0uSk5H7AiBlRMC0nJdaE+6T5KLor112iKrYjT5oTaZA8e+lCQpWyqr 9NoScNQUYVktrdYzsZ/klwodJXUmG5J2+apJHcv9fTWA4AOHy6ioNoOFY1hNN8622IgR9vZRnGfl fOdLcp0D93Ue+haUoGJ0aJ1rLQaBba5LTsh7PvJo5CLUQdw3mF4nQXC6LIxaXAW00yUZpbwaoMif KIKxSrtds2OSfTe6ccWTuuxpccMW4A3E+PTa4HrFxZpE3coQJ4Q0klgaI2llQj+A4FgXrhFzYrmm JQ1fZwl26QkMV3/8YLxfjJejpVGV8kFfjg6/dnwbusvncw8ljySNlQvug+tJJr5BvyDSAd5zbSke m8GEa+4UcHU5cCO4bjBPRIvhtfry+mvHqfeAO1sxrCclvJEOXdXAIWl2D9StuuuCIAsoKx5WnDG8 K3g6Tsx35hSyZlfko8YOdmJBokm8e9++UHug4RLAAODOxRH5tl7tFCzyVvDA4lFohewLGnbl2Lq1 twIpA4RmA91MYLSmF3H+yE9ttvVy7BbQSniLCaUKpAuRbe0L77NWkhegLHVkUw+U0QCuE4AemPTy he0aYr9DBl/HrNcaCUmXKQpkruMVOcbFrCtRQwKvNUoGoixpGWhf62Nlw189htP7vL9/75blJUdT zy9hekUusmBQN3ygt5v9I/WMpKt22HKuleWgcUQEmb6t1zs4mCVrsosZJ0+QC23TD7os4D6TjXP+ NNi4A8cT7Oewtf84mHSU702xOpsgtabPaq4bBvstxuKAgkt2Tnw1rqjr+06LTXH7D4pQ8TJhMgVO S7wGd8AFquRm5BU1kEq4J2UMyfP4bQQ8I0e/O00baxbC69gY47P4hZWK1FZAnMOICBIkf7PVRae+ h0k6bba2qTXM1NpqwtBag/EI/p1jqZ8Bw3o0+iwTjf5nm0wf4NZDT/eA7Hu7zu2w0wgrZfZLkKKz wfRKfXn2lXM1JbtgqYmXq1lGbotsLHKhS71yGSRAsdXW0afvPCRRTuxdAmUAN1e6DsvxImiFAWdY 76QdmlBys6QMR0sLI1uacJigZo21Z0yOUFoWlT9gvkfWMklZGDXLcKLbDcorK24HGt0IKwsR1bws bS037Gk9ru3f0WlQTEIubHhzmD9pROmR2HBUXOB0gxvAcoYsgOSwIAUdF8N/1x4FMvS8Kz28nHFp g03Xv7JjwTkeETaPAXhuBlIHg7NfO/sHl20SfWoeF8WLI9I8WwbsekTkUTe8gpF8LRk+BLJAHcAF +XLZTSxbCu02W+EVUTkIXRARyni5pZ4Z9nQYDuowfYPb1nLTCtA6NeRqgI7qhkopLFzz05R+T61n ZVfWn7GBHQ/WD9IJwCu8h9AmLxV51njQiNO5NVneK/wN1q4XJmvSJy6ZyISEZDAGgacqBPLTOTWJ oSq0OR6DuVwIjmHGGNIYPAMFGEa2imVpyvGEbyHhLKBNFlthsz1oVA2xdhJlD7C9KWhUcbKyvICY q9gWMDQs7izLMBjnwIYMaIQGs+CaeebCHI5gg6axLqUErMF32WzW0nUNGqch6jVDGxhG32aUstMn ljvH7XDU7LvbfbbbtRLKMptGCH6zuXW4hUtQBsDdz01gPjhmbZO2Tsg0oeVgOynSEkjKuoKHRWeI SIYcw6vpuENGbkp0x+7UBXE1OVYpWbOssVxHbk68NtY64c4/gzlEB9XlNjRypAssFjtUAvoZzgx6 jLc1xeGYz6kEq3SaGDaxq08Nv+JF4aNMis7umsFffpFK65h7W2dLbjuoYDfnmhwVPpzmvokyYWS6 P9bLf/0YXr5S962JJ0ILOakH0PaxMR83LQfloJwgtoWEOxBZyrmgi0FAfX3I5WVZuROY5MOCWmyG fAQIPRPawN4IiWVo7weC8YryeGYTZG6VcQyvwFw/riuoJWG7rtOD9sYOJzfReLJ52O3qc/6b303D DZscieidfk2rMbxs1uvgrA9DwgUSSv25SBI6OAntxkiR2djpqa5rVt9WTZDsBmemgtXbnbYFlmhL ttulskvCOsuhlsKapxQSSLGEMRb7pbEcV9TQKM4dcZx7SU1XblOnCLbV1y1udeiPOOu7N+nn1i1I 2A8mzLl+M4PfpAXzAIuA2ttzMrc1hC06NnvNcDjEDXZ5cCcZh5TU9vpA6x/T17b/BVEvWrn6EQX4 GIsJBE4YRgVZ/UwaSLiriEJdoXBbZibMyvgkQb2wnGGp3Ra1I9z9HZWp4VJ4GHmELiSjwDuNmpvk 9kTUoUzZWFoMXYY7tnfsm9MJTE6Xf69XA0pxizSdskKZdtFtTbMQ+uTsgTImdKKaD2b2utr++TCh 6vaAxi4l0uoDfIcCr2sdrOiWTo2L+y0M7kjwoJ1wrULtvvpf//03baecM3X4GLbzRf+7ziQSOUAh rB9h5qIex77JlpSpNEiQyNUaLXmZ7Qhx6jnZnqzhSmC8mYDCHr1OULzsc8IrIicYuget7HUMRR0z 30ZZtaGz1vDcHwl39pxYYQ3E+SV2GXTVe/k/MB391al5147psI3KBe1kqVp2hcie7SD7Ye8W2aY2 pWbeoH4nqUFJvbhB6yVCaf6Hy6Bz2SfnE22OlcROyCm7veUouxOXYeBW3cZAs20gwGHLHWv32Hev hcb2l0k5zZKr/Jcg6lbnuMrvLYBFSN+Vbb5yJf90p+/UbXSjcrmvaCT7Mi+1Td+1B4DPpDbYqCoy TcC1WGbWuHkoVpUElbk9nRTqy/Gzry4TIzsQQy1Y22SeCj+FVbQaHziek0a4ptf1cO2s5o8FhbSO 81N12qwSHUhmKajcdr6rlimFNLpht/LkK0Yt24B2N6c7lm3u3q8RITAFjUrWwdl1rVBYL8H5PBtB aJTZ8A7wTm0SghMa1IMWLKxPBNQkK2xcFJlyxBJKYWqBFZM7NCIoFbpsOIK1GfEdRpubRG9drg5v pSazjY5ugMWTrBAHxBeWbRIGFMvMLOO0cERZuzZeVFqnkjv/xHWig9NPPnEnOYCzMWVULgfYNUnu pmVW1qGdRtTg6mitvfTpvL7fiXVSoyyFQ/PxB0JiFsCgENNIuiyCPn6C4q8HB3z9JWv/Y6z8oxwn +bK/77zA0LDb9aAEo5DOuUCBsfVxJoz+hTSasgcSiiIjWMK5sjWQ9PXZ5dRmsnDbDQa9wV5x2wSL C28LtPa7Wk9uHBwmRoadHjdppDdFxc8hDHHb3NC13FqauVoDO3vSD8liLqmbGp/Owq335HkzHegu 1hA8DXI4kesZd4nvZcZUuV4k4OR4F8iX+h3KNYLAYBSkk+oUp93ugTBk4u2eujJwYEhHBhVicq5o p0lNo8lU5xk2uUq+rnYWHUGoL/rR668E/svx4deddUaAWGUqqhlqF5BtNjBO3a4hgrWUfgpq2aT2 cIsf+/tjJPJRjlt81bfnbuIntXMouO2twh59UHY3aIvJk5Px/Fln9Y2DrUfj+RN0rflycJqn57Km 33+Crrq659BedIHsmGI49xxmF1jyhw6yI0Dth9k19vi1HmTXFUTKv3pEHeaj0MHhbChKLUPi8+g4 nJDGYKZ2/ayPrqr371BSYmyPd2bE7cz3T4lTQBS45j1nz9EowmffYbbGGm1Xja7gu97oKtCEBH1n 9gKlscOu67U9UmIwGDBJTBn9HxXNRzlEzp9ii59wsKOv8N/TvIKQCZtPwUl+MmmeOu0Pm3NB8xPm Pf7h9wbgyeb82gAQvN7ha3XQPMIdnKNBtcQKCWJkfcovx4gCBElRFt101QRR2PNSizfqPAeHBuHe i8Dirgd0bRt/ajalWVuiOBROEIWzlS5uNFDh/Q4VuEpdueNLp3ZfAe4oCBCBCLDiZg10Erl6Nrp6 0sUXFqiT569O9mLwDDGYRqsq+RM8jdQIFtTC0ON9r72B995a1qSFIoWHx4QBhxXf49BKmkudg+9S Q+p5O1IDSwo8XcOSYiLeDp4mn0V+LwT/nCWU/kOy4JSAIvdh+EdWhFgGcO7H9wXiexm9ReM+B2ar IRuuG3ndiAxqrRbCraM5wWCcEJ20wDdgHLZS7kOVmjoiL0mqMpgdLDgxtB2whXLOFt3L0w8hsYev XrUvIe2qfKPeyb5nq2XUJUUiIVsFKNV0wf4l5JeFHD6wfLtEe42oXmCqKzVg8D4Q/zfOCr2P24lW ovl7UbnZpwNCtegGPwJnT13EZkZrRnrwwVNSH8RB5/OeNUF7sAmVR/sKHqGKvga0soVJ4yUuIJmu t331a56BL57AI/D1ExcGXa8wXCzuY3DPVyXf3Ds83sPbEDDV8UF9fVpFqyQWQg3UWMpQlqUb518T 42fTAItih41mBFE46AFhCwDVUUM9fl511T8QLWclR+zXAJx9L0s6QDJ1Wui0qBpvwtmjPNt5CpX6 r1k2R0qRXavlA4u6lbh9sW+duA0j3vQwB9dbx5vbF73DV/fh0UagH+eaPMoBpgj+CA3OhTGiNGtn uRKxwAvkLXETPY8zK5fCfW1OSWJEKTmG64Em+X5FfoQm5TTXELN01Skg9T/ov3fVBfx5CkuILiji +t7kf2ZL/JtkE9+spddxGiL0xFnIiQE5+TvbcScjB5Pp3686qtdTfwe4eOnI0VCHWngaBvPiWhwf Hz4PTcDR69cv/RzQGgGyS/TwEPF3GrB+C39M7yhwh2/gwxV+ewV/XGcQvBXAsud2MsHol1lCXXgx ukiAMb4YAai3Uh9v+bAG+MK+wGPowl9GM+TK1y+OupbbDg+PPLJosD6bomSldsH6Bai0yQrNmgSH vT1uWew7eQx1Lt3eg9t7eXG7uT3eI7gBjDHm/4Unjz0+aJXeg9OJtOuNiXrYG3DKtAFdPF3FZoWy bV1TtpPGb2XgnylISrWRKhQWDOVNEJLucE7icUiYwEs+3IdIF3RMEafFTdyG1i4itWEh6AWfcquG Cbm6HovDdizQGE1XKA1nfYJ+Sw6En7wo24lZag7LqWRlwzv+sUrC+xAAsaFo0YdvldIAjjVOfrmO 0TgFjjxR46xPHLVZ6WRHq9RWrYmiOO+euxCEd8ecXv5uZydAFE3Vo/pl3sQ3HbJ2YraasONnNY28 X7tTzQg0fItY7n+hXLsWvteG7b49RVCd0ijvM/tKQ0Ux5U11oz6lmGIoJAQ4Zzfk1Wv1GTR5gWWB bLWteOF+y/CdcD1Ufu+2CGcZ9+aZUs+eve69fM1vqPn142Q4kEGvVllq3qj/fHWsTo7Uycmhevbi Gb9+Znip4+SNKlY0/b+tqkXR11H/pnHi/I+yyY9yJKTCN+ggVbdVdOPegOjeY8innc6BS4syLjG7 BfS9NtHKvooAbo57Yp2Rdy/0jG3JFMh+9KwHmm4Mky9M1suR5PHK4HCm2jy8GvKWn/2rcfzqUL1+ /up5bTVKnRdVH7yCvxV6XcBg/Shbu8l+gDFWmX9r5P/jmf6+Ojx++ao/g6m0TvV0myECHzIwAQen Hzr/L1f3xfGLcM6z309O2tf2e35/jBw+yslnCG33RU9T+2onIRAWN+iVsHgGJu1jByeITjVQubPG OBp1OJE6zBWEsnyUjm3Ui8OxNnYsuJO3sef8nkB+dQ29YQpbTxIdr42ryGykJVgS8jGWfhFPKf7n 9hw0vFg6hqqVYQhOvRgmCXiqqVBpTIpt2IUIMSc2ElbcpIW7HRlPAsNoYkMV/SH9+u4k6f/Cxm7O bmOXcIy9ixtYb2NPWZEaMTacrfVc+gUXC6w4leHpJOk2HBqbj5odDwQHl+iXAkkL0kWvGeJzP+l4 OQIpNI7pGLB0jucZ9vBFjDc+S+6+t7VESyYerraxAuCcnl31jo76+F6w2O/0oWWj5KaMyNNzR2yj X7GpZi7nqFM+9FmDi5drOhVJIMkC2NpBHU7XLh1MEXcncceJvCiJ7xXGyWbcSu7fyCULm/EGCWkJ tbUYe5xeJVvENtR3YUo6PpxnNNt69svw+Fxivty/u7ZeGg12HjEuQVshy9bURDmOEOvaK0LpWpze xiV3E5MYwXxpH65GCULK5FKmom0IJfIxk5UlL7IvbSu6WMjnxHMufzbezeXkMZgzAZF5s2zwQTVY egnEzL11amZsiYy6LzZUxYpspwvtImAu66srfs2CPSyGpHq3cYSIMPxmoqqk7nqAY1+OKt7bOb7x t+XldELJH/DOUtUsN1KlGLOHcgAOrrzfbByhQHBFfVHlKR+5brkRCSylM9ArMR7Nd8tv8BUFiBtu SDWlbkHu4sLQ8W3IyKI5Muy0p9OCYn5rR0Mj2k26Odbscfc5Y9Vl4UOUCAzh4d4kPKeu57sVnVJJ b61DPuu6CjUyXx4H2/CYP7Da2vX1bLfrltrqPQuilqRz8KkXCeiJ3QTLXG9on44YCiqA0gn1+L5m 0n0RK5g2kjUOuCYYvihcFiZZhPupuJDO5UcUKNo7ZjeyU4se7zoWdm3BPcMWNPfWRsujTYayC8e6 2V7N8qVOJUTGV+F9w5e64MiyvdeqIOl5tnpwDvNLgAQg5g6U09W8Xtz3JIfCBUbAhp9eC6jGWW0e dQdxwzsaeNuRlMn51Fd5r7MuajJuBYF69UFF4U7cdFlRP7d//zL7VOkSeS9Uckm8jkmhOVVcKOCJ lHpSiH+wqAxXN4a8B+QCtyHAnQ9zm90Y1+DYthxx6TbuicpG6VkC5Yt7RLyhkuR4RxgJq90od4Xn elK6BOjJYKpG0yd0MgOz7fX7oRqNr4eT8fBaTT+egVL7TQ3Gb+sXhuN3o/FwOBmN3zFCg+mv6vzj 5Gyo3o6mZxeD0eVUDS4u1OfBZDIYX4+G064a/uNqMpxO1ceJgjD/YjR82wWIZxef3lowp5+u1fjj tboYXY6uhzDmRxj6NwvkN8BhcE2IfJoO1cdzwQnGvRxcjz6Of6wr+1hndb0fToajsfo8AvLgZGEC SMchTXUyevf+mkiEn4RMARVh1gTkcjg5ew9fDexpSRN1ProeI3nP8WF1NZhcj84+XQwm6urT5Orj dGgzCPUNuoIUzGNus8w4DcyCDefYWuyaQKjjkw9zSbaemYIjYpvc7PLuP/r3xyywnEvxv1BLAQIU ABQABAAIANJeXC9rgO4ZPSYAAEuCAAAlAAAAAAAAAAEAIAAAAAAAAABkcmFmdC1qZW9uZy1uc2lz LW1vYmlsaXR5LW50bHAtMDEudHh0UEsFBgAAAAABAAEAUwAAAIAmAAAAAA== ------=_NextPart_000_0002_01C39DB2.C5BF6460-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Oct 28 10:30:19 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29876 for ; Tue, 28 Oct 2003 10:30:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEVnF-0003BZ-Vx for nsis-archive@odin.ietf.org; Tue, 28 Oct 2003 10:30:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9SFU16e012224 for nsis-archive@odin.ietf.org; Tue, 28 Oct 2003 10:30:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEVnF-0003B1-G5; Tue, 28 Oct 2003 10:30:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEVmV-00037Y-J3 for nsis@optimus.ietf.org; Tue, 28 Oct 2003 10:29:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29685 for ; Tue, 28 Oct 2003 10:29:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEVmT-0005hp-00 for nsis@ietf.org; Tue, 28 Oct 2003 10:29:13 -0500 Received: from [202.20.142.13] (helo=ns.sait.samsung.co.kr) by ietf-mx with esmtp (Exim 4.12) id 1AEVmR-0005fB-00 for nsis@ietf.org; Tue, 28 Oct 2003 10:29:12 -0500 Received: from LocalHost (localhost [127.0.0.1]) by ns.sait.samsung.co.kr (8.12.10/8.12.1) with SMTP id h9SFSclr016072 for ; Wed, 29 Oct 2003 00:28:38 +0900 (KST) From: "Sung Hycuk Lee" To: Date: Wed, 29 Oct 2003 00:28:48 +0900 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0006_01C39DB3.9E80E4E0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: [NSIS] draft-lee-nsis-mobility-nslp-01 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_0006_01C39DB3.9E80E4E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 SGkgSm9obiBhbmQgYWxsLA0KDQpQbGVhc2UgcmVmZXIgdGhlIGF0dGFjaGVkIGZpbGUgZm9yIGRy YWZ0LWxlZS1uc2lzLW1vYmlsaXR5LW5zbHAtMDEudHh0Lg0KDQpUaGFua3MgJiBSZWdhcmRzLA0K DQpTdW5nLUh5dWNrIExlZQ0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0N Cg0KSGkgSm9obiBhbmQgYWxsLA0KDQpJIHN1Ym1pdHRlZCB0aGUgZm9sbG93aW5nIHVwZGF0ZWQg ZHJhZnRzIGNvbmNlcm5pbmcNCiAiTW9iaWxpdHkgRnVuY3Rpb25zIGluIHRoZSBOVExQL1FvUy1O U0xQIjoNCiANCiAtIGRyYWZ0LWplb25nLW5zaXMtbW9iaWxpdHktbnRscC0wMS50eHQNCiAtIGRy YWZ0LWxlZS1uc2lzLW1vYmlsaXR5LW5zbHAtMDEudHh0DQoNClRoZXNlIGRyYWZ0cyBkaXNjdXNz ZWQgdGhlIGZvbGxvd2luZyBpc3N1ZXMgaW4gZWFjaCBsYXllcjoNCg0KMS4gSW50ZXJhY3Rpb25z IHdpdGggdGhlIE5UTFAgYW5kIHRoZSBOU0xQIGluIG1vYmlsaXR5IHN1cHBvcnQNCiAgIEEuIFdo YXQgc2hvdWxkIHRoZSBOVExQIGRvIGZvciB0aGUgTlNMUCBOT1QgdG8gdHJpZ2dlciBhbiBlcnJv ciBtZXNzYWdlIA0KICAgICAgIGluZGljYXRpbmcgkUNhbi1Ob3QtQmUtRm9yd2FyZGVkLXRvLXRo ZS1MQVNUX05PREUgKGUuZy4sIE1OKZIgYWZ0ZXIgaGFuZG92ZXI/DQogICBCLiBXaGF0IHNob3Vs ZCB0aGUgTlRMUCBkbyBmb3IgdGhlIE5TTFAgdG8gaW1tZWRpYXRlbHkgcmUtZXN0YWJsaXNoIGl0 cyBzdGF0ZXMgDQogICAgICAgYWZ0ZXIgaGFuZG92ZXI/DQogICBDLiBXaGF0IHNob3VsZCB0aGUg TlRMUCBkbyBmb3IgdGhlIE5TTFAgdG8gdGVhcmRvd24gdGhlIG9sZCBzdGF0ZXMgDQogICAgICAg b24gdGhlIG9ic29sZXRlIHBhdGggYWZ0ZXIgaGFuZG92ZXI/DQoNCjIuIENyb3Nzb3ZlciBOb2Rl IERpc2NvdmVyeQ0KICAgQS4gSWYgdGhlIG1lcmdpbmcgcG9pbnQgb2YgdGhlIG9sZCBhbmQgbmV3 IHBhdGhzIGNhbiBub3QgcGVyZm9ybSBOU0lTIGZ1bmN0aW9uYWxpdHksIA0KICAgICAgIGhvdyBk b2VzIHRoZSBOVExQIGZpbmQgdGhlIE5TSVMtYXdhcmUgY3Jvc3NvdmVyIE5vZGUgDQogICAgICAg b24gdGhlIGpvaW50ZWQvY29tbW9uIHBhdGg/DQogICBCLiBIb3cgZG9lcyB0aGUgTlRMUCBvZiBh IENhbmRpZGF0ZSBBY2Nlc3MgUm91dGVyIChBUikgZmluZCB0aGUgY2FuZGlkYXRlICAgIA0KICAg ICAgIENyb3Nzb3ZlciBOb2RlIHRvIGZhc3QgcmUtZXN0YWJsaXNoIHRoZSBleGlzdGluZyBOU0xQ IHN0YXRlIGR1cmluZyBoYW5kb3Zlcj8NCg0KMy4gIERlYWQgUGVlciBEaXNjb3ZlcnkNCiAgIEEu IElmIHRoZSBjcm9zc292ZXIgbm9kZSBmYWlscywgaG93IGRvZXMgdGhlIE5UTFAgZGV0ZWN0IGZh aWx1cmUgb2YgdGhlIENyb3Nzb3ZlciBOb2RlIA0KICAgICAgIGFuZCBmaW5kIGFuIGFwcHJvcHJp YXRlIG5ldyBDcm9zc292ZXIgTm9kZT8NCiANCjQuIEludGVyd29ya2luZyB3aXRoIE1vYmlsaXR5 IHByb3RvY29scw0KICBBLiBIb3cgZG9lcyB0aGUgTlRMUCBpbiB0aGUgY3VycmVudCBBUiBpbnRl cmFjdCB3aXRoIENBUkQNCiAgICAgIHRvIGZhc3QgcmUtZXN0YWJsaXNoIGl0cyBhc3NvY2lhdGVk IE5TTFAgc3RhdGVzPw0KICBCLiBIb3cgZG9lcyB0aGUgTlRMUCBpbiBDdXJyZW50IEFSIGludGVy YWN0IHdpdGggQ1QgDQogICAgICB0byBzZW5kIGl0cyBhc3NvY2lhdGVkIGV4aXN0aW5nIE5TTFAg c3RhdGVzIHRvIHRoZSBjYW5kaWRhdGUgQVI/DQoNCjUuIFN0YXRlIE1hbmFnZW1lbnQNCiAgQS4g SG93IChhbmQgd2hlbikgY2FuIHRoZSBRb1MtTlNMUCBhZGp1c3QgdGhlIHJlZnJlc2ggdGltZXIg dmFsdWUgYWNjb3JkaW5nDQogICAgIHRvIG5ldHdvcmsgZW52aXJvbm1lbnQ/DQogIEIuIElzIGl0 IG5lY2Vzc2FyeSB0byBzZXQgdGhlIHJlZnJlc2ggdGltZXIgdmFsdWUgaW4gYSB3aXJlbGVzcyBu ZXR3b3JrIHRvIGEgc21hbGxlciANCiAgICAgIHZhbHVlIHRoYW4gdGhhdCBpbiB0aGUgY29yZSAo d2lyZWQpIG5ldHdvcms/DQoNCjYuIFFvUy1OU0xQIHN0YXRlIFJlLWVzdGFibGlzaG1lbnQNCiAg QS4gSG93IGRvZXMgdGhlIFFvUy1OU0xQIGludGVyYWN0IHdpdGggdGhlIE5UTFAgdG8gZmFzdCBy ZS1lc3RhYmxpc2ggdGhlIFFvUy1OU0xQIA0KICAgICAgc3RhdGVzIGFmdGVyIGhhbmRvdmVyPw0K ICBCLiBIb3cgY2FuIHRoZSBkZWxheWVkIHNpZ25hbGluZyBwcm9ibGVtIGJlIHNvbHZlZCBpbiBh IHJlY2VpdmVyLWluaXRpYXRlZCBhcHByb2FjaD8NCg0KIFBsZWFzZSwgY29tbWVudCBpbiBvdXIg ZHJhZnRzLA0KDQpUaGFua3MgYW5kIFJlZ2FyZHMsDQoNClN1bmctSHl1Y2sgTGVlLyBTZW9uZy1I byBKZW9uZw0K ------=_NextPart_000_0006_01C39DB3.9E80E4E0 Content-Type: application/x-zip-compressed; name="draft-lee-nsis-mobility-nslp-01.zip" Content-Disposition: attachment; filename="draft-lee-nsis-mobility-nslp-01.zip" Content-Transfer-Encoding: base64 UEsDBBQABAAIALNeXC/6FOLcyi8AABypAAAjAAAAZHJhZnQtbGVlLW5zaXMtbW9iaWxpdHktbnNs cC0wMS50eHTVfdty28ay6Hvq5B+m/GKxNslI8t37ZdMyZcvLohWSXtk5LtcpEByKiECAwUWy8vWn b3MDQErJlh62VGtFJoGenp6+d8/Mzz/9/NPZeH6qJvpHpWaV3pYqydQsucyiNMku1b1+ZkP1Weuf f/otL67wpQ9FXm/veqn5Mxudz75OPqjR2RxwyipdZLoavC+iVXXXq+0fwOiTzrPLn38a/9gmhS7f qtG2SFJ1/LKvjg8Pn98FIPj5+PV09vNPdz1158+noXoXIU53PXj3z7tPTPG7ntv7E1D8rod3/XyJ q3yhC3X8igj77Oef8LfjwfN8kaRJdatO6yyukjwjTqvWWv2azwaT2eeLrteWuP6DVOtBViblYCNA 4F/pdnB4NKx+VDjerIqqulT5CgAmpTrXm1zQmOO/l3lcb3RWKfg7ylSDu6JsiV8ANqs6TVWcZ6u8 2ERZrNVNUq0JTARfbIv8OikJcxhopmkW6ugQ/zU9PTk+PH45lFHDEWDQAmCJdBhkBF1tH1bj7DLJ tC4SYZJ5VF6p07wARA5QSnt9lTCwqOwz2vBPA/cSpa4cqkleaYAbVSoH6AVB4u/UJrqFmZS5WiZl VSSLuupCKyqb+O+bFq2Q9/Y1KI6lAgqqCMb7kWzqDU60TH6oTZ5V65LpCcgjNgut6u0yqvSyrwq9 TaMY/4KX80WZpxo+V4tbnoiPIS7aLQGqko0eqrOKVzDawiKBoEdIglzVpW7jXMJAK11oWF+CsIGH 4Y0UR4V34oTIpzcyKlAyw5eeIKGQSWCES9Ao5fCJZTGtUiAoTjOuiwIZrTlqDEBgrlEcw5swKZjB uqq2b3/5hUDc3NwME12thnlx+Qv+8ctRshxEC1ilKAb6A5sPO0ZrMPJsHS3zG/UeFB5IZZHornEJ iIwdDFvS28N1tUmHvvA0BrlJQBQ0aVUF7B+qVXrxJN/eFsnlukJWTJDKBMx9fHDSo2lYxp/lMaBx qw5Qg/SGagRDTPHRUk11qYtrvSTIIyGIR4rJ7GwWigByQlkBg0XFMvkLP46A+4xBg9Wr8jhPVVnD QjPxQchRCXlPwXqjZK6SAgiNXBRHJbAZDphf6wK1gX2YYIRgEYWljvPNNkeiJxnwVaQudQaMFqs0 vwG+SqNb+H8au9TbqIgEm3q7Nd+WJEYeVtttmsQRKU9GxnvYotAnMDHgCEMTeZw5/0xPXhhkD1Dt glZZR6QXdbYcVPkA/qPKON9qK6mgEqsoAb3nYaDKrY6TFcxnJQo9Qs08VF8ybTRbAgQoYCmY6VYa lDRIDn4Lo+HYSCij04F0W3x82NTZS/h/GEiz5ljqElhv6V5b+fbEwEXChUt6YMxMD55jK/XzT2BE +woYMEqHKvgRt+Eur+HbRXSp1dH3n3/6P3c6LRuDgOr4sWbUN6FIQoCH3E3sP48WKdH2BNYDFaE8 dzQk1Vzky5pt0vBv/6pnAulIzXWxSbI8zS9v1Z3v7YR0DH9NczQwJ6BAgUjIR9YHuBMKQXpBkJ7B X+fRlR4sNKyqHrwD83elrkEC6C/zMT6yC656SZCew18j4ZU5qKJLXbB9iRxm42vkud04vSJIL+Cv zznIWPIXQLiIQIinIMRJcb+ZEaTXBOkl/IXeiwY7lAEzEcvf9W4D0huC9AohsQgR+7PmZFk9z0Fs 7sbt6JAgvR6KqY+EWKSlLImM+ij3QToiSG8AEorhVA806OQFGK41zfBcx8AWSbkhqSXQWs1inUVF kgeYHj0TSEfqNAJt3Alu76xakI4Z0lSn4EiRQAGt8hr8rHvQiCA9F0jPUBTBSmyIzL+MiwII/xFY nYOnu+AAJObxo8MhOpR1gfQFkCUovYIV/X2gECTm8SNQBrN6s4mKe0pZByTm8RHYlmwJbttoSES/ KJpUB0YAd41U+g5IzOP4MzU+1z6u2f179MZCGtXVOi/Kp2q0XKIf9jchHh9aSMjjYCXjqgbvDyYD thTIj4rK+Sokm+x1tiAdGzPy938fxvAcP4bhAQbyjYnYGPQ2yIEBUoEuiYtkS5pFLD35GaETBMFK Fqf1EiUhqdh4gy0bsLcSFfEaHorRI+gbN3WV1xjUZOrb8Xd2cHxficNFgtM5nMVjXkRZSXqw5e/M yf4zMgka0SXob/DOKLZbauOlgfN0i34fBISqstBQn4I/y15ZHXNk6DyMDTAjrIq4ZhGzVftrippg LjIQAQFnHUI/DINI18K3vmfX7QEC/0TxGny3a5/C+U12L6fPuPhd3lqnp3aAoU9UgENfp1HRD9ws JgTbnt7f8+mMP0cgun06P0cAnP/qu7pZg18NBhO+zBd/YCB+rc2qmpUsRKXjH9YOQhyUF8SRsOYI 145Y6D9rwGPDbhXAwamtaiRDR/Qga7wLX0HFTpcCTjOke/ZmncACIjvUJbOhkMsBRlfV8LtFAwWU Ex1mBAiZM+BYmx4pdErMZPBl6jqbKytuqUqBfFLGNQaJnFrwqcME8d38FoSkNCGHVTcua6DWoEvd pHR2nRR5RrTuqxWSHqkEyC0xuuI8BSxbnVbk01s5w3AD+XOpL4toGRkFhNYJpMVmbRLG7QbWMwWh k+iXoIg7jejWGbnTnvDrbI3vQ/STpzUvEXIBfL3ZVpbPm2aQWKEgJxSXwYrTlb51gkT5mHKd1yk4 nNqXF4oPPR0NmK2Mn9M5lHuWwTBQSusY9unkfRhlkVO0CUqvGOAiy3xiDfJTDDBjkFUUWqG3eIOz wiQOO2cZfKgOzic9ziLFFQbJkUATJWZhYaYTWTon6cX4OfBp+iH3Wta7M8LD5ah8EnhGhnncCxQW GB70PbYj136pK87c9cG4GA9+ix58QR48h89lwyXvk7UQh5j9YQvXKgUWHFiHPBuyJQ2iKRGH0fQt RCHIkRwgFfL5CX5xAhASzIfteuT9zmfUe6Aiyo8Z6ORkEjx9UuRliQ+oCa5l6/EJPJwXwDLbPEP9 TI+ZL6f4bQDgMRyaZ4/h0MCHJ/O3HDT/qNg7WFmansPEJP7w5muHeNtOXFsF6OSQlfT4LSvqMdi2 ypCVgew1yebJuX1ylwdjnkRWmeibTib5gl9+AZXQ+vJhfh9mpZ8/xkofD3fnHPB7eGmUQvRQgzVC NVLQwzE/HEdkhSkd0NAZnKmm940iQyuRbBJwhchuS74xgFiyS0puyjJZSfxj/BSyCOQPgI/rHKKC BsvyyqAFZNGs9DK0b2kwBEE60MPLYV8tazJmwF9XqIpJX6+iJAX700NXI9Whx4Pj0JytVy0jiv1q 4BWYuS682RARIJfVBy7J0dtao3WtMGcMgyRktYnR8cMqMQaSPePrPL0Wh5AULb4MtgErL/wYpisX WmfosYJG5kUL5kbLBhjnBIVx6USaU4Ze4hNUPrjlPMPY6Dt2HcgAgiLsieOWcJJ4o4tL8g1zMBGG eDmaZACXgZCicSGfRqxbjL4GrBSQ8gZ5JhJrI2hKnABWr6ioAJHjU6VdJTCPFcYKiVgZJYlw0B7G GWAbhzWSXSzephYBQpa0qieFz1P2BTlZVjZtr/iJWfg5G1DGJMlgeXFWmUZlhFkJnmwMxpls6UEy 1MC9Xe5Oj3GyHGSIaf1ToRg5Hpv8Gms4ELDAmsUJMR8NhWaZZ9cZR/E0/bJZFyoiXSK5ulvgrehm Gjk/uw0X1k6EoIg4eLEFzqxMUEV0ceoyBylxesGXfHz8DJx4zocgDYCTmR0bb/XYgwT+AMUA7tsC sLdzCqZi3SR0bzjL0xGlP/8+vMtcPLYhefEYhuTZ8L4pZ08C0SdG8Rf/Asu41iPnQPp8AtFOvqEo YTRFHRBlXGUUoyAhlImEKNDjByBqWZZ9+43K47guyEkHDcbMgmpRWBRWCZ9ED3y12jWmFLkAKZAd SVugxw//gyCJ4GxBASakJVBHo/e9NslNiwlGvODkEt91BR5v2c1qkROFuEVOo9F+M4q/4z2s8Ubx ur8jzCnBWFQgc7uUh8tKRfQhEIXhq4ISwom8YKA34KBmRzhY6OIPiJhIjr6zVx18glAs6qZOvGsK VV6A04DJHIubh03jYRgCplxvJdyyUzXEPIH4NSo4w9CJnIdYJ82ZFzhKLhXF1FRck3wYhG9FTelA l5nAgimwa34D2rXAvgXD4s4QePmOTpWLtllhgMIBMVvmIQHBXLRPBI/1SjQHmzqtksE63/gyGEv0 rdY63a5qToogTyebjV6SlerEgz0wx++ltWpLnK/Vn7tZ1TkMYJwg5KWVWEjapytj1A8tqvEqwPng +vs2xRg8yIkUeapNuqhzGgttvT0HaMH/9vsmyM8RPWLNN4uKT3I2bUkG/01T5438s9+HMQUvH8MU PB/er2Yosmb4vzRJhhttrPitqNOUTAVBrEKIQb5NfNgRcV8rJMH8M2dgfMZkq21dPIJDjqF4CrXV blQBOz+7uH5p8xe9JteRO6OJW0NucDJsJmLQuUOUcictgTNXuFKcJ8dZqHCFwnOnNkodbUgbWRqI N7kfjV7fyeyXd2efz+a/Sx7Z9CQt9SrJjGwGJBHn/NvRC65QsHFrQOHYipsm1DWWNGuXE7fJWXDr 0qUlnUXJzOX/Ibn5IaLR0+n4dDqefXzKn0lKveNpgmSaqySxDCYfGRDo69ltWk1SnwV5q2zJ2kxY Wk+f4z9iM0xrtZUHtmNhFMEKb1fK1HiSVo8S+0vhguMs59lixDW0TpYQQegicMws9Q9065MqvfUm jDBsZEtwWHVRgh+lgP/ZwvGg1Np2+b3sOV+MYIg/touHTH40szjBZJcYcmBv20py2g2Zthh1535h fHDxE1YrQhkCg1Qo9GWeJX9JCIPfdgqgTUEDlkstIkZAKBkKEnXJk2f6n08wLp6Mpj1DyUa8Qv4n Z31NCraDJBx1dNGJ0inczEapc2S/ghF6djxYANmI0OxYRfQMfgAmHNAnFxYkbDr79wVI5Mvv4TgE xV8TTJG3hZv0I/kaJqFzE91aR0YIXHLSAwM2S8Ey35DPyDntdbKFD6sbLeFwY7ZSnVu5IU0Q65dK fiN3ngIFVuW+gt/hFKD/DrNDp7faoY9aaqxVleTMtaaWUnETeebip46m1JXZiQA40B4CzcEJDLtQ lk8YDsxJ/Dyq3JCccVHUaIRQF9l6rzDn02k1y9OL4qmdBMzzlG3at6Pn322Ns4v5jPez1CkWLFh/ mNxTIzdFzr/lbUOShiTQ6zgRQ5ZWMmrH4nBDJT5TU9nZeWmtkoNZFWv32jUIQxwsFXArwxzsuuSS ULZwgUFhEBxPdXpKHHCIln/UJS/ndZTWYphXYJvXpOIL4xKAEQCh+YvxvQHd1bDhvhIt1UvC6E1v j6f4MJ7gq8fwBF8Mu3u+nOcnJf2moBqD7zM6mO6Q11HoWUcU6mTSNwJppFHl4PKU1JtMphegNHOO 4iQBiI8m7DIfc29kqyxPQTBXCUxhtC6JC1n4xWpiaZlK//hNKw/saRVWjQLcWZVmiY347TpPlkHH aUsl6R+SR2eDSx4FKhoI4Gv0iCkkB/kVbR3kSULE0Im1uZEUGJZZm5pckXpubH+JqGnXmMXYxJlW BgPxF28skeZy0SdgnhwB/EFUK+IL2rvtO78GLaxdXhNbkLPZILqJxHDeLyHdd0EpGjKUalPC58W3 xT6X+DbRCALEEFIiDnIFHTYUb5SyPcU4UM9NwrC3g2sWmn22hJJWZgimkbY8z8vyZ53EVyn2CAwk AG2HpmWY+2ELYpPHuaKMMdOl410Te8guBKPi2ZgR6y7zGiO5oLskEyuCye3Sa0GpKxC7v4KU/RkP 0C0fpWmEtH4eMT5F/fgBxfrizKLbfNZXk1My0JPpEHeMgOxEm22KPVgm8UisydX5ECoKBxu33HNb J2c8FYn4dkRzhrqWsgRISGvYbg9JhwF+3EvQtyLmY9jAbspLSKVqoyF9ATOhjQiEVFQwD4pPwnC4 Vs3Z7sObVXOIe6gICx0gaxxESgeT016KzXU+InYcMutwy4WX5llq6r6EyQjdAEYdcpATbPDApBiV YvhAAivlwP3OI8+KISDyko+guIV6WQ3piBcofpEII6z22N42VFFYbqAyAZW3NFdCxANhDz2EbSpj zvHxqjnhYgydaROf1rrm8gTLRCtbqzY1EaYSn493FpnUquPrxKvQdKkRYXS/iBxOJsgO7nZzHtbd ef0Y7s7LYasx3bNRZb4ykbNXB6dIrCEFWP/GRAh/wMBY36xD9cnQJHqdjG3vH4hDn4tThWQizicl pt9F2ZigInIK1wcrK9MnOR+DZZJ9K+Rsm7W2tOlhHFOqetvMEnggxdhLBrQ0/ESA6owcc8p3G5fZ RDOSQt2JojCkRxzf4+Y9V24vnk1WhRl1icLCd9mJJx/QdMUREOP1katTbtD6m4dp3xuJupE0lJUD fH3Zsy9+e/nd5WYaDZmY5qA4go3Fajde1jcLwok6czNrhxZY3QcjrNCTciYjUHDIQxT4B7FNk0IU ZV1LI65p70B+MnP02xWZhlutC/Rb8b+mLgGeTlX5ORB/hjL5hq9tmkIwXyW2Kap8zbyI4qsF5jzM G+IBLvGzBbZwZNhjjDtWk8u6sMk8MjzRMtriOjBCOl5nyZ+1459RZpwE8oApCSlveE8bHqt4MyVO AvOQmIYkKJyGM5mIZmRLRpHeOX+qFiwTJvviWRRHslv2x810vSygzZ7uDF2kW0CyKk8vpuPWmHcn 2LjZ0UKyLaQyRkmVLJskLpOCe0hNzs2xH64UcBpBwl26XXx/sCBurExG5JzwBcI8PXraC7mW4LR8 AgzKDPEbNIuyJrflRSdPgVP/FbwoFSZnmku5rO2u5D0eBUxaeg1R9Fx7M61ZqZcyD5tmEc0SRjnB HkPUxeFyitsL5uAyp2ixmZsv71rmU6EEhQ5ZDJZh2ygnlmL3dtkxHCDCwEWiXHDjkpzFgLYjNzRT O2XmEk2iogyrhHOFgY/Y4kV7cETx1Ni7DyGDUDi0uRywIOiODE2dQXBCX3qFJNGFqB2oyjkKSqA8 KcDSyBfixYyb1Wn6lH3pZR07ycbXMGdr3FLb9E3u8Sbh7i4vy2QWs2+jCk+HXOltJasCohJm6nGj GFLMbV+i5bJpZel96VEF5/FdszeP4Zq9Gu7f6ef5aV1xtul7v0+7OAHyWsbV/nZx0h0TV2rHf+9q Ef/NNfcReJfXaLQjTNSB12vOeh71q1edDiSDeiGosI+HLBhFgT0ytP2/zHPa0Z/IXviopFw0i4q0 hHjY2Qnvxo/gBDiSCV7bphyTGvbhIbcjglaqRFhqDDkAV9eHIs/78Xg445Wk5mmKxh9jxzS6DVJP gDcs/sZo3j1z85PEpVXXERZHfI+fhmX/uJEdsLVmgnJn07r6dnT4nTPWjUZt9e3Nd1Mg5a1nC0bG E3kvrWJqZAa7OkuWdCJCgq3bAd2iBQzdUNHM8B2bKhY7wRDDWY4R7XnH417MSssXPg6E4gohMy33 NOEYkjZaRGUSS+wbvtnKGPJ8ElDltKONWJSPG7AG0FilMtr4WRS7X0hJWwntN7ODDcNe6vYEBPl1 JDkVBM9wYJEpOVm6DLXhSPBJ3BCl61/0DLFhKYTXbDiqbAsbDA+SHORCpcvYvI/tVWVV6Ggj68B2 MUznIQNt9zzF5lbrqpUXxyyOEUxvqCDuc33lNhbwIgHztkXAf/fG9N2CeixwZUzugzRYVFXwEclh kAY2xwmoESqrDTzGiggUdiH0Iygz6bc+e28WZtcUMK+CznAbf9b4q51TGJoUFsX2pendsI8aw++N TJnrHvuUt5uNrook7lPlNrtMQ97liJoDJgJj99hRd2CXrfMYr4mbya1HjWGb49kUo9nRCUtoa+lc 2un5GsZLuEE0RP59WFtsAS5kf07h4u4Yd+2kEv01y/SGiVCwqE3Uky5b3i4KSrvX7VLxPXJY/2NX SU7ROHwMV+n18F5HGYj5AKlAmYEnQwvzvMOP53SSOODiUhEQSihQyLVjn5jXhmWL4Lbf2hWK7Xe5 yZE7F842evERNX7pxT4tYQ46M/MAec4VZ2H3mX3fJNr98NPL8bhwa3fNX3CwrldXrjiM0rp7cCTR 1oTeUb6G+B6DJNS5mP8QtBotUzQk1RR9z6S7wG3TJMbGUUtAgsFlXMvWRqwBD0BzblPfxwq2Cpbu CDHUXQM8FajxvMcXpouuVd9nAPtq/C4ZqGVLe8srszP2YgK2aEgVHV+5QCC6joRp82aNZ1WJL+96 7uB9zg/Yz3pchep0DJ2Rse2QfqODrX35m392tjuwUkZzjyuTkv8rXTTdHbssyK6thQDsaExxeyD8 svCu7hOR/aADhdU2iyOXrnmibm60hs7TEhXC7JwFrXWSzuFEOEQb0i5HdV8q+fRMQcPQ1yeADeZx ufriHbl8TQAcGAzQKnu2MrOQTR89527RrpBSHDijd0LSNiJOgkSZgTi/pFY1cGGqtSkncw1LZjVw s5LeoVIyX2ZuT+Noa3gUD467dV1AB4AJkrXX1Hu5369EUDyvsqvZBgTLdR1hOGEiksAYsD2Xduig fUAkBzzvpYQ5eunPz9EflDSrm45GqZjjoQ5Se6/7hshQeqEvE8bDeBneK436/tLGYQe4b7gnqtrw pWexGsrDn7LdECTGggqZFnCrfaGhNIwDeB8uxp4mDPBtCm9vzo/g5EUzh9asJtooAsufq1USY4LD D4NKyzSB1dlF1KGvof3jF5oGjH00lKq6wEQpuOe7V8rfhUVQcM8K1jXs1rF7LDKMRTFkUASj+E92 Bclm050AaKlRG7A/WlJCiWNWqoq4JynTh/s3TB1uL4oo56gGWLHHV1l+A9ZSzsXyq9EQzdFARGgX /VPpA1exDHefUDKXy7/W7EhRIzCyzZMznFGGJaSVhCXtiDop6yVo2ywNzXQXBamtipVbgltfi+Ra 89GWtl+FXDdqa9ZLOZbSA2BVsCtJmCNrcpNXdVnlxqpYZem5fj0b8opXmbDO5f2LohGkXVQ6qJBj KOf90MHAY52pB+S0mwO4gyjwj1rqLWpnvhs+lF8m2OSw9Lm/WajtOLxjqhKUr8GWXz4LDb0HMF3k QDn9ljcrNGYI4Tg7TL9dhKLnTfocbEfTLTZ9TX+zBRSPXaK4h8ohRmKDmhPyk2nWMkaogxmxVju/ Z6z5T38fhi0f5cStN8N/ckgevgngRo19u1xf6d7lHzYwlaaW5tDF9bKt8u619kY/fz90uy9s1SVK QYLM1I3o0CW3wWifZHJ20qTgwgFclMIWyPT5kfTK9vlc+jS6CGF4tCO6+XYk2wo4vEDxK+tFKeWr 0iYq+Qib3VteNsFiyqE6LthJMrvhnytUQ+aMPaceCgPMve1mtn+hpHyPtXTe4JVtn2zhGeTEgiJh Vw9Ui1RvO44IxEU47SwP2PqbYl9x237Xq0T4sT5jqT30JD9NB2NL2VlMMjIzHtpd+fUuG0/+6jax StkkSGlTfOUdDGbOupYaRMkmfOeKN/aNAiNJurv1JAY+BMO1FMjJUYj2ZR2BMa+0kcUu5GUzMgHx NySTMe+k/y7q+szRkSq9iy1Q93hNPDwrpzbyVYB3g0aWH3LKSd5SRrKbZJaj+7aGHubdZAJ/a6ME unl+/o9gmBzga3rK7qCFIAknaxp4u9F0ybyu/g+raRfYCloR0byCvdf/xFqt0QFAZe9GmTvUIaXd AnO26mY7dIlp5TGJk3Q9lLt2JKdvV3R8hNganHkKrjpl/a7hm0gao91+bGZDOouGWZSbs9r8I93h 9GVhkt2sw0yE1xK2XZFpg7dIy+ChbKAfI2P6dssHNaXtiPhlALFaYdeL398LTGJdakxwiK8NkYTE uIETF3Erc8BRdygVs7y2WC25Aoe3FXNXOfWqngHqTBBuI/QuCMDnfDcW1q5F6Y2s46bU6bUUojCr CNgkWZ3XJR5OKD0prMX4YBTbe9LiOxbfGtxJ3LrhUgImBSCYuNU1EdlNdOu89HBpUNOlOioaJQ6z muuCNH939rYS1bvIF54SMfRHX91vua/Y+kQxXzhg2gJMdaXZ8MDLHzQVnLiUjt3dujdQWdw+rKf7 WEexmURe2MFg4kqvZdBv4ENDlNtNZ4FQGo43gbsopLas0llLIpVsljj9hB/tZqMd0o3LE0n+BaUc WcslNh2H+4KD8s15dvzeS7GvRKU1Nr43j/HgSy7IYLgUhuk8tAnmzgYRP0XdVIvtVIZ3gpIRmzuL CCV1WFlH2iWjfCc95UjZtvt6B3Nx+BLukRML3WE6+1zKPHvft5qTjl3sfTt69d2zeS05bGyBOZk4 I2yDHYwzJLfC7OaxzmhaeufmeKJtC8YIk82jZz6cCiFauQYBswewvFseOH4nSCIRd+qErm23u/IG frMtp3/efTVoODcC24tRkVU76ktttkicY7q3kyriLZVlV+ulHUJUJeE3vMcCt3L/suIExQzAsw2n sXW4hMsvmfAk85KdjVbwfiv0XJv0oLdzjWMYRxoj/AvJDO7Xk6LlkIVcRxvLguBOTXDm8cRu/rK1 XqRapy/RRdXQfN3VEcdaEWgVWHVdNikLCJp5nEw6m0wbmia3qEmauGuuXV3nYnmqYDGBdova7TZp VjppFURDiXbaJTN7NVRLJJo6S5pxCjrwuMm3TCmJ0QJyMjbCUI3Fs0EN/WOuuJhW2c7PRosCJt9+ CetZGZhb3p4m/SVxlYpFvGe+h2nuTkuocJ+72+/YCBSbQeKXZmTeNlMtVYOzpFUL6eQfhkPKfaMh yEfaiO3UP5KSmvDbjah+w2u3u4b2WuiEtMSIdXuX195xuISXTzbJYEc7k8ynMw0TPNwqyjR71dZB /WjyDPt1ekJKJcw7u7QzQcKzCIwTG5xU4XBc0oky3NqHu/u6feaOoDsqu1s4X0u6a8/VHCbfaY/8 6Aea0Xgh7DN7J8F4R6kJHzykm/wo59gGb/hH/FWyD5qjatsCGC1NBz16w4Wc915oOngktCCNY2Rc 6chVNc1hTEZmgJ2vE+Y2MVtLz1517LX007guTdiK10uTy/XyzwTMHZra2MQqbUgBin8fvXbmsi+t QywjxkU1kg9fVhA1EgsZicF0SWQsd9M694KdxpyPpCu2qMa3tDU+qu+1tjHia83xfP1gPBncf+8I TUDYWpVdcpF7W2k18wpZoECbEBCjbHa5pJ4JlZ3DYWrdKf+WXeg4RZHFfu89Oh2CL6Tl+hbV4E2V ecVpBwvL7ANorZW80BX/7IRlLw7BEyS13b9kuK2LXJ5hpuN4/a59jBL6DSqHu4nllBqCEJxUwwTg nNbu16n4I8eQ6QyzGy0PpsyVH0MiReWEYuQAuQDD9XyHbsaXHXvPO4qmLQZmDrnP1nPeg8pbBaWF OzCUYkXv2ngeHIpiPAafIVnZRfs3i+/QYjvOmrAZUiBRMKt/UOp8GHv1KMfl7rm+ShhmHnAAqO/E 5TlK86ZXpQqchG/PZZMxj9FK93I7Gh5OSr7eyfnM7D2khkArn8xyC7GK5Npxzsh8FpwMlngXVFAY ylYsi6MtOOrWPUTfRpszF2HooMyZYbu5d7mj3XtOsidX/bQmE2zoNpSwMsOyK1KEPhIjL72yMmVq g1ml4NmKC5ZkKrwpw+FtZl/J4fGIT0SXbMmZJcDjeosD2iZ/C0G8Os5ce0eH06k5vp6RuS5zTAOX ri4S3ioTLvvRG94Q9O348LsJgexCi7PNZK0XJV5chLe42n69Tb60pP5F/6h0Rnf3/gPJ2//7MHL5 KGeXepfB4T9V6zpkc7y4+PfNC1cic9MFfmuG7ns2kHYotK9c6b5YxeZ27KUq7LSE+7NwwffsneIS bthjTWDueSfLY/0+DBc8yrllf+ciP3xe7SrIu05IcSzM0Y3VutA6vNDMnGwjd9i2DmrFPX12xx/2 KvDhEcFrBOnXjn5OvJRFerTfu+t8dmwxJChum+EBtQb327sMD+ikPAekedtNAwo2yfbFinj8Sdv0 hIp7dpP43emcVsjtRiGze8P0VOHpm3I0Fjtak7FvOsB/Mo5248TBdpahyxFDcLiWVVLVlYzQ2HHh NmFLTgJ9I8/ldwmUhjNkYy4vp8BmNDw0h707Y9mfwiIMJnk1eKcHp8aZwyQrfDn4PJrNB5Mv78d8 AAX29pdlDQQOdoG/sGeVdWe/DdWT3LRseg10AZV+MeeDCq1NSr8kB9kFO0HaxfSMsnvD4Za7y6Hf vNxBUoItqhvPyB4ZHKDpMoimnuK1llOlIihpmkuySVH6jcl+04Nxs2gar7tp2O5HF+r4/egEiBrQ pRDimv+odcLpkm/HR9+xGVmb68K60pFlq5rmV8rbfRcige/YaW993yEJPvLs0US2UmgqBSjp0vjq jj9qnovJjG/bObjVYyGx9bpxvAOfDGdq/RJG2t5zPG2xUVq2YHYc8FN1au7tGrMlrmzEqQvQFVWq 6XI+3Tj2hwKdZENMZ2UGeTCLb1v9zra0EPQmzUyPjxQcXPuKn6BxqsXlbNzBIcE7mKyvM6qGm9Nb wU3NkR9ie2alZIaW5t4koA5YgWZxIdhL0GAGX8/B2JVpPJAdnekuytvCGHXvEJR7n3JBhwd02QoC 89Jv42GVsuPABJyX3VHQ7BcinmaIXcUdSmmZtSx6tg2hpG9EcA/KXk8MXrNwhSWx5TXtJ1/cXb4y OSQCwoDdOLj5qPN+DclK35GSt1TgGcvpgsFEG9M0h6sSGHcqHwaWfK8kHoIy57YYmFWNZcK2lNkt fQTGri0lA3c/bB/sN9SD16L0dMoM87RxTr0pXAN2p8ibWKJplkVEE0vfgnQkYXXOCFFYpfOu/0Qu wZQlrWMlSkOuTJGGB8qP/uo6+vyUZMvffhgf+VEOu3PXU4ukfQOjBPajqLmiew5+2ZOpd0csSZi7 0O/CxBtP2JTzD/WLDhJdrQboK4M0/jk4fKMO+ApSulrpEuZdAheO6ktMOiFGRti/HSMKH0Gi8hiC qimiMEGXdQbhOMmbHf+tOi2ijUa4exFY3QyArl3jz/S20htDFIvCM0ThBKzHFd75+7FFBWz5U7/W NlAUpa8OgPw9D5GZ3KhKZJNO9rOLJzCr0xP17MXrZzsxeI4YzOJ1nf5VJLAYgsXJaHahBuykD0be kVHtNemgSOngMWHAPd4ODo86SXOOd1WHSL3oRmpkSDHIVwNDiqkx66MUHRar1fnnJKVNZkgWnBJQ ZB+Gf+alj6UHZz++LxHf8/g9xtMg4KMAWX/dSGIQGXQlOwi3iZcEg3FCdLIyBcoddlLuU53pEJFX JFV5iZ0CM2JoM2AH5ayK3MvTdyGxg69edy/hh7Pzi9lb9UGuOjdaRp2TkvbZykMp0AW7lxAcugDL 7uVrE+0NovoZPflMg4L/RPzfDF/3cDvRCn2zfHE7iKvtLh3gq0U7OMbo6nOiF7RmpAd3BNouPL4T BzD+A5Oi2YGNrzy6V/AIVfQc0MpXOksucQHJdL0fqn8VOXgdKbwCHz+xqen5Gm8dLPcxuOOrih8e HB7v4O30toEP6ut3EPmliRBqpCayEcqwdOMudmJ82T/AP2WLjRYEUTjoDmHzAIWooR4/rfvqvxEt e/zFGUbOZEl22BW8LP5s1uug06pmjOy5jDuUZzdPoVL/V54vkVJk16jqb1oYytBKXL/ctU68iybZ DrAXbbBJttcvB4ev9+HRRaCHc00e5bA3pWivDAgh4khKk8Kr4ISXs4sBh9DTaJnkRi6F+7qcklSL UrIMNwBNcn9FfoQm5V0RLXXWV+8Aqf+LLVJ99Rl3OMISYoICcf2oi7/yS/ybZBP+8ynaJJmP0BNr Iaca5OTfbMetjBxgybenBgP1b4CLXx15VzH7asIvrohrcXx8+MI3AUdv3rxyc0BrBMheooeHiH+I AOv38Mfshuoo8An84wI/vYA/5vlmE5XAsqdmMt7o53lKIU+CLhIegywuu/pyLUcfTvFIRJrb2FYj GE2fK9+8POobbjs8PHLIosH6Dfx0VmqfWb8AlSByiViT4LDXxx2LfSOvoc6lxwfw+KAor7fXxzsE 14MxwVyr8OSxwwet0kdwOpF2gwlRDxsV3jFtQBfP1oleo2wb15TtJKfDAvVeDeqtnMyDwQM4w171 yTqJxz5hPC/5cBcifdAxZZKVV0kXWm1EgmHVRQ4+5a0ap+TqOiwOu7FAYzRbozScDAn6NTkQbvKi bKf6Eqwfyi0f3yHZD/4xmtn5EACxoWjRh++UUg+OMU5uuY7ROHmOPEeBQ+Ko7RrvLGlolWDVmiiK 8+64C0E4d8zq5Xs7Ox6iaKoe1S9zJr7pkHUTs9OEHaMJ+6Tz7FJ0sjWqRjfZ88sxndkhlH/gy421 ZYT2WtJuC8asWz5VI74E2MaxsxoG+Xhbx1doP/ij0fns6+QDPErZmiUQU5L/GAnM8eznPM0v5aze gRgRJPHnaMEqbwbR/9HzAQjkBCZR6nxQgIx9SNYah9Ny+ervOZ60NECN+eEWZ3uZDJa5Us+fvxm8 OjqmZ/71ZToeCa4X6zzTb9V/vD5Wz47U8etD9ebF6xf01fg8StK3mNEoynoIxuu/ymhTwmDDON8Y I/6Apvz4UQ4jU6jscNU/5sw79BG4PVf1lfqaYUKqlIDslJ3C12/Ub2BXS8xi5evbOrubsG+O7iDs s2eH6vnL58cBYdfEjv+1rlflMIqHV4XF+BN8vs7Vu0jQ/V/MPn+sD49fvR4uYCpt/oHH3t3miMAn bKc/ePep979SZF4ev/TnvPjj2bP9ArP/92HE6VGO80BoaapjvDiNPCFdgPDMMOvJWwiJDnNQwWfj +amqoiuNO14V5XoT6gE0thj19DWYiSWJX+Guhooyc2a5N9bWjAVPcnq6SC7X5nzRDf6NidU4jRK+ 7JdA4Cu0/5FLRHgkK+HJ7gaAqkt7tEFlWSroiSE4YWuS5MypwYVqO1I9yW4V+C8aT+apKe1NNUnG k8AwmliFpT+k3c1u4P1PlemE5kZnsCa412eLuXwchVryvOOT8S5JHFGvVtj+gzsMzJ23+LE3NFal XREvd5uDcImeyrli1IrADiH8scWEN1bfmMYJ9bRmS9xaM6gK3Hhsq9P2c1MwNWTi4fyjkxDOu5OL AfbInORb6kfjhDstG19nziPy9OzOZqqt1AubceQqwy3d7VygerCQZAFK7h9rwLEXKha08YOZDQ9u 1Zttxc8K4+QL4pvIdFjYhUVEsCOc60orgSdshERnvqNTXXSFDWUyo8WtYz9wG4T5CmkTxjph0Kjm nVfFuGCFybQ4k2zNdFzgCEkU3GRG3yXZdULNlmajAPiL1BqEEoSU4ZY+PtMJ558JWeVaoHx7y2j3 sZeA086F/OnfFlD2nTx6cyYgMm93iRwlqnwxY9Hlsop3LglAwi4je5R9UlouG6oL7kKP2OdiqW6f AEdEGP/QcW2v43hP7U15Id7baZ2myIQ8z5YGc98cnPSYrsb9neUxzPJWHaBWxJ4HADTluU6lburW w1cbVOPB3GEq/Tb5ytsMEKNAcP1sVRcZb6Mx3IgElr4qvCkFS3vXdC3rlShAsDCsmjK7IDdJyZsy kJETeyAbiAy2ENFnZVMjCi5bbB8rsC7FWPVZ+OwOKMLDbldf0lluN2u6IY12rCGf9e3eHGS+IuEw 3FPvYKsRsGkutC3RtFfesSD14eD5mFQhw/JgVESXRbRd2xOCbXM4sjCsBum+mBVMF8mCxuTGpYBI FZ2u/MPLuKuRa8QoULRP2bSbLLDBfJMHV/G2cKfqp6l2WR5tMpRZONbN5tu8uIwyCZCBBfSPGG9i iEqze8SoIDnHzujBJcwvBRKAmFtQVlfzeiV0Eond0mGNgAk+nRZQjft7HeoW4pZ375rDqQkAH9+D /EF8F8i4EQS6HBVUVK5ScBFrqt6yPsG2CPaqskvkPV/J0YWSqNCsKi7VJZ3YImctcCuDLraavAfk Aqq98pKyftLX+ZW2mzO7loPajWpK7InKRum5BMqXe0S8oZJkNwB2dQAHJFnQO01KlwA9Gc3U2ewJ nRHIbDv/OFZnk/l4OhnP1ezLCSi139Vo8j78Yjz5cDYZj6dnkw+M0Gj2L3X6ZXoyVu/PZiefR2fn MzX6/Fn9NppOR5P52XjWV+P/vpiOZzP1ZaogyP98Nn7fB4gnn7++N2DefZ2ryZe5+nx2fjYfw5hf YOjfDZDfAYfRnBD5OhurL6eCE4x7PpqffZk8rCv7KEeAwYcfx9Px2UT9dgbkwcnCBJCOY5rq9OzD xzmRCP8lZPKoCLMmIOfj6clH+GgknWTwwunZfILkPcWX1cVoOj87+fp5NFUXX6cXX2Zjk0EIz1oU pE5rbuMwgo05sPGSzrgzTcLUS8OHvqa3jpm8TZdNbrZZ94f+fZgFlpMv/j9QSwECFAAUAAQACACz Xlwv+hTi3MovAAAcqQAAIwAAAAAAAAABACAAAAAAAAAAZHJhZnQtbGVlLW5zaXMtbW9iaWxpdHkt bnNscC0wMS50eHRQSwUGAAAAAAEAAQBRAAAACzAAAAAA ------=_NextPart_000_0006_01C39DB3.9E80E4E0-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Oct 28 12:28:23 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10540 for ; Tue, 28 Oct 2003 12:28:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEXdV-0007hx-42 for nsis-archive@odin.ietf.org; Tue, 28 Oct 2003 12:28:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9SHS5QH029618 for nsis-archive@odin.ietf.org; Tue, 28 Oct 2003 12:28:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEXdR-0007gq-6C; Tue, 28 Oct 2003 12:28:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEXd9-0007fa-Mj for nsis@optimus.ietf.org; Tue, 28 Oct 2003 12:27:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10467 for ; Tue, 28 Oct 2003 12:27:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEXd7-00021k-00 for nsis@ietf.org; Tue, 28 Oct 2003 12:27:41 -0500 Received: from tokyo.netlab.nec.de ([195.37.70.2] helo=tokyo.ccrle.nec.de) by ietf-mx with esmtp (Exim 4.12) id 1AEXd7-00020h-00 for nsis@ietf.org; Tue, 28 Oct 2003 12:27:41 -0500 Received: from tokyo.ccrle.nec.de (localhost [127.0.0.1]) by tokyo.ccrle.nec.de (8.12.9-20030927/8.12.9) with ESMTP id h9SHR8qL057449 for ; Tue, 28 Oct 2003 18:27:08 +0100 (CET) Received: (from defang@localhost) by tokyo.ccrle.nec.de (8.12.9-20030927/8.12.8/Submit) id h9SHR4eO057446 for ; Tue, 28 Oct 2003 18:27:04 +0100 (CET) X-Authentication-Warning: tokyo.ccrle.nec.de: defang set sender to using -f Received: from venus.office (venus.office [10.1.1.11]) by pluto.office (8.12.9/8.12.9+MIMEDefang) with ESMTP id h9SHR4qL057445; Tue, 28 Oct 2003 18:27:04 +0100 (CET) Received: from [10.1.1.130] (brunner.office [10.1.1.130]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 064AC30463; Tue, 28 Oct 2003 17:51:36 +0100 (CET) Date: Tue, 28 Oct 2003 18:27:03 +0100 From: Marcus Brunner Reply-To: Marcus Brunner To: "Hancock, Robert" , nsis@ietf.org Subject: Re: [NSIS] NTLP draft Message-ID: <31834325.1067365623@[10.1.1.130]> In-Reply-To: References: X-Mailer: Mulberry/3.0.2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: MIMEDefang 2.35 Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Robert, all, In general I think it is a good starting point for discussion. > The view has been expressed that this is a good approach to > investigate, but that there are some consequences which have > to be worried over. We hope that the description now in the draft > is clear enough to allow the WG to make its mind up on the > matter. In particular, section 5.3 describes the problems > and some possible cures (some people may find some of the > cures worse than the problems). > Section 5.3 was really the point were I got lost. I have seen the several options, but did not figure what the difference really is, and why the raw encapsulation is not sufficient. > > As a general point, this version is long (very long) on > explanation and discussion, and short on actual specification. > In fact, my impression is that GIMPS (or whatever we call it) > is actually a rather simple protocol, which can behave > in a number of very complicated ways and has a number of > very complicated interactions with other protocols. So, > in the longer term, we may need to think about how to structure > the specification to reflect this (somewhat unusual) situation. The main problem I see is the flexibility which is still in there. I think we need to define quite a number of parameters in a static way. There is a lot of language saying "if you want to do that then configure ....". In many cases it is not clear who is deciding on the choices (And I think we already had some discussion on the topic). The other thing I did not get: 1) the GIMPS State (section 4.1). Why is the session id not enough as index? 2) For route change propagation I would assume a notification per-application sitting on the node detecting the change might work fine. Would mean that the GIMPS keeps state for applications not supported on the specific node (which might be the case when only using raw encapsulation.) Concerning the Open Issues 8.1) in GIMPS I don't like the word messaging in GIMPS. I would vote for GIST 8.2) + 8.3) I don't see why raw IP would not work for datagram mode. 8.4) I don't see why we need to care about letting signaling messages travel on the fast path (no processing on the node). Putting too much optimization into a design normally causes more problems than gain, and we optimize for todays technology, which might change as well. 8.5) I propose to use 3 types of associations (unreliable, reliable, secure), finer granular differentiation only complicates without too much gain. 8.7) I am in favor of raw mode. Seams to be the simplest one without to much impact. 8.10) scope should be a function for applications needing it, I don't regard it as general functionality. 8.11) Reverse routing should be optional, it allows for stateless operation in the core 8.12) additional discovery mechanisms are really nice in various environments. Is there an impact on the protocol definition, or is this more an implementation issue? Kind regrad, Marcus _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Oct 28 15:09:03 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20760 for ; Tue, 28 Oct 2003 15:09:03 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEa8y-0003BT-EQ for nsis-archive@odin.ietf.org; Tue, 28 Oct 2003 15:08:45 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9SK8i90012233 for nsis-archive@odin.ietf.org; Tue, 28 Oct 2003 15:08:44 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEa8I-0002vz-Gu; Tue, 28 Oct 2003 15:08:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEa7n-0002nZ-H4 for nsis@optimus.ietf.org; Tue, 28 Oct 2003 15:07:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20505 for ; Tue, 28 Oct 2003 15:07:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEa7k-0005iQ-00 for nsis@ietf.org; Tue, 28 Oct 2003 15:07:28 -0500 Received: from deprox.docomolab-euro.com ([212.119.9.186]) by ietf-mx with smtp (Exim 4.12) id 1AEa7j-0005ht-00 for nsis@ietf.org; Tue, 28 Oct 2003 15:07:27 -0500 Received: from 192.168.0.23 by deprox.docomolab-euro.com (InterScan E-Mail VirusWall NT); Tue, 28 Oct 2003 21:06:51 +0100 Received: from docomolab-euro.com ([192.168.0.138]) by deex.docomolab-euro.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 28 Oct 2003 21:06:50 +0100 Message-ID: <3F9ECBEE.5030808@docomolab-euro.com> Date: Tue, 28 Oct 2003 21:05:02 +0100 From: Paulo Mendes User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030821 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Hancock, Robert" CC: nsis@ietf.org Subject: Re: [NSIS] Re: qos-nslp-00 References: In-Reply-To: X-Enigmail-Version: 0.76.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-b61b659f-d650-427b-87d7-666acbc8ec19" X-OriginalArrivalTime: 28 Oct 2003 20:06:50.0735 (UTC) FILETIME=[06418FF0:01C39D8F] Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPartTM-000-b61b659f-d650-427b-87d7-666acbc8ec19 Content-Type: multipart/alternative; boundary="------------070603060204090806010607" --------------070603060204090806010607 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit hi Robert, I agree with you that the experience of RSVP and many-to-many multicast was nor good. But, as you said, we have a different scenario if we consider SSM or xcast like-schemes. With my questions, I wanted to understand what is opinion of the NSIS community about the inclusion of some lighter form of multicast, instead of the many-to-many considered in RSVP. I completely agree that this is out of scope in the current charter, but what is going to happen in the next charter? A starting point could be to include in this NSLP (which I think is quite good) some considerations, not only referring to what will be analyzed in the next versions of the document, but also referring future open issues. In this latter case, I could include the study of the interaction with different QoS models and the study of multicast usage (even if only with one-to-many schemes). Another question that I got from your answer is the following. The NSIS charter says "The intention is to re-use, where appropriate, the protocol mechanisms of RSVP, while at the same time simplifying it and applying a more general signaling model.". I think that this general signaling model is in contrast with what you said "there is no reason why a resource manager shouldn't be able to handle unicast traffic with nsis and multicast with rsvp". Is this right? It seems that in the end of this charter we'll have a unicast signaling protocol, but not a general signaling protocol for the Internet. This picture is more confuse when we read the definition of a flow in the requirements draft: "Flow: .... The flow can be unicast (uni- or bi-directional) or multicast. For multicast, a flow can diverge into multiple flows as it propagates toward the receiver. For multi-sender multicast, a flow can also diverge when viewed in the reverse direction (toward the senders)." For me, it is clear that multicast is included in the set of issues that are out of scope of the current NSIS charter. In this case, the previous definion of a flow should be modified. What is not clear is if someone has an idea about the road to follow after achieving the current goals (next charter). Cheers, Paulo Hancock, Robert wrote: >hi paulo, > >i (for one) would be quite happy to see it clarified that >no future version of this draft will ever consider multicast. > >there are a number of reasons for this to do with missing >parts of the multicast story in the Internet as a whole >and also the fact that we would have to revisit multicast >in the whole NSIS requirements and framework. > >however, the main point is that I'm pretty sure that if you >tried to invent a multicast NSIS you would end up with >something nearly identical to RSVP (which of course we do >not need to invent again). there is no reason why a resource >manager shouldn't be able to handle unicast traffic with nsis >and multicast with rsvp; and, IMHO, the overlap between >unicast and multicast functionality in the signalling >protocol is rather limited. > >(at least, this is true if you consider traditional IP >multicast in its full glory. the situation for things like >SSM or xcast is probably different, since these are much >easier to handle. all we need is someone to want these >supported strongly enough...) > >cheers, > >r. > > > >>-----Original Message----- >>From: Paulo Mendes [mailto:mendes@docomolab-euro.com] >>Sent: Friday, October 24, 2003 17:44 >>To: Rute C. Sofia >>Cc: sven.van_den_bosch@alcatel.be; nsis@ietf.org >>Subject: Re: [NSIS] Re: qos-nslp-00 >> >> >>Hi all, >> >> >> >>>* would change "it is simplified by the elimination of support for >>>multicast" to something as "it does not address multicast >>> >>> >>support" (which >> >> >>>you actually say a couple of paragraphs after) >>> >>> >>> >>> >>I agree with this point, which leads me to a question: Will >>some future >>version of this draft address the issue of multicast? If not, >>should be >>referred somewhere in this draft that multicast support should be >>analysed in a different document? A lack of any comment about >>this issue >>might be understood as an indication that the future NSIS >>protocol will >>not be able to handle QoS multicast services. >> >>Cheers, >>Paulo >> >>-- >>Paulo Mendes >>DoCoMo Communications Laboratories Europe GmbH >>Landsberger Str. 312 >>80687 Munich, Germany >>Tel. +49-89-56824-226 >>Fax. +49-89-56824-300 >>E-mail: mendes@docomolab-euro.com >>http://www.docomoeurolabs.de/ >> >> >> >>_______________________________________________ >>nsis mailing list >>nsis@ietf.org >>https://www1.ietf.org/mailman/listinfo/nsis >> >> >> > >-- >Registered Office: Roke Manor Research Ltd, Siemens House, Oldbury, Bracknell, >Berkshire. RG12 8FZ > >The information contained in this e-mail and any attachments is confidential to >Roke Manor Research Ltd and must not be passed to any third party without >permission. This communication is for information only and shall not create or >change any contractual relationship. > > > > -- Paulo Mendes DoCoMo Communications Laboratories Europe GmbH Landsberger Str. 312 80687 Munich, Germany Tel. +49-89-56824-226 Fax. +49-89-56824-300 E-mail: mendes@docomolab-euro.com http://www.docomoeurolabs.de/ --------------070603060204090806010607 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit hi Robert,

I agree with you that the experience of RSVP and many-to-many multicast was nor good. But, as you said, we have a different scenario if we consider SSM or xcast like-schemes.

With my questions, I wanted to understand what is opinion of the NSIS community about the inclusion of some lighter form of multicast, instead of the many-to-many considered in RSVP. I completely agree that this is out of scope in the current charter, but what is going to happen in the next charter?
A starting point could be to include in this NSLP (which I think is quite good) some considerations, not only referring to what will be analyzed in the next versions of the document, but also referring future open issues. In this latter case, I could include the study of the interaction with different QoS models and the study of multicast usage (even if only with one-to-many schemes).

Another question that I got from your answer is the following. The NSIS charter says "The intention is to re-use, where appropriate,
the protocol mechanisms of RSVP, while at the same time simplifying it and applying a more general signaling model.". I think that this general signaling model is in contrast with what you said "there is no reason why a resource manager shouldn't be able to handle unicast traffic with nsis and multicast with rsvp". Is this right? It seems that in the end of this charter we'll have a unicast signaling protocol, but not a general signaling protocol for the Internet.

This picture is more confuse when we read the definition of a flow in the requirements draft:
    "Flow: .... The flow can be unicast (uni- or bi-directional) or multicast. For multicast, a flow can diverge into multiple flows as it propagates toward the receiver.  For multi-sender multicast, a flow can also diverge when viewed in the reverse direction (toward the senders)."

For me, it is clear that multicast is included in the set of issues that are out of scope of the current NSIS charter. In this case, the previous definion of a flow should be modified. What is not clear is if someone has an idea about the road to follow after achieving the current goals (next charter).

Cheers,
Paulo

Hancock, Robert wrote:
hi paulo,

i (for one) would be quite happy to see it clarified that 
no future version of this draft will ever consider multicast.

there are a number of reasons for this to do with missing 
parts of the multicast story in the Internet as a whole
and also the fact that we would have to revisit multicast
in the whole NSIS requirements and framework. 

however, the main point is that I'm pretty sure that if you
tried to invent a multicast NSIS you would end up with 
something nearly identical to RSVP (which of course we do
not need to invent again). there is no reason why a resource
manager shouldn't be able to handle unicast traffic with nsis
and multicast with rsvp; and, IMHO, the overlap between 
unicast and multicast functionality in the signalling 
protocol is rather limited.

(at least, this is true if you consider traditional IP 
multicast in its full glory. the situation for things like
SSM or xcast is probably different, since these are much
easier to handle. all we need is someone to want these 
supported strongly enough...)

cheers,

r.

  
-----Original Message-----
From: Paulo Mendes [mailto:mendes@docomolab-euro.com]
Sent: Friday, October 24, 2003 17:44
To: Rute C. Sofia
Cc: sven.van_den_bosch@alcatel.be; nsis@ietf.org
Subject: Re: [NSIS] Re: qos-nslp-00


Hi all,

    
* would change "it is simplified by the elimination of support for
multicast" to something as "it does not address multicast 
      
support" (which
    
you actually say a couple of paragraphs after)
 

      
I agree with this point, which leads me to a question: Will 
some future 
version of this draft address the issue of multicast? If not, 
should be 
referred somewhere in this draft that multicast support should be 
analysed in a different document? A lack of any comment about 
this issue 
might be understood as an indication that the future NSIS 
protocol will 
not be able to handle QoS multicast services.

Cheers,
Paulo

-- 
Paulo Mendes
DoCoMo Communications Laboratories Europe GmbH
Landsberger Str. 312
80687 Munich, Germany
Tel. +49-89-56824-226
Fax. +49-89-56824-300
E-mail: mendes@docomolab-euro.com
http://www.docomoeurolabs.de/



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

    

--
Registered Office: Roke Manor Research Ltd, Siemens House, Oldbury, Bracknell,
Berkshire. RG12 8FZ

The information contained in this e-mail and any attachments is confidential to
Roke Manor Research Ltd and must not be passed to any third party without
permission. This communication is for information only and shall not create or
change any contractual relationship.


  


-- 
Paulo Mendes
DoCoMo Communications Laboratories Europe GmbH
Landsberger Str. 312
80687 Munich, Germany
Tel. +49-89-56824-226
Fax. +49-89-56824-300
E-mail: mendes@docomolab-euro.com
http://www.docomoeurolabs.de/
--------------070603060204090806010607-- ------=_NextPartTM-000-b61b659f-d650-427b-87d7-666acbc8ec19-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Oct 28 15:11:55 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21236 for ; Tue, 28 Oct 2003 15:11:55 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEaBk-0003WE-Vh for nsis-archive@odin.ietf.org; Tue, 28 Oct 2003 15:11:37 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9SKBa6P013509 for nsis-archive@odin.ietf.org; Tue, 28 Oct 2003 15:11:36 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEaBB-0003PP-QH; Tue, 28 Oct 2003 15:11:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEaAN-0003LS-1k for nsis@optimus.ietf.org; Tue, 28 Oct 2003 15:10:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20918 for ; Tue, 28 Oct 2003 15:09:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEaAJ-0005n9-00 for nsis@ietf.org; Tue, 28 Oct 2003 15:10:07 -0500 Received: from deprox.docomolab-euro.com ([212.119.9.186]) by ietf-mx with smtp (Exim 4.12) id 1AEaAJ-0005lm-00 for nsis@ietf.org; Tue, 28 Oct 2003 15:10:07 -0500 Received: from 192.168.0.23 by deprox.docomolab-euro.com (InterScan E-Mail VirusWall NT); Tue, 28 Oct 2003 21:09:27 +0100 Received: from docomolab-euro.com ([192.168.0.138]) by deex.docomolab-euro.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 28 Oct 2003 21:09:27 +0100 Message-ID: <3F9ECC8A.7040304@docomolab-euro.com> Date: Tue, 28 Oct 2003 21:07:38 +0100 From: Paulo Mendes User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030821 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Roland Bless CC: sven.van_den_bosch@alcatel.be, nsis@ietf.org Subject: Re: [NSIS] QoS-NSLP comments References: <3F995519.6040809@docomolab-euro.com> <20031027110349.68fba2bd.bless@tm.uka.de> In-Reply-To: <20031027110349.68fba2bd.bless@tm.uka.de> X-Enigmail-Version: 0.76.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-dff9e2cf-75db-4dfa-9892-f4b3c3a86b85" X-OriginalArrivalTime: 28 Oct 2003 20:09:27.0376 (UTC) FILETIME=[639F1500:01C39D8F] Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPartTM-000-dff9e2cf-75db-4dfa-9892-f4b3c3a86b85 Content-Type: multipart/alternative; boundary="------------060104050302090101040301" --------------060104050302090101040301 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit hi Roland, You're right. I was thinking about policing schemes. This thread is over :). Cheers, Paulo Roland Bless wrote: >Hi Paulo, > > > >>- Policy Object: Policy in QoS related issues leads me to think more >>about dropping of packets that do not comply with some QoS profile, >>than with authentication issues. >> >> > >What you think of is _policing_ (at the network edge), not policy. While >policing is part of traffic conditioning (DiffServ terminology), policy >is important to let providers express their administrative preferences >by a rule set. Thus, you have to consider not only resource >based-admission control, but also policy-based admission control (see >also rap WG). The latter determines whether the user has administrative >permission to make a reservation (see policy control definition in nslp >draft). For example: customer A is not allowed to make reservations for >a certain service class X, but is allowed to make a reservation for >service class Y from 08:00 till 18:00. Therefore, you also need to know >the user's identity and that's where authentication comes in. > >Regards, > Roland > > > -- Paulo Mendes DoCoMo Communications Laboratories Europe GmbH Landsberger Str. 312 80687 Munich, Germany Tel. +49-89-56824-226 Fax. +49-89-56824-300 E-mail: mendes@docomolab-euro.com http://www.docomoeurolabs.de/ --------------060104050302090101040301 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit hi Roland,

You're right. I was thinking about policing schemes. This thread is over :).

Cheers,
Paulo



Roland Bless wrote:
Hi Paulo,

  
- Policy Object: Policy in QoS related issues leads me to think more
about dropping of packets that do not comply with some QoS profile,
than with authentication issues.
    

What you think of is _policing_ (at the network edge), not policy. While
policing is part of traffic conditioning (DiffServ terminology), policy
is important to let providers express their administrative preferences
by a rule set. Thus, you have to consider not only resource
based-admission control, but also policy-based admission control (see
also rap WG). The latter determines whether the user has administrative
permission to make a reservation (see policy control definition in nslp
draft). For example: customer A is not allowed to make reservations for
a certain service class X, but is allowed to make a reservation for
service class Y from 08:00 till 18:00. Therefore, you also need to know
the user's identity and that's where authentication comes in.

Regards,
 Roland

  


-- 
Paulo Mendes
DoCoMo Communications Laboratories Europe GmbH
Landsberger Str. 312
80687 Munich, Germany
Tel. +49-89-56824-226
Fax. +49-89-56824-300
E-mail: mendes@docomolab-euro.com
http://www.docomoeurolabs.de/
--------------060104050302090101040301-- ------=_NextPartTM-000-dff9e2cf-75db-4dfa-9892-f4b3c3a86b85-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Oct 28 15:16:57 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21833 for ; Tue, 28 Oct 2003 15:16:56 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEaGb-0003yW-4e for nsis-archive@odin.ietf.org; Tue, 28 Oct 2003 15:16:37 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9SKGbxN015263 for nsis-archive@odin.ietf.org; Tue, 28 Oct 2003 15:16:37 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEaG1-0003qd-VC; Tue, 28 Oct 2003 15:16:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEaFu-0003po-Kl for nsis@optimus.ietf.org; Tue, 28 Oct 2003 15:15:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21700 for ; Tue, 28 Oct 2003 15:15:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEaFt-0005uw-00 for nsis@ietf.org; Tue, 28 Oct 2003 15:15:53 -0500 Received: from deprox.docomolab-euro.com ([212.119.9.186]) by ietf-mx with smtp (Exim 4.12) id 1AEaFs-0005uh-00 for nsis@ietf.org; Tue, 28 Oct 2003 15:15:52 -0500 Received: from 192.168.0.23 by deprox.docomolab-euro.com (InterScan E-Mail VirusWall NT); Tue, 28 Oct 2003 21:15:07 +0100 Received: from docomolab-euro.com ([192.168.0.138]) by deex.docomolab-euro.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 28 Oct 2003 21:15:06 +0100 Message-ID: <3F9ECDDE.10805@docomolab-euro.com> Date: Tue, 28 Oct 2003 21:13:18 +0100 From: Paulo Mendes User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030821 X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?=22Attila_B=E1der_=28IJ/ETH=29=22?= CC: nsis@ietf.org, sven.van_den_bosch@alcatel.be Subject: Re: [NSIS] QoS-NSLP comments References: In-Reply-To: X-Enigmail-Version: 0.76.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-d60a1811-a61f-497e-9834-d0959c76acd6" X-OriginalArrivalTime: 28 Oct 2003 20:15:06.0907 (UTC) FILETIME=[2DFF66B0:01C39D90] Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPartTM-000-d60a1811-a61f-497e-9834-d0959c76acd6 Content-Type: multipart/alternative; boundary="------------090204020005050505030707" --------------090204020005050505030707 Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id PAA21701 Content-Transfer-Encoding: quoted-printable hi Attila, Comments inline.. Attila B=E1der (IJ/ETH) wrote: >Hi Paulo, > >I tried to answer some of your points, please see my comments inline. > >Best regards, Attila > > =20 > >>-----Original Message----- >>From: Paulo Mendes [mailto:mendes@docomolab-euro.com] >>Sent: Friday, October 24, 2003 6:37 PM >>To: sven.van_den_bosch@alcatel.be >>Cc: nsis@ietf.org >>Subject: [NSIS] QoS-NSLP comments >> >> >>Hi Sven, >> >>Some general comments about the QoS-NSLP draft: >> >>a) Terminology: >>- Why isn't a reduced-state QNE defined? >> =20 >> >=20 >I think it is, 4th from last. > Ups.. It is correct.. >>c) On section 2.5 it is said "In order to allow some local=20 >>selection of which QoS Model to use without destroying all=20 >>end-to-end aspects of the signalling QoS-NSLP allows a=20 >>nesting of QoS Models by 'stacking' more than one pair of=20 >>Control Information / QSpec object within a message".=20 >>Shouldn't this sentence be more general to allow the stacking=20 >>of QSpec instances within the same QoS model? For example, in=20 >>DiffServ type of QoS models, one statefull edge router might=20 >>use the same message to signal another statefull edge router,=20 >>while signalling all reduced-state interior routers in the=20 >>path. Since QSpec to signal edge routers might be different=20 >>from the one to signal interior routers, these models might=20 >>need to stack edge-QSpec inside interior-QSpec. >>Another question about this issue is: How much related with=20 >>section 7.3.2 (tunnel management) is section 2.5 (nested=20 >>protocol operation)? >> >> =20 >> >Well you are right, it could be better formulated. I think the descripti= on is based on the assumption that QoS model is defined by QSpec and Cont= rol Info. I think both nesting of QoS models and nesting of QSpec objects= are needed. The connection with tunnel management is that QoS model or Q= Spec object, used outside the tunnel, can be tunneled. > Since different QoS models have different QSpecs, I think it is enough=20 to refer to nesting of QSpecs instead of nesting of QoS models by=20 stacking QSpecs. > =20 > >> d) Reverse Path State: On section 2.7 it is said that a=20 >>stateless and reduced state QNEs will be able to provide the=20 >>underlying NTLP with some information, namely reverse path=20 >>state. How can this be done in the case of stateless=20 >>operation, in which QNEs are supposed to keep no state? Why=20 >>can't QNEs operating in a statefull mode provide also the=20 >>NTLP with such information? >> >> =20 >> > >I think it is not said. It is said that QNEs provide info about the NSLP= stateless (reduced state) situation. > Agree. What is said is that the stateless NSLP informs the NTLP about=20 its situation. But, the focus that I wanted to give to my question was=20 on the "state" issue. On 2.7 it is said "Stateless and reduced state=20 QoS-NSLP operation makes the most sense when (some nodes of) the=20 underlying NTLP is (are) able to operate in a stateless way as well.".=20 This means that neither the NSLP nor the NTLP keep state, right? In this=20 case, how does a QNE know to want peer it should relay a message? So, I think the core question is related with the definition of state.=20 Does "state" only refers to reservation state, as mentioned in the=20 definition of statefull, reduced-state and stateless operations, or does=20 it refer to any state, including for instance reverse path state? If "state" is referred to any state, my question stands. Otherwise, my=20 question is how much state has a QNE to keep besides the reservation stat= e? This question has something to do with a previous Geib's e-mail, where=20 he asked about "session state". In the same e-mail Sven said "Section=20 2.7 introduces the fact that some QoS models supported by the QoS NSLP=20 might not keep (per-flow) state." By now he have references to reservation state, session state and flow=20 state. I think that the draft needs a clear definition of what is meant=20 by state. In what concerns Geib's question about the maximum per session state=20 maintenance requirements. If by "state" it is meant reservation state,=20 then I agree with Sven, when he said that that is a QoS model issue. But=20 if "state" means any control information, I think that the draft should=20 indicate what is that control state (not reservation state) required by=20 QoS-NSLP (forwarding state, fragmentation state, congestion control=20 state, security state, ....). Any way, I think any control information=20 is important, not only reservation state. Cheers, Paulo --=20 Paulo Mendes DoCoMo Communications Laboratories Europe GmbH Landsberger Str. 312 80687 Munich, Germany Tel. +49-89-56824-226 Fax. +49-89-56824-300 E-mail: mendes@docomolab-euro.com http://www.docomoeurolabs.de/ --------------090204020005050505030707 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit hi Attila,

Comments inline..

Attila Báder (IJ/ETH) wrote:
Hi Paulo,

I tried to answer some of your points, please see my comments inline.

Best regards, Attila

  
-----Original Message-----
From: Paulo Mendes [mailto:mendes@docomolab-euro.com]
Sent: Friday, October 24, 2003 6:37 PM
To: sven.van_den_bosch@alcatel.be
Cc: nsis@ietf.org
Subject: [NSIS] QoS-NSLP comments


Hi Sven,

Some general comments about the QoS-NSLP draft:

a) Terminology:
- Why isn't a reduced-state QNE defined?
    
 
I think it is, 4th from last.
Ups.. It is correct..
c) On section 2.5 it is said "In order to allow some local 
selection of which QoS Model to use without destroying all 
end-to-end aspects of the signalling QoS-NSLP allows a 
nesting of QoS Models by 'stacking' more than one pair of 
Control Information / QSpec object within a message". 
Shouldn't this sentence be more general to allow the stacking 
of QSpec instances within the same QoS model? For example, in 
DiffServ type of QoS models, one statefull edge router might 
use the same message to signal another statefull edge router, 
while signalling all reduced-state interior routers in the 
path. Since QSpec to signal edge routers might be different 
from the one to signal interior routers, these models might 
need to stack edge-QSpec inside interior-QSpec.
Another question about this issue is: How much related with 
section 7.3.2 (tunnel management) is section 2.5 (nested 
protocol operation)?

    
Well you are right, it could be better formulated. I think the description is based on the assumption that QoS model is defined by QSpec and Control Info. I think both nesting of QoS models and nesting of QSpec objects are needed. The connection with tunnel management is that QoS model or QSpec object, used outside the tunnel, can be tunneled.
Since different QoS models have different QSpecs, I think it is enough to refer to nesting of QSpecs instead of nesting of QoS models by stacking QSpecs.
   
 d) Reverse Path State: On section 2.7 it is said that a 
stateless and reduced state QNEs will be able to provide the 
underlying NTLP with some information, namely reverse path 
state. How can this be done in the case of stateless 
operation, in which QNEs are supposed to keep no state? Why 
can't QNEs operating in a statefull mode provide also the 
NTLP with such information?

    

I think it is not said. It is said that QNEs provide info about the NSLP stateless (reduced state) situation.
Agree. What is said is that the stateless NSLP informs the NTLP about its situation. But, the focus that I wanted to give to my question  was on the "state" issue. On 2.7 it is said "Stateless and reduced state QoS-NSLP operation makes the most sense when (some nodes of) the underlying NTLP is (are) able to operate in a stateless way as well.". This means that neither the NSLP nor the NTLP keep state, right? In this case, how does a QNE know to want peer it should relay a message?

So, I think the core question is related with the definition of state. Does "state" only refers to reservation state, as mentioned in the definition of statefull, reduced-state and stateless operations, or does it refer to any state, including for instance reverse path state?
If "state" is referred to any state, my question stands. Otherwise, my question is how much state has a QNE to keep besides the reservation state?

This question has something to do with a previous Geib's e-mail, where he asked about "session state". In the same e-mail Sven said  "Section 2.7 introduces the fact that some QoS models supported by the QoS NSLP might not keep (per-flow) state."

By now he have references to reservation state, session state and flow state. I think that the draft needs a clear definition of what is meant by state.

In what concerns Geib's question about the maximum per session state maintenance requirements. If by "state" it is meant reservation state, then I agree with Sven, when he said that that is a QoS model issue. But if "state" means any control information, I think that the draft should indicate what is that control state (not reservation state) required by QoS-NSLP (forwarding state, fragmentation state, congestion control state, security state, ....). Any way, I think any control information is important, not only reservation state.

Cheers,
Paulo
-- 
Paulo Mendes
DoCoMo Communications Laboratories Europe GmbH
Landsberger Str. 312
80687 Munich, Germany
Tel. +49-89-56824-226
Fax. +49-89-56824-300
E-mail: mendes@docomolab-euro.com
http://www.docomoeurolabs.de/
--------------090204020005050505030707-- ------=_NextPartTM-000-d60a1811-a61f-497e-9834-d0959c76acd6-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Oct 28 15:44:58 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25461 for ; Tue, 28 Oct 2003 15:44:58 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEahj-00017E-2N for nsis-archive@odin.ietf.org; Tue, 28 Oct 2003 15:44:39 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9SKicil003774 for nsis-archive@odin.ietf.org; Tue, 28 Oct 2003 15:44:38 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEah8-0000hG-4T; Tue, 28 Oct 2003 15:44:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEagD-00008I-40 for nsis@optimus.ietf.org; Tue, 28 Oct 2003 15:43:05 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25039; Tue, 28 Oct 2003 15:42:53 -0500 (EST) Message-Id: <200310282042.PAA25039@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: nsis@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 28 Oct 2003 15:42:53 -0500 Subject: [NSIS] I-D ACTION:draft-ietf-nsis-signalling-analysis-03.txt Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , --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 : Analysis of Existing Quality of Service Signaling Protocols Author(s) : J. Manner Filename : draft-ietf-nsis-signalling-analysis-03.txt Pages : 39 Date : 2003-10-28 This document reviews some of the existing QoS signaling protocols for an IP network. The goal here is to learn from them and to avoid common misconceptions. Further, we need to avoid the mistakes during the design and the implementation of any new protocol in this area. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nsis-signalling-analysis-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-nsis-signalling-analysis-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-nsis-signalling-analysis-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-10-28155700.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nsis-signalling-analysis-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nsis-signalling-analysis-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-28155700.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Oct 28 15:44:58 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25463 for ; Tue, 28 Oct 2003 15:44:58 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEahj-00017G-3M for nsis-archive@odin.ietf.org; Tue, 28 Oct 2003 15:44:39 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9SKic88004259 for nsis-archive@odin.ietf.org; Tue, 28 Oct 2003 15:44:38 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEah9-0000hf-ND; Tue, 28 Oct 2003 15:44:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEagY-0000MI-V9 for nsis@optimus.ietf.org; Tue, 28 Oct 2003 15:43:26 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25115; Tue, 28 Oct 2003 15:43:15 -0500 (EST) Message-Id: <200310282043.PAA25115@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: nsis@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 28 Oct 2003 15:43:15 -0500 Subject: [NSIS] I-D ACTION:draft-ietf-nsis-rsvp-sec-properties-03.txt Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , --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 : RSVP Security Properties Author(s) : H. Tschofenig Filename : draft-ietf-nsis-rsvp-sec-properties-03.txt Pages : 45 Date : 2003-10-28 This document summarizes the security properties of RSVP. The goal of this analysis is to benefit from previous work done with RSVP and to capture the knowledge about past activities. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nsis-rsvp-sec-properties-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-nsis-rsvp-sec-properties-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-nsis-rsvp-sec-properties-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-10-28155735.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nsis-rsvp-sec-properties-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nsis-rsvp-sec-properties-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-28155735.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Oct 28 15:45:00 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25515 for ; Tue, 28 Oct 2003 15:45:00 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEahl-00017q-0H for nsis-archive@odin.ietf.org; Tue, 28 Oct 2003 15:44:41 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9SKieKV004309 for nsis-archive@odin.ietf.org; Tue, 28 Oct 2003 15:44:40 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEahA-0000hn-Ad; Tue, 28 Oct 2003 15:44:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEags-0000WA-En for nsis@optimus.ietf.org; Tue, 28 Oct 2003 15:43:46 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25219; Tue, 28 Oct 2003 15:43:34 -0500 (EST) Message-Id: <200310282043.PAA25219@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: nsis@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 28 Oct 2003 15:43:34 -0500 Subject: [NSIS] I-D ACTION:draft-ietf-nsis-threats-03.txt Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , --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 : Security Threats for NSIS Author(s) : H. Tschofenig, D. Kroeselberg Filename : draft-ietf-nsis-threats-03.txt Pages : 22 Date : 2003-10-28 This threats document provides a detailed analysis of the security threats relevant for the NSIS working group. It motivates and helps to understand various security considerations in the NSIS Requirements, Framework and Protocol proposals. This document does not describe vulnerabilities of specific NSIS protocols. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nsis-threats-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-nsis-threats-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-nsis-threats-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-10-28155746.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nsis-threats-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nsis-threats-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-28155746.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Oct 28 16:34:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25462 for ; Tue, 28 Oct 2003 15:44:58 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEahj-00017F-2w for nsis-archive@odin.ietf.org; Tue, 28 Oct 2003 15:44:39 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9SKicUc004253 for nsis-archive@odin.ietf.org; Tue, 28 Oct 2003 15:44:38 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEah9-0000hW-4B; Tue, 28 Oct 2003 15:44:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEagQ-0000Ig-HJ for nsis@optimus.ietf.org; Tue, 28 Oct 2003 15:43:18 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25102; Tue, 28 Oct 2003 15:43:07 -0500 (EST) Message-Id: <200310282043.PAA25102@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: nsis@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 28 Oct 2003 15:43:06 -0500 Subject: [NSIS] I-D ACTION:draft-ietf-nsis-qos-nslp-01.txt Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Next Steps in Signaling Working Group of the IETF. Title : NSLP for Quality-of-Service signaling Author(s) : S. Van den Bosch Filename : draft-ietf-nsis-qos-nslp-01.txt Pages : 30 Date : 2003-10-28 This draft describes an NSIS Signaling Layer Protocol (NSLP) for signaling QoS reservations in the Internet. It is in accordance with the framework and requirements developed in NSIS. Together with the NTLP, it provides functionality similar to RSVP and extends it. The QoS-NSLP is independent of the underlying QoS specification or architecture and provides support for different reservation models. It is simplified by the elimination of support for multicast flows. This version of the draft focuses on the basic protocol structure. It identifies the different message types and describes the basic operation of the protocol to create, refresh, modify and teardown a reservation or to obtain information on the characteristics of the associated data path. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nsis-qos-nslp-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-nsis-qos-nslp-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-nsis-qos-nslp-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-10-28155721.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nsis-qos-nslp-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nsis-qos-nslp-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-28155721.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Oct 28 16:34:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25464 for ; Tue, 28 Oct 2003 15:44:58 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEahj-00017H-3q for nsis-archive@odin.ietf.org; Tue, 28 Oct 2003 15:44:39 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9SKicMw003775 for nsis-archive@odin.ietf.org; Tue, 28 Oct 2003 15:44:38 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEah8-0000hO-Im; Tue, 28 Oct 2003 15:44:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEagJ-0000DM-E0 for nsis@optimus.ietf.org; Tue, 28 Oct 2003 15:43:11 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25083; Tue, 28 Oct 2003 15:42:59 -0500 (EST) Message-Id: <200310282042.PAA25083@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: nsis@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 28 Oct 2003 15:42:59 -0500 Subject: [NSIS] I-D ACTION:draft-ietf-nsis-fw-05.txt Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , --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 : Next Steps in Signaling: Framework Author(s) : R. Hancock Filename : draft-ietf-nsis-fw-05.txt Pages : 45 Date : 2003-10-28 The Next Steps in Signaling working group is considering protocols for signaling information about a data flow along its path in the network. Based on existing work on signaling requirements, this document proposes an architectural framework for such signaling protocols. This document provides a model for the network entities that take part in such signaling, and the relationship between signaling and the rest of network operation. We decompose the overall signaling protocol suite into a generic (lower) layer, with a separate upper layers for each specific signaling application. An initial proposal for the split between these layers is given, describing the overall functionality of the lower layer, and discussing the ways that upper layer behavior can be adapted to specific signaling application requirements. This framework also considers the general interactions between signaling and other network layer functions, specifically routing and mobility. The different routing and mobility events that impact signaling operation are described, along with how their handling should be divided between the generic and application-specific layers. Finally, an example signaling application (for Quality of Service) is described in more detail. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nsis-fw-05.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-nsis-fw-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-nsis-fw-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-10-28155711.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nsis-fw-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nsis-fw-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-28155711.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Wed Oct 29 02:39:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26649 for ; Wed, 29 Oct 2003 02:39:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEkv5-0002cM-91 for nsis-archive@odin.ietf.org; Wed, 29 Oct 2003 02:39:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9T7d7nO010061 for nsis-archive@odin.ietf.org; Wed, 29 Oct 2003 02:39:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEkuz-0002ap-Rr; Wed, 29 Oct 2003 02:39:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEku8-0002Rf-Qy for nsis@optimus.ietf.org; Wed, 29 Oct 2003 02:38:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26583 for ; Wed, 29 Oct 2003 02:37:57 -0500 (EST) From: sven.van_den_bosch@alcatel.be Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEku4-0003aV-00 for nsis@ietf.org; Wed, 29 Oct 2003 02:38:04 -0500 Received: from alc250.alcatel.be ([195.207.101.250] helo=bt0g2p.god.bel.alcatel.be) by ietf-mx with esmtp (Exim 4.12) id 1AEku3-0003Zx-00 for nsis@ietf.org; Wed, 29 Oct 2003 02:38:03 -0500 Received: from bemail04.net.alcatel.be (bemail04.net.alcatel.be [138.203.144.6]) by bt0g2p.god.bel.alcatel.be (8.12.10/8.12.10) with ESMTP id h9T5efr2023770; Wed, 29 Oct 2003 06:40:41 +0100 Subject: Re: [NSIS] QoS-NSLP comments To: Paulo Mendes Cc: "Attila =?iso-8859-1?Q?B=E1der_=28IJ=2FETH=29?=" , nsis@ietf.org X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: Date: Wed, 29 Oct 2003 08:37:25 +0100 X-MIMETrack: Serialize by Router on BEMAIL04/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 10/29/2003 08:37:31 MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable X-Scanned-By: MIMEDefang 2.37 Content-Transfer-Encoding: quoted-printable Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi Paulo, Attila, Please find my take on things inline ... Best regards, Sven Paulo Mendes on 28/10/2003 21:13:18 To: "Attila B=E1der (IJ/ETH)" cc: nsis@ietf.org, Sven VAN DEN BOSCH/BE/ALCATEL@ALCATEL Subject: Re: [NSIS] QoS-NSLP comments hi Attila, Comments inline.. Attila B=E1der (IJ/ETH) wrote: Hi Paulo, I tried to answer some of your points, please see my comments inline. Best regards, Attila -----Original Message----- From: Paulo Mendes [mailto:mendes@docomolab-euro.com] Sent: Friday, October 24, 2003 6:37 PM To: sven.van_den_bosch@alcatel.beCc: nsis@ietf.orgSubject: [NSIS] QoS-N= SLP comments Hi Sven, Some general comments about the QoS-NSLP draft: a) Terminology: - Why isn't a reduced-state QNE defined? I think it is, 4th from last. Ups.. It is correct.. c) On section 2.5 it is said "In order to allow some local selection of which QoS Model to use without destroying all end-to-end aspects of the signalling QoS-NSLP allows a nesting of QoS Models by 'stacking' more than one pair of Control Information / QSpec object within a message". Shouldn't this sentence be more general to allow the stacking of QSpec instances within the same QoS model? For example, in DiffServ type of QoS models, one statefull edge router might use the same message to signal another statefull edge router, while signalling all reduced-state interior routers in the path. Since QSpec to signal edge routers might be different from the one to signal interior routers, these models might need to stack edge-QSpec inside interior-QSpec. Another question about this issue is: How much related with section 7.3.2 (tunnel management) is section 2.5 (nested protocol operation)? Well you are right, it could be better formulated. I think the descript= ion is based on the assumption that QoS model is defined by QSpec and Contr= ol Info. I think both nesting of QoS models and nesting of QSpec objects a= re needed. The connection with tunnel management is that QoS model or QSpe= c object, used outside the tunnel, can be tunneled. Since different QoS models have different QSpecs, I think it is enough = to refer to nesting of QSpecs instead of nesting of QoS models by stacking= QSpecs. Sven>> I think the reason for the formulation that was chosen is the following: The parameters of a QoS model are carried in the QSpec. The = way the QSpec is treated by QNEs may be influenced by Control Information. Therefore, each QSpec could have its associated Control Information. Therefore, we refer to the nesting of QoS models as stacking of QSpec a= nd Control Information. Note that this model could also cover the case tha= t no Control Information is present. This means that Control Information onl= y refers to the next QSpec. I think by allowing to stack just QSpec, you would create confucion in the interpretation of which Control Informati= on applies to which QSpecs, which is something to avoid. Therefore, I woul= d prefer to always think about this in QSPec/CI pairs. d) Reverse Path State: On section 2.7 it is said that a stateless and reduced state QNEs will be able to provide the underlying NTLP with some information, namely reverse path state. How can this be done in the case of stateless operation, in which QNEs are supposed to keep no state? Why can't QNEs operating in a statefull mode provide also the NTLP with such information? I think it is not said. It is said that QNEs provide info about the NSL= P stateless (reduced state) situation. Agree. What is said is that the stateless NSLP informs the NTLP about i= ts situation. But, the focus that I wanted to give to my question=A0 was o= n the "state" issue. On 2.7 it is said "Stateless and reduced state QoS-NSLP operation makes the most sense when (some nodes of) the underlying NTLP= is (are) able to operate in a stateless way as well.". This means that nei= ther the NSLP nor the NTLP keep state, right? In this case, how does a QNE k= now to want peer it should relay a message? So, I think the core question is related with the definition of state. = Does "state" only refers to reservation state, as mentioned in the definitio= n of statefull, reduced-state and stateless operations, or does it refer to = any state, including for instance reverse path state? If "state" is referred to any state, my question stands. Otherwise, my question is how much state has a QNE to keep besides the reservation st= ate? This question has something to do with a previous Geib's e-mail, where = he asked about "session state". In the same e-mail Sven said=A0 "Section 2= .7 introduces the fact that some QoS models supported by the QoS NSLP migh= t not keep (per-flow) state." By now he have references to reservation state, session state and flow state. I think that the draft needs a clear definition of what is meant= by state. Sven>> You are right. We should be more precise and qualify the use of = the word state when we use it. Let me try: A stateless QNE is a QNE that do= es not keep per-flow reservation state (note that no NSLP entity will ever= keep forwarding state). The main reason to have stateless QNEs is to re= duce state keeping requirements. Those will be the sum of the reservation st= ate keeping requirements of the QNE and the forwarding state keeping requirements of the NE. If the NE keeps per-flow forwarding state, the NE+QNE stills scales with the number of flows. Hence the comment that stateless QNEs make the most sense combine with NEs that can take advan= tage of this fact. One way of taking advantage is for the QNE to indicate to= the NE that it does not require its per-flow forwarding state keeping (e.g.= because no messages will ever be sent upstream on the reverse path). Th= en, the NE could always forward messages of that flow based on the destinat= ion IP address and reverse state keeping is not needed. Does this make any sense? In what concerns Geib's question about the maximum per session state maintenance requirements. If by "state" it is meant reservation state, = then I agree with Sven, when he said that that is a QoS model issue. But if "state" means any control information, I think that the draft should indicate what is that control state (not reservation state) required by= QoS-NSLP (forwarding state, fragmentation state, congestion control sta= te, security state, ....). Any way, I think any control information is important, not only reservation state. Cheers, Paulo -- Paulo Mendes DoCoMo Communications Laboratories Europe GmbH Landsberger Str. 312 80687 Munich, Germany Tel. +49-89-56824-226 Fax. +49-89-56824-300 E-mail: mendes@docomolab-euro.comhttp://www.docomoeurolabs.de/ = _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Wed Oct 29 10:18:21 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12462 for ; Wed, 29 Oct 2003 10:18:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEs5C-0002sl-01 for nsis-archive@odin.ietf.org; Wed, 29 Oct 2003 10:18:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9TFI1UJ011061 for nsis-archive@odin.ietf.org; Wed, 29 Oct 2003 10:18:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEs5B-0002sA-C0; Wed, 29 Oct 2003 10:18:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEs4m-0002q7-FO for nsis@optimus.ietf.org; Wed, 29 Oct 2003 10:17:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12389 for ; Wed, 29 Oct 2003 10:17:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEs4k-0002QG-00 for nsis@ietf.org; Wed, 29 Oct 2003 10:17:34 -0500 Received: from wicx01.informatik.uni-wuerzburg.de ([132.187.11.1] helo=europa.informatik.uni-wuerzburg.de) by ietf-mx with esmtp (Exim 4.12) id 1AEs4j-0002QC-00 for nsis@ietf.org; Wed, 29 Oct 2003 10:17:33 -0500 Received: from nero.informatik.uni-wuerzburg.de (wi3x05.informatik.uni-wuerzburg.de [132.187.106.5]) by europa.informatik.uni-wuerzburg.de (8.11.3/8.11.2/SuSE Linux 8.11.1-0.5) with ESMTP id h9TFHWb23338 for ; Wed, 29 Oct 2003 16:17:32 +0100 Received: from informatik.uni-wuerzburg.de (wi3d13.informatik.uni-wuerzburg.de [132.187.106.113]) by nero.informatik.uni-wuerzburg.de (Postfix) with ESMTP id 349D86F58E for ; Wed, 29 Oct 2003 16:16:55 +0100 (CET) Message-ID: <3F9FDA01.2080004@informatik.uni-wuerzburg.de> Date: Wed, 29 Oct 2003 16:17:21 +0100 From: Michael Menth Organization: Lehrstuhl Informatik III, =?ISO-8859-1?Q?Universit=E4t_W=FC?= =?ISO-8859-1?Q?rzburg?= User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: nsis@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [NSIS] Bandwidth Efficiency of Different Reservation Concepts Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi all, recently we have finished some investigations comparing the potential bandwidth utilization for different resource reservation concepts. The studies are independent of protocol issues in the sense that protocols are classified according to the way bandwidth is utilized, e.g. there is the link-by-link resource reservation like the IntServ paradigm, the tunneling approach like RFC3175, or DiffServ-like Admission Control for an enitre network. This performance aspect is not covered in the analysis draft but the basic protocol design affects the bandwidth efficiency significantly. In any case, I think that the following papers are of interest to many people on the nsis list. http://www3.informatik.uni-wuerzburg.de/TR/tr308.pdf http://www3.informatik.uni-wuerzburg.de/staff/menth/Publications/ResilientNAC_COST03029.pdf Kind regards, Michael -- Dipl.-Inform. Michael Menth University of Wuerzburg, Institute of Computer Science Am Hubland, D-97074 Wuerzburg, Germany, room A212 phone: (+49)-931/888-6644, fax: (+49)-931/888-6632 mailto:menth@informatik.uni-wuerzburg.de http://www-info3.informatik.uni-wuerzburg.de/~menth _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Wed Oct 29 12:38:22 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22246 for ; Wed, 29 Oct 2003 12:38:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEuGg-0005fX-V2 for nsis-archive@odin.ietf.org; Wed, 29 Oct 2003 12:38:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9THc2mV021752 for nsis-archive@odin.ietf.org; Wed, 29 Oct 2003 12:38:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEuGf-0005eU-RX; Wed, 29 Oct 2003 12:38:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEuFy-0005Pj-I5 for nsis@optimus.ietf.org; Wed, 29 Oct 2003 12:37:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22226 for ; Wed, 29 Oct 2003 12:37:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEuFw-0006A9-00 for nsis@ietf.org; Wed, 29 Oct 2003 12:37:16 -0500 Received: from infres.enst.fr ([137.194.192.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEuFw-0006A6-00 for nsis@ietf.org; Wed, 29 Oct 2003 12:37:16 -0500 Received: from pcluu (pcluu.enst.fr [137.194.7.121]) by infres.enst.fr (Postfix) with SMTP id 785731B03 for ; Wed, 29 Oct 2003 18:37:14 +0100 (MET) Message-ID: <000f01c39e43$54bee560$7907c289@pcluu> From: "Thanh Tra LUU" To: References: <200310282043.PAA25102@ietf.org> Subject: Re: [NSIS] I-D ACTION:draft-ietf-nsis-qos-nslp-01.txt Date: Wed, 29 Oct 2003 18:37:27 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Dear all , It seems that the life-cycle of a draft version becomes shorter. :o) I still have some question on QoS NSLP. Generally, that is a "too" generic QoS-NSLP to me. As the remarks in the others' mails, I find that there are many more 'should' (23 words) than 'must' (13 words). :o) -You write message name in uppercase (e.g. RESERVE), it can make confusion with class and object name. Can you use lowercase (e.g. Reserve) ? I don't think it as a convention, however, it was used in COPS, RSVP... -To refresh a reservation, everything is done by QoS-NSLP. I don't see the any NTLP functions to support refreshment. However, in the draft of R.Hancock (draft-handcock-nsis-reliability-00), NTLP can be used to support refreshing state between NSLP peers. It raises a question : "If NTLP supports refreshing state, should it know the RSN to do refreshing ? " Note that, RSN can be applied in other signaling applications, eg: the first "trigger message" is marked as RSN=x, the second is x+1 and the third is x+2. If NTLP receives RSN=x+1 and then it receives this message one more time, it considers this message a refresh message. After that it receives message with RSN=x+2 (of the same session id), it knows this is a new trigger message and gives NSLP this message. Somebody has answered me NTLP should not know RSN because it belongs to NSLP. According to me, NTLP should know to support refreshing state, reason : this is a generic function of NTLP to support most of NSLP applications. Please correct me if i am wrong. - For "QUERY" message, if no NSLP (reservation state) is established, does this message go back to the previous hop (as the Resv of RSVP) or it will be directly sent to the hop which initiated the "QUERY" message (in some cases, this hop is not an edge node) ? If it does, hop by hop security is suitable ? - It seems obscure to me the ResponseRequest object, how is the flag 'local' used ? RII is unique to a NSLP node or global in a local 'region' ? Can we simpify the problem by putting in RII the address of the node which wants to receive a REPONSE ? (it's only my propose) - I totally agree the 6.2. The fonction routing change detection is done by NTLP. - It seems to be a new requirement for NTLP to detect that there is no more NSLPs (e.g. QoS-NSLP) on the path (6.3). I think it is good but it needs some explications. Regards. Nary Tra ENST, Paris ----- Original Message ----- From: To: Cc: Sent: Tuesday, October 28, 2003 9:43 PM Subject: [NSIS] I-D ACTION:draft-ietf-nsis-qos-nslp-01.txt _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu Oct 30 08:42:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21866 for ; Thu, 30 Oct 2003 08:42:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFD3t-0005Lw-GQ for nsis-archive@odin.ietf.org; Thu, 30 Oct 2003 08:42:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9UDg5mj020560 for nsis-archive@odin.ietf.org; Thu, 30 Oct 2003 08:42:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFD3q-0005L2-11; Thu, 30 Oct 2003 08:42:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFD2v-0005Ha-4y for nsis@optimus.ietf.org; Thu, 30 Oct 2003 08:41:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21819 for ; Thu, 30 Oct 2003 08:40:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFD2t-0003IQ-00 for nsis@ietf.org; Thu, 30 Oct 2003 08:41:03 -0500 Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx with esmtp (Exim 4.12) id 1AFD2t-0003Hx-00 for nsis@ietf.org; Thu, 30 Oct 2003 08:41:03 -0500 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2657.72) id ; Thu, 30 Oct 2003 13:40:25 -0000 Message-ID: From: "Hancock, Robert" To: "'Thanh Tra LUU'" , nsis@ietf.org Subject: RE: [NSIS] I-D ACTION:draft-ietf-nsis-qos-nslp-01.txt Date: Thu, 30 Oct 2003 13:40:25 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , hi all, a brief comment on the refresh/NSLP/NTLP question. > -To refresh a reservation, everything is done by QoS-NSLP. I don't see the > any NTLP functions to support refreshment. However, in the draft of > R.Hancock (draft-handcock-nsis-reliability-00), NTLP can be used to support > refreshing state between NSLP peers. i think this is a misunderstanding. the draft mentioned classifies various different sorts of signalling messages (and some of them are refresh messages). the role of the NTLP is to deliver all messages, but it doesn't care directly if they are refreshes or something else. in other words, the NTLP doesn't include specific functionality for refreshing signalling application state, it provides a message delivery capability which signalling applications can use to refresh their own state. this specific issue is further discussed in 3.2.5 of the framework. it was discussed on the mailing list quite intensively (around April/May this year). > It raises a question : "If NTLP > supports refreshing state, should it know the RSN to do refreshing ? " Note > that, RSN can be applied in other signaling applications, eg: the first > "trigger message" is marked as RSN=x, the second is x+1 and the third is > x+2. If NTLP receives RSN=x+1 and then it receives this message one more > time, it considers this message a refresh message. After that it receives > message with RSN=x+2 (of the same session id), it knows this is a new > trigger message and gives NSLP this message. Somebody has answered me NTLP > should not know RSN because it belongs to NSLP. According to me, NTLP should > know to support refreshing state, reason : this is a generic function of > NTLP to support most of NSLP applications. Please correct me if i am wrong. please see above. hope this helps. r. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu Oct 30 09:47:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23789 for ; Thu, 30 Oct 2003 09:47:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFE4p-0003zN-Ow for nsis-archive@odin.ietf.org; Thu, 30 Oct 2003 09:47:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9UEl7oS015327 for nsis-archive@odin.ietf.org; Thu, 30 Oct 2003 09:47:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFE4j-0003yT-Uc; Thu, 30 Oct 2003 09:47:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFE3v-0003ul-Rh for nsis@optimus.ietf.org; Thu, 30 Oct 2003 09:46:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23683 for ; Thu, 30 Oct 2003 09:46:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFE3t-0004Ei-00 for nsis@ietf.org; Thu, 30 Oct 2003 09:46:09 -0500 Received: from infres.enst.fr ([137.194.192.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFE3t-0004Ef-00 for nsis@ietf.org; Thu, 30 Oct 2003 09:46:09 -0500 Received: from pcluu (pcluu.enst.fr [137.194.7.121]) by infres.enst.fr (Postfix) with SMTP id B07BA1B02; Thu, 30 Oct 2003 15:46:05 +0100 (MET) Message-ID: <005401c39ef4$9b47f920$7907c289@pcluu> From: "Thanh Tra LUU" To: "Hancock, Robert" Cc: References: Subject: Re: [NSIS] I-D ACTION:draft-ietf-nsis-qos-nslp-01.txt Date: Thu, 30 Oct 2003 15:46:27 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit hi, I do not mean NTLP refreshes the signaling application state. It is enough clear about this one. I did not clearly express my thought. We can consider RSN (RSN is just a name) as a message sequential number of NSLP and NTLP should know this number as a NTLP state number. It helps NTLP to filter only new NSLP message to transfert to NSLP. Regards, Nary Tra ENST, Paris ----- Original Message ----- From: "Hancock, Robert" To: "'Thanh Tra LUU'" ; Sent: Thursday, October 30, 2003 2:40 PM Subject: RE: [NSIS] I-D ACTION:draft-ietf-nsis-qos-nslp-01.txt > hi all, > > a brief comment on the refresh/NSLP/NTLP question. > > > -To refresh a reservation, everything is done by QoS-NSLP. I don't see the > > any NTLP functions to support refreshment. However, in the draft of > > R.Hancock (draft-handcock-nsis-reliability-00), NTLP can be used to > support > > refreshing state between NSLP peers. > > i think this is a misunderstanding. the draft mentioned classifies various > different sorts of signalling messages (and some of them are refresh > messages). the role of the NTLP is to deliver all messages, but it > doesn't care directly if they are refreshes or something else. in other > words, the NTLP doesn't include specific functionality for refreshing > signalling application state, it provides a message delivery capability > which signalling applications can use to refresh their own state. > > this specific issue is further discussed in 3.2.5 of the framework. > it was discussed on the mailing list quite intensively (around April/May > this year). > > > It raises a question : "If NTLP > > supports refreshing state, should it know the RSN to do refreshing ? " > Note > > that, RSN can be applied in other signaling applications, eg: the first > > "trigger message" is marked as RSN=x, the second is x+1 and the third is > > x+2. If NTLP receives RSN=x+1 and then it receives this message one more > > time, it considers this message a refresh message. After that it receives > > message with RSN=x+2 (of the same session id), it knows this is a new > > trigger message and gives NSLP this message. Somebody has answered me NTLP > > should not know RSN because it belongs to NSLP. According to me, NTLP > should > > know to support refreshing state, reason : this is a generic function of > > NTLP to support most of NSLP applications. Please correct me if i am > wrong. > > please see above. hope this helps. > > r. > > -- > Registered Office: Roke Manor Research Ltd, Siemens House, Oldbury, Bracknell, > Berkshire. RG12 8FZ > > The information contained in this e-mail and any attachments is confidential to > Roke Manor Research Ltd and must not be passed to any third party without > permission. This communication is for information only and shall not create or > change any contractual relationship. > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu Oct 30 09:52:21 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24024 for ; Thu, 30 Oct 2003 09:52:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFE9a-0004Xy-2j for nsis-archive@odin.ietf.org; Thu, 30 Oct 2003 09:52:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9UEq2KT017441 for nsis-archive@odin.ietf.org; Thu, 30 Oct 2003 09:52:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFE9Z-0004X8-Qp; Thu, 30 Oct 2003 09:52:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFE8q-0004TH-4j for nsis@optimus.ietf.org; Thu, 30 Oct 2003 09:51:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24014 for ; Thu, 30 Oct 2003 09:51:05 -0500 (EST) From: sven.van_den_bosch@alcatel.be Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFE8o-0004Mw-00 for nsis@ietf.org; Thu, 30 Oct 2003 09:51:14 -0500 Received: from alc245.alcatel.be ([195.207.101.245] helo=relay4.alcatel.be) by ietf-mx with esmtp (Exim 4.12) id 1AFE8n-0004Mb-00 for nsis@ietf.org; Thu, 30 Oct 2003 09:51:13 -0500 Received: from bemail04.net.alcatel.be (bemail04.net.alcatel.be [138.203.144.6]) by relay4.alcatel.be (8.12.10/8.12.10) with ESMTP id h9UEogn0015530; Thu, 30 Oct 2003 15:50:42 +0100 Subject: Re: [NSIS] I-D ACTION:draft-ietf-nsis-qos-nslp-01.txt To: "Thanh Tra LUU" Cc: "Hancock, Robert" , X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: Date: Thu, 30 Oct 2003 15:50:32 +0100 X-MIMETrack: Serialize by Router on BEMAIL04/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 10/30/2003 15:50:41 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Scanned-By: MIMEDefang 2.37 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Hi, I am not sure if it is a good idea to filter messages out in the NTLP because you assume the NSLP will not need them (because it believes the message is not new). It is probably cleaner if the NTLP does not need to know about the RSN in the first place. Best regards, Sven "Thanh Tra LUU" @ietf.org on 30/10/2003 15:46:27 Sent by: nsis-admin@ietf.org To: "Hancock, Robert" cc: Subject: Re: [NSIS] I-D ACTION:draft-ietf-nsis-qos-nslp-01.txt hi, I do not mean NTLP refreshes the signaling application state. It is enough clear about this one. I did not clearly express my thought. We can consider RSN (RSN is just a name) as a message sequential number of NSLP and NTLP should know this number as a NTLP state number. It helps NTLP to filter only new NSLP message to transfert to NSLP. Regards, Nary Tra ENST, Paris ----- Original Message ----- From: "Hancock, Robert" To: "'Thanh Tra LUU'" ; Sent: Thursday, October 30, 2003 2:40 PM Subject: RE: [NSIS] I-D ACTION:draft-ietf-nsis-qos-nslp-01.txt > hi all, > > a brief comment on the refresh/NSLP/NTLP question. > > > -To refresh a reservation, everything is done by QoS-NSLP. I don't see the > > any NTLP functions to support refreshment. However, in the draft of > > R.Hancock (draft-handcock-nsis-reliability-00), NTLP can be used to > support > > refreshing state between NSLP peers. > > i think this is a misunderstanding. the draft mentioned classifies various > different sorts of signalling messages (and some of them are refresh > messages). the role of the NTLP is to deliver all messages, but it > doesn't care directly if they are refreshes or something else. in other > words, the NTLP doesn't include specific functionality for refreshing > signalling application state, it provides a message delivery capability > which signalling applications can use to refresh their own state. > > this specific issue is further discussed in 3.2.5 of the framework. > it was discussed on the mailing list quite intensively (around April/May > this year). > > > It raises a question : "If NTLP > > supports refreshing state, should it know the RSN to do refreshing ? " > Note > > that, RSN can be applied in other signaling applications, eg: the first > > "trigger message" is marked as RSN=x, the second is x+1 and the third is > > x+2. If NTLP receives RSN=x+1 and then it receives this message one more > > time, it considers this message a refresh message. After that it receives > > message with RSN=x+2 (of the same session id), it knows this is a new > > trigger message and gives NSLP this message. Somebody has answered me NTLP > > should not know RSN because it belongs to NSLP. According to me, NTLP > should > > know to support refreshing state, reason : this is a generic function of > > NTLP to support most of NSLP applications. Please correct me if i am > wrong. > > please see above. hope this helps. > > r. > > -- > Registered Office: Roke Manor Research Ltd, Siemens House, Oldbury, Bracknell, > Berkshire. RG12 8FZ > > The information contained in this e-mail and any attachments is confidential to > Roke Manor Research Ltd and must not be passed to any third party without > permission. This communication is for information only and shall not create or > change any contractual relationship. > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu Oct 30 10:08:21 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25033 for ; Thu, 30 Oct 2003 10:08:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFEP4-0006z9-Ax for nsis-archive@odin.ietf.org; Thu, 30 Oct 2003 10:08:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9UF819d026829 for nsis-archive@odin.ietf.org; Thu, 30 Oct 2003 10:08:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFEP3-0006yd-JO; Thu, 30 Oct 2003 10:08:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFEO7-0006gW-6b for nsis@optimus.ietf.org; Thu, 30 Oct 2003 10:07:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24825 for ; Thu, 30 Oct 2003 10:06:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFEO4-0004Zz-00 for nsis@ietf.org; Thu, 30 Oct 2003 10:07:00 -0500 Received: from infres.enst.fr ([137.194.192.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFEO4-0004Zr-00 for nsis@ietf.org; Thu, 30 Oct 2003 10:07:00 -0500 Received: from pcluu (pcluu.enst.fr [137.194.7.121]) by infres.enst.fr (Postfix) with SMTP id E7F4C1B30 for ; Thu, 30 Oct 2003 16:06:57 +0100 (MET) Message-ID: <006d01c39ef7$844dae60$7907c289@pcluu> From: "Thanh Tra LUU" To: References: Subject: Re: [NSIS] I-D ACTION:draft-ietf-nsis-qos-nslp-01.txt Date: Thu, 30 Oct 2003 16:07:20 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit hi Sven, For NSLP can receive a message, RSN can increase. Anyway, RSN is not a suitable name to discuss about this problem. More generally, can we suppose that when there is a sequential number for each trigger NSLP message and it can be used by NTLP to filter NSLP message before it is sent to NSLP. For NSLP can receive a message, this number must be inscreased. Of course, NSLP can refresh its own state by sending Refresh messge with a increased number. Regards. Nary Tra ENST, Paris ----- Original Message ----- From: To: "Thanh Tra LUU" Cc: "Hancock, Robert" ; Sent: Thursday, October 30, 2003 3:50 PM Subject: Re: [NSIS] I-D ACTION:draft-ietf-nsis-qos-nslp-01.txt > Hi, > > I am not sure if it is a good idea to filter messages out in the NTLP > because you assume the NSLP will not need them (because it believes the > message is not new). It is probably cleaner if the NTLP does not need to > know about the RSN in the first place. > > Best regards, > Sven _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu Oct 30 10:08:22 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25042 for ; Thu, 30 Oct 2003 10:08:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFEP5-00070C-2x for nsis-archive@odin.ietf.org; Thu, 30 Oct 2003 10:08:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9UF82jq026865 for nsis-archive@odin.ietf.org; Thu, 30 Oct 2003 10:08:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFEP4-0006zB-Cv; Thu, 30 Oct 2003 10:08:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFEOm-0006tm-JU for nsis@optimus.ietf.org; Thu, 30 Oct 2003 10:07:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24933 for ; Thu, 30 Oct 2003 10:07:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFEOk-0004b2-00 for nsis@ietf.org; Thu, 30 Oct 2003 10:07:42 -0500 Received: from rsys002a.roke.co.uk ([193.118.192.251]) by ietf-mx with esmtp (Exim 4.12) id 1AFEOj-0004a7-00 for nsis@ietf.org; Thu, 30 Oct 2003 10:07:41 -0500 Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2657.72) id ; Thu, 30 Oct 2003 15:07:08 -0000 Message-ID: From: "Hancock, Robert" To: "'sven.van_den_bosch@alcatel.be'" , Thanh Tra LUU Cc: nsis@ietf.org Subject: RE: [NSIS] I-D ACTION:draft-ietf-nsis-qos-nslp-01.txt Date: Thu, 30 Oct 2003 15:07:17 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , hi, > Hi, > > I am not sure if it is a good idea to filter messages out in the NTLP > because you assume the NSLP will not need them (because it believes the > message is not new). It is probably cleaner if the NTLP does not need to > know about the RSN in the first place. > > Best regards, > Sven this would also absolutely be my view. lower layers should not do thinking on behalf of upper layers. if it is possible for an entity to know not to send a message, why not do this in the layer that the message is generated, rather than asking a lower layer to guess that the message wasn't really needed? r. > > > > > > "Thanh Tra LUU" @ietf.org on 30/10/2003 15:46:27 > > Sent by: nsis-admin@ietf.org > > > To: "Hancock, Robert" > cc: > Subject: Re: [NSIS] I-D ACTION:draft-ietf-nsis-qos-nslp-01.txt > > > hi, > > I do not mean NTLP refreshes the signaling application state. > It is enough > clear about this one. I did not clearly express my thought. > We can consider > RSN (RSN is just a name) as a message sequential number of > NSLP and NTLP > should know this number as a NTLP state number. It helps NTLP > to filter > only > new NSLP message to transfert to NSLP. > > Regards, > > Nary Tra > ENST, Paris > > ----- Original Message ----- > From: "Hancock, Robert" > To: "'Thanh Tra LUU'" ; > Sent: Thursday, October 30, 2003 2:40 PM > Subject: RE: [NSIS] I-D ACTION:draft-ietf-nsis-qos-nslp-01.txt > > > > hi all, > > > > a brief comment on the refresh/NSLP/NTLP question. > > > > > -To refresh a reservation, everything is done by > QoS-NSLP. I don't see > the > > > any NTLP functions to support refreshment. However, in > the draft of > > > R.Hancock (draft-handcock-nsis-reliability-00), NTLP can > be used to > > support > > > refreshing state between NSLP peers. > > > > i think this is a misunderstanding. the draft mentioned classifies > various > > different sorts of signalling messages (and some of them are refresh > > messages). the role of the NTLP is to deliver all messages, but it > > doesn't care directly if they are refreshes or something > else. in other > > words, the NTLP doesn't include specific functionality for > refreshing > > signalling application state, it provides a message > delivery capability > > which signalling applications can use to refresh their own state. > > > > this specific issue is further discussed in 3.2.5 of the framework. > > it was discussed on the mailing list quite intensively > (around April/May > > this year). > > > > > It raises a question : "If NTLP > > > supports refreshing state, should it know the RSN to do > refreshing ? " > > Note > > > that, RSN can be applied in other signaling applications, > eg: the first > > > "trigger message" is marked as RSN=x, the second is x+1 > and the third > is > > > x+2. If NTLP receives RSN=x+1 and then it receives this > message one > more > > > time, it considers this message a refresh message. After that it > receives > > > message with RSN=x+2 (of the same session id), it knows > this is a new > > > trigger message and gives NSLP this message. Somebody has > answered me > NTLP > > > should not know RSN because it belongs to NSLP. According > to me, NTLP > > should > > > know to support refreshing state, reason : this is a > generic function > of > > > NTLP to support most of NSLP applications. Please correct > me if i am > > wrong. > > > > please see above. hope this helps. > > > > r. > > > > -- > > Registered Office: Roke Manor Research Ltd, Siemens House, Oldbury, > Bracknell, > > Berkshire. RG12 8FZ > > > > The information contained in this e-mail and any attachments is > confidential to > > Roke Manor Research Ltd and must not be passed to any third > party without > > permission. This communication is for information only and shall not > create or > > change any contractual relationship. > > > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > > > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu Oct 30 10:49:23 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27673 for ; Thu, 30 Oct 2003 10:49:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFF2m-0003DT-NP for nsis-archive@odin.ietf.org; Thu, 30 Oct 2003 10:49:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9UFn4qN012345 for nsis-archive@odin.ietf.org; Thu, 30 Oct 2003 10:49:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFF2j-0003CO-U2; Thu, 30 Oct 2003 10:49:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFF24-00037n-KN for nsis@optimus.ietf.org; Thu, 30 Oct 2003 10:48:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27630 for ; Thu, 30 Oct 2003 10:48:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFF22-0005FV-00 for nsis@ietf.org; Thu, 30 Oct 2003 10:48:18 -0500 Received: from infres.enst.fr ([137.194.192.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFF21-0005FR-00 for nsis@ietf.org; Thu, 30 Oct 2003 10:48:17 -0500 Received: from pcluu (pcluu.enst.fr [137.194.7.121]) by infres.enst.fr (Postfix) with SMTP id 0BD691B56 for ; Thu, 30 Oct 2003 16:47:40 +0100 (MET) Message-ID: <00b001c39efd$3550ad20$7907c289@pcluu> From: "Thanh Tra LUU" To: References: <006d01c39ef7$844dae60$7907c289@pcluu> Subject: Re: [NSIS] I-D ACTION:draft-ietf-nsis-qos-nslp-01.txt Date: Thu, 30 Oct 2003 16:48:03 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit hi Robert, I have the same thought as you have stated : "why not do this in the layer that the message is generated, rather than asking a lower layer to guess that the message wasn't really needed? ". However, this function is generic for signaing applications. It avoids implementing refresh burden (as possible) for NSLP application. Every different NSLP types can use this one and NTLP will optimise this function. It can filter message for many instances of different NSLPs at the same time. In this case, NTLP state refreshing is more meaningful. On the other hand, in the draft of Melinda, draft-shore-ntlp-00.txt, (5.5.4) she talked about 2 mechanisms. I review the second mechanism " The second mechanism is to periodically send full, standard NTLP with complete NSLP payloads as appropriate. ". I think it is good if we use the sequential number in this case. Regards, Nary Tra, ENST, Paris. > > this would also absolutely be my view. lower layers should not do > thinking on behalf of upper layers. if it is possible for an entity > to know not to send a message, why not do this in the layer that > the message is generated, rather than asking a lower layer to guess > that the message wasn't really needed? > > r. > hi Sven, > > For NSLP can receive a message, RSN can increase. Anyway, RSN is not a > suitable name to discuss about this problem. More generally, can we suppose > that when there is a sequential number for each trigger NSLP message and it > can be used by NTLP to filter NSLP message before it is sent to NSLP. For > NSLP can receive a message, this number must be inscreased. Of course, NSLP > can refresh its own state by sending Refresh messge with a increased number. > > Regards. > > Nary Tra > ENST, Paris _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu Oct 30 11:08:20 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28637 for ; Thu, 30 Oct 2003 11:08:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFFL7-0006j0-EQ for nsis-archive@odin.ietf.org; Thu, 30 Oct 2003 11:08:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9UG811k025833 for nsis-archive@odin.ietf.org; Thu, 30 Oct 2003 11:08:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFFL7-0006iU-7T; Thu, 30 Oct 2003 11:08:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFFKX-0006YA-OQ for nsis@optimus.ietf.org; Thu, 30 Oct 2003 11:07:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28586 for ; Thu, 30 Oct 2003 11:07:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFFKV-0005bi-00 for nsis@ietf.org; Thu, 30 Oct 2003 11:07:23 -0500 Received: from rsys002a.roke.co.uk ([193.118.192.251]) by ietf-mx with esmtp (Exim 4.12) id 1AFFKU-0005b5-00 for nsis@ietf.org; Thu, 30 Oct 2003 11:07:22 -0500 Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2657.72) id ; Thu, 30 Oct 2003 16:06:51 -0000 Message-ID: From: "Hancock, Robert" To: "'Paulo Mendes'" Cc: nsis@ietf.org Subject: RE: [NSIS] Re: qos-nslp-00 Date: Thu, 30 Oct 2003 16:07:01 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , hi paulo, > I agree with you that the experience of RSVP and many-to-many > multicast was nor good. But, as you said, we have a different > scenario if we consider SSM or xcast like-schemes. well, to be strict, what i was trying to say was that actually RSVP including multicast is complicated, but because the problem is fundamentally complicated it is probably not possible to do any better. anyway... > With my questions, I wanted to understand what is opinion of the > NSIS community about the inclusion of some lighter form of > multicast, instead of the many-to-many considered in RSVP. I > completely agree that this is out of scope in the current > charter, but what is going to happen in the next charter? > A starting point could be to include in this NSLP (which I think > is quite good) some considerations, not only referring to what > will be analyzed in the next versions of the document, but also > referring future open issues. In this latter case, I could > include the study of the interaction with different QoS models > and the study of multicast usage (even if only with one-to-many > schemes). this would be an approach. > Another question that I got from your answer is the following. > The NSIS charter says "The intention is to re-use, where > appropriate, > the protocol mechanisms of RSVP, while at the same time > simplifying it and applying a more general signaling model.". I > think that this general signaling model is in contrast with what > you said "there is no reason why a resource manager shouldn't be > able to handle unicast traffic with nsis and multicast with > rsvp". Is this right? It seems that in the end of this charter > we'll have a unicast signaling protocol, but not a general > signaling protocol for the Internet. well, this is a good question about charter scope and engineering feasibility. but my interpretation of the "general signalling model" phrase in the charter is to do with handling multiple signalling applications (rather than QoS with an IntServ focus as RSVP does), and not to do with handling unicast + multicast together. my engineering prejudice is that building protocols which integrate unicast and multicast (ASM) is not a good idea; we don't try to do it with routing, transport or security protocols, and we shouldn't try to do it with signalling protocols, at least not the NTLP (which has interactions with routing, transport and security functions), especially when you start to pin down error conditions. > This picture is more confuse when we read the definition of a flow > in the requirements draft: > "Flow: .... The flow can be unicast (uni- or bi-directional) or > multicast. For multicast, a flow can diverge into multiple flows as > it propagates toward the receiver. For multi-sender multicast, a > flow can also diverge when viewed in the reverse direction (toward > the senders)." > For me, it is clear that multicast is included in the set of issues > that are out of scope of the current NSIS charter. In this case, the > previous definion of a flow should be modified. What is not clear is > if someone has an idea about the road to follow after achieving the > current goals (next charter). I agree it's confusing that the req draft includes multicast in the flow defn but doesn't later include any statements about whether it is actually a requirement. Your final question I cannot answer! r. > Cheers, > Paulo _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Fri Oct 31 03:07:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17053 for ; Fri, 31 Oct 2003 03:07:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFUJL-0002sM-8C for nsis-archive@odin.ietf.org; Fri, 31 Oct 2003 03:07:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9V87A9n011016 for nsis-archive@odin.ietf.org; Fri, 31 Oct 2003 03:07:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFUJC-0002qS-6e; Fri, 31 Oct 2003 03:07:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFUIr-0002on-Eq for nsis@optimus.ietf.org; Fri, 31 Oct 2003 03:06:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17031 for ; Fri, 31 Oct 2003 03:06:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFUIn-0003Z2-00 for nsis@ietf.org; Fri, 31 Oct 2003 03:06:37 -0500 Received: from smtp102.mail.sc5.yahoo.com ([216.136.174.140]) by ietf-mx with smtp (Exim 4.12) id 1AFUIm-0003Yz-00 for nsis@ietf.org; Fri, 31 Oct 2003 03:06:36 -0500 Received: from unknown (HELO KimHui) (lingkimhui@202.14.153.7 with login) by smtp.mail.vip.sc5.yahoo.com with SMTP; 31 Oct 2003 08:06:35 -0000 From: "Ling Kim Hui" To: Subject: RE: [NSIS] I-D ACTION:draft-ietf-nsis-fw-05.txt Date: Fri, 31 Oct 2003 16:06:51 +0800 Message-ID: <000901c39f85$f48ffe10$4e71510a@KimHui> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000A_01C39FC9.02B33E10" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_000A_01C39FC9.02B33E10 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Mr Hancock and all, I think this latest framework draft is a good piece of work. I have some comments and wish to seek some clarifications. Thanks in advance! * In section 3.1.2, it is mentioned that in the path-coupled case, signaling messages do not have to reach all the nodes on the data path. Does it mean that signaling will be able to skip some of the NEs on the data path, bypassing even the NTLP layer? * In section 3.2.5 (pt 4), we consider a case of route change when a peer has failed or become available. Consider the case of a peer failure, in the event of a NE failure (NTLP not accessible) instead of a whole node failure (normal operations of a router such as routing are still available). Is this case classified as a route change? If not, how can we differentiate this from a real route change (failure of the entire node)? * In section 3.3.1, "Where signaling is looking for the last (nearest to receiver) NE on the data path, receiver oriented signaling is most efficient". Looking in another perspective, the receiver oriented signaling needs to discover the last NE (the first NE with respect to the sender) on the data path in the reverse direction. It seems to me that signaling in either directions will encounter similar difficulties. Can I seek clarification on this issue? * In section 4.2 paragraph 2, "With peer-peer addressing, an NE will determine the address of the next NE based on the payload of the message (and potentially on the previous NE)." It is possible that some information in the payload is accessible to NSLP only. Therefore the function requires some interaction between NTLP and NSLP. Would there be a clear definition of what is the information necessary to be accessible by the NTLP in the payload for the peer discovery? For example, flow classifiers (so that NTLP could interact with routing protocols)? * In section 4.6.2 paragraph 2, "In addition, the session identifier can be used by the NTLP to demultiplex received signaling messages between multiple instances of the same signaling application, if such an operational scenario is supported." The demultiplex of the multiple instance of the same signaling application should be done at the NSLP layer. What's more, this cannot replace the Signaling Application Identifier, since there will be no Session Identifier exists on a NE before any session was setup even though the NSLP is installed on the node. Recommended change: Remove this statement. * In section 4.6.3 paragraph 2, "No position is taken on the form of the signaling application identifier, or even the structure of the signaling application 'space' - free-standing applications, potentially overlapping groups of capabilities, etc." The Signaling Application Identifier should be defined and managed by the NSIS framework, like the protocol number for IP. Otherwise, it will lose the capability for interoperation. E.g. If QoS NSLP from vender A take a form a of the identifier, and QoS NSLP from vender B take a form b of the identifier, they will never be able to interoperate even though they are implementating the same protocol. Recommended change: Replace statement with "Format of the signaling application identifier will be defined and mantained by the NSIS framework." Thank you very much for your time and attention. Regards, Kim Hui ------=_NextPart_000_000A_01C39FC9.02B33E10 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Hi Mr Hancock and = all,
 
    I think this = latest=20 framework draft is a good piece of work.  I have = some=20 comments and wish to seek some clarifications.  Thanks in=20 advance!
 

* In section 3.1.2, it is mentioned that in the path-coupled case, = signaling=20 messages do not have to reach all the nodes on the data path. Does it = mean that=20 signaling will be able to skip some of the NEs on the data path, = bypassing even=20 the NTLP layer?

 

* In section 3.2.5 (pt 4), we consider a case of route change when a = peer has=20 failed or become available. Consider the case of a peer failure, in the = event of=20 a NE failure (NTLP not accessible) instead of a whole node failure = (normal=20 operations of a router such as routing are still available). Is this = case=20 classified as a route change? If not, how can we differentiate this from = a real=20 route change (failure of the entire node)?

 

* In section 3.3.1, "Where signaling is looking for the last (nearest = to=20 receiver) NE on the data path, receiver oriented signaling is most = efficient".=20 Looking in another perspective, the receiver oriented signaling needs to = discover the last NE (the first NE with respect to the sender) on the = data path=20 in the reverse direction. It seems to me that signaling in either = directions=20 will encounter similar difficulties. Can I seek clarification on this = issue?

 

* In section 4.2 paragraph 2, "With peer-peer addressing, an NE will=20 determine the address of the next NE based on the payload of the message = (and=20 potentially on the previous NE)." It is possible that some information = in the=20 payload is accessible to NSLP only. Therefore the function requires some = interaction between NTLP and NSLP. Would there be a clear definition of = what is=20 the information necessary to be accessible by the NTLP in the payload = for the=20 peer discovery? For example, flow classifiers (so that NTLP could = interact with=20 routing protocols)?

 

* In section 4.6.2 paragraph 2, "In addition, the session identifier = can be=20 used by the NTLP to demultiplex received signaling messages between = multiple=20 instances of the same signaling application, if such an operational = scenario is=20 supported." The demultiplex of the multiple instance of the same = signaling=20 application should be done at the NSLP layer. What's more, this cannot = replace=20 the Signaling Application Identifier, since there will be no Session = Identifier=20 exists on a NE before any session was setup even though the NSLP is = installed on=20 the node.

Recommended change: Remove this statement.

 

* In section 4.6.3 paragraph = 2, "No=20 position is taken on the form of the signaling application identifier, = or even=20 the structure of the signaling application 'space' - free-standing = applications,=20 potentially overlapping groups of capabilities, etc." The Signaling = Application=20 Identifier should be defined and managed by the NSIS framework, like the = protocol number for IP. Otherwise, it will lose the capability for=20 interoperation. E.g. If QoS NSLP from vender A take a form a of the = identifier,=20 and QoS NSLP from vender B take a form b of the identifier, they will = never be=20 able to interoperate even though they are implementating the same = protocol.

Recommended change: Replace statement with "Format of the signaling=20 application identifier will be defined and mantained by the NSIS = framework."

 

Thank you very much for your time and attention.

 

Regards,

Kim Hui

------=_NextPart_000_000A_01C39FC9.02B33E10-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Fri Oct 31 03:08:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17123 for ; Fri, 31 Oct 2003 03:08:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFUKG-00039q-SP for nsis-archive@odin.ietf.org; Fri, 31 Oct 2003 03:08:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9V887aF012112 for nsis-archive@odin.ietf.org; Fri, 31 Oct 2003 03:08:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFUKE-00038f-5A; Fri, 31 Oct 2003 03:08:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFUJq-0002zN-FU for nsis@optimus.ietf.org; Fri, 31 Oct 2003 03:07:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17065 for ; Fri, 31 Oct 2003 03:07:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFUJm-0003Ze-00 for nsis@ietf.org; Fri, 31 Oct 2003 03:07:38 -0500 Received: from smtp013.mail.yahoo.com ([216.136.173.57]) by ietf-mx with smtp (Exim 4.12) id 1AFUJl-0003Zb-00 for nsis@ietf.org; Fri, 31 Oct 2003 03:07:37 -0500 Received: from unknown (HELO KimHui) (lingkimhui@202.14.153.7 with login) by smtp.mail.vip.sc5.yahoo.com with SMTP; 31 Oct 2003 08:07:36 -0000 From: "Ling Kim Hui" To: Subject: RE: [NSIS] I-D ACTION:draft-ietf-nsis-fw-05.txt Date: Fri, 31 Oct 2003 16:07:44 +0800 Message-ID: <000f01c39f86$18ea05d0$4e71510a@KimHui> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0010_01C39FC9.270D45D0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_0010_01C39FC9.270D45D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Mr Hancock and all, I think this latest framework draft is a good piece of work. I have some comments and wish to seek some clarifications. Thanks in advance! * In section 3.1.2, it is mentioned that in the path-coupled case, signaling messages do not have to reach all the nodes on the data path. Does it mean that signaling will be able to skip some of the NEs on the data path, bypassing even the NTLP layer? * In section 3.2.5 (pt 4), we consider a case of route change when a peer has failed or become available. Consider the case of a peer failure, in the event of a NE failure (NTLP not accessible) instead of a whole node failure (normal operations of a router such as routing are still available). Is this case classified as a route change? If not, how can we differentiate this from a real route change (failure of the entire node)? * In section 3.3.1, "Where signaling is looking for the last (nearest to receiver) NE on the data path, receiver oriented signaling is most efficient". Looking in another perspective, the receiver oriented signaling needs to discover the last NE (the first NE with respect to the sender) on the data path in the reverse direction. It seems to me that signaling in either directions will encounter similar difficulties. Can I seek clarification on this issue? * In section 4.2 paragraph 2, "With peer-peer addressing, an NE will determine the address of the next NE based on the payload of the message (and potentially on the previous NE)." It is possible that some information in the payload is accessible to NSLP only. Therefore the function requires some interaction between NTLP and NSLP. Would there be a clear definition of what is the information necessary to be accessible by the NTLP in the payload for the peer discovery? For example, flow classifiers (so that NTLP could interact with routing protocols)? * In section 4.6.2 paragraph 2, "In addition, the session identifier can be used by the NTLP to demultiplex received signaling messages between multiple instances of the same signaling application, if such an operational scenario is supported." The demultiplex of the multiple instance of the same signaling application should be done at the NSLP layer. What's more, this cannot replace the Signaling Application Identifier, since there will be no Session Identifier exists on a NE before any session was setup even though the NSLP is installed on the node. Recommended change: Remove this statement. * In section 4.6.3 paragraph 2, "No position is taken on the form of the signaling application identifier, or even the structure of the signaling application 'space' - free-standing applications, potentially overlapping groups of capabilities, etc." The Signaling Application Identifier should be defined and managed by the NSIS framework, like the protocol number for IP. Otherwise, it will lose the capability for interoperation. E.g. If QoS NSLP from vender A take a form a of the identifier, and QoS NSLP from vender B take a form b of the identifier, they will never be able to interoperate even though they are implementating the same protocol. Recommended change: Replace statement with "Format of the signaling application identifier will be defined and mantained by the NSIS framework." Thank you very much for your time and attention. Regards, Kim Hui ------=_NextPart_000_0010_01C39FC9.270D45D0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Hi Mr Hancock and = all,
 
    I think this = latest=20 framework draft is a good piece of work.  I have = some=20 comments and wish to seek some clarifications.  Thanks in=20 advance!
 

* In section 3.1.2, it is mentioned that in the path-coupled case, = signaling=20 messages do not have to reach all the nodes on the data path. Does it = mean that=20 signaling will be able to skip some of the NEs on the data path, = bypassing even=20 the NTLP layer?

 

* In section 3.2.5 (pt 4), we consider a case of route change when a = peer has=20 failed or become available. Consider the case of a peer failure, in the = event of=20 a NE failure (NTLP not accessible) instead of a whole node failure = (normal=20 operations of a router such as routing are still available). Is this = case=20 classified as a route change? If not, how can we differentiate this from = a real=20 route change (failure of the entire node)?

 

* In section 3.3.1, "Where signaling is looking for the last (nearest = to=20 receiver) NE on the data path, receiver oriented signaling is most = efficient".=20 Looking in another perspective, the receiver oriented signaling needs to = discover the last NE (the first NE with respect to the sender) on the = data path=20 in the reverse direction. It seems to me that signaling in either = directions=20 will encounter similar difficulties. Can I seek clarification on this = issue?

 

* In section 4.2 paragraph 2, "With peer-peer addressing, an NE will=20 determine the address of the next NE based on the payload of the message = (and=20 potentially on the previous NE)." It is possible that some information = in the=20 payload is accessible to NSLP only. Therefore the function requires some = interaction between NTLP and NSLP. Would there be a clear definition of = what is=20 the information necessary to be accessible by the NTLP in the payload = for the=20 peer discovery? For example, flow classifiers (so that NTLP could = interact with=20 routing protocols)?

 

* In section 4.6.2 paragraph 2, "In addition, the session identifier = can be=20 used by the NTLP to demultiplex received signaling messages between = multiple=20 instances of the same signaling application, if such an operational = scenario is=20 supported." The demultiplex of the multiple instance of the same = signaling=20 application should be done at the NSLP layer. What's more, this cannot = replace=20 the Signaling Application Identifier, since there will be no Session = Identifier=20 exists on a NE before any session was setup even though the NSLP is = installed on=20 the node.

Recommended change: Remove this statement.

 

* In section 4.6.3 paragraph = 2, "No=20 position is taken on the form of the signaling application identifier, = or even=20 the structure of the signaling application 'space' - free-standing = applications,=20 potentially overlapping groups of capabilities, etc." The Signaling = Application=20 Identifier should be defined and managed by the NSIS framework, like the = protocol number for IP. Otherwise, it will lose the capability for=20 interoperation. E.g. If QoS NSLP from vender A take a form a of the = identifier,=20 and QoS NSLP from vender B take a form b of the identifier, they will = never be=20 able to interoperate even though they are implementating the same = protocol.

Recommended change: Replace statement with "Format of the signaling=20 application identifier will be defined and mantained by the NSIS = framework."

 

Thank you very much for your time and attention.

 

Regards,

Kim Hui

------=_NextPart_000_0010_01C39FC9.270D45D0-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Fri Oct 31 04:04:23 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18265 for ; Fri, 31 Oct 2003 04:04:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFVCN-0000SG-KP for nsis-archive@odin.ietf.org; Fri, 31 Oct 2003 04:04:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9V943vQ001725 for nsis-archive@odin.ietf.org; Fri, 31 Oct 2003 04:04:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFVCM-0000Ri-69; Fri, 31 Oct 2003 04:04:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFVBo-0000PI-P8 for nsis@optimus.ietf.org; Fri, 31 Oct 2003 04:03:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18247 for ; Fri, 31 Oct 2003 04:03:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFVBl-0004AF-00 for nsis@ietf.org; Fri, 31 Oct 2003 04:03:25 -0500 Received: from mailsrv.psl.com.sg ([202.14.153.3]) by ietf-mx with esmtp (Exim 4.12) id 1AFVBk-00049G-00 for nsis@ietf.org; Fri, 31 Oct 2003 04:03:24 -0500 Received: from netpronote3 (netpronote3.psl.com.sg [10.81.113.71]) by mailsrv.psl.com.sg (8.12.9/8.12.9) with SMTP id h9V8sRRn004568; Fri, 31 Oct 2003 16:54:27 +0800 (SGT) From: "Cheng Hong" To: , Cc: "Thanh Tra LUU" Subject: RE: [NSIS] I-D ACTION:draft-ietf-nsis-qos-nslp-01.txt Date: Fri, 31 Oct 2003 17:05:53 +0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4927.1200 Importance: Normal In-reply-to: <000f01c39e43$54bee560$7907c289@pcluu> Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Nary Tra, Sven, and all, I have the similar question as Nary about the RII. Is that the same as SII? Can it be just replace by the SII or using the same value? Besides that, I have a few more comments on the -01 draft. a) Section 1.2 says "Only messages related to QoS are passed to the QoS-NSLP. The NTLP may also generate triggers to the QoS-NSLP (e.g.indications that a route change has occurred)." I don't think QoS-NSLP would be the only QoS related Signaling Application. It is somehow confusing. Therefore, I think it maybe better to clarify that as: "Only messages related to the particular QoS NSLP, e.g. indicated by the Signaling Application Identifier defined in 4.6.3 of [3], are passed to the QoS-NSLP.The NTLP may also generate triggers to the QoS-NSLP (e.g.indications that a route change has occurred)." b) In Section 2.1, it says "Messages are normally passed from the NSLP to the NTLP via an API,which also specifies the signaling application (as QoS-NSLP), the flow/session identifier, and an indication of the intended direction - towards data sender or receiver." It sounds that the session identifier is provided through the NTLP. And other than here, there is no mentioning about the session identifier. My feeling is that it is better for the NSLP to actual maintain the session ID, since there my be several session come from the same NSLP instance, and only NSLP knows how to correlate the session and flows. Therefore, it would be better to provide some description about the operation on session ID in the NSLP draft. c) In section 3.1 RESERVE, it is mentioned that "Note that the potential initiation of (reverse path) state removal at the NTLP is a separate issue. This will be signaled over the API between NTLP and QoS-NSLP." Shouldn't the state removal a business of the NSLP only? NTLP could provide hint/trigger for that, but the decision should still be made by the NSLP. Also, whether to use API for this purpose is purely implementation issue, e.g. we could use loopback message instead. cheers Cheng Hong > -----Original Message----- > From: nsis-admin@ietf.org [mailto:nsis-admin@ietf.org]On Behalf Of Thanh > Tra LUU > Sent: Thursday, October 30, 2003 1:37 AM > To: nsis@ietf.org > Subject: Re: [NSIS] I-D ACTION:draft-ietf-nsis-qos-nslp-01.txt > > > > Dear all , > > It seems that the life-cycle of a draft version becomes shorter. :o) > > I still have some question on QoS NSLP. Generally, that is a "too" generic > QoS-NSLP to me. As the remarks in the others' mails, I find that there are > many more 'should' (23 words) than 'must' (13 words). :o) > > -You write message name in uppercase (e.g. RESERVE), it can make confusion > with class and object name. Can you use lowercase (e.g. Reserve) ? I don't > think it as a convention, however, it was used in COPS, RSVP... > > -To refresh a reservation, everything is done by QoS-NSLP. I don't see the > any NTLP functions to support refreshment. However, in the draft of > R.Hancock (draft-handcock-nsis-reliability-00), NTLP can be used > to support > refreshing state between NSLP peers. It raises a question : "If NTLP > supports refreshing state, should it know the RSN to do > refreshing ? " Note > that, RSN can be applied in other signaling applications, eg: the first > "trigger message" is marked as RSN=x, the second is x+1 and the third is > x+2. If NTLP receives RSN=x+1 and then it receives this message one more > time, it considers this message a refresh message. After that it receives > message with RSN=x+2 (of the same session id), it knows this is a new > trigger message and gives NSLP this message. Somebody has answered me NTLP > should not know RSN because it belongs to NSLP. According to me, > NTLP should > know to support refreshing state, reason : this is a generic function of > NTLP to support most of NSLP applications. Please correct me if i > am wrong. > > - For "QUERY" message, if no NSLP (reservation state) is established, does > this message go back to the previous hop (as the Resv of RSVP) or > it will be > directly sent to the hop which initiated the "QUERY" message (in > some cases, > this hop is not an edge node) ? If it does, hop by hop security > is suitable > ? > > - It seems obscure to me the ResponseRequest object, how is the > flag 'local' > used ? RII is unique to a NSLP node or global in a local 'region' ? Can we > simpify the problem by putting in RII the address of the node > which wants to > receive a REPONSE ? (it's only my propose) > > - I totally agree the 6.2. The fonction routing change detection > is done by > NTLP. > > - It seems to be a new requirement for NTLP to detect that there > is no more > NSLPs (e.g. QoS-NSLP) on the path (6.3). I think it is good but it needs > some explications. > > Regards. > > Nary Tra > ENST, Paris > > > ----- Original Message ----- > From: > To: > Cc: > Sent: Tuesday, October 28, 2003 9:43 PM > Subject: [NSIS] I-D ACTION:draft-ietf-nsis-qos-nslp-01.txt > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Fri Oct 31 04:40:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19219 for ; Fri, 31 Oct 2003 04:40:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFVlM-0003xp-CX for nsis-archive@odin.ietf.org; Fri, 31 Oct 2003 04:40:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9V9eC8Q015187 for nsis-archive@odin.ietf.org; Fri, 31 Oct 2003 04:40:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFVlE-0003wl-8Q; Fri, 31 Oct 2003 04:40:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFVkT-0003su-9C for nsis@optimus.ietf.org; Fri, 31 Oct 2003 04:39:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19186 for ; Fri, 31 Oct 2003 04:39:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFVkQ-0004fE-00 for nsis@ietf.org; Fri, 31 Oct 2003 04:39:14 -0500 Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx with esmtp (Exim 4.12) id 1AFVkP-0004eW-00 for nsis@ietf.org; Fri, 31 Oct 2003 04:39:13 -0500 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2657.72) id ; Fri, 31 Oct 2003 09:38:41 -0000 Message-ID: From: "Hancock, Robert" To: "'lingkimhui@yahoo.com.sg'" Cc: "'nsis@ietf.org'" Subject: RE: [NSIS] I-D ACTION:draft-ietf-nsis-fw-05.txt Date: Fri, 31 Oct 2003 09:38:45 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , hi Kim Hui, thanks for these comments. i'm hoping most of them can be viewed/handled as clarifications (i think it's difficult to make substantive changes on our own now the WG last call has completed, but i'll try to work in whatever is necessary when I do updates following AD/IESG review.) > -----Original Message----- > From: Ling Kim Hui [mailto:lingkimhui@yahoo.com.sg] > Sent: Friday, October 31, 2003 08:07 > To: nsis@ietf.org > Subject: RE: [NSIS] I-D ACTION:draft-ietf-nsis-fw-05.txt > > > Hi Mr Hancock and all, > > I think this latest framework draft is a good piece of > work. I have some comments and wish to seek some > clarifications. Thanks in advance! > > * In section 3.1.2, it is mentioned that in the path-coupled > case, signaling messages do not have to reach all the nodes > on the data path. Does it mean that signaling will be able to > skip some of the NEs on the data path, bypassing even the NTLP layer? the main purpose of 3.1.2 is to say that if a node is not a signalling node (just a routing node) you don't have to make signalling go through it. (i see that the phrasing of the first sentence might make it seem like node=NE which is not intended.) the question of how to handle bypassing intermediate nodes which are signalling aware is discussed in 3.2.3, including whether or not the NTLP should be involved there. however, it is left open by the framework, since we can't really decide what is possible without going into the actual protocol design. > > * In section 3.2.5 (pt 4), we consider a case of route change > when a peer has failed or become available. Consider the case > of a peer failure, in the event of a NE failure (NTLP not > accessible) instead of a whole node failure (normal > operations of a router such as routing are still available). > Is this case classified as a route change? If not, how can we > differentiate this from a real route change (failure of the > entire node)? i consider this as coming under the broad heading of route changes. there are actually several different categories of route change anyway (different peer because of topology change, different peer because of NE failure but no rerouting, same peer but different ingress or egress interfaces, same peer but different intermediate routers, ...) exactly how each case is distinguished and handled will have to be done during protocol design. different protocol designs and indeed different implementations will be able to do different types of route change handling, so the framework can't really define this. > > * In section 3.3.1, "Where signaling is looking for the last > (nearest to receiver) NE on the data path, receiver oriented > signaling is most efficient". Looking in another perspective, > the receiver oriented signaling needs to discover the last NE > (the first NE with respect to the sender) on the data path in > the reverse direction. It seems to me that signaling in > either directions will encounter similar difficulties. Can I > seek clarification on this issue? this is probably not well phrased. it refers to the case where the signalling application needs to involve the NE closest to the flow receiver. finding this NE may need a message from the sender, but the actual signalling application negotiation is most efficiently carried out between NE and receiver (which is receiver initiation, loosely). > > * In section 4.2 paragraph 2, "With peer-peer addressing, an > NE will determine the address of the next NE based on the > payload of the message (and potentially on the previous NE)." > It is possible that some information in the payload is > accessible to NSLP only. Therefore the function requires some > interaction between NTLP and NSLP. Would there be a clear > definition of what is the information necessary to be > accessible by the NTLP in the payload for the peer discovery? > For example, flow classifiers (so that NTLP could interact > with routing protocols)? the information is the flow id (4.6.1). we specifically don't call this the flow classifier, since the NTLP isn't interested in packet classification; another name for the flow id would be 'flow routing information' (which is what the NTLP draft calls it). the NSLP might use the flow id as part of a packet classifier. > > * In section 4.6.2 paragraph 2, "In addition, the session > identifier can be used by the NTLP to demultiplex received > signaling messages between multiple instances of the same > signaling application, if such an operational scenario is > supported." The demultiplex of the multiple instance of the > same signaling application should be done at the NSLP layer. > What's more, this cannot replace the Signaling Application > Identifier, since there will be no Session Identifier exists > on a NE before any session was setup even though the NSLP is > installed on the node. > Recommended change: Remove this statement. the demultiplexing possibility is mainly related to load sharing if you need to achieve some very high level of signalling application processing in a single node. there is (I hope) no suggestion that the session id could replace this signalling application id. > > * In section 4.6.3 paragraph 2, "No position is taken on the > form of the signaling application identifier, or even the > structure of the signaling application 'space' - > free-standing applications, potentially overlapping groups of > capabilities, etc." The Signaling Application Identifier > should be defined and managed by the NSIS framework, like the > protocol number for IP. Otherwise, it will lose the > capability for interoperation. E.g. If QoS NSLP from vender A > take a form a of the identifier, and QoS NSLP from vender B > take a form b of the identifier, they will never be able to > interoperate even though they are implementating the same protocol. > Recommended change: Replace statement with "Format of the > signaling application identifier will be defined and > mantained by the NSIS framework." formally, the f/w is not a standards track document, so it cannot define and manage identifier formats in this way. at the moment it seems likely that the session id will be an object in the NTLP, so the NTLP specification will pin this down and the sort of problems you indicate cannot arise. > > Thank you very much for your time and attention. it was a pleasure! r. > > Regards, > Kim Hui > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis