From mailnull@www1.ietf.org Mon Dec 2 07:06:07 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11082 for ; Mon, 2 Dec 2002 07:06:07 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB2C8Qf25289 for nsis-archive@odin.ietf.org; Mon, 2 Dec 2002 07:08:26 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB2C8Ov25274; Mon, 2 Dec 2002 07:08:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB2C75v24849 for ; Mon, 2 Dec 2002 07:07:05 -0500 Received: from rsys002a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11060 for ; Mon, 2 Dec 2002 07:04:15 -0500 (EST) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Mon, 2 Dec 2002 12:07:02 -0000 Message-ID: <76C92FBBFB58D411AE760090271ED4181EA6D7@rsys002a.roke.co.uk> From: "Hancock, Robert" To: nsis@ietf.org Subject: RE: [NSIS] Interim Meeting Query Date: Mon, 2 Dec 2002 12:07:01 -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: , John, I can see the value in an interim meeting, provided we have time to explore new-ish technical issues in real detail, i.e. framework and beyond (including protocol issues - not to make decisions, but to avoid future discussions being at such cross purposes). One aspect I would particularly like to talk about is 'how much should we try to "handle" mobility, and how could this be done'. This all depends a bit on who comes, of course. For me, later is better - we need enough time for discussion beforehand (taking into account the several null weeks there will be around christmas/new year) and a few days for document updating afterwards before #56. So mid-Feb would be ideal. January would be hard. Cheers, Robert H. > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > Sent: 27 November 2002 13:23 > To: nsis@ietf.org > Subject: [NSIS] Interim Meeting Query > > > Hi all, > > As both previous IETF meetings (54 & 55) have been quite > busy, there is a possibility for an interim meeting before > IETF 56. IETF 56 is March 16-21, 2003 - so early February > may very well be the best time frame for a meeting. I > discussed the possibilites with our ADs and Allison suggest > she might be able to host it in New Jersey, which might be > preferable as it is in between those on the West Coast and > those in Europe. > > Topics to discuss would be: > > 1) Framework document > 2) Analysis document > 3) 2 layer functionality split > 4) Settling the existing security docs > > Is anyone interested in this? > > 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 mailnull@www1.ietf.org Mon Dec 2 18:37:11 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17810 for ; Mon, 2 Dec 2002 18:37:11 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB2NdZo11155 for nsis-archive@odin.ietf.org; Mon, 2 Dec 2002 18:39:35 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB2NdVv11146; Mon, 2 Dec 2002 18:39:31 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB2Ncqv11109 for ; Mon, 2 Dec 2002 18:38:52 -0500 Received: from sj-msg-core-3.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17775 for ; Mon, 2 Dec 2002 18:35:56 -0500 (EST) Received: from mira-sjc5-7.cisco.com (IDENT:mirapoint@mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id gB2NcQ0J019432; Mon, 2 Dec 2002 15:38:26 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAT39749; Mon, 2 Dec 2002 15:31:51 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id PAA19942; Mon, 2 Dec 2002 15:38:41 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15851.61185.392591.364355@thomasm-u1.cisco.com> Date: Mon, 2 Dec 2002 15:38:41 -0800 (PST) To: "Hancock, Robert" Cc: nsis@ietf.org Subject: RE: [NSIS] Use IPSec draft In-Reply-To: <76C92FBBFB58D411AE760090271ED41805DF6037@rsys002a.roke.co.uk> References: <76C92FBBFB58D411AE760090271ED41805DF6037@rsys002a.roke.co.uk> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! 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 Hancock, Robert writes: > Hi, > > I like this draft also, especially the warning in section 2 ("If IPsec is a bad choice, use another standardized, well-understood security protocol. Don't roll your own.") Personally, I feel the security problems for general path-coupled signalling taken as a whole are sufficiently weird that it's worth considering how to slice the problem up at the architectural stage to get a better match to existing "standardized, well-understood security protocol[s]". But I know other people object to this style of approach. FWIW, I think we should spend the lion's share of time just enumerating the requirements and let the chips fall as they may. Even if the choice ends up being something other than IPsec, whatever takes its place needs to meet those requirements. In particular, what's already in RFC2749 and 2752 would be a good starting point for defining the requirements. Mike _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Mon Dec 2 18:47:45 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18094 for ; Mon, 2 Dec 2002 18:47:45 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB2NoAL11781 for nsis-archive@odin.ietf.org; Mon, 2 Dec 2002 18:50:10 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB2No9v11774; Mon, 2 Dec 2002 18:50:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB2NnKv11718 for ; Mon, 2 Dec 2002 18:49:20 -0500 Received: from sj-msg-core-4.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18071 for ; Mon, 2 Dec 2002 18:46:24 -0500 (EST) Received: from mira-sjc5-7.cisco.com (IDENT:mirapoint@mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id gB2NnCcb028210; Mon, 2 Dec 2002 15:49:12 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAT40120; Mon, 2 Dec 2002 15:42:22 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id PAA19945; Mon, 2 Dec 2002 15:49:11 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15851.61815.107921.938861@thomasm-u1.cisco.com> Date: Mon, 2 Dec 2002 15:49:11 -0800 (PST) To: "Hancock, Robert" Cc: nsis@ietf.org Subject: [NSIS] attempted summary of next-peer issue (was: RE: next peer issue in rsvp-sec) In-Reply-To: <76C92FBBFB58D411AE760090271ED41805DF6034@rsys002a.roke.co.uk> References: <76C92FBBFB58D411AE760090271ED41805DF6034@rsys002a.roke.co.uk> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! 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 Hancock, Robert writes: > Hi Kuntal, Sven, Ping, Michael, John, Melinda, Hannes, all, > > It seems a number of issues have got combined here. Here is an attempted summary. Let me know if I missed or confused something. > > 1. If the originator knows the route the traffic is taking up to the next peer, it can send the signalling message to the right place no problem - there is *no next-peer issue* in this case. (This could be either because the originator is doing traffic engineering, or has complete IGP knowledge, or is telepathic, or whatever.) It can send the signalling message with an ERO object or with what the framework (currently) calls peer-peer addressing; in any case, there is *no problem*. I think this probably just points out a previously un(der)solved problem: if the next peer isn't directly adjacent how do you know which one it will be? Solving for this first makes the keying problem tractable, I'd think. The question is what scale you need to solve for. The current solution of pre-shared keys and manually set up SA's is not very attractive as the mesh gets larger. Also: one thing that Steve's draft should *really* drive home as hard as possible with the clue-by-four is that Key Management is an extremely large pain in the patochkie. Non-security working groups should be extremely fearful of recreating them. As in, if at all possible beg, borrow or steal even if it makes for some warts; do not assume you're smarter than security geeks on this front. Mike _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Dec 3 04:01:56 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11848 for ; Tue, 3 Dec 2002 04:01:56 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB394Rd23069 for nsis-archive@odin.ietf.org; Tue, 3 Dec 2002 04:04:27 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB394Ov23047; Tue, 3 Dec 2002 04:04:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB393xv23026 for ; Tue, 3 Dec 2002 04:03:59 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11805 for ; Tue, 3 Dec 2002 04:00:57 -0500 (EST) From: john.loughney@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gB394tW08740 for ; Tue, 3 Dec 2002 11:04:55 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Tue, 3 Dec 2002 11:03:46 +0200 Received: from esebe008.NOE.Nokia.com ([172.21.138.48]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 3 Dec 2002 11:03:46 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe008.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 3 Dec 2002 11:03:45 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Tue, 3 Dec 2002 11:03:44 +0200 Message-ID: Thread-Topic: [NSIS] attempted summary of next-peer issue (was: RE: next peer issue in rsvp-sec) Thread-Index: AcKaXZF8+L9WgMYuTiyDSHiNapkCMwATRjdg To: X-OriginalArrivalTime: 03 Dec 2002 09:03:45.0845 (UTC) FILETIME=[E2B55E50:01C29AAA] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gB393xv23027 Subject: [NSIS] NSIS Requirements 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: 8bit Hi all, WE've been working on the requirements for a while and I think we are getting close to needing to ship it to the IETF. With that in mind, I would request Marcus to update the document based on discussions in Atlanta, then we will start a WG last call. Please note, that the document can never be perfect nor complete, so we need make certain compromises, etc. thanks, John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Dec 3 04:01:58 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11861 for ; Tue, 3 Dec 2002 04:01:58 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB394Sc23081 for nsis-archive@odin.ietf.org; Tue, 3 Dec 2002 04:04:28 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB394Qv23062; Tue, 3 Dec 2002 04:04:26 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB392Sv22935 for ; Tue, 3 Dec 2002 04:02:28 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11758 for ; Tue, 3 Dec 2002 03:59:26 -0500 (EST) From: john.loughney@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gB393OW07214 for ; Tue, 3 Dec 2002 11:03:24 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Tue, 3 Dec 2002 11:02:07 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 3 Dec 2002 11:02:07 +0200 Received: from esebe001.NOE.Nokia.com ([172.21.138.30]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 3 Dec 2002 11:02:06 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 3 Dec 2002 11:02:06 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Tue, 3 Dec 2002 11:02:05 +0200 Message-ID: Thread-Topic: [NSIS] attempted summary of next-peer issue (was: RE: next peer issue in rsvp-sec) Thread-Index: AcKaXZF8+L9WgMYuTiyDSHiNapkCMwATKbpA To: X-OriginalArrivalTime: 03 Dec 2002 09:02:06.0384 (UTC) FILETIME=[A76CD300:01C29AAA] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gB392Sv22936 Subject: [NSIS] Plans for NSIS 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: 8bit Hi all, I have received some feedback that some other SDOs are looking at NSIS, but there is a fear that we will not get the work done in time to be useful. What I propose is that we need to have an initial version of the nsis protocol, even if it is just an outline, ready for discussion at an interim meeting. There have been a number of proposals, so we have some things to look at. What I think is needed is to get a good editor for this work, someone neutral but with a decent amount of experience in this area. I am going to chat with the ADs on this, but I am happy to get suggestions for this (no self-nominations please) off the list. thanks, John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Dec 3 04:05:34 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11975 for ; Tue, 3 Dec 2002 04:05:34 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB3985c23844 for nsis-archive@odin.ietf.org; Tue, 3 Dec 2002 04:08:05 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB3983v23837; Tue, 3 Dec 2002 04:08:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB397hv23812 for ; Tue, 3 Dec 2002 04:07:43 -0500 Received: from mgw-x1.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11936 for ; Tue, 3 Dec 2002 04:04:41 -0500 (EST) From: john.loughney@nokia.com Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gB396nG01273 for ; Tue, 3 Dec 2002 11:06:49 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Tue, 3 Dec 2002 11:07:24 +0200 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 3 Dec 2002 11:07:25 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe013.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 3 Dec 2002 11:07:25 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Tue, 3 Dec 2002 11:07:24 +0200 Message-ID: Thread-Topic: [NSIS] attempted summary of next-peer issue (was: RE: next peer issue in rsvp-sec) Thread-Index: AcKaXZF8+L9WgMYuTiyDSHiNapkCMwATVIbg To: X-OriginalArrivalTime: 03 Dec 2002 09:07:25.0374 (UTC) FILETIME=[658ED5E0:01C29AAB] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gB397hv23813 Subject: [NSIS] NSIS Analysis 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: 8bit Hi all, Jukka Manner has editted an analysis doc: http://www.ietf.org/internet-drafts/draft-ietf-nsis-signalling-analysis-00.txt We need to capture some additional material for this document and then see how much more work is needed. In Atlanta, there were a number of voices suggesting that some basic functionality is not broken, so does not need to be changed. If there are folks looking new and novel ways to perform signaling that is not in keeping with the RSVP model, then they must provide some analysis why what RSVP is doing, is broken. Otherwise, we will start with some basic assumptions for the NSIS protocol from RSVP. I don't think that basing some mechanisms on RSVP is a bad thing, that is why there needs to be documented reasons if we choose to do something else. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Dec 3 04:08:36 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12034 for ; Tue, 3 Dec 2002 04:08:36 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB39B6L24007 for nsis-archive@odin.ietf.org; Tue, 3 Dec 2002 04:11:06 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB39B4v24000; Tue, 3 Dec 2002 04:11:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB39Alv23953 for ; Tue, 3 Dec 2002 04:10:47 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12029 for ; Tue, 3 Dec 2002 04:07:45 -0500 (EST) From: john.loughney@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gB39BhW14821 for ; Tue, 3 Dec 2002 11:11:43 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Tue, 3 Dec 2002 11:10:32 +0200 Received: from esebe011.NOE.Nokia.com ([172.21.138.50]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 3 Dec 2002 11:10:33 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe011.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 3 Dec 2002 11:10:30 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Tue, 3 Dec 2002 11:10:26 +0200 Message-ID: Thread-Topic: [NSIS] attempted summary of next-peer issue (was: RE: next peer issue in rsvp-sec) Thread-Index: AcKaXZF8+L9WgMYuTiyDSHiNapkCMwATdWAg To: X-OriginalArrivalTime: 03 Dec 2002 09:10:30.0682 (UTC) FILETIME=[D40297A0:01C29AAB] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gB39Alv23954 Subject: [NSIS] Interim Meeting 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: 8bit Hi all, I propose the week of February 10th - 14th for the NSIS interim meeting. We have one offer to host the meeting at Columbia University. Allison Mankin has also said that she may be able to host the meeting in New Jersey. Please let me know if this is acceptable to those interested in participating. I would like to spend the bulk of the time working on an initial cut of a solution. Another suggest topic, that could be held towards the end of the meeting would be interactions with mobility. thanks, John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Dec 3 04:39:37 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12775 for ; Tue, 3 Dec 2002 04:39:37 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB39g8W25956 for nsis-archive@odin.ietf.org; Tue, 3 Dec 2002 04:42:08 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB39g6v25949; Tue, 3 Dec 2002 04:42:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB39fKv25925 for ; Tue, 3 Dec 2002 04:41:20 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12734 for ; Tue, 3 Dec 2002 04:38:18 -0500 (EST) Received: from esealnt611.al.sw.ericsson.se (esealnt611.al.sw.ericsson.se [153.88.254.68]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id gB39f7KV006614; Tue, 3 Dec 2002 10:41:07 +0100 (MET) Received: from ESEALNT747.al.sw.ericsson.se ([153.88.251.7]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id YBCYT0FM; Tue, 3 Dec 2002 10:41:07 +0100 Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Tue, 3 Dec 2002 10:41:06 +0100 Message-ID: <2B06CD3FC17AF64587BC7A7617B230C0CBB7BC@enleent103.nl.eu.ericsson.se> X-Sybari-Trust: 34cd4502 ca231590 3510fc58 00000138 From: "Georgios Karagiannis (ELN)" To: "'john.loughney@nokia.com'" , "'Jukka MJ Manner'" Cc: nsis@ietf.org Subject: RE: [NSIS] NSIS Analysis Date: Tue, 3 Dec 2002 10:38:22 +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 and Jukka During the meeting of Atlanta I promised to provide input on the definition of scalability in terms of number of states and some input on the RMD (Resource Management in Diffserv) framework. I will try to finalize this before Friday! Is it Okay? -----Original Message----- From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] Sent: dinsdag 3 december 2002 10:07 To: nsis@ietf.org Subject: [NSIS] NSIS Analysis Hi all, Jukka Manner has editted an analysis doc: http://www.ietf.org/internet-drafts/draft-ietf-nsis-signalling-analysis-00.txt We need to capture some additional material for this document and then see how much more work is needed. In Atlanta, there were a number of voices suggesting that some basic functionality is not broken, so does not need to be changed. If there are folks looking new and novel ways to perform signaling that is not in keeping with the RSVP model, then they must provide some analysis why what RSVP is doing, is broken. Otherwise, we will start with some basic assumptions for the NSIS protocol from RSVP. I don't think that basing some mechanisms on RSVP is a bad thing, that is why there needs to be documented reasons if we choose to do something else. 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 mailnull@www1.ietf.org Tue Dec 3 04:41:35 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12866 for ; Tue, 3 Dec 2002 04:41:35 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB39i6226067 for nsis-archive@odin.ietf.org; Tue, 3 Dec 2002 04:44:06 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB39i2v26053; Tue, 3 Dec 2002 04:44:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB39hJv26012 for ; Tue, 3 Dec 2002 04:43:19 -0500 Received: from mgw-x1.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12801 for ; Tue, 3 Dec 2002 04:40:16 -0500 (EST) From: john.loughney@nokia.com Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gB39gSG02678 for ; Tue, 3 Dec 2002 11:42:28 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 3 Dec 2002 11:43:04 +0200 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 3 Dec 2002 11:43:04 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe013.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 3 Dec 2002 11:43:03 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] NSIS Analysis Date: Tue, 3 Dec 2002 11:43:03 +0200 Message-ID: Thread-Topic: [NSIS] NSIS Analysis Thread-Index: AcKasB8nGLoJC+0sQLKRQrBhtQKBAwAABzsQ To: , Cc: X-OriginalArrivalTime: 03 Dec 2002 09:43:04.0011 (UTC) FILETIME=[6048F1B0:01C29AB0] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gB39hJv26013 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: 8bit Hi Georgios, > During the meeting of Atlanta I promised to provide > input on the definition of scalability in terms of number of states > and some input on the RMD (Resource Management in Diffserv) framework. > > I will try to finalize this before Friday! > > Is it Okay? Please send some suggested text to the list and we can see what the WG thinks. thanks, John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Dec 3 04:43:34 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12951 for ; Tue, 3 Dec 2002 04:43:34 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB39k5A26310 for nsis-archive@odin.ietf.org; Tue, 3 Dec 2002 04:46:05 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB39k3v26291; Tue, 3 Dec 2002 04:46:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB39j7v26239 for ; Tue, 3 Dec 2002 04:45:07 -0500 Received: from mgw-x1.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12903 for ; Tue, 3 Dec 2002 04:42:04 -0500 (EST) From: john.loughney@nokia.com Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gB39iGG03970 for ; Tue, 3 Dec 2002 11:44:16 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 3 Dec 2002 11:44:53 +0200 Received: from esebe003.NOE.Nokia.com ([172.21.138.39]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 3 Dec 2002 11:44:53 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 3 Dec 2002 11:44:53 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] attempted summary of next-peer issue (was: RE: next peer issue in rsvp-sec) Date: Tue, 3 Dec 2002 11:44:51 +0200 Message-ID: Thread-Topic: [NSIS] attempted summary of next-peer issue (was: RE: next peer issue in rsvp-sec) Thread-Index: AcKaXZF8+L9WgMYuTiyDSHiNapkCMwAUvWOA To: , Cc: X-OriginalArrivalTime: 03 Dec 2002 09:44:53.0216 (UTC) FILETIME=[A1604E00:01C29AB0] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gB39j7v26240 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: 8bit Hi Mike, > I think this probably just points out a previously > un(der)solved problem: if the next peer isn't > directly adjacent how do you know which one it > will be? Solving for this first makes the keying > problem tractable, I'd think. The question is what > scale you need to solve for. The current solution > of pre-shared keys and manually set up SA's is > not very attractive as the mesh gets larger. Agreed. > Also: one thing that Steve's draft should *really* > drive home as hard as possible with the clue-by-four > is that Key Management is an extremely large pain > in the patochkie. Non-security working groups should > be extremely fearful of recreating them. As in, if > at all possible beg, borrow or steal even if it makes > for some warts; do not assume you're smarter > than security geeks on this front. Most definately agreed. We should work on the signaling and not work on making key distribution mechanisms. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Dec 3 05:07:56 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13473 for ; Tue, 3 Dec 2002 05:07:56 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB3AAEp27702 for nsis-archive@odin.ietf.org; Tue, 3 Dec 2002 05:10:14 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB3AACv27695; Tue, 3 Dec 2002 05:10:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB3A9Kv27643 for ; Tue, 3 Dec 2002 05:09:20 -0500 Received: from porsta.cs.Helsinki.FI (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13451 for ; Tue, 3 Dec 2002 05:06:31 -0500 (EST) Received: from melkinpaasi.cs.Helsinki.FI (IDENT:jmanner@melkinpaasi.cs.Helsinki.FI [128.214.10.13]) by porsta.cs.Helsinki.FI (8.11.6/8.11.6) with ESMTP id gB3A9Ha14919 for ; Tue, 3 Dec 2002 12:09:19 +0200 Date: Tue, 3 Dec 2002 12:09:16 +0200 (EET) From: Jukka MJ Manner To: nsis@ietf.org Subject: Re: [NSIS] NSIS Analysis In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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, For the next "01" version of the document, I propose the following editorial/conceptual changes: - Divide the document into 1) pure signalling protocols, like RSVP, INSIGNIA and YESSIR 2) larger architectural frameworks with some signalling mechanisms, eg. currently ITSUMO - Keep the main focus on the signalling protocols: Part 1 would be around 80% of the text, part 2 the rest 20% - Any _architecture_ review must be kept short, just to point out original new ideas that might benefit our work. Thus, I am open for input from people regarding analysis of different sig. prots and architectures. Send your suggestions for text to the list and I will take the text once the WG has had time to comment on it - please don't send me text outside the list. Any additional text or changes to current text are more than welcome. Also, me and Xiaoming don't intend to do a thorough review of all protocols ourselves, so please contribute text to the existing analysis. Regards, Jukka On Tue, 3 Dec 2002 john.loughney@nokia.com wrote: > Hi all, > > Jukka Manner has editted an analysis doc: > > http://www.ietf.org/internet-drafts/draft-ietf-nsis-signalling-analysis-00.txt > > We need to capture some additional material for this document and then > see how much more work is needed. > > In Atlanta, there were a number of voices suggesting that some basic > functionality is not broken, so does not need to be changed. If there > are folks looking new and novel ways to perform signaling that is not in > keeping with the RSVP model, then they must provide some analysis why > what RSVP is doing, is broken. Otherwise, we will start with some basic > assumptions for the NSIS protocol from RSVP. I don't think that basing > some mechanisms on RSVP is a bad thing, that is why there needs to be > documented reasons if we choose to do something else. > > 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 mailnull@www1.ietf.org Tue Dec 3 05:52:56 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14242 for ; Tue, 3 Dec 2002 05:52:56 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB3AtFq30221 for nsis-archive@odin.ietf.org; Tue, 3 Dec 2002 05:55:15 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB3At9v30211; Tue, 3 Dec 2002 05:55:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB3Asbv30170 for ; Tue, 3 Dec 2002 05:54:37 -0500 Received: from rsys002a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14231 for ; Tue, 3 Dec 2002 05:51:46 -0500 (EST) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Tue, 3 Dec 2002 10:54:33 -0000 Message-ID: <76C92FBBFB58D411AE760090271ED4181EA6DD@rsys002a.roke.co.uk> From: "Hancock, Robert" To: "'Jukka MJ Manner'" Cc: nsis@ietf.org Subject: RE: [NSIS] NSIS Analysis Date: Tue, 3 Dec 2002 10:54:33 -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: , jukka, all, i still find myself slightly confused about what the end result of this analysis is going to be, and how it might/might not lead in to other activities. i restrict myself to rsvp for some example questions: *) are we going to say 'this is what rsvp is'? (impractical, i think there are about 600 pages of related standards track RFCs to consider. however, the introduction seems to imply this.) *) are we just going to say 'this is what we don't like about rsvp'? (unfair, provocative?) *) are we going to say 'we don't like this but fundamentally it comes with the territory'? (i.e. analyse the signalling problem in general as well as specific protocols) *) are we going to say 'this is what we do like and there's no need to change' (i guess it's easy to say yes to that one) *) are we going to say 'this can be changed and here is the reasoning about the way to change it' (or is that straying into next stages?) clarification welcome. as an example, i'd like to capture some thinking about the signalling/data path divergence issues and also sender/receiver issues, which [to be useful] would cover all the above questions. but i'm not clear how much would come under the heading 'analysis'. cheers, robert h. > -----Original Message----- > From: Jukka MJ Manner [mailto:jmanner@cs.helsinki.fi] > Sent: 03 December 2002 10:09 > To: nsis@ietf.org > Subject: Re: [NSIS] NSIS Analysis > > > > Hi all, > > For the next "01" version of the document, I propose the following > editorial/conceptual changes: > > - Divide the document into > 1) pure signalling protocols, like RSVP, INSIGNIA and YESSIR > 2) larger architectural frameworks with some signalling > mechanisms, eg. currently ITSUMO > > - Keep the main focus on the signalling protocols: Part 1 > would be around > 80% of the text, part 2 the rest 20% > > - Any _architecture_ review must be kept short, just to point > out original > new ideas that might benefit our work. > > > Thus, I am open for input from people regarding analysis of different > sig. prots and architectures. Send your suggestions for text > to the list > and I will take the text once the WG has had time to comment on it - > please don't send me text outside the list. > > Any additional text or changes to current text are more than welcome. > Also, me and Xiaoming don't intend to do a thorough review of all > protocols ourselves, so please contribute text to the > existing analysis. > > Regards, > > Jukka > > On Tue, 3 Dec 2002 john.loughney@nokia.com wrote: > > > Hi all, > > > > Jukka Manner has editted an analysis doc: > > > > > http://www.ietf.org/internet-drafts/draft-ietf-nsis-signalling -analysis-00.txt > > We need to capture some additional material for this document and then > see how much more work is needed. > > In Atlanta, there were a number of voices suggesting that some basic > functionality is not broken, so does not need to be changed. If there > are folks looking new and novel ways to perform signaling that is not in > keeping with the RSVP model, then they must provide some analysis why > what RSVP is doing, is broken. Otherwise, we will start with some basic > assumptions for the NSIS protocol from RSVP. I don't think that basing > some mechanisms on RSVP is a bad thing, that is why there needs to be > documented reasons if we choose to do something else. > > 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 mailnull@www1.ietf.org Tue Dec 3 06:26:56 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15073 for ; Tue, 3 Dec 2002 06:26:56 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB3BTFc32311 for nsis-archive@odin.ietf.org; Tue, 3 Dec 2002 06:29:15 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB3BTCv32304; Tue, 3 Dec 2002 06:29:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB3BSJv32269 for ; Tue, 3 Dec 2002 06:28:19 -0500 Received: from porsta.cs.Helsinki.FI (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15056 for ; Tue, 3 Dec 2002 06:25:29 -0500 (EST) Received: from melkinpaasi.cs.Helsinki.FI (IDENT:jmanner@melkinpaasi.cs.Helsinki.FI [128.214.10.13]) by porsta.cs.Helsinki.FI (8.11.6/8.11.6) with ESMTP id gB3BSHa10609 for ; Tue, 3 Dec 2002 13:28:17 +0200 Date: Tue, 3 Dec 2002 13:28:15 +0200 (EET) From: Jukka MJ Manner To: nsis@ietf.org Subject: RE: [NSIS] NSIS Analysis In-Reply-To: <76C92FBBFB58D411AE760090271ED4181EA6DD@rsys002a.roke.co.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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, below my view of the work. On Tue, 3 Dec 2002, Hancock, Robert wrote: > jukka, all, > > i still find myself slightly confused about what the end result of this > analysis is going to be, and how it might/might not lead in to other > activities. i restrict myself to rsvp for some example questions: > > *) are we going to say 'this is what rsvp is'? (impractical, i think > there are about 600 pages of related standards track RFCs to consider. > however, the introduction seems to imply this.) No, RSVP is documented elsewhere, that is why we have a very long list of references (same goes with all other protocols reviewed) - still, from an editorial pov we need to write a short overview of the basic functionality. > *) are we just going to say 'this is what we don't like about rsvp'? > (unfair, provocative?) I would say "no" here and "yes" to the following bullet. > *) are we going to say 'we don't like this but fundamentally it comes > with the territory'? (i.e. analyse the signalling problem in general as > well as specific protocols) Yes, it is part of the review, to say what is not working properly, eg. related to mobility and RSVP - it comes with the territory. > *) are we going to say 'this is what we do like and there's no need to > change' (i guess it's easy to say yes to that one) Yes. (although, see below...) > *) are we going to say 'this can be changed and here is the reasoning > about the way to change it' (or is that straying into next stages?) No, no suggestions for changes in any of the protocols (at least not in this doc). > > clarification welcome. as an example, i'd like to capture some thinking > about the signalling/data path divergence issues and also > sender/receiver issues, which [to be useful] would cover all the above > questions. but i'm not clear how much would come under the heading > 'analysis'. I wouldn't like to take sides in the document about whether sender/receiver orientation is best, or should the signalling go in/out-of-path, or (this is provocative, I know) is the mechanism scalable or not. Each protocol works in its own way and therefore what I'd like to have is a review of the functionality, the good and bad points. Naturally, this does require us to take sides on what is "good" and "bad" operation, but still I'd like to be as neutral as possible - and really not compare against the requirements doc. Regards, Jim _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Dec 3 08:54:51 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19983 for ; Tue, 3 Dec 2002 08:54:51 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB3DvCS09521 for nsis-archive@odin.ietf.org; Tue, 3 Dec 2002 08:57:12 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB3Dv9v09513; Tue, 3 Dec 2002 08:57:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB3Dugv09472 for ; Tue, 3 Dec 2002 08:56:42 -0500 Received: from mgw-x1.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19803 for ; Tue, 3 Dec 2002 08:53:49 -0500 (EST) From: john.loughney@nokia.com Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gB3Du0G11024 for ; Tue, 3 Dec 2002 15:56:00 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 3 Dec 2002 15:56:37 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 3 Dec 2002 15:56:37 +0200 Received: from esebe020.NOE.Nokia.com ([172.21.138.59]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 3 Dec 2002 15:56:36 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe020.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 3 Dec 2002 15:56:36 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] NSIS Analysis Date: Tue, 3 Dec 2002 15:56:35 +0200 Message-ID: Thread-Topic: [NSIS] NSIS Analysis Thread-Index: AcKavz49Hrc7gQdRQeKpFSIotCzBZAAFBMuQ To: , X-OriginalArrivalTime: 03 Dec 2002 13:56:36.0192 (UTC) FILETIME=[CB738E00:01C29AD3] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gB3Dugv09473 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: 8bit Hi all, > > *) are we going to say 'this is what rsvp is'? (impractical, i think > > there are about 600 pages of related standards track RFCs > to consider. > > however, the introduction seems to imply this.) > > No, RSVP is documented elsewhere, that is why we have a very long list of > references (same goes with all other protocols reviewed) - still, from an > editorial pov we need to write a short overview of the basic > functionality. Exactly. > > *) are we just going to say 'this is what we don't like about rsvp'? > > (unfair, provocative?) > > I would say "no" here and "yes" to the following bullet. This would not be the place to say this. > > *) are we going to say 'we don't like this but fundamentally it comes > > with the territory'? (i.e. analyse the signalling problem in general as > > well as specific protocols) > > Yes, it is part of the review, to say what is not working properly, eg. > related to mobility and RSVP - it comes with the territory. But if there are key conclusions to draw, then we should at least include them. > > *) are we going to say 'this is what we do like and there's no need to > > change' (i guess it's easy to say yes to that one) > > Yes. (although, see below...) Agreed. > > *) are we going to say 'this can be changed and here is the reasoning > > about the way to change it' (or is that straying into next stages?) > > No, no suggestions for changes in any of the protocols (at > least not in this doc). I think that we should outline the things that SHOULD be changed. For example, issues of Multicast could be handled here. Mobility is another issue - I think we still need to figure out if Michael Thomas' draft should be a standalone draft or included with this work. > I wouldn't like to take sides in the document about whether > sender/receiver orientation is best, or should the signalling go > in/out-of-path, or (this is provocative, I know) is the mechanism scalable > or not. Each protocol works in its own way and therefore what I'd like to > have is a review of the functionality, the good and bad points. Perhaps we could have some text on this though. > Naturally, this does require us to take sides on what is "good" and "bad" > operation, but still I'd like to be as neutral as possible - and really > not compare against the requirements doc. Exactly. However, we could say that if you do x, then y comes along with x. JOhn _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Dec 3 10:28:06 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26150 for ; Tue, 3 Dec 2002 10:28:06 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB3FUS117648 for nsis-archive@odin.ietf.org; Tue, 3 Dec 2002 10:30:28 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB3FUQv17635; Tue, 3 Dec 2002 10:30:26 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB3FTrv17556 for ; Tue, 3 Dec 2002 10:29:53 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26095 for ; Tue, 3 Dec 2002 10:26:59 -0500 (EST) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id gB3FTnKV028655; Tue, 3 Dec 2002 16:29:49 +0100 (MET) Received: from ESEALNT747.al.sw.ericsson.se ([153.88.251.7]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id YBCNZM59; Tue, 3 Dec 2002 16:29:49 +0100 Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Tue, 3 Dec 2002 16:29:48 +0100 Message-ID: <2B06CD3FC17AF64587BC7A7617B230C0CBB7C4@enleent103.nl.eu.ericsson.se> X-Sybari-Trust: e3f44ee8 ca231590 3510fc58 00000138 From: "Georgios Karagiannis (ELN)" To: "'john.loughney@nokia.com'" , jmanner@cs.helsinki.fi, nsis@ietf.org Date: Tue, 3 Dec 2002 16:29:47 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [NSIS] What is the goal of 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: , Hi In my opinion, the analysis draft should emphasize the significant positive features but also the main drawbacks of RSVP. Based on the results of this analysis we could then use the good things of RSVP and avoid the drawbacks of RSVP during the specification of our "NSIS" transport protocol (NTLP). Otherwise, I do not see the reason of spending time on an analysis draft that will not have any value! Furthermore, I propose that the analysis draft should concentrate only on the analysis of the RSVP protocol. I do not see the point of explaining and analyzing other protocols than RSVP. We could actually investigate if a simplified version of RSVP could satisfy the requirements of the NTLP. Best Regards, Georgios _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Dec 3 10:32:45 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26570 for ; Tue, 3 Dec 2002 10:32:45 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB3FZ7U18136 for nsis-archive@odin.ietf.org; Tue, 3 Dec 2002 10:35:07 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB3FZ4v18126; Tue, 3 Dec 2002 10:35:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB3FYMv18057 for ; Tue, 3 Dec 2002 10:34:22 -0500 Received: from porsta.cs.Helsinki.FI (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26463 for ; Tue, 3 Dec 2002 10:31:28 -0500 (EST) Received: from melkinpaasi.cs.Helsinki.FI (IDENT:jmanner@melkinpaasi.cs.Helsinki.FI [128.214.10.13]) by porsta.cs.Helsinki.FI (8.11.6/8.11.6) with ESMTP id gB3FYHa00245 for ; Tue, 3 Dec 2002 17:34:18 +0200 Date: Tue, 3 Dec 2002 17:34:16 +0200 (EET) From: Jukka MJ Manner To: nsis@ietf.org In-Reply-To: <2B06CD3FC17AF64587BC7A7617B230C0CBB7C4@enleent103.nl.eu.ericsson.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [NSIS] Re: What is the goal of 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: , Hi, I strongly believe that looking also at other protocols than RSVP would give us more insight into our work, to learn from other efforts, too. We can well find good ideas in other protocols that can help the design of NTLP. Jukka On Tue, 3 Dec 2002, Georgios Karagiannis (ELN) wrote: > Hi > > In my opinion, the analysis draft should emphasize > the significant positive features but also the main > drawbacks of RSVP. > > Based on the results of this analysis we could then use > the good things of RSVP and avoid the drawbacks of RSVP > during the specification of our "NSIS" transport > protocol (NTLP). > > Otherwise, I do not see the reason of spending time > on an analysis draft that will not have any value! > > > Furthermore, I propose that the analysis draft should > concentrate only on the analysis of the RSVP protocol. I do not > see the point of explaining and analyzing other protocols > than RSVP. > We could actually investigate if a simplified version of RSVP could > satisfy the requirements of the NTLP. > > Best Regards, > Georgios > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Dec 3 10:39:50 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27203 for ; Tue, 3 Dec 2002 10:39:50 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB3FgDi19388 for nsis-archive@odin.ietf.org; Tue, 3 Dec 2002 10:42:13 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB3Fg9v19352; Tue, 3 Dec 2002 10:42:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB3Ff3v19297 for ; Tue, 3 Dec 2002 10:41:03 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27081 for ; Tue, 3 Dec 2002 10:38:08 -0500 (EST) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id gB3FevQ1025157; Tue, 3 Dec 2002 16:40:57 +0100 (MET) Received: from ESEALNT746.al.sw.ericsson.se ([153.88.251.6]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id YBCNZPQD; Tue, 3 Dec 2002 16:40:57 +0100 Received: by ESEALNT746.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Tue, 3 Dec 2002 16:40:57 +0100 Message-ID: <2B06CD3FC17AF64587BC7A7617B230C0CBB7C5@enleent103.nl.eu.ericsson.se> X-Sybari-Trust: 245c2b2f ca231590 3510fc58 00000138 From: "Georgios Karagiannis (ELN)" To: "'Jukka MJ Manner'" , nsis@ietf.org Subject: RE: [NSIS] Re: What is the goal of the analysis draft? Date: Tue, 3 Dec 2002 16:40:56 +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 Yes, but then you will have to use fair and wise criteria on choosing protocols with efficient and right solutions. I think that the choice of which other efforts we should use should be at the moment left open! Best Regards, Georgios -----Original Message----- From: Jukka MJ Manner [mailto:jmanner@cs.helsinki.fi] Sent: dinsdag 3 december 2002 16:34 To: nsis@ietf.org Subject: [NSIS] Re: What is the goal of the analysis draft? Hi, I strongly believe that looking also at other protocols than RSVP would give us more insight into our work, to learn from other efforts, too. We can well find good ideas in other protocols that can help the design of NTLP. Jukka On Tue, 3 Dec 2002, Georgios Karagiannis (ELN) wrote: > Hi > > In my opinion, the analysis draft should emphasize > the significant positive features but also the main > drawbacks of RSVP. > > Based on the results of this analysis we could then use > the good things of RSVP and avoid the drawbacks of RSVP > during the specification of our "NSIS" transport > protocol (NTLP). > > Otherwise, I do not see the reason of spending time > on an analysis draft that will not have any value! > > > Furthermore, I propose that the analysis draft should > concentrate only on the analysis of the RSVP protocol. I do not > see the point of explaining and analyzing other protocols > than RSVP. > We could actually investigate if a simplified version of RSVP could > satisfy the requirements of the NTLP. > > Best Regards, > Georgios > _______________________________________________ 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 mailnull@www1.ietf.org Tue Dec 3 10:41:45 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27365 for ; Tue, 3 Dec 2002 10:41:45 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB3Fi8Q19528 for nsis-archive@odin.ietf.org; Tue, 3 Dec 2002 10:44:08 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB3Fi4v19519; Tue, 3 Dec 2002 10:44:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB3Fhqv19499 for ; Tue, 3 Dec 2002 10:43:52 -0500 Received: from porsta.cs.Helsinki.FI (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27295 for ; Tue, 3 Dec 2002 10:40:58 -0500 (EST) Received: from melkinpaasi.cs.Helsinki.FI (IDENT:jmanner@melkinpaasi.cs.Helsinki.FI [128.214.10.13]) by porsta.cs.Helsinki.FI (8.11.6/8.11.6) with ESMTP id gB3Fhka02745 for ; Tue, 3 Dec 2002 17:43:48 +0200 Date: Tue, 3 Dec 2002 17:43:45 +0200 (EET) From: Jukka MJ Manner To: nsis@ietf.org Subject: RE: [NSIS] Re: What is the goal of the analysis draft? In-Reply-To: <2B06CD3FC17AF64587BC7A7617B230C0CBB7C5@enleent103.nl.eu.ericsson.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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: , My point is that we are not choosing anything in this document. It would be used as a reference of existing work (design decisions people have done) when designing ourselves the NTLP or RSVPv2 or whatever that is. The evaluation parts of the document need to be agreed on the list, of course. Jim On Tue, 3 Dec 2002, Georgios Karagiannis (ELN) wrote: > Hi > > Yes, but then you will have to use fair and wise > criteria on choosing protocols with efficient > and right solutions. > > I think that the choice of which other efforts we should > use should be at the moment left open! > > Best Regards, > Georgios > > > > -----Original Message----- > From: Jukka MJ Manner [mailto:jmanner@cs.helsinki.fi] > Sent: dinsdag 3 december 2002 16:34 > To: nsis@ietf.org > Subject: [NSIS] Re: What is the goal of the analysis draft? > > > > Hi, > > I strongly believe that looking also at other protocols than RSVP would > give us more insight into our work, to learn from other efforts, too. We > can well find good ideas in other protocols that can help the design of > NTLP. > > Jukka > > On Tue, 3 Dec 2002, Georgios Karagiannis (ELN) wrote: > > > Hi > > > > In my opinion, the analysis draft should emphasize > > the significant positive features but also the main > > drawbacks of RSVP. > > > > Based on the results of this analysis we could then use > > the good things of RSVP and avoid the drawbacks of RSVP > > during the specification of our "NSIS" transport > > protocol (NTLP). > > > > Otherwise, I do not see the reason of spending time > > on an analysis draft that will not have any value! > > > > > > Furthermore, I propose that the analysis draft should > > concentrate only on the analysis of the RSVP protocol. I do not > > see the point of explaining and analyzing other protocols > > than RSVP. > > We could actually investigate if a simplified version of RSVP could > > satisfy the requirements of the NTLP. > > > > Best Regards, > > Georgios > > > > _______________________________________________ > 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 mailnull@www1.ietf.org Tue Dec 3 10:49:47 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27905 for ; Tue, 3 Dec 2002 10:49:47 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB3Fq9120011 for nsis-archive@odin.ietf.org; Tue, 3 Dec 2002 10:52:09 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB3Fq6v19992; Tue, 3 Dec 2002 10:52:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB3FpDv19940 for ; Tue, 3 Dec 2002 10:51:13 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27784 for ; Tue, 3 Dec 2002 10:48:19 -0500 (EST) Received: from esealnt613.al.sw.ericsson.se (esealnt613.al.sw.ericsson.se [153.88.254.72]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id gB3Fp9KV004491; Tue, 3 Dec 2002 16:51:09 +0100 (MET) Received: from ESEALNT747.al.sw.ericsson.se ([153.88.251.7]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id YCDYZ0QT; Tue, 3 Dec 2002 16:51:09 +0100 Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Tue, 3 Dec 2002 16:51:08 +0100 Message-ID: <2B06CD3FC17AF64587BC7A7617B230C0CBB7C6@enleent103.nl.eu.ericsson.se> X-Sybari-Trust: 0f558585 ca231590 3510fc58 00000138 From: "Georgios Karagiannis (ELN)" To: "'Jukka MJ Manner'" , "'nsis@ietf.org'" Subject: RE: [NSIS] Re: What is the goal of the analysis draft? Date: Tue, 3 Dec 2002 16:51:07 +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 We could always use experience from other (than RSVP) existing work, even if it is not listed (referenced) in the analysis draft! Just focus and analyze the positive features and the main drawbacks of RSVP, since this is one of the main goals of the updated NSIS WG charter! We should not be interested at the moment on other protocols. Best regards, Georgios -----Original Message----- From: Jukka MJ Manner [mailto:jmanner@cs.helsinki.fi] Sent: dinsdag 3 december 2002 16:44 To: nsis@ietf.org Subject: RE: [NSIS] Re: What is the goal of the analysis draft? My point is that we are not choosing anything in this document. It would be used as a reference of existing work (design decisions people have done) when designing ourselves the NTLP or RSVPv2 or whatever that is. The evaluation parts of the document need to be agreed on the list, of course. Jim On Tue, 3 Dec 2002, Georgios Karagiannis (ELN) wrote: > Hi > > Yes, but then you will have to use fair and wise > criteria on choosing protocols with efficient > and right solutions. > > I think that the choice of which other efforts we should > use should be at the moment left open! > > Best Regards, > Georgios > > > > -----Original Message----- > From: Jukka MJ Manner [mailto:jmanner@cs.helsinki.fi] > Sent: dinsdag 3 december 2002 16:34 > To: nsis@ietf.org > Subject: [NSIS] Re: What is the goal of the analysis draft? > > > > Hi, > > I strongly believe that looking also at other protocols than RSVP would > give us more insight into our work, to learn from other efforts, too. We > can well find good ideas in other protocols that can help the design of > NTLP. > > Jukka > > On Tue, 3 Dec 2002, Georgios Karagiannis (ELN) wrote: > > > Hi > > > > In my opinion, the analysis draft should emphasize > > the significant positive features but also the main > > drawbacks of RSVP. > > > > Based on the results of this analysis we could then use > > the good things of RSVP and avoid the drawbacks of RSVP > > during the specification of our "NSIS" transport > > protocol (NTLP). > > > > Otherwise, I do not see the reason of spending time > > on an analysis draft that will not have any value! > > > > > > Furthermore, I propose that the analysis draft should > > concentrate only on the analysis of the RSVP protocol. I do not > > see the point of explaining and analyzing other protocols > > than RSVP. > > We could actually investigate if a simplified version of RSVP could > > satisfy the requirements of the NTLP. > > > > Best Regards, > > Georgios > > > > _______________________________________________ > 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 mailnull@www1.ietf.org Tue Dec 3 11:11:51 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29789 for ; Tue, 3 Dec 2002 11:11:51 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB3GECj22272 for nsis-archive@odin.ietf.org; Tue, 3 Dec 2002 11:14:12 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB3GE7v22261; Tue, 3 Dec 2002 11:14:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB3GDiv22229 for ; Tue, 3 Dec 2002 11:13:44 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29738 for ; Tue, 3 Dec 2002 11:10:51 -0500 (EST) From: john.loughney@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gB3GElW23314 for ; Tue, 3 Dec 2002 18:14:47 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 3 Dec 2002 18:13:38 +0200 Received: from esebe002.NOE.Nokia.com ([172.21.138.17]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 3 Dec 2002 18:13:37 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 3 Dec 2002 18:13:37 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] Re: What is the goal of the analysis draft? Date: Tue, 3 Dec 2002 18:13:36 +0200 Message-ID: Thread-Topic: [NSIS] Re: What is the goal of the analysis draft? Thread-Index: AcKa5HvaQ9qOG9qrRoe0qRv5rPnVugAAlNBA To: , , X-OriginalArrivalTime: 03 Dec 2002 16:13:37.0170 (UTC) FILETIME=[EF893F20:01C29AE6] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gB3GDiv22230 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: 8bit Hi All, The point of looking at other protocols is not to promote other protocols over RSVP in NSIS, but rather to see what signaling protocols do well and what they do not do well. If we can apply any of the lessons learned to the new work, then we are ahead of the curve. John > -----Original Message----- > From: ext Georgios Karagiannis (ELN) > [mailto:Georgios.Karagiannis@eln.ericsson.se] > Sent: 03 December, 2002 17:51 > To: 'Jukka MJ Manner'; 'nsis@ietf.org' > Subject: RE: [NSIS] Re: What is the goal of the analysis draft? > > > Hi > > We could always use experience from other (than RSVP) > existing work, even if it is not listed (referenced) in the > analysis draft! > Just focus and analyze the positive features and the > main drawbacks of RSVP, since this is one of the main > goals of the updated NSIS WG charter! > > We should not be interested at the moment on other protocols. > > Best regards, > Georgios > > > -----Original Message----- > From: Jukka MJ Manner [mailto:jmanner@cs.helsinki.fi] > Sent: dinsdag 3 december 2002 16:44 > To: nsis@ietf.org > Subject: RE: [NSIS] Re: What is the goal of the analysis draft? > > > > My point is that we are not choosing anything in this > document. It would > be used as a reference of existing work (design decisions people have > done) when designing ourselves the NTLP or RSVPv2 or whatever that is. > > The evaluation parts of the document need to be agreed on the > list, of > course. > > Jim > > On Tue, 3 Dec 2002, Georgios Karagiannis (ELN) wrote: > > > Hi > > > > Yes, but then you will have to use fair and wise > > criteria on choosing protocols with efficient > > and right solutions. > > > > I think that the choice of which other efforts we should > > use should be at the moment left open! > > > > Best Regards, > > Georgios > > > > > > > > -----Original Message----- > > From: Jukka MJ Manner [mailto:jmanner@cs.helsinki.fi] > > Sent: dinsdag 3 december 2002 16:34 > > To: nsis@ietf.org > > Subject: [NSIS] Re: What is the goal of the analysis draft? > > > > > > > > Hi, > > > > I strongly believe that looking also at other protocols > than RSVP would > > give us more insight into our work, to learn from other > efforts, too. We > > can well find good ideas in other protocols that can help > the design of > > NTLP. > > > > Jukka > > > > On Tue, 3 Dec 2002, Georgios Karagiannis (ELN) wrote: > > > > > Hi > > > > > > In my opinion, the analysis draft should emphasize > > > the significant positive features but also the main > > > drawbacks of RSVP. > > > > > > Based on the results of this analysis we could then use > > > the good things of RSVP and avoid the drawbacks of RSVP > > > during the specification of our "NSIS" transport > > > protocol (NTLP). > > > > > > Otherwise, I do not see the reason of spending time > > > on an analysis draft that will not have any value! > > > > > > > > > Furthermore, I propose that the analysis draft should > > > concentrate only on the analysis of the RSVP protocol. I do not > > > see the point of explaining and analyzing other protocols > > > than RSVP. > > > We could actually investigate if a simplified version of > RSVP could > > > satisfy the requirements of the NTLP. > > > > > > Best Regards, > > > Georgios > > > > > > > _______________________________________________ > > 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 mailnull@www1.ietf.org Tue Dec 3 11:34:10 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01315 for ; Tue, 3 Dec 2002 11:34:10 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB3GaVT23955 for nsis-archive@odin.ietf.org; Tue, 3 Dec 2002 11:36:31 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB3GaRv23946; Tue, 3 Dec 2002 11:36:27 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB3GZvv23847 for ; Tue, 3 Dec 2002 11:35:57 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01220 for ; Tue, 3 Dec 2002 11:33:04 -0500 (EST) From: john.loughney@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gB3Gb0W06225 for ; Tue, 3 Dec 2002 18:37:00 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 3 Dec 2002 18:35:51 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 3 Dec 2002 18:35:51 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 3 Dec 2002 18:35:51 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Tue, 3 Dec 2002 18:35:50 +0200 Message-ID: Thread-Topic: What is the goal of the analysis draft? Thread-Index: AcKa4NZ1SRcmd4n8RNe2bve/2p8lyQACR29w To: , , X-OriginalArrivalTime: 03 Dec 2002 16:35:51.0411 (UTC) FILETIME=[0ACE4430:01C29AEA] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gB3GZvv23848 Subject: [NSIS] RE: What is the goal of 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: 8bit Hi all, Rather than debating this in some abstract, existential sense, please comment directly on the draft. If text is needed, please suggest. thanks, John > -----Original Message----- > From: ext Georgios Karagiannis (ELN) > [mailto:Georgios.Karagiannis@eln.ericsson.se] > Sent: 03 December, 2002 17:30 > To: Loughney John (NRC/Helsinki); jmanner@cs.helsinki.fi; > nsis@ietf.org > Subject: What is the goal of the analysis draft? > > > Hi > > In my opinion, the analysis draft should emphasize > the significant positive features but also the main > drawbacks of RSVP. > > Based on the results of this analysis we could then use > the good things of RSVP and avoid the drawbacks of RSVP > during the specification of our "NSIS" transport > protocol (NTLP). > > Otherwise, I do not see the reason of spending time > on an analysis draft that will not have any value! > > > Furthermore, I propose that the analysis draft should > concentrate only on the analysis of the RSVP protocol. I do not > see the point of explaining and analyzing other protocols > than RSVP. > We could actually investigate if a simplified version of RSVP could > satisfy the requirements of the NTLP. > > Best Regards, > Georgios > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Dec 3 12:36:56 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05275 for ; Tue, 3 Dec 2002 12:36:56 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB3HdIw30630 for nsis-archive@odin.ietf.org; Tue, 3 Dec 2002 12:39:18 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB3HdFv30625; Tue, 3 Dec 2002 12:39:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB3HcKv30537 for ; Tue, 3 Dec 2002 12:38:20 -0500 Received: from sj-msg-core-3.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05114 for ; Tue, 3 Dec 2002 12:35:27 -0500 (EST) Received: from mira-sjc5-7.cisco.com (IDENT:mirapoint@mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id gB3Hbe0J016601; Tue, 3 Dec 2002 09:37:40 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAT55616; Tue, 3 Dec 2002 09:31:08 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA20153; Tue, 3 Dec 2002 09:37:57 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15852.60405.402592.830518@thomasm-u1.cisco.com> Date: Tue, 3 Dec 2002 09:37:57 -0800 (PST) To: john.loughney@nokia.com Cc: , Subject: RE: [NSIS] NSIS Analysis In-Reply-To: References: X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! 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 john.loughney@nokia.com writes: > > > *) are we going to say 'this can be changed and here is the reasoning > > > about the way to change it' (or is that straying into next stages?) > > > > No, no suggestions for changes in any of the protocols (at > > least not in this doc). > > I think that we should outline the things that SHOULD be changed. For > example, issues of Multicast could be handled here. > > Mobility is another issue - I think we still need to figure out if > Michael Thomas' draft should be a standalone draft or included with > this work. That's my question too.. when I wrote my draft originally, it was mainly to show that as currently instantiated RSVP had some issues with mobility and interdomain policy. It was aimed mostly as a "heads up" kind of draft to illustrate what was still left unanswered with the current crop of RSVP RFC's. I really didn't have any intention one way or the other about publishing it permanently, etc as it was mainly intended to give some fodder to instigate work to find solutions. It's not entirely clear to me how that fits in with this wg too. Having some background is still useful, I think, but it might make more sense to do it in terms of a more terse problem statement which feeds into requirements which then allows us to have a guide for ultimate protocol selection. As a corollary, I think until we figure this all out, it's probably premature to last call the requirements. Mike _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Dec 3 14:55:12 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13443 for ; Tue, 3 Dec 2002 14:55:12 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB3Jva909573 for nsis-archive@odin.ietf.org; Tue, 3 Dec 2002 14:57:36 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB3JvVv09566; Tue, 3 Dec 2002 14:57:31 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB3JuQv09499 for ; Tue, 3 Dec 2002 14:56:26 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13390 for ; Tue, 3 Dec 2002 14:53:30 -0500 (EST) From: john.loughney@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gB3JvRW03515 for ; Tue, 3 Dec 2002 21:57:27 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Tue, 3 Dec 2002 21:56:18 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 3 Dec 2002 21:56:17 +0200 Received: from esebe014.NOE.Nokia.com ([172.21.138.53]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 3 Dec 2002 21:56:17 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe014.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 3 Dec 2002 21:56:17 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Tue, 3 Dec 2002 21:56:17 +0200 Message-ID: Thread-Topic: What is the goal of the analysis draft? Thread-Index: AcKa4NZ1SRcmd4n8RNe2bve/2p8lyQACR29wAAbzveA= To: X-OriginalArrivalTime: 03 Dec 2002 19:56:17.0661 (UTC) FILETIME=[0B0262D0:01C29B06] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gB3JuQv09500 Subject: [NSIS] IETF 55 Meeting Minutes 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: 8bit Hi all, Here is the first version of the minutes from IETF 55. I still need to do a good proof-read. Comments welcome. Thanks, John The NSIS working group met twice at IETF 55 NSIS Tuesday, November 19, 1300-1400 Afternoon Session I ================================================= WG Status, charter discussion - chair http://www-nrc.nokia.com/sua/nsis/ietf55/charter.txt The chair went over the main highlights of the charter. IP signaling protocol with QoS as first use case is the main goal, focusing on a two-layer signaling approach. Existing work will be completed. Developing transport layer signaling for transport of upper layer signaling with an initial application layer will be optimized RSVP. A potential for a second layer will be in consultation with ADs (to ensure the solution developed is not QoS specific. Comments were raised regarding the justification for the design of a new protocol. It was noted that even though there may be specific problems with RSVP the work does not seem to depend on the analysis. Scoping problems regarding the previous charter were noted. It was asked whether Transport Signaling Layer referred to OSI layer 4. It was explained that this was not the case and that there was a precedent for using the term transport, such as TLS. Security is not an explicit goal and the intention is to reuse existing securi! ty mechanisms. The applicability of current framework is kept. It was mentioned that it is a non-goal to define what QoS is. Cross-realm policy needs to be solved. Authentication and Authorization requirements for application layer are going to be different from transport layer. They should be considered on a case-by-case basis. A comment was made that a reliable solution for NAT/firewall traversal is needed. The area director pointed out that NSIS may need to work on SIP change for RSVP. Pulling in loose ends from SIP. Needs to be made coherent. Next steps are to take charter to list, review by IESG afterwards. Like to get feedback. Terminology Discussion - Robert Hancock - (10 min) http://www-nrc.nokia.com/sua/nsis/ietf55/NSIS-Terminology-Issues.ppt Robert Hancock clarified that the goal of the contribution is to provide unambiguous, unsurprising terms that can usefully describe the NSIS problem space. Non-traditional routing was discussing. Conclusion was that 'Policy forwarding' seems to be the consensus. Path-(de)coupled was discussed and decided to be used. A name for the thing signaling is requesting or installing. Proposals included 'reservation', 'RMF'. Conclusion was that this needs discussion on the mailing list. Working Group and protocol names such as NTLP/NSLP. It was stated that these are not proposed names for protocols but anything using 'NSIS' is placeholder until we begin the protocol. It was decided to use 'peer' not neighbor. Should always use discovery qualified as 'peer discovery', 'topology discovery', 'path discovery.' Sender/receiver initiation/orientation needs further discussion on the mailing list. Requirements - Marcus Brunner http://www.ietf.org/internet-drafts/draft-ietf-nsis-req-05.txt http://www-nrc.nokia.com/sua/nsis/ietf55/IETF55_Req.ppt Marcus discussed changes from version 04, such as trying to get rid of QoS unless used as example. Five major open issues remain. Two requirements for local information exchange, 5.3.5 separate messages & 5.4.2 information piggybacking. The proposal is to keep both but clarify the text. It felt that things that are state-related should have independent identifier. Replay protection was agreed as a MUST requirement. Confidentiality of signaling issues was discussed, with a comment that this requirement may be dependent upon which layer is being discussed. WEDNESDAY, November 20, 2002 0900-1130 Morning Session ================================================= Next Steps in Signaling: Framework - Robert Hancock http://www.ietf.org/internet-drafts/draft-ietf-nsis-fw-00.txt http://www-nrc.nokia.com/sua/nsis/ietf55/NSIS-framework-issues.ppt The division between NTLP and NSLP was discussed on the following points. Message types: The question is not to define any message formats here, but it is more about message sequences and message flows. Flow issues: There were slight concerns to have policy routing (forwarding) mentioned in the presentation, but it was clarified that we are not defining policy forwarding in this WG. Path management: It was asked and clarified that NTLP layer is not doing any kind of stream management. The correlation between the layers is a difficult question and reservation ID issue is addressed in another slide. Security issues: We are protecting signaling and signaling messages. Security needs to be clarified when the scope of transportation layer is clear. State management: Different views were presented on whether the state management should be taken care by NTLP layer or not. The work will continue with the issues introduced in the presentation and comments are to be sent to the mailin! g list. Trade-offs and open issues with path discovery and transport - Henning Schulzrinne http://www.ietf.org/internet-drafts/draft-schulzrinne-nsis-casp-00.txt http://www-nrc.nokia.com/sua/nsis/ietf55/55-NSIS.ppt Next hop discovery and routing functionality was questioned on this proposal. Concern was raised that features showed in the presentation are not common for all use case. At this phase it was proposed transport layer to be more general. In general next node discovery raised many concerns and questions and more discussion is needed in the list. A Two-Level Architecture for Internet Signaling - chair http://www.ietf.org/internet-drafts/draft-braden-2level-signaling-01.txt http://www-nrc.nokia.com/sua/nsis/ietf55/2level.atlanta.ppt John Loughney gave the presentation instead of the authors. It was questioned that is the soft state necessary functionality for the transport layer. It was asked how much of previous presentation as well as this presentation is covered already in the framework documents. We should discuss in this group, what parts should be covered in the framework. It was pointed out in the session that it is not appropriate way to base the architecture and framework work for some existing protocol as RSVPv1 is used now. Several points needs to be clarified in the mailing list, since the author of the draft was not at present in the session. Also some hesitation was raised against the planned re-engineering of the signaling framework. Sender and Receiver Orientation Issues in NSIS - Robert Hancock http://www.ietf.org/internet-drafts/draft-hancock-nsis-sender-receiver-00.txt http://www-nrc.Nokia.com/sua/nsis/ietf55/NSIS-Sender-Receiver-Issues.ppt The directionality is not so relevant for the transport layer, but it is more related to the reservations. Analysis of Existing Quality of Service Signaling Protocols - Jukka Manner http://www.ietf.org/internet-drafts/draft-ietf-nsis-signalling-analysis-00.txt http://www-nrc.nokia.com/sua/nsis/ietf55/analysis.pdf It was asked to send the text/information about the possible other signaling protocols to the authors of this document. Security issues are not going to be covered in this document. Robustness of different solutions was seen to be one issue to be studied in this document. Scalability was seen difficult issue to be captured in the document, but some text proposal may be sent to the mailing list on that topic. NSIS Threats - H. Tschofenig http://www.ietf.org/internet-drafts/draft-ietf-nsis-threats-00.txt http://www-nrc.nokia.com/sua/nsis/ietf55/Security-Signaling.ppt Divergent view was presented on relationship between the flow identifier and security. Security AD had big concerns with the authorization and NSIS signaling. He mentioned it is very hard to implement hop-by-hop security. Figuring the authorization is an essential challenge for this WG. The security issues for NSIS WG are similar than SIP WG has. Authorization made by hop-by-hop is probably an unsolvable problem, but we should consider authorization issue as more of an upper layer issue. RSVP Security Properties - H. Tschofenig http://www.ietf.org/internet-drafts/draft-ietf-nsis-rsvp-sec-properties-00.txt http://www-nrc.nokia.com/sua/nsis/ietf55/RSVP-Security-Properties.ppt Feedback is needed for this. It was asked that have we considered using group keys, but we haven't. In general the problems with keys and end-to-middle authentication would be good to describe in the document. Analysis of Existing QoS Solutions - G. Karagiannis http://www.ietf.org/internet-drafts/draft-demeer-nsis-analysis-03.txt http://www-nrc.nokia.com/sua/nsis/ietf55/IETF55-Analysis-karagiannis-02.ppt Authors should align the analyses together with the authors of the NSIS WG signaling document. Analysis of Mobile IP and RSVP Interactions - Mike Thomas - (10 minutes) http://www.ietf.org/internet-drafts/draft-thomas-nsis-rsvp-analysis-00.txt http://www-nrc.nokia.com/sua/nsis/ietf55/ This is two years old draft, which is now resurrected. In practice this could be a working group document or then this analyze could be captured in the NSIS analyses document including conclusions. There was not time to discuss the following drafts: A Proposal for RSVPv2 - Karagiannis http://www.ietf.org/internet-drafts/draft-westberg-proposal-for-rsvpv2-01.txt http://www-nrc.nokia.com/sua/nsis/ietf55/IETF55-RSVPv2-karagiannis-01.ppt A Firewall/NAT Traversal Client for CASP - H. Tschofenig http://www.ietf.org/internet-drafts/draft-tschofenig-nsis-casp-midcom-00.txt http://www-nrc.nokia.com/sua/nsis/ietf55/Implications-Relationships-NSIS.ppt The Use of Bi-Directional RSVP in the Wireless Internet - Kamel Shaheen http://www.ietf.org/internet-drafts/draft-Shaheen-shahrier-nsis-brsvp-00.txt http://www-nrc.nokia.com/sua/nsis/ietf55/B-RSVP.ppt Signaling Interworking for IPv6 Network - Gyu Myoung Lee http://www.ietf.org/internet-drafts/draft-choi-ipv6-signaling-interworking-00.txt http://www-nrc.nokia.com/sua/nsis/ietf55/draft-choi-ipv6-signaling-interworking-00.ppt _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Dec 3 15:01:06 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13782 for ; Tue, 3 Dec 2002 15:01:06 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB3K3UI10019 for nsis-archive@odin.ietf.org; Tue, 3 Dec 2002 15:03:30 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB3K3Lv10011; Tue, 3 Dec 2002 15:03:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB3K2xv09942 for ; Tue, 3 Dec 2002 15:02:59 -0500 Received: from mgw-x1.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13703 for ; Tue, 3 Dec 2002 15:00:03 -0500 (EST) From: john.loughney@nokia.com Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gB3K2DG26517 for ; Tue, 3 Dec 2002 22:02:13 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Tue, 3 Dec 2002 22:02:51 +0200 Received: from esebe007.NOE.Nokia.com ([172.21.138.47]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 3 Dec 2002 22:02:50 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe007.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 3 Dec 2002 22:02:36 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] IETF 55 Meeting Minutes Date: Tue, 3 Dec 2002 21:59:46 +0200 Message-ID: Thread-Topic: What is the goal of the analysis draft? Thread-Index: AcKa4NZ1SRcmd4n8RNe2bve/2p8lyQACR29wAAbzveAAACxNcA== To: X-OriginalArrivalTime: 03 Dec 2002 20:02:36.0979 (UTC) FILETIME=[ED19B830:01C29B06] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gB3K2xv09943 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: 8bit PS - thanks to Sven van den Bosch and Janne Rinne for the minutes. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Dec 3 15:26:47 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16160 for ; Tue, 3 Dec 2002 15:26:47 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB3KTC812401 for nsis-archive@odin.ietf.org; Tue, 3 Dec 2002 15:29:12 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB3KT9v12393; Tue, 3 Dec 2002 15:29:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB3KSBv12358 for ; Tue, 3 Dec 2002 15:28:11 -0500 Received: from tnt.isi.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16094 for ; Tue, 3 Dec 2002 15:25:15 -0500 (EST) Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id gB3KS4L00473; Tue, 3 Dec 2002 12:28:04 -0800 (PST) From: Bob Braden Received: (from braden@localhost) by gra.isi.edu (8.8.7/8.8.6) id UAA14453; Tue, 3 Dec 2002 20:28:04 GMT Date: Tue, 3 Dec 2002 20:28:04 GMT Message-Id: <200212032028.UAA14453@gra.isi.edu> To: john.loughney@nokia.com, nsis@ietf.org Subject: Re: [NSIS] What is the goal of the analysis draft? X-Sun-Charset: US-ASCII 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 find this discussion rather annoying and a waste of the WG's valuable time. It does not take rocket science to recognize the areas in which RSVP did it right, and which account for its very widespread use (and abuse!!!) for a variety of signaling applications, often entirely outside its design domain. Nor is it particularly hard to understand that the RSVP framework is being used for applications for which it was not particularly appropriate. Vendor communities keep defining marvelously complicated new RSVP objects which contain/conceal entirely new signaling regimes. There are currently 31 Internet Drafts with "rsvp" in the title, and some contain material that would frighten children. The result is that RSVP is ALREADY a suite of signaling protocols, perhaps 10 of them! In short, we have a horrific protocol engineering mess on our hands, and it gets worse weekly. There is far too much micro-engineering is inventing 17 ways to do the same thing, and RSVP is not a sufficient framework to bring some order to this cahos. The proper role for the NSIS has taken on the task of straightening out this mess. My first thought was that writing an analysis draft is a complete waste of time. The original base E2E signaling protocol for QoS with multicasting is a dead issue; nothing is to be gained by writing anything further about it (beyond RFC 2208). However, describing in some generality the ~10 different signaling protocols currently based on RSVP (or RSVP-TE, etc.) might be useful for helping the NSIS group to understand how to structure the space of ULSPs. It will require digging into design documents of the ATM Forum, 3GPP, the Optical Interworking Forum, and the ITU, as well as the MPLS WG of the IETF., where RSVP "extensions" have been defined. Bob Braden _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Dec 3 19:50:57 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27749 for ; Tue, 3 Dec 2002 19:50:57 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB40rN631326 for nsis-archive@odin.ietf.org; Tue, 3 Dec 2002 19:53:23 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB40rKv31318; Tue, 3 Dec 2002 19:53:20 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB40qnv31292 for ; Tue, 3 Dec 2002 19:52:49 -0500 Received: from sj-msg-core-4.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27735 for ; Tue, 3 Dec 2002 19:49:51 -0500 (EST) Received: from mira-sjc5-7.cisco.com (IDENT:mirapoint@mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id gB40qeLW012440; Tue, 3 Dec 2002 16:52:40 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAT70150; Tue, 3 Dec 2002 16:45:45 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id QAA20379; Tue, 3 Dec 2002 16:52:34 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15853.20946.720964.598278@thomasm-u1.cisco.com> Date: Tue, 3 Dec 2002 16:52:34 -0800 (PST) To: "Hancock, Robert" Cc: nsis@ietf.org Subject: [NSIS] Layer split issues In-Reply-To: <76C92FBBFB58D411AE760090271ED4181EA6C6@rsys002a.roke.co.uk> References: <76C92FBBFB58D411AE760090271ED4181EA6C6@rsys002a.roke.co.uk> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! 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 So, I'm still trying to make it back to some reasonable semblance of "caught up", and I have to say that this desire for a new decoupling of transport/application leaves me pretty quizzical as to why the current set of affairs with RSVP are so broken that we need to open Pandora's Box here. As I said in the meeting, I think that we should be pretty prejudiced toward not fixing things that aren't absolutely, positively broken. What we don't want to be facilitating here is a Second System Syndrome Crack House. RSVP already has a division of labor of sorts, re transport. What's the fatal problem here again? Mike Hancock, Robert writes: > Dear all, > > Following the NSIS session in Atlanta, I'd like to stimulate further discussion (and maybe agreement??) on some of the issues around where the NTLP/NSLP boundary should actually go. > > It seems to me there are > 1) some options on which there is some agreement > 2) some options on which there is some disagreement > 3) some options we haven't really discussed yet or at least not properly. > > This email is an attempt to summarise (1) (i.e. find out whether I have read the mood right). Separate emails will cover some of the topics under (2). > > [I think (3) includes some real headaches (e.g. mobility handling/reservation identifiers, security attributes, coupled/decoupled aspects) which can reasonably be postponed before (1) and (2) are clearer.] > > Message Types > ============= > > I think we can make a working assumption that the NTLP basically provides a capability like 'send data', without associating that data with creating a reservation, querying something, releasing resources, or whatever. The 'send data' message can go with or against the data flow, and only goes between NTLP peers. > > Is this valid? [There may be different variants of 'send data' depending on whether the NTLP can do state management stuff, I'm not prejudging that here.] > > [NB. There are potentially confusing comments within the framework about how much the NTLP and NSLP could be coupled/not properly independent layers. This is a historical overhang from when we used to think that the NTLP would have a richer message set. If the NTLP has only a very simple message set, these issues would go away.] > > Path Management > =============== > > What was discussed/not objected in the framework session was (roughly) the assertion that the NTLP processing at each NSIS entity should include getting to the next NTLP peer, and that the NTLP should detect and maybe do something about path changes ("do something" may just be "tell the NSLP it's happened".) > > Left to its own devices, the NTLP would then implicitly construct the whole path (although I would content this shouldn't be described as giving the NTLP end to end capabilities). But the NSLP at any node is free to interfere however it wants anyway. > > I like this because it puts a large number of hard but signalling application independent, transport and lower layer issues inside the NTLP where they can be solved once. But I think there may be other views as well. Arguments? > > Sender/Receiver Issues > ====================== > > The proposal (actually in an individual submission) is that, in so far as the NTLP has 'directionality': > a) it only needs the functionality to get to the next NTLP peer in the sender-->receiver direction (might be called 'sender oriented') > b) by default, it should be able to send its 'data' messages either direction, but as an optimisation, some signalling applications might only ask to send them sender-->receiver. > > However, we shouldn't make any restrictions on how (i.e. from which end) any NSLP should trigger the signalling process, request/authorise something, or whatever. In other words, NI and NR are NSLP concepts. > > I haven't heard counter-proposals, but the assumption is partly contingent on the path management assumption (so I'm asking). > > > > Is this a reasonable starting point? > > Cheers, > > Robert H. > > (Later, under (2), we get to state management and flow identification, where there are clearly interesting divergences of view.) > _______________________________________________ > 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 mailnull@www1.ietf.org Tue Dec 3 20:03:48 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28127 for ; Tue, 3 Dec 2002 20:03:48 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB416EB31796 for nsis-archive@odin.ietf.org; Tue, 3 Dec 2002 20:06:14 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB416Bv31777; Tue, 3 Dec 2002 20:06:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB4150v31719 for ; Tue, 3 Dec 2002 20:05:00 -0500 Received: from sj-msg-core-3.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28088 for ; Tue, 3 Dec 2002 20:02:03 -0500 (EST) Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id gB414X0J015993; Tue, 3 Dec 2002 17:04:33 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id ABC25886; Tue, 3 Dec 2002 17:04:50 -0800 (PST) Message-Id: <200212040104.ABC25886@mira-sjc5-c.cisco.com> To: Michael Thomas cc: "Hancock, Robert" , nsis@ietf.org From: Melinda Shore Subject: Re: [NSIS] Layer split issues In-Reply-To: Message from Michael Thomas of "Tue, 03 Dec 2002 16:52:34 PST." <15853.20946.720964.598278@thomasm-u1.cisco.com> Date: Tue, 03 Dec 2002 20:04:50 -0500 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: , > and I have to > say that this desire for a new decoupling of > transport/application leaves me pretty quizzical > as to why the current set of affairs with RSVP are > so broken that we need to open Pandora's Box here. I don't know how far out on a limb we need to go, but I do think that it's pretty clear that in RSVP, QoS in general and intserv in particular are more closely intertwined with the protocol itself than they need to be, particularly in the form of mandatory data elements. There may be stuff around the namespace if it does become a more general signaling protocol; one of the unfortunate things about Diameter, for example, is that the flatness of the namespace makes adding new applications a little unwieldy. I'd be happy, frankly, with just getting some of that stuff cleaned up, but other people have raised specific issues about a need for reliable delivery, etc., and I hope they can be more explicit about why they feel it's necessary. Melinda _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Dec 3 20:10:47 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28274 for ; Tue, 3 Dec 2002 20:10:47 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB41DDc32661 for nsis-archive@odin.ietf.org; Tue, 3 Dec 2002 20:13:13 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB41DBv32642; Tue, 3 Dec 2002 20:13:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB4199v32470 for ; Tue, 3 Dec 2002 20:09:09 -0500 Received: from sj-msg-core-4.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28176 for ; Tue, 3 Dec 2002 20:06:11 -0500 (EST) Received: from mira-sjc5-7.cisco.com (IDENT:mirapoint@mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id gB4190LW025313; Tue, 3 Dec 2002 17:09:00 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAT70591; Tue, 3 Dec 2002 17:02:11 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id RAA20382; Tue, 3 Dec 2002 17:09:00 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15853.21932.48003.689248@thomasm-u1.cisco.com> Date: Tue, 3 Dec 2002 17:09:00 -0800 (PST) To: Bob Braden Cc: john.loughney@nokia.com, nsis@ietf.org Subject: Re: [NSIS] What is the goal of the analysis draft? In-Reply-To: <200212032028.UAA14453@gra.isi.edu> References: <200212032028.UAA14453@gra.isi.edu> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! 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 Bob, Apologies for non-LotR geeks, tis the season. Elves were perverted into Orcs by Morgoth; there was very little the Elves could do about that. Likewise, I really don't think there's much we can do to stop people outside of IETF's purview from taking IETF protocols and turning them into, well, Orcs. If there are legitimate problems with RSVP with WG's outside and within IETF that can actually articulate the general problem, then we should hear it out and consider the general problem. This is as much a WG management issue as a technical issue as has been very evident with the SIP WG experience. So, I'm not entirely sure whether an endless string of analysis papers is really what's needed so much as: 1) Identifying Stovepiped Problems 2) Generalizing Them 3) Deriving Requirements The question is what is the most expeditious route to get to (3). The SIP experience says that it's not easy when there are large culture clashes. I'm all ears. Mike Bob Braden writes: > > I find this discussion rather annoying and a waste of the WG's valuable > time. It does not take rocket science to recognize the areas in which > RSVP did it right, and which account for its very widespread use (and > abuse!!!) for a variety of signaling applications, often entirely > outside its design domain. Nor is it particularly hard to understand > that the RSVP framework is being used for applications for which it was > not particularly appropriate. Vendor communities keep defining > marvelously complicated new RSVP objects which contain/conceal entirely > new signaling regimes. > > There are currently 31 Internet Drafts with "rsvp" in the title, and > some contain material that would frighten children. The result is that > RSVP is ALREADY a suite of signaling protocols, perhaps 10 of them! In > short, we have a horrific protocol engineering mess on our hands, and > it gets worse weekly. > > There is far too much micro-engineering is inventing 17 ways to do the > same thing, and RSVP is not a sufficient framework to bring some order > to this cahos. The proper role for the NSIS has taken on the task of > straightening out this mess. > > My first thought was that writing an analysis draft is a complete waste > of time. The original base E2E signaling protocol for QoS with > multicasting is a dead issue; nothing is to be gained by writing > anything further about it (beyond RFC 2208). However, describing in > some generality the ~10 different signaling protocols currently based > on RSVP (or RSVP-TE, etc.) might be useful for helping the NSIS group > to understand how to structure the space of ULSPs. It will require > digging into design documents of the ATM Forum, 3GPP, the Optical > Interworking Forum, and the ITU, as well as the MPLS WG of the IETF., > where RSVP "extensions" have been defined. > > Bob Braden > > _______________________________________________ > 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 mailnull@www1.ietf.org Tue Dec 3 23:25:00 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA02498 for ; Tue, 3 Dec 2002 23:25:00 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB44RTh09553 for nsis-archive@odin.ietf.org; Tue, 3 Dec 2002 23:27:29 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB44RRv09546; Tue, 3 Dec 2002 23:27:27 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB44Qlv09521 for ; Tue, 3 Dec 2002 23:26:47 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA02488 for ; Tue, 3 Dec 2002 23:23:47 -0500 (EST) From: john.loughney@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gB44RjW12604 for ; Wed, 4 Dec 2002 06:27:45 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 4 Dec 2002 06:26:36 +0200 Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 4 Dec 2002 06:26:36 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe016.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 4 Dec 2002 06:26:36 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] What is the goal of the analysis draft? Date: Wed, 4 Dec 2002 06:26:34 +0200 Message-ID: Thread-Topic: [NSIS] What is the goal of the analysis draft? Thread-Index: AcKbC2fg6r2MIiSRSvi6jg+dXU0/UwAQXwVg To: , X-OriginalArrivalTime: 04 Dec 2002 04:26:36.0316 (UTC) FILETIME=[55265DC0:01C29B4D] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gB44Qlv09522 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: 8bit Hi Bob, > There is far too much micro-engineering is inventing 17 ways to do the > same thing, and RSVP is not a sufficient framework to bring some order > to this cahos. The proper role for the NSIS has taken on the task of > straightening out this mess. > > My first thought was that writing an analysis draft is a complete waste > of time. The point of doing an analysis was to ensure that what RSVP done well is captured in the process of doing the NSIS work. It is a non-goal to toss everything learned from RSVP into the trash can & start over fresh. I don't envision a massive work effort in making the analysis, I'd prefer that folks read the current draft, do a sanity check & see if anything needs to be added. That being done, we can move on to bigger and better things. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Dec 3 23:26:35 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA02547 for ; Tue, 3 Dec 2002 23:26:35 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB44T4a09595 for nsis-archive@odin.ietf.org; Tue, 3 Dec 2002 23:29:04 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB44T3v09588; Tue, 3 Dec 2002 23:29:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB44SNv09570 for ; Tue, 3 Dec 2002 23:28:23 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA02541 for ; Tue, 3 Dec 2002 23:25:22 -0500 (EST) From: john.loughney@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gB44TLW13292 for ; Wed, 4 Dec 2002 06:29:21 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 4 Dec 2002 06:28:12 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 4 Dec 2002 06:28:12 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe019.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 4 Dec 2002 06:28:11 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] What is the goal of the analysis draft? Date: Wed, 4 Dec 2002 06:28:10 +0200 Message-ID: Thread-Topic: [NSIS] What is the goal of the analysis draft? Thread-Index: AcKbMcBsd5b47h1ZS6mY+nmlgWtQHgAG6vdQ To: , Cc: X-OriginalArrivalTime: 04 Dec 2002 04:28:11.0797 (UTC) FILETIME=[8E0F9C50:01C29B4D] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gB44SNv09571 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: 8bit Hi Mike, > So, I'm not entirely sure whether an endless > string of analysis papers is really what's needed > so much as: > > 1) Identifying Stovepiped Problems > 2) Generalizing Them > 3) Deriving Requirements > > The question is what is the most expeditious route > to get to (3). The SIP experience says that it's > not easy when there are large culture clashes. I'm > all ears. I'd substitute 3) with. 3) Bring them as input into the protocol work. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Dec 4 03:37:56 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02417 for ; Wed, 4 Dec 2002 03:37:56 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB48eQg32752 for nsis-archive@odin.ietf.org; Wed, 4 Dec 2002 03:40:26 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB48eIv32730; Wed, 4 Dec 2002 03:40:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB48dTv32644 for ; Wed, 4 Dec 2002 03:39:29 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02382 for ; Wed, 4 Dec 2002 03:36:27 -0500 (EST) Received: from esealnt612.al.sw.ericsson.se (esealnt612.al.sw.ericsson.se [153.88.254.71]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id gB48dGKV002899; Wed, 4 Dec 2002 09:39:16 +0100 (MET) Received: from ESEALNT747.al.sw.ericsson.se ([153.88.251.7]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id YBCS0NYM; Wed, 4 Dec 2002 09:39:16 +0100 Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 4 Dec 2002 09:39:15 +0100 Message-ID: <2B06CD3FC17AF64587BC7A7617B230C022BD7D@enleent103.nl.eu.ericsson.se> X-Sybari-Trust: 0bcfe229 ca231590 9763731a 00000138 From: "Vlora Rexhepi (ELN)" To: "'Jukka MJ Manner'" , nsis@ietf.org Subject: RE: [NSIS] NSIS Analysis Date: Wed, 4 Dec 2002 09:39:14 +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 Jukka, John, I did send comments on the current analysis draft. I thought that we've agreed that frameworks are not going to be part of the analysis draft. Further I definitely agree with Bob that some of the RSVP extensions should be explained in more detail than the others. This has been one of my comments as well. Regards, Vlora |-----Original Message----- |From: Jukka MJ Manner [mailto:jmanner@cs.helsinki.fi] |Sent: Tuesday, December 03, 2002 11:09 AM |To: nsis@ietf.org |Subject: Re: [NSIS] NSIS Analysis | | | |Hi all, | |For the next "01" version of the document, I propose the following |editorial/conceptual changes: | |- Divide the document into | 1) pure signalling protocols, like RSVP, INSIGNIA and YESSIR | 2) larger architectural frameworks with some signalling | mechanisms, eg. currently ITSUMO | |- Keep the main focus on the signalling protocols: Part 1 |would be around |80% of the text, part 2 the rest 20% | |- Any _architecture_ review must be kept short, just to point |out original |new ideas that might benefit our work. | | |Thus, I am open for input from people regarding analysis of different |sig. prots and architectures. Send your suggestions for text |to the list |and I will take the text once the WG has had time to comment on it - |please don't send me text outside the list. | |Any additional text or changes to current text are more than welcome. |Also, me and Xiaoming don't intend to do a thorough review of all |protocols ourselves, so please contribute text to the existing |analysis. | |Regards, | |Jukka | |On Tue, 3 Dec 2002 john.loughney@nokia.com wrote: | |> Hi all, |> |> Jukka Manner has editted an analysis doc: |> |> |http://www.ietf.org/internet-drafts/draft-ietf-|nsis-signalling- |analysis-00.txt |> |> We need to capture some additional material for this |document and then |> see how much more work is needed. |> |> In Atlanta, there were a number of voices suggesting that some basic |> functionality is not broken, so does not need to be changed. | If there |> are folks looking new and novel ways to perform signaling |that is not in |> keeping with the RSVP model, then they must provide some analysis why |> what RSVP is doing, is broken. Otherwise, we will start |with some basic |> assumptions for the NSIS protocol from RSVP. I don't think |that basing |> some mechanisms on RSVP is a bad thing, that is why there needs to be |> documented reasons if we choose to do something else. |> |> 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 mailnull@www1.ietf.org Wed Dec 4 04:10:45 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03082 for ; Wed, 4 Dec 2002 04:10:45 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB49DFs02333 for nsis-archive@odin.ietf.org; Wed, 4 Dec 2002 04:13:15 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB49DBv02304; Wed, 4 Dec 2002 04:13:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB49C6v02269 for ; Wed, 4 Dec 2002 04:12:06 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03019 for ; Wed, 4 Dec 2002 04:09:04 -0500 (EST) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id gB49BrQ1004090; Wed, 4 Dec 2002 10:11:53 +0100 (MET) Received: from ESEALNT747.al.sw.ericsson.se ([153.88.251.7]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id YBCN873B; Wed, 4 Dec 2002 10:11:53 +0100 Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 4 Dec 2002 10:11:53 +0100 Message-ID: <2B06CD3FC17AF64587BC7A7617B230C0CBB7C7@enleent103.nl.eu.ericsson.se> X-Sybari-Trust: 393b8074 ca231590 9763731a 00000138 From: "Georgios Karagiannis (ELN)" To: "'Bob Braden'" , nsis@ietf.org Subject: RE: [NSIS] What is the goal of the analysis draft? Date: Wed, 4 Dec 2002 10:11:48 +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 Bob >> There is far too much micro-engineering is inventing 17 ways to do the >> same thing, and RSVP is not a sufficient framework to bring some order >> to this cahos. The proper role for the NSIS has taken on the task of >> straightening out this mess. I agree with you! >> The original base E2E signaling protocol for QoS with >> multicasting is a dead issue; nothing is to be gained by writing >> anything further about it (beyond RFC 2208). However, describing in >> some generality the ~10 different signaling protocols currently based >> on RSVP (or RSVP-TE, etc.) might be useful for helping the NSIS group >> to understand how to structure the space of ULSPs. It will require >> digging into design documents of the ATM Forum, 3GPP, the Optical >> Interworking Forum, and the ITU, as well as the MPLS WG of the IETF., >> where RSVP "extensions" have been defined. I totally agree! Best Regards, Georgios _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Dec 4 05:26:07 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05114 for ; Wed, 4 Dec 2002 05:26:06 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB4ASRr06733 for nsis-archive@odin.ietf.org; Wed, 4 Dec 2002 05:28:27 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB4ASMv06710; Wed, 4 Dec 2002 05:28:22 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB4ARtv06659 for ; Wed, 4 Dec 2002 05:27:55 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05041 for ; Wed, 4 Dec 2002 05:25:04 -0500 (EST) Received: from esealnt611.al.sw.ericsson.se (esealnt611.al.sw.ericsson.se [153.88.254.68]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id gB4ARsQ1028419; Wed, 4 Dec 2002 11:27:54 +0100 (MET) Received: from ESEALNT747.al.sw.ericsson.se ([153.88.251.7]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id YFXDFT11; Wed, 4 Dec 2002 11:27:54 +0100 Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 4 Dec 2002 11:27:53 +0100 Message-ID: <2B06CD3FC17AF64587BC7A7617B230C0CBB7C8@enleent103.nl.eu.ericsson.se> X-Sybari-Trust: 2b1d261e ca231590 9763731a 00000138 From: "Georgios Karagiannis (ELN)" To: "'Melinda Shore'" Cc: nsis@ietf.org Subject: RE: [NSIS] Layer split issues Date: Wed, 4 Dec 2002 11:27:51 +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 Melinda >> I'd be >> happy, frankly, with just getting some of that stuff cleaned >> up, but other people have raised specific issues about a >> need for reliable delivery, etc., and I hope they can be >> more explicit about why they feel it's necessary. I agree with you, we should just simplify RSVPv1 as much as possible, i.e., use only the transport related features, and try to see if it can be used as a NTLP. Best Regards, Georgios _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Dec 4 06:36:19 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06467 for ; Wed, 4 Dec 2002 06:36:18 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB4BccE11030 for nsis-archive@odin.ietf.org; Wed, 4 Dec 2002 06:38:38 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB4BcZv11022; Wed, 4 Dec 2002 06:38:35 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB4Bbxv11003 for ; Wed, 4 Dec 2002 06:37:59 -0500 Received: from mail.alcatel.be (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06461 for ; Wed, 4 Dec 2002 06:35:08 -0500 (EST) From: sven.van_den_bosch@alcatel.be Received: from bemail04.net.alcatel.be (relay3 [127.0.0.1]) by mail.alcatel.be (8.11.0/8.11.4) with ESMTP id gB4BbrY09561 for ; Wed, 4 Dec 2002 12:37:53 +0100 Subject: Re: [NSIS] Layer split issues To: "Hancock, Robert" Cc: nsis@ietf.org X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: Date: Wed, 4 Dec 2002 12:37:40 +0100 X-MIMETrack: Serialize by Router on BEMAIL04/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at 12/04/2002 12:37:53 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii 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, all, I have included some comments inline. Cheers, Sven. "Hancock, Robert" @ietf.org on 28/11/2002 14:42:40 Sent by: nsis-admin@ietf.org To: nsis@ietf.org cc: Subject: [NSIS] Layer split issues Dear all, Following the NSIS session in Atlanta, I'd like to stimulate further discussion (and maybe agreement??) on some of the issues around where the NTLP/NSLP boundary should actually go. It seems to me there are 1) some options on which there is some agreement 2) some options on which there is some disagreement 3) some options we haven't really discussed yet or at least not properly. This email is an attempt to summarise (1) (i.e. find out whether I have read the mood right). Separate emails will cover some of the topics under (2). [I think (3) includes some real headaches (e.g. mobility handling/reservation identifiers, security attributes, coupled/decoupled aspects) which can reasonably be postponed before (1) and (2) are clearer.] Message Types ============= I think we can make a working assumption that the NTLP basically provides a capability like 'send data', without associating that data with creating a reservation, querying something, releasing resources, or whatever. The 'send data' message can go with or against the data flow, and only goes between NTLP peers. Is this valid? [There may be different variants of 'send data' depending on whether the NTLP can do state management stuff, I'm not prejudging that here.] [NB. There are potentially confusing comments within the framework about how much the NTLP and NSLP could be coupled/not properly independent layers. This is a historical overhang from when we used to think that the NTLP would have a richer message set. If the NTLP has only a very simple message set, these issues would go away.] [Sven] I agree that the NTLP message types should be restricted to send data. Path Management =============== What was discussed/not objected in the framework session was (roughly) the assertion that the NTLP processing at each NSIS entity should include getting to the next NTLP peer, and that the NTLP should detect and maybe do something about path changes ("do something" may just be "tell the NSLP it's happened".) [Sven] It is clear that the NTLP should have the functionality to get to the next NTLP peer. This is required to support opaque handling of NSLP (I believe 'selective nodes' is used elsewhere to indicate this functionality). What I would like to get to the bottom of is what exactly will happen with route changes. Detecting and notifying them is the minimum we need. Left to its own devices, the NTLP would then implicitly construct the whole path (although I would content this shouldn't be described as giving the NTLP end to end capabilities). But the NSLP at any node is free to interfere however it wants anyway. [Sven] I am not sure I completely follow you here. Why does the NTLP node need to (implicitly or explicitly) construct the whole path if its scope is restricted to the next hop? I am also not sure what you mean with 'the NSLP is free to interfere'. I like this because it puts a large number of hard but signalling application independent, transport and lower layer issues inside the NTLP where they can be solved once. But I think there may be other views as well. Arguments? Sender/Receiver Issues ====================== The proposal (actually in an individual submission) is that, in so far as the NTLP has 'directionality': a) it only needs the functionality to get to the next NTLP peer in the sender-->receiver direction (might be called 'sender oriented') [Sven] The underlying reason here, I believe is the assumption that the backwards direction, if required will be taken care of by means of installed (reverse) state. There are other ways of doing it (record route is an example) which do not require keeping state. I think it is important that these are not excluded in the discussion. b) by default, it should be able to send its 'data' messages either direction, but as an optimisation, some signalling applications might only ask to send them sender-->receiver. [Sven] Can you give an example where this would matter for the NTLP? However, we shouldn't make any restrictions on how (i.e. from which end) any NSLP should trigger the signalling process, request/authorise something, or whatever. In other words, NI and NR are NSLP concepts. [Sven] Agreed. Or in other words, UNI/NNI distinction is irrelevant in the NTLP context. I haven't heard counter-proposals, but the assumption is partly contingent on the path management assumption (so I'm asking). Is this a reasonable starting point? Cheers, Robert H. (Later, under (2), we get to state management and flow identification, where there are clearly interesting divergences of view.) _______________________________________________ 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 mailnull@www1.ietf.org Wed Dec 4 08:05:10 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08774 for ; Wed, 4 Dec 2002 08:05:10 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB4D7Vt16108 for nsis-archive@odin.ietf.org; Wed, 4 Dec 2002 08:07:31 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB4D7Qv16030; Wed, 4 Dec 2002 08:07:26 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB4D4bv15381 for ; Wed, 4 Dec 2002 08:04:37 -0500 Received: from rsys002a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08658 for ; Wed, 4 Dec 2002 08:01:45 -0500 (EST) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Wed, 4 Dec 2002 13:04:34 -0000 Message-ID: <76C92FBBFB58D411AE760090271ED4181EA6F2@rsys002a.roke.co.uk> From: "Hancock, Robert" To: nsis@ietf.org Subject: RE: [NSIS] Layer split issues Date: Wed, 4 Dec 2002 13:04:33 -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 sven, some comments on your comments. [snip] > Path Management > =============== > > What was discussed/not objected in the framework session was > (roughly) the > assertion that the NTLP processing at each NSIS entity should include > getting to the next NTLP peer, and that the NTLP should > detect and maybe do > something about path changes ("do something" may just be > "tell the NSLP > it's happened".) > > [Sven] It is clear that the NTLP should have the > functionality to get to > the next NTLP peer. This is required to support opaque > handling of NSLP (I > believe 'selective nodes' is used elsewhere to indicate this > functionality). What I would like to get to the bottom of is > what exactly > will happen with route changes. Detecting and notifying them > is the minimum > we need. [reh] i think having the ability to notify an NSLP is included, and to detect at least local routing changes. i think there are some path changes better detected in the signalling application (but this is a bizarre idea i am still thinking about). mobility handling was in my category (3) ("too hard at the moment" box) > > Left to its own devices, the NTLP would then implicitly > construct the whole > path (although I would content this shouldn't be described as > giving the > NTLP end to end capabilities). But the NSLP at any node is free to > interfere however it wants anyway. > > [Sven] I am not sure I completely follow you here. Why does > the NTLP node > need to (implicitly or explicitly) construct the whole path > if its scope is > restricted to the next hop? I am also not sure what you mean > with 'the NSLP > is free to interfere'. [reh] what i mean is *) first NTLP sends it to the next *) it knows the next will send it to the next *) and so on till it gets to the end - and lo! the originating signalling application just passed a message to the NTLP and has good reason to believe it got all the way, even if there were no signalling application instances in the middle of the network helping it along. what i mean by 'interfere' is that a signalling application might eat a message at an interior node and do something which made it wrong for the NTLP to forward it directly (e.g. it might put it and its flow inside an aggregate). > > I like this because it puts a large number of hard but signalling > application independent, transport and lower layer issues > inside the NTLP > where they can be solved once. But I think there may be other views as > well. Arguments? > > Sender/Receiver Issues > ====================== > > The proposal (actually in an individual submission) is that, > in so far as > the NTLP has 'directionality': > a) it only needs the functionality to get to the next NTLP peer in the > sender-->receiver direction (might be called 'sender oriented') > > [Sven] The underlying reason here, I believe is the > assumption that the > backwards direction, if required will be taken care of by means of > installed (reverse) state. There are other ways of doing it > (record route > is an example) which do not require keeping state. I think it > is important > that these are not excluded in the discussion. [reh] i agree with you, but your comment is actually relevant to the next point (b). What (a) is trying to say (badly) is that the NTLP is only required to find downstream, not upstream peers (which is good, because we only know how to do the downstream case). > > b) by default, it should be able to send its 'data' messages either > direction, but as an optimisation, some signalling > applications might only > ask to send them sender-->receiver. > > [Sven] Can you give an example where this would matter for the NTLP? [reh] 1. to answer your route-recording point: i agree this is a reasonable mechanism to contemplate, and is not excluded here. all it says is that the state OR recorded-route data is kept internally to the NTLP, and the signalling application doesn't care how it's done. 2. where would it matter? if you had a resource management application which only required sender-->receiver messages (I'm sure you can think of one), the NTLP could forget about all the backwards routing stuff and be simpler. cheers, robert h. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Dec 4 08:08:53 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08973 for ; Wed, 4 Dec 2002 08:08:52 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB4DBD616275 for nsis-archive@odin.ietf.org; Wed, 4 Dec 2002 08:11:13 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB4DB5v16252; Wed, 4 Dec 2002 08:11:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB4DA6v16228 for ; Wed, 4 Dec 2002 08:10:06 -0500 Received: from rsys002a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08951 for ; Wed, 4 Dec 2002 08:07:15 -0500 (EST) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Wed, 4 Dec 2002 13:10:03 -0000 Message-ID: <76C92FBBFB58D411AE760090271ED4181EA6F3@rsys002a.roke.co.uk> From: "Hancock, Robert" To: nsis@ietf.org Subject: RE: [NSIS] Layer split issues Date: Wed, 4 Dec 2002 13:10:02 -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 Georgios, Melinda, all, a brief comment: > >> I'd be > >> happy, frankly, with just getting some of that stuff cleaned > >> up, but other people have raised specific issues about a > >> need for reliable delivery, etc., and I hope they can be > >> more explicit about why they feel it's necessary. > > I agree with you, we should just simplify RSVPv1 as much as possible, > i.e., use only the transport related features, > and try to see if it can be used as a NTLP. > To be clear: are we assuming that when people say 'RSVP' or 'RSVPv1' transport features they include RFC2961? I certainly hope so. (That is, I feel we need to be able to support at least equivalent transport functionality to RFC2961, even if it is not mandated in all circumstances. Presumably, these features were not added to RSVP without a good reason - i.e. genuine need. [maybe it would be profitable for the analysis document to explain why!]) Cheers, Robert H. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Dec 4 10:29:59 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16430 for ; Wed, 4 Dec 2002 10:29:59 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB4FWL425315 for nsis-archive@odin.ietf.org; Wed, 4 Dec 2002 10:32:21 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB4FWGv25305; Wed, 4 Dec 2002 10:32:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB4FVmv25256 for ; Wed, 4 Dec 2002 10:31:48 -0500 Received: from sj-msg-core-4.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16371 for ; Wed, 4 Dec 2002 10:28:54 -0500 (EST) Received: from mira-sjc5-7.cisco.com (IDENT:mirapoint@mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id gB4FViLW020842; Wed, 4 Dec 2002 07:31:44 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAT81377; Wed, 4 Dec 2002 07:24:54 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id HAA20586; Wed, 4 Dec 2002 07:31:43 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15854.8159.476580.342595@thomasm-u1.cisco.com> Date: Wed, 4 Dec 2002 07:31:43 -0800 (PST) To: Cc: , , Subject: RE: [NSIS] What is the goal of the analysis draft? In-Reply-To: References: X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! 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 john.loughney@nokia.com writes: > Hi Mike, > > > So, I'm not entirely sure whether an endless > > string of analysis papers is really what's needed > > so much as: > > > > 1) Identifying Stovepiped Problems > > 2) Generalizing Them > > 3) Deriving Requirements > > > > The question is what is the most expeditious route > > to get to (3). The SIP experience says that it's > > not easy when there are large culture clashes. I'm > > all ears. > > I'd substitute 3) with. > > 3) Bring them as input into the protocol work. I guess I disagree. To take a small example, one the problems I found with MIP/RSVP is the route damping problem. That is, an interior node seeing a new PATH for an existing reservation is going to want to back off to dampen flapping. This is great for the normal cause (interfaces bouncing), and lousy for MIP where the topology change is intentional. Thus, I think it's fairly easy to derive a requirement out of that: o The protocol must allow for explicit and intentional topology changes which are not subject to route flap damping procedures. I'm not sure I'd want to leave it up to the protocol desiners to *realize* that's a requirement if it's just in the middle of some analysis document. However we structure the process, we need to place derive the MUST's and SHOULD's of what the NSIS protocol is in a readily referenced document, and I'd sort of think that's the requirements doc. Mike _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Dec 4 10:40:52 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17069 for ; Wed, 4 Dec 2002 10:40:52 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB4FhEG26619 for nsis-archive@odin.ietf.org; Wed, 4 Dec 2002 10:43:14 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB4FhCv26604; Wed, 4 Dec 2002 10:43:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB4Ffrv26497 for ; Wed, 4 Dec 2002 10:41:53 -0500 Received: from sj-msg-core-3.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16979 for ; Wed, 4 Dec 2002 10:38:59 -0500 (EST) Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id gB4FfV0J016270; Wed, 4 Dec 2002 07:41:31 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id ABC48794; Wed, 4 Dec 2002 07:41:48 -0800 (PST) Message-Id: <200212041541.ABC48794@mira-sjc5-c.cisco.com> To: Michael Thomas cc: john.loughney@nokia.com, braden@ISI.EDU, nsis@ietf.org From: Melinda Shore Subject: Re: [NSIS] What is the goal of the analysis draft? In-Reply-To: Message from Michael Thomas of "Wed, 04 Dec 2002 07:31:43 PST." <15854.8159.476580.342595@thomasm-u1.cisco.com> Date: Wed, 04 Dec 2002 10:41:48 -0500 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: , > Thus, I think it's fairly easy to derive a requirement > out of that: > > o The protocol must allow for explicit and intentional > topology changes which are not subject to route > flap damping procedures. > > I'm not sure I'd want to leave it up to the protocol > desiners to *realize* that's a requirement if it's > just in the middle of some analysis document. I absolutely agree with this. I think that right now the requirements document suffers a bit from the inclusion of things that aren't really requirements (much of the scalability section, for example), while it's one function of a requirements document to bring out non-obvious requirements like this one. Also, while I agree with the need to move as quickly as possible, I don't think it's a good idea to try to move *more* quickly than it's possible in order to head off efforts by other standards bodies. We need to produce the best quality protocol we can within a reasonable time frame, and I'd rather see us achieve that by constraining the problem than by omitting important pieces of the process. Melinda _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Dec 4 11:07:36 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18890 for ; Wed, 4 Dec 2002 11:07:35 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB4G9wG29187 for nsis-archive@odin.ietf.org; Wed, 4 Dec 2002 11:09:58 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB4G9qv29090; Wed, 4 Dec 2002 11:09:52 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB4FtQv27808 for ; Wed, 4 Dec 2002 10:55:26 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17989 for ; Wed, 4 Dec 2002 10:52:32 -0500 (EST) Received: from esealnt613.al.sw.ericsson.se (esealnt613.al.sw.ericsson.se [153.88.254.72]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id gB4FtMKV023792; Wed, 4 Dec 2002 16:55:22 +0100 (MET) Received: from ESEALNT746.al.sw.ericsson.se ([153.88.251.6]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id YCDZBVXH; Wed, 4 Dec 2002 16:55:22 +0100 Received: by ESEALNT746.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 4 Dec 2002 16:54:36 +0100 Message-ID: <2B06CD3FC17AF64587BC7A7617B230C0CBB7CF@enleent103.nl.eu.ericsson.se> X-Sybari-Trust: 6c1c2275 ca231590 9763731a 00000138 From: "Georgios Karagiannis (ELN)" To: "'Hancock, Robert'" , "'nsis@ietf.org'" Subject: RE: [NSIS] Layer split issues Date: Wed, 4 Dec 2002 16:43:35 +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 Robert Which features of RFC2961 do you consider as transport features? Best regards, Georgios -----Original Message----- From: Hancock, Robert [mailto:robert.hancock@roke.co.uk] Sent: woensdag 4 december 2002 14:10 To: nsis@ietf.org Subject: RE: [NSIS] Layer split issues Hi Georgios, Melinda, all, a brief comment: > >> I'd be > >> happy, frankly, with just getting some of that stuff cleaned > >> up, but other people have raised specific issues about a > >> need for reliable delivery, etc., and I hope they can be > >> more explicit about why they feel it's necessary. > > I agree with you, we should just simplify RSVPv1 as much as possible, > i.e., use only the transport related features, > and try to see if it can be used as a NTLP. > To be clear: are we assuming that when people say 'RSVP' or 'RSVPv1' transport features they include RFC2961? I certainly hope so. (That is, I feel we need to be able to support at least equivalent transport functionality to RFC2961, even if it is not mandated in all circumstances. Presumably, these features were not added to RSVP without a good reason - i.e. genuine need. [maybe it would be profitable for the analysis document to explain why!]) Cheers, Robert H. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Dec 4 11:10:02 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19074 for ; Wed, 4 Dec 2002 11:10:02 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB4GCPu29425 for nsis-archive@odin.ietf.org; Wed, 4 Dec 2002 11:12:25 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB4GCIv29402; Wed, 4 Dec 2002 11:12:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB4G5fv28353 for ; Wed, 4 Dec 2002 11:05:41 -0500 Received: from sj-msg-core-3.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18604 for ; Wed, 4 Dec 2002 11:02:47 -0500 (EST) Received: from mira-sjc5-7.cisco.com (IDENT:mirapoint@mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id gB4G5J0J000372 for ; Wed, 4 Dec 2002 08:05:19 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAT82046; Wed, 4 Dec 2002 07:58:48 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id IAA20589; Wed, 4 Dec 2002 08:05:37 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15854.10193.474861.944389@thomasm-u1.cisco.com> Date: Wed, 4 Dec 2002 08:05:37 -0800 (PST) To: nsis@ietf.org X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Content-Transfer-Encoding: 7bit Subject: [NSIS] "split layers" 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 again, It occurs to me that requirements centered around the term "split layer" unnecessarily prejudice the requirements: the subtext is that this is something that RSVP got really wrong and needs to be redesigned -- most likely from the ground up -- which is not a particular accurate assessment of the state of affairs. I think it would be a lot more productive to instead devive requirements given the RSVP experience and label them in a non-prejudicial way like, oh say, Transport Requirements which says what the protocol needs to achieve rather than a particular design methodology which lends itself to fulfilling those requirements. Melinda brought up a couple issues earlier relating to transport (flat namespace, required QoS-related objects). To my mind, abstracting requirements from those kinds of issues and placing them in a general transport requirements section would be a lot more sensible at this point than trying to say how RSVP should be teased apart if we started over again; it seem quite possible to me to acheive these sorts of requirements in an RSVPbis, after all. The long and short of this is that requirements should not be prejudicing the outcome in any way. Requirements should not read like a judicial indictment. If overhauling RSVP given the requirements becomes untenable, it will become readily apparent in the design phase. Until then, we need to keep all options explicitly open. Mike _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Dec 4 11:27:59 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19914 for ; Wed, 4 Dec 2002 11:27:59 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB4GUM230516 for nsis-archive@odin.ietf.org; Wed, 4 Dec 2002 11:30:22 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB4GU7v30489; Wed, 4 Dec 2002 11:30:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB4GT6v30400 for ; Wed, 4 Dec 2002 11:29:06 -0500 Received: from rsys002a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19825 for ; Wed, 4 Dec 2002 11:26:11 -0500 (EST) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Wed, 4 Dec 2002 16:29:00 -0000 Message-ID: <76C92FBBFB58D411AE760090271ED4181EA6F5@rsys002a.roke.co.uk> From: "Hancock, Robert" To: "'nsis@ietf.org'" Subject: RE: [NSIS] Layer split issues Date: Wed, 4 Dec 2002 16:28:59 -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 georgios, i would say most of them, certainly message bundling and retransmission backoff and probably message identification. (i'm not sure about the summary refresh since i'm not sure about whether state management is a transport function, although i'm preparing to write something separate on this anyway.) which parts would you say were signalling application specific? cheers, r. > -----Original Message----- > From: Georgios Karagiannis (ELN) > [mailto:Georgios.Karagiannis@eln.ericsson.se] > Sent: 04 December 2002 15:44 > To: Hancock, Robert; 'nsis@ietf.org' > Subject: RE: [NSIS] Layer split issues > > > Hi Robert > > Which features of RFC2961 do you consider as transport features? > > Best regards, > Georgios > > > -----Original Message----- > From: Hancock, Robert [mailto:robert.hancock@roke.co.uk] > Sent: woensdag 4 december 2002 14:10 > To: nsis@ietf.org > Subject: RE: [NSIS] Layer split issues > > > Hi Georgios, Melinda, all, > > a brief comment: > > > >> I'd be > > >> happy, frankly, with just getting some of that stuff cleaned > > >> up, but other people have raised specific issues about a > > >> need for reliable delivery, etc., and I hope they can be > > >> more explicit about why they feel it's necessary. > > > > I agree with you, we should just simplify RSVPv1 as much as > possible, > > i.e., use only the transport related features, > > and try to see if it can be used as a NTLP. > > > > To be clear: are we assuming that when people say 'RSVP' or > 'RSVPv1' transport features they include RFC2961? I certainly > hope so. (That is, I feel we need to be able to support at > least equivalent transport functionality to RFC2961, even if > it is not mandated in all circumstances. Presumably, these > features were not added to RSVP without a good reason - i.e. > genuine need. [maybe it would be profitable for the analysis > document to explain why!]) > > Cheers, > > Robert H. > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Dec 4 11:28:42 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19988 for ; Wed, 4 Dec 2002 11:28:42 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB4GV6d30611 for nsis-archive@odin.ietf.org; Wed, 4 Dec 2002 11:31:06 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB4GV3v30600; Wed, 4 Dec 2002 11:31:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB4GUOv30528 for ; Wed, 4 Dec 2002 11:30:24 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19894 for ; Wed, 4 Dec 2002 11:27:29 -0500 (EST) Received: from esealnt611.al.sw.ericsson.se (esealnt611.al.sw.ericsson.se [153.88.254.68]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id gB4GUIKV001914; Wed, 4 Dec 2002 17:30:18 +0100 (MET) Received: from ESEALNT746.al.sw.ericsson.se ([153.88.251.6]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id YFXD24BD; Wed, 4 Dec 2002 17:30:18 +0100 Received: by ESEALNT746.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 4 Dec 2002 17:29:33 +0100 Message-ID: <2B06CD3FC17AF64587BC7A7617B230C0CBB7D3@enleent103.nl.eu.ericsson.se> X-Sybari-Trust: 86bac680 ca231590 9763731a 00000138 From: "Georgios Karagiannis (ELN)" To: "'Melinda Shore'" Cc: nsis@ietf.org Subject: RE: [NSIS] What is the goal of the analysis draft? Date: Wed, 4 Dec 2002 17:30:14 +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 Melinda In my opinion the scalability on the number of reservation states is an important issue that we should consider during the design process of the NSIS protocol. To give a definition of the term scalability on the number of states, see below: Scalability is a factor that shows how the performance of a node, expressed in number of reservation states, is affected by increasing the number of network users (or application flows). Maybe we could modify the scalability on the number of reservation states requirement as below: "The NSIS signaling protocol should scale in terms of number of reservation states no worse, and when possible better, than linearly with the number of users (or application flows)." Best Regards, Georgios -----Original Message----- From: Melinda Shore [mailto:mshore@cisco.com] Sent: woensdag 4 december 2002 16:42 To: Michael Thomas Cc: john.loughney@nokia.com; braden@ISI.EDU; nsis@ietf.org Subject: Re: [NSIS] What is the goal of the analysis draft? > Thus, I think it's fairly easy to derive a requirement > out of that: > > o The protocol must allow for explicit and intentional > topology changes which are not subject to route > flap damping procedures. > > I'm not sure I'd want to leave it up to the protocol > desiners to *realize* that's a requirement if it's > just in the middle of some analysis document. I absolutely agree with this. I think that right now the requirements document suffers a bit from the inclusion of things that aren't really requirements (much of the scalability section, for example), while it's one function of a requirements document to bring out non-obvious requirements like this one. Also, while I agree with the need to move as quickly as possible, I don't think it's a good idea to try to move *more* quickly than it's possible in order to head off efforts by other standards bodies. We need to produce the best quality protocol we can within a reasonable time frame, and I'd rather see us achieve that by constraining the problem than by omitting important pieces of the process. Melinda _______________________________________________ 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 mailnull@www1.ietf.org Wed Dec 4 11:30:46 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20207 for ; Wed, 4 Dec 2002 11:30:46 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB4GX9231042 for nsis-archive@odin.ietf.org; Wed, 4 Dec 2002 11:33:09 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB4GX3v30945; Wed, 4 Dec 2002 11:33:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB4GWGv30788 for ; Wed, 4 Dec 2002 11:32:16 -0500 Received: from mgw-x1.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20066 for ; Wed, 4 Dec 2002 11:29:22 -0500 (EST) From: john.loughney@nokia.com Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gB4GVXG14767 for ; Wed, 4 Dec 2002 18:31:33 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 4 Dec 2002 18:32:11 +0200 Received: from esebe010.NOE.Nokia.com ([172.21.138.49]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 4 Dec 2002 18:32:11 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe010.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 4 Dec 2002 18:32:11 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] "split layers" Date: Wed, 4 Dec 2002 18:32:11 +0200 Message-ID: Thread-Topic: [NSIS] "split layers" Thread-Index: AcKbsS1v7wYd7+jGT/2DU/U9EHXSSQAAVbWQ To: , X-OriginalArrivalTime: 04 Dec 2002 16:32:11.0453 (UTC) FILETIME=[B21D16D0:01C29BB2] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gB4GWHv30789 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: 8bit Hi Michael, > I think it would be a lot more productive to > instead devive requirements given the RSVP > experience and label them in a non-prejudicial way > like, oh say, Transport Requirements which says > what the protocol needs to achieve rather than a > particular design methodology which lends itself > to fulfilling those requirements. > > Melinda brought up a couple issues earlier > relating to transport (flat namespace, required > QoS-related objects). To my mind, abstracting > requirements from those kinds of issues and > placing them in a general transport requirements > section would be a lot more sensible at this point > than trying to say how RSVP should be teased apart > if we started over again; it seem quite possible > to me to acheive these sorts of requirements in an > RSVPbis, after all. > > The long and short of this is that requirements > should not be prejudicing the outcome in any way. > Requirements should not read like a judicial > indictment. If overhauling RSVP given the > requirements becomes untenable, it will become > readily apparent in the design phase. Until then, > we need to keep all options explicitly open. I think we'd all appreciate if folks had requirements to add, they'd suggest them. Noone has been suggesting new requirements for many months - which seemed to point to the document being quite stable. thanks, John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Dec 4 11:33:46 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20378 for ; Wed, 4 Dec 2002 11:33:46 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB4Ga9031404 for nsis-archive@odin.ietf.org; Wed, 4 Dec 2002 11:36:09 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB4Ga2v31356; Wed, 4 Dec 2002 11:36:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB4GZ3v31281 for ; Wed, 4 Dec 2002 11:35:03 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20302 for ; Wed, 4 Dec 2002 11:32:08 -0500 (EST) From: john.loughney@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gB4Ga8W20370 for ; Wed, 4 Dec 2002 18:36:09 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 4 Dec 2002 18:34:57 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 4 Dec 2002 18:34:57 +0200 Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 4 Dec 2002 18:34:56 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe016.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 4 Dec 2002 18:34:56 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] What is the goal of the analysis draft? Date: Wed, 4 Dec 2002 18:34:55 +0200 Message-ID: Thread-Topic: [NSIS] What is the goal of the analysis draft? Thread-Index: AcKbqki3wcYm8ToBSnaR+/QSoYIjaAACLVAw To: Cc: X-OriginalArrivalTime: 04 Dec 2002 16:34:56.0327 (UTC) FILETIME=[1462DD70:01C29BB3] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gB4GZ3v31282 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: 8bit Hi Mike, > I guess I disagree. To take a small example, one the > problems I found with MIP/RSVP is the route damping > problem. That is, an interior node seeing a new PATH > for an existing reservation is going to want to back > off to dampen flapping. This is great for the normal > cause (interfaces bouncing), and lousy for MIP where > the topology change is intentional. > > Thus, I think it's fairly easy to derive a requirement > out of that: > > o The protocol must allow for explicit and intentional > topology changes which are not subject to route > flap damping procedures. I'd suggest that you submit that this as a requirement to Marcus. thanks, John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Dec 4 11:49:41 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21390 for ; Wed, 4 Dec 2002 11:49:41 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB4Gq5D00501 for nsis-archive@odin.ietf.org; Wed, 4 Dec 2002 11:52:05 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB4Gq2v00490; Wed, 4 Dec 2002 11:52:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB4GpKv00425 for ; Wed, 4 Dec 2002 11:51:20 -0500 Received: from rsys002a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21268 for ; Wed, 4 Dec 2002 11:48:25 -0500 (EST) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Wed, 4 Dec 2002 16:51:16 -0000 Message-ID: <76C92FBBFB58D411AE760090271ED4181EA6F8@rsys002a.roke.co.uk> From: "Hancock, Robert" To: nsis@ietf.org Subject: RE: [NSIS] "split layers" Date: Wed, 4 Dec 2002 16:51:15 -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: , Mike, someone will doubtless correct me if i'm wrong, but I don't think it is proposed to split the requirements document by layer. (This has been proposed in the past, but isn't any more.) one the other hand, I have been operating under the belief that the w.g. had converged on having a 2 layer solution for the protocol, and therefore at some stage we should actually define the split. (i personally would like to define that split as one end product of the framework activity.) if we are not agreed on this, there is some more discussion to go through... am i labouring under a misapprehension? robert h. > -----Original Message----- > From: Michael Thomas [mailto:mat@cisco.com] > Sent: 04 December 2002 16:06 > To: nsis@ietf.org > Subject: [NSIS] "split layers" > > > > Hi again, > > It occurs to me that requirements centered around > the term "split layer" unnecessarily prejudice the > requirements: the subtext is that this is > something that RSVP got really wrong and needs to > be redesigned -- most likely from the ground up > -- which is not a particular accurate assessment > of the state of affairs. > > I think it would be a lot more productive to > instead devive requirements given the RSVP > experience and label them in a non-prejudicial way > like, oh say, Transport Requirements which says > what the protocol needs to achieve rather than a > particular design methodology which lends itself > to fulfilling those requirements. > > Melinda brought up a couple issues earlier > relating to transport (flat namespace, required > QoS-related objects). To my mind, abstracting > requirements from those kinds of issues and > placing them in a general transport requirements > section would be a lot more sensible at this point > than trying to say how RSVP should be teased apart > if we started over again; it seem quite possible > to me to acheive these sorts of requirements in an > RSVPbis, after all. > > The long and short of this is that requirements > should not be prejudicing the outcome in any way. > Requirements should not read like a judicial > indictment. If overhauling RSVP given the > requirements becomes untenable, it will become > readily apparent in the design phase. Until then, > we need to keep all options explicitly open. > > Mike > _______________________________________________ > 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 mailnull@www1.ietf.org Wed Dec 4 12:06:50 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22183 for ; Wed, 4 Dec 2002 12:06:50 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB4H9Cu03733 for nsis-archive@odin.ietf.org; Wed, 4 Dec 2002 12:09:12 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB4H98v03648; Wed, 4 Dec 2002 12:09:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB4H2av02378 for ; Wed, 4 Dec 2002 12:02:36 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21820 for ; Wed, 4 Dec 2002 11:59:43 -0500 (EST) From: john.loughney@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gB4H3gW04644 for ; Wed, 4 Dec 2002 19:03:42 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 4 Dec 2002 19:02:08 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 4 Dec 2002 19:02:08 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe019.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 4 Dec 2002 19:02:07 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] What is the goal of the analysis draft? Date: Wed, 4 Dec 2002 19:02:07 +0200 Message-ID: Thread-Topic: [NSIS] What is the goal of the analysis draft? Thread-Index: AcKbq6+DcTXPq9hFQKWzD+/OCKtRJgACn3Cw To: , Cc: , X-OriginalArrivalTime: 04 Dec 2002 17:02:07.0958 (UTC) FILETIME=[E0E9FF60:01C29BB6] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gB4H2av02379 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: 8bit Hi Melinda, Mike & Bob, > I absolutely agree with this. I think that right now the > requirements document suffers a bit from the inclusion of > things that aren't really requirements (much of the > scalability section, for example), while it's one function > of a requirements document to bring out non-obvious > requirements like this one. > > Also, while I agree with the need to move as quickly as > possible, I don't think it's a good idea to try to move > *more* quickly than it's possible in order to head off > efforts by other standards bodies. We need to produce the > best quality protocol we can within a reasonable time frame, > and I'd rather see us achieve that by constraining the > problem than by omitting important pieces of the process. My current reading of the Requirements doc is that it is general requirements document for the problem space. What you, Mike & Bob seem to be pointing to is much closer to a sort of input for protocol design. In fact, I would like to see a major part of the interim meeting to be working on such a document. Mike's document and Bob's documents have elements which are very close to what I see as needed. They are so close, that I have toyed with the idea of making one of them the starting point for the work. An even better solution would be for you, Bob & Mike to formulate a document which could be used as input for the transport protocol. This need not even be an Internet draft (though helpful if it was). Generally, we need some starting point to start to say what the transport protocol will & should & should not do. I don't think the current requirements document is really intended to do this. What do you think about this proposal? John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Dec 4 12:06:53 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22209 for ; Wed, 4 Dec 2002 12:06:52 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB4H9EM03760 for nsis-archive@odin.ietf.org; Wed, 4 Dec 2002 12:09:14 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB4H9Bv03711; Wed, 4 Dec 2002 12:09:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB4H5mv02722 for ; Wed, 4 Dec 2002 12:05:48 -0500 Received: from sj-msg-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22011 for ; Wed, 4 Dec 2002 12:02:55 -0500 (EST) Received: from mira-sjc5-7.cisco.com (IDENT:mirapoint@mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id gB4H5f0R025648; Wed, 4 Dec 2002 09:05:41 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAT83343; Wed, 4 Dec 2002 08:58:53 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA20593; Wed, 4 Dec 2002 09:05:41 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15854.13797.771447.645721@thomasm-u1.cisco.com> Date: Wed, 4 Dec 2002 09:05:41 -0800 (PST) To: Cc: , Subject: RE: [NSIS] "split layers" In-Reply-To: References: X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! 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 john.loughney@nokia.com writes: > > The long and short of this is that requirements > > should not be prejudicing the outcome in any way. > > Requirements should not read like a judicial > > indictment. If overhauling RSVP given the > > requirements becomes untenable, it will become > > readily apparent in the design phase. Until then, > > we need to keep all options explicitly open. > > I think we'd all appreciate if folks had requirements > to add, they'd suggest them. Noone has been suggesting > new requirements for many months - which seemed to point > to the document being quite stable. John, An alternatate explanation is that the mailing list has been a very confusing mishmash of culture clash, problem scoping, requirements (some), along with a huge volume of solution space which makes it very difficult to track what the actual problem scope/requirements are in all of the noise. Or at least that's *my* problem. I think it would be really helpful to quash any talk of solutions on the main list for now. For my part, I think the requirements draft needs a lot of work. More later. Mike _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Dec 4 12:15:58 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22789 for ; Wed, 4 Dec 2002 12:15:58 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB4HIKQ04273 for nsis-archive@odin.ietf.org; Wed, 4 Dec 2002 12:18:20 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB4HIDv04265; Wed, 4 Dec 2002 12:18:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB4HHgv04224 for ; Wed, 4 Dec 2002 12:17:42 -0500 Received: from sj-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22653 for ; Wed, 4 Dec 2002 12:14:48 -0500 (EST) Received: from mira-sjc5-7.cisco.com (IDENT:mirapoint@mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gB4HHbK0007721; Wed, 4 Dec 2002 09:17:37 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAT83644; Wed, 4 Dec 2002 09:10:48 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA20596; Wed, 4 Dec 2002 09:17:37 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15854.14512.863345.906207@thomasm-u1.cisco.com> Date: Wed, 4 Dec 2002 09:17:36 -0800 (PST) To: "Hancock, Robert" Cc: nsis@ietf.org Subject: RE: [NSIS] "split layers" In-Reply-To: <76C92FBBFB58D411AE760090271ED4181EA6F8@rsys002a.roke.co.uk> References: <76C92FBBFB58D411AE760090271ED4181EA6F8@rsys002a.roke.co.uk> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! 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 Hancock, Robert writes: > Mike, > > someone will doubtless correct me if i'm wrong, but I > don't think it is proposed to split the requirements > document by layer. (This has been proposed in the past, > but isn't any more.) My suggestion was more along the lines of grouping requirements based on some overall characteristic. There might be transport related requirements, mobility related requirements, application separability related requirements, initiation related requirements, and so forth. > one the other hand, I have been operating under the > belief that the w.g. had converged on having a 2 layer > solution for the protocol, and therefore at some stage > we should actually define the split. (i personally > would like to define that split as one end product of > the framework activity.) if we are not agreed on this, > there is some more discussion to go through... > > am i labouring under a misapprehension? Reading through the requirements document it isn't immediately clear to me what "2 layer" actually means in practice. I could easily claim that RSVP is two layer right now, and the current requirements doesn't guide me as to why somebody else might have a different opinion. Right now, there's way too much motherhood in the draft and not enough concrete design criterion. This is particularly important as we already have a working signaling protocol to compare and contrast. If there are additional things that RSVP should have done, for example, or does poorly I think we should be very explicit about those things so long as we keep the tone requirements based rather than a polemic. Mike _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Dec 4 12:29:50 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23827 for ; Wed, 4 Dec 2002 12:29:49 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB4HWC805291 for nsis-archive@odin.ietf.org; Wed, 4 Dec 2002 12:32:12 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB4HW7v05283; Wed, 4 Dec 2002 12:32:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB4HVMv05248 for ; Wed, 4 Dec 2002 12:31:22 -0500 Received: from tokyo.ccrle.nec.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23780 for ; Wed, 4 Dec 2002 12:28:28 -0500 (EST) Received: from imap.heidelberg.ccrle.nec.de (imap [192.168.102.11]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id gB4HV1F54273; Wed, 4 Dec 2002 18:31:01 +0100 (CET) (envelope-from brunner@ccrle.nec.de) Received: from [192.168.102.207] (marcus.heidelberg.ccrle.nec.de [192.168.102.207]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 149ED12C8A; Wed, 4 Dec 2002 18:28:59 +0100 (CET) Date: Wed, 04 Dec 2002 18:29:00 +0100 From: Marcus Brunner Reply-To: brunner@ccrle.nec.de To: Michael Thomas , "Hancock, Robert" Cc: nsis@ietf.org Subject: RE: [NSIS] "split layers" Message-ID: <28811008.1039026540@[192.168.102.207]> In-Reply-To: <15854.14512.863345.906207@thomasm-u1.cisco.com> References: <15854.14512.863345.906207@thomasm-u1.cisco.com> X-Mailer: Mulberry/2.2.0 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline 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 > > am i labouring under a misapprehension? > > Reading through the requirements document it isn't > immediately clear to me what "2 layer" actually > means in practice. I could easily claim that RSVP > is two layer right now, and the current > requirements doesn't guide me as to why somebody > else might have a different opinion. The requierments stays on an abstraction level above and is talking about e.g. modularity, which can be achieved by 2 layers or 5 layers or other means. The document does not requiere a 2 layer appraoch. And everything in the requirement draft must not be new compared to RSVP. What the problem of RSVP is should be covered in the analysis draft. From a requirement perspective there is much more scoping requirements then protocol design requirements. Marcus -------------------------------------- Dr. Marcus Brunner Network Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ Phone: +49 (0) 6221 905 11 29 personal home page: http://www.brubers.org/marcus _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Dec 4 12:42:46 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24539 for ; Wed, 4 Dec 2002 12:42:46 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB4Hj9u06605 for nsis-archive@odin.ietf.org; Wed, 4 Dec 2002 12:45:09 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB4Hj5v06590; Wed, 4 Dec 2002 12:45:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB4Hiiv06555 for ; Wed, 4 Dec 2002 12:44:44 -0500 Received: from tokyo.ccrle.nec.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24488 for ; Wed, 4 Dec 2002 12:41:50 -0500 (EST) Received: from imap.heidelberg.ccrle.nec.de (imap [192.168.102.11]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id gB4HiUF54609; Wed, 4 Dec 2002 18:44:30 +0100 (CET) (envelope-from brunner@ccrle.nec.de) Received: from [192.168.102.207] (marcus.heidelberg.ccrle.nec.de [192.168.102.207]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id DBC6C698D8; Wed, 4 Dec 2002 18:42:27 +0100 (CET) Date: Wed, 04 Dec 2002 18:42:28 +0100 From: Marcus Brunner Reply-To: brunner@ccrle.nec.de To: Michael Thomas Cc: nsis@ietf.org Subject: RE: [NSIS] NSIS Analysis Message-ID: <29619700.1039027348@[192.168.102.207]> In-Reply-To: <15852.60405.402592.830518@thomasm-u1.cisco.com> References: <15852.60405.402592.830518@thomasm-u1.cisco.com> X-Mailer: Mulberry/2.2.0 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline 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 > It's not entirely clear to me how that fits in > with this wg too. Having some background is still > useful, I think, but it might make more sense to > do it in terms of a more terse problem statement > which feeds into requirements which then allows us > to have a guide for ultimate protocol selection. > I would think most of your analysis work fits very well in the analysuis draft. > As a corollary, I think until we figure this all > out, it's probably premature to last call the > requirements. If you think this way, we will finish the requierment draft after the protocol specification :-) Marcus -------------------------------------- Marcus Brunner Network Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ Phone: +49 (0) 6221 905 11 29 personal home page: http://www.brubers.org/marcus _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Dec 4 13:22:59 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26715 for ; Wed, 4 Dec 2002 13:22:59 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB4IPMK09224 for nsis-archive@odin.ietf.org; Wed, 4 Dec 2002 13:25:22 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB4IPEv09183; Wed, 4 Dec 2002 13:25:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB4IO1v09115 for ; Wed, 4 Dec 2002 13:24:01 -0500 Received: from sj-msg-core-3.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26622 for ; Wed, 4 Dec 2002 13:21:07 -0500 (EST) Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id gB4INa0J005888; Wed, 4 Dec 2002 10:23:36 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id ABC58281; Wed, 4 Dec 2002 10:23:53 -0800 (PST) Message-Id: <200212041823.ABC58281@mira-sjc5-c.cisco.com> To: "Georgios Karagiannis (ELN)" cc: nsis@ietf.org From: Melinda Shore Subject: Re: [NSIS] What is the goal of the analysis draft? In-Reply-To: Message from "Georgios Karagiannis (ELN)" of "Wed, 04 Dec 2002 17:30:14 +0100." <2B06CD3FC17AF64587BC7A7617B230C0CBB7D3@enleent103.nl.eu.ericsson.se> Date: Wed, 04 Dec 2002 13:23:53 -0500 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 think that it's pretty clear that "scalability" is not a particularly meaningful term when it comes to laying out requirements. I would prefer to see things like "must support message aggregation" than "should limit the load on devices." Maybe this needs to be thought of in terms of what would happen if it were not included. Do you think that if section 5.5.5 were omitted, people designing a protocol would then think "the heck with network efficiency?" Melinda _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Dec 4 13:56:55 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28322 for ; Wed, 4 Dec 2002 13:56:55 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB4IxIS11368 for nsis-archive@odin.ietf.org; Wed, 4 Dec 2002 13:59:18 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB4IxEv11344; Wed, 4 Dec 2002 13:59:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB4Iwxv11307 for ; Wed, 4 Dec 2002 13:58:59 -0500 Received: from sj-msg-core-4.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28278 for ; Wed, 4 Dec 2002 13:56:04 -0500 (EST) Received: from mira-sjc5-7.cisco.com (IDENT:mirapoint@mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id gB4IwjLW029626; Wed, 4 Dec 2002 10:58:45 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAT87293; Wed, 4 Dec 2002 10:51:53 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA20614; Wed, 4 Dec 2002 10:58:42 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15854.20578.232784.438928@thomasm-u1.cisco.com> Date: Wed, 4 Dec 2002 10:58:42 -0800 (PST) To: brunner@ccrle.nec.de Cc: Michael Thomas , "Hancock, Robert" , nsis@ietf.org Subject: RE: [NSIS] "split layers" In-Reply-To: <28811008.1039026540@[192.168.102.207]> References: <15854.14512.863345.906207@thomasm-u1.cisco.com> <28811008.1039026540@[192.168.102.207]> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! 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 Marcus Brunner writes: > > > > am i labouring under a misapprehension? > > > > Reading through the requirements document it isn't > > immediately clear to me what "2 layer" actually > > means in practice. I could easily claim that RSVP > > is two layer right now, and the current > > requirements doesn't guide me as to why somebody > > else might have a different opinion. > > The requierments stays on an abstraction level above and is talking about > e.g. modularity, which can be achieved by 2 layers or 5 layers or other > means. The document does not requiere a 2 layer appraoch. And everything in > the requirement draft must not be new compared to RSVP. What the problem of > RSVP is should be covered in the analysis draft. Again, modularity doesn't mean very much in the abstract; we need more concrete requirements. For example: does the protocol need to be able to transport more than one "application" at a time? Does it need to provide name space hierarchy? Are the auth/authz requirements for one application transported required to be identical for other applications? I'm afraid that these kinds of issues need to be clear in the requirements because they greatly either expand or contract the design space. Mike _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Dec 5 04:12:22 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04831 for ; Thu, 5 Dec 2002 04:12:22 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB59Erm07681 for nsis-archive@odin.ietf.org; Thu, 5 Dec 2002 04:14:53 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB59ELv07671; Thu, 5 Dec 2002 04:14:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB59Djv07656 for ; Thu, 5 Dec 2002 04:13:45 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04807 for ; Thu, 5 Dec 2002 04:10:43 -0500 (EST) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id gB59DWQ1006972; Thu, 5 Dec 2002 10:13:32 +0100 (MET) Received: from ESEALNT746.al.sw.ericsson.se ([153.88.251.6]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id YBC3GSNS; Thu, 5 Dec 2002 10:13:32 +0100 Received: by ESEALNT746.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 5 Dec 2002 10:13:32 +0100 Message-ID: <2B06CD3FC17AF64587BC7A7617B230C0CBB7D4@enleent103.nl.eu.ericsson.se> X-Sybari-Trust: 051e56b6 ca231590 0ab44ba3 00000138 From: "Georgios Karagiannis (ELN)" To: "'Melinda Shore'" Cc: nsis@ietf.org Subject: RE: [NSIS] What is the goal of the analysis draft? Date: Thu, 5 Dec 2002 10:13:34 +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 Melinda Regarding the scalability term I see your point! Maybe we could enlarge the scalability requirements with sentences, such as: "when applicable must support state aggregation", "when applicable must support message aggregation", etc. Is this acceptable to you? Regarding section 5.5.5, I think that it emphasizes the need on achieving high network utilization and therefore, it makes sense to have such a requirement. Best Regards, Georgios -----Original Message----- From: Melinda Shore [mailto:mshore@cisco.com] Sent: woensdag 4 december 2002 19:24 To: Georgios Karagiannis (ELN) Cc: nsis@ietf.org Subject: Re: [NSIS] What is the goal of the analysis draft? I think that it's pretty clear that "scalability" is not a particularly meaningful term when it comes to laying out requirements. I would prefer to see things like "must support message aggregation" than "should limit the load on devices." Maybe this needs to be thought of in terms of what would happen if it were not included. Do you think that if section 5.5.5 were omitted, people designing a protocol would then think "the heck with network efficiency?" Melinda _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Dec 5 04:21:03 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04976 for ; Thu, 5 Dec 2002 04:21:03 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB59NYZ07967 for nsis-archive@odin.ietf.org; Thu, 5 Dec 2002 04:23:34 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB59NMv07960; Thu, 5 Dec 2002 04:23:22 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB59Mqv07912 for ; Thu, 5 Dec 2002 04:22:52 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04967 for ; Thu, 5 Dec 2002 04:19:50 -0500 (EST) Received: from esealnt611.al.sw.ericsson.se (esealnt611.al.sw.ericsson.se [153.88.254.68]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id gB59MeKV010773; Thu, 5 Dec 2002 10:22:40 +0100 (MET) Received: from ESEALNT747.al.sw.ericsson.se ([153.88.251.7]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id YFXDMP13; Thu, 5 Dec 2002 10:22:40 +0100 Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 5 Dec 2002 10:22:39 +0100 Message-ID: <2B06CD3FC17AF64587BC7A7617B230C0CBB7D6@enleent103.nl.eu.ericsson.se> X-Sybari-Trust: 7c227eca ca231590 0ab44ba3 00000138 From: "Georgios Karagiannis (ELN)" To: "'john.loughney@nokia.com'" , mshore@cisco.com, mat@cisco.com Cc: braden@ISI.EDU, nsis@ietf.org Subject: RE: [NSIS] What is the goal of the analysis draft? Date: Thu, 5 Dec 2002 10:22:40 +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 I agree with your proposal! Best regards, Georgios -----Original Message----- From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] Sent: woensdag 4 december 2002 18:02 To: mshore@cisco.com; mat@cisco.com Cc: braden@ISI.EDU; nsis@ietf.org Subject: RE: [NSIS] What is the goal of the analysis draft? Hi Melinda, Mike & Bob, > I absolutely agree with this. I think that right now the > requirements document suffers a bit from the inclusion of > things that aren't really requirements (much of the > scalability section, for example), while it's one function > of a requirements document to bring out non-obvious > requirements like this one. > > Also, while I agree with the need to move as quickly as > possible, I don't think it's a good idea to try to move > *more* quickly than it's possible in order to head off > efforts by other standards bodies. We need to produce the > best quality protocol we can within a reasonable time frame, > and I'd rather see us achieve that by constraining the > problem than by omitting important pieces of the process. My current reading of the Requirements doc is that it is general requirements document for the problem space. What you, Mike & Bob seem to be pointing to is much closer to a sort of input for protocol design. In fact, I would like to see a major part of the interim meeting to be working on such a document. Mike's document and Bob's documents have elements which are very close to what I see as needed. They are so close, that I have toyed with the idea of making one of them the starting point for the work. An even better solution would be for you, Bob & Mike to formulate a document which could be used as input for the transport protocol. This need not even be an Internet draft (though helpful if it was). Generally, we need some starting point to start to say what the transport protocol will & should & should not do. I don't think the current requirements document is really intended to do this. What do you think about this proposal? 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 mailnull@www1.ietf.org Thu Dec 5 04:53:37 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05840 for ; Thu, 5 Dec 2002 04:53:37 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB59u8J09643 for nsis-archive@odin.ietf.org; Thu, 5 Dec 2002 04:56:08 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB59u6v09636; Thu, 5 Dec 2002 04:56:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB59tov09617 for ; Thu, 5 Dec 2002 04:55:50 -0500 Received: from porsta.cs.Helsinki.FI (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05824 for ; Thu, 5 Dec 2002 04:52:47 -0500 (EST) Received: from melkinpaasi.cs.Helsinki.FI (IDENT:jmanner@melkinpaasi.cs.Helsinki.FI [128.214.10.13]) by porsta.cs.Helsinki.FI (8.11.6/8.11.6) with ESMTP id gB59tcW07354 for ; Thu, 5 Dec 2002 11:55:38 +0200 Date: Thu, 5 Dec 2002 11:55:37 +0200 (EET) From: Jukka MJ Manner To: nsis@ietf.org Subject: RE: [NSIS] What is the goal of the analysis draft? In-Reply-To: <2B06CD3FC17AF64587BC7A7617B230C0CBB7D4@enleent103.nl.eu.ericsson.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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: , Just a thought: aren't your suggestions related to the "blob" the protocols is carrying? Thus, the protocol should support upper layer object agregation (within single messages) and the upper layer objects should be designed to allow for state aggregation at processing nodes. Regards, Jukka On Thu, 5 Dec 2002, Georgios Karagiannis (ELN) wrote: > Hi Melinda > > Regarding the scalability term I see your point! > Maybe we could enlarge the scalability requirements > with sentences, such as: > "when applicable must support state aggregation", > "when applicable must support message aggregation", etc. > > Is this acceptable to you? > > Regarding section 5.5.5, I think that it emphasizes > the need on achieving high network utilization and therefore, > it makes sense to have such a requirement. > > Best Regards, > Georgios > > > -----Original Message----- > From: Melinda Shore [mailto:mshore@cisco.com] > Sent: woensdag 4 december 2002 19:24 > To: Georgios Karagiannis (ELN) > Cc: nsis@ietf.org > Subject: Re: [NSIS] What is the goal of the analysis draft? > > > I think that it's pretty clear that "scalability" is not a > particularly meaningful term when it comes to laying out > requirements. I would prefer to see things like "must > support message aggregation" than "should limit the load on > devices." Maybe this needs to be thought of in terms of > what would happen if it were not included. Do you think > that if section 5.5.5 were omitted, people designing a > protocol would then think "the heck with network > efficiency?" > > Melinda > _______________________________________________ > 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 mailnull@www1.ietf.org Thu Dec 5 04:54:36 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05892 for ; Thu, 5 Dec 2002 04:54:36 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB59v8x09723 for nsis-archive@odin.ietf.org; Thu, 5 Dec 2002 04:57:08 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB59v6v09712; Thu, 5 Dec 2002 04:57:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB59uqv09681 for ; Thu, 5 Dec 2002 04:56:52 -0500 Received: from mail1.telekom.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05857 for ; Thu, 5 Dec 2002 04:53:48 -0500 (EST) Received: from g8pbr.blf01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Thu, 5 Dec 2002 10:47:31 +0100 Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Thu, 5 Dec 2002 10:47:30 +0100 Message-Id: <9F8582E37B2EE5498E76392AEDDCD3FE23B269@G8PQD.blf01.telekom.de> From: "Geib, Ruediger" To: brunner@ccrle.nec.de Cc: nsis@ietf.org Subject: RE: [NSIS] "split layers" Date: Thu, 5 Dec 2002 10:47:25 +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: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gB59uqv09682 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: 8bit Marcus, Given that there's one requirements doc only, Mike is certainly right in demanding that the "layered requirements" get clearly visible there. The "two layers" are no requirement in themselves. They are a definition (or a basic design assumption). Any requirements must be classified as "Transport", "Service" or "General" (if applicable). In cases like security, both layers may have different requirements on the same subject (like e.g. message integrity and authentication between peers). Regards, Rüdiger > Marcus Brunner writes: > > > > > > am i labouring under a misapprehension? > > > > > > Reading through the requirements document it isn't > > > immediately clear to me what "2 layer" actually > > > means in practice. I could easily claim that RSVP > > > is two layer right now, and the current > > > requirements doesn't guide me as to why somebody > > > else might have a different opinion. > > > > The requierments stays on an abstraction level above and > > is talking about e.g. modularity, which can be achieved > > by 2 layers or 5 layers or other means. The document > > does not requiere a 2 layer appraoch. And everything in > > the requirement draft must not be new compared to RSVP. > > What the problem of RSVP is should be covered in the > > analysis draft. > > Again, modularity doesn't mean very much in the > abstract; we need more concrete requirements. For > example: does the protocol need to be able to > transport more than one "application" at a time? > Does it need to provide name space hierarchy? Are > the auth/authz requirements for one application > transported required to be identical for other > applications? > > I'm afraid that these kinds of issues need to be > clear in the requirements because they greatly > either expand or contract the design space. > > Mike _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Dec 5 04:57:35 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05963 for ; Thu, 5 Dec 2002 04:57:35 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB59xue09830 for nsis-archive@odin.ietf.org; Thu, 5 Dec 2002 04:59:56 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB59xqv09814; Thu, 5 Dec 2002 04:59:52 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB59xQv09773 for ; Thu, 5 Dec 2002 04:59:26 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05949 for ; Thu, 5 Dec 2002 04:56:23 -0500 (EST) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id gB59xEQ1020957; Thu, 5 Dec 2002 10:59:14 +0100 (MET) Received: from ESEALNT747.al.sw.ericsson.se ([153.88.251.7]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id YBC3G0Y2; Thu, 5 Dec 2002 10:59:14 +0100 Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 5 Dec 2002 10:59:13 +0100 Message-ID: <2B06CD3FC17AF64587BC7A7617B230C0CBB7D7@enleent103.nl.eu.ericsson.se> X-Sybari-Trust: d0f562f6 ca231590 0ab44ba3 00000138 From: "Georgios Karagiannis (ELN)" To: "'Jukka MJ Manner'" , nsis@ietf.org Subject: RE: [NSIS] What is the goal of the analysis draft? Date: Thu, 5 Dec 2002 10:59:15 +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 Jukka The requirements document refers to both transport and application layers! Best regards, Georgios -----Original Message----- From: Jukka MJ Manner [mailto:jmanner@cs.helsinki.fi] Sent: donderdag 5 december 2002 10:56 To: nsis@ietf.org Subject: RE: [NSIS] What is the goal of the analysis draft? Just a thought: aren't your suggestions related to the "blob" the protocols is carrying? Thus, the protocol should support upper layer object agregation (within single messages) and the upper layer objects should be designed to allow for state aggregation at processing nodes. Regards, Jukka On Thu, 5 Dec 2002, Georgios Karagiannis (ELN) wrote: > Hi Melinda > > Regarding the scalability term I see your point! > Maybe we could enlarge the scalability requirements > with sentences, such as: > "when applicable must support state aggregation", > "when applicable must support message aggregation", etc. > > Is this acceptable to you? > > Regarding section 5.5.5, I think that it emphasizes > the need on achieving high network utilization and therefore, > it makes sense to have such a requirement. > > Best Regards, > Georgios > > > -----Original Message----- > From: Melinda Shore [mailto:mshore@cisco.com] > Sent: woensdag 4 december 2002 19:24 > To: Georgios Karagiannis (ELN) > Cc: nsis@ietf.org > Subject: Re: [NSIS] What is the goal of the analysis draft? > > > I think that it's pretty clear that "scalability" is not a > particularly meaningful term when it comes to laying out > requirements. I would prefer to see things like "must > support message aggregation" than "should limit the load on > devices." Maybe this needs to be thought of in terms of > what would happen if it were not included. Do you think > that if section 5.5.5 were omitted, people designing a > protocol would then think "the heck with network > efficiency?" > > Melinda > _______________________________________________ > 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 mailnull@www1.ietf.org Thu Dec 5 05:01:47 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06051 for ; Thu, 5 Dec 2002 05:01:46 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB5A47L09959 for nsis-archive@odin.ietf.org; Thu, 5 Dec 2002 05:04:07 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB5A43v09951; Thu, 5 Dec 2002 05:04:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB5A3vv09922 for ; Thu, 5 Dec 2002 05:03:57 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06022 for ; Thu, 5 Dec 2002 05:01:05 -0500 (EST) Received: from esealnt613.al.sw.ericsson.se (esealnt613.al.sw.ericsson.se [153.88.254.72]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id gB5A3uKV024931; Thu, 5 Dec 2002 11:03:56 +0100 (MET) Received: from ESEALNT747.al.sw.ericsson.se ([153.88.251.7]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id YCDZGK73; Thu, 5 Dec 2002 11:03:56 +0100 Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 5 Dec 2002 11:03:55 +0100 Message-ID: <2B06CD3FC17AF64587BC7A7617B230C0CBB7D9@enleent103.nl.eu.ericsson.se> X-Sybari-Trust: 4038f7af ca231590 0ab44ba3 00000138 From: "Georgios Karagiannis (ELN)" To: "'Geib, Ruediger'" , brunner@ccrle.nec.de Cc: nsis@ietf.org Subject: RE: [NSIS] "split layers" Date: Thu, 5 Dec 2002 11:03:54 +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: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gB5A3vv09923 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: 8bit Hi Rudiger I think that the layered functionality could be emphasized in the framework draft. Best Regards, Georgios -----Original Message----- From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] Sent: donderdag 5 december 2002 10:47 To: brunner@ccrle.nec.de Cc: nsis@ietf.org Subject: RE: [NSIS] "split layers" Marcus, Given that there's one requirements doc only, Mike is certainly right in demanding that the "layered requirements" get clearly visible there. The "two layers" are no requirement in themselves. They are a definition (or a basic design assumption). Any requirements must be classified as "Transport", "Service" or "General" (if applicable). In cases like security, both layers may have different requirements on the same subject (like e.g. message integrity and authentication between peers). Regards, Rüdiger > Marcus Brunner writes: > > > > > > am i labouring under a misapprehension? > > > > > > Reading through the requirements document it isn't > > > immediately clear to me what "2 layer" actually > > > means in practice. I could easily claim that RSVP > > > is two layer right now, and the current > > > requirements doesn't guide me as to why somebody > > > else might have a different opinion. > > > > The requierments stays on an abstraction level above and > > is talking about e.g. modularity, which can be achieved > > by 2 layers or 5 layers or other means. The document > > does not requiere a 2 layer appraoch. And everything in > > the requirement draft must not be new compared to RSVP. > > What the problem of RSVP is should be covered in the > > analysis draft. > > Again, modularity doesn't mean very much in the > abstract; we need more concrete requirements. For > example: does the protocol need to be able to > transport more than one "application" at a time? > Does it need to provide name space hierarchy? Are > the auth/authz requirements for one application > transported required to be identical for other > applications? > > I'm afraid that these kinds of issues need to be > clear in the requirements because they greatly > either expand or contract the design space. > > Mike _______________________________________________ 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 mailnull@www1.ietf.org Thu Dec 5 05:01:47 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06053 for ; Thu, 5 Dec 2002 05:01:47 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB5A47C09971 for nsis-archive@odin.ietf.org; Thu, 5 Dec 2002 05:04:07 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB5A42v09936; Thu, 5 Dec 2002 05:04:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB5A3Yv09917 for ; Thu, 5 Dec 2002 05:03:34 -0500 Received: from mgw-x1.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06008 for ; Thu, 5 Dec 2002 05:00:42 -0500 (EST) From: john.loughney@nokia.com Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gB5A2rG01330 for ; Thu, 5 Dec 2002 12:02:53 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 5 Dec 2002 12:03:29 +0200 Received: from esebe005.NOE.Nokia.com ([172.21.138.45]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 5 Dec 2002 12:03:28 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 5 Dec 2002 12:03:27 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] "split layers" Date: Thu, 5 Dec 2002 12:03:25 +0200 Message-ID: Thread-Topic: [NSIS] "split layers" Thread-Index: AcKcRK7tE/B/VxaOTX23NWHSHuHshgAAHrqg To: , Cc: X-OriginalArrivalTime: 05 Dec 2002 10:03:27.0095 (UTC) FILETIME=[8E204070:01C29C45] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gB5A3Yv09918 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: 8bit Rüdiger, > Given that there's one requirements doc only, > Mike is certainly right in demanding that the > "layered requirements" get clearly visible > there. The "two layers" are no requirement in > themselves. They are a definition (or a basic > design assumption). Any requirements must be > classified as "Transport", "Service" or > "General" (if applicable). In cases like > security, both layers may have different > requirements on the same subject (like e.g. > message integrity and authentication between > peers). What I'd like to encourage folks to do is make recommendations on how to improve the current set of requirements, if they feel thre is some need. So, if you think that some current requirements could be better worded to cover possible functionality split, then please suggest. Please note that currently, we do not have a functionality split determined, so I feel trying to make requirements specifically discussing a fictitious split to be wrong. That does not mean, however, that I don't think that the current set could be improved, so please make some suggestions, if you have any. thanks, John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Dec 5 05:53:02 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07241 for ; Thu, 5 Dec 2002 05:53:02 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB5AtNL13129 for nsis-archive@odin.ietf.org; Thu, 5 Dec 2002 05:55:23 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB5AtJv13118; Thu, 5 Dec 2002 05:55:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB5AsRv13046 for ; Thu, 5 Dec 2002 05:54:27 -0500 Received: from mail1.telekom.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07175 for ; Thu, 5 Dec 2002 05:51:35 -0500 (EST) Received: from g8pbr.blf01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Thu, 5 Dec 2002 11:41:12 +0100 Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Thu, 5 Dec 2002 11:41:11 +0100 Message-Id: <9F8582E37B2EE5498E76392AEDDCD3FE23B26A@G8PQD.blf01.telekom.de> From: "Geib, Ruediger" To: john.loughney@nokia.com Cc: nsis@ietf.org Subject: RE: [NSIS] "split layers" Date: Thu, 5 Dec 2002 11:41:10 +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: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gB5AsRv13047 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: 8bit John, > Please note that currently, we do not have a functionality > split determined, so I feel trying to make requirements specifically > discussing a fictitious split to be wrong. That does not mean, > however, that I don't think that the current set could be improved, > so please make some suggestions, if you have any. You want to say that first we will determine the the functionality split and then we will formulate the requirements for each functionality? Regards, Rüdiger _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Dec 5 05:57:46 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07298 for ; Thu, 5 Dec 2002 05:57:46 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB5B08o13310 for nsis-archive@odin.ietf.org; Thu, 5 Dec 2002 06:00:08 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB5B03v13292; Thu, 5 Dec 2002 06:00:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB5Axov13256 for ; Thu, 5 Dec 2002 05:59:50 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07292 for ; Thu, 5 Dec 2002 05:56:58 -0500 (EST) From: john.loughney@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gB5B0xW16514 for ; Thu, 5 Dec 2002 13:00:59 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 5 Dec 2002 12:59:48 +0200 Received: from esebe005.NOE.Nokia.com ([172.21.138.45]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 5 Dec 2002 12:59:48 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 5 Dec 2002 12:59:47 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] "split layers" Date: Thu, 5 Dec 2002 12:59:47 +0200 Message-ID: Thread-Topic: [NSIS] "split layers" Thread-Index: AcKcTLKjny1IXTBJTCyOjj/dHY+8tAAAGdJA To: Cc: X-OriginalArrivalTime: 05 Dec 2002 10:59:47.0919 (UTC) FILETIME=[6D410DF0:01C29C4D] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gB5Axov13257 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: 8bit Hi Rüdiger, > > Please note that currently, we do not have a functionality > > split determined, so I feel trying to make requirements specifically > > discussing a fictitious split to be wrong. That does not mean, > > however, that I don't think that the current set could be improved, > > so please make some suggestions, if you have any. > > You want to say that first we will determine the the functionality > split and then we will formulate the requirements for each > functionality? No, I am actually trying to say the reverse. The requirements should be general requirements. We should handle the layer split in a seperate document, which then specifies the more layer-specific requirements. I have thought that a document which is more prescriptive like 'the transport layer handles message fragmentation / re-assembly' or the 'application layer handles application state creation authorization' would be the proper way to go. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Dec 5 08:43:09 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10963 for ; Thu, 5 Dec 2002 08:43:08 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB5DjUT23559 for nsis-archive@odin.ietf.org; Thu, 5 Dec 2002 08:45:30 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB5DjJv23549; Thu, 5 Dec 2002 08:45:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB5Di4v23451 for ; Thu, 5 Dec 2002 08:44:04 -0500 Received: from sj-msg-core-4.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10866 for ; Thu, 5 Dec 2002 08:41:12 -0500 (EST) Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id gB5Di0LW026483; Thu, 5 Dec 2002 05:44:00 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id ABD09022; Thu, 5 Dec 2002 05:44:00 -0800 (PST) Message-Id: <200212051344.ABD09022@mira-sjc5-c.cisco.com> To: "Georgios Karagiannis (ELN)" cc: nsis@ietf.org From: Melinda Shore Subject: Re: [NSIS] What is the goal of the analysis draft? In-Reply-To: Message from "Georgios Karagiannis (ELN)" of "Thu, 05 Dec 2002 10:13:34 +0100." <2B06CD3FC17AF64587BC7A7617B230C0CBB7D4@enleent103.nl.eu.ericsson.se> Date: Thu, 05 Dec 2002 08:43:59 -0500 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: , > Regarding the scalability term I see your point! > Maybe we could enlarge the scalability requirements > with sentences, such as: > "when applicable must support state aggregation", > "when applicable must support message aggregation", etc. > Is this acceptable to you? I like to see crisp requirements - ones that really will be helpful to the protocol design/selection process - and I think that if we're going to use phrases like "when applicable" we need to add some text (in framework or requirements) stating what "when applicable" means. I also like to think about what happens if you leave the requirement out, or what happens if you leave the mitigating words out. So, what's the *real* difference between "must support message aggregation" and "when applicable must support message aggregation?" > Regarding section 5.5.5, I think that it emphasizes > the need on achieving high network utilization and therefore, > it makes sense to have such a requirement. I'm unconvinced those are real requirements, but will defer to the will of the group on that. Melinda _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Dec 5 08:48:46 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11128 for ; Thu, 5 Dec 2002 08:48:45 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB5Dp7T23827 for nsis-archive@odin.ietf.org; Thu, 5 Dec 2002 08:51:07 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB5Do2v23739; Thu, 5 Dec 2002 08:50:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB5DlAv23610 for ; Thu, 5 Dec 2002 08:47:10 -0500 Received: from sj-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11001 for ; Thu, 5 Dec 2002 08:44:18 -0500 (EST) Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gB5Dl7K0012290; Thu, 5 Dec 2002 05:47:07 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id ABD09098; Thu, 5 Dec 2002 05:47:06 -0800 (PST) Message-Id: <200212051347.ABD09098@mira-sjc5-c.cisco.com> To: john.loughney@nokia.com cc: Ruediger.Geib@t-systems.com, nsis@ietf.org From: Melinda Shore Subject: Re: [NSIS] "split layers" In-Reply-To: Message from john.loughney@nokia.com of "Thu, 05 Dec 2002 12:59:47 +0200." Date: Thu, 05 Dec 2002 08:47:06 -0500 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: , > No, I am actually trying to say the reverse. The requirements should > be general requirements. We should handle the layer split in a > seperate document, which then specifies the more layer-specific > requirements. I think I disagree with that - it's certainly not going to speed up the process, and the layer split almost certainly imposes its own requirements, even if its as simple as "The protocol must support the transmission of blobs of data that are opaque to it." Melinda _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Dec 5 08:51:47 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11241 for ; Thu, 5 Dec 2002 08:51:47 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB5Ds8P24117 for nsis-archive@odin.ietf.org; Thu, 5 Dec 2002 08:54:08 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB5Ds4v24108; Thu, 5 Dec 2002 08:54:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB5DrGv24074 for ; Thu, 5 Dec 2002 08:53:16 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11234 for ; Thu, 5 Dec 2002 08:50:24 -0500 (EST) Received: from esealnt611.al.sw.ericsson.se (esealnt611.al.sw.ericsson.se [153.88.254.68]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id gB5DrDKV007238; Thu, 5 Dec 2002 14:53:13 +0100 (MET) Received: from ESEALNT746.al.sw.ericsson.se ([153.88.251.6]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id YFXD3TFK; Thu, 5 Dec 2002 14:53:13 +0100 Received: by ESEALNT746.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 5 Dec 2002 14:52:27 +0100 Message-ID: <2B06CD3FC17AF64587BC7A7617B230C0CBB7DE@enleent103.nl.eu.ericsson.se> X-Sybari-Trust: 6adc72c6 ca231590 0ab44ba3 00000138 From: "Georgios Karagiannis (ELN)" To: "'Melinda Shore'" , "Georgios Karagiannis (ELN)" Cc: nsis@ietf.org Subject: RE: [NSIS] What is the goal of the analysis draft? Date: Thu, 5 Dec 2002 14:53:11 +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 Melinda You are of course right when saying that the "when applicable" term has to be specified somewhere! Regarding the difference between "must support message aggregation" and "when applicable must support message aggregation?" in my opinion, can be solved, by requiring a "should" in place of a "must". Thus the scalability requirements can be enlarged with sentences such as: "should support state aggregation", "should support message aggregation", etc. Is this acceptable to you? Best Regards, Georgios -----Original Message----- From: Melinda Shore [mailto:mshore@cisco.com] Sent: donderdag 5 december 2002 14:44 To: Georgios Karagiannis (ELN) Cc: nsis@ietf.org Subject: Re: [NSIS] What is the goal of the analysis draft? > Regarding the scalability term I see your point! > Maybe we could enlarge the scalability requirements > with sentences, such as: > "when applicable must support state aggregation", > "when applicable must support message aggregation", etc. > Is this acceptable to you? I like to see crisp requirements - ones that really will be helpful to the protocol design/selection process - and I think that if we're going to use phrases like "when applicable" we need to add some text (in framework or requirements) stating what "when applicable" means. I also like to think about what happens if you leave the requirement out, or what happens if you leave the mitigating words out. So, what's the *real* difference between "must support message aggregation" and "when applicable must support message aggregation?" > Regarding section 5.5.5, I think that it emphasizes > the need on achieving high network utilization and therefore, > it makes sense to have such a requirement. I'm unconvinced those are real requirements, but will defer to the will of the group on that. Melinda _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Dec 5 09:14:49 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12164 for ; Thu, 5 Dec 2002 09:14:49 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB5EHBs25817 for nsis-archive@odin.ietf.org; Thu, 5 Dec 2002 09:17:11 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB5EH6v25790; Thu, 5 Dec 2002 09:17:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB5EGiv25768 for ; Thu, 5 Dec 2002 09:16:44 -0500 Received: from fw11.telekom.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12093 for ; Thu, 5 Dec 2002 09:13:50 -0500 (EST) Received: by fw11.telekom.de; (8.8.8/1.3/10May95) id PAA13721; Thu, 5 Dec 2002 15:12:35 +0100 (MET) Received: from g8pbr.blf01.telekom.de by G8PXB.blf01.telekom.de with ESMTP; Thu, 5 Dec 2002 15:16:23 +0100 Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Thu, 5 Dec 2002 15:16:23 +0100 Message-Id: <9F8582E37B2EE5498E76392AEDDCD3FE23B26D@G8PQD.blf01.telekom.de> From: "Geib, Ruediger" To: mshore@cisco.com Cc: nsis@ietf.org Subject: RE: [NSIS] "split layers" Date: Thu, 5 Dec 2002 15:16:20 +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: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gB5EGiv25769 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: 8bit Thanks Melinda. I share your point of view. Regards, Rüdiger > > John: > > No, I am actually trying to say the reverse. The > > requirements should be general requirements. We > > should handle the layer split in a seperate > > document, which then specifies the more layer-specific > > requirements. > Melinda: > I think I disagree with that - it's certainly not going to > speed up the process, and the layer split almost certainly > imposes its own requirements, even if its as simple as "The > protocol must support the transmission of blobs of data that > are opaque to it." _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Dec 5 09:15:47 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12207 for ; Thu, 5 Dec 2002 09:15:47 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB5EI9F25958 for nsis-archive@odin.ietf.org; Thu, 5 Dec 2002 09:18:09 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB5EI1v25940; Thu, 5 Dec 2002 09:18:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB5EHfv25883 for ; Thu, 5 Dec 2002 09:17:41 -0500 Received: from rsys002a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12162 for ; Thu, 5 Dec 2002 09:14:48 -0500 (EST) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Thu, 5 Dec 2002 14:17:38 -0000 Message-ID: <76C92FBBFB58D411AE760090271ED4181EA6FF@rsys002a.roke.co.uk> From: "Hancock, Robert" To: nsis@ietf.org Date: Thu, 5 Dec 2002 14:17:31 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [NSIS] framework next steps 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, Following events and discussions in Atlanta, here is an updated proposal on what I imagine happening next with the framework i-d. The current (-01) version is historically derived from what was basically a framework for a QoS signalling protocol with more generic parameters, but still a very QoS-centric view on how the protocol should operate. Since then, the range of possible signalling applications has broadened and hence the appropriate thickness of the 'generic' (lower) layer has decreased. At the same time, the attempt to describe all signalling applications as abstractions of QoS signalling has probably stopped being convincing. The proposal for the next framework version is therefore to restructure it around a revised NTLP/NSLP split (see below), describing a) how the NTLP functions as a 'black box' (including interactions with external functions like routing/mobility/some security), and b) how an NSLP for QoS would function the same way (as a sort of 'worked example'). (It's possible that other signalling applications could be added as further examples if they were included in the w.g. charter.) IMHO, if the framework doesn't define this layer split, it isn't clear what it is for and in what sense it isn't either finished or stalled waiting for it to be defined somewhere else. I imagine releasing a framework update before the interim meeting, which would also take account of the other comments that we have got up to now, especially those from Bob & Melinda. (I believe that many of them will be automatically taken care of by the proposed restructuring.) In the meantime, I propose to concentrate on thinking about the engineering aspects of what functions should be either side of the layer boundary (hence other emails). Cheers, Robert H. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Dec 5 09:24:45 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12802 for ; Thu, 5 Dec 2002 09:24:45 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB5ER7L26585 for nsis-archive@odin.ietf.org; Thu, 5 Dec 2002 09:27:07 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB5ER5v26578; Thu, 5 Dec 2002 09:27:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB5EQPv26534 for ; Thu, 5 Dec 2002 09:26:25 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12729 for ; Thu, 5 Dec 2002 09:23:31 -0500 (EST) From: john.loughney@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gB5ERWW19702 for ; Thu, 5 Dec 2002 16:27:32 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 5 Dec 2002 16:26:21 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 5 Dec 2002 16:26:18 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 5 Dec 2002 16:26:18 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] "split layers" Date: Thu, 5 Dec 2002 16:26:17 +0200 Message-ID: Thread-Topic: [NSIS] "split layers" Thread-Index: AcKcZNAcNS1o8ZqtSauOJIfqZPVdkQABVDzw To: Cc: , X-OriginalArrivalTime: 05 Dec 2002 14:26:18.0363 (UTC) FILETIME=[4688C4B0:01C29C6A] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gB5EQPv26535 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: 8bit Hi Melinda, > I think I disagree with that - it's certainly not going to > speed up the process, and the layer split almost certainly > imposes its own requirements, even if its as simple as "The > protocol must support the transmission of blobs of data that > are opaque to it." I agree. What I am saying, though, is that the requirements document is not specifying the protocol split. Do you want the requirements doc to do this? I see this as 2 seperate documents, otherwise one document will be very large. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Dec 5 09:49:54 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14451 for ; Thu, 5 Dec 2002 09:49:54 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB5EqHu29206 for nsis-archive@odin.ietf.org; Thu, 5 Dec 2002 09:52:17 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB5Eq9v29183; Thu, 5 Dec 2002 09:52:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB5EpGv29136 for ; Thu, 5 Dec 2002 09:51:16 -0500 Received: from rsys002a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14382 for ; Thu, 5 Dec 2002 09:48:22 -0500 (EST) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Thu, 5 Dec 2002 14:51:12 -0000 Message-ID: <76C92FBBFB58D411AE760090271ED4181EA702@rsys002a.roke.co.uk> From: "Hancock, Robert" To: nsis@ietf.org Subject: RE: [NSIS] "split layers" Date: Thu, 5 Dec 2002 14:51:10 -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: , Dear all, FWIW my past experience in similar activities to this is that there are unavoidably bound to be many levels of things that could be called "requirements", starting from a) "we would like the world to be a better place" all the way to z) "a foo MUST set the bar flag in baz messages" Different communities are producers and consumers of the requirements at each stage of the lifecycle, and commonly don't have much in common from one stage to the next. Trying to define a single point at which all things called "requirements" are gathered together and agreed in one document is therefore IMHO bound to fail (although I have seen several large scale projects collapse while trying). In particular, I think we have a requirements document which is currently pitched around stage (c) - i.e. "what the rest of the Internet community (certainly outside NSIS w.g., and probably outside the transport area) would like NSIS to achieve". They don't care about things like layer splitting, except in the abstract sense of wanting a 'quality' result. That amount of information clearly isn't enough to design a protocol suite on, but I don't think we were tasked to produce that level of detail as our *first* output anyway. My personal feeling is that - given a limited target as proposed above - the requirements are basically done. To follow up on one of Mike's earlier comments, I wouldn't expect to be able to do protocol design work without being familiar with the requirements and the framework and analysis documents and also most of the RSVP standards, as well as the implications of mobility support protocols (MIP and seamoby), key management and other security protocols, and knowing how routing works. (This is not an ironic comment: protocol design is hard.) It might be that it would be worth gathering all the constraints from these sources into protocol specific requirements documents which we could also check for internal consistency (I don't have a feeling for that), but let's not try to do that as a first step. (Please.) Cheers, Robert H. PS i promise not to send any more emails on this subject (at least until the subject line changes). > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > Sent: 05 December 2002 14:26 > To: mshore@cisco.com > Cc: Ruediger.Geib@t-systems.com; nsis@ietf.org > Subject: RE: [NSIS] "split layers" > > > Hi Melinda, > > > I think I disagree with that - it's certainly not going to > > speed up the process, and the layer split almost certainly > > imposes its own requirements, even if its as simple as "The > > protocol must support the transmission of blobs of data that > > are opaque to it." > > I agree. What I am saying, though, is that the requirements > document is not specifying the protocol split. Do you want > the requirements doc to do this? > > I see this as 2 seperate documents, otherwise one document will > be very large. > > 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 mailnull@www1.ietf.org Thu Dec 5 09:54:54 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14679 for ; Thu, 5 Dec 2002 09:54:54 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB5EvGm29462 for nsis-archive@odin.ietf.org; Thu, 5 Dec 2002 09:57:16 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB5Ev2v29421; Thu, 5 Dec 2002 09:57:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB5EuPv29384 for ; Thu, 5 Dec 2002 09:56:25 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14582 for ; Thu, 5 Dec 2002 09:53:31 -0500 (EST) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id gB5EuLKV028087; Thu, 5 Dec 2002 15:56:21 +0100 (MET) Received: from ESEALNT747.al.sw.ericsson.se ([153.88.251.7]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id YBC3JVS4; Thu, 5 Dec 2002 15:56:21 +0100 Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 5 Dec 2002 15:48:01 +0100 Message-ID: <2B06CD3FC17AF64587BC7A7617B230C0CBB7E2@enleent103.nl.eu.ericsson.se> X-Sybari-Trust: 1ff4919a ca231590 0ab44ba3 00000138 From: "Georgios Karagiannis (ELN)" To: "'john.loughney@nokia.com'" Cc: nsis@ietf.org Subject: RE: [NSIS] "split layers" Date: Thu, 5 Dec 2002 15:56:19 +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 I agree with your proposal! First we will have to define the required functionality split and only then we could produce a document that is specifying the protocol split. This document does not have to be the requirements document. Best regards, Georgios -----Original Message----- From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] Sent: donderdag 5 december 2002 15:26 To: mshore@cisco.com Cc: Ruediger.Geib@t-systems.com; nsis@ietf.org Subject: RE: [NSIS] "split layers" Hi Melinda, > I think I disagree with that - it's certainly not going to > speed up the process, and the layer split almost certainly > imposes its own requirements, even if its as simple as "The > protocol must support the transmission of blobs of data that > are opaque to it." I agree. What I am saying, though, is that the requirements document is not specifying the protocol split. Do you want the requirements doc to do this? I see this as 2 seperate documents, otherwise one document will be very large. 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 mailnull@www1.ietf.org Fri Dec 6 01:22:57 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA16287 for ; Fri, 6 Dec 2002 01:22:57 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB66PQr22959 for nsis-archive@odin.ietf.org; Fri, 6 Dec 2002 01:25:26 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB66POv22951; Fri, 6 Dec 2002 01:25:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB66O9v22920 for ; Fri, 6 Dec 2002 01:24:09 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA16252 for ; Fri, 6 Dec 2002 01:21:08 -0500 (EST) From: john.loughney@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gB66PAW02436 for ; Fri, 6 Dec 2002 08:25:10 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 6 Dec 2002 08:22:35 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 6 Dec 2002 08:22:35 +0200 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 6 Dec 2002 08:22:34 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe013.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 6 Dec 2002 08:22:34 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] "split layers" Date: Fri, 6 Dec 2002 08:22:33 +0200 Message-ID: Thread-Topic: [NSIS] "split layers" Thread-Index: AcKcbe3zyntbijzSQW20QpHDihmK7QAga4rA To: , X-OriginalArrivalTime: 06 Dec 2002 06:22:34.0334 (UTC) FILETIME=[DD4727E0:01C29CEF] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gB66O9v22921 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: 8bit Hi Robert, > My personal feeling is that - given a limited target as > proposed above - the requirements are basically done. To > follow up on one of Mike's earlier comments, I wouldn't > expect to be able to do protocol design work without being > familiar with the requirements and the framework and analysis > documents and also most of the RSVP standards, as well as the > implications of mobility support protocols (MIP and seamoby), > key management and other security protocols, and knowing how > routing works. (This is not an ironic comment: protocol > design is hard.) > > It might be that it would be worth gathering all the > constraints from these sources into protocol specific > requirements documents which we could also check for internal > consistency (I don't have a feeling for that), but let's not > try to do that as a first step. (Please.) Thanks for the proposal, it more crisply states what I was indending to say. My worry about trying has been that we get into an endless loop in defining the requirements (the requirements are dependent on how we break down the layer functionality which are dependent on what we require which are dependent on ...) Does anyone have any suggests, comments or feedback on this approach? John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Mon Dec 9 03:38:10 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01513 for ; Mon, 9 Dec 2002 03:38:10 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB98ei117641 for nsis-archive@odin.ietf.org; Mon, 9 Dec 2002 03:40:44 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB98egv17633; Mon, 9 Dec 2002 03:40:42 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB98dWv17580 for ; Mon, 9 Dec 2002 03:39:32 -0500 Received: from rsys002a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01501 for ; Mon, 9 Dec 2002 03:36:26 -0500 (EST) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Mon, 9 Dec 2002 08:39:19 -0000 Message-ID: <76C92FBBFB58D411AE760090271ED4181EA70F@rsys002a.roke.co.uk> From: "Hancock, Robert" To: nsis@ietf.org Date: Mon, 9 Dec 2002 08:39:11 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [NSIS] 2 slightly more interesting questions about the layer split 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, Please note: this email is not about process issues! (Not that this will stop responses on process issues, I'm sure.) Again as a follow up to the Atlanta session, I'd like to pose 2 further questions about where the NTLP/NSLP split should go. Rather than being about 'what is good basic transport layer functionality?', these questions are much more about 'how should a single transport layer support a diverse set of signalling applications?'. Since being able to do this is a prime motivation behind our work (at least for some of us), this is my justification for calling these questions 'interesting'. I have no idea where the the centre of gravity of working group thinking is on these issues, so I have deliberately phrased them in a one-sided partisan way to see what the response is. I. Are NSLP peers always NTLP peers? ==================================== Background: we think of the NTLP as operating over a limited range (a single 'hop' of some description), but on the other hand, there may be signalling applications where the interested peer nodes are far apart. [A concrete example could be a path through two QoS-aware nodes (A, C) separated by a QoS-unaware NAT (B). So, the QoS-NSLP peers are A and C, but they are more than one NTLP hop apart. This would be either because the NTLP is split at the NAT to re-write addresses, which participates in NTLP security mechanisms to enable it to do so, or because there is a full Midcom-NSLP at B. (Which of these two is possible depends on which layer carries the relevant addressing information, which is still open, but I don't think it changes the general argument.)] So, I propose the answer to the question is 'no'. This could have interesting implications (e.g. for the signalling application multiplexing approach). In particular, where the NSLP depends on a service provided by the NTLP, it means it depends on concatenating that service over several NTLP hops. E2E/fate-sharing arguments might then imply it shouldn't be an NTLP service after all. Are there other ways to model this type of scenario? Do we have to worry about it? II. Should the NTLP provide a state management service? ======================================================= Note this is *not* either of the following questions: *) should state be held in the NTLP and should soft state mechanisms be used to manage it? *) could state be held in an NSLP and could soft state mechanisms be used to manage it? These are protocol design questions, distinctly beyond the framework stage. This is the following choice: a) Should a signalling application be able to invoke the NTLP saying "please create this opaque state blob in my peer node and manage it", or b) Should a signalling application just use the NTLP to get opaque data to its peer, with the state management logic built into the signalling application and parametrised in the data The choice between (a) and (b) obviously has an impact on the NTLP/NSLP divide. I'd like to propose the answer 'No' to see how loud people shout (I know people disagree). Here are some very brief justifications: 1. Different signalling applications might have very different qualitative state management requirements/semantics - e.g. soft (deleted unless explicitly refreshed), soft (deleted unless implicitly refreshed), explicitly deleted by initiator, deleted by responder if it loses contact with the initiator, hard, etc. Defining these semantics could be subtle (especially the error cases). Which paradigm should the NTLP implement? 1a. Even if the qualitative aspects are the same, the quantitive requirements (lifetimes, number of messages that can be dropped etc) over a specific NTLP hop supporting multiple NSLPs might be different. 2. Why is doing this at the NTLP easier than doing it at the NSLP, i.e. what does the integration with transport layer functions buy you? (NB: we could use some guidance from the analysis work to tell us whether using a single soft state refresh mechanism to handle packet loss/route change *and* signalling application specific state is still felt to be a good idea.) Note that we can still implement generic state management functionality within the signalling application layer if we want (as Bob has pointed out previously). 3. Some quick analysis we've done suggests that including state management functions in the NTLP makes the NTLP API more complex (by a factor or 2 or 3). That strikes me as alarming. 4. If you believe the answer 'no' to question (I) above, then the state management service available to the NSLP will actually be the concatenation of several NTLP state management services. This could be hard to define and analyse, and the e2e/fate sharing arguments might be seen as significant here. I'm sure the argument isn't this one-sided. Are there better options than (a) or (b) anyway? Views? Robert H. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Dec 10 08:41:32 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06119 for ; Tue, 10 Dec 2002 08:41:31 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBADhwD29402 for nsis-archive@odin.ietf.org; Tue, 10 Dec 2002 08:43:58 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBADhtv29395; Tue, 10 Dec 2002 08:43:55 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBADgIv29347 for ; Tue, 10 Dec 2002 08:42:18 -0500 Received: from mail.alcatel.be (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05988 for ; Tue, 10 Dec 2002 08:39:19 -0500 (EST) From: sven.van_den_bosch@alcatel.be Received: from bemail04.net.alcatel.be (relay3 [127.0.0.1]) by mail.alcatel.be (8.11.0/8.11.4) with ESMTP id gBADg9415625 for ; Tue, 10 Dec 2002 14:42:09 +0100 Subject: Re: [NSIS] 2 slightly more interesting questions about the layer split To: "Hancock, Robert" Cc: nsis@ietf.org X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: Date: Tue, 10 Dec 2002 14:42:05 +0100 X-MIMETrack: Serialize by Router on BEMAIL04/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at 12/10/2002 14:42:08 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii 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, all, My views on your questions: - NSLP/NTLP peers: I agree with your analysis and answer (no) - state: I am assuming b). In that case, I think that you can come to a situation where the NTLP can fail and recover without causing a failure in the NSLP which may be desirable in some cases. Just my 2cc, Sven. "Hancock, Robert" @ietf.org on 09/12/2002 09:39:11 Sent by: nsis-admin@ietf.org To: nsis@ietf.org cc: Subject: [NSIS] 2 slightly more interesting questions about the layer split Dear all, Please note: this email is not about process issues! (Not that this will stop responses on process issues, I'm sure.) Again as a follow up to the Atlanta session, I'd like to pose 2 further questions about where the NTLP/NSLP split should go. Rather than being about 'what is good basic transport layer functionality?', these questions are much more about 'how should a single transport layer support a diverse set of signalling applications?'. Since being able to do this is a prime motivation behind our work (at least for some of us), this is my justification for calling these questions 'interesting'. I have no idea where the the centre of gravity of working group thinking is on these issues, so I have deliberately phrased them in a one-sided partisan way to see what the response is. I. Are NSLP peers always NTLP peers? ==================================== Background: we think of the NTLP as operating over a limited range (a single 'hop' of some description), but on the other hand, there may be signalling applications where the interested peer nodes are far apart. [A concrete example could be a path through two QoS-aware nodes (A, C) separated by a QoS-unaware NAT (B). So, the QoS-NSLP peers are A and C, but they are more than one NTLP hop apart. This would be either because the NTLP is split at the NAT to re-write addresses, which participates in NTLP security mechanisms to enable it to do so, or because there is a full Midcom-NSLP at B. (Which of these two is possible depends on which layer carries the relevant addressing information, which is still open, but I don't think it changes the general argument.)] So, I propose the answer to the question is 'no'. This could have interesting implications (e.g. for the signalling application multiplexing approach). In particular, where the NSLP depends on a service provided by the NTLP, it means it depends on concatenating that service over several NTLP hops. E2E/fate-sharing arguments might then imply it shouldn't be an NTLP service after all. Are there other ways to model this type of scenario? Do we have to worry about it? II. Should the NTLP provide a state management service? ======================================================= Note this is *not* either of the following questions: *) should state be held in the NTLP and should soft state mechanisms be used to manage it? *) could state be held in an NSLP and could soft state mechanisms be used to manage it? These are protocol design questions, distinctly beyond the framework stage. This is the following choice: a) Should a signalling application be able to invoke the NTLP saying "please create this opaque state blob in my peer node and manage it", or b) Should a signalling application just use the NTLP to get opaque data to its peer, with the state management logic built into the signalling application and parametrised in the data The choice between (a) and (b) obviously has an impact on the NTLP/NSLP divide. I'd like to propose the answer 'No' to see how loud people shout (I know people disagree). Here are some very brief justifications: 1. Different signalling applications might have very different qualitative state management requirements/semantics - e.g. soft (deleted unless explicitly refreshed), soft (deleted unless implicitly refreshed), explicitly deleted by initiator, deleted by responder if it loses contact with the initiator, hard, etc. Defining these semantics could be subtle (especially the error cases). Which paradigm should the NTLP implement? 1a. Even if the qualitative aspects are the same, the quantitive requirements (lifetimes, number of messages that can be dropped etc) over a specific NTLP hop supporting multiple NSLPs might be different. 2. Why is doing this at the NTLP easier than doing it at the NSLP, i.e. what does the integration with transport layer functions buy you? (NB: we could use some guidance from the analysis work to tell us whether using a single soft state refresh mechanism to handle packet loss/route change *and* signalling application specific state is still felt to be a good idea.) Note that we can still implement generic state management functionality within the signalling application layer if we want (as Bob has pointed out previously). 3. Some quick analysis we've done suggests that including state management functions in the NTLP makes the NTLP API more complex (by a factor or 2 or 3). That strikes me as alarming. 4. If you believe the answer 'no' to question (I) above, then the state management service available to the NSLP will actually be the concatenation of several NTLP state management services. This could be hard to define and analyse, and the e2e/fate sharing arguments might be seen as significant here. I'm sure the argument isn't this one-sided. Are there better options than (a) or (b) anyway? Views? Robert H. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Dec 10 14:11:54 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18105 for ; Tue, 10 Dec 2002 14:11:54 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBAJENo21842 for nsis-archive@odin.ietf.org; Tue, 10 Dec 2002 14:14:23 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBAJEJv21835; Tue, 10 Dec 2002 14:14:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBAJDTv21792 for ; Tue, 10 Dec 2002 14:13:29 -0500 Received: from arb-exchange1.cetaceannetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18058 for ; Tue, 10 Dec 2002 14:10:29 -0500 (EST) Received: by mail.cetaceannetworks.com with Internet Mail Service (5.5.2653.19) id ; Tue, 10 Dec 2002 14:02:43 -0500 Message-ID: <6D8664171C38D511B5AD0002B325CE66A935BF@mail.cetaceannetworks.com> From: "Freytsis, Ilya" To: "'Hancock, Robert'" , nsis@ietf.org Subject: RE: [NSIS] 2 slightly more interesting questions about the layer split Date: Tue, 10 Dec 2002 14:02:40 -0500 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: , Robert, These are very good questions. I think the following principles are important for the layer separation: - The less interdependency between layers the better - The simpler (but meaningful) service lower layer delivers the better It seems to me that answer NO (the first question) and choice B (the second question) are inline with these principles. Ilya -----Original Message----- From: Hancock, Robert [mailto:robert.hancock@roke.co.uk] Sent: Monday, December 09, 2002 3:39 AM To: nsis@ietf.org Subject: [NSIS] 2 slightly more interesting questions about the layer split Dear all, Please note: this email is not about process issues! (Not that this will stop responses on process issues, I'm sure.) Again as a follow up to the Atlanta session, I'd like to pose 2 further questions about where the NTLP/NSLP split should go. Rather than being about 'what is good basic transport layer functionality?', these questions are much more about 'how should a single transport layer support a diverse set of signalling applications?'. Since being able to do this is a prime motivation behind our work (at least for some of us), this is my justification for calling these questions 'interesting'. I have no idea where the the centre of gravity of working group thinking is on these issues, so I have deliberately phrased them in a one-sided partisan way to see what the response is. I. Are NSLP peers always NTLP peers? ==================================== Background: we think of the NTLP as operating over a limited range (a single 'hop' of some description), but on the other hand, there may be signalling applications where the interested peer nodes are far apart. [A concrete example could be a path through two QoS-aware nodes (A, C) separated by a QoS-unaware NAT (B). So, the QoS-NSLP peers are A and C, but they are more than one NTLP hop apart. This would be either because the NTLP is split at the NAT to re-write addresses, which participates in NTLP security mechanisms to enable it to do so, or because there is a full Midcom-NSLP at B. (Which of these two is possible depends on which layer carries the relevant addressing information, which is still open, but I don't think it changes the general argument.)] So, I propose the answer to the question is 'no'. This could have interesting implications (e.g. for the signalling application multiplexing approach). In particular, where the NSLP depends on a service provided by the NTLP, it means it depends on concatenating that service over several NTLP hops. E2E/fate-sharing arguments might then imply it shouldn't be an NTLP service after all. Are there other ways to model this type of scenario? Do we have to worry about it? II. Should the NTLP provide a state management service? ======================================================= Note this is *not* either of the following questions: *) should state be held in the NTLP and should soft state mechanisms be used to manage it? *) could state be held in an NSLP and could soft state mechanisms be used to manage it? These are protocol design questions, distinctly beyond the framework stage. This is the following choice: a) Should a signalling application be able to invoke the NTLP saying "please create this opaque state blob in my peer node and manage it", or b) Should a signalling application just use the NTLP to get opaque data to its peer, with the state management logic built into the signalling application and parametrised in the data The choice between (a) and (b) obviously has an impact on the NTLP/NSLP divide. I'd like to propose the answer 'No' to see how loud people shout (I know people disagree). Here are some very brief justifications: 1. Different signalling applications might have very different qualitative state management requirements/semantics - e.g. soft (deleted unless explicitly refreshed), soft (deleted unless implicitly refreshed), explicitly deleted by initiator, deleted by responder if it loses contact with the initiator, hard, etc. Defining these semantics could be subtle (especially the error cases). Which paradigm should the NTLP implement? 1a. Even if the qualitative aspects are the same, the quantitive requirements (lifetimes, number of messages that can be dropped etc) over a specific NTLP hop supporting multiple NSLPs might be different. 2. Why is doing this at the NTLP easier than doing it at the NSLP, i.e. what does the integration with transport layer functions buy you? (NB: we could use some guidance from the analysis work to tell us whether using a single soft state refresh mechanism to handle packet loss/route change *and* signalling application specific state is still felt to be a good idea.) Note that we can still implement generic state management functionality within the signalling application layer if we want (as Bob has pointed out previously). 3. Some quick analysis we've done suggests that including state management functions in the NTLP makes the NTLP API more complex (by a factor or 2 or 3). That strikes me as alarming. 4. If you believe the answer 'no' to question (I) above, then the state management service available to the NSLP will actually be the concatenation of several NTLP state management services. This could be hard to define and analyse, and the e2e/fate sharing arguments might be seen as significant here. I'm sure the argument isn't this one-sided. Are there better options than (a) or (b) anyway? Views? Robert H. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Dec 11 12:06:15 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12809 for ; Wed, 11 Dec 2002 12:06:15 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBBH8g008866 for nsis-archive@odin.ietf.org; Wed, 11 Dec 2002 12:08:42 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBBH8ev08840; Wed, 11 Dec 2002 12:08:40 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBBH5Av07885 for ; Wed, 11 Dec 2002 12:05:10 -0500 Received: from tokyo.ccrle.nec.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12694 for ; Wed, 11 Dec 2002 12:02:09 -0500 (EST) Received: from imap.heidelberg.ccrle.nec.de (imap [192.168.102.11]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id gBBH4oF49167; Wed, 11 Dec 2002 18:04:50 +0100 (CET) (envelope-from brunner@ccrle.nec.de) Received: from [192.168.102.207] (marcus.heidelberg.ccrle.nec.de [192.168.102.207]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 156DD28A45; Wed, 11 Dec 2002 18:02:27 +0100 (CET) Date: Wed, 11 Dec 2002 18:02:27 +0100 From: Marcus Brunner Reply-To: brunner@ccrle.nec.de To: "Georgios Karagiannis (ELN)" , "'Melinda Shore'" Cc: nsis@ietf.org Subject: RE: [NSIS] What is the goal of the analysis draft? Message-ID: <28959121.1039629747@[192.168.102.207]> In-Reply-To: <2B06CD3FC17AF64587BC7A7617B230C0CBB7DE@enleent103.nl.eu.ericsson.se> References: <2B06CD3FC17AF64587BC7A7617B230C0CBB7DE@enleent103.nl.eu.ericsso n.se> X-Mailer: Mulberry/2.2.0 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline 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 IMHO state aggregation is already a solution to a problem. And I definitly don't want to prescribe a solution with that type of requirements draft. Anothger solution could be avoid state instead of aggregate it. Marcus --On Donnerstag, 5. Dezember 2002 14:53 +0100 "Georgios Karagiannis (ELN)" wrote: > Hi Melinda > > You are of course right when saying that the "when applicable" > term has to be specified somewhere! > > Regarding the difference between "must support message aggregation" and > "when applicable must support message aggregation?" > in my opinion, can be solved, by requiring a "should" in place of a > "must". Thus the scalability requirements can be enlarged with sentences > such as: "should support state aggregation", > "should support message aggregation", etc. > Is this acceptable to you? > > Best Regards, > Georgios > > -----Original Message----- > From: Melinda Shore [mailto:mshore@cisco.com] > Sent: donderdag 5 december 2002 14:44 > To: Georgios Karagiannis (ELN) > Cc: nsis@ietf.org > Subject: Re: [NSIS] What is the goal of the analysis draft? > > >> Regarding the scalability term I see your point! >> Maybe we could enlarge the scalability requirements >> with sentences, such as: >> "when applicable must support state aggregation", >> "when applicable must support message aggregation", etc. >> Is this acceptable to you? > > I like to see crisp requirements - ones that really will be > helpful to the protocol design/selection process - and I > think that if we're going to use phrases like "when > applicable" we need to add some text (in framework or > requirements) stating what "when applicable" means. I also > like to think about what happens if you leave the > requirement out, or what happens if you leave the mitigating > words out. So, what's the *real* difference between "must > support message aggregation" and "when applicable must > support message aggregation?" > >> Regarding section 5.5.5, I think that it emphasizes >> the need on achieving high network utilization and therefore, >> it makes sense to have such a requirement. > > I'm unconvinced those are real requirements, but will defer > to the will of the group on that. > > Melinda > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis -------------------------------------- Dr. Marcus Brunner Network Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ Phone: +49 (0) 6221 905 11 29 personal home page: http://www.brubers.org/marcus _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Dec 12 04:06:45 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17218 for ; Thu, 12 Dec 2002 04:06:45 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBC99L604422 for nsis-archive@odin.ietf.org; Thu, 12 Dec 2002 04:09:21 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBC99Jv04415; Thu, 12 Dec 2002 04:09:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBBI2Pv11236 for ; Wed, 11 Dec 2002 13:02:25 -0500 Received: from entcl9.et.tu-dresden.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14735 for ; Wed, 11 Dec 2002 12:59:25 -0500 (EST) Received: (from itc18@localhost) by entcl9.et.tu-dresden.de (8.11.3/8.11.3/SuSE Linux 8.11.1-0.5) id gBBI5Z604318; Wed, 11 Dec 2002 19:05:35 +0100 Date: Wed, 11 Dec 2002 19:05:35 +0100 Message-Id: <200212111805.gBBI5Z604318@entcl9.et.tu-dresden.de> To: nsis@ietf.org From: itc18@ifn.et.tu-dresden.de Subject: [NSIS] ITC 18 - Call for Papers 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: , Our apologies for receiving multiple copies of this email. REMINDER: The deadline (31 Dec) for ITC18 paper submission is           approaching soon.           Please submit your paper in time. CALL FOR PAPERS - CALL FOR PAPERS - CALL FOR PAPERS - CALL FOR PAPERS       +-----------------------------------------------+       |    18th International TELETRAFFIC CONGRESS    |       |   Haus am Köllnischen Park, Berlin, Germany   |       |        31 August - 5 September 2003           |       |                                               |       | "Providing QoS in Heterogeneous Environments" |       |            http://www.ITC18.org               |       +-----------------------------------------------+ CALL FOR PAPERS - CALL FOR PAPERS - CALL FOR PAPERS - CALL FOR PAPERS ORGANIZATIONS AND HISTORY International Advisory Committee http://www.i-teletraffic.org/ ITG - Information Technology Society in the VDE http://www.vde.com/vde/html/e/fach/itg/itg.htm The ITC, founded in 1955, provides, through regular, now bi-annual congresses, the main international forum for teletraffic research and engineering. The purpose of the ITC is to stimulate the development and application of teletraffic theory for planning, engineering, managing and administrating telecommunication networks. The analysis and control of traffic phenomena in such networks require measurements, forecasts, as well as network management algorithms. The ITC gathers teletraffic experts from research organizations, universities, manufacturers, network operators and international technical organizations yielding a well-balanced contribution from theory and application. ITCs are organized so that researchers, engineers, and administrators from telcos and data network operators can interact and benefit from discussions and exchange of ideas. The ITC also benefits from the social environment which allows for the creation of new personal contacts between delegates. CONFERENCE CITY After 33 years, the ITC community meets again in Germany - in Berlin, the old and new capital, a four million people meeting place of the East and the West in the center of Europe. Berlin is a city in transition, one that is not always easy to understand, and which is often quite difficult to describe. However, no other city of Germany reflects the historical events of the last few years to the extent Berlin does. More information: http://www.berlin.de/english CONFERENCE VENUE Close to the river Spree in the center of Berlin, the "Haus am Köllnischen Park"is located just a few minutes walking distance from famous places such as Alexanderplatz, Humboldt University, Gendarmenmarkt, Reichstag or Brandenburger Tor. "PROVIDING QOS IN HETEROGENEOUS EINVIRONMENTS" The ITC 18 will be held in a transient phase where IP packet-switched architectures migrate from being data networks only to also substituting traditional circuit-switched networks. Papers are welcome tackling the following topics: NETWORK ARCHITECTURES AND TECHNOLOGIES - Next generation networks - Broadband transport networks - Access networks - Wireless networks and wireless LANs - Heterogeneous networks and ubiquitous communication - Web technologies - Voice over IP - Ad hoc and peer to peer networking - Communication protocols TRAFFIC CONTROL AND ENGINEERING - Traffic engineering - Quality of service provisioning - Service pricing - Overload control - Traffic management - QoS in multi-provider networks - Service-aware admission control - Traffic conditioning - Routing - Mobility management and signalling - Network planning and optimization - Network management - Reliability and Survivability METHODS AND TOOLS - Traffic characterization and modelling - Performance evaluation - Queueing theory - Scheduling - Simulation methodology - Traffic and performance measurements IMPORTANT DATES Full paper due                   : 31 December 2002 Notification of acceptance mailed: 16 April 2003 Camera ready paper due           :  1 June 2003 SUBMISSION OF PAPERS Papers should not exceed 15 double-spaced pages (about 5000 words, font 12pt), have an abstract of 100-200 words, and be original material not previously published. The title page should contain the authors' names, affiliation and contact details. The corresponding author must be indicated. Only electronic submission via the ITC18 homepage will be arranged. Further information can be obtained on the ITC18 homepage via http://www.ITC18.org. CONFERENCE ORGANIZATION AND CONTACT ADDRESS ITC 18 VDE Conference Services Stresemannallee 15 D-60596 Frankfurt/Main, Germany Phone: +49 69 6308-202 Fax  : +49 69 9631-5213 email: vde-conferences@vde.com COMMITTEES EXECUTIVE COMMITTEE Chair            : Joachim Claus, Deutsche Telekom AG, Bonn Secretariat      : Volker Schanz, ITG/VDE, Frankfurt Conference Office: Rupert Rompel, VDE, Frankfurt TECHNICAL PROGRAMME COMMITTEE Chairs: Joachim Charzinski, Siemens, Munich Ralf Lehnert, Dresden University of Technology Phuoc Tran-Gia, University of Würzburg Carmelita Görg, University of Bremen (Tutorials Chair) INTERNATIONAL TPC                NATIONAL TPC Marco Ajmone Marsan, Italy       Dieter Baum, University of Trier Åke Arvidsson, Sweden            Matthias Baumann, Dresden University     Khalid Begain, United Kingdom    of Technology Chris Blondia, Belgium           Gunter Bolch, University of                   Onno Boxma, The Netherlands      Erlangen-Nuremberg Herwig Bruneel, Belgium          Andreas Brandt, Humboldt University Olga Casals, Spain               Joachim Charzinski, Siemens AG Prosper Chemouil, France         Jörg Eberspächer, Munich University of       Laurie Cuthbert, United Kingdom  Technology Hermann de Meer, United Kingdom  Anja Feldmann, Saarland University Edmundo de Souza e Silva, Brazil Wolfgang Fischer, Cisco GmbH Zbigniew Dziong, USA             Carmelita Görg, University of Bremen Khaled Elsayed, Egypt            Franz Hartleb, T-Systems GmbH Peder Emstad, Norway             Christoph Herrmann, Philips Research David Everitt, Australia         Ulrich Killat, Technical University of Serge Fdida, France              Hamburg-Harburg Georges Fiche, France            Udo Krieger, T-Systems GmbH Markus Fiedler, Sweden           Paul J. Kühn, University of Stuttgart Luigi Fratta, Italy              Ralf Lehnert, Dresden University of H. Richard Gail, USA             Technology Richard Harris, Australia        Georg Rößler, Tenovis GmbH&Co. KG Frank Hübner-Szabo de Bucs, USA  Stefan Schneeberger, Siemens AG Boudewijn Haverkort, The Netherlands  Hans-Peter Schwefel, Siemens AG Villy Baek Iversen, Denmark      Michael Söllner, Lucent Technologies Konosuke Kawashima, Japan        GmbH Peter Key, United Kingdom        Michael Tangemann, Alcatel AG Daniel Kofman, USA               Sandra Tartarelli, NEC GmbH Yonathan Levy, USA               Phuoc Tran-Gia, University of Würzburg Xiong Jiang Liang, China         Kurt Tutschku, University of Würzburg Karl Lindberger, Sweden          Bernhard Walke, Aachen University of Michel Mandjes, The Netherlands  Technology Ian Marshall, United Kingdom     Ulrich Wellens, Vodafone GmbH Debasis Mitra, USA               Albert Weller, T-Mobile GmbH Sandor Molnár, Hungary           Adam Wolisz, Berlin University of Jorge Moreira de Souza, Brazil   Technology Arne A. Nilsson, USA             Martina Zitterbart, University of Ilkka Norros, Finland            Karlsruhe Baron Peterssen, South Africa Michal Pioro, Poland Jim Roberts, France Matthew Roughan, USA Hiroshi Saito, Japan Shohei Sato, Japan Danny Tsang, Hong Kong Hans van den Berg, The Netherlands Rob van der Mei, The Netherlands Manuel Villen-Altamirano, Spain Jorma Virtamo, Finland Y.T. Wang, USA Pat Wirth, USA Jim Yan, Canada Hideaki Yoshino, Japan Moshe Zukerman, Australia _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Dec 12 04:42:35 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18075 for ; Thu, 12 Dec 2002 04:42:35 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBC9jC306873 for nsis-archive@odin.ietf.org; Thu, 12 Dec 2002 04:45:12 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBC9j9v06862; Thu, 12 Dec 2002 04:45:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBC9iAv06790 for ; Thu, 12 Dec 2002 04:44:10 -0500 Received: from rsys002a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18029 for ; Thu, 12 Dec 2002 04:41:02 -0500 (EST) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Thu, 12 Dec 2002 09:43:57 -0000 Message-ID: <76C92FBBFB58D411AE760090271ED4181EA72B@rsys002a.roke.co.uk> From: "Hancock, Robert" To: nsis@ietf.org Date: Thu, 12 Dec 2002 09:43:55 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [NSIS] A 3rd slightly more interesting question about the layer split (w arning: involves NATs) 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, Here is a third question about the layer split which also comes into the 'quite interesting' category (in that the answer is not obvious, but the issues are known and relatively easy to summarise). Should the NTLP explicitly contain flow addressing information? =============================================================== Background: the current framework suggests it should (sections 3.3.5 and 4.5.1), on which Melinda (msg http://www1.ietf.org/mail-archive/working-groups/nsis/current/msg01842.html, reply http://www1.ietf.org/mail-archive/working-groups/nsis/current/msg02178.html) and Bob (http://www1.ietf.org/mail-archive/working-groups/nsis/current/msg02224.html, in several places) have commented; the NSIS-through-NATs question (http://www1.ietf.org/mail-archive/working-groups/nsis/current/msg01715.html) and policy-forwarding (http://www1.ietf.org/mail-archive/working-groups/nsis/current/msg02285.html) questions are also relevant. I now think that the current framework assumption is wrong in at least minor details, but here is the summary anyway. It's clear that messages from our protocols will be stuffed with addressing and related information (ports, flow labels etc). There are two sides to this information: 1. It defines what packets the signalling messages are about (i.e. it's an input to the packet classifier). Call this 'packet classification information' (PCI). 2. It is relevant in policy-based forwarding decisions (i.e. you need to use it to make sure the signalling messages follow the same path as data packets), and may also need to get rewritten by NATs (consistently with how they are rewriting data packet headers). Call this 'flow routing information' (FRI). Probably, the FRI is a subset of the PCI. (I think it would be just SA+DA+[FL|(PI+[(SP+DP)|SPI])], if that isn't too terse. Maybe DSCP as well.) It's clear (I think) that PCI could get arbitrarily complicated but is also relevant only to the signalling application, i.e. the NTLP shouldn't worry about this stuff. The question is, should we separate out the FRI and carry it separately in the NTLP. I think this gives some benefits for some problems, although it probably isn't a perfect solution to those problems. Here is a bag of issues: 1. You could do provide NAT and policy forwarding handling for signalling applications even at nodes which were unaware of specific signalling applications. My perception is that this is a major point for us to worry about these days (was it even on the horizon when RSVP was designed?). Otherwise, deploying a new signalling application (even a simple one) would require writing NAT ALG functionality for it and getting it into every on-path device. 2. For (1) to be true, you need to ensure that *all* address information needed by a signalling application is (a) in the FRI, and (b) arranged so it can easily be processed without understanding the rest of the signalling message. If we fail on (a), we have gained (and lost) nothing compared to carrying the information only inside the signalling application. But it seems that at least for unicast flows, achieving (a) for the majority of signalling applications is not hard. The same reasoning almost certainly *doesn't* apply to fully generic multicast handling. I don't see (b) as a problem. Basically, the NTLP could contain a field saying 'here are some fields, treat them like you would treat the same fields in an ordinary packet header'. 3. We have to worry about the encapsulation and security issues for the NTLP to make sure that the FRI can be manipulated easily but not too easily. 4. Some people may start to use higher layer fields for NAT or policy routing which aren't in our (fixed) FRI. In that case, again we've gained (and lost) nothing. My perception however is that this is not the long-term trend (even the doom-mongers discussing IPv6 NAT scenarios are mainly talking about straight address-address mapping rather than address sharing, which is where the real problems come). 5. There are probably other issues as well. Summary: I think we have a fairly clear tradeoff here, between COST: some additional complexity in the NTLP, making signalling applications dependent on some NTLP data fields BENEFIT: for a one-off cost we can handle a high proportion of nat/policy problems for a high proportion of [unicast] signalling applications. ('high proportion' may or may not be 100%.) How do people see this tradeoff? Cheers, Robert H. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Dec 12 08:51:57 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23392 for ; Thu, 12 Dec 2002 08:51:57 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBCDsOQ20396 for nsis-archive@odin.ietf.org; Thu, 12 Dec 2002 08:54:24 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBCDsMv20388; Thu, 12 Dec 2002 08:54:22 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBCDrZv20345 for ; Thu, 12 Dec 2002 08:53:35 -0500 Received: from tokyo.ccrle.nec.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23370 for ; Thu, 12 Dec 2002 08:50:36 -0500 (EST) Received: from imap.heidelberg.ccrle.nec.de (imap [192.168.102.11]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id gBCDr7F86142; Thu, 12 Dec 2002 14:53:32 +0100 (CET) (envelope-from brunner@ccrle.nec.de) Received: from [192.168.102.207] (marcus.heidelberg.ccrle.nec.de [192.168.102.207]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 49F9218693; Thu, 12 Dec 2002 14:50:21 +0100 (CET) Date: Thu, 12 Dec 2002 14:50:22 +0100 From: Marcus Brunner Reply-To: brunner@ccrle.nec.de To: john.loughney@nokia.com, nsis@ietf.org Subject: Re: [NSIS] Interim Meeting Message-ID: <103843469.1039704622@[192.168.102.207]> In-Reply-To: References: X-Mailer: Mulberry/2.2.0 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline 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 --On Dienstag, 3. Dezember 2002 11:10 +0200 john.loughney@nokia.com wrote: > Hi all, > > I propose the week of February 10th - 14th for the NSIS interim meeting. > We have one offer to host the meeting at Columbia University. Allison > Mankin has also said that she may be able to host the meeting in > New Jersey. > If possible also include the Saturday (enable to get cheaper flights from Europe. > Please let me know if this is acceptable to those interested in > participating. I would like to spend the bulk of the time working on an > initial cut of a solution. Another suggest topic, that could be held > towards the end of the meeting would be interactions with mobility. I would think this is part of the first goal anyway. Marcus > thanks, > John > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis -------------------------------------- Dr. Marcus Brunner Network Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ Phone: +49 (0) 6221 905 11 29 personal home page: http://www.brubers.org/marcus _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Fri Dec 13 08:56:15 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23424 for ; Fri, 13 Dec 2002 08:56:15 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBDDwhl17907 for nsis-archive@odin.ietf.org; Fri, 13 Dec 2002 08:58:43 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBDDwev17889; Fri, 13 Dec 2002 08:58:41 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBDDvrv17778 for ; Fri, 13 Dec 2002 08:57:53 -0500 Received: from mgw-x1.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23323 for ; Fri, 13 Dec 2002 08:54:54 -0500 (EST) From: john.loughney@nokia.com Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gBDDv7013028 for ; Fri, 13 Dec 2002 15:57:07 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Fri, 13 Dec 2002 15:57:40 +0200 Received: from esebe011.NOE.Nokia.com ([172.21.138.50]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 13 Dec 2002 15:57:40 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe011.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 13 Dec 2002 15:57:40 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Fri, 13 Dec 2002 15:57:39 +0200 Message-ID: Thread-Topic: [NSIS] 2 slightly more interesting questions about the layer split Thread-Index: AcKggNH6URWrDENHRpO5i2WfRK1eFQCLpW+w To: X-OriginalArrivalTime: 13 Dec 2002 13:57:40.0800 (UTC) FILETIME=[9A177400:01C2A2AF] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gBDDvrv17779 Subject: [NSIS] Updated milestones 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: 8bit Hi all, I've updated the milestones for NSIS. They can be viewed here: http://www.ietf.org/html.charters/nsis-charter.html These milestones are still with the old charter. My intention is that we work towards these goals at present. best regards, John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Fri Dec 13 09:13:42 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23846 for ; Fri, 13 Dec 2002 09:13:42 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBDEGAM19479 for nsis-archive@odin.ietf.org; Fri, 13 Dec 2002 09:16:10 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBDEG7v19469; Fri, 13 Dec 2002 09:16:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBDEF2v19427 for ; Fri, 13 Dec 2002 09:15:02 -0500 Received: from tms001bb.han.telia.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23833 for ; Fri, 13 Dec 2002 09:12:03 -0500 (EST) From: Anders.P.Bergsten@telia.se Received: from tms041mb.han.telia.se ([131.115.230.167]) by tms001bb.han.telia.se with Microsoft SMTPSVC(5.0.2195.2966); Fri, 13 Dec 2002 15:14:58 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] Updated milestones Date: Fri, 13 Dec 2002 15:14:58 +0100 Message-ID: <1BF8A5964E4EFA41A094B835FCA71291F7B8CC@TMS041MB.tcad.telia.se> Thread-Topic: [NSIS] 2 slightly more interesting questions about the layer split Thread-Index: AcKggNH6URWrDENHRpO5i2WfRK1eFQCLpW+wAABTNfA= To: , X-OriginalArrivalTime: 13 Dec 2002 14:14:58.0777 (UTC) FILETIME=[04C62C90:01C2A2B2] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gBDEF2v19428 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: 8bit John, not sure if you sent out draft of the charter before, in that case I apologize for the late reply. Otherwise, concerning: DEC 03 If criteria were met, submit 'Next Step QoS Signaling' as a standards track RFC Does this mean that a protocol should be designed (/revised design of RSVP) until dec-03 or an architect or what? The goal/milestone were a bit vague about what "Next Step QoS Signaling" refers to. Furthermore, there are two wg id's (Threats, Security properties) that does not have an associated goal/milestone. Not that I am fully up-to-date with NSIS activities, but is the intention to move this to informational or merge them with framework/analysis document? If the intention is to move them to informational then they should go into goal/milestone, otherwise, should they still be a wg item? Best regards, Anders > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > Sent: den 13 december 2002 14:58 > To: nsis@ietf.org > Subject: [NSIS] Updated milestones > > > Hi all, > > I've updated the milestones for NSIS. They can be viewed here: > > http://www.ietf.org/html.charters/nsis-charter.html > > These milestones are still with the old charter. My intention > is that we work towards these goals at present. > > best regards, > 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 mailnull@www1.ietf.org Fri Dec 13 09:21:37 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24077 for ; Fri, 13 Dec 2002 09:21:37 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBDEO5E19787 for nsis-archive@odin.ietf.org; Fri, 13 Dec 2002 09:24:05 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBDEO2v19772; Fri, 13 Dec 2002 09:24:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBDENvv19750 for ; Fri, 13 Dec 2002 09:23:57 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24053 for ; Fri, 13 Dec 2002 09:20:58 -0500 (EST) From: john.loughney@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gBDEPGp03195 for ; Fri, 13 Dec 2002 16:25:16 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 13 Dec 2002 16:23:53 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 13 Dec 2002 16:23:53 +0200 Received: from esebe017.NOE.Nokia.com ([172.21.138.56]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 13 Dec 2002 16:23:52 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe017.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 13 Dec 2002 16:23:52 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] Updated milestones Date: Fri, 13 Dec 2002 16:23:51 +0200 Message-ID: Thread-Topic: [NSIS] 2 slightly more interesting questions about the layer split Thread-Index: AcKggNH6URWrDENHRpO5i2WfRK1eFQCLpW+wAABTNfAAAFtk8A== To: , X-OriginalArrivalTime: 13 Dec 2002 14:23:52.0080 (UTC) FILETIME=[42A5C100:01C2A2B3] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gBDENvv19751 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: 8bit Hi Anders, > not sure if you sent out draft of the charter before, in that > case I apologize for the late reply. Otherwise, concerning: > > DEC 03 If criteria were met, submit 'Next Step QoS > Signaling' as a standards track RFC > > Does this mean that a protocol should be designed (/revised > design of RSVP) until dec-03 or an architect or what? The > goal/milestone were a bit vague about what "Next Step QoS > Signaling" refers to. This work would be the protocol work, based on RSVP - a RSVPv2, so to speak. So, working with the existing charter, the plan is to try to get an initial draft out by March. > Furthermore, there are two wg id's (Threats, Security > properties) that does not have an associated goal/milestone. > Not that I am fully up-to-date with NSIS activities, but is > the intention to move this to informational or merge them > with framework/analysis document? If the intention is to move > them to informational then they should go into > goal/milestone, otherwise, should they still be a wg item? Yes, of course. The charter is undergoing some revision as we speak. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Fri Dec 13 10:27:51 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25701 for ; Fri, 13 Dec 2002 10:27:51 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBDFUKk23608 for nsis-archive@odin.ietf.org; Fri, 13 Dec 2002 10:30:20 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBDFUEv23599; Fri, 13 Dec 2002 10:30:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBDFTIv23532 for ; Fri, 13 Dec 2002 10:29:18 -0500 Received: from sj-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25653 for ; Fri, 13 Dec 2002 10:26:18 -0500 (EST) Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gBDFTEFp014899; Fri, 13 Dec 2002 07:29:14 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id ABJ56410; Fri, 13 Dec 2002 07:29:13 -0800 (PST) Message-Id: <200212131529.ABJ56410@mira-sjc5-c.cisco.com> To: john.loughney@nokia.com cc: nsis@ietf.org From: Melinda Shore Subject: Re: [NSIS] Updated milestones In-Reply-To: Message from john.loughney@nokia.com of "Fri, 13 Dec 2002 15:57:39 +0200." Date: Fri, 13 Dec 2002 10:29:13 -0500 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: , What is the second MAR 03 goal ("'Next Step QoS Signaling'")? Is that a framework document? Thanks, Melinda _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Fri Dec 13 10:41:37 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26304 for ; Fri, 13 Dec 2002 10:41:37 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBDFi7f24971 for nsis-archive@odin.ietf.org; Fri, 13 Dec 2002 10:44:07 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBDFi4v24964; Fri, 13 Dec 2002 10:44:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBDFhJv24913 for ; Fri, 13 Dec 2002 10:43:19 -0500 Received: from rsys002a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26206 for ; Fri, 13 Dec 2002 10:40:19 -0500 (EST) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Fri, 13 Dec 2002 15:43:14 -0000 Message-ID: <76C92FBBFB58D411AE760090271ED4181EA738@rsys002a.roke.co.uk> From: "Hancock, Robert" To: "'Melinda Shore'" , john.loughney@nokia.com Cc: nsis@ietf.org Subject: RE: [NSIS] Updated milestones Date: Fri, 13 Dec 2002 15:43:11 -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: , eek! another one? (compared to the 'Done' i-d and July informational, which i assume is the one we are currently working on.) i can't currently decide how to interpret the analysis/framework 'charter criteria' mentioned in the milestones, since the existing charter implies we are going to evaluate RSVP to see if it is up to the job (and i'm not sure how/where this is taking place), and the charter presented in Atlanta doesn't mention this 'hurdle' the same way. so, i'm not really sure how to interpret the milestones in detail without updated charter text. cheers, robert h. > -----Original Message----- > From: Melinda Shore [mailto:mshore@cisco.com] > Sent: 13 December 2002 15:29 > To: john.loughney@nokia.com > Cc: nsis@ietf.org > Subject: Re: [NSIS] Updated milestones > > > What is the second MAR 03 goal ("'Next Step QoS > Signaling'")? Is that a framework document? > > Thanks, > > Melinda > _______________________________________________ > 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 mailnull@www1.ietf.org Fri Dec 13 12:31:52 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29192 for ; Fri, 13 Dec 2002 12:31:52 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBDHYNs31267 for nsis-archive@odin.ietf.org; Fri, 13 Dec 2002 12:34:23 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBDHYJv31244; Fri, 13 Dec 2002 12:34:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBDHX7v31209 for ; Fri, 13 Dec 2002 12:33:07 -0500 Received: from tokyo.ccrle.nec.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29115 for ; Fri, 13 Dec 2002 12:30:05 -0500 (EST) Received: from imap.heidelberg.ccrle.nec.de (imap [192.168.102.11]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id gBDHX3F37487 for ; Fri, 13 Dec 2002 18:33:03 +0100 (CET) (envelope-from brunner@ccrle.nec.de) Received: from [192.168.102.207] (marcus.heidelberg.ccrle.nec.de [192.168.102.207]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 3DD6F2B1A3 for ; Fri, 13 Dec 2002 18:30:33 +0100 (CET) Date: Fri, 13 Dec 2002 18:30:33 +0100 From: Marcus Brunner Reply-To: brunner@ccrle.nec.de To: nsis@ietf.org Message-ID: <30942953.1039804233@[192.168.102.207]> X-Mailer: Mulberry/2.2.0 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Subject: [NSIS] draft on functional protocol req 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 Following the discussion of the list on requierements, where some people think they are too abstract and high level I put together a list, which might help to go forward. I just now subitted an draft on NSIS Transport Layer Protocol (NTLP) Functionality. It lists functional protocol requirements, which are very near to a PROPOSED solution for NTLP. Naturally, the list is not exhaustive nor is the description long. Let us know whether this nmore the type of requieremnt you have in mind. You can find it under. http://www.brubers.org/marcus/papers/draft-brunner-nsis-ntlp-func-00.txt Marcus -------------------------------------- Marcus Brunner Network Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ Phone: +49 (0) 6221 905 11 29 personal home page: http://www.brubers.org/marcus _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Fri Dec 13 19:01:57 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10674 for ; Fri, 13 Dec 2002 19:01:56 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBE04Ui22589 for nsis-archive@odin.ietf.org; Fri, 13 Dec 2002 19:04:30 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBE04Sv22570; Fri, 13 Dec 2002 19:04:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBE03Ev22525 for ; Fri, 13 Dec 2002 19:03:14 -0500 Received: from mailrelay1.alcatel.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10651 for ; Fri, 13 Dec 2002 19:00:09 -0500 (EST) From: Axel.Kuttner@alcatel.de Received: from slsas5.stgl.netd.alcatel.de (slsas5.stgl.netd.alcatel.de [149.204.45.57]) by mailrelay1.alcatel.de (8.9.3/8.9.3) with ESMTP id BAA01001 for ; Sat, 14 Dec 2002 01:03:04 +0100 (MET) To: nsis@ietf.org Message-ID: Date: Sat, 14 Dec 2002 01:03:02 +0100 X-MIMETrack: Serialize by Router on DEMTA001/DE/ALCATEL(Release 5.0.9 |November 16, 2001) at 12/14/2002 01:03:06 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Alcanet-MTA-scanned-and-authorized: yes Subject: [NSIS] Axel KUTTNER/DE/ALCATEL is out of the office. 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 be out of the office starting 13.12.2002 and will not return until 07.01.2003. Thank you for keeping me informed. I will respond to your message when I return. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Sun Dec 15 02:07:26 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA25341 for ; Sun, 15 Dec 2002 02:07:26 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBF7A4Q22084 for nsis-archive@odin.ietf.org; Sun, 15 Dec 2002 02:10:04 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBF79vv22009; Sun, 15 Dec 2002 02:09:57 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBF768v16296 for ; Sun, 15 Dec 2002 02:06:08 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21864 for ; Sun, 15 Dec 2002 02:02:59 -0500 (EST) From: john.loughney@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gBF77Lp19856 for ; Sun, 15 Dec 2002 09:07:21 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Sun, 15 Dec 2002 09:03:29 +0200 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Sun, 15 Dec 2002 09:03:30 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe013.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Sun, 15 Dec 2002 09:03:30 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] Updated milestones Date: Sun, 15 Dec 2002 09:03:28 +0200 Message-ID: Thread-Topic: [NSIS] Updated milestones Thread-Index: AcKivJN2u7ZiguvRS4maBeExeP7DyABSO5qg To: Cc: X-OriginalArrivalTime: 15 Dec 2002 07:03:30.0122 (UTC) FILETIME=[12C26AA0:01C2A408] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gBF768v16297 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: 8bit Hi Melinda, > What is the second MAR 03 goal ("'Next Step QoS > Signaling'")? Is that a framework document? This is an update of the original charter. It is meant as what is the NSIS protocol. The current plan is to get an initial version of the protocol document out. I would hope it contains initial assumptions and goals of the protocol before getting (heavily) into the protocol mechanisms. The plan for the WG was to work on a general requirements doc, analysis of existing solutions & a framework in order to set the sandbox for the protocol. The IESG put a constraint on us, which is we need to prove that if NSIS WG chooses to work on something not RSVP based, we would need to have justification. How this is decided is based upon the chair & ADs discussing this. However, in my opinion, it does seem that the mechanisms which we will use will be at least based on RSVP, and may re-use much of the protocol mechanisms. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Mon Dec 16 08:37:53 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04498 for ; Mon, 16 Dec 2002 08:37:52 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBGDeNj21618 for nsis-archive@odin.ietf.org; Mon, 16 Dec 2002 08:40:23 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBGDeKv21591; Mon, 16 Dec 2002 08:40:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBGDaiv20802 for ; Mon, 16 Dec 2002 08:36:44 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04362 for ; Mon, 16 Dec 2002 08:33:37 -0500 (EST) From: john.loughney@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gBGDc3t21295 for ; Mon, 16 Dec 2002 15:38:03 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Mon, 16 Dec 2002 15:34:51 +0200 Received: from esebe009.NOE.Nokia.com ([172.21.138.41]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 16 Dec 2002 15:34:47 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe009.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 16 Dec 2002 15:34:45 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Mon, 16 Dec 2002 15:34:30 +0200 Message-ID: Thread-Topic: Reminder to all TSV area WG Chairs: Thread-Index: AcKktgNyvxOCsspxTpCc+p/9BtGv4QAUa+bQ To: X-OriginalArrivalTime: 16 Dec 2002 13:34:45.0461 (UTC) FILETIME=[E590A050:01C2A507] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gBGDaiv20803 Subject: [NSIS] Attentional all document editors or draft submitters 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: 8bit Hi all, Remember that you need to read and understand http://www.ietf.org/ID-nits.html We need to make sure that all document submissions for NSIS conform to the above. Please ask quesions if you are confused. Please use this as a checklist *before* sending ID for publication! Thanks, John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Dec 17 01:39:49 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27615 for ; Tue, 17 Dec 2002 01:39:48 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBH6gRP11219 for nsis-archive@odin.ietf.org; Tue, 17 Dec 2002 01:42:27 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBH6gPv11212; Tue, 17 Dec 2002 01:42:25 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBH6fev11194 for ; Tue, 17 Dec 2002 01:41:40 -0500 Received: from mgw-x1.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27608 for ; Tue, 17 Dec 2002 01:38:30 -0500 (EST) From: john.loughney@nokia.com Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gBH6ei007024 for ; Tue, 17 Dec 2002 08:40:44 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 17 Dec 2002 08:41:28 +0200 Received: from esebe002.NOE.Nokia.com ([172.21.138.17]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 17 Dec 2002 08:41:26 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 17 Dec 2002 08:41:26 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] Updated milestones Date: Tue, 17 Dec 2002 08:41:26 +0200 Message-ID: Thread-Topic: [NSIS] Updated milestones Thread-Index: AcKivmUvj+2InpOjRLGW13HaIoGkBQC2LOAg To: , Cc: X-OriginalArrivalTime: 17 Dec 2002 06:41:26.0582 (UTC) FILETIME=[52B1BD60:01C2A597] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gBH6fiv11195 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: 8bit Hi Robert, > i can't currently decide how to interpret the > analysis/framework 'charter criteria' mentioned in the > milestones, since the existing charter implies we are going > to evaluate RSVP to see if it is up to the job (and i'm not > sure how/where this is taking place), and the charter > presented in Atlanta doesn't mention this 'hurdle' the same way. This is something for the ADs to deterime. They originally wanted to ensure due-dilegence when looking at new solutions. They wanted to make sure we don't toss RSVP into the garbage can and do something entirely new. My current view is that we are not doing this, so if the ADs agree, we probably don't need to worry about the hurdle. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Dec 17 23:47:58 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA02249 for ; Tue, 17 Dec 2002 23:47:58 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBI4oZl29326 for nsis-archive@odin.ietf.org; Tue, 17 Dec 2002 23:50:35 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBI4oUv29318; Tue, 17 Dec 2002 23:50:30 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBGFQsv27340 for ; Mon, 16 Dec 2002 10:26:54 -0500 Received: from titan.tele.pw.edu.pl (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07884 for ; Mon, 16 Dec 2002 10:23:42 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by titan.tele.pw.edu.pl (Postfix) with ESMTP id 201773B6B7 for ; Mon, 16 Dec 2002 16:26:39 +0100 (CET) Received: from aquila (zttstaff-dhcp119.tele.pw.edu.pl [194.29.169.119]) by titan.tele.pw.edu.pl (Postfix) with ESMTP id 13C053B6AF for ; Mon, 16 Dec 2002 16:26:33 +0100 (CET) Message-ID: <410-2200212116153257274@aquila> From: "Art-QoS" To: nsis@ietf.org Date: Mon, 16 Dec 2002 16:32:57 +0100 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Virus-Scanned: by AMaViS perl-11 titan Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gBGFQsv27341 Subject: [NSIS] CFP: Art-QoS, Architectures for Quality of Service in the Internet 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: 8bit We apologize if you recieve multiple copies of this message. CALL FOR PAPERS Art-QoS 2003 Workshop on ARCHITECTURES FOR QUALITY OF SERVICE IN THE INTERNET jointly held with THE FINAL AQUILA IST SEMINAR Warsaw, Poland, March 24-25, 2003 Organised by: Institute of Telecommunications Warsaw University of Technology, Poland WORKSHOP PURPOSE The Workshop is organised for bringing together the researchers working on providing Quality of Service (QoS) into IP-based networks. The intention is to discuss architectural and traffic control mechanisms aspects supporting end-to-end QoS. The Workshop is organised jointly with the Final Seminar of the AQUILA IST project. The AQUILA (Adaptive Resource Control for QoS Using an IP-based Layered Architecture) project started in December 1999 with 12 partners from 6 countries (Austria, Finland, Germany, Greece, Italy and Poland). The project has defined a comprehensive framework for the support of QoS in IP-based networks. The proposed solutions were implemented in the form of prototypes and tested in the AQUILA trial sites, in Helsinki, Vienna and Warsaw. During the Workshop there are planned two special sessions devoted to AQUILA. More information about the project one can find at www.ist-aquila.org. CONFERENCE TOPICS The list of the topics includes (but is not limited to) - Architectures for QoS IP - QoS IP Mechanisms - Performance Evaluation - Internet Traffic Modelling - Traffic Control and Engineering - Traffic Measurements - Testing Results - QoS Requirements - Transport Protocols (TCP, UDP) over IP QoS - Inter-domain QoS - QoS in IPv.6 WORKSHOP VENUE The Workshop will be held in the Sheraton Warsaw Hotel situated near the centre of Warsaw: www.sheraton.pl PROCEEDINGS EDITION All accepted papers will be published in the form of a book, in the Lecture Notes in Computer Science (LNCS) series by Springer-Verlag. Remark that the paper publication is conditioned by paper presentation at the Workshop. PAPER SUBMISSION Authors are kindly invited to submit full paper describing original research as well as results of laboratory and real network trials. The paper (with max. 12 single-spaced pages) should be written in English and submitted not later than February 1st, 2003. Please send the paper in the form of PS or PDF file. The authors will be notified about the paper acceptance not later than February 20th, 2003. The deadline for camera-ready copy is March 1st, 2003. The papers should be submitted to the following e-mail address: art-qos@tele.pw.edu.pl For the submitted paper and camera-ready manuscript please use the Springer-Verlag instructions for authors at: www.springer.de/comp/lncs/authors.html WORKSHOP REGISTRATION Information about the registration is available at the www.tele.pw.edu.pl/art-qos ACCOMMODATION For the conference participants the organisers booked the rooms in the Sheraton Warsaw Hotel with special price (125 EUR + 7% VAT for single room). The hotel registration form one can find at www.tele.pw.edu.pl/art-qos. The special rates are guaranteed for the reservations not later than March 3rd. IMPORTANT DATES Full paper due: February 1, 2003 Notification of acceptance due: February 20, 2003 Camera-ready paper due: March 1, 2003 CORRESPONDENCE ADDRESS Halina Tarasiuk Institute of Telecommunications Warsaw University of Technology Ul. Nowowiejska 15/19 00-665 Warsaw, Poland Phone: (+48 22) 660 73 96 Fax: (+48 22) 660 75 64 E-mail: art-qos@tele.pw.edu.pl PROGRAM COMMITTEE Co-chairs Wojciech Burakowski, Warsaw University of Technology, Poland Berthold Koch, Siemens AG, Germany Members Jose Brazio, Telecommunications Institute Lisbon, Portugal Andrzej Dabrowski, Warsaw University of Technology, Poland Franco Davoli, University of Genua, Italy Gerald Eichler, T-Systems Nova, Germany Hermann Granzer, Siemens AG, Germany Ulrich Hofmann, Salzburg Research, Austria Heinrich Hussmann, Dresden University of Technology, Germany Laszlo Jereb, Budapest University of Technology and Economics, Hungary Yannis Karadimas, Q-Systems, Greece Ilkka Norros, VTT Information Technology, Finland James Roberts, France Telecom R&D, France Stefano Salsano, University of Roma "Tor Vergata", Italy Paulo de Sousa ,European Commission Phuoc Tran-Gia, University of Wuerzburg, Germany Iakovos S. Venieris, National Technical University of Athens, Greece Manuel Villen Altamirano, Telefonica I+D, Spain Jozef Wozniak, Technical University of Gdansk, Poland LOCAL ORGANISING COMMITTEE Andrzej Bak, Andrzej Beben, Marek Dabrowski, Monika Fudala, Halina Tarasiuk (chair), Elzbieta Tarwacka _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Dec 18 09:47:25 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09802 for ; Wed, 18 Dec 2002 09:47:25 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBIEnw109180 for nsis-archive@odin.ietf.org; Wed, 18 Dec 2002 09:49:58 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBIEntv09170; Wed, 18 Dec 2002 09:49:55 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBIEm3v09117 for ; Wed, 18 Dec 2002 09:48:03 -0500 Received: from yamato.ccrle.nec.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09774 for ; Wed, 18 Dec 2002 09:44:59 -0500 (EST) Received: from imap.heidelberg.ccrle.nec.de (imap [192.168.102.11]) by yamato.ccrle.nec.de (8.12.3/8.10.1) with ESMTP id gBIFvKOf009292 for ; Wed, 18 Dec 2002 15:57:20 GMT Received: from [192.168.102.207] (marcus.heidelberg.ccrle.nec.de [192.168.102.207]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 7441727DE5 for ; Wed, 18 Dec 2002 15:45:00 +0100 (CET) Date: Wed, 18 Dec 2002 16:00:35 +0100 From: Marcus Brunner Reply-To: marcus@brubers.org To: nsis@ietf.org Message-ID: <20406382.1040227235@[192.168.102.207]> X-Mailer: Mulberry/2.2.0 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Subject: [NSIS] submission of req -06 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 just submitted the next version of the requirements draft. I changed the draft according to the decision made at Atlanta (find them in the minutes). You can find it under http://www.brubers.org/marcus/papers/draft-ietf-nsis-req-06.txt I hope I addressed all the ID-nits as well. Marcus -------------------------------------- Dr. Marcus Brunner Network Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ Phone: +49 (0) 6221 905 11 29 personal home page: http://www.brubers.org/marcus _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Dec 18 09:51:37 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09873 for ; Wed, 18 Dec 2002 09:51:37 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBIEsAg09348 for nsis-archive@odin.ietf.org; Wed, 18 Dec 2002 09:54:10 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBIEs2v09337; Wed, 18 Dec 2002 09:54:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBIErHv09287 for ; Wed, 18 Dec 2002 09:53:17 -0500 Received: from yamato.ccrle.nec.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09850 for ; Wed, 18 Dec 2002 09:50:12 -0500 (EST) Received: from imap.heidelberg.ccrle.nec.de (imap [192.168.102.11]) by yamato.ccrle.nec.de (8.12.3/8.10.1) with ESMTP id gBIG2WOf009397 for ; Wed, 18 Dec 2002 16:02:32 GMT Received: from [192.168.102.207] (marcus.heidelberg.ccrle.nec.de [192.168.102.207]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 5EB947EEC7 for ; Wed, 18 Dec 2002 15:50:12 +0100 (CET) Date: Wed, 18 Dec 2002 16:05:47 +0100 From: Marcus Brunner Reply-To: marcus@brubers.org To: nsis@ietf.org Message-ID: <20718361.1040227547@[192.168.102.207]> X-Mailer: Mulberry/2.2.0 (Win32) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="==========20722458==========" Subject: [NSIS] I-D ACTION:draft-brunner-nsis-ntlp-func-00.txt (fwd) 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: , --==========20722458========== Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: 7bit ---------- Forwarded Message ---------- Date: Mittwoch, 18. Dezember 2002 08:02 -0500 From: Internet-Drafts@ietf.org To: IETF-Announce Subject: I-D ACTION:draft-brunner-nsis-ntlp-func-00.txt > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : NSIS Transport Layer Protocol (NTLP) Functionality > Author(s) : M. Brunner > Filename : draft-brunner-nsis-ntlp-func-00.txt > Pages : 4 > Date : 2002-12-16 > > This memo is a first step towards the design of a NSIS Transport > Layer Protocol (NTLP). It lists protocol requirements, protocol > design principles, and functional issues on the protocol level coming > out of the NSIS requirements document[NSIS-REQ], the NSIS framework > document [NSIS-FW], and several analysis documents. This list might > be very near to implementation or solution already. The draft has > been motivated by recommendations to list protocol requirements > instead of higher level NSIS requirements as done in the NSIS > requirements draft [NSIS-REQ]. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-brunner-nsis-ntlp-func-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-brunner-nsis-ntlp-func-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-brunner-nsis-ntlp-func-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. ---------- End Forwarded Message ---------- -------------------------------------- Dr. Marcus Brunner Network Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ Phone: +49 (0) 6221 905 11 29 personal home page: http://www.brubers.org/marcus --==========20722458========== Content-Type: multipart/mixed; boundary="==========20721122==========" --==========20721122========== Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : NSIS Transport Layer Protocol (NTLP) Functionality Author(s) : M. Brunner Filename : draft-brunner-nsis-ntlp-func-00.txt Pages : 4 Date : 2002-12-16 This memo is a first step towards the design of a NSIS Transport Layer Protocol (NTLP). It lists protocol requirements, protocol design principles, and functional issues on the protocol level coming out of the NSIS requirements document[NSIS-REQ], the NSIS framework document [NSIS-FW], and several analysis documents. This list might be very near to implementation or solution already. The draft has been motivated by recommendations to list protocol requirements instead of higher level NSIS requirements as done in the NSIS requirements draft [NSIS-REQ]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-brunner-nsis-ntlp-func-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-brunner-nsis-ntlp-func-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-brunner-nsis-ntlp-func-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. --==========20721122========== Content-Type: multipart/alternative; boundary="==========20731141==========" --==========20731141========== Content-Type: message/external-body; ACCESS-TYPE=mail-server; SERVER="mailserv@ietf.org" Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <2002-12-16123434.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-brunner-nsis-ntlp-func-00.txt --==========20731141========== Content-Type: message/external-body; name="draft-brunner-nsis-ntlp-func-00.txt"; SITE="ftp.ietf.org"; ACCESS-TYPE=anon-ftp; DIRECTORY=internet-drafts Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <2002-12-16123434.I-D@ietf.org> --==========20731141==========-- --==========20721122==========-- --==========20722458==========-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Sun Dec 22 17:06:22 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06471 for ; Sun, 22 Dec 2002 17:06:22 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBMM9jf25408 for nsis-archive@odin.ietf.org; Sun, 22 Dec 2002 17:09:45 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBMM9av25389; Sun, 22 Dec 2002 17:09:36 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBKCCkv11982 for ; Fri, 20 Dec 2002 07:12: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 HAA23042; Fri, 20 Dec 2002 07:09:21 -0500 (EST) Message-Id: <200212201209.HAA23042@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, 20 Dec 2002 07:09:21 -0500 Subject: [NSIS] I-D ACTION:draft-ietf-nsis-req-06.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 : Requirements for Signaling Protocols Author(s) : M. Brunner Filename : draft-ietf-nsis-req-06.txt Pages : 35 Date : 2002-12-18 This document defines requirements for signaling across different network environments, where different network environments mean across administrative and technology domains. Signaling is mainly though for QoS such as [RSVP], however in recent year several other applications of signaling have been defined such as signaling for MPLS label distribution [RSVP-TE]. To achieve wide applicability of the requirements, the starting point is a diverse set of scenarios/use cases concerning various types of networks and application interactions. This memo present the assumptions and the aspects not considered within scope before listing the requirements grouped according to areas such as architecture and design goals, signaling flows, layering, performance, flexibility, security, and mobility. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nsis-req-06.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-req-06.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-req-06.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: <2002-12-18131952.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nsis-req-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nsis-req-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-12-18131952.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Mon Dec 23 08:19:51 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29489 for ; Mon, 23 Dec 2002 08:19:51 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBNDNL809772 for nsis-archive@odin.ietf.org; Mon, 23 Dec 2002 08:23:21 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBNDNCv09728; Mon, 23 Dec 2002 08:23:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBN9XKv30836 for ; Mon, 23 Dec 2002 04:33:20 -0500 Received: from entcl9.et.tu-dresden.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24687 for ; Mon, 23 Dec 2002 04:29:19 -0500 (EST) Received: (from itc18@localhost) by entcl9.et.tu-dresden.de (8.11.3/8.11.3/SuSE Linux 8.11.1-0.5) id gBN9a3e02674; Mon, 23 Dec 2002 10:36:03 +0100 Date: Mon, 23 Dec 2002 10:36:03 +0100 Message-Id: <200212230936.gBN9a3e02674@entcl9.et.tu-dresden.de> To: nsis@ietf.org From: itc18@ifn.et.tu-dresden.de Subject: [NSIS] ITC 18 - Call for Papers: Deadline extended 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: , Our apologies for receiving multiple copies of this email.. DEADLINE EXTENSION: Because of multiple requests and difficulties to use infrastructures in the christmas holiday period we have extended the deadline to January 19, 2003. Due to this now very tight schedule we have to close the web server for submissions on 24:00 h that Sunday, sharply. CALL FOR PAPERS - CALL FOR PAPERS - CALL FOR PAPERS - CALL FOR PAPERS       +-----------------------------------------------+       |    18th International TELETRAFFIC CONGRESS    |       |   Haus am Köllnischen Park, Berlin, Germany   |       |        31 August - 5 September 2003           |       |                                               |       | "Providing QoS in Heterogeneous Environments" |       |            http://www.ITC18.org               |       +-----------------------------------------------+ CALL FOR PAPERS - CALL FOR PAPERS - CALL FOR PAPERS - CALL FOR PAPERS ORGANIZATIONS AND HISTORY International Advisory Committee http://www.i-teletraffic.org/ ITG - Information Technology Society in the VDE http://www.vde.com/vde/html/e/fach/itg/itg.htm The ITC, founded in 1955, provides, through regular, now bi-annual congresses, the main international forum for teletraffic research and engineering. The purpose of the ITC is to stimulate the development and application of teletraffic theory for planning, engineering, managing and administrating telecommunication networks. The analysis and control of traffic phenomena in such networks require measurements, forecasts, as well as network management algorithms. The ITC gathers teletraffic experts from research organizations, universities, manufacturers, network operators and international technical organizations yielding a well-balanced contribution from theory and application. ITCs are organized so that researchers, engineers, and administrators from telcos and data network operators can interact and benefit from discussions and exchange of ideas. The ITC also benefits from the social environment which allows for the creation of new personal contacts between delegates. CONFERENCE CITY After 33 years, the ITC community meets again in Germany - in Berlin, the old and new capital, a four million people meeting place of the East and the West in the center of Europe. Berlin is a city in transition, one that is not always easy to understand, and which is often quite difficult to describe. However, no other city of Germany reflects the historical events of the last few years to the extent Berlin does. More information: http://www.berlin.de/english CONFERENCE VENUE Close to the river Spree in the center of Berlin, the "Haus am Köllnischen Park"is located just a few minutes walking distance from famous places such as Alexanderplatz, Humboldt University, Gendarmenmarkt, Reichstag or Brandenburger Tor. "PROVIDING QOS IN HETEROGENEOUS EINVIRONMENTS" The ITC 18 will be held in a transient phase where IP packet-switched architectures migrate from being data networks only to also substituting traditional circuit-switched networks. Papers are welcome tackling the following topics: NETWORK ARCHITECTURES AND TECHNOLOGIES - Next generation networks - Broadband transport networks - Access networks - Wireless networks and wireless LANs - Heterogeneous networks and ubiquitous communication - Web technologies - Voice over IP - Ad hoc and peer to peer networking - Communication protocols TRAFFIC CONTROL AND ENGINEERING - Traffic engineering - Quality of service provisioning - Service pricing - Overload control - Traffic management - QoS in multi-provider networks - Service-aware admission control - Traffic conditioning - Routing - Mobility management and signalling - Network planning and optimization - Network management - Reliability and Survivability METHODS AND TOOLS - Traffic characterization and modelling - Performance evaluation - Queueing theory - Scheduling - Simulation methodology - Traffic and performance measurements IMPORTANT DATES Full paper due : extended to 19 January 2003 Notification of acceptance mailed: 16 April 2003 Camera ready paper due : 1 June 2003 SUBMISSION OF PAPERS Papers should not exceed 15 double-spaced pages (about 5000 words, font 12pt), have an abstract of 100-200 words, and be original material not previously published. The title page should contain the authors' names, affiliation and contact details. The corresponding author must be indicated. Only electronic submission via the ITC18 homepage will be arranged. Further information can be obtained on the ITC18 homepage via http://www.ITC18.org. CONFERENCE ORGANIZATION AND CONTACT ADDRESS ITC 18 VDE Conference Services Stresemannallee 15 D-60596 Frankfurt/Main, Germany Phone: +49 69 6308-202 Fax : +49 69 9631-5213 email: vde-conferences@vde.com COMMITTEES EXECUTIVE COMMITTEE Chair            : Joachim Claus, Deutsche Telekom AG, Bonn Secretariat      : Volker Schanz, ITG/VDE, Frankfurt Conference Office: Rupert Rompel, VDE, Frankfurt TECHNICAL PROGRAMME COMMITTEE Chairs: Joachim Charzinski, Siemens, Munich Ralf Lehnert, Dresden University of Technology Phuoc Tran-Gia, University of Würzburg Carmelita Görg, University of Bremen (Tutorials Chair) INTERNATIONAL TPC                NATIONAL TPC Marco Ajmone Marsan, Italy       Dieter Baum, University of Trier Åke Arvidsson, Sweden            Matthias Baumann, Dresden University Khalid Begain, United Kingdom    of Technology Chris Blondia, Belgium           Gunter Bolch, University of Onno Boxma, The Netherlands      Erlangen-Nuremberg Herwig Bruneel, Belgium          Andreas Brandt, Humboldt University Olga Casals, Spain               Joachim Charzinski, Siemens AG Prosper Chemouil, France         Jörg Eberspächer, Munich University of Laurie Cuthbert, United Kingdom  Technology Hermann de Meer, United Kingdom  Anja Feldmann, Saarland University Edmundo de Souza e Silva, Brazil Wolfgang Fischer, Cisco GmbH Zbigniew Dziong, USA             Carmelita Görg, University of Bremen Khaled Elsayed, Egypt            Franz Hartleb, T-Systems GmbH Peder Emstad, Norway             Christoph Herrmann, Philips Research David Everitt, Australia         Ulrich Killat, Technical University of Serge Fdida, France              Hamburg-Harburg Georges Fiche, France            Udo Krieger, T-Systems GmbH Markus Fiedler, Sweden           Paul J. Kühn, University of Stuttgart Luigi Fratta, Italy              Ralf Lehnert, Dresden University of H. Richard Gail, USA             Technology Richard Harris, Australia        Georg Rößler, Tenovis GmbH&Co. KG Frank Hübner-Szabo de Bucs, USA  Stefan Schneeberger, Siemens AG Boudewijn Haverkort, The Netherlands  Hans-Peter Schwefel, Siemens AG Villy Baek Iversen, Denmark      Michael Söllner, Lucent Technologies Konosuke Kawashima, Japan        GmbH Peter Key, United Kingdom        Michael Tangemann, Alcatel AG Daniel Kofman, USA               Sandra Tartarelli, NEC GmbH Yonathan Levy, USA               Phuoc Tran-Gia, University of Würzburg Xiong Jiang Liang, China         Kurt Tutschku, University of Würzburg Karl Lindberger, Sweden          Bernhard Walke, Aachen University of Michel Mandjes, The Netherlands  Technology Ian Marshall, United Kingdom     Ulrich Wellens, Vodafone GmbH Debasis Mitra, USA               Albert Weller, T-Mobile GmbH Sandor Molnár, Hungary           Adam Wolisz, Berlin University of Jorge Moreira de Souza, Brazil   Technology Arne A. Nilsson, USA             Martina Zitterbart, University of Ilkka Norros, Finland            Karlsruhe Baron Peterssen, South Africa Michal Pioro, Poland Jim Roberts, France Matthew Roughan, USA Hiroshi Saito, Japan Shohei Sato, Japan Danny Tsang, Hong Kong Hans van den Berg, The Netherlands Rob van der Mei, The Netherlands Manuel Villen-Altamirano, Spain Jorma Virtamo, Finland Y.T. Wang, USA Pat Wirth, USA Jim Yan, Canada Hideaki Yoshino, Japan Moshe Zukerman, Australia _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Sat Dec 28 09:22:13 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05496 for ; Sat, 28 Dec 2002 09:22:13 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBSES5d14822 for nsis-archive@odin.ietf.org; Sat, 28 Dec 2002 09:28:05 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBSERvJ14813; Sat, 28 Dec 2002 09:27:57 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBSEQAJ14789 for ; Sat, 28 Dec 2002 09:26:10 -0500 Received: from nazare.cin.ufpe.br (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05490 for ; Sat, 28 Dec 2002 09:19:38 -0500 (EST) From: cak@cin.ufpe.br Received: (from root@localhost) by nazare.cin.ufpe.br (8.11.6/8.11.6) id gBSEMiJ38982 for nsis@ietf.org; Sat, 28 Dec 2002 11:22:44 -0300 (BRST) (envelope-from cak@cin.ufpe.br) Received: from cin.ufpe.br (buique [172.17.33.108]) by nazare.cin.ufpe.br (8.11.6/8.11.6) with SMTP id gBSEMhc03885 for ; Sat, 28 Dec 2002 11:22:43 -0300 (BRST) (envelope-from cak@cin.ufpe.br) Received: from 200.199.75.34 (SquirrelMail authenticated user cak) by webmail.cin.ufpe.br with HTTP; Sat, 28 Dec 2002 11:22:43 -0300 (BRST) Message-ID: <3188.200.199.75.34.1041085363.squirrel@webmail.cin.ufpe.br> Date: Sat, 28 Dec 2002 11:22:43 -0300 (BRST) To: X-Priority: 3 Importance: Normal X-MSMail-Priority: Normal X-Mailer: SquirrelMail (version 1.2.6) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Subject: [NSIS] Service definition and negotiation 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: 8bit Hello all, I’ve just finished writing my dissertation, called "An Architecture for Providing End-to-End QoS-based Advanced Services in the Internet", which focuses in e2e service definition and dynamic service negotiation. It can be downloaded from http://www.cin.ufpe.br/~cak/publications/thesis_proposal.pdf Comments will be appreciated. Have a good 2003! Carlos Kamienski ----------------------------------------- Federal University of Pernambuco - Brazil cak@cin.ufpe.br _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis