From nsis-bounces@ietf.org Thu Apr 06 10:59:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRVxT-00070D-Pb; Thu, 06 Apr 2006 10:59:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRVxS-000702-Iv for nsis@ietf.org; Thu, 06 Apr 2006 10:59:38 -0400 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FRVxS-0002by-5H for nsis@ietf.org; Thu, 06 Apr 2006 10:59:38 -0400 Received: (qmail invoked by alias); 06 Apr 2006 14:59:37 -0000 Received: from socks2.netz.sbs.de (EHLO [192.35.17.25]) [192.35.17.25] by mail.gmx.net (mp030) with SMTP; 06 Apr 2006 16:59:37 +0200 X-Authenticated: #29516787 Message-ID: <44352CD2.7070008@gmx.net> Date: Thu, 06 Apr 2006 16:59:30 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: NSIS Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.1 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Subject: [NSIS] IETF#65 Meeting Minutes X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi all, here is a first attempt for compiling the meeting minutes: http://www3.ietf.org/proceedings/06mar/minutes/nsis.txt I have only received the meeting minutes by Paulo Mendes and hence they are still incomplete. Thanks Paulo for writing the meeting minutes and for sending them to me quickly. I am still waiting for Andrew to send me something. Please help us to * verify whether the summary for each presentation reflects your conclusion from the meeting (and provide text) * verify whether the slides are up-to-date Ciao Hannes _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Apr 06 11:01:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRVzO-0007Lr-79; Thu, 06 Apr 2006 11:01:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRVzN-0007LO-JD for nsis@ietf.org; Thu, 06 Apr 2006 11:01:37 -0400 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FRVzM-0002nR-58 for nsis@ietf.org; Thu, 06 Apr 2006 11:01:37 -0400 Received: (qmail invoked by alias); 06 Apr 2006 15:01:35 -0000 Received: from socks2.netz.sbs.de (EHLO [192.35.17.25]) [192.35.17.25] by mail.gmx.net (mp029) with SMTP; 06 Apr 2006 17:01:35 +0200 X-Authenticated: #29516787 Message-ID: <44352D42.3030506@gmx.net> Date: Thu, 06 Apr 2006 17:01:22 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Hannes Tschofenig References: <44352CD2.7070008@gmx.net> In-Reply-To: <44352CD2.7070008@gmx.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: NSIS Subject: [NSIS] Re: IETF#65 Meeting Minutes X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org I forgot something: Roland acted as as Jabber scribe. Here is the log: http://www.ietf.org/meetings/ietf-logs/nsis@rooms.jabber.ietf.org/2006-03-23.html Thanks Roland. Ciao Hannes PS: I will double-check the Jabber-Log with the meeting minutes. Hannes Tschofenig wrote: > Hi all, > > here is a first attempt for compiling the meeting minutes: > http://www3.ietf.org/proceedings/06mar/minutes/nsis.txt > > I have only received the meeting minutes by Paulo Mendes and hence they > are still incomplete. Thanks Paulo for writing the meeting minutes and > for sending them to me quickly. I am still waiting for Andrew to send me > something. > > Please help us to > * verify whether the summary for each presentation reflects your > conclusion from the meeting (and provide text) > * verify whether the slides are up-to-date > > Ciao > Hannes > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Apr 06 11:29:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRWQ5-0006hr-J1; Thu, 06 Apr 2006 11:29:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRWQ3-0006hm-Qw for nsis@ietf.org; Thu, 06 Apr 2006 11:29:11 -0400 Received: from rsys002x.roke.co.uk ([193.118.201.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRWPz-0004K5-De for nsis@ietf.org; Thu, 06 Apr 2006 11:29:11 -0400 Received: from rsys005a.comm.ad.roke.co.uk (rsys005a [193.118.193.85]) by rsys002x.roke.co.uk (8.13.1/8.13.1) with ESMTP id k36FSuRs029724; Thu, 6 Apr 2006 16:29:01 +0100 Received: from [193.118.197.86] ([193.118.197.86]) by rsys005a.comm.ad.roke.co.uk with Microsoft SMTPSVC(6.0.3790.211); Thu, 6 Apr 2006 16:28:56 +0100 Message-ID: <443533B7.1080705@roke.co.uk> Date: Thu, 06 Apr 2006 16:28:56 +0100 From: Andrew McDonald User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Hannes Tschofenig Subject: Re: [NSIS] IETF#65 Meeting Minutes References: <44352CD2.7070008@gmx.net> In-Reply-To: <44352CD2.7070008@gmx.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Apr 2006 15:28:56.0169 (UTC) FILETIME=[D17FF590:01C6598E] X-MailScanner-roke.co.uk: Found to be clean X-MailScanner-roke.co.uk-SpamCheck: X-MailScanner-From: andrew.mcdonald@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: NSIS X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hannes Tschofenig wrote: > I have only received the meeting minutes by Paulo Mendes and hence they > are still incomplete. Thanks Paulo for writing the meeting minutes and > for sending them to me quickly. I am still waiting for Andrew to send me > something. You're not spam filtering out my e-mail are you. :-) I've sent them to you twice - the first time was within minutes of the session ending. If you still haven't got them, my raw notes can be found at: http://nsis.srmr.co.uk/~adm/nsis-notes-ietf65.txt (-: regards, Andy _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Apr 06 11:58:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRWsD-0002pv-Cf; Thu, 06 Apr 2006 11:58:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRWsC-0002pq-5c for nsis@ietf.org; Thu, 06 Apr 2006 11:58:16 -0400 Received: from gecko.sbs.de ([194.138.37.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRWsA-0005Uw-Ki for nsis@ietf.org; Thu, 06 Apr 2006 11:58:16 -0400 Received: from mail2.sbs.de (localhost [127.0.0.1]) by gecko.sbs.de (8.12.6/8.12.6) with ESMTP id k36FwD2n028861; Thu, 6 Apr 2006 17:58:13 +0200 Received: from fthw9xpa.ww002.siemens.net (fthw9xpa.ww002.siemens.net [157.163.133.222]) by mail2.sbs.de (8.12.6/8.12.6) with ESMTP id k36FwDUR024871; Thu, 6 Apr 2006 17:58:13 +0200 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xpa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Apr 2006 17:58:12 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: AW: [NSIS] IETF#65 Meeting Minutes Date: Thu, 6 Apr 2006 17:53:23 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] IETF#65 Meeting Minutes Thread-Index: AcZZjuC3kr5s5CQmSISzkHZhhtx3vwAAzSRA From: "Tschofenig, Hannes" To: "Andrew McDonald" , "Hannes Tschofenig" X-OriginalArrivalTime: 06 Apr 2006 15:58:12.0918 (UTC) FILETIME=[E89A9560:01C65992] X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: NSIS X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Andy,=20 thanks a lot for the extremely quick reply! I will merge them with Paulo's meeting minutes.=20 Ciao Hannes > -----Urspr=FCngliche Nachricht----- > Von: Andrew McDonald [mailto:andrew.mcdonald@roke.co.uk]=20 > Gesendet: Donnerstag, 6. April 2006 17:29 > An: Hannes Tschofenig > Cc: NSIS > Betreff: Re: [NSIS] IETF#65 Meeting Minutes >=20 > Hannes Tschofenig wrote: > > I have only received the meeting minutes by Paulo Mendes=20 > and hence they=20 > > are still incomplete. Thanks Paulo for writing the meeting=20 > minutes and=20 > > for sending them to me quickly. I am still waiting for=20 > Andrew to send me=20 > > something. >=20 > You're not spam filtering out my e-mail are you. :-) I've=20 > sent them to=20 > you twice - the first time was within minutes of the session=20 > ending. If=20 > you still haven't got them, my raw notes can be found at: > http://nsis.srmr.co.uk/~adm/nsis-notes-ietf65.txt >=20 > (-: >=20 > regards, > Andy >=20 > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Apr 07 02:34:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRkXn-0001DI-5C; Fri, 07 Apr 2006 02:34:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRkXm-0001DB-2p for nsis@ietf.org; Fri, 07 Apr 2006 02:34:06 -0400 Received: from tcmail33.telekom.de ([217.6.95.240]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRkXk-0007Zp-NC for nsis@ietf.org; Fri, 07 Apr 2006 02:34:06 -0400 Received: from s4de8psaans.mitte.t-com.de by tcmail31.dmz.telekom.de with ESMTP; Fri, 7 Apr 2006 08:33:55 +0200 Received: by S4DE8PSAANS.blf.telekom.de with Internet Mail Service (5.5.2653.19) id <2FZLGG19>; Fri, 7 Apr 2006 08:33:54 +0200 Message-Id: <6439282641581441A36F7F6F83ED2ED20E62F0@S4DE8PSAAFQ.mitte.t-com.de> From: "Geib, Ruediger" To: hannes.tschofenig@siemens.com Date: Fri, 7 Apr 2006 08:33:47 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: nsis@ietf.org Subject: [NSIS] one or separate qos models for classic and PCN CL respectively X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Hannes, the issue was raised in the minutes to be taken to the list. Arguments to support only a single QoS model are: - simplification of the end system (which doesn't have to=20 worry which flavor of a CL QoS model is applied by the=20 network or by the remote end system). - no mapping or interworking required. That would assume that the characteristics of the service=20 are the same, no matter how it is produced. But this question=20 will arise with any interworking. CL over IP/MPLS, CL over=20 aggregated NSIS, CL over a network avoiding packet losses=20 by provisioning. My position would be, if a carrier guarantees service, CL=20 can be produced and should use a single QoS model. Independent=20 of the way the CL service is produced in the backbone. Regards, R=FCdiger _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Apr 07 05:02:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRmrh-0008I8-Qb; Fri, 07 Apr 2006 05:02:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRmrg-0008I3-1O for nsis@ietf.org; Fri, 07 Apr 2006 05:02:48 -0400 Received: from courier.cs.helsinki.fi ([128.214.9.1] helo=mail.cs.helsinki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRmre-0004q4-OM for nsis@ietf.org; Fri, 07 Apr 2006 05:02:48 -0400 Received: from sbz-31.cs.helsinki.fi (sbz-31.cs.helsinki.fi [128.214.9.99]) (TLS: TLSv1/SSLv3,256bits,AES256-SHA) by mail.cs.helsinki.fi with esmtp; Fri, 07 Apr 2006 12:02:38 +0300 id 0007034B.44362AAE.00005F3D Date: Fri, 7 Apr 2006 12:02:38 +0300 (EEST) From: Jukka MJ Manner To: nsis@ietf.org Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Subject: [NSIS] QoS NSLP - The Next Steps X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi all, Here are my proposed updated to the QoS NSLP. Once we (me, Andy, and Georgios) get these written, we would call a new WGLC. - Remove the Ack-mechanism (& retransmissions, slew handling?) - Section 5 needs clarifications - Section about use of GIST interface needs updates/clarifications - How do we use the Router Alert? With IPv4 single RAO, IPv6 may have different values, e.g. allowing levels of aggregation. This should be decoupled anyway from the QoS NSLP? - Aggregation marking must be clarified - Re-routing description needs some more work - INFO_SPEC has some unnecessary things, and it is a bit unclear how QSPEC processing can inform about error situations - IANA considerations must be updated - Need to define what to do if a transient/intermediate domain does not guarantee/support a certain QoS parameter Regards, Jukka _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Apr 07 12:15:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRtcV-000603-6n; Fri, 07 Apr 2006 12:15:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRtcU-0005zy-IK for nsis@ietf.org; Fri, 07 Apr 2006 12:15:34 -0400 Received: from natfrord.rzone.de ([81.169.145.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRtcR-0002CG-4t for nsis@ietf.org; Fri, 07 Apr 2006 12:15:34 -0400 Received: from [192.168.178.200] (p5484C03A.dip0.t-ipconnect.de [84.132.192.58]) (authenticated bits=0) by post.webmailer.de (8.13.6/8.13.6) with ESMTP id k37GFS74027565; Fri, 7 Apr 2006 18:15:29 +0200 (MEST) Message-ID: <44368F9C.7020804@cs.uni-goettingen.de> Date: Fri, 07 Apr 2006 18:13:16 +0200 From: Bernd Schloer User-Agent: Mozilla Thunderbird 1.0.7 (X11/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Elena Scialpi - Unile Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: nsis@ietf.org Subject: [NSIS] draft-tommasi-nsis-semipro-00 X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Elena, I read through your draft http://www.ietf.org/internet-drafts/draft-tommasi-nsis-semipro-00.txt and have some questions on it. Before a potential handoff you install a GA, but no QoS state. The QoS State is installed after the handoff occurred. The reason for the late QoS installation is saving resources against a proactive procedure. The QUERY message is used to setup GIST state. So setting up GA is to speed up the reservation against a reactive procedure. Does the M-Flag indicate that the RESERVE msg followed by a QUERY is only sent after a handoff? After a handoff what happens to the old reservation? How are Ping Pong handovers handled? Is the old reservation torn down immediately or is it held for some time? Why is it necessary to have a buffering mechanism when the MN is the flow receiver? In realtime applications (voice or video streming) it is better from my point of view to accept the packet loss instead of receiving delayed data. Buffering increases the performance for pure data streams, e.g. a FTP download. Bernd _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Sun Apr 09 09:51:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSaJq-0003xd-2A; Sun, 09 Apr 2006 09:51:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSaJp-0003xY-Ec for nsis@ietf.org; Sun, 09 Apr 2006 09:51:09 -0400 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FSaJo-0006zK-6B for nsis@ietf.org; Sun, 09 Apr 2006 09:51:09 -0400 Received: (qmail invoked by alias); 09 Apr 2006 13:51:06 -0000 Received: from p54985DB6.dip.t-dialin.net (EHLO [192.168.2.33]) [84.152.93.182] by mail.gmx.net (mp033) with SMTP; 09 Apr 2006 15:51:06 +0200 X-Authenticated: #29516787 Message-ID: <44391146.8080007@gmx.net> Date: Sun, 09 Apr 2006 15:51:02 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: NSIS Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.1 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Subject: [NSIS] Updated IETF#65 Meeting Minutes X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi all, I have incorporated Andrew's meeting minutes. Here is the updated version: http://www3.ietf.org/proceedings/06mar/agenda/nsis.txt Please take a look at them. Ciao Hannes _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Sun Apr 09 09:53:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSaM3-00045a-JU; Sun, 09 Apr 2006 09:53:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSaM2-00045V-3G for nsis@ietf.org; Sun, 09 Apr 2006 09:53:26 -0400 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FSaM1-00075G-LP for nsis@ietf.org; Sun, 09 Apr 2006 09:53:26 -0400 Received: (qmail invoked by alias); 09 Apr 2006 13:53:24 -0000 Received: from p54985DB6.dip.t-dialin.net (EHLO [192.168.2.33]) [84.152.93.182] by mail.gmx.net (mp034) with SMTP; 09 Apr 2006 15:53:24 +0200 X-Authenticated: #29516787 Message-ID: <443911D0.4080300@gmx.net> Date: Sun, 09 Apr 2006 15:53:20 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Hannes Tschofenig References: <44391146.8080007@gmx.net> In-Reply-To: <44391146.8080007@gmx.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: NSIS Subject: [NSIS] Re: Updated IETF#65 Meeting Minutes X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org This is the correct link: http://www3.ietf.org/proceedings/06mar/minutes/nsis.txt The other link points to the agenda. Hannes Tschofenig wrote: > Hi all, > > I have incorporated Andrew's meeting minutes. > > Here is the updated version: > http://www3.ietf.org/proceedings/06mar/agenda/nsis.txt > > Please take a look at them. > > Ciao > Hannes > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Sun Apr 09 11:01:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSbQD-0006Cl-TF; Sun, 09 Apr 2006 11:01:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSbQC-0006Cd-JL for nsis@ietf.org; Sun, 09 Apr 2006 11:01:48 -0400 Received: from mclmx2.mail.saic.com ([149.8.64.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FSbQC-00015f-9j for nsis@ietf.org; Sun, 09 Apr 2006 11:01:48 -0400 Received: from 0015-its-ieg01.mail.saic.com ([149.8.64.21] [149.8.64.21]) by mclmx2.mail.saic.com; Sun, 9 Apr 2006 11:01:36 -0400 Received: from mcl-its-exig01.mail.saic.com ([149.8.64.12]) by 0015-its-ieg01.mail.saic.com (SMSSMTP 4.0.5.66) with SMTP id M2006040911013625942 ; Sun, 09 Apr 2006 11:01:36 -0400 Received: by mcl-its-exig01.mail.saic.com with Internet Mail Service (5.5.2657.72) id ; Sun, 9 Apr 2006 11:01:36 -0400 Message-Id: <62D92A9A02BCC845B202323D49A48426230D8C@0591-ITS-EXMP02.us.saic.com> From: "Roy, Radhika R." To: Hannes Tschofenig Subject: RE: [NSIS] Re: Updated IETF#65 Meeting Minutes Date: Sun, 9 Apr 2006 11:01:33 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) content-class: urn:content-classes:message X-Spam-Score: 0.0 (/) X-Scan-Signature: 93df555cbdbcdae9621e5b95d44b301e Cc: NSIS X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0977080601==" Errors-To: nsis-bounces@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============0977080601== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C65BE6.7E389F1F" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C65BE6.7E389F1F Content-Type: text/plain; charset="iso-8859-1" Hi, Hannes and all: With respect to QSPEC and Y.1541-QoSM drafts, comments were inter-related. You probably have not noticed it. Let me explain as follows: 1. QSPEC draft must NOT contain any extensions of Y.1541 parameters. It must be a "generic" QSPEC draft. Any extensions of Y.1541 is done here is INCOMPLETE as you can see the other draft. 2. The Y.1541-QoSM draft should be the only draft that MUST take care of all extensions of all parameters of QSPEC. 3. Similar is the case should be for the DiffServ network. Best regards, Radhika ------------------------------------------------------ * Y.1541 QoSM ------------- Slides are available at: http://www3.ietf.org/proceedings/06mar/slides/nsis-8.ppt - Jerry Ash: No updates; Completed WGLC, but had no comments, so probably not 'successfully compeleted WGLC'. May need revisions based on QoS NSLP and QSpec discussions. - Hannes: Reviewed the document and it looks good, and only some small fixes are needed. ------_=_NextPart_001_01C65BE6.7E389F1F Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [NSIS] Re: Updated IETF#65 Meeting Minutes

Hi, Hannes and = all:

With respect to QSPEC and Y.1541-QoSM drafts, comments were = inter-related. You probably have not noticed it. Let = me explain as follows:

1.      = QSPEC draft = must NOT contain any extensions of Y.1541 parameters. It must be a = "generic" QSPEC draft. Any extensions of Y.1541 is done = here is INCOMPLETE as you can see the other draft.

2.      The Y.1541-QoSM draft should be the only draft = that = MUST take care of all extensions of all parameters of QSPEC.

3.      Similar is the case should be for the = DiffServ network.

Best regards,

Radhika

------------------------------------------------------

* Y.1541 QoSM

-------------

Slides are available at:

http:/= /www3.ietf.org/proceedings/06mar/slides/nsis-8.ppt

=

- Jerry Ash: No updates;

Completed WGLC, but had no comments,

so probably not 'successfully compeleted WGLC'. =

May need revisions based on QoS NSLP and QSpec = discussions.

- Hannes: Reviewed the document and it looks good, =

and only some small fixes are needed.

------_=_NextPart_001_01C65BE6.7E389F1F-- --===============0977080601== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis --===============0977080601==-- From nsis-bounces@ietf.org Sun Apr 09 13:02:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSdJF-0000a6-BC; Sun, 09 Apr 2006 13:02:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSdJE-0000a1-Hu for nsis@ietf.org; Sun, 09 Apr 2006 13:02:44 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FSdJD-0005yl-3t for nsis@ietf.org; Sun, 09 Apr 2006 13:02:44 -0400 Received: (qmail invoked by alias); 09 Apr 2006 17:02:41 -0000 Received: from p54985DB6.dip.t-dialin.net (EHLO [192.168.2.33]) [84.152.93.182] by mail.gmx.net (mp039) with SMTP; 09 Apr 2006 19:02:41 +0200 X-Authenticated: #29516787 Message-ID: <44393E2B.1000808@gmx.net> Date: Sun, 09 Apr 2006 19:02:35 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Roy, Radhika R." Subject: Re: [NSIS] Re: Updated IETF#65 Meeting Minutes References: <62D92A9A02BCC845B202323D49A48426230D8C@0591-ITS-EXMP02.us.saic.com> In-Reply-To: <62D92A9A02BCC845B202323D49A48426230D8C@0591-ITS-EXMP02.us.saic.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: NSIS X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Roy, I went through the QSPEC and the Y.1541-QoSM meeting minutes again and have to state that they are correct. None of the issues listed below have been mentioned during the meeting. Ciao Hannes Roy, Radhika R. wrote: > Hi, Hannes and all: > > With respect to QSPEC and Y.1541-QoSM drafts, comments were > inter-related. You probably have not noticed it. Let me explain as follows: > > 1. QSPEC draft must NOT contain any extensions of Y.1541 > parameters. It must be a "generic" QSPEC draft. Any extensions of Y.1541 > is done here is INCOMPLETE as you can see the other draft. > > 2. The Y.1541-QoSM draft should be the only draft that MUST take > care of all extensions of all parameters of QSPEC. > > 3. Similar is the case should be for the DiffServ network. > > Best regards, > > Radhika > > ------------------------------------------------------ > > * Y.1541 QoSM > > ------------- > > Slides are available at: > > http://www3.ietf.org/proceedings/06mar/slides/nsis-8.ppt > > - Jerry Ash: No updates; > > Completed WGLC, but had no comments, > > so probably not 'successfully compeleted WGLC'. > > May need revisions based on QoS NSLP and QSpec discussions. > > - Hannes: Reviewed the document and it looks good, > > and only some small fixes are needed. > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Sun Apr 09 14:32:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSehq-0001eY-6u; Sun, 09 Apr 2006 14:32:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSeho-0001eS-CW for nsis@ietf.org; Sun, 09 Apr 2006 14:32:12 -0400 Received: from mclmx.mail.saic.com ([149.8.64.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FSeho-0000cm-0F for nsis@ietf.org; Sun, 09 Apr 2006 14:32:12 -0400 Received: from 0015-its-ieg02.mail.saic.com ([149.8.64.21] [149.8.64.21]) by mclmx.mail.saic.com; Sun, 9 Apr 2006 14:32:00 -0400 Received: from mcl-its-exig01.mail.saic.com ([149.8.64.12]) by 0015-its-ieg02.mail.saic.com (SMSSMTP 4.0.5.66) with SMTP id M2006040914320014409 ; Sun, 09 Apr 2006 14:32:00 -0400 Received: by mcl-its-exig01.mail.saic.com with Internet Mail Service (5.5.2657.72) id ; Sun, 9 Apr 2006 14:32:00 -0400 Message-Id: <62D92A9A02BCC845B202323D49A48426230D92@0591-ITS-EXMP02.us.saic.com> From: "Roy, Radhika R." To: Hannes.Tschofenig@gmx.net, "Roy, Radhika R." Subject: RE: [NSIS] Re: Updated IETF#65 Meeting Minutes Date: Sun, 9 Apr 2006 14:31:57 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) content-class: urn:content-classes:message X-Spam-Score: 0.0 (/) X-Scan-Signature: 07e9b4af03a165a413ec6e4d37ae537b Cc: NSIS X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0760900933==" Errors-To: nsis-bounces@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============0760900933== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C65C03.E253A45B" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C65C03.E253A45B Content-Type: text/plain; charset="iso-8859-1" Hi, Hannes: I dot NOT know what you exactly mean "during" the meeting. What I am saying is this: I sent these comments in the NSIS mailing list BEFORE the meeting as I could NOT attend the meeting. In any even, please add these comments of mine NOW as a complete package of IETF #65 meeting. Best regards, Radhika -----Original Message----- From: Hannes.Tschofenig@gmx.net [mailto:Hannes.Tschofenig@gmx.net ] Sent: Sunday, April 09, 2006 1:03 PM To: Roy, Radhika R. Cc: NSIS Subject: Re: [NSIS] Re: Updated IETF#65 Meeting Minutes Hi Roy, I went through the QSPEC and the Y.1541-QoSM meeting minutes again and have to state that they are correct. None of the issues listed below have been mentioned during the meeting. Ciao Hannes Roy, Radhika R. wrote: > Hi, Hannes and all: > > With respect to QSPEC and Y.1541-QoSM drafts, comments were > inter-related. You probably have not noticed it. Let me explain as follows: > > 1. QSPEC draft must NOT contain any extensions of Y.1541 > parameters. It must be a "generic" QSPEC draft. Any extensions of Y.1541 > is done here is INCOMPLETE as you can see the other draft. > > 2. The Y.1541-QoSM draft should be the only draft that MUST take > care of all extensions of all parameters of QSPEC. > > 3. Similar is the case should be for the DiffServ network. > > Best regards, > > Radhika > > ------------------------------------------------------ > > * Y.1541 QoSM > > ------------- > > Slides are available at: > > http://www3.ietf.org/proceedings/06mar/slides/nsis-8.ppt > > - Jerry Ash: No updates; > > Completed WGLC, but had no comments, > > so probably not 'successfully compeleted WGLC'. > > May need revisions based on QoS NSLP and QSpec discussions. > > - Hannes: Reviewed the document and it looks good, > > and only some small fixes are needed. > ------_=_NextPart_001_01C65C03.E253A45B Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [NSIS] Re: Updated IETF#65 Meeting Minutes

Hi, Hannes:

I dot NOT know what you = exactly mean "during" the = meeting. = What I am saying is this: I = sent these comments in the NSIS mailing list BEFORE the meeting as I = could NOT attend the meeting.

In any even, please = add these comments of = mine = NOW as a complete package of IETF #65 meeting.

Best regards,

Radhika

-----Original Message-----
From: Hannes.Tschofenig@gmx.net [mailto:Hannes.Tschofenig@gmx.n= et]
Sent: Sunday, April 09, 2006 1:03 PM
To: Roy, Radhika R.
Cc: NSIS
Subject: Re: [NSIS] Re: Updated IETF#65 Meeting = Minutes

Hi Roy,

I went through the QSPEC and the Y.1541-QoSM meeting minutes = again and

have to state that they are correct.

None of the issues listed below have been mentioned during the = meeting.

Ciao

Hannes

Roy, Radhika R. wrote:

> Hi, Hannes and all:

>

> With respect to QSPEC and Y.1541-QoSM drafts, comments were =

> inter-related. You probably have not noticed it. Let me = explain as follows:

>

> 1.      QSPEC draft must NOT = contain any extensions of Y.1541

> parameters. It must be a "generic" QSPEC draft. = Any extensions of Y.1541

> is done here is INCOMPLETE as you can see the other = draft.

>

> 2.      The Y.1541-QoSM draft = should be the only draft that MUST take

> care of all extensions of all parameters of = QSPEC.

>

> 3.      Similar is the case should = be for the DiffServ network.

>

> Best regards,

>

> Radhika

>

> = ------------------------------------------------------

=

>

> * Y.1541 QoSM

>

> -------------

>

> Slides are available at:

>

> http:/= /www3.ietf.org/proceedings/06mar/slides/nsis-8.ppt

=

>

> - Jerry Ash: No updates;

>

> Completed WGLC, but had no comments,

>

> so probably not 'successfully compeleted = WGLC'.

>

> May need revisions based on QoS NSLP and QSpec = discussions.

>

> - Hannes: Reviewed the document and it looks = good,

>

> and only some small fixes are needed.

>

------_=_NextPart_001_01C65C03.E253A45B-- --===============0760900933== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis --===============0760900933==-- From nsis-bounces@ietf.org Sun Apr 09 14:44:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSetr-0007aK-UL; Sun, 09 Apr 2006 14:44:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSetq-0007aF-5r for nsis@ietf.org; Sun, 09 Apr 2006 14:44:38 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FSetp-0001Df-Hf for nsis@ietf.org; Sun, 09 Apr 2006 14:44:38 -0400 Received: (qmail invoked by alias); 09 Apr 2006 18:44:36 -0000 Received: from p54985DB6.dip.t-dialin.net (EHLO [192.168.2.33]) [84.152.93.182] by mail.gmx.net (mp041) with SMTP; 09 Apr 2006 20:44:36 +0200 X-Authenticated: #29516787 Message-ID: <4439560E.9020005@gmx.net> Date: Sun, 09 Apr 2006 20:44:30 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Roy, Radhika R." Subject: Re: [NSIS] Re: Updated IETF#65 Meeting Minutes References: <62D92A9A02BCC845B202323D49A48426230D92@0591-ITS-EXMP02.us.saic.com> In-Reply-To: <62D92A9A02BCC845B202323D49A48426230D92@0591-ITS-EXMP02.us.saic.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c Cc: NSIS X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Roy, I am secretary of the working group already for some time and I do the same stuff every time. Discussions during the working group session are included in the meeting minutes. Comments posted on Jabber are already covered in the jabber log. I use the Jabber log file sometimes to improve the meeting minutes (if the minute taker gave a presentation at that time, was sleeping, gave comments on the mike, etc. ). I do not provide a summary of the meeting nor do I capture discussions outside the NSIS WG session. Your comment was sent to the mailing list already and does not need to be added to the meeting minutes. Your WGLC comments will surely be captured with an upcomming draft update. Ciao Hannes Roy, Radhika R. wrote: > Hi, Hannes: > > I dot NOT know what you exactly mean "during" the meeting. What I am > saying is this: I sent these comments in the NSIS mailing list BEFORE > the meeting as I could NOT attend the meeting. > > In any even, please add these comments of mine NOW as a complete package > of IETF #65 meeting. > > Best regards, > > Radhika > > -----Original Message----- > From: Hannes.Tschofenig@gmx.net [mailto:Hannes.Tschofenig@gmx.net] > Sent: Sunday, April 09, 2006 1:03 PM > To: Roy, Radhika R. > Cc: NSIS > Subject: Re: [NSIS] Re: Updated IETF#65 Meeting Minutes > > Hi Roy, > > I went through the QSPEC and the Y.1541-QoSM meeting minutes again and > > have to state that they are correct. > > None of the issues listed below have been mentioned during the meeting. > > Ciao > > Hannes > > Roy, Radhika R. wrote: > >> Hi, Hannes and all: > >> > >> With respect to QSPEC and Y.1541-QoSM drafts, comments were > >> inter-related. You probably have not noticed it. Let me explain as > follows: > >> > >> 1. QSPEC draft must NOT contain any extensions of Y.1541 > >> parameters. It must be a "generic" QSPEC draft. Any extensions of Y.1541 > >> is done here is INCOMPLETE as you can see the other draft. > >> > >> 2. The Y.1541-QoSM draft should be the only draft that MUST take > >> care of all extensions of all parameters of QSPEC. > >> > >> 3. Similar is the case should be for the DiffServ network. > >> > >> Best regards, > >> > >> Radhika > >> > >> ------------------------------------------------------ > >> > >> * Y.1541 QoSM > >> > >> ------------- > >> > >> Slides are available at: > >> > >> http://www3.ietf.org/proceedings/06mar/slides/nsis-8.ppt > >> > >> - Jerry Ash: No updates; > >> > >> Completed WGLC, but had no comments, > >> > >> so probably not 'successfully compeleted WGLC'. > >> > >> May need revisions based on QoS NSLP and QSpec discussions. > >> > >> - Hannes: Reviewed the document and it looks good, > >> > >> and only some small fixes are needed. > >> > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Sun Apr 09 15:01:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSf9o-0007BM-4U; Sun, 09 Apr 2006 15:01:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSf9m-0007BH-SF for nsis@ietf.org; Sun, 09 Apr 2006 15:01:06 -0400 Received: from mclmx2.mail.saic.com ([149.8.64.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FSf9m-0002AX-JC for nsis@ietf.org; Sun, 09 Apr 2006 15:01:06 -0400 Received: from 0015-its-ieg01.mail.saic.com ([149.8.64.21] [149.8.64.21]) by mclmx2.mail.saic.com; Sun, 9 Apr 2006 15:00:14 -0400 Received: from mcl-its-exig01.mail.saic.com ([149.8.64.12]) by 0015-its-ieg01.mail.saic.com (SMSSMTP 4.0.5.66) with SMTP id M2006040915001402485 ; Sun, 09 Apr 2006 15:00:14 -0400 Received: by mcl-its-exig01.mail.saic.com with Internet Mail Service (5.5.2657.72) id ; Sun, 9 Apr 2006 15:00:14 -0400 Message-Id: <62D92A9A02BCC845B202323D49A48426230D93@0591-ITS-EXMP02.us.saic.com> From: "Roy, Radhika R." To: Hannes.Tschofenig@gmx.net Subject: RE: [NSIS] Re: Updated IETF#65 Meeting Minutes Date: Sun, 9 Apr 2006 15:00:09 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) content-class: urn:content-classes:message Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: cd3fc8e909678b38737fc606dec187f0 Cc: NSIS X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi, Hannes: You might be right. However, other WGs have also provisions to include the comments when people provide comments via emails on the drafts that are discussed in the meeting because many folks are not able to attend the meeting. In any events, if the comments are taken, we are done. That's all we want so that people do not say that no comments were provided as a part of the WGLC etc. Best regards, Radhika -----Original Message----- From: Hannes.Tschofenig@gmx.net [mailto:Hannes.Tschofenig@gmx.net] Sent: Sunday, April 09, 2006 2:45 PM To: Roy, Radhika R. Cc: NSIS Subject: Re: [NSIS] Re: Updated IETF#65 Meeting Minutes Hi Roy, I am secretary of the working group already for some time and I do the same stuff every time. Discussions during the working group session are included in the meeting minutes. Comments posted on Jabber are already covered in the jabber log. I use the Jabber log file sometimes to improve the meeting minutes (if the minute taker gave a presentation at that time, was sleeping, gave comments on the mike, etc. ). I do not provide a summary of the meeting nor do I capture discussions outside the NSIS WG session. Your comment was sent to the mailing list already and does not need to be added to the meeting minutes. Your WGLC comments will surely be captured with an upcomming draft update. Ciao Hannes Roy, Radhika R. wrote: > Hi, Hannes: > > I dot NOT know what you exactly mean "during" the meeting. What I am > saying is this: I sent these comments in the NSIS mailing list BEFORE > the meeting as I could NOT attend the meeting. > > In any even, please add these comments of mine NOW as a complete package > of IETF #65 meeting. > > Best regards, > > Radhika > > -----Original Message----- > From: Hannes.Tschofenig@gmx.net [mailto:Hannes.Tschofenig@gmx.net] > Sent: Sunday, April 09, 2006 1:03 PM > To: Roy, Radhika R. > Cc: NSIS > Subject: Re: [NSIS] Re: Updated IETF#65 Meeting Minutes > > Hi Roy, > > I went through the QSPEC and the Y.1541-QoSM meeting minutes again and > > have to state that they are correct. > > None of the issues listed below have been mentioned during the meeting. > > Ciao > > Hannes > > Roy, Radhika R. wrote: > >> Hi, Hannes and all: > >> > >> With respect to QSPEC and Y.1541-QoSM drafts, comments were > >> inter-related. You probably have not noticed it. Let me explain as > follows: > >> > >> 1. QSPEC draft must NOT contain any extensions of Y.1541 > >> parameters. It must be a "generic" QSPEC draft. Any extensions of Y.1541 > >> is done here is INCOMPLETE as you can see the other draft. > >> > >> 2. The Y.1541-QoSM draft should be the only draft that MUST take > >> care of all extensions of all parameters of QSPEC. > >> > >> 3. Similar is the case should be for the DiffServ network. > >> > >> Best regards, > >> > >> Radhika > >> > >> ------------------------------------------------------ > >> > >> * Y.1541 QoSM > >> > >> ------------- > >> > >> Slides are available at: > >> > >> http://www3.ietf.org/proceedings/06mar/slides/nsis-8.ppt > >> > >> - Jerry Ash: No updates; > >> > >> Completed WGLC, but had no comments, > >> > >> so probably not 'successfully compeleted WGLC'. > >> > >> May need revisions based on QoS NSLP and QSpec discussions. > >> > >> - Hannes: Reviewed the document and it looks good, > >> > >> and only some small fixes are needed. > >> > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Apr 10 02:16:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSpgu-00013k-Cl; Mon, 10 Apr 2006 02:16:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSpgs-000109-Na for nsis@ietf.org; Mon, 10 Apr 2006 02:15:58 -0400 Received: from mgw-ext13.nokia.com ([131.228.20.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FSpf9-00019q-Nt for nsis@ietf.org; Mon, 10 Apr 2006 02:14:13 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext13.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k3A6D699001025 for ; Mon, 10 Apr 2006 09:13:06 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Apr 2006 09:13:58 +0300 Received: from esebe100.NOE.Nokia.com ([172.21.138.118]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Apr 2006 09:13:57 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 10 Apr 2006 09:13:58 +0300 Message-ID: <615BD9B54CB01B41838C323DB9E91AAB0C929B@esebe100.NOE.Nokia.com> In-Reply-To: <615BD9B54CB01B41838C323DB9E91AAB0C9299@esebe100.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WGLC on QoS NSLP and QSPEC template Thread-Index: AcZcZXcmOK+//erYRPGT2VxJYIig9wAAFQFw From: To: X-OriginalArrivalTime: 10 Apr 2006 06:13:58.0039 (UTC) FILETIME=[F3EB8A70:01C65C65] X-Spam-Score: 0.2 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Subject: [NSIS] WGLC on QoS NSLP and QSPEC template X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Obviously, I meant the QSPEC template document, not QoSM. John >-----Original Message----- >From: Loughney John (Nokia-NRC/Helsinki)=20 >Sent: 10 April, 2006 09:10 >To: nsis@ietf.org >Subject: WGLC on QoS NSLP and QOSM > >Hi all, > >The WGLC ended on both the QoS NSLP and QOSM. A number of=20 >issues have been identified and were discussed at IETF 65. The=20 >authors are revising the documents, and after the documents=20 >are resubmitted, we'll check the change log, and see if=20 >another WGLC is needed, or if the document is ready for=20 >submission to the IESG. > >thanks, >John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Apr 10 02:16:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSph1-00016n-JE; Mon, 10 Apr 2006 02:16:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSpgy-000109-EN for nsis@ietf.org; Mon, 10 Apr 2006 02:16:04 -0400 Received: from mgw-ext14.nokia.com ([131.228.20.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FSpdE-00014b-Em for nsis@ietf.org; Mon, 10 Apr 2006 02:12:16 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext14.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k3A6BAYH027591 for ; Mon, 10 Apr 2006 09:11:11 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Apr 2006 09:12:11 +0300 Received: from esebe100.NOE.Nokia.com ([172.21.138.118]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Apr 2006 09:12:10 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 10 Apr 2006 09:12:11 +0300 Message-ID: <615BD9B54CB01B41838C323DB9E91AAB0C929A@esebe100.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WGLC on RMD & Y.1541 Thread-Index: AcZcZbQ5ENYCrXuDTPSBwviR+gmn8A== From: To: X-OriginalArrivalTime: 10 Apr 2006 06:12:10.0965 (UTC) FILETIME=[B4195850:01C65C65] X-Spam-Score: 0.2 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Subject: [NSIS] WGLC on RMD & Y.1541 X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi all, The WGLC ended on both the RMD and Y.1541 QoSM documents. A number of issues have been identified and were discussed at IETF 65. Additionally, there were very few comments received on these documents. These documents cannot procede without review. If you have read the document and think that they are ready, then please let us know. The authors are revising the documents, and after the documents are resubmitted, we'll need another WGLC is needed befor the documents are submitted to the IESG. thanks, John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Apr 10 02:17:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSphu-0001ne-13; Mon, 10 Apr 2006 02:17:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSpgy-000109-LV for nsis@ietf.org; Mon, 10 Apr 2006 02:16:04 -0400 Received: from mgw-ext14.nokia.com ([131.228.20.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FSpba-0000vj-Kg for nsis@ietf.org; Mon, 10 Apr 2006 02:10:34 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext14.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k3A69Sg9027053 for ; Mon, 10 Apr 2006 09:09:28 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Apr 2006 09:10:29 +0300 Received: from esebe100.NOE.Nokia.com ([172.21.138.118]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Apr 2006 09:10:29 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 10 Apr 2006 09:10:28 +0300 Message-ID: <615BD9B54CB01B41838C323DB9E91AAB0C9299@esebe100.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WGLC on QoS NSLP and QOSM Thread-Index: AcZcZXcmOK+//erYRPGT2VxJYIig9w== From: To: X-OriginalArrivalTime: 10 Apr 2006 06:10:29.0299 (UTC) FILETIME=[77805830:01C65C65] X-Spam-Score: 0.2 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Subject: [NSIS] WGLC on QoS NSLP and QOSM X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi all, The WGLC ended on both the QoS NSLP and QOSM. A number of issues have been identified and were discussed at IETF 65. The authors are revising the documents, and after the documents are resubmitted, we'll check the change log, and see if another WGLC is needed, or if the document is ready for submission to the IESG. thanks, John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Apr 10 03:28:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSqoZ-0007Pw-Qg; Mon, 10 Apr 2006 03:27:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSqoJ-0007JT-Pa for nsis@ietf.org; Mon, 10 Apr 2006 03:27:43 -0400 Received: from mgw-ext11.nokia.com ([131.228.20.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FSqhV-0003CE-RE for nsis@ietf.org; Mon, 10 Apr 2006 03:20:44 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext11.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k3A7IW1F012575; Mon, 10 Apr 2006 10:18:38 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Apr 2006 10:20:39 +0300 Received: from esebe100.NOE.Nokia.com ([172.21.138.118]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Apr 2006 10:20:39 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] Re: Updated IETF#65 Meeting Minutes Date: Mon, 10 Apr 2006 10:20:38 +0300 Message-ID: <615BD9B54CB01B41838C323DB9E91AAB0C92A0@esebe100.NOE.Nokia.com> In-Reply-To: <62D92A9A02BCC845B202323D49A48426230D93@0591-ITS-EXMP02.us.saic.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] Re: Updated IETF#65 Meeting Minutes Thread-Index: AcZcCBJE9+U28q/9TW+QR/KB2hFH4QAZbaCw From: To: , X-OriginalArrivalTime: 10 Apr 2006 07:20:39.0079 (UTC) FILETIME=[44B9CB70:01C65C6F] X-Spam-Score: 0.2 (/) X-Scan-Signature: 97c820c82c68af374c4e382a80dc5017 Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Radhika, The mailing list is the 'official' mechanism for submitting issues. It is hard to have a discussion on email comments during a meeting, unless there =20 is someone to discuss it from both sides. You have made the comments on Q.1541 before, however I haven't seen comments in support of your interpretation of the QSPEC. If people in the working group support your view point, I'd really like them to speak up, so that we can determine if there is consensus behind Radhika's concerns. It would be useful to know if agree or disagree with Radhika. John >-----Original Message----- >From: ext Roy, Radhika R. [mailto:RADHIKA.R.ROY@saic.com]=20 >Sent: 09 April, 2006 22:00 >To: Hannes.Tschofenig@gmx.net >Cc: NSIS >Subject: RE: [NSIS] Re: Updated IETF#65 Meeting Minutes > >Hi, Hannes: > >You might be right. > >However, other WGs have also provisions to include the=20 >comments when people provide comments via emails on the drafts=20 >that are discussed in the meeting because many folks are not=20 >able to attend the meeting. > >In any events, if the comments are taken, we are done. That's=20 >all we want so that people do not say that no comments were=20 >provided as a part of the WGLC etc. > >Best regards, >Radhika > >-----Original Message----- >From: Hannes.Tschofenig@gmx.net [mailto:Hannes.Tschofenig@gmx.net] >Sent: Sunday, April 09, 2006 2:45 PM >To: Roy, Radhika R. >Cc: NSIS >Subject: Re: [NSIS] Re: Updated IETF#65 Meeting Minutes > >Hi Roy, > >I am secretary of the working group already for some time and=20 >I do the same stuff every time. Discussions during the working=20 >group session are included in the meeting minutes. Comments=20 >posted on Jabber are already covered in the jabber log. I use=20 >the Jabber log file sometimes to improve the meeting minutes=20 >(if the minute taker gave a presentation at that time, was=20 >sleeping, gave comments on the mike, etc. ). > >I do not provide a summary of the meeting nor do I capture=20 >discussions outside the NSIS WG session. > >Your comment was sent to the mailing list already and does not=20 >need to be added to the meeting minutes. Your WGLC comments=20 >will surely be captured with an upcomming draft update. > >Ciao >Hannes > >Roy, Radhika R. wrote: >> Hi, Hannes: >>=20 >> I dot NOT know what you exactly mean "during" the meeting. What I am=20 >> saying is this: I sent these comments in the NSIS mailing=20 >list BEFORE=20 >> the meeting as I could NOT attend the meeting. >>=20 >> In any even, please add these comments of mine NOW as a complete >package=20 >> of IETF #65 meeting. >>=20 >> Best regards, >>=20 >> Radhika >>=20 >> -----Original Message----- >> From: Hannes.Tschofenig@gmx.net [mailto:Hannes.Tschofenig@gmx.net] >> Sent: Sunday, April 09, 2006 1:03 PM >> To: Roy, Radhika R. >> Cc: NSIS >> Subject: Re: [NSIS] Re: Updated IETF#65 Meeting Minutes >>=20 >> Hi Roy, >>=20 >> I went through the QSPEC and the Y.1541-QoSM meeting minutes=20 >again and >>=20 >> have to state that they are correct. >>=20 >> None of the issues listed below have been mentioned during the >meeting. >>=20 >> Ciao >>=20 >> Hannes >>=20 >> Roy, Radhika R. wrote: >>=20 >>> Hi, Hannes and all: >>=20 >>> >>=20 >>> With respect to QSPEC and Y.1541-QoSM drafts, comments were >>=20 >>> inter-related. You probably have not noticed it. Let me explain as >> follows: >>=20 >>> >>=20 >>> 1. QSPEC draft must NOT contain any extensions of Y.1541 >>=20 >>> parameters. It must be a "generic" QSPEC draft. Any extensions of >Y.1541 >>=20 >>> is done here is INCOMPLETE as you can see the other draft. >>=20 >>> >>=20 >>> 2. The Y.1541-QoSM draft should be the only draft that MUST >take >>=20 >>> care of all extensions of all parameters of QSPEC. >>=20 >>> >>=20 >>> 3. Similar is the case should be for the DiffServ network. >>=20 >>> >>=20 >>> Best regards, >>=20 >>> >>=20 >>> Radhika >>=20 >>> >>=20 >>> ------------------------------------------------------ >>=20 >>> >>=20 >>> * Y.1541 QoSM >>=20 >>> >>=20 >>> ------------- >>=20 >>> >>=20 >>> Slides are available at: >>=20 >>> >>=20 >>> http://www3.ietf.org/proceedings/06mar/slides/nsis-8.ppt >>=20 >>> >>=20 >>> - Jerry Ash: No updates; >>=20 >>> >>=20 >>> Completed WGLC, but had no comments, >>=20 >>> >>=20 >>> so probably not 'successfully compeleted WGLC'. >>=20 >>> >>=20 >>> May need revisions based on QoS NSLP and QSpec discussions. >>=20 >>> >>=20 >>> - Hannes: Reviewed the document and it looks good, >>=20 >>> >>=20 >>> and only some small fixes are needed. >>=20 >>> >>=20 > > >_______________________________________________ >nsis mailing list >nsis@ietf.org >https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Apr 10 06:45:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSttP-00057C-Fk; Mon, 10 Apr 2006 06:45:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSttO-000572-RK for nsis@ietf.org; Mon, 10 Apr 2006 06:45:10 -0400 Received: from mclmx.mail.saic.com ([149.8.64.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FSttO-0002Uj-HE for nsis@ietf.org; Mon, 10 Apr 2006 06:45:10 -0400 Received: from 0015-its-ieg01.mail.saic.com ([149.8.64.21] [149.8.64.21]) by mclmx.mail.saic.com; Mon, 10 Apr 2006 06:45:07 -0400 Received: from mcl-its-exig01.mail.saic.com ([149.8.64.12]) by 0015-its-ieg01.mail.saic.com (SMSSMTP 4.0.5.66) with SMTP id M2006041006450712439 ; Mon, 10 Apr 2006 06:45:07 -0400 Received: by mcl-its-exig01.mail.saic.com with Internet Mail Service (5.5.2657.72) id ; Mon, 10 Apr 2006 06:45:07 -0400 Message-Id: <62D92A9A02BCC845B202323D49A48426209C2C@0591-ITS-EXMP02.us.saic.com> From: "Roy, Radhika R." To: john.loughney@nokia.com, RADHIKA.R.ROY@saic.com, Hannes.Tschofenig@gmx.net Subject: RE: [NSIS] Re: Updated IETF#65 Meeting Minutes Date: Mon, 10 Apr 2006 06:41:02 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) content-class: urn:content-classes:message Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: e1924de3f9fb68e58c31920136007eb1 Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi, John: Great! If anyone can provide better resaon for the comments that I have provided, let us see what are those. I have also NOT seen any disagreement with anyone with the comments that I have provided. So, I think that my comments must be accepted. Best regards, Radhika _____ From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] Sent: Mon 4/10/2006 3:20 AM To: RADHIKA.R.ROY@saic.com; Hannes.Tschofenig@gmx.net Cc: nsis@ietf.org Subject: RE: [NSIS] Re: Updated IETF#65 Meeting Minutes Radhika, The mailing list is the 'official' mechanism for submitting issues. It is hard to have a discussion on email comments during a meeting, unless there is someone to discuss it from both sides. You have made the comments on Q.1541 before, however I haven't seen comments in support of your interpretation of the QSPEC. If people in the working group support your view point, I'd really like them to speak up, so that we can determine if there is consensus behind Radhika's concerns. It would be useful to know if agree or disagree with Radhika. John >-----Original Message----- >From: ext Roy, Radhika R. [mailto:RADHIKA.R.ROY@saic.com ] >Sent: 09 April, 2006 22:00 >To: Hannes.Tschofenig@gmx.net >Cc: NSIS >Subject: RE: [NSIS] Re: Updated IETF#65 Meeting Minutes > >Hi, Hannes: > >You might be right. > >However, other WGs have also provisions to include the >comments when people provide comments via emails on the drafts >that are discussed in the meeting because many folks are not >able to attend the meeting. > >In any events, if the comments are taken, we are done. That's >all we want so that people do not say that no comments were >provided as a part of the WGLC etc. > >Best regards, >Radhika > >-----Original Message----- >From: Hannes.Tschofenig@gmx.net [mailto:Hannes.Tschofenig@gmx.net ] >Sent: Sunday, April 09, 2006 2:45 PM >To: Roy, Radhika R. >Cc: NSIS >Subject: Re: [NSIS] Re: Updated IETF#65 Meeting Minutes > >Hi Roy, > >I am secretary of the working group already for some time and >I do the same stuff every time. Discussions during the working >group session are included in the meeting minutes. Comments >posted on Jabber are already covered in the jabber log. I use >the Jabber log file sometimes to improve the meeting minutes >(if the minute taker gave a presentation at that time, was >sleeping, gave comments on the mike, etc. ). > >I do not provide a summary of the meeting nor do I capture >discussions outside the NSIS WG session. > >Your comment was sent to the mailing list already and does not >need to be added to the meeting minutes. Your WGLC comments >will surely be captured with an upcomming draft update. > >Ciao >Hannes > >Roy, Radhika R. wrote: >> Hi, Hannes: >> >> I dot NOT know what you exactly mean "during" the meeting. What I am >> saying is this: I sent these comments in the NSIS mailing >list BEFORE >> the meeting as I could NOT attend the meeting. >> >> In any even, please add these comments of mine NOW as a complete >package >> of IETF #65 meeting. >> >> Best regards, >> >> Radhika >> >> -----Original Message----- >> From: Hannes.Tschofenig@gmx.net [mailto:Hannes.Tschofenig@gmx.net ] >> Sent: Sunday, April 09, 2006 1:03 PM >> To: Roy, Radhika R. >> Cc: NSIS >> Subject: Re: [NSIS] Re: Updated IETF#65 Meeting Minutes >> >> Hi Roy, >> >> I went through the QSPEC and the Y.1541-QoSM meeting minutes >again and >> >> have to state that they are correct. >> >> None of the issues listed below have been mentioned during the >meeting. >> >> Ciao >> >> Hannes >> >> Roy, Radhika R. wrote: >> >>> Hi, Hannes and all: >> >>> >> >>> With respect to QSPEC and Y.1541-QoSM drafts, comments were >> >>> inter-related. You probably have not noticed it. Let me explain as >> follows: >> >>> >> >>> 1. QSPEC draft must NOT contain any extensions of Y.1541 >> >>> parameters. It must be a "generic" QSPEC draft. Any extensions of >Y.1541 >> >>> is done here is INCOMPLETE as you can see the other draft. >> >>> >> >>> 2. The Y.1541-QoSM draft should be the only draft that MUST >take >> >>> care of all extensions of all parameters of QSPEC. >> >>> >> >>> 3. Similar is the case should be for the DiffServ network. >> >>> >> >>> Best regards, >> >>> >> >>> Radhika >> >>> >> >>> ------------------------------------------------------ >> >>> >> >>> * Y.1541 QoSM >> >>> >> >>> ------------- >> >>> >> >>> Slides are available at: >> >>> >> >>> http://www3.ietf.org/proceedings/06mar/slides/nsis-8.ppt >> >>> >> >>> - Jerry Ash: No updates; >> >>> >> >>> Completed WGLC, but had no comments, >> >>> >> >>> so probably not 'successfully compeleted WGLC'. >> >>> >> >>> May need revisions based on QoS NSLP and QSpec discussions. >> >>> >> >>> - Hannes: Reviewed the document and it looks good, >> >>> >> >>> and only some small fixes are needed. >> >>> >> > > >_______________________________________________ >nsis mailing list >nsis@ietf.org >https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Apr 10 06:53:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSu0x-0007TJ-K3; Mon, 10 Apr 2006 06:52:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSu0w-0007TE-CB for nsis@ietf.org; Mon, 10 Apr 2006 06:52:58 -0400 Received: from mclmx.mail.saic.com ([149.8.64.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FSu0w-0002rA-5G for nsis@ietf.org; Mon, 10 Apr 2006 06:52:58 -0400 Received: from 0015-its-ieg02.mail.saic.com ([149.8.64.21] [149.8.64.21]) by mclmx.mail.saic.com; Mon, 10 Apr 2006 06:52:56 -0400 Received: from mcl-its-exig01.mail.saic.com ([149.8.64.12]) by 0015-its-ieg02.mail.saic.com (SMSSMTP 4.0.5.66) with SMTP id M2006041006525629163 ; Mon, 10 Apr 2006 06:52:56 -0400 Received: by mcl-its-exig01.mail.saic.com with Internet Mail Service (5.5.2657.72) id ; Mon, 10 Apr 2006 06:52:56 -0400 Message-Id: <62D92A9A02BCC845B202323D49A48426209C2D@0591-ITS-EXMP02.us.saic.com> From: "Roy, Radhika R." To: john.loughney@nokia.com, nsis@ietf.org Subject: RE: [NSIS] WGLC on RMD & Y.1541 Date: Mon, 10 Apr 2006 06:52:54 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) content-class: urn:content-classes:message Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org John: The comments that I have provided on this yesterday (in the context of IETF # 65 meeting minutes) need to be addressed in the Y.1541 draft. Basically, this document needs to be a stand-alone document for extensions of QSPEC parameters for Y.1541, and the main QSPEC draft MUST be a generic draft without any specific extensions for any specs like Y.1541, etc. If any help is needed to modify the document per above suggestion, please let me know. I will volunteer to do so. Best regards, Radhika _____ From: nsis-bounces@ietf.org on behalf of john.loughney@nokia.com Sent: Mon 4/10/2006 2:12 AM To: nsis@ietf.org Subject: [NSIS] WGLC on RMD & Y.1541 Hi all, The WGLC ended on both the RMD and Y.1541 QoSM documents. A number of issues have been identified and were discussed at IETF 65. Additionally, there were very few comments received on these documents. These documents cannot procede without review. If you have read the document and think that they are ready, then please let us know. The authors are revising the documents, and after the documents are resubmitted, we'll need another WGLC is needed befor the documents are submitted to the IESG. 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 nsis-bounces@ietf.org Mon Apr 10 07:03:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSuAr-000369-6z; Mon, 10 Apr 2006 07:03:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSuAp-000364-U4 for nsis@ietf.org; Mon, 10 Apr 2006 07:03:11 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FSuAp-0003VB-9N for nsis@ietf.org; Mon, 10 Apr 2006 07:03:11 -0400 Received: (qmail invoked by alias); 10 Apr 2006 11:03:09 -0000 Received: from socks2.netz.sbs.de (EHLO [192.35.17.25]) [192.35.17.25] by mail.gmx.net (mp038) with SMTP; 10 Apr 2006 13:03:09 +0200 X-Authenticated: #29516787 Message-ID: <443A3B69.7090505@gmx.net> Date: Mon, 10 Apr 2006 13:03:05 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Roy, Radhika R." Subject: Re: [NSIS] Re: Updated IETF#65 Meeting Minutes References: <62D92A9A02BCC845B202323D49A48426209C2C@0591-ITS-EXMP02.us.saic.com> In-Reply-To: <62D92A9A02BCC845B202323D49A48426209C2C@0591-ITS-EXMP02.us.saic.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: c2e58d9873012c90703822e287241385 Cc: john.loughney@nokia.com, nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Roy, if your review comments are not discussed on the mailing list then it does not mean that they must be accepted. You know the IETF process: rough consensus (and running code). Regarding to your comments: > 1. To clarify priority levels: What does it mean it mean? Is it for > media? Is it for call (e.g., SIP)? Or, is it for something? I guess in our discussions we concluded that the priority level does not relate to a SIP call itself (since these priority levels have e2e semantic). As such, the priority levels have the same semantic as those defined for RSVP. It might not hurt to add a few lines to the draft to reflect past discussions regarding this subject. In fact I was also confused about this issue in the past... > 2. To remove the implementation specific extensions that do not belong > to this "generic" draft > * Y.xxx specific extensions of QSPEC (It will go where Y.xxx > extensions of QSPEC draft is dealing). > * DiffServ specific extensions of QSPEC parameters (need to do a > separate draft like Y.xxxx as stated above) There are no implementation specific extensions in the draft. I think that the term "implementation" is wrong here. You are saying that you do not want to see the Y.1541 and the DiffServ classes in the document. Why do you think so? Ciao Hannes Roy, Radhika R. wrote: > Hi, John: > > Great! > > If anyone can provide better resaon for the comments that I have provided, > let us see what are those. > > I have also NOT seen any disagreement with anyone with the comments that I > have provided. > > So, I think that my comments must be accepted. > > Best regards, > Radhika > > _____ > > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > Sent: Mon 4/10/2006 3:20 AM > To: RADHIKA.R.ROY@saic.com; Hannes.Tschofenig@gmx.net > Cc: nsis@ietf.org > Subject: RE: [NSIS] Re: Updated IETF#65 Meeting Minutes > > > > Radhika, > > The mailing list is the 'official' mechanism for submitting issues. It > is > hard to have a discussion on email comments during a meeting, unless > there > is someone to discuss it from both sides. > > You have made the comments on Q.1541 before, however I haven't seen > comments > in support of your interpretation of the QSPEC. If people in the > working > group support your view point, I'd really like them to speak up, so that > we can determine if there is consensus behind Radhika's concerns. It > would > be useful to know if agree or disagree with Radhika. > > John > > >>-----Original Message----- >>From: ext Roy, Radhika R. [mailto:RADHIKA.R.ROY@saic.com > > ] > >>Sent: 09 April, 2006 22:00 >>To: Hannes.Tschofenig@gmx.net >>Cc: NSIS >>Subject: RE: [NSIS] Re: Updated IETF#65 Meeting Minutes >> >>Hi, Hannes: >> >>You might be right. >> >>However, other WGs have also provisions to include the >>comments when people provide comments via emails on the drafts >>that are discussed in the meeting because many folks are not >>able to attend the meeting. >> >>In any events, if the comments are taken, we are done. That's >>all we want so that people do not say that no comments were >>provided as a part of the WGLC etc. >> >>Best regards, >>Radhika >> >>-----Original Message----- >>From: Hannes.Tschofenig@gmx.net [mailto:Hannes.Tschofenig@gmx.net > > ] > >>Sent: Sunday, April 09, 2006 2:45 PM >>To: Roy, Radhika R. >>Cc: NSIS >>Subject: Re: [NSIS] Re: Updated IETF#65 Meeting Minutes >> >>Hi Roy, >> >>I am secretary of the working group already for some time and >>I do the same stuff every time. Discussions during the working >>group session are included in the meeting minutes. Comments >>posted on Jabber are already covered in the jabber log. I use >>the Jabber log file sometimes to improve the meeting minutes >>(if the minute taker gave a presentation at that time, was >>sleeping, gave comments on the mike, etc. ). >> >>I do not provide a summary of the meeting nor do I capture >>discussions outside the NSIS WG session. >> >>Your comment was sent to the mailing list already and does not >>need to be added to the meeting minutes. Your WGLC comments >>will surely be captured with an upcomming draft update. >> >>Ciao >>Hannes >> >>Roy, Radhika R. wrote: >> >>>Hi, Hannes: >>> >>>I dot NOT know what you exactly mean "during" the meeting. What I am >>>saying is this: I sent these comments in the NSIS mailing >> >>list BEFORE >> >>>the meeting as I could NOT attend the meeting. >>> >>>In any even, please add these comments of mine NOW as a complete >> >>package >> >>>of IETF #65 meeting. >>> >>>Best regards, >>> >>>Radhika >>> >>>-----Original Message----- >>>From: Hannes.Tschofenig@gmx.net [mailto:Hannes.Tschofenig@gmx.net > > ] > >>>Sent: Sunday, April 09, 2006 1:03 PM >>>To: Roy, Radhika R. >>>Cc: NSIS >>>Subject: Re: [NSIS] Re: Updated IETF#65 Meeting Minutes >>> >>>Hi Roy, >>> >>>I went through the QSPEC and the Y.1541-QoSM meeting minutes >> >>again and >> >>>have to state that they are correct. >>> >>>None of the issues listed below have been mentioned during the >> >>meeting. >> >>>Ciao >>> >>>Hannes >>> >>>Roy, Radhika R. wrote: >>> >>> >>>> Hi, Hannes and all: >>> >>>> With respect to QSPEC and Y.1541-QoSM drafts, comments were >>> >>>> inter-related. You probably have not noticed it. Let me explain as >>> >>>follows: >>> >>> >>>> 1. QSPEC draft must NOT contain any extensions of Y.1541 >>> >>>> parameters. It must be a "generic" QSPEC draft. Any extensions of >> >>Y.1541 >> >>>> is done here is INCOMPLETE as you can see the other draft. >>> >>>> 2. The Y.1541-QoSM draft should be the only draft that MUST >> >>take >> >>>> care of all extensions of all parameters of QSPEC. >>> >>>> 3. Similar is the case should be for the DiffServ network. >>> >>>> Best regards, >>> >>>> Radhika >>> >>>> ------------------------------------------------------ >>> >>>> * Y.1541 QoSM >>> >>>> ------------- >>> >>>> Slides are available at: >>> >>>> http://www3.ietf.org/proceedings/06mar/slides/nsis-8.ppt > > > >>>> - Jerry Ash: No updates; >>> >>>> Completed WGLC, but had no comments, >>> >>>> so probably not 'successfully compeleted WGLC'. >>> >>>> May need revisions based on QoS NSLP and QSpec discussions. >>> >>>> - Hannes: Reviewed the document and it looks good, >>> >>>> and only some small fixes are needed. >>> >> >>_______________________________________________ >>nsis mailing list >>nsis@ietf.org >>https://www1.ietf.org/mailman/listinfo/nsis > > > > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Apr 10 07:06:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSuDj-0004pb-CW; Mon, 10 Apr 2006 07:06:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSuDi-0004pW-P3 for nsis@ietf.org; Mon, 10 Apr 2006 07:06:10 -0400 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FSuDi-000410-BX for nsis@ietf.org; Mon, 10 Apr 2006 07:06:10 -0400 Received: (qmail invoked by alias); 10 Apr 2006 11:06:09 -0000 Received: from socks2.netz.sbs.de (EHLO [192.35.17.25]) [192.35.17.25] by mail.gmx.net (mp019) with SMTP; 10 Apr 2006 13:06:09 +0200 X-Authenticated: #29516787 Message-ID: <443A3C1C.6050502@gmx.net> Date: Mon, 10 Apr 2006 13:06:04 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Roy, Radhika R." Subject: Re: [NSIS] WGLC on RMD & Y.1541 References: <62D92A9A02BCC845B202323D49A48426209C2D@0591-ITS-EXMP02.us.saic.com> In-Reply-To: <62D92A9A02BCC845B202323D49A48426209C2D@0591-ITS-EXMP02.us.saic.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.1 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: john.loughney@nokia.com, nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Roy, my impression over the last year was that you are not unbiased when it comes to Y.1541. This is a problem. Now, you want to see the Y.1541 content moved to a separate document (to the Y.1541 QoSM draft). Can you motivate your desire to move this particular text to another document? Why not other parts? Ciao Hannes Roy, Radhika R. wrote: > John: > > The comments that I have provided on this yesterday (in the context > of IETF # 65 meeting minutes) need to be addressed in the Y.1541 > draft. > > Basically, this document needs to be a stand-alone document for > extensions of QSPEC parameters for Y.1541, and the main QSPEC draft > MUST be a generic draft without any specific extensions for any specs > like Y.1541, etc. > > If any help is needed to modify the document per above suggestion, > please let me know. I will volunteer to do so. > > Best regards, Radhika > > _____ > > From: nsis-bounces@ietf.org on behalf of john.loughney@nokia.com > Sent: Mon 4/10/2006 2:12 AM To: nsis@ietf.org Subject: [NSIS] WGLC on > RMD & Y.1541 > > > > Hi all, > > The WGLC ended on both the RMD and Y.1541 QoSM documents. A number of > issues have been identified and were discussed at IETF 65. > Additionally, there were very few comments received on these > documents. These documents cannot procede without review. If you > have read the document and think that they are ready, then please let > us know. The authors are revising the documents, and after the > documents are resubmitted, we'll need another WGLC is needed befor > the documents are submitted to the IESG. > > thanks, John > > _______________________________________________ nsis mailing list > nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis > > > > > _______________________________________________ nsis mailing list > nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Apr 10 07:55:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSuzX-0008Gf-2C; Mon, 10 Apr 2006 07:55:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSuzV-0008Ga-W4 for nsis@ietf.org; Mon, 10 Apr 2006 07:55:33 -0400 Received: from mclmx2.mail.saic.com ([149.8.64.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FSuzV-0005hc-ML for nsis@ietf.org; Mon, 10 Apr 2006 07:55:33 -0400 Received: from 0015-its-ieg02.mail.saic.com ([149.8.64.21] [149.8.64.21]) by mclmx2.mail.saic.com; Mon, 10 Apr 2006 07:55:20 -0400 Received: from mcl-its-exig01.mail.saic.com ([149.8.64.12]) by 0015-its-ieg02.mail.saic.com (SMSSMTP 4.0.5.66) with SMTP id M2006041007552000533 ; Mon, 10 Apr 2006 07:55:20 -0400 Received: by mcl-its-exig01.mail.saic.com with Internet Mail Service (5.5.2657.72) id ; Mon, 10 Apr 2006 07:55:20 -0400 Message-Id: <62D92A9A02BCC845B202323D49A48426209C2E@0591-ITS-EXMP02.us.saic.com> From: "Roy, Radhika R." To: Hannes Tschofenig , "Roy, Radhika R." Subject: RE: [NSIS] WGLC on RMD & Y.1541 Date: Mon, 10 Apr 2006 07:55:18 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) content-class: urn:content-classes:message Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 Cc: john.loughney@nokia.com, nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hannes: It is a good question to discuss in the mailing list. I appreciate your question. Let me explain again as follows: 1. QSPEC is a generic spec that can be used by any QoS models. So, this draft must be a stand-alone draft without dealing with any "specific" extensions of any "specific" QoS models. 2. It can be seen that many "specific" QoS models like Y.1541 may come in the future just by changing some values in parameters like delay, jitter, loss, etc. That does not mean we have extend our "generic" QSPEC draft again and again for those "specific" extensions. It is technically inconsistent to "mix" a generic draft with extensions of some "specific" QoS models. Is this clear? 3. The specific extensions of QSPEC parameters for Y.1541 and/or other QoS models in this generic draft is OUT-of-SCOPE. 4. It is can be easily seen that there are many extensions of QSPEC parameters are needed to have the complete implementation of Y.1541 QoS models as these have been addressed specific to Y.1541-QSPEC draft that is going through the WGLC. If this is so, why do we need to pollute the generic QSPEC draft with some "incomplete" extensions of QSPEC parameters for a "specific" Y.1451 QoS model? Why does this the "specific" QSPEC-Y.1541 draft MUST not be, like generic QSPEC draft, a stand-alone draft by its own merit? Hope that the above shows that there are enough technical reasons why I have been providing comments for a long time. I would appreciate if you would provide any good technical reason against all the comments that I have provided above. Best regards, Radhika _____ From: nsis-bounces@ietf.org on behalf of Hannes Tschofenig Sent: Mon 4/10/2006 7:06 AM To: Roy, Radhika R. Cc: john.loughney@nokia.com; nsis@ietf.org Subject: Re: [NSIS] WGLC on RMD & Y.1541 Hi Roy, my impression over the last year was that you are not unbiased when it comes to Y.1541. This is a problem. Now, you want to see the Y.1541 content moved to a separate document (to the Y.1541 QoSM draft). Can you motivate your desire to move this particular text to another document? Why not other parts? Ciao Hannes Roy, Radhika R. wrote: > John: > > The comments that I have provided on this yesterday (in the context > of IETF # 65 meeting minutes) need to be addressed in the Y.1541 > draft. > > Basically, this document needs to be a stand-alone document for > extensions of QSPEC parameters for Y.1541, and the main QSPEC draft > MUST be a generic draft without any specific extensions for any specs > like Y.1541, etc. > > If any help is needed to modify the document per above suggestion, > please let me know. I will volunteer to do so. > > Best regards, Radhika > > _____ > > From: nsis-bounces@ietf.org on behalf of john.loughney@nokia.com > Sent: Mon 4/10/2006 2:12 AM To: nsis@ietf.org Subject: [NSIS] WGLC on > RMD & Y.1541 > > > > Hi all, > > The WGLC ended on both the RMD and Y.1541 QoSM documents. A number of > issues have been identified and were discussed at IETF 65. > Additionally, there were very few comments received on these > documents. These documents cannot procede without review. If you > have read the document and think that they are ready, then please let > us know. The authors are revising the documents, and after the > documents are resubmitted, we'll need another WGLC is needed befor > the documents are submitted to the IESG. > > thanks, John > > _______________________________________________ nsis mailing list > nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis > > > > > > _______________________________________________ nsis mailing list > nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Apr 10 08:22:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSvPG-00008Q-8Y; Mon, 10 Apr 2006 08:22:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSvIt-0007kD-6l for nsis@ietf.org; Mon, 10 Apr 2006 08:15:35 -0400 Received: from mexforward.lss.emc.com ([168.159.213.200]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FSvGr-0006yP-VH for nsis@ietf.org; Mon, 10 Apr 2006 08:13:32 -0400 Received: from mailhub.lss.emc.com (nirah.lss.emc.com [10.254.144.13]) by mexforward.lss.emc.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k3ACDTYr014000; Mon, 10 Apr 2006 08:13:29 -0400 (EDT) Received: from mxic2.corp.emc.com (mxic2.corp.emc.com [128.221.12.9]) by mailhub.lss.emc.com (Switch-3.1.6/Switch-3.1.7) with ESMTP id k3ACDREu017916; Mon, 10 Apr 2006 08:13:27 -0400 (EDT) Received: by mxic2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Mon, 10 Apr 2006 08:13:27 -0400 Message-ID: From: Black_David@emc.com To: RADHIKA.R.ROY@saic.com Subject: RE: [NSIS] Re: Updated IETF#65 Meeting Minutes Date: Mon, 10 Apr 2006 08:13:19 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.3.0.1, Antispam-Data: 2006.04.10.045109 X-PerlMx-Spam: Gauge=, SPAM=0%, Reason='EMC_BODY_1+ -3, EMC_FROM_0+ -2, NO_REAL_NAME 0, __C230066_P5 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __HAS_X_MAILER 0, __IMS_MSGID 0, __IMS_MUA 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __STOCK_CRUFT 0' X-Spam-Score: 0.2 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org > I have also NOT seen any disagreement with anyone with the > comments that I have provided. > > So, I think that my comments must be accepted. For the record, with respect to: > >>> 3. Similar is the case should be for the DiffServ network. I disagree. For reasons previously discussed on the mailing list and resolved with the draft authors, a second token bucket is *required* for full diffserv support, as otherwise AF cannot be signaled. I believe the requirement for this second token bucket is specific to diffserv, necessary for full diffserv support, and that both those conclusions remain true even though RMD does not need the second token bucket. The latter is because RMD is actually signaling a subset of diffserv, as was pointed out at the meeting and on the list. Thanks, --David ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Apr 10 08:22:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSvQ1-0000Wu-Og; Mon, 10 Apr 2006 08:22:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSvIu-0007kD-AH for nsis@ietf.org; Mon, 10 Apr 2006 08:15:36 -0400 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FSvE4-0006it-QB for nsis@ietf.org; Mon, 10 Apr 2006 08:10:37 -0400 Received: (qmail invoked by alias); 10 Apr 2006 12:10:35 -0000 Received: from socks2.netz.sbs.de (EHLO [192.35.17.25]) [192.35.17.25] by mail.gmx.net (mp017) with SMTP; 10 Apr 2006 14:10:35 +0200 X-Authenticated: #29516787 Message-ID: <443A4B36.70208@gmx.net> Date: Mon, 10 Apr 2006 14:10:30 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Roy, Radhika R." Subject: Re: [NSIS] WGLC on RMD & Y.1541 References: <62D92A9A02BCC845B202323D49A48426209C2E@0591-ITS-EXMP02.us.saic.com> In-Reply-To: <62D92A9A02BCC845B202323D49A48426209C2E@0591-ITS-EXMP02.us.saic.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 25eb6223a37c19d53ede858176b14339 Cc: john.loughney@nokia.com, nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Roy, please find some comments below: Roy, Radhika R. wrote: > Hannes: > > It is a good question to discuss in the mailing list. I appreciate your > question. Let me explain again as follows: > > 1. > > QSPEC is a generic spec that can be used by any QoS models. So, this > draft must be a stand-alone draft without dealing with any "specific" > extensions of any "specific" QoS models. By generic you mean: The QSPEC template draft defines parameters that can be reused by more than one QoSM. Right? > 2. > > It can be seen that many "specific" QoS models like Y.1541 may come > in the future just by changing some values in parameters like delay, jitter, > loss, etc. You mean: In the future QoSM designers might use the QSPEC draft as a template to pick their favorite parameters (such as bandwidth, delay, etc.) and potentially have to define additional parameters to finalize their QoSM design. > That does not mean we have extend our "generic" QSPEC draft again > and again for those "specific" extensions. It is technically inconsistent to > "mix" a generic draft with extensions of some "specific" QoS models. Is this > clear? Well, the parameters listed in the QSPEC template draft are taken from existing QoSMs and the assumption is that they are sufficiently generic so that they might be used by other QoSMs in the future as well. > 3. > > The specific extensions of QSPEC parameters for Y.1541 and/or other > QoS models in this generic draft is OUT-of-SCOPE. This is no separate argument. > 4. > > It is can be easily seen that there are many extensions of QSPEC > parameters are needed to have the complete implementation of Y.1541 QoS > models as these have been addressed specific to Y.1541-QSPEC draft that is > going through the WGLC. If this is so, why do we need to pollute the generic > QSPEC draft with some "incomplete" extensions of QSPEC parameters for a > "specific" Y.1451 QoS model? Why does this the "specific" QSPEC-Y.1541 draft > MUST not be, like generic QSPEC draft, a stand-alone draft by its own merit? > I don't get the point with this bullet. > Hope that the above shows that there are enough technical reasons why I have > been providing comments for a long time. I would appreciate if you would > provide any good technical reason against all the comments that I have > provided above. Do you think that any of the classes listed in Section 7.2.6 are generic enough to be useful in the document? http://www.ietf.org/internet-drafts/draft-ietf-nsis-qspec-09.txt > > Best regards, > > Radhika Ciao Hannes > > > > _____ > > From: nsis-bounces@ietf.org on behalf of Hannes Tschofenig > Sent: Mon 4/10/2006 7:06 AM > To: Roy, Radhika R. > Cc: john.loughney@nokia.com; nsis@ietf.org > Subject: Re: [NSIS] WGLC on RMD & Y.1541 > > > > Hi Roy, > > my impression over the last year was that you are not unbiased when it > comes to Y.1541. This is a problem. > > Now, you want to see the Y.1541 content moved to a separate document (to > the Y.1541 QoSM draft). > > Can you motivate your desire to move this particular text to another > document? Why not other parts? > > Ciao > Hannes > > Roy, Radhika R. wrote: > >>John: >> >>The comments that I have provided on this yesterday (in the context >>of IETF # 65 meeting minutes) need to be addressed in the Y.1541 >>draft. >> >>Basically, this document needs to be a stand-alone document for >>extensions of QSPEC parameters for Y.1541, and the main QSPEC draft >>MUST be a generic draft without any specific extensions for any specs >>like Y.1541, etc. >> >>If any help is needed to modify the document per above suggestion, >>please let me know. I will volunteer to do so. >> >>Best regards, Radhika >> >>_____ >> >>From: nsis-bounces@ietf.org on behalf of john.loughney@nokia.com >>Sent: Mon 4/10/2006 2:12 AM To: nsis@ietf.org Subject: [NSIS] WGLC on >>RMD & Y.1541 >> >> >> >>Hi all, >> >>The WGLC ended on both the RMD and Y.1541 QoSM documents. A number of >> issues have been identified and were discussed at IETF 65. >>Additionally, there were very few comments received on these >>documents. These documents cannot procede without review. If you >>have read the document and think that they are ready, then please let >>us know. The authors are revising the documents, and after the >>documents are resubmitted, we'll need another WGLC is needed befor >>the documents are submitted to the IESG. >> >>thanks, John >> >>_______________________________________________ nsis mailing list >>nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis > > > >> > > > >> >> >>_______________________________________________ nsis mailing list >>nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis > > > >> > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Apr 10 09:39:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSwcY-0006pH-F0; Mon, 10 Apr 2006 09:39:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSwcX-0006pC-TP for nsis@ietf.org; Mon, 10 Apr 2006 09:39:57 -0400 Received: from mclmx2.mail.saic.com ([149.8.64.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FSwcX-0001mh-04 for nsis@ietf.org; Mon, 10 Apr 2006 09:39:57 -0400 Received: from 0015-its-ieg01.mail.saic.com ([149.8.64.21] [149.8.64.21]) by mclmx2.mail.saic.com; Mon, 10 Apr 2006 09:39:49 -0400 Received: from mcl-its-exig01.mail.saic.com ([149.8.64.12]) by 0015-its-ieg01.mail.saic.com (SMSSMTP 4.0.5.66) with SMTP id M2006041009394802688 ; Mon, 10 Apr 2006 09:39:48 -0400 Received: by mcl-its-exig01.mail.saic.com with Internet Mail Service (5.5.2657.72) id ; Mon, 10 Apr 2006 09:39:45 -0400 Message-Id: <62D92A9A02BCC845B202323D49A48426230D95@0591-ITS-EXMP02.us.saic.com> From: "Roy, Radhika R." To: Hannes.Tschofenig@gmx.net, "Roy, Radhika R." Subject: RE: [NSIS] WGLC on RMD & Y.1541 Date: Mon, 10 Apr 2006 09:39:34 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) content-class: urn:content-classes:message X-Spam-Score: 0.0 (/) X-Scan-Signature: f946603c3d764423e4a93f9c16516a6d Cc: john.loughney@nokia.com, nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1066782486==" Errors-To: nsis-bounces@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============1066782486== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C65CA4.34950035" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C65CA4.34950035 Content-Type: text/plain; charset="iso-8859-1" Hannes: Probably, we have missed the finer technical arguments due to lack of specific references of the QSPEC draft. Let me provide the sections of the draft that I am talking about as follows: 7.2.6.1 Parameter . . . . . . . . . . . . 29 7.2.6.2 Parameter . . . . . . . . 29 7.2.6.3 Parameter . . . . . . . . . 30 These above sections deal with "use cases" of QSPEC parameters for different "specific" QoS models that are implementation-specifics, and do NOT belong to the "generic" QSPEC draft. For example, Y.1541 QoS classes depend on some "specific values" of delay, jitter, or packet loss. If any values of any parameters are changed, it will NOT be called as Y.1541 QoS model. More over, the extensions shown here are NOT complete in all respects. The other Y.1541-draft shows how many other things need to be dealt with respect QOSEC for implementations of Y.1541 QoS model. So, the suggestions are as follows: 1. Remove the use cases of QoS models from this "generic" QSPEC draft. That is, remove Sections 7.2.6.1 - 7.2.6.3 from this draft. 2. Make Section 7.2.6 a generic one by explaining the fact that "there are many QoS models that may use this generic QSPEC template for "specific" implementations of different QoS models in the context of the public Internet, Enterprise networks, or other networks. 3. In the same token, the Y.1541-QSPEC draft should be a stand-alone draft that will deal with implementations of the Y.1541 QoS model extending all QSPEC parameters. 4. Similarly, we can write separate drafts for DSTE and DiffServ network for implementations of those QoS models extending the QSPEC parameters for specific purposes. More inline [RRR]. I really appreciate your help for technical clarifications. Best regards, Radhika -----Original Message----- From: Hannes.Tschofenig@gmx.net [mailto:Hannes.Tschofenig@gmx.net ] Sent: Monday, April 10, 2006 8:11 AM To: Roy, Radhika R. Cc: john.loughney@nokia.com; nsis@ietf.org Subject: Re: [NSIS] WGLC on RMD & Y.1541 Hi Roy, please find some comments below: Roy, Radhika R. wrote: > Hannes: > > It is a good question to discuss in the mailing list. I appreciate your > question. Let me explain again as follows: > > 1. > > QSPEC is a generic spec that can be used by any QoS models. So, this > draft must be a stand-alone draft without dealing with any "specific" > extensions of any "specific" QoS models. By generic you mean: The QSPEC template draft defines parameters that can be reused by more than one QoSM. Right? [RRR] More specifically - QSPEC must not deal with how to "extend" its parameters for implementation of specific QoS models that depend on "specific" values of delay, jitter, or packet loss. Kindly see the explanations provided above. > 2. > > It can be seen that many "specific" QoS models like Y.1541 may come > in the future just by changing some values in parameters like delay, jitter, > loss, etc. You mean: In the future QoSM designers might use the QSPEC draft as a template to pick their favorite parameters (such as bandwidth, delay, etc.) and potentially have to define additional parameters to finalize their QoSM design. [RRR] You are right, but it is one of the examples that you have provided that I call that a specific QoS model that depends on "grouping" on some QoS parameters. [RRR] The interesting thing is this: 1) A specific QoS model can also be defined "only" on "grouping" of the QoS parameters without defining any specific values of any QoS parameters and 2) A specific QoS model may be very tightly coupled by defining both "grouping" of parameters and the specific value of each parameter of each group. [RRR] Y.1541 QoS model depends on Category 2 as stated above. > That does not mean we have extend our "generic" QSPEC draft again > and again for those "specific" extensions. It is technically inconsistent to > "mix" a generic draft with extensions of some "specific" QoS models. Is this > clear? Well, the parameters listed in the QSPEC template draft are taken from existing QoSMs and the assumption is that they are sufficiently generic so that they might be used by other QoSMs in the future as well. [RRR] Kindly see that the general explanations that I have provided for Sections 7.2.6.1 - 7.2.6.3 of the draft. These sections are NOT "generic." They address specific extensions of QSPEC templates for specific QoS models. These sections need to be removed and the generic texts to be used, and the separate drafts need to be written for each QoS model extending QSPEC templates. > 3. > > The specific extensions of QSPEC parameters for Y.1541 and/or other > QoS models in this generic draft is OUT-of-SCOPE. This is no separate argument. > 4. > > It is can be easily seen that there are many extensions of QSPEC > parameters are needed to have the complete implementation of Y.1541 QoS > models as these have been addressed specific to Y.1541-QSPEC draft that is > going through the WGLC. If this is so, why do we need to pollute the generic > QSPEC draft with some "incomplete" extensions of QSPEC parameters for a > "specific" Y.1451 QoS model? Why does this the "specific" QSPEC-Y.1541 draft > MUST not be, like generic QSPEC draft, a stand-alone draft by its own merit? > I don't get the point with this bullet. [RRR] Kindly see that the general explanations that I have provided for Sections 7.2.6.1 - 7.2.6.3 of the draft. These sections are NOT "generic." > Hope that the above shows that there are enough technical reasons why I have > been providing comments for a long time. I would appreciate if you would > provide any good technical reason against all the comments that I have > provided above. Do you think that any of the classes listed in Section 7.2.6 are generic enough to be useful in the document? http://www.ietf.org/internet-drafts/draft-ietf-nsis-qspec-09.txt [RRR] Kindly see that the general explanations that I have provided for Sections 7.2.6.1 - 7.2.6.3 of the draft. These sections are NOT "generic." > > Best regards, > > Radhika Ciao Hannes > > > > _____ > > From: nsis-bounces@ietf.org on behalf of Hannes Tschofenig > Sent: Mon 4/10/2006 7:06 AM > To: Roy, Radhika R. > Cc: john.loughney@nokia.com; nsis@ietf.org > Subject: Re: [NSIS] WGLC on RMD & Y.1541 > > > > Hi Roy, > > my impression over the last year was that you are not unbiased when it > comes to Y.1541. This is a problem. > > Now, you want to see the Y.1541 content moved to a separate document (to > the Y.1541 QoSM draft). > > Can you motivate your desire to move this particular text to another > document? Why not other parts? > > Ciao > Hannes > > Roy, Radhika R. wrote: > >>John: >> >>The comments that I have provided on this yesterday (in the context >>of IETF # 65 meeting minutes) need to be addressed in the Y.1541 >>draft. >> >>Basically, this document needs to be a stand-alone document for >>extensions of QSPEC parameters for Y.1541, and the main QSPEC draft >>MUST be a generic draft without any specific extensions for any specs >>like Y.1541, etc. >> >>If any help is needed to modify the document per above suggestion, >>please let me know. I will volunteer to do so. >> >>Best regards, Radhika >> >>_____ >> >>From: nsis-bounces@ietf.org on behalf of john.loughney@nokia.com >>Sent: Mon 4/10/2006 2:12 AM To: nsis@ietf.org Subject: [NSIS] WGLC on >>RMD & Y.1541 >> >> >> >>Hi all, >> >>The WGLC ended on both the RMD and Y.1541 QoSM documents. A number of >> issues have been identified and were discussed at IETF 65. >>Additionally, there were very few comments received on these >>documents. These documents cannot procede without review. If you >>have read the document and think that they are ready, then please let >>us know. The authors are revising the documents, and after the >>documents are resubmitted, we'll need another WGLC is needed befor >>the documents are submitted to the IESG. >> >>thanks, John >> > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > > > > ------_=_NextPart_001_01C65CA4.34950035 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [NSIS] WGLC on RMD & Y.1541

Hannes:

Probably, we have missed the finer technical arguments due = to lack of specific references of the QSPEC draft. Let me provide the sections of the draft that I am talking about as = follows:

         

7.2.6.1 <PHB Class> Parameter . . . . . . . . . . . . = 29

7.2.6.2 <Y.1541 QoS Class> Parameter  . . . . . . . . = 29

7.2.6.3 <DSTE Class Type> Parameter . . . . . . . . . = 30

These above sections deal with "use cases" of QSPEC = parameters for different = "specific" QoS models that are = implementation-specifics, and do NOT = belong to the "generic" QSPEC draft.

For example, Y.1541 QoS classes depend on some "specific values" of delay, = jitter, or packet loss. If any values of any parameters are changed, it = will NOT be called as Y.1541 QoS model. More over, the extensions shown here are NOT = complete in all respects. The other Y.1541-draft shows how many other = things need to be dealt with respect QOSEC for implementations = of Y.1541 QoS model.

So, the suggestions are as follows:

1.      = Remove the use cases of QoS = models from this "generic" QSPEC draft. That is, remove Sections 7.2.6.1 - 7.2.6.3 from this draft.

2.      Make Section 7.2.6 a generic one by explaining = the fact that "there = are many QoS models that = may = use this generic QSPEC template for "specific" implementations of different QoS models in the context of the public Internet, Enterprise networks, = or other networks.

3.      In the same token, the Y.1541-QSPEC draft = should be a stand-alone draft that will deal with implementations of the Y.1541 QoS model extending all QSPEC = parameters.

4.      Similarly, we can write separate = drafts for = DSTE = and DiffServ network for implementations of those QoS models = extending the QSPEC = parameters for specific purposes.

More inline [RRR].

I really appreciate your help for technical = clarifications.

Best regards,

Radhika

-----Original Message-----
From: Hannes.Tschofenig@gmx.net [mailto:Hannes.Tschofenig@gmx.n= et]
Sent: Monday, April 10, 2006 8:11 AM
To: Roy, Radhika R.
Cc: john.loughney@nokia.com; nsis@ietf.org
Subject: Re: [NSIS] WGLC on RMD & Y.1541

Hi Roy,

please find some comments below:

Roy, Radhika R. wrote:

> Hannes:

> 

> It is a good question to discuss in the mailing list. I = appreciate your

> question. Let me explain again as = follows:

>

> 1.   

>

>       QSPEC is a generic spec that = can be used by any QoS models. So, this

> draft must be a stand-alone draft without dealing with any = "specific"

> extensions of any "specific" QoS = models.

By generic you mean: The QSPEC template draft defines parameters = that

can be reused by more than one QoSM. Right?

[RRR] More specifically - QSPEC must not deal = with how to "extend" its parameters for implementation of specific QoS models that depend on = "specific" values of delay, jitter, or packet = loss. = Kindly see = the explanations provided above.

> 2.   

>

>       It can be seen that many = "specific" QoS models like Y.1541 may come

> in the future just by changing some values in parameters = like delay, jitter,

> loss, etc.

You mean: In the future QoSM designers might use the QSPEC draft = as a

template to pick their favorite parameters (such as bandwidth, = delay,

etc.) and potentially have to define additional parameters to = finalize

their QoSM design.

[RRR] You are right, but it is one of the = examples that you have provided that I call that a specific QoS model = that depends on "grouping" on some QoS = parameters.

[RRR] The interesting thing is this: 1) A specific QoS = model can also be defined "only" on "grouping" of the QoS parameters without defining any specific values = of any QoS parameters and 2) A specific QoS model may be very = tightly coupled by defining both "grouping" of = parameters and the specific value of each parameter of each = group.

[RRR] Y.1541 QoS model depends on Category 2 = as stated above.

> That does not mean we have extend our "generic" = QSPEC draft again

> and again for those "specific" extensions. It is = technically inconsistent to

> "mix" a generic draft with extensions of some = "specific" QoS models. Is this

> clear?

Well, the parameters listed in the QSPEC template draft are = taken from

existing QoSMs and the assumption is that they are sufficiently = generic

so that they might be used by other QoSMs in the future as = well.

[RRR] Kindly see that the general explanations = that I have provided for Sections 7.2.6.1 = - 7.2.6.3 of the = draft. = These = sections are NOT "generic." They address specific extensions = of QSPEC templates for specific QoS models. These sections need to be = removed and the generic texts to be used, and the separate drafts need = to be written for each QoS model extending QSPEC = templates.

> 3.   

>

>       The specific extensions of = QSPEC parameters for Y.1541 and/or other

> QoS models in this generic draft is = OUT-of-SCOPE.

This is no separate argument.

> 4.   

>

>       It is can be easily seen = that there are many extensions of QSPEC

> parameters are needed to have the complete implementation = of Y.1541 QoS

> models as these have been addressed specific to = Y.1541-QSPEC draft that is

> going through the WGLC. If this is so, why do we need to = pollute the generic

> QSPEC draft with some "incomplete" extensions of = QSPEC parameters for a

> "specific" Y.1451 QoS model? Why does this the = "specific" QSPEC-Y.1541 draft

> MUST not be, like generic QSPEC draft, a stand-alone draft = by its own merit?

>

I don't get the point with this bullet.

[RRR] Kindly see that the general explanations = that I have provided for Sections 7.2.6.1 = - 7.2.6.3 of the = draft. = These = sections are NOT "generic."

> Hope that the above shows that there are enough technical = reasons why I have

> been providing comments for a long time. I would appreciate = if you would

> provide any good technical reason against all the comments = that I have

> provided above.


Do you think that any of the classes listed in Section 7.2.6 are = generic

enough to be useful in the document?

http://www.ietf.org/internet-drafts/draft-ietf-nsis-qspec-09.txt

[RRR] Kindly see that the general explanations = that I have provided for Sections 7.2.6.1 = - 7.2.6.3 of the = draft. = These = sections are NOT "generic."

>

> Best regards,

>

> Radhika

Ciao

Hannes

>

> 

>

>   _____ 

>

> From: nsis-bounces@ietf.org on behalf of Hannes = Tschofenig

> Sent: Mon 4/10/2006 7:06 AM

> To: Roy, Radhika R.

> Cc: john.loughney@nokia.com; = nsis@ietf.org

> Subject: Re: [NSIS] WGLC on RMD & = Y.1541

>

>

>

> Hi Roy,

>

> my impression over the last year was that you are not = unbiased when it

> comes to Y.1541. This is a problem.

>

> Now, you want to see the Y.1541 content moved to a separate = document (to

> the Y.1541 QoSM draft).

>

> Can you motivate your desire to move this particular text = to another

> document? Why not other parts?

>

> Ciao

> Hannes

>

> Roy, Radhika R. wrote:

>

>>John:

>>

>>The comments that I have provided on this yesterday (in = the context

>>of IETF # 65 meeting minutes) need to be addressed in = the Y.1541

>>draft.

>>

>>Basically, this document needs to be a stand-alone = document for

>>extensions of QSPEC parameters for Y.1541, and the main = QSPEC draft

>>MUST be a generic draft without any specific extensions = for any specs

>>like Y.1541, etc.

>>

>>If any help is needed to modify the document per above = suggestion,

>>please let me know. I will volunteer to do so. =

>>

>>Best regards, Radhika

>>

>>_____

>>

>>From: nsis-bounces@ietf.org on behalf of = john.loughney@nokia.com

>>Sent: Mon 4/10/2006 2:12 AM To: nsis@ietf.org Subject: = [NSIS] WGLC on

>>RMD & Y.1541

>>

>>

>>

>>Hi all,

>>

>>The WGLC ended on both the RMD and Y.1541 QoSM = documents. A number of

>> issues have been identified and were discussed at IETF = 65.

>>Additionally, there were very few comments received on = these

>>documents.  These documents cannot procede without = review.  If you

>>have read the document and think that they are ready, = then please let

>>us know. The authors are revising the documents, and = after the

>>documents are resubmitted, we'll need another WGLC is = needed befor

>>the documents are submitted to the IESG. =

>>

>>thanks, John

>>

> _______________________________________________ =

> nsis mailing list

> nsis@ietf.org

> https://www1.ietf.o= rg/mailman/listinfo/nsis

> <https://www1.ietf.o= rg/mailman/listinfo/nsis> 

>

>

------_=_NextPart_001_01C65CA4.34950035-- --===============1066782486== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis --===============1066782486==-- From nsis-bounces@ietf.org Mon Apr 10 10:06:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSx2O-0000YH-RP; Mon, 10 Apr 2006 10:06:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSx2N-0000YC-KI for nsis@ietf.org; Mon, 10 Apr 2006 10:06:39 -0400 Received: from mclmx2.mail.saic.com ([149.8.64.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FSx2N-0002kT-95 for nsis@ietf.org; Mon, 10 Apr 2006 10:06:39 -0400 Received: from 0015-its-ieg02.mail.saic.com ([149.8.64.21] [149.8.64.21]) by mclmx2.mail.saic.com; Mon, 10 Apr 2006 10:06:29 -0400 Received: from mcl-its-exig01.mail.saic.com ([149.8.64.12]) by 0015-its-ieg02.mail.saic.com (SMSSMTP 4.0.5.66) with SMTP id M2006041010062921692 ; Mon, 10 Apr 2006 10:06:29 -0400 Received: by mcl-its-exig01.mail.saic.com with Internet Mail Service (5.5.2657.72) id ; Mon, 10 Apr 2006 10:06:29 -0400 Message-Id: <62D92A9A02BCC845B202323D49A48426230D96@0591-ITS-EXMP02.us.saic.com> From: "Roy, Radhika R." To: Hannes.Tschofenig@gmx.net, "Roy, Radhika R." Subject: RE: [NSIS] Re: Updated IETF#65 Meeting Minutes Date: Mon, 10 Apr 2006 10:06:25 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) content-class: urn:content-classes:message X-Spam-Score: 0.0 (/) X-Scan-Signature: 850245b51c39701e2700a112f3032caa Cc: john.loughney@nokia.com, nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0792276182==" Errors-To: nsis-bounces@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============0792276182== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C65CA7.F4D8C513" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C65CA7.F4D8C513 Content-Type: text/plain; charset="iso-8859-1" Hi, Hannes: It is highly appreciated by all that you are so keen to resolve all the technical comments. Kindly see inline [RRR]. Best regards, Radhika -----Original Message----- From: Hannes.Tschofenig@gmx.net [mailto:Hannes.Tschofenig@gmx.net ] Sent: Monday, April 10, 2006 7:03 AM To: Roy, Radhika R. Cc: john.loughney@nokia.com; nsis@ietf.org Subject: Re: [NSIS] Re: Updated IETF#65 Meeting Minutes Hi Roy, if your review comments are not discussed on the mailing list then it does not mean that they must be accepted. You know the IETF process: rough consensus (and running code). Regarding to your comments: > 1. To clarify priority levels: What does it mean it mean? Is it for > media? Is it for call (e.g., SIP)? Or, is it for something? I guess in our discussions we concluded that the priority level does not relate to a SIP call itself (since these priority levels have e2e semantic). As such, the priority levels have the same semantic as those defined for RSVP. It might not hurt to add a few lines to the draft to reflect past discussions regarding this subject. In fact I was also confused about this issue in the past... [RRR] Yes, this is another BIG issue for us to resolve. It may be right that we may follow the RSVP path for resolving the priority issues. However, the RSVP priority levels are not sufficient to resolve the priority levels of different media knowing the call level priority. [RRR] The same issue has also been discussed in SIP, SIPPING, and other WGs. SIP/SIPPING WG was silent about this. I believe that MMUSIC, AVT, and other WGs that deal with similar issues also did not resolve this. [RRR] My take will be to suggest as follows: A sub-field may also used within the call-level priority to have option for different media level priorities once it is decided to accept the call based on its own priority level. Let us discuss more on this. ------_=_NextPart_001_01C65CA7.F4D8C513 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [NSIS] Re: Updated IETF#65 Meeting Minutes

Hi, Hannes:

It is highly appreciated by all that you are so keen to resolve = all the technical comments.

Kindly see inline [RRR].

Best regards,

Radhika

-----Original Message-----
From: Hannes.Tschofenig@gmx.net [mailto:Hannes.Tschofenig@gmx.n= et]
Sent: Monday, April 10, 2006 7:03 AM
To: Roy, Radhika R.
Cc: john.loughney@nokia.com; nsis@ietf.org
Subject: Re: [NSIS] Re: Updated IETF#65 Meeting = Minutes

Hi Roy,

if your review comments are not discussed on the mailing list = then it

does not mean that they must be accepted. You know the IETF = process:

rough consensus (and running code).

Regarding to your comments:

 > 1.      To clarify priority = levels: What does it mean it mean? Is it for

 > media? Is it for call (e.g., SIP)? Or, is it for = something?

I guess in our discussions we concluded that the priority level = does not

  relate to a SIP call itself (since these priority levels = have e2e

semantic). As such, the priority levels have the same semantic = as those

defined for RSVP.

It might not hurt to add a few lines to the draft to reflect = past

discussions regarding this subject. In fact I was also confused = about

this issue in the past...

[RRR] Yes, this is another BIG issue for us to = resolve. = It may = be right that we may = follow the RSVP path for resolving the priority issues. However, the = RSVP priority levels are not sufficient to resolve the priority levels = of different = media knowing the call level priority.

[RRR] The same issue has also been discussed = in SIP, SIPPING, and other WGs. SIP/SIPPING WG was silent about this. = I believe that MMUSIC, AVT, and other WGs that deal with similar issues = also did not resolve this.

[RRR] My take will be to suggest as follows: A = sub-field may also used within the call-level priority to have option for different media = level priorities once it is decided to accept the call based = on its = own = priority level. = Let us = discuss more on this.

 

------_=_NextPart_001_01C65CA7.F4D8C513-- --===============0792276182== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis --===============0792276182==-- From nsis-bounces@ietf.org Mon Apr 10 10:13:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSx8j-0003d5-5e; Mon, 10 Apr 2006 10:13:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSx8h-0003d0-Qy for nsis@ietf.org; Mon, 10 Apr 2006 10:13:11 -0400 Received: from mclmx2.mail.saic.com ([149.8.64.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FSx8h-00030W-GZ for nsis@ietf.org; Mon, 10 Apr 2006 10:13:11 -0400 Received: from 0015-its-ieg02.mail.saic.com ([149.8.64.21] [149.8.64.21]) by mclmx2.mail.saic.com; Mon, 10 Apr 2006 10:13:00 -0400 Received: from mcl-its-exig01.mail.saic.com ([149.8.64.12]) by 0015-its-ieg02.mail.saic.com (SMSSMTP 4.0.5.66) with SMTP id M2006041010130022953 ; Mon, 10 Apr 2006 10:13:00 -0400 Received: by mcl-its-exig01.mail.saic.com with Internet Mail Service (5.5.2657.72) id ; Mon, 10 Apr 2006 10:12:59 -0400 Message-Id: <62D92A9A02BCC845B202323D49A48426230D97@0591-ITS-EXMP02.us.saic.com> From: "Roy, Radhika R." To: Black_David@emc.com, RADHIKA.R.ROY@saic.com Subject: RE: [NSIS] Re: Updated IETF#65 Meeting Minutes Date: Mon, 10 Apr 2006 10:12:19 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) content-class: urn:content-classes:message X-Spam-Score: 0.0 (/) X-Scan-Signature: bacfc6c7290e34d410f9bc22b825ce96 Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0424516567==" Errors-To: nsis-bounces@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============0424516567== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C65CA8.CAD53993" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C65CA8.CAD53993 Content-Type: text/plain; charset="iso-8859-1" Hi, David: Yes, I agree with you. However, we are talking about different topics, and I have provided the details in response to Hannes emails. Kindly see those. Your help will be appreciated to resolve those technical issues. Best regards, Radhika -----Original Message----- From: Black_David@emc.com [mailto:Black_David@emc.com ] Sent: Monday, April 10, 2006 8:13 AM To: RADHIKA.R.ROY@saic.com Cc: nsis@ietf.org Subject: RE: [NSIS] Re: Updated IETF#65 Meeting Minutes > I have also NOT seen any disagreement with anyone with the > comments that I have provided. > > So, I think that my comments must be accepted. For the record, with respect to: > >>> 3. Similar is the case should be for the DiffServ network. I disagree. For reasons previously discussed on the mailing list and resolved with the draft authors, a second token bucket is *required* for full diffserv support, as otherwise AF cannot be signaled. I believe the requirement for this second token bucket is specific to diffserv, necessary for full diffserv support, and that both those conclusions remain true even though RMD does not need the second token bucket. The latter is because RMD is actually signaling a subset of diffserv, as was pointed out at the meeting and on the list. Thanks, --David ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- ------_=_NextPart_001_01C65CA8.CAD53993 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [NSIS] Re: Updated IETF#65 Meeting Minutes

Hi, David:

Yes, I agree with you. However, we are talking about different = topics, and I have provided the details in response to = Hannes = emails. Kindly see = those.

Your help will be appreciated to resolve = those = technical issues.

Best = regards,

Radhika

-----Original Message-----
From: Black_David@emc.com [mailto:Black_David@emc.com]
Sent: Monday, April 10, 2006 8:13 AM
To: RADHIKA.R.ROY@saic.com
Cc: nsis@ietf.org
Subject: RE: [NSIS] Re: Updated IETF#65 Meeting = Minutes

> I have also NOT seen any disagreement with anyone with the =

> comments that I have provided.

> 

> So, I think that my comments must be = accepted.

For the record, with respect to:

> >>>  3.      Similar = is the case should be for the DiffServ network.

I disagree.  For reasons previously discussed on the = mailing list and

resolved with the draft authors, a second token bucket is = *required*

for full diffserv support, as otherwise AF cannot be = signaled.  I

believe the requirement for this second token bucket is specific = to

diffserv, necessary for full diffserv support, and that both = those

conclusions remain true even though RMD does not need the = second

token bucket.  The latter is because RMD is actually = signaling a

subset of diffserv, as was pointed out at the meeting and on the = list.

Thanks,

--David

----------------------------------------------------

David L. Black, Senior Technologist

EMC Corporation, 176 South St., Hopkinton, MA  = 01748

+1 (508) = 293-7953          &nbs= p;  FAX: +1 (508) 293-7786

black_david@emc.com        = Mobile: +1 (978) 394-7754

----------------------------------------------------

------_=_NextPart_001_01C65CA8.CAD53993-- --===============0424516567== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis --===============0424516567==-- From nsis-bounces@ietf.org Mon Apr 10 15:10:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FT1mf-0001pk-JW; Mon, 10 Apr 2006 15:10:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FT1mf-0001p2-5f for nsis@ietf.org; Mon, 10 Apr 2006 15:10:45 -0400 Received: from mclmx.mail.saic.com ([149.8.64.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FT1me-0007R1-Nb for nsis@ietf.org; Mon, 10 Apr 2006 15:10:45 -0400 Received: from 0015-its-ieg01.mail.saic.com ([149.8.64.21] [149.8.64.21]) by mclmx.mail.saic.com; Mon, 10 Apr 2006 15:10:32 -0400 Received: from mcl-its-exig01.mail.saic.com ([149.8.64.12]) by 0015-its-ieg01.mail.saic.com (SMSSMTP 4.0.5.66) with SMTP id M2006041015103224518 ; Mon, 10 Apr 2006 15:10:32 -0400 Received: by mcl-its-exig01.mail.saic.com with Internet Mail Service (5.5.2657.72) id ; Mon, 10 Apr 2006 15:10:32 -0400 Message-Id: <62D92A9A02BCC845B202323D49A48426209C35@0591-ITS-EXMP02.us.saic.com> From: "Roy, Radhika R." To: "Roy, Radhika R." , Hannes.Tschofenig@gmx.net Subject: RE: [NSIS] WGLC on RMD & Y.1541 Date: Mon, 10 Apr 2006 15:10:24 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) content-class: urn:content-classes:message Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 85e99493ec37f9acef29c7843dbf2e68 Cc: john.loughney@nokia.com, nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi, Hannes and all: In addition, it is a simple soul-searching question for the entire NSIS WG and all IETF members in general as follows: * What does it make a mandatory justification that there MUST be TWO different RFCs for extensions of QSPEC parameters (a. QSPEC Template and b. Y.1541-QSPEC) for the SAME Y.1541 QoS model? * Why does the QSPEC Template draft need to address extensions of specific QoS models like Y.1541 that is going to be an informational RFC? * Why does there need to be ANOTHER Y.1541-QoS draft to address the additional extensions of QSPEC parameters for the same Y.1541 QoS model that is also going be an Informational RFC as it is its WGLC stage? Can anyone help to justify the above requirements? If anyone cannot justify the above requirements, does it not simply prove the fact that these TWO separate drafts can NOT be recommended to assign RFCs as it is if those technical inconsistencies are NOT removed? Best regards, Radhika _____ From: Roy, Radhika R. [mailto:RADHIKA.R.ROY@saic.com] Sent: Mon 4/10/2006 9:39 AM To: Hannes.Tschofenig@gmx.net; Roy, Radhika R. Cc: john.loughney@nokia.com; nsis@ietf.org Subject: RE: [NSIS] WGLC on RMD & Y.1541 Hannes: Probably, we have missed the finer technical arguments due to lack of specific references of the QSPEC draft. Let me provide the sections of the draft that I am talking about as follows: 7.2.6.1 Parameter . . . . . . . . . . . . 29 7.2.6.2 Parameter . . . . . . . . 29 7.2.6.3 Parameter . . . . . . . . . 30 These above sections deal with "use cases" of QSPEC parameters for different "specific" QoS models that are implementation-specifics, and do NOT belong to the "generic" QSPEC draft. For example, Y.1541 QoS classes depend on some "specific values" of delay, jitter, or packet loss. If any values of any parameters are changed, it will NOT be called as Y.1541 QoS model. More over, the extensions shown here are NOT complete in all respects. The other Y.1541-draft shows how many other things need to be dealt with respect QOSEC for implementations of Y.1541 QoS model. So, the suggestions are as follows: 1. Remove the use cases of QoS models from this "generic" QSPEC draft. That is, remove Sections 7.2.6.1 - 7.2.6.3 from this draft. 2. Make Section 7.2.6 a generic one by explaining the fact that "there are many QoS models that may use this generic QSPEC template for "specific" implementations of different QoS models in the context of the public Internet, Enterprise networks, or other networks. 3. In the same token, the Y.1541-QSPEC draft should be a stand-alone draft that will deal with implementations of the Y.1541 QoS model extending all QSPEC parameters. 4. Similarly, we can write separate drafts for DSTE and DiffServ network for implementations of those QoS models extending the QSPEC parameters for specific purposes. More inline [RRR]. I really appreciate your help for technical clarifications. Best regards, Radhika -----Original Message----- From: Hannes.Tschofenig@gmx.net [mailto:Hannes.Tschofenig@gmx.net ] Sent: Monday, April 10, 2006 8:11 AM To: Roy, Radhika R. Cc: john.loughney@nokia.com; nsis@ietf.org Subject: Re: [NSIS] WGLC on RMD & Y.1541 Hi Roy, please find some comments below: Roy, Radhika R. wrote: > Hannes: > > It is a good question to discuss in the mailing list. I appreciate your > question. Let me explain again as follows: > > 1. > > QSPEC is a generic spec that can be used by any QoS models. So, this > draft must be a stand-alone draft without dealing with any "specific" > extensions of any "specific" QoS models. By generic you mean: The QSPEC template draft defines parameters that can be reused by more than one QoSM. Right? [RRR] More specifically - QSPEC must not deal with how to "extend" its parameters for implementation of specific QoS models that depend on "specific" values of delay, jitter, or packet loss. Kindly see the explanations provided above. > 2. > > It can be seen that many "specific" QoS models like Y.1541 may come > in the future just by changing some values in parameters like delay, jitter, > loss, etc. You mean: In the future QoSM designers might use the QSPEC draft as a template to pick their favorite parameters (such as bandwidth, delay, etc.) and potentially have to define additional parameters to finalize their QoSM design. [RRR] You are right, but it is one of the examples that you have provided that I call that a specific QoS model that depends on "grouping" on some QoS parameters. [RRR] The interesting thing is this: 1) A specific QoS model can also be defined "only" on "grouping" of the QoS parameters without defining any specific values of any QoS parameters and 2) A specific QoS model may be very tightly coupled by defining both "grouping" of parameters and the specific value of each parameter of each group. [RRR] Y.1541 QoS model depends on Category 2 as stated above. > That does not mean we have extend our "generic" QSPEC draft again > and again for those "specific" extensions. It is technically inconsistent to > "mix" a generic draft with extensions of some "specific" QoS models. Is this > clear? Well, the parameters listed in the QSPEC template draft are taken from existing QoSMs and the assumption is that they are sufficiently generic so that they might be used by other QoSMs in the future as well. [RRR] Kindly see that the general explanations that I have provided for Sections 7.2.6.1 - 7.2.6.3 of the draft. These sections are NOT "generic." They address specific extensions of QSPEC templates for specific QoS models. These sections need to be removed and the generic texts to be used, and the separate drafts need to be written for each QoS model extending QSPEC templates. > 3. > > The specific extensions of QSPEC parameters for Y.1541 and/or other > QoS models in this generic draft is OUT-of-SCOPE. This is no separate argument. > 4. > > It is can be easily seen that there are many extensions of QSPEC > parameters are needed to have the complete implementation of Y.1541 QoS > models as these have been addressed specific to Y.1541-QSPEC draft that is > going through the WGLC. If this is so, why do we need to pollute the generic > QSPEC draft with some "incomplete" extensions of QSPEC parameters for a > "specific" Y.1451 QoS model? Why does this the "specific" QSPEC-Y.1541 draft > MUST not be, like generic QSPEC draft, a stand-alone draft by its own merit? > I don't get the point with this bullet. [RRR] Kindly see that the general explanations that I have provided for Sections 7.2.6.1 - 7.2.6.3 of the draft. These sections are NOT "generic." > Hope that the above shows that there are enough technical reasons why I have > been providing comments for a long time. I would appreciate if you would > provide any good technical reason against all the comments that I have > provided above. Do you think that any of the classes listed in Section 7.2.6 are generic enough to be useful in the document? http://www.ietf.org/internet-drafts/draft-ietf-nsis-qspec-09.txt [RRR] Kindly see that the general explanations that I have provided for Sections 7.2.6.1 - 7.2.6.3 of the draft. These sections are NOT "generic." > > Best regards, > > Radhika Ciao Hannes > > > > _____ > > From: nsis-bounces@ietf.org on behalf of Hannes Tschofenig > Sent: Mon 4/10/2006 7:06 AM > To: Roy, Radhika R. > Cc: john.loughney@nokia.com; nsis@ietf.org > Subject: Re: [NSIS] WGLC on RMD & Y.1541 > > > > Hi Roy, > > my impression over the last year was that you are not unbiased when it > comes to Y.1541. This is a problem. > > Now, you want to see the Y.1541 content moved to a separate document (to > the Y.1541 QoSM draft). > > Can you motivate your desire to move this particular text to another > document? Why not other parts? > > Ciao > Hannes > > Roy, Radhika R. wrote: > >>John: >> >>The comments that I have provided on this yesterday (in the context >>of IETF # 65 meeting minutes) need to be addressed in the Y.1541 >>draft. >> >>Basically, this document needs to be a stand-alone document for >>extensions of QSPEC parameters for Y.1541, and the main QSPEC draft >>MUST be a generic draft without any specific extensions for any specs >>like Y.1541, etc. >> >>If any help is needed to modify the document per above suggestion, >>please let me know. I will volunteer to do so. >> >>Best regards, Radhika >> >>_____ >> >>From: nsis-bounces@ietf.org on behalf of john.loughney@nokia.com >>Sent: Mon 4/10/2006 2:12 AM To: nsis@ietf.org Subject: [NSIS] WGLC on >>RMD & Y.1541 >> >> >> >>Hi all, >> >>The WGLC ended on both the RMD and Y.1541 QoSM documents. A number of >> issues have been identified and were discussed at IETF 65. >>Additionally, there were very few comments received on these >>documents. These documents cannot procede without review. If you >>have read the document and think that they are ready, then please let >>us know. The authors are revising the documents, and after the >>documents are resubmitted, we'll need another WGLC is needed befor >>the documents are submitted to the IESG. >> >>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 nsis-bounces@ietf.org Mon Apr 10 17:42:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FT49B-0004sn-7V; Mon, 10 Apr 2006 17:42:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FT49A-0004si-77 for nsis@ietf.org; Mon, 10 Apr 2006 17:42:08 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FT497-0005YB-Fa for nsis@ietf.org; Mon, 10 Apr 2006 17:42:08 -0400 Received: (qmail invoked by alias); 10 Apr 2006 21:42:03 -0000 Received: from p54985544.dip.t-dialin.net (EHLO [192.168.2.33]) [84.152.85.68] by mail.gmx.net (mp042) with SMTP; 10 Apr 2006 23:42:03 +0200 X-Authenticated: #29516787 Message-ID: <443AD128.6090906@gmx.net> Date: Mon, 10 Apr 2006 23:42:00 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Roy, Radhika R." Subject: Re: [NSIS] WGLC on RMD & Y.1541 References: <62D92A9A02BCC845B202323D49A48426230D95@0591-ITS-EXMP02.us.saic.com> In-Reply-To: <62D92A9A02BCC845B202323D49A48426230D95@0591-ITS-EXMP02.us.saic.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: e3901bdd61b234d82da85cc76f05a7e8 Cc: john.loughney@nokia.com, nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Roy, to summarize what you say: The parameters used in Section 7.2.6.1 - Section 7.2.6.3 are QoSM specific and provide little value for reuse among other QoSM. Since the QSPEC draft aims to be a toolbox that provides attributes that can be reused by multiple QoSMs you suggest to delete these sections from the QSPEC draft and to deal with them in a separate document (which is, btw, partically done already). Ciao Hannes Roy, Radhika R. wrote: > Hannes: > > Probably, we have missed the finer technical arguments due to lack of > specific references of the QSPEC draft. Let me provide the sections of > the draft that I am talking about as follows: > > > > 7.2.6.1 Parameter . . . . . . . . . . . . 29 > > 7.2.6.2 Parameter . . . . . . . . 29 > > 7.2.6.3 Parameter . . . . . . . . . 30 > > These above sections deal with "use cases" of QSPEC parameters for > different "specific" QoS models that are implementation-specifics, and > do NOT belong to the "generic" QSPEC draft. > > For example, Y.1541 QoS classes depend on some "specific values" of > delay, jitter, or packet loss. If any values of any parameters are > changed, it will NOT be called as Y.1541 QoS model. More over, the > extensions shown here are NOT complete in all respects. The other > Y.1541-draft shows how many other things need to be dealt with respect > QOSEC for implementations of Y.1541 QoS model. > > So, the suggestions are as follows: > > 1. Remove the use cases of QoS models from this "generic" QSPEC > draft. That is, remove Sections 7.2.6.1 - 7.2.6.3 from this draft. > > 2. Make Section 7.2.6 a generic one by explaining the fact that > "there are many QoS models that may use this generic QSPEC template for > "specific" implementations of different QoS models in the context of the > public Internet, Enterprise networks, or other networks. > > 3. In the same token, the Y.1541-QSPEC draft should be a > stand-alone draft that will deal with implementations of the Y.1541 QoS > model extending all QSPEC parameters. > > 4. Similarly, we can write separate drafts for DSTE and DiffServ > network for implementations of those QoS models extending the QSPEC > parameters for specific purposes. > > More inline [RRR]. > > I really appreciate your help for technical clarifications. > > Best regards, > > Radhika > > -----Original Message----- > From: Hannes.Tschofenig@gmx.net [mailto:Hannes.Tschofenig@gmx.net] > Sent: Monday, April 10, 2006 8:11 AM > To: Roy, Radhika R. > Cc: john.loughney@nokia.com; nsis@ietf.org > Subject: Re: [NSIS] WGLC on RMD & Y.1541 > > Hi Roy, > > please find some comments below: > > Roy, Radhika R. wrote: > >> Hannes: > >> > >> It is a good question to discuss in the mailing list. I appreciate your > >> question. Let me explain again as follows: > >> > >> 1. > >> > >> QSPEC is a generic spec that can be used by any QoS models. So, this > >> draft must be a stand-alone draft without dealing with any "specific" > >> extensions of any "specific" QoS models. > > By generic you mean: The QSPEC template draft defines parameters that > > can be reused by more than one QoSM. Right? > > [RRR] More specifically - QSPEC must not deal with how to "extend" its > parameters for implementation of specific QoS models that depend on > "specific" values of delay, jitter, or packet loss. Kindly see the > explanations provided above. > >> 2. > >> > >> It can be seen that many "specific" QoS models like Y.1541 may come > >> in the future just by changing some values in parameters like delay, > jitter, > >> loss, etc. > > You mean: In the future QoSM designers might use the QSPEC draft as a > > template to pick their favorite parameters (such as bandwidth, delay, > > etc.) and potentially have to define additional parameters to finalize > > their QoSM design. > > [RRR] You are right, but it is one of the examples that you have > provided that I call that a specific QoS model that depends on > "grouping" on some QoS parameters. > > [RRR] The interesting thing is this: 1) A specific QoS model can also be > defined "only" on "grouping" of the QoS parameters without defining any > specific values of any QoS parameters and 2) A specific QoS model may be > very tightly coupled by defining both "grouping" of parameters and the > specific value of each parameter of each group. > > [RRR] Y.1541 QoS model depends on Category 2 as stated above. > >> That does not mean we have extend our "generic" QSPEC draft again > >> and again for those "specific" extensions. It is technically > inconsistent to > >> "mix" a generic draft with extensions of some "specific" QoS models. > Is this > >> clear? > > Well, the parameters listed in the QSPEC template draft are taken from > > existing QoSMs and the assumption is that they are sufficiently generic > > so that they might be used by other QoSMs in the future as well. > > [RRR] Kindly see that the general explanations that I have provided for > Sections 7.2.6.1 - 7.2.6.3 of the draft. These sections are NOT > "generic." They address specific extensions of QSPEC templates for > specific QoS models. These sections need to be removed and the generic > texts to be used, and the separate drafts need to be written for each > QoS model extending QSPEC templates. > >> 3. > >> > >> The specific extensions of QSPEC parameters for Y.1541 and/or other > >> QoS models in this generic draft is OUT-of-SCOPE. > > This is no separate argument. > >> 4. > >> > >> It is can be easily seen that there are many extensions of QSPEC > >> parameters are needed to have the complete implementation of Y.1541 QoS > >> models as these have been addressed specific to Y.1541-QSPEC draft that is > >> going through the WGLC. If this is so, why do we need to pollute the > generic > >> QSPEC draft with some "incomplete" extensions of QSPEC parameters for a > >> "specific" Y.1451 QoS model? Why does this the "specific" QSPEC-Y.1541 > draft > >> MUST not be, like generic QSPEC draft, a stand-alone draft by its own > merit? > >> > > I don't get the point with this bullet. > > [RRR] Kindly see that the general explanations that I have provided for > Sections 7.2.6.1 - 7.2.6.3 of the draft. These sections are NOT "generic." > >> Hope that the above shows that there are enough technical reasons why > I have > >> been providing comments for a long time. I would appreciate if you would > >> provide any good technical reason against all the comments that I have > >> provided above. > > > Do you think that any of the classes listed in Section 7.2.6 are generic > > enough to be useful in the document? > > _http://www.ietf.org/internet-drafts/draft-ietf-nsis-qspec-09.txt_ > > [RRR] Kindly see that the general explanations that I have provided for > Sections 7.2.6.1 - 7.2.6.3 of the draft. These sections are NOT "generic." > >> > >> Best regards, > >> > >> Radhika > > Ciao > > Hannes > >> > >> > >> > >> _____ > >> > >> From: nsis-bounces@ietf.org on behalf of Hannes Tschofenig > >> Sent: Mon 4/10/2006 7:06 AM > >> To: Roy, Radhika R. > >> Cc: john.loughney@nokia.com; nsis@ietf.org > >> Subject: Re: [NSIS] WGLC on RMD & Y.1541 > >> > >> > >> > >> Hi Roy, > >> > >> my impression over the last year was that you are not unbiased when it > >> comes to Y.1541. This is a problem. > >> > >> Now, you want to see the Y.1541 content moved to a separate document (to > >> the Y.1541 QoSM draft). > >> > >> Can you motivate your desire to move this particular text to another > >> document? Why not other parts? > >> > >> Ciao > >> Hannes > >> > >> Roy, Radhika R. wrote: > >> > >> >John: > >> > > >> >The comments that I have provided on this yesterday (in the context > >> >of IETF # 65 meeting minutes) need to be addressed in the Y.1541 > >> >draft. > >> > > >> >Basically, this document needs to be a stand-alone document for > >> >extensions of QSPEC parameters for Y.1541, and the main QSPEC draft > >> >MUST be a generic draft without any specific extensions for any specs > >> >like Y.1541, etc. > >> > > >> >If any help is needed to modify the document per above suggestion, > >> >please let me know. I will volunteer to do so. > >> > > >> >Best regards, Radhika > >> > > >> >_____ > >> > > >> >From: nsis-bounces@ietf.org on behalf of john.loughney@nokia.com > >> >Sent: Mon 4/10/2006 2:12 AM To: nsis@ietf.org Subject: [NSIS] WGLC on > >> >RMD & Y.1541 > >> > > >> > > >> > > >> >Hi all, > >> > > >> >The WGLC ended on both the RMD and Y.1541 QoSM documents. A number of > >> > issues have been identified and were discussed at IETF 65. > >> >Additionally, there were very few comments received on these > >> >documents. These documents cannot procede without review. If you > >> >have read the document and think that they are ready, then please let > >> >us know. The authors are revising the documents, and after the > >> >documents are resubmitted, we'll need another WGLC is needed befor > >> >the documents are submitted to the IESG. > >> > > >> >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 nsis-bounces@ietf.org Mon Apr 10 20:28:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FT6kE-00065E-Kk; Mon, 10 Apr 2006 20:28:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FT6kC-00064g-Pl for nsis@ietf.org; Mon, 10 Apr 2006 20:28:32 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FT5fZ-0001p5-Ko for nsis@ietf.org; Mon, 10 Apr 2006 19:19:41 -0400 Received: from mclmx2.mail.saic.com ([149.8.64.32]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FT5Xs-0000F6-TL for nsis@ietf.org; Mon, 10 Apr 2006 19:11:47 -0400 Received: from 0015-its-ieg02.mail.saic.com ([149.8.64.21] [149.8.64.21]) by mclmx2.mail.saic.com; Mon, 10 Apr 2006 19:11:31 -0400 Received: from mcl-its-exig01.mail.saic.com ([149.8.64.12]) by 0015-its-ieg02.mail.saic.com (SMSSMTP 4.0.5.66) with SMTP id M2006041019113027048 ; Mon, 10 Apr 2006 19:11:30 -0400 Received: by mcl-its-exig01.mail.saic.com with Internet Mail Service (5.5.2657.72) id ; Mon, 10 Apr 2006 19:11:31 -0400 Message-Id: <62D92A9A02BCC845B202323D49A48426209C36@0591-ITS-EXMP02.us.saic.com> From: "Roy, Radhika R." To: Hannes Tschofenig , "Roy, Radhika R." Subject: RE: [NSIS] WGLC on RMD & Y.1541 Date: Mon, 10 Apr 2006 19:11:27 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) content-class: urn:content-classes:message Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: -1.0 (-) X-Scan-Signature: fbe0995f04cc21309ef8614a2838e306 Cc: john.loughney@nokia.com, nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hannes: Right. If this is done already, we will have no issues as the QSPEC draft can be a stand-alone "GENERIC" draft all by itself. In the same token, Y.1541-QSPEC draft can also be a stand-alone draft all by itself, and people will NOT be confused as it will contain all of its Y.1541 QoS model-specific intensions in one draft. If those two drafts become completely separate, we will have no more technical issues. All we need to do is to improve its texts especially for the QSPEC Template draft to make it so generic that it will be a universal template for all QoS signaling schemes that people are yet to imagine in the future. In this case, I would even propose to make it (QOS Template draft) a "standard-track RFC." We appreciate your help in this regard. Best regards, Radhika _____ From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] Sent: Mon 4/10/2006 5:42 PM To: Roy, Radhika R. Cc: john.loughney@nokia.com; nsis@ietf.org Subject: Re: [NSIS] WGLC on RMD & Y.1541 Hi Roy, to summarize what you say: The parameters used in Section 7.2.6.1 - Section 7.2.6.3 are QoSM specific and provide little value for reuse among other QoSM. Since the QSPEC draft aims to be a toolbox that provides attributes that can be reused by multiple QoSMs you suggest to delete these sections from the QSPEC draft and to deal with them in a separate document (which is, btw, partically done already). Ciao Hannes Roy, Radhika R. wrote: > Hannes: > > Probably, we have missed the finer technical arguments due to lack of > specific references of the QSPEC draft. Let me provide the sections of > the draft that I am talking about as follows: > > > > 7.2.6.1 Parameter . . . . . . . . . . . . 29 > > 7.2.6.2 Parameter . . . . . . . . 29 > > 7.2.6.3 Parameter . . . . . . . . . 30 > > These above sections deal with "use cases" of QSPEC parameters for > different "specific" QoS models that are implementation-specifics, and > do NOT belong to the "generic" QSPEC draft. > > For example, Y.1541 QoS classes depend on some "specific values" of > delay, jitter, or packet loss. If any values of any parameters are > changed, it will NOT be called as Y.1541 QoS model. More over, the > extensions shown here are NOT complete in all respects. The other > Y.1541-draft shows how many other things need to be dealt with respect > QOSEC for implementations of Y.1541 QoS model. > > So, the suggestions are as follows: > > 1. Remove the use cases of QoS models from this "generic" QSPEC > draft. That is, remove Sections 7.2.6.1 - 7.2.6.3 from this draft. > > 2. Make Section 7.2.6 a generic one by explaining the fact that > "there are many QoS models that may use this generic QSPEC template for > "specific" implementations of different QoS models in the context of the > public Internet, Enterprise networks, or other networks. > > 3. In the same token, the Y.1541-QSPEC draft should be a > stand-alone draft that will deal with implementations of the Y.1541 QoS > model extending all QSPEC parameters. > > 4. Similarly, we can write separate drafts for DSTE and DiffServ > network for implementations of those QoS models extending the QSPEC > parameters for specific purposes. > > More inline [RRR]. > > I really appreciate your help for technical clarifications. > > Best regards, > > Radhika > > -----Original Message----- > From: Hannes.Tschofenig@gmx.net [mailto:Hannes.Tschofenig@gmx.net ] > Sent: Monday, April 10, 2006 8:11 AM > To: Roy, Radhika R. > Cc: john.loughney@nokia.com; nsis@ietf.org > Subject: Re: [NSIS] WGLC on RMD & Y.1541 > > Hi Roy, > > please find some comments below: > > Roy, Radhika R. wrote: > >> Hannes: > >> > >> It is a good question to discuss in the mailing list. I appreciate your > >> question. Let me explain again as follows: > >> > >> 1. > >> > >> QSPEC is a generic spec that can be used by any QoS models. So, this > >> draft must be a stand-alone draft without dealing with any "specific" > >> extensions of any "specific" QoS models. > > By generic you mean: The QSPEC template draft defines parameters that > > can be reused by more than one QoSM. Right? > > [RRR] More specifically - QSPEC must not deal with how to "extend" its > parameters for implementation of specific QoS models that depend on > "specific" values of delay, jitter, or packet loss. Kindly see the > explanations provided above. > >> 2. > >> > >> It can be seen that many "specific" QoS models like Y.1541 may come > >> in the future just by changing some values in parameters like delay, > jitter, > >> loss, etc. > > You mean: In the future QoSM designers might use the QSPEC draft as a > > template to pick their favorite parameters (such as bandwidth, delay, > > etc.) and potentially have to define additional parameters to finalize > > their QoSM design. > > [RRR] You are right, but it is one of the examples that you have > provided that I call that a specific QoS model that depends on > "grouping" on some QoS parameters. > > [RRR] The interesting thing is this: 1) A specific QoS model can also be > defined "only" on "grouping" of the QoS parameters without defining any > specific values of any QoS parameters and 2) A specific QoS model may be > very tightly coupled by defining both "grouping" of parameters and the > specific value of each parameter of each group. > > [RRR] Y.1541 QoS model depends on Category 2 as stated above. > >> That does not mean we have extend our "generic" QSPEC draft again > >> and again for those "specific" extensions. It is technically > inconsistent to > >> "mix" a generic draft with extensions of some "specific" QoS models. > Is this > >> clear? > > Well, the parameters listed in the QSPEC template draft are taken from > > existing QoSMs and the assumption is that they are sufficiently generic > > so that they might be used by other QoSMs in the future as well. > > [RRR] Kindly see that the general explanations that I have provided for > Sections 7.2.6.1 - 7.2.6.3 of the draft. These sections are NOT > "generic." They address specific extensions of QSPEC templates for > specific QoS models. These sections need to be removed and the generic > texts to be used, and the separate drafts need to be written for each > QoS model extending QSPEC templates. > >> 3. > >> > >> The specific extensions of QSPEC parameters for Y.1541 and/or other > >> QoS models in this generic draft is OUT-of-SCOPE. > > This is no separate argument. > >> 4. > >> > >> It is can be easily seen that there are many extensions of QSPEC > >> parameters are needed to have the complete implementation of Y.1541 QoS > >> models as these have been addressed specific to Y.1541-QSPEC draft that is > >> going through the WGLC. If this is so, why do we need to pollute the > generic > >> QSPEC draft with some "incomplete" extensions of QSPEC parameters for a > >> "specific" Y.1451 QoS model? Why does this the "specific" QSPEC-Y.1541 > draft > >> MUST not be, like generic QSPEC draft, a stand-alone draft by its own > merit? > >> > > I don't get the point with this bullet. > > [RRR] Kindly see that the general explanations that I have provided for > Sections 7.2.6.1 - 7.2.6.3 of the draft. These sections are NOT "generic." > >> Hope that the above shows that there are enough technical reasons why > I have > >> been providing comments for a long time. I would appreciate if you would > >> provide any good technical reason against all the comments that I have > >> provided above. > > > Do you think that any of the classes listed in Section 7.2.6 are generic > > enough to be useful in the document? > > _http://www.ietf.org/internet-drafts/draft-ietf-nsis-qspec-09.txt_ > > [RRR] Kindly see that the general explanations that I have provided for > Sections 7.2.6.1 - 7.2.6.3 of the draft. These sections are NOT "generic." > >> > >> Best regards, > >> > >> Radhika > > Ciao > > Hannes > >> > >> > >> > >> _____ > >> > >> From: nsis-bounces@ietf.org on behalf of Hannes Tschofenig > >> Sent: Mon 4/10/2006 7:06 AM > >> To: Roy, Radhika R. > >> Cc: john.loughney@nokia.com; nsis@ietf.org > >> Subject: Re: [NSIS] WGLC on RMD & Y.1541 > >> > >> > >> > >> Hi Roy, > >> > >> my impression over the last year was that you are not unbiased when it > >> comes to Y.1541. This is a problem. > >> > >> Now, you want to see the Y.1541 content moved to a separate document (to > >> the Y.1541 QoSM draft). > >> > >> Can you motivate your desire to move this particular text to another > >> document? Why not other parts? > >> > >> Ciao > >> Hannes > >> > >> Roy, Radhika R. wrote: > >> > >> >John: > >> > > >> >The comments that I have provided on this yesterday (in the context > >> >of IETF # 65 meeting minutes) need to be addressed in the Y.1541 > >> >draft. > >> > > >> >Basically, this document needs to be a stand-alone document for > >> >extensions of QSPEC parameters for Y.1541, and the main QSPEC draft > >> >MUST be a generic draft without any specific extensions for any specs > >> >like Y.1541, etc. > >> > > >> >If any help is needed to modify the document per above suggestion, > >> >please let me know. I will volunteer to do so. > >> > > >> >Best regards, Radhika > >> > > >> >_____ > >> > > >> >From: nsis-bounces@ietf.org on behalf of john.loughney@nokia.com > >> >Sent: Mon 4/10/2006 2:12 AM To: nsis@ietf.org Subject: [NSIS] WGLC on > >> >RMD & Y.1541 > >> > > >> > > >> > > >> >Hi all, > >> > > >> >The WGLC ended on both the RMD and Y.1541 QoSM documents. A number of > >> > issues have been identified and were discussed at IETF 65. > >> >Additionally, there were very few comments received on these > >> >documents. These documents cannot procede without review. If you > >> >have read the document and think that they are ready, then please let > >> >us know. The authors are revising the documents, and after the > >> >documents are resubmitted, we'll need another WGLC is needed befor > >> >the documents are submitted to the IESG. > >> > > >> >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 nsis-bounces@ietf.org Tue Apr 11 01:57:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTBso-0005hT-Uu; Tue, 11 Apr 2006 01:57:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTBso-0005h6-1j for nsis@ietf.org; Tue, 11 Apr 2006 01:57:46 -0400 Received: from mgw-ext12.nokia.com ([131.228.20.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTBsm-0000kK-IK for nsis@ietf.org; Tue, 11 Apr 2006 01:57:46 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext12.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k3B5u422000739; Tue, 11 Apr 2006 08:56:05 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 11 Apr 2006 08:57:43 +0300 Received: from esebe100.NOE.Nokia.com ([172.21.138.118]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 11 Apr 2006 08:57:42 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] one or separate qos models for classic and PCN CLrespectively Date: Tue, 11 Apr 2006 08:57:41 +0300 Message-ID: <615BD9B54CB01B41838C323DB9E91AAB0C92CD@esebe100.NOE.Nokia.com> In-Reply-To: <6439282641581441A36F7F6F83ED2ED20E62F0@S4DE8PSAAFQ.mitte.t-com.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] one or separate qos models for classic and PCN CLrespectively Thread-Index: AcZaDat2IopASN+CSLaOYVmMh19KgwDHk3hg From: To: , X-OriginalArrivalTime: 11 Apr 2006 05:57:42.0539 (UTC) FILETIME=[D8E3CDB0:01C65D2C] X-Spam-Score: 0.2 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Rudy, >the issue was raised in the minutes to be taken to the list. > >Arguments to support only a single QoS model are: > >- simplification of the end system (which doesn't have to > worry which flavor of a CL QoS model is applied by the > network or by the remote end system). > >- no mapping or interworking required. > >That would assume that the characteristics of the service are=20 >the same, no matter how it is produced. But this question will=20 >arise with any interworking. CL over IP/MPLS, CL over=20 >aggregated NSIS, CL over a network avoiding packet losses by=20 >provisioning. > >My position would be, if a carrier guarantees service, CL can=20 >be produced and should use a single QoS model. Independent of=20 >the way the CL service is produced in the backbone. Not quite sure what your exact opinion is - are you saying that CL SHOULD be the default QoS handling, or are you suggesting that if an operator wants CL, they use CL? Some off-line discussions indicate that there might be interest in a basic inter-domain QoS model - for signaling QoS between different service providers. This QoS model would be independent of how QoS is deployed within a network. Would this be something of interst? John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Apr 11 02:22:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTCGr-000689-0U; Tue, 11 Apr 2006 02:22:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTCGo-0005iT-JQ for nsis@ietf.org; Tue, 11 Apr 2006 02:22:34 -0400 Received: from tcmail33.telekom.de ([217.6.95.240]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTCGU-0002cw-D1 for nsis@ietf.org; Tue, 11 Apr 2006 02:22:15 -0400 Received: from s4de8psaans.mitte.t-com.de by tcmail31.dmz.telekom.de with ESMTP; Tue, 11 Apr 2006 08:22:02 +0200 Received: by S4DE8PSAANS.blf.telekom.de with Internet Mail Service (5.5.2653.19) id <24GX7LAR>; Tue, 11 Apr 2006 08:22:01 +0200 Message-Id: <6439282641581441A36F7F6F83ED2ED20E62FF@S4DE8PSAAFQ.mitte.t-com.de> From: "Geib, Ruediger" To: john.loughney@nokia.com Subject: RE: [NSIS] one or separate qos models for classic and PCN CLrespe ctively Date: Tue, 11 Apr 2006 08:21:49 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org John, the only purpose of my message was to suggest a one single QoS model to signal CL. I didn't suggest CL as the default QoS handling. A basic QoS model understood and supported by all carriers would sure be helpful. I recall the DiffServ and IPPM discussions - IETF refused to define performance in quantitaive numbers these days. But carrier class QoS requires SLAs determining performance in measurable terms. So the ITU approach is charming. A good question may be, which aspect of the issue should be handled by NSIS or IETF respectively. Regards, Rudiger Rudi|> the issue was raised in the minutes to be taken to the list. |> |>Arguments to support only a single QoS model are: |> |>- simplification of the end system (which doesn't have to |> worry which flavor of a CL QoS model is applied by the |> network or by the remote end system). |> |>- no mapping or interworking required. |> |>That would assume that the characteristics of the service are |>the same, no matter how it is produced. But this question will |>arise with any interworking. CL over IP/MPLS, CL over |>aggregated NSIS, CL over a network avoiding packet losses by |>provisioning. |> |>My position would be, if a carrier guarantees service, CL can |>be produced and should use a single QoS model. Independent of |>the way the CL service is produced in the backbone. | John| Not quite sure what your exact opinion is - are you saying that |CL SHOULD be the default QoS handling, or are you suggesting |that if an operator wants CL, they use CL? | |Some off-line discussions indicate that there might be interest in |a basic inter-domain QoS model - for signaling QoS between different |service providers. This QoS model would be independent of how |QoS is deployed within a network. Would this be something of |interst? | |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 nsis-bounces@ietf.org Tue Apr 11 12:04:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTLLx-0003Ai-5j; Tue, 11 Apr 2006 12:04:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTLLw-0003Ad-Cv for nsis@ietf.org; Tue, 11 Apr 2006 12:04:28 -0400 Received: from mail120.messagelabs.com ([216.82.250.83]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FTLLu-0007fx-1u for nsis@ietf.org; Tue, 11 Apr 2006 12:04:28 -0400 X-VirusChecked: Checked X-Env-Sender: gash@att.com X-Msg-Ref: server-9.tower-120.messagelabs.com!1144771326!9601997!35 X-StarScan-Version: 5.5.9.1; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 2802 invoked from network); 11 Apr 2006 16:04:24 -0000 Received: from unknown (HELO attrh3i.attrh.att.com) (134.24.146.4) by server-9.tower-120.messagelabs.com with SMTP; 11 Apr 2006 16:04:24 -0000 Received: from kcclust06evs1.ugd.att.com (135.38.164.88) by attrh3i.attrh.att.com (7.2.052) id 4426C9FE0021F3DA; Tue, 11 Apr 2006 12:04:24 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] Re: Updated IETF#65 Meeting Minutes Date: Tue, 11 Apr 2006 11:04:24 -0500 Message-ID: <9473683187ADC049A855ED2DA739ABCA0DDC7625@KCCLUST06EVS1.ugd.att.com> In-Reply-To: <443911D0.4080300@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] Re: Updated IETF#65 Meeting Minutes Thread-Index: AcZb3QFQpMM6CIzvR2S2qXMIpb0TUwBoDcWg From: "Ash, Gerald R \(Jerry\), ALABS" To: "Hannes Tschofenig" X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: "Ash, Gerald R \(Jerry\), ALABS" , NSIS X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Hannes, > Here is the updated version: > http://www3.ietf.org/proceedings/06mar/minutes/nsis.txt >=20 > Please take a look at them. A few corrections/additions/changes: Change (RE QoS-NSLP): "- Jerry Ash: Error codes and QSPEC related errors needs also clarification" To "- Jerry Ash: Error codes and QSPEC related errors also needs clarification. Also discussion on intermediate domains and mandatory parameters, reaction to missing parameters etc. - John Loughney: John speaks about the QSPEC and QOSM idea." Change (RE Y.1541-QOSM): "- Jerry Ash: No updates; Completed WGLC, but had no comments,=20 so probably not 'successfully compeleted WGLC'.=20 May need revisions based on QoS NSLP and QSpec discussions." To "- Jerry Ash: No updates; Completed WGLC, no comments on the list.=20 - John Loughney: So probably not 'successfully completed WGLC'.=20 May need revisions based on QoS NSLP and QSpec discussions." Change (RE RMD-QOSM): "- Georgios: doesn't mean you can't do it - Paulo: but you can't signal the DSCP end-to-end - Jerry: What does this add to existing QoSM?" To "- Georgios: doesn't mean you can't do it - Paulo: but you can't signal the DSCP end-to-end" (I made no such comment here) Thanks, Regards, Jerry _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Apr 11 16:58:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTPwe-0003Yf-3b; Tue, 11 Apr 2006 16:58:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTPwd-0003VJ-3I; Tue, 11 Apr 2006 16:58:39 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTP6j-0000oU-HA; Tue, 11 Apr 2006 16:05:01 -0400 Received: from chsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.24.129] helo=oak.neustar.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FTOsE-0001eZ-Bm; Tue, 11 Apr 2006 15:50:04 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k3BJo1BX012219 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 11 Apr 2006 19:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FTOsD-0006MD-UT; Tue, 11 Apr 2006 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 11 Apr 2006 15:50:01 -0400 X-Spam-Score: -5.9 (-----) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: nsis@ietf.org Subject: [NSIS] I-D ACTION:draft-ietf-nsis-nslp-natfw-11.txt X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Next Steps in Signaling Working Group of the IETF. Title : NAT/Firewall NSIS Signaling Layer Protocol (NSLP) Author(s) : M. Stiemerling, et al. Filename : draft-ietf-nsis-nslp-natfw-11.txt Pages : 101 Date : 2006-4-11 This memo defines the NSIS Signaling Layer Protocol (NSLP) for Network Address Translators (NATs) and firewalls. This NSLP allows hosts to signal on the data path for NATs and firewalls to be configured according to the needs of the application data flows. It enables hosts behind NATs to obtain a public reachable address and hosts behind firewalls to receive data traffic. The overall architecture is given by the framework and requirements defined by the Next Steps in Signaling (NSIS) working group. The network scenarios, the protocol itself, and examples for path-coupled signaling are given in this memo. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nsis-nslp-natfw-11.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-nsis-nslp-natfw-11.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-nsis-nslp-natfw-11.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: <2006-4-11141742.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nsis-nslp-natfw-11.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nsis-nslp-natfw-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-4-11141742.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis --NextPart-- From nsis-bounces@ietf.org Wed Apr 12 03:44:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTa14-0003yn-0W; Wed, 12 Apr 2006 03:43:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTa13-0003yi-5I for nsis@ietf.org; Wed, 12 Apr 2006 03:43:53 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FTa11-0002Kg-N2 for nsis@ietf.org; Wed, 12 Apr 2006 03:43:53 -0400 Received: (qmail invoked by alias); 12 Apr 2006 07:43:46 -0000 Received: from socks2.netz.sbs.de (EHLO [192.35.17.25]) [192.35.17.25] by mail.gmx.net (mp003) with SMTP; 12 Apr 2006 09:43:46 +0200 X-Authenticated: #29516787 Message-ID: <443CAFAF.4030609@gmx.net> Date: Wed, 12 Apr 2006 09:43:43 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Ash, Gerald R \(Jerry\), ALABS" Subject: Re: [NSIS] Re: Updated IETF#65 Meeting Minutes References: <9473683187ADC049A855ED2DA739ABCA0DDC7625@KCCLUST06EVS1.ugd.att.com> In-Reply-To: <9473683187ADC049A855ED2DA739ABCA0DDC7625@KCCLUST06EVS1.ugd.att.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: NSIS X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Done; http://www3.ietf.org/proceedings/06mar/minutes/nsis.txt Ciao Hannes Ash, Gerald R (Jerry), ALABS wrote: > Hi Hannes, > > >>Here is the updated version: >>http://www3.ietf.org/proceedings/06mar/minutes/nsis.txt >> >>Please take a look at them. > > > A few corrections/additions/changes: > > Change (RE QoS-NSLP): > "- Jerry Ash: Error codes and QSPEC related errors needs also > clarification" > To > "- Jerry Ash: Error codes and QSPEC related errors also needs > clarification. Also discussion on intermediate domains and mandatory > parameters, reaction to missing parameters etc. > - John Loughney: John speaks about the QSPEC and QOSM idea." > > Change (RE Y.1541-QOSM): > "- Jerry Ash: No updates; > Completed WGLC, but had no comments, > so probably not 'successfully compeleted WGLC'. > May need revisions based on QoS NSLP and QSpec discussions." > To > "- Jerry Ash: No updates; > Completed WGLC, no comments on the list. > - John Loughney: So probably not 'successfully completed WGLC'. > May need revisions based on QoS NSLP and QSpec discussions." > > Change (RE RMD-QOSM): > "- Georgios: doesn't mean you can't do it > - Paulo: but you can't signal the DSCP end-to-end > - Jerry: What does this add to existing QoSM?" > To > "- Georgios: doesn't mean you can't do it > - Paulo: but you can't signal the DSCP end-to-end" > (I made no such comment here) > > Thanks, > Regards, > Jerry > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Apr 12 08:21:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTeLy-0007JD-TT; Wed, 12 Apr 2006 08:21:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTeLx-0007J8-QB for nsis@ietf.org; Wed, 12 Apr 2006 08:21:45 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTdwr-0002Ie-IK for nsis@ietf.org; Wed, 12 Apr 2006 07:55:49 -0400 Received: from mailing.unile.it ([193.204.77.251]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FTdiM-0001zk-Rh for nsis@ietf.org; Wed, 12 Apr 2006 07:40:52 -0400 Received: from elena (unknown [10.0.12.228]) by mailing.unile.it (Postfix) with SMTP id A6428104B5F; Wed, 12 Apr 2006 13:40:48 +0200 (CEST) Message-ID: <00e101c65e25$f1c75050$e40c000a@elena> From: "Elena Scialpi" To: References: <44368F9C.7020804@cs.uni-goettingen.de> Subject: Re: [NSIS] draft-tommasi-nsis-semipro-00 Date: Wed, 12 Apr 2006 13:40:48 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1506 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-Spam-Score: -2.6 (--) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org > Hi Elena, > > I read through your draft > http://www.ietf.org/internet-drafts/draft-tommasi-nsis-semipro-00.txt and have > some questions on it. > > Before a potential handoff you install a GA, but no QoS state. The QoS State is > installed after the handoff occurred. The reason for the late QoS installation > is saving resources against a proactive procedure. The QUERY message is used to > setup GIST state. So setting up GA is to speed up the reservation against a > reactive procedure. > > Does the M-Flag indicate that the RESERVE msg followed by a QUERY is only sent > after a handoff? > M-flag in a Query message indicates to the QNI to wait the end of the handover for sending the Reserve message. In a semi-proactive procedure m-flag is enough to do this. > After a handoff what happens to the old reservation? How are Ping Pong handovers > handled? Is the old reservation torn down immediately or is it held for some time? > After an handoff old reservation are torn down only between CRN and NAR (see Local Path Repair - section 3.4). In the draft we propose to tear down the old reservation as soon as the new one has been reservated on the new local path. Then, we not manage now a ping pong handover. > Why is it necessary to have a buffering mechanism when the MN is the flow > receiver? In realtime applications (voice or video streming) it is better from > my point of view to accept the packet loss instead of receiving delayed data. > Buffering increases the performance for pure data streams, e.g. a FTP download. > Buffering mechanism is necessary to avoid packet loss during the handover. Optimezed smooth handoff proposes to buffer the packets at the PAR. We propose to buffer the packets in a node on the end-to-end path near to the NAR (the CRN). This allow to reduce the delay when the buffered packets must reach the NAR. > Bernd > Ciao, Elena > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Apr 12 11:01:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTgqd-0004Jq-I2; Wed, 12 Apr 2006 11:01:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTgqb-0004Ji-Jb for nsis@ietf.org; Wed, 12 Apr 2006 11:01:33 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTf4z-0004vp-Mb for nsis@ietf.org; Wed, 12 Apr 2006 09:08:17 -0400 Received: from mailing.unile.it ([193.204.77.251]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FTezI-0002aI-S7 for nsis@ietf.org; Wed, 12 Apr 2006 09:02:26 -0400 Received: from elena (unknown [10.0.12.228]) by mailing.unile.it (Postfix) with SMTP id A681D104B62; Wed, 12 Apr 2006 15:02:22 +0200 (CEST) Message-ID: <012e01c65e31$576ff000$e40c000a@elena> From: "Gregory William Ray" To: References: <44368F9C.7020804@cs.uni-goettingen.de> <00e101c65e25$f1c75050$e40c000a@elena> Subject: Re: [NSIS] draft-tommasi-nsis-semipro-00 Date: Wed, 12 Apr 2006 15:02:23 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1506 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-Spam-Score: -2.6 (--) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Cc: Elena Scialpi X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org > > Hi Elena, > > > > I read through your draft > > http://www.ietf.org/internet-drafts/draft-tommasi-nsis-semipro-00.txt and > have > > some questions on it. > > > > Before a potential handoff you install a GA, but no QoS state. The QoS > State is > > installed after the handoff occurred. The reason for the late QoS > installation > > is saving resources against a proactive procedure. The QUERY message is > used to > > setup GIST state. So setting up GA is to speed up the reservation against > a > > reactive procedure. > > > > Does the M-Flag indicate that the RESERVE msg followed by a QUERY is only > sent > > after a handoff? > > > > > M-flag in a Query message indicates to the QNI to wait the end of the > handover for sending the Reserve message. In a semi-proactive procedure > m-flag is enough to do this. > > > > After a handoff what happens to the old reservation? How are Ping Pong > handovers > > handled? Is the old reservation torn down immediately or is it held for > some time? > > > > > > After an handoff old reservation are torn down only between CRN and NAR (see > Local Path Repair - section 3.4). In the draft we propose to tear down the > old reservation as soon as the new one has been reservated on the new local > path. Then, we not manage now a ping pong handover. > > To retard the elimination of the resource reservated on the old local path can help in a ping pong handover? > > > Why is it necessary to have a buffering mechanism when the MN is the flow > > receiver? In realtime applications (voice or video streming) it is better > from > > my point of view to accept the packet loss instead of receiving delayed > data. > > Buffering increases the performance for pure data streams, e.g. a FTP > download. > > > > Buffering mechanism is necessary to avoid packet loss during the handover. > Optimezed smooth handoff proposes to buffer the packets at the PAR. > We propose to buffer the packets in a node on the end-to-end path near to > the NAR (the CRN). This allow to reduce the delay when the buffered > packets must reach the NAR. > > > > > Bernd > > > Ciao, > Elena > > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Apr 13 08:37:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FU14f-00022B-K3; Thu, 13 Apr 2006 08:37:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FU14e-0001xV-7m for nsis@ietf.org; Thu, 13 Apr 2006 08:37:24 -0400 Received: from mgw-ext13.nokia.com ([131.228.20.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FU14c-0002kL-MA for nsis@ietf.org; Thu, 13 Apr 2006 08:37:24 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext13.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k3DCa9wW005666 for ; Thu, 13 Apr 2006 15:36:12 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Apr 2006 15:35:23 +0300 Received: from esebe100.NOE.Nokia.com ([172.21.138.118]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Apr 2006 15:35:22 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 13 Apr 2006 15:35:22 +0300 Message-ID: <615BD9B54CB01B41838C323DB9E91AAB4074D6@esebe100.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WGLC on " NAT/Firewall NSIS Signaling Layer Protocol (NSLP)" to start next week Thread-Index: AcZe9rtzEuU99HuiRF+1+vjKTK1bEw== From: To: X-OriginalArrivalTime: 13 Apr 2006 12:35:22.0711 (UTC) FILETIME=[BB7C9E70:01C65EF6] X-Spam-Score: 0.2 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Subject: [NSIS] WGLC on " NAT/Firewall NSIS Signaling Layer Protocol (NSLP)" to start next week X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi all, The authors have indicated that they think that the draft is ready for WGLC. As long as the WG agrees, I'd like to start a WGLC on Monday April 17th, until May 1st. Feel free to send comments beforehand, however. http://www.ietf.org/internet-drafts/draft-ietf-nsis-nslp-natfw-11.txt thanks, John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Apr 14 13:24:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUS1k-0007Z9-2J; Fri, 14 Apr 2006 13:24:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUS1i-0007Z4-RQ for nsis@ietf.org; Fri, 14 Apr 2006 13:24:10 -0400 Received: from mail1.mclink.it ([195.110.128.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FUS1i-0000ce-6v for nsis@ietf.org; Fri, 14 Apr 2006 13:24:10 -0400 Received: from elena (net84-253-130-140.mclink.it [84.253.130.140]) by mail1.mclink.it (8.12.6p2/8.12.3) with SMTP id k3EHO015039786; Fri, 14 Apr 2006 19:24:02 +0200 (CEST) (envelope-from scel@inwind.it) Message-ID: <005e01c65fe8$3b2aa620$19b2a8c0@elena> From: "Elena Scialpi" To: References: <44368F9C.7020804@cs.uni-goettingen.de><00e101c65e25$f1c75050$e40c000a@elena> <012e01c65e31$576ff000$e40c000a@elena> Subject: Re: [NSIS] draft-tommasi-nsis-semipro-00 Date: Fri, 14 Apr 2006 19:22:57 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1506 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-Spam-Score: 0.0 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Cc: Gregory William Ray X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org > > > Hi Elena, > > > > > > I read through your draft > > > http://www.ietf.org/internet-drafts/draft-tommasi-nsis-semipro-00.txt > and > > have > > > some questions on it. > > > > > > Before a potential handoff you install a GA, but no QoS state. The QoS > > State is > > > installed after the handoff occurred. The reason for the late QoS > > installation > > > is saving resources against a proactive procedure. The QUERY message is > > used to > > > setup GIST state. So setting up GA is to speed up the reservation > against > > a > > > reactive procedure. > > > > > > Does the M-Flag indicate that the RESERVE msg followed by a QUERY is > only > > sent > > > after a handoff? > > > > > > > > > M-flag in a Query message indicates to the QNI to wait the end of the > > handover for sending the Reserve message. In a semi-proactive procedure > > m-flag is enough to do this. > > > > > > > After a handoff what happens to the old reservation? How are Ping Pong > > handovers > > > handled? Is the old reservation torn down immediately or is it held for > > some time? > > > > > > > > > > > After an handoff old reservation are torn down only between CRN and NAR > (see > > Local Path Repair - section 3.4). In the draft we propose to tear down the > > old reservation as soon as the new one has been reservated on the new > local > > path. Then, we not manage now a ping pong handover. > > > > > > > To retard the elimination of the resource reservated on the old local path > can help in a ping pong handover? > > Yes, it is! In a semi-proactive procedure and a ping pong handover can help also to hold the GIST state on the old local path meanwhile the old resource reservated are torn down. > > > > > > > > Why is it necessary to have a buffering mechanism when the MN is the > flow > > > receiver? In realtime applications (voice or video streming) it is > better > > from > > > my point of view to accept the packet loss instead of receiving delayed > > data. > > > Buffering increases the performance for pure data streams, e.g. a FTP > > download. > > > > > > > Buffering mechanism is necessary to avoid packet loss during the handover. > > Optimezed smooth handoff proposes to buffer the packets at the PAR. > > We propose to buffer the packets in a node on the end-to-end path near to > > the NAR (the CRN). This allow to reduce the delay when the buffered > > packets must reach the NAR. > > > > > > > > > Bernd > > > > > Ciao, > > Elena > > > > > _______________________________________________ > > > nsis mailing list > > > nsis@ietf.org > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > > > > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Apr 17 08:58:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVTJJ-0002MG-JD; Mon, 17 Apr 2006 08:58:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVTJI-0002MB-Il for nsis@ietf.org; Mon, 17 Apr 2006 08:58:32 -0400 Received: from mx5.informatik.uni-tuebingen.de ([134.2.12.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVTJH-0003r2-1X for nsis@ietf.org; Mon, 17 Apr 2006 08:58:32 -0400 Received: from localhost (loopback [127.0.0.1]) by mx5.informatik.uni-tuebingen.de (Postfix) with ESMTP id 55F01115 for ; Mon, 17 Apr 2006 14:58:29 +0200 (MST) Received: from mx3.informatik.uni-tuebingen.de ([134.2.12.26]) by localhost (mx5 [134.2.12.32]) (amavisd-new, port 10024) with ESMTP id 15396-01 for ; Mon, 17 Apr 2006 14:58:21 +0200 (DFT) Received: from [127.0.0.1] (rouen.Informatik.Uni-Tuebingen.De [134.2.11.152]) by mx3.informatik.uni-tuebingen.de (Postfix) with ESMTP id 27302141 for ; Mon, 17 Apr 2006 14:58:19 +0200 (MST) Message-ID: <444390EA.20709@uni-tuebingen.de> Date: Mon, 17 Apr 2006 14:58:18 +0200 From: Ali Fessi User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: nsis@ietf.org References: <615BD9B54CB01B41838C323DB9E91AAB4074D6@esebe100.NOE.Nokia.com> In-Reply-To: <615BD9B54CB01B41838C323DB9E91AAB4074D6@esebe100.NOE.Nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new (McAfee AntiVirus) at informatik.uni-tuebingen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Subject: [NSIS] NATFW NSLP; problem with session ownership X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi all, a proof of session ownership is the NATFW NSLP is supposed to be provided by the session ID. (Section 3.6) However, SID can not provide any garantee that a request is originating from the initial NI; even if it is randomly generated. SID can be eavesdropped and can be miused for replay attacks and cut-and-paste attacks with modified policy rules. Those attacks are already described, e.g. in Section 5.5 and 5.10; but no solution has been provided. The problem with SID is that it is not cryptographically protected. Using it for proof of session ownership would be a mistake in the design of the NATFW NSLP similar to the mistake of using CRC for message integrity for WEP. greeting, Ali -- Ali Fessi University of Tuebingen, Germany _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Apr 17 09:22:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVTg4-0003Lr-6T; Mon, 17 Apr 2006 09:22:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVTg2-0003Lg-PR for nsis@ietf.org; Mon, 17 Apr 2006 09:22:02 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FVTg1-000587-DS for nsis@ietf.org; Mon, 17 Apr 2006 09:22:02 -0400 Received: (qmail invoked by alias); 17 Apr 2006 13:21:57 -0000 Received: from ip-80-226-203-2.vodafone-net.de (EHLO [10.227.136.73]) [80.226.203.2] by mail.gmx.net (mp037) with SMTP; 17 Apr 2006 15:21:57 +0200 X-Authenticated: #29516787 Message-ID: <4443966B.6020605@gmx.net> Date: Mon, 17 Apr 2006 15:21:47 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ali Fessi Subject: Re: [NSIS] NATFW NSLP; problem with session ownership References: <615BD9B54CB01B41838C323DB9E91AAB4074D6@esebe100.NOE.Nokia.com> <444390EA.20709@uni-tuebingen.de> In-Reply-To: <444390EA.20709@uni-tuebingen.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Ali, thanks for revisiting this discussion. In previous draft versions we described a solution based on a cryptographically generated Session Identifier (i.e., using the hash of a public key). Another document also elaborated on the usage of a hash based identifier. We discussed the idea of a crypgraphically generated SIDs in the past but there was never huge excitement about it. Altought the usage of a crypgraphic identifier addresses certain attacks it also comes at a cost. The additional complexity was not seen as a good justification to introduce the cryptgraphic SID to address relatively minor attacks. A randomly generated SID already prevents attacks by off-path adversaries. Adversaries along the path are problematic for various reasons (e.g., injection of data traffic). Ciao Hannes Ali Fessi wrote: > Hi all, > > a proof of session ownership is the NATFW NSLP is supposed to be > provided by the session ID. (Section 3.6) > > However, SID can not provide any garantee that a request is > originating from the initial NI; even if it is randomly generated. > > SID can be eavesdropped and can be miused for replay attacks and > cut-and-paste attacks with modified policy rules. > > Those attacks are already described, e.g. in Section 5.5 and 5.10; but > no solution has been provided. > > The problem with SID is that it is not cryptographically protected. > Using it for proof of session ownership would be a mistake in the design > of the NATFW NSLP similar to the mistake of using CRC for message > integrity for WEP. > > greeting, > Ali _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Apr 17 09:24:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVTio-00044v-DW; Mon, 17 Apr 2006 09:24:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVTin-00044q-0B for nsis@ietf.org; Mon, 17 Apr 2006 09:24:53 -0400 Received: from mx5.informatik.uni-tuebingen.de ([134.2.12.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVTim-0005C4-KG for nsis@ietf.org; Mon, 17 Apr 2006 09:24:52 -0400 Received: from localhost (loopback [127.0.0.1]) by mx5.informatik.uni-tuebingen.de (Postfix) with ESMTP id B4CA2115 for ; Mon, 17 Apr 2006 15:24:51 +0200 (MST) Received: from mx3.informatik.uni-tuebingen.de ([134.2.12.26]) by localhost (mx5 [134.2.12.32]) (amavisd-new, port 10024) with ESMTP id 36778-03 for ; Mon, 17 Apr 2006 15:24:49 +0200 (DFT) Received: from [127.0.0.1] (rouen.Informatik.Uni-Tuebingen.De [134.2.11.152]) by mx3.informatik.uni-tuebingen.de (Postfix) with ESMTP id 1E4A0141 for ; Mon, 17 Apr 2006 15:24:46 +0200 (MST) Message-ID: <4443971D.8000100@uni-tuebingen.de> Date: Mon, 17 Apr 2006 15:24:45 +0200 From: Ali Fessi User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: nsis Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new (McAfee AntiVirus) at informatik.uni-tuebingen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Subject: [NSIS] NATFW NSLP; confidentiality of signaling messages X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi, the draft is currently contradictory on the requirement of message confidentiality. Section: 5.14.1 says: "optionally confidentiality protection" While other sections, e.g. Section 5.13, instructs message confidentiality as a MUST, especially when authorization tokens are transported. Is there a reason for not providing message confidentiality?! From a cryptographic point of view message confidentiality is cheap, since security contexts need to be established between neighboring NSIS nodes anyway. Also, it should be clearly stated that NATFW NSLP does not provide message confidentiality by itself. Rather it relies on underlying protocols, for providing security services such as confidentiality, message integrity, data origin authentication, and replay protection. (In Section 5.14.1 only authentication is mentioned) Greetings, Ali -- Ali Fessi University of Tuebingen, Germany _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Apr 17 10:11:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVURs-00087Y-IS; Mon, 17 Apr 2006 10:11:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVURr-00086o-8V for nsis@ietf.org; Mon, 17 Apr 2006 10:11:27 -0400 Received: from mx5.informatik.uni-tuebingen.de ([134.2.12.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVUGd-000767-04 for nsis@ietf.org; Mon, 17 Apr 2006 09:59:51 -0400 Received: from localhost (loopback [127.0.0.1]) by mx5.informatik.uni-tuebingen.de (Postfix) with ESMTP id C99D311C; Mon, 17 Apr 2006 15:59:49 +0200 (MST) Received: from mx5.informatik.uni-tuebingen.de ([127.0.0.1]) by localhost (mx5 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 36778-04; Mon, 17 Apr 2006 15:59:47 +0200 (DFT) Received: from [127.0.0.1] (rouen.Informatik.Uni-Tuebingen.De [134.2.11.152]) by mx5.informatik.uni-tuebingen.de (Postfix) with ESMTP id 4D474115; Mon, 17 Apr 2006 15:59:46 +0200 (MST) Message-ID: <44439F50.5020007@uni-tuebingen.de> Date: Mon, 17 Apr 2006 15:59:44 +0200 From: Ali Fessi User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Hannes Tschofenig Subject: Re: [NSIS] NATFW NSLP; problem with session ownership References: <615BD9B54CB01B41838C323DB9E91AAB4074D6@esebe100.NOE.Nokia.com> <444390EA.20709@uni-tuebingen.de> <4443966B.6020605@gmx.net> In-Reply-To: <4443966B.6020605@gmx.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new (McAfee AntiVirus) at informatik.uni-tuebingen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Hannes, Hannes Tschofenig wrote: > > A randomly generated SID already prevents attacks by off-path > adversaries. this is not true if attackers can eavesdrop the SID and re-initiate signaling with it (this would be very easy, e.g. in a wireless environment). The fact that NSIS nodes need to establish a security context with their NSIS peer-nodes to secure the signaling, reduces the severity of the problem. But attackers can also be legitimate neighboring hosts. Such as an attack is already described in Section 5.10.1 (Miuse of mobility in NAT handling; BTW: this attacks is actually not specific to NATs; firewalls need also to update their policy rules for mobility support) Protecting the signaling by providing message confidentiality could help to solve the problem. Is this correct? > Adversaries along the path are problematic for various > reasons (e.g., injection of data traffic). I actually don't see a severe problem with nodes along the path, since they will be of a nature of routers and not end hosts. > > Ciao > Hannes > Ali > > > Ali Fessi wrote: > >> Hi all, >> >> a proof of session ownership is the NATFW NSLP is supposed to be >> provided by the session ID. (Section 3.6) >> >> However, SID can not provide any garantee that a request is >> originating from the initial NI; even if it is randomly generated. >> >> SID can be eavesdropped and can be miused for replay attacks and >> cut-and-paste attacks with modified policy rules. >> >> Those attacks are already described, e.g. in Section 5.5 and 5.10; but >> no solution has been provided. >> >> The problem with SID is that it is not cryptographically protected. >> Using it for proof of session ownership would be a mistake in the >> design of the NATFW NSLP similar to the mistake of using CRC for >> message integrity for WEP. >> >> greeting, >> Ali -- Ali Fessi University of Tuebingen, Germany _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Apr 17 10:13:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVUTM-0008Mx-Gp; Mon, 17 Apr 2006 10:13:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVUTL-0008Ms-8p for nsis@ietf.org; Mon, 17 Apr 2006 10:12:59 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FVUTK-0008EU-SM for nsis@ietf.org; Mon, 17 Apr 2006 10:12:59 -0400 Received: (qmail invoked by alias); 17 Apr 2006 14:12:55 -0000 Received: from ip-80-226-140-107.vodafone-net.de (EHLO [10.226.220.130]) [80.226.140.107] by mail.gmx.net (mp008) with SMTP; 17 Apr 2006 16:12:55 +0200 X-Authenticated: #29516787 Message-ID: <4443A25D.3030304@gmx.net> Date: Mon, 17 Apr 2006 16:12:45 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ali Fessi Subject: Re: [NSIS] NATFW NSLP; confidentiality of signaling messages References: <4443971D.8000100@uni-tuebingen.de> In-Reply-To: <4443971D.8000100@uni-tuebingen.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: nsis X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Ali, there is a MUST implement regarding confidentiality protection based on GIST. I would not want to indicate a MUST use here since the NATFW NSLP usage depends on the environment. The same is true for the QoS NSLP. For example, in my home network I use link layer security and I do not see why the NATFW NSLP has to use confidentiality protection in such an environment. I will re-read the text to ensure that the language is used unambiguously (e.g., with regard to the usage of GIST security). Ciao Hannes Ali Fessi wrote: > Hi, > > the draft is currently contradictory on the requirement of message > confidentiality. > > Section: 5.14.1 says: "optionally confidentiality protection" > > While other sections, e.g. Section 5.13, instructs message > confidentiality as a MUST, especially when authorization tokens are > transported. > > Is there a reason for not providing message confidentiality?! From a > cryptographic point of view message confidentiality is cheap, since > security contexts need to be established between neighboring NSIS nodes > anyway. > > Also, it should be clearly stated that NATFW NSLP does not provide > message confidentiality by itself. Rather it relies on underlying > protocols, for providing security services such as confidentiality, > message integrity, data origin authentication, and replay protection. > (In Section 5.14.1 only authentication is mentioned) > > Greetings, > Ali _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Apr 17 10:21:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVUbs-0002Bp-Ve; Mon, 17 Apr 2006 10:21:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVUbr-0002BY-27 for nsis@ietf.org; Mon, 17 Apr 2006 10:21:47 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FVUbq-0000kh-Lj for nsis@ietf.org; Mon, 17 Apr 2006 10:21:47 -0400 Received: (qmail invoked by alias); 17 Apr 2006 14:21:42 -0000 Received: from ip-80-226-140-107.vodafone-net.de (EHLO [10.226.220.130]) [80.226.140.107] by mail.gmx.net (mp008) with SMTP; 17 Apr 2006 16:21:42 +0200 X-Authenticated: #29516787 Message-ID: <4443A46B.6020107@gmx.net> Date: Mon, 17 Apr 2006 16:21:31 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ali Fessi Subject: Re: [NSIS] NATFW NSLP; problem with session ownership References: <615BD9B54CB01B41838C323DB9E91AAB4074D6@esebe100.NOE.Nokia.com> <444390EA.20709@uni-tuebingen.de> <4443966B.6020605@gmx.net> <44439F50.5020007@uni-tuebingen.de> In-Reply-To: <44439F50.5020007@uni-tuebingen.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Ali, Ali Fessi wrote: > Hi Hannes, > > Hannes Tschofenig wrote: > >> >> A randomly generated SID already prevents attacks by off-path >> adversaries. > > > this is not true if attackers can eavesdrop the SID and re-initiate > signaling with it (this would be very easy, e.g. in a wireless > environment). I guess you refer to off-path adversaries on the same shared medium. Right? > > The fact that NSIS nodes need to establish a security context with their > NSIS peer-nodes to secure the signaling, reduces the severity of the > problem. But attackers can also be legitimate neighboring hosts. > > Such as an attack is already described in Section 5.10.1 (Miuse of > mobility in NAT handling; BTW: this attacks is actually not specific to > NATs; firewalls need also to update their policy rules for mobility > support) The attack in Section 5.10.1 can be prevented with ordinary TLS protection between neighboring nodes. > > Protecting the signaling by providing message confidentiality could help > to solve the problem. Is this correct? Yes. The only attack that cannot be addressed here is the following: The adversary sends a signaling message to a firewall that is not the next one along the path. Section 4.10 of RFC 4081 describes it. > >> Adversaries along the path are problematic for various reasons (e.g., >> injection of data traffic). > > > I actually don't see a severe problem with nodes along the path, since > they will be of a nature of routers and not end hosts. True. Ciao Hannes > >> >> Ciao >> Hannes >> > > Ali > >> >> >> Ali Fessi wrote: >> >>> Hi all, >>> >>> a proof of session ownership is the NATFW NSLP is supposed to be >>> provided by the session ID. (Section 3.6) >>> >>> However, SID can not provide any garantee that a request is >>> originating from the initial NI; even if it is randomly generated. >>> >>> SID can be eavesdropped and can be miused for replay attacks and >>> cut-and-paste attacks with modified policy rules. >>> >>> Those attacks are already described, e.g. in Section 5.5 and 5.10; >>> but no solution has been provided. >>> >>> The problem with SID is that it is not cryptographically protected. >>> Using it for proof of session ownership would be a mistake in the >>> design of the NATFW NSLP similar to the mistake of using CRC for >>> message integrity for WEP. >>> >>> greeting, >>> Ali > > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Apr 17 16:12:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVa5B-0006Dy-Va; Mon, 17 Apr 2006 16:12:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVa5A-0006Da-JF for nsis@ietf.org; Mon, 17 Apr 2006 16:12:24 -0400 Received: from mx5.informatik.uni-tuebingen.de ([134.2.12.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVa59-0002fl-4j for nsis@ietf.org; Mon, 17 Apr 2006 16:12:24 -0400 Received: from localhost (loopback [127.0.0.1]) by mx5.informatik.uni-tuebingen.de (Postfix) with ESMTP id AB6C9115 for ; Mon, 17 Apr 2006 22:12:21 +0200 (MST) Received: from mx3.informatik.uni-tuebingen.de ([134.2.12.26]) by localhost (mx5 [134.2.12.32]) (amavisd-new, port 10024) with ESMTP id 36782-02 for ; Mon, 17 Apr 2006 22:12:19 +0200 (DFT) Received: from [127.0.0.1] (rouen.Informatik.Uni-Tuebingen.De [134.2.11.152]) by mx3.informatik.uni-tuebingen.de (Postfix) with ESMTP id C3ED8141 for ; Mon, 17 Apr 2006 22:12:17 +0200 (MST) Message-ID: <4443F69F.9000708@uni-tuebingen.de> Date: Mon, 17 Apr 2006 22:12:15 +0200 From: Ali Fessi User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: nsis Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new (McAfee AntiVirus) at informatik.uni-tuebingen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Subject: [NSIS] NATFW NSLP; using REA mode for blocking data flows X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi all, the REA mode (Reserving External Address) was originally called REA mode because it is used by hosts behind a NAT to reserve a publicly reachable IP address (and port number). Now, the REA mode is also used by hosts behind a firewall to signal to a firewall for blocking data traffic. Although from functionality point of view, it might be fine to use the same name for these two similar functionalities; but from terminology point of view, this is rather confusing to signal for blocking data traffic and call it "REA mode". So, why not use a different name that matches more the functionality, something like "BLOCK mode" for example?! This would make it easier for the readers to understand. Cheers, Ali -- Ali Fessi University of Tuebingen, Germany _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Apr 17 17:24:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVbCt-00022o-O1; Mon, 17 Apr 2006 17:24:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVbCs-00022W-BP for nsis@ietf.org; Mon, 17 Apr 2006 17:24:26 -0400 Received: from mx5.informatik.uni-tuebingen.de ([134.2.12.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVbCp-0006Ln-OS for nsis@ietf.org; Mon, 17 Apr 2006 17:24:26 -0400 Received: from localhost (loopback [127.0.0.1]) by mx5.informatik.uni-tuebingen.de (Postfix) with ESMTP id 23DC9115; Mon, 17 Apr 2006 23:24:21 +0200 (MST) Received: from mx3.informatik.uni-tuebingen.de ([134.2.12.26]) by localhost (mx5 [134.2.12.32]) (amavisd-new, port 10024) with ESMTP id 15400-02; Mon, 17 Apr 2006 23:24:19 +0200 (DFT) Received: from [127.0.0.1] (rouen.Informatik.Uni-Tuebingen.De [134.2.11.152]) by mx3.informatik.uni-tuebingen.de (Postfix) with ESMTP id E0CE8141; Mon, 17 Apr 2006 23:24:17 +0200 (MST) Message-ID: <4444077E.8060309@uni-tuebingen.de> Date: Mon, 17 Apr 2006 23:24:14 +0200 From: Ali Fessi User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Hannes Tschofenig Subject: Re: [NSIS] NATFW NSLP; confidentiality of signaling messages References: <4443971D.8000100@uni-tuebingen.de> <4443A25D.3030304@gmx.net> In-Reply-To: <4443A25D.3030304@gmx.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new (McAfee AntiVirus) at informatik.uni-tuebingen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: nsis X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Hannes, all, as you know, the functionality provided by the NATFW NSLP is pretty complex and very security-sensitive. Therefore, it will not be easy for someone who wants to deploy it to decide whether confidentiality in his network makes sense or not. I wouldn't leave this decision open because this would just introduce more vulnurabilities in the deployment of the NATFW NSLP. Furthermore, message confidentiality for the NATFW NSLP is required for several reasons: - it protects the SID, which is necessary if SID should be used as a proof for session ownership; - it protect authorization tokens if there will be any. Actually , other protocols carrying an authorization tokens for the NATFW NSLP, e.g. application layer protocols, must be also confidentility-protected. Otherwise, we have a problem and authorization tokens would be useless. - it protects the policy rules that need to be installed. The draft currently argues that policy rules do not need to be protected from eavesdropping, since an attacker could also eavesdrop the traffic and find out which policy rules are currently installed. However, I think this argument would be just one more argument for not deploying the NATFW NSLP due to its insecurity Also, if TLS or IPSec is used for providing hop-by-hop authentication between NSIS node, it does not requires an additional effort to provide message confidentiality. And as I mentiond before, from cryptographic point of view, confidentiality is cheap and does not add an addional delay to the signaling process. What do you think? Cheers, Ali -- Ali Fessi University of Tuebingen, Germany Hannes Tschofenig wrote: > Hi Ali, > > there is a MUST implement regarding confidentiality protection based on > GIST. I would not want to indicate a MUST use here since the NATFW NSLP > usage depends on the environment. The same is true for the QoS NSLP. For > example, in my home network I use link layer security and I do not see > why the NATFW NSLP has to use confidentiality protection in such an > environment. > > I will re-read the text to ensure that the language is used > unambiguously (e.g., with regard to the usage of GIST security). > > Ciao > Hannes > > > Ali Fessi wrote: > >> Hi, >> >> the draft is currently contradictory on the requirement of message >> confidentiality. >> >> Section: 5.14.1 says: "optionally confidentiality protection" >> >> While other sections, e.g. Section 5.13, instructs message >> confidentiality as a MUST, especially when authorization tokens are >> transported. >> >> Is there a reason for not providing message confidentiality?! From a >> cryptographic point of view message confidentiality is cheap, since >> security contexts need to be established between neighboring NSIS >> nodes anyway. >> >> Also, it should be clearly stated that NATFW NSLP does not provide >> message confidentiality by itself. Rather it relies on underlying >> protocols, for providing security services such as confidentiality, >> message integrity, data origin authentication, and replay protection. >> (In Section 5.14.1 only authentication is mentioned) >> >> Greetings, >> Ali _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Apr 17 17:35:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVbNr-0005Vr-Nc; Mon, 17 Apr 2006 17:35:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVbNq-0005Vl-2O for nsis@ietf.org; Mon, 17 Apr 2006 17:35:46 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FVbNo-0006t5-LW for nsis@ietf.org; Mon, 17 Apr 2006 17:35:46 -0400 Received: (qmail invoked by alias); 17 Apr 2006 21:35:41 -0000 Received: from ip-80-226-170-244.vodafone-net.de (EHLO [10.227.144.47]) [80.226.170.244] by mail.gmx.net (mp033) with SMTP; 17 Apr 2006 23:35:41 +0200 X-Authenticated: #29516787 Message-ID: <44440A22.2080300@gmx.net> Date: Mon, 17 Apr 2006 23:35:30 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ali Fessi Subject: Re: [NSIS] NATFW NSLP; using REA mode for blocking data flows References: <4443F69F.9000708@uni-tuebingen.de> In-Reply-To: <4443F69F.9000708@uni-tuebingen.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: nsis X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Ali, it is true that there is some history about the REA name. However, we also want to avoid having too many configuration options: REA and BLOCK Now, you just use one message, which is has the name REA, and the DR does not need to know whether he is behind a NAT, a firewall or a combination of both. Ciao Hannes Ali Fessi wrote: > Hi all, > > the REA mode (Reserving External Address) was originally called REA mode > because it is used by hosts behind a NAT to reserve a publicly reachable > IP address (and port number). > > Now, the REA mode is also used by hosts behind a firewall to signal to a > firewall for blocking data traffic. > > Although from functionality point of view, it might be fine to use the > same name for these two similar functionalities; but from terminology > point of view, this is rather confusing to signal for blocking data > traffic and call it "REA mode". > > So, why not use a different name that matches more the functionality, > something like "BLOCK mode" for example?! This would make it easier for > the readers to understand. > > Cheers, > Ali _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Apr 17 17:49:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVbbF-0003Qc-1f; Mon, 17 Apr 2006 17:49:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVbbD-0003QX-Sm for nsis@ietf.org; Mon, 17 Apr 2006 17:49:35 -0400 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FVbbD-0007Xc-G4 for nsis@ietf.org; Mon, 17 Apr 2006 17:49:35 -0400 Received: (qmail invoked by alias); 17 Apr 2006 21:49:31 -0000 Received: from ip-80-226-188-44.vodafone-net.de (EHLO [10.227.144.47]) [80.226.188.44] by mail.gmx.net (mp032) with SMTP; 17 Apr 2006 23:49:31 +0200 X-Authenticated: #29516787 Message-ID: <44440D60.9080409@gmx.net> Date: Mon, 17 Apr 2006 23:49:20 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ali Fessi Subject: Re: [NSIS] NATFW NSLP; confidentiality of signaling messages References: <4443971D.8000100@uni-tuebingen.de> <4443A25D.3030304@gmx.net> <4444077E.8060309@uni-tuebingen.de> In-Reply-To: <4444077E.8060309@uni-tuebingen.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: nsis X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Ali, Ali Fessi wrote: > Hi Hannes, all, > > as you know, the functionality provided by the NATFW NSLP is pretty > complex and very security-sensitive. Where do you see the complexity in the protocol? > > Therefore, it will not be easy for someone who wants to deploy it to > decide whether confidentiality in his network makes sense or not. I > wouldn't leave this decision open because this would just introduce more > vulnurabilities in the deployment of the NATFW NSLP. Mandating a particular deployment model would, in my view, make it even harder to get things deployed. > > Furthermore, message confidentiality for the NATFW NSLP is required for > several reasons: > > - it protects the SID, which is necessary if SID should be used as a > proof for session ownership; I need to take a look again at the GIST draft but some time back I got the impression that the discovery exchange messages also carry the SID. As such, the SID would not be protected. I need to check it again. > > - it protect authorization tokens if there will be any. Actually , other > protocols carrying an authorization tokens for the NATFW NSLP, e.g. > application layer protocols, must be also confidentility-protected. Actually they don't. RSVP carries authorization tokens and RSVP signaling messages are not confidentiality protected. > Otherwise, we have a problem and authorization tokens would be useless. That's not true. It depends on the deployment environment. > > - it protects the policy rules that need to be installed. They do not need a protection since the data traffic will reveal these rules anyway. The draft > currently argues that policy rules do not need to be protected from > eavesdropping, since an attacker could also eavesdrop the traffic and > find out which policy rules are currently installed. However, I think > this argument would be just one more argument for not deploying the > NATFW NSLP due to its insecurity I am not sure I can follow your line of argument here. The NATFW NSLP is not IKEv2 and IPsec. > > Also, if TLS or IPSec is used for providing hop-by-hop authentication > between NSIS node, it does not requires an additional effort to provide > message confidentiality. > And as I mentiond before, from cryptographic > point of view, confidentiality is cheap and does not add an addional > delay to the signaling process. That's true. IF you use hop-by-hop authentication then you might just want to enable confidentiality protection. Still, I do not want to make deployment restrictions: If the 3GPP2 want to use the NATFW NSLP based on a specific set of ciphersuites then I am fine with it because they have their security folks that know the environment better than we do. Ciao Hannes > > What do you think? > > Cheers, > Ali _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Apr 17 18:32:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVcGU-0007Ld-ST; Mon, 17 Apr 2006 18:32:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVcGT-0007LO-63 for nsis@ietf.org; Mon, 17 Apr 2006 18:32:13 -0400 Received: from mx5.informatik.uni-tuebingen.de ([134.2.12.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVcGS-00016a-G5 for nsis@ietf.org; Mon, 17 Apr 2006 18:32:13 -0400 Received: from localhost (loopback [127.0.0.1]) by mx5.informatik.uni-tuebingen.de (Postfix) with ESMTP id BC828115; Tue, 18 Apr 2006 00:32:10 +0200 (MST) Received: from mx3.informatik.uni-tuebingen.de ([134.2.12.26]) by localhost (mx5 [134.2.12.32]) (amavisd-new, port 10024) with ESMTP id 36782-05; Tue, 18 Apr 2006 00:32:08 +0200 (DFT) Received: from [127.0.0.1] (rouen.Informatik.Uni-Tuebingen.De [134.2.11.152]) by mx3.informatik.uni-tuebingen.de (Postfix) with ESMTP id 10A8B141; Tue, 18 Apr 2006 00:32:05 +0200 (MST) Message-ID: <44441763.8040908@uni-tuebingen.de> Date: Tue, 18 Apr 2006 00:32:03 +0200 From: Ali Fessi User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Hannes Tschofenig Subject: Re: [NSIS] NATFW NSLP; confidentiality of signaling messages References: <4443971D.8000100@uni-tuebingen.de> <4443A25D.3030304@gmx.net> <4444077E.8060309@uni-tuebingen.de> <44440D60.9080409@gmx.net> In-Reply-To: <44440D60.9080409@gmx.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new (McAfee AntiVirus) at informatik.uni-tuebingen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c Cc: nsis X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Hannes, Hannes Tschofenig wrote: > Hi Ali, > > Ali Fessi wrote: > >> Hi Hannes, all, >> >> as you know, the functionality provided by the NATFW NSLP is pretty >> complex and very security-sensitive. > > > Where do you see the complexity in the protocol? The NATFW NSLP involves many entities in the signaling process which makes a security analysis difficult. One of the main problems is that due to the NAT handling, message integrity can not be provided end-to-end or end-to-middle. If the protocol would, for example, deal only with firewalls, it would be much easier. > >> >> Therefore, it will not be easy for someone who wants to deploy it to >> decide whether confidentiality in his network makes sense or not. I >> wouldn't leave this decision open because this would just introduce >> more vulnurabilities in the deployment of the NATFW NSLP. > > > Mandating a particular deployment model would, in my view, make it even > harder to get things deployed. > >> >> Furthermore, message confidentiality for the NATFW NSLP is required >> for several reasons: >> >> - it protects the SID, which is necessary if SID should be used as a >> proof for session ownership; > > > I need to take a look again at the GIST draft but some time back I got > the impression that the discovery exchange messages also carry the SID. > As such, the SID would not be protected. I need to check it again. That would be even one more reason for NOT using the SID for the proof of session ownership! >> >> - it protect authorization tokens if there will be any. Actually , >> other protocols carrying an authorization tokens for the NATFW NSLP, >> e.g. application layer protocols, must be also confidentility-protected. > > Actually they don't. > RSVP carries authorization tokens and RSVP signaling messages are not > confidentiality protected. do you know whether RSVP authorization tokens are used in some environments?! If the NATFW NSLP should be used in an Internet environment, then authorization tokens must be protected against eavesdropping. > >> Otherwise, we have a problem and authorization tokens would be useless. > > That's not true. It depends on the deployment environment. agreed. > >> >> - it protects the policy rules that need to be installed. > > They do not need a protection since the data traffic will reveal these > rules anyway. > > > The draft > >> currently argues that policy rules do not need to be protected from >> eavesdropping, since an attacker could also eavesdrop the traffic and >> find out which policy rules are currently installed. However, I think >> this argument would be just one more argument for not deploying the >> NATFW NSLP due to its insecurity > > > I am not sure I can follow your line of argument here. > > The NATFW NSLP is not IKEv2 and IPsec. I'm not talking about IKEv2 neither about IPSec. > >> >> Also, if TLS or IPSec is used for providing hop-by-hop authentication >> between NSIS node, it does not requires an additional effort to >> provide message confidentiality. >> And as I mentiond before, from cryptographic point of view, >> confidentiality is cheap and does not add an addional delay to the >> signaling process. > > > > That's true. IF you use hop-by-hop authentication then you might just > want to enable confidentiality protection. > > Still, I do not want to make deployment restrictions: If the 3GPP2 want > to use the NATFW NSLP based on a specific set of ciphersuites then I am > fine with it because they have their security folks that know the > environment better than we do. Ok, I understand your point. But I think it should be clearly stated in the draft, which vulnerabilities do exist if the NATFW NSLP is used without message confidentiality and that it is highly recommended to provide message confidentiality either by using IPSec/TLS or a link layer specific mechanism (I guess the latter case will apply in 3GPP2 environments). Is that fine with you? Cheers, Ali. > > Ciao > Hannes > >> >> What do you think? >> >> Cheers, >> Ali -- Ali Fessi University of Tuebingen, Germany _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Apr 18 06:21:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVnKQ-00039d-H2; Tue, 18 Apr 2006 06:21:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVnKP-00039Y-PU for nsis@ietf.org; Tue, 18 Apr 2006 06:21:01 -0400 Received: from rsys002x.roke.co.uk ([193.118.201.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVnKP-0004eA-2c for nsis@ietf.org; Tue, 18 Apr 2006 06:21:01 -0400 Received: from rsys005a.comm.ad.roke.co.uk (rsys005a [193.118.193.85]) by rsys002x.roke.co.uk (8.13.1/8.13.1) with ESMTP id k3IAKmkB003746; Tue, 18 Apr 2006 11:20:54 +0100 Received: from ac78840 ([193.118.192.66]) by rsys005a.comm.ad.roke.co.uk with Microsoft SMTPSVC(6.0.3790.211); Tue, 18 Apr 2006 11:20:52 +0100 From: "Robert Hancock" To: "'Ali Fessi'" , "'Hannes Tschofenig'" Subject: RE: [NSIS] NATFW NSLP; confidentiality of signaling messages Date: Tue, 18 Apr 2006 11:20:52 +0100 Message-ID: <000001c662d1$c57f77b0$6500000a@comm.ad.roke.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Importance: Normal In-Reply-To: <44441763.8040908@uni-tuebingen.de> X-OriginalArrivalTime: 18 Apr 2006 10:20:52.0857 (UTC) FILETIME=[C58B5E90:01C662D1] X-MailScanner-roke.co.uk: Found to be clean X-MailScanner-roke.co.uk-SpamCheck: X-MailScanner-From: robert.hancock@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: e367d58950869b6582535ddf5a673488 Cc: 'nsis' X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org hi all, some cents: *) GIST carries the SID in routing state setup messages (including the Query). This is at least partly because the routing state maintained at the GIST level is SID- dependent (for security reasons which are discussed in the spec). It might theoretically be possible to remove the SID from the initial messages but it would require quite a bit of careful thought, and would also require quite a bit of surgery to the message processing rules. The principle we adopted at an early stage was that confidentiality of the SID was not a goal. *) GIST doesn't say anything about how SIDs should be allocated. There are asymmetric cryptography techniques that could use the SID in a particular way which was more secure. That might be an option for future development of the NATFW protocol. *) I think (with Hannes) that it would be a very bad idea to mandate the use of confidentiality. (Implementation is already mandated, since it's an mandatory-to-implement function within GIST.) Mandating the use would have one of two effects: - people who took the requirement seriously would quite possibly decide never to use the protocol at all, even in environments where it was legitimate, because of the burden of credential & key management; - people who did not take the requirement seriously would simply ignore it. (How many times have you heard from the v6 marketing community that it has 'security built in'? and what effect does it have in practice?) *) I think the right way to address these concerns is to write a thorough security considerations section which explains (in particular) the consequences of not using GIST-level confidentiality, both for yourself and for other nodes along the path. r. > -----Original Message----- > From: Ali Fessi [mailto:ali.fessi@uni-tuebingen.de] > Sent: 17 April 2006 23:32 > To: Hannes Tschofenig > Cc: nsis > Subject: Re: [NSIS] NATFW NSLP; confidentiality of signaling messages > > > Hi Hannes, > > Hannes Tschofenig wrote: > > Hi Ali, > > > > Ali Fessi wrote: > > > >> Hi Hannes, all, > >> > >> as you know, the functionality provided by the NATFW NSLP > is pretty > >> complex and very security-sensitive. > > > > > > Where do you see the complexity in the protocol? > > The NATFW NSLP involves many entities in the signaling process which > makes a security analysis difficult. > > One of the main problems is that due to the NAT handling, message > integrity can not be provided end-to-end or end-to-middle. > > If the protocol would, for example, deal only with firewalls, > it would > be much easier. > > > > >> > >> Therefore, it will not be easy for someone who wants to > deploy it to > >> decide whether confidentiality in his network makes sense > or not. I > >> wouldn't leave this decision open because this would just > introduce > >> more vulnurabilities in the deployment of the NATFW NSLP. > > > > > > Mandating a particular deployment model would, in my view, > make it even > > harder to get things deployed. > > > >> > >> Furthermore, message confidentiality for the NATFW NSLP is > required > >> for several reasons: > >> > >> - it protects the SID, which is necessary if SID should be > used as a > >> proof for session ownership; > > > > > > I need to take a look again at the GIST draft but some time > back I got > > the impression that the discovery exchange messages also > carry the SID. > > As such, the SID would not be protected. I need to check it again. > > > That would be even one more reason for NOT using the SID for > the proof > of session ownership! > > > >> > >> - it protect authorization tokens if there will be any. Actually , > >> other protocols carrying an authorization tokens for the > NATFW NSLP, > >> e.g. application layer protocols, must be also > confidentility-protected. > > > > Actually they don't. > > RSVP carries authorization tokens and RSVP signaling > messages are not > > confidentiality protected. > > do you know whether RSVP authorization tokens are used in some > environments?! If the NATFW NSLP should be used in an Internet > environment, then authorization tokens must be protected against > eavesdropping. > > > > >> Otherwise, we have a problem and authorization tokens > would be useless. > > > > That's not true. It depends on the deployment environment. > > agreed. > > > > >> > >> - it protects the policy rules that need to be installed. > > > > They do not need a protection since the data traffic will > reveal these > > rules anyway. > > > > > > The draft > > > >> currently argues that policy rules do not need to be > protected from > >> eavesdropping, since an attacker could also eavesdrop the > traffic and > >> find out which policy rules are currently installed. > However, I think > >> this argument would be just one more argument for not > deploying the > >> NATFW NSLP due to its insecurity > > > > > > I am not sure I can follow your line of argument here. > > > > The NATFW NSLP is not IKEv2 and IPsec. > > I'm not talking about IKEv2 neither about IPSec. > > > >> > >> Also, if TLS or IPSec is used for providing hop-by-hop > authentication > >> between NSIS node, it does not requires an additional effort to > >> provide message confidentiality. > >> And as I mentiond before, from cryptographic point of view, > >> confidentiality is cheap and does not add an addional delay to the > >> signaling process. > > > > > > > > That's true. IF you use hop-by-hop authentication then you > might just > > want to enable confidentiality protection. > > > > Still, I do not want to make deployment restrictions: If > the 3GPP2 want > > to use the NATFW NSLP based on a specific set of > ciphersuites then I am > > fine with it because they have their security folks that know the > > environment better than we do. > > Ok, I understand your point. But I think it should be clearly > stated in > the draft, which vulnerabilities do exist if the NATFW NSLP is used > without message confidentiality and that it is highly recommended to > provide message confidentiality either by using IPSec/TLS or a link > layer specific mechanism (I guess the latter case will apply in 3GPP2 > environments). > > Is that fine with you? > > Cheers, > Ali. > > > > > Ciao > > Hannes > > > >> > >> What do you think? > >> > >> Cheers, > >> Ali > > > -- > Ali Fessi > University of Tuebingen, Germany > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Apr 18 07:37:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVoWK-0004oO-4n; Tue, 18 Apr 2006 07:37:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVoWJ-0004oJ-2g for nsis@ietf.org; Tue, 18 Apr 2006 07:37:23 -0400 Received: from mgw-ext14.nokia.com ([131.228.20.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVoWH-0000gb-Kr for nsis@ietf.org; Tue, 18 Apr 2006 07:37:23 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext14.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k3IBZil9014303; Tue, 18 Apr 2006 14:35:45 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 18 Apr 2006 14:37:19 +0300 Received: from esebe100.NOE.Nokia.com ([172.21.138.118]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 18 Apr 2006 14:37:19 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] NATFW NSLP; confidentiality of signaling messages Date: Tue, 18 Apr 2006 14:37:17 +0300 Message-ID: <615BD9B54CB01B41838C323DB9E91AAB40750D@esebe100.NOE.Nokia.com> In-Reply-To: <000001c662d1$c57f77b0$6500000a@comm.ad.roke.co.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] NATFW NSLP; confidentiality of signaling messages Thread-Index: AcZi0e07Iq7xq1kBTea0MQnW9T8nUQACcmrA From: To: , , X-OriginalArrivalTime: 18 Apr 2006 11:37:19.0154 (UTC) FILETIME=[7330C120:01C662DC] X-Spam-Score: 0.2 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Robert, >some cents: > >*) GIST carries the SID in routing state setup messages=20 >(including the Query). This is at least partly because the=20 >routing state maintained at the GIST level is SID- dependent=20 >(for security reasons which are discussed in the spec). It=20 >might theoretically be possible to remove the SID from the=20 >initial messages but it would require quite a bit of careful=20 >thought, and would also require quite a bit of surgery to the=20 >message processing rules. >The principle we adopted at an early stage was that=20 >confidentiality of the SID was not a goal. > >*) GIST doesn't say anything about how SIDs should be=20 >allocated. There are asymmetric cryptography techniques that=20 >could use the SID in a particular way which was more secure.=20 >That might be an option for future development of the NATFW protocol. > >*) I think (with Hannes) that it would be a very bad idea to=20 >mandate the use of confidentiality. (Implementation is already=20 >mandated, since it's an mandatory-to-implement function within=20 >GIST.) Mandating the use would have one of two effects: >- people who took the requirement seriously would quite=20 >possibly decide never to use the protocol at all, even in=20 >environments where it was legitimate, because of the burden of=20 >credential & key management; >- people who did not take the requirement seriously would=20 >simply ignore it. (How many times have you heard from the v6=20 >marketing community that it has 'security built in'? >and what effect does it have in practice?) > >*) I think the right way to address these concerns is to write=20 >a thorough security considerations section which explains (in=20 >particular) the consequences of not using GIST-level=20 >confidentiality, both for yourself and for other nodes along the path. Thanks for the summary. I think that these are reasonable points. Of course, we also have to remember that NATs themselves are a security threat, and non-trusted firewalls can also be problematic. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Apr 18 07:39:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVoYG-0005Ly-07; Tue, 18 Apr 2006 07:39:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVoYE-0005Lt-Tr for nsis@ietf.org; Tue, 18 Apr 2006 07:39:22 -0400 Received: from mx5.informatik.uni-tuebingen.de ([134.2.12.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVoYD-0000pA-Gg for nsis@ietf.org; Tue, 18 Apr 2006 07:39:22 -0400 Received: from localhost (loopback [127.0.0.1]) by mx5.informatik.uni-tuebingen.de (Postfix) with ESMTP id E63BA11C; Tue, 18 Apr 2006 13:39:19 +0200 (MST) Received: from mx5.informatik.uni-tuebingen.de ([127.0.0.1]) by localhost (mx5 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24306-02; Tue, 18 Apr 2006 13:39:17 +0200 (DFT) Received: from [127.0.0.1] (rouen.Informatik.Uni-Tuebingen.De [134.2.11.152]) by mx5.informatik.uni-tuebingen.de (Postfix) with ESMTP id EA92D11B; Tue, 18 Apr 2006 13:39:16 +0200 (MST) Message-ID: <4444CFE3.9060304@uni-tuebingen.de> Date: Tue, 18 Apr 2006 13:39:15 +0200 From: Ali Fessi User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Hancock Subject: Re: [NSIS] NATFW NSLP; confidentiality of signaling messages References: <000001c662d1$c57f77b0$6500000a@comm.ad.roke.co.uk> In-Reply-To: <000001c662d1$c57f77b0$6500000a@comm.ad.roke.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new (McAfee AntiVirus) at informatik.uni-tuebingen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: 'nsis' X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Robert, Robert Hancock wrote: > *) I think the right way to address these concerns is to > write a thorough security considerations section which > explains (in particular) the consequences of not using > GIST-level confidentiality, both for yourself and for > other nodes along the path. > > r. sounds like a good approach. agreed! Cheers, Ali _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Apr 18 11:47:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVsQJ-0006NK-CJ; Tue, 18 Apr 2006 11:47:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVsQH-0006NF-IW for nsis@ietf.org; Tue, 18 Apr 2006 11:47:25 -0400 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FVsQH-00065a-3N for nsis@ietf.org; Tue, 18 Apr 2006 11:47:25 -0400 Received: (qmail invoked by alias); 18 Apr 2006 15:47:23 -0000 Received: from p54984B8E.dip.t-dialin.net (EHLO [192.168.2.33]) [84.152.75.142] by mail.gmx.net (mp006) with SMTP; 18 Apr 2006 17:47:23 +0200 X-Authenticated: #29516787 Message-ID: <44450A08.10605@gmx.net> Date: Tue, 18 Apr 2006 17:47:20 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ali Fessi Subject: Re: [NSIS] NATFW NSLP; confidentiality of signaling messages References: <4443971D.8000100@uni-tuebingen.de> <4443A25D.3030304@gmx.net> <4444077E.8060309@uni-tuebingen.de> <44440D60.9080409@gmx.net> <44441763.8040908@uni-tuebingen.de> In-Reply-To: <44441763.8040908@uni-tuebingen.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.1 (/) X-Scan-Signature: ec7c6dab5a62df223002ae71b5179d41 Cc: nsis X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Ali, Ali Fessi wrote: > Hi Hannes, > > Hannes Tschofenig wrote: > >> Hi Ali, >> >> Ali Fessi wrote: >> >>> Hi Hannes, all, >>> >>> as you know, the functionality provided by the NATFW NSLP is pretty >>> complex and very security-sensitive. >> >> >> >> Where do you see the complexity in the protocol? > > > The NATFW NSLP involves many entities in the signaling process which > makes a security analysis difficult. > > One of the main problems is that due to the NAT handling, message > integrity can not be provided end-to-end or end-to-middle. > > If the protocol would, for example, deal only with firewalls, it would > be much easier. It is true that there are protocols with a simpler security analysis. However, I am convinced that the protocol is actually quite simple: CREATE message exchange and a REA message exchange. Since we want to deal with migration scenarios (and we can do that) we provide the ability to stop signaling earlier. The refresh handling is also pretty simple: E2E with the ability to allow intermediate nodes to send a NOTIFY message. > >> >>> >>> Therefore, it will not be easy for someone who wants to deploy it to >>> decide whether confidentiality in his network makes sense or not. I >>> wouldn't leave this decision open because this would just introduce >>> more vulnurabilities in the deployment of the NATFW NSLP. >> >> >> >> Mandating a particular deployment model would, in my view, make it >> even harder to get things deployed. >> >>> >>> Furthermore, message confidentiality for the NATFW NSLP is required >>> for several reasons: >>> >>> - it protects the SID, which is necessary if SID should be used as a >>> proof for session ownership; >> >> >> >> I need to take a look again at the GIST draft but some time back I got >> the impression that the discovery exchange messages also carry the >> SID. As such, the SID would not be protected. I need to check it again. > > > > That would be even one more reason for NOT using the SID for the proof > of session ownership! The session ownership section in the NATFW NSLP draft might be a bit misleading since it was written at the time when the session ownership was provided using the cryptographically generated identities. It was modified later but maybe we need to put additional text in there to highlight the provided properties much better. > > >>> >>> - it protect authorization tokens if there will be any. Actually , >>> other protocols carrying an authorization tokens for the NATFW NSLP, >>> e.g. application layer protocols, must be also confidentility-protected. >> >> >> Actually they don't. >> RSVP carries authorization tokens and RSVP signaling messages are not >> confidentiality protected. > > > do you know whether RSVP authorization tokens are used in some > environments?! If the NATFW NSLP should be used in an Internet > environment, then authorization tokens must be protected against > eavesdropping. The 3GPP used the authorization token idea for QoS signaling. However, they do not mandate RSVP usage but use GTP tunnels instead although the usage of RSVP is described in one of their documents. Note that this use cases covers QoS signaling and not NATFW signaling. (I can lookup the detailed references, if you want.) > >> >>> Otherwise, we have a problem and authorization tokens would be useless. >> >> >> That's not true. It depends on the deployment environment. > > > agreed. > >> >>> >>> - it protects the policy rules that need to be installed. >> >> >> They do not need a protection since the data traffic will reveal these >> rules anyway. >> >> >> The draft >> >>> currently argues that policy rules do not need to be protected from >>> eavesdropping, since an attacker could also eavesdrop the traffic and >>> find out which policy rules are currently installed. However, I think >>> this argument would be just one more argument for not deploying the >>> NATFW NSLP due to its insecurity >> >> >> >> I am not sure I can follow your line of argument here. >> >> The NATFW NSLP is not IKEv2 and IPsec. > > > I'm not talking about IKEv2 neither about IPSec. > >> >>> >>> Also, if TLS or IPSec is used for providing hop-by-hop authentication >>> between NSIS node, it does not requires an additional effort to >>> provide message confidentiality. >>> And as I mentiond before, from cryptographic point of view, >>> confidentiality is cheap and does not add an addional delay to the >>> signaling process. >> >> >> >> >> That's true. IF you use hop-by-hop authentication then you might just >> want to enable confidentiality protection. >> >> Still, I do not want to make deployment restrictions: If the 3GPP2 >> want to use the NATFW NSLP based on a specific set of ciphersuites >> then I am fine with it because they have their security folks that >> know the environment better than we do. > > > Ok, I understand your point. But I think it should be clearly stated in > the draft, which vulnerabilities do exist if the NATFW NSLP is used > without message confidentiality and that it is highly recommended to > provide message confidentiality either by using IPSec/TLS or a link > layer specific mechanism (I guess the latter case will apply in 3GPP2 > environments). > > Is that fine with you? Sounds good to me. I will go through the text to see where additional wording would be a reasonable thing todo. Please let me know if you have some suggestions for specific paragraphs as well. Ciao Hannes > > Cheers, > Ali. > >> >> Ciao >> Hannes >> >>> >>> What do you think? >>> >>> Cheers, >>> Ali > > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Apr 20 18:11:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWhNF-0004J1-WF; Thu, 20 Apr 2006 18:11:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWhNF-0004Iv-HY for nsis@ietf.org; Thu, 20 Apr 2006 18:11:41 -0400 Received: from mx5.informatik.uni-tuebingen.de ([134.2.12.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWhND-00018P-V8 for nsis@ietf.org; Thu, 20 Apr 2006 18:11:41 -0400 Received: from localhost (loopback [127.0.0.1]) by mx5.informatik.uni-tuebingen.de (Postfix) with ESMTP id 7D6BD11C for ; Fri, 21 Apr 2006 00:11:38 +0200 (MST) Received: from mx5.informatik.uni-tuebingen.de ([127.0.0.1]) by localhost (mx5 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 36738-02 for ; Fri, 21 Apr 2006 00:11:35 +0200 (DFT) Received: from [127.0.0.1] (rouen.Informatik.Uni-Tuebingen.De [134.2.11.152]) by mx5.informatik.uni-tuebingen.de (Postfix) with ESMTP id 98AEC11B for ; Fri, 21 Apr 2006 00:11:34 +0200 (MST) Message-ID: <44480714.2000907@uni-tuebingen.de> Date: Fri, 21 Apr 2006 00:11:32 +0200 From: Ali Fessi User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: nsis X-Virus-Scanned: by amavisd-new (McAfee AntiVirus) at informatik.uni-tuebingen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Subject: [NSIS] NATFW NSLP; No solution provided for attack described in section 5.5.3 X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0034671412==" Errors-To: nsis-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============0034671412== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020706060308080109020607" This is a cryptographically signed message in MIME format. --------------ms020706060308080109020607 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear NATFW NSLP authors, there is currently no security requirement derived from the threat described in Section 5.5.3 (Data Receiver (DR) behind a firewall); although it is a very realistic attack! However, looking at the whole document, a solution for resolving this attack can be actually provided: - either by relying on an authorization framework (authorization tokens, SAML, etc.) - or by relying upon GIST or underlying protocols, for providing hop-by-hop authentication; So the derived security requirements could be updated accordingly (i could provide a suggestions for some text, if you want) Also: the attack described in section 5.5.4 is actually the same except the middlebox function is a NAT instead of firewall; but this doesn't make a difference. Regards, Ali -- Ali Fessi University of Tuebingen, Germany --------------ms020706060308080109020607 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJSTCC Av8wggJooAMCAQICECvZHKWODjLVSWiWg0FHOegwDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MDIwNzIxMzIyOFoX DTA3MDIwNzIxMzIyOFowXTEOMAwGA1UEBBMFRmVzc2kxDDAKBgNVBCoTA0FsaTESMBAGA1UE AxMJQWxpIEZlc3NpMSkwJwYJKoZIhvcNAQkBFhphbGkuZmVzc2lAdW5pLXR1ZWJpbmdlbi5k ZTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMFdryM1RfD1kn8ZQnO7w7HQwt/f n6OQIib5MSNtWEI5kz2CTCxxhLtv3LqkskAv4Mmpw1ZNOoahVOul/TbawnMGBicUfmbUfeX5 /j/qIO+j7BRwuJBEfBNQoW3OyO9WIU7bLzWfmSV5W+9UE7AeTHXEbIExPtZb3CQAYhF9Im4F xVaepDshnJvjippJTfgH8vwIOqpYEk3WGYDW5pxruaWVhy9Q+8c9TfmES1qjemOjeEXliQ+n j8ns6PAJwIXuahvH7QY2AJDnP4WW0vvrhSHApzZVRX+rriGNnvkYao9UhRoQaePDLtQfl3D3 fT0CdRkJ4+ateXT0D8FEdL5P02cCAwEAAaM3MDUwJQYDVR0RBB4wHIEaYWxpLmZlc3NpQHVu aS10dWViaW5nZW4uZGUwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQA/nk208AFH IEcT8G8OT/olmcQMCHvgIsIrTGbPvlac/5ieANG7L1UjEBKv+THkcLTAH20Ca4XyplGiU2L2 8BSWNdtHNqOS8yA1Y8w1uxitcbYappbqtMeALITQTFyRQM70dzTatBB0JYVL6DE1KGs2g995 aLEax/S57zdx8axdHzCCAv8wggJooAMCAQICECvZHKWODjLVSWiWg0FHOegwDQYJKoZIhvcN AQEEBQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkp IEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4X DTA2MDIwNzIxMzIyOFoXDTA3MDIwNzIxMzIyOFowXTEOMAwGA1UEBBMFRmVzc2kxDDAKBgNV BCoTA0FsaTESMBAGA1UEAxMJQWxpIEZlc3NpMSkwJwYJKoZIhvcNAQkBFhphbGkuZmVzc2lA dW5pLXR1ZWJpbmdlbi5kZTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMFdryM1 RfD1kn8ZQnO7w7HQwt/fn6OQIib5MSNtWEI5kz2CTCxxhLtv3LqkskAv4Mmpw1ZNOoahVOul /TbawnMGBicUfmbUfeX5/j/qIO+j7BRwuJBEfBNQoW3OyO9WIU7bLzWfmSV5W+9UE7AeTHXE bIExPtZb3CQAYhF9Im4FxVaepDshnJvjippJTfgH8vwIOqpYEk3WGYDW5pxruaWVhy9Q+8c9 TfmES1qjemOjeEXliQ+nj8ns6PAJwIXuahvH7QY2AJDnP4WW0vvrhSHApzZVRX+rriGNnvkY ao9UhRoQaePDLtQfl3D3fT0CdRkJ4+ateXT0D8FEdL5P02cCAwEAAaM3MDUwJQYDVR0RBB4w HIEaYWxpLmZlc3NpQHVuaS10dWViaW5nZW4uZGUwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0B AQQFAAOBgQA/nk208AFHIEcT8G8OT/olmcQMCHvgIsIrTGbPvlac/5ieANG7L1UjEBKv+THk cLTAH20Ca4XyplGiU2L28BSWNdtHNqOS8yA1Y8w1uxitcbYappbqtMeALITQTFyRQM70dzTa tBB0JYVL6DE1KGs2g995aLEax/S57zdx8axdHzCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcN AQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcT CUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRp ZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBG cmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNv bTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYD VQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVy c29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA xKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkV cI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUq VIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMG A1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZy ZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJp dmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIX oUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydx VyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggNkMIIDYAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGlu ZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWlu ZyBDQQIQK9kcpY4OMtVJaJaDQUc56DAJBgUrDgMCGgUAoIIBwzAYBgkqhkiG9w0BCQMxCwYJ KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNjA0MjAyMjExMzJaMCMGCSqGSIb3DQEJBDEW BBS6CkpcRf1gq9a/uJ7ZhGfdRbkFUjBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4G CCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB hQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1 bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElz c3VpbmcgQ0ECECvZHKWODjLVSWiWg0FHOegwgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYD VQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECECvZHKWODjLVSWiWg0FH OegwDQYJKoZIhvcNAQEBBQAEggEAuf86GkM1XZo6z9KmVZQs0DMSimXTGnv3rEkEUDsstLAy 6zd7kHY50Q4XNcgrBhtv+D8M2Oqqz3NY5J304QYvDXA703FmsnKywQNeIZk5nikejjxUafG6 Ju96JH5Di/CnXpV/uBBMeHZnpH+5pHaMnr8/+XB7KWPuAAdw/s2e4Z1tsZ+kR3v1by++WOIM uIvzACpHWBnCRFTRIWNtemw41OTy3TFh2CuJ5GrTDnA27DsXwY00q1UR/B5dpzuL7+lM9sXb F/9kHDuqpn8WDhxzJWIvMO+RN6fm4v9dCEPR+2YatC/Udm+xUcD52vGLryVZTsbo/5DOOvlj M/DGyWJn1wAAAAAAAA== --------------ms020706060308080109020607-- --===============0034671412== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis --===============0034671412==-- From nsis-bounces@ietf.org Thu Apr 20 18:12:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWhNo-0004O5-Ac; Thu, 20 Apr 2006 18:12:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWhNn-0004Nx-Jl for nsis@ietf.org; Thu, 20 Apr 2006 18:12:15 -0400 Received: from mx5.informatik.uni-tuebingen.de ([134.2.12.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWhNm-00019A-2b for nsis@ietf.org; Thu, 20 Apr 2006 18:12:15 -0400 Received: from localhost (loopback [127.0.0.1]) by mx5.informatik.uni-tuebingen.de (Postfix) with ESMTP id 8FD9711B for ; Fri, 21 Apr 2006 00:12:13 +0200 (MST) Received: from mx3.informatik.uni-tuebingen.de ([134.2.12.26]) by localhost (mx5 [134.2.12.32]) (amavisd-new, port 10024) with ESMTP id 24234-02 for ; Fri, 21 Apr 2006 00:12:11 +0200 (DFT) Received: from [127.0.0.1] (rouen.Informatik.Uni-Tuebingen.De [134.2.11.152]) by mx3.informatik.uni-tuebingen.de (Postfix) with ESMTP id 0FFD5145 for ; Fri, 21 Apr 2006 00:12:09 +0200 (MST) Message-ID: <44480737.4000202@uni-tuebingen.de> Date: Fri, 21 Apr 2006 00:12:07 +0200 From: Ali Fessi User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: nsis Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new (McAfee AntiVirus) at informatik.uni-tuebingen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Subject: [NSIS] NATFW NSLP; attack in Section 5.10.1 is not specific to NATs X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi, the attack described in Section 5.10.1 (Misuse of mobility in NAT handling) is actually not specific to NATs. Firewalls need also to update their policy rules to support mobility. I would modify the description of the attack accordingly and call it "Miuse of Mobility Support" or something like this. Also: in the figure 42, the end host does not necessarly need to be on the private side of the network. a Mobile Node can be on both sides of the network; and in both cases, policy rules need to be updated. So there shouldn't be a difference between the public and the private network sides. Regards, Ali -- Ali Fessi University of Tuebingen, Germany _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Apr 20 18:19:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWhUu-0006ZZ-8t; Thu, 20 Apr 2006 18:19:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWhUt-0006ZU-1L for nsis@ietf.org; Thu, 20 Apr 2006 18:19:35 -0400 Received: from mx5.informatik.uni-tuebingen.de ([134.2.12.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWhUr-0001QS-OS for nsis@ietf.org; Thu, 20 Apr 2006 18:19:35 -0400 Received: from localhost (loopback [127.0.0.1]) by mx5.informatik.uni-tuebingen.de (Postfix) with ESMTP id B0A9D11B for ; Fri, 21 Apr 2006 00:19:32 +0200 (MST) Received: from mx3.informatik.uni-tuebingen.de ([134.2.12.26]) by localhost (mx5 [134.2.12.32]) (amavisd-new, port 10024) with ESMTP id 24234-03 for ; Fri, 21 Apr 2006 00:19:30 +0200 (DFT) Received: from [127.0.0.1] (rouen.Informatik.Uni-Tuebingen.De [134.2.11.152]) by mx3.informatik.uni-tuebingen.de (Postfix) with ESMTP id 83CA2145 for ; Fri, 21 Apr 2006 00:19:28 +0200 (MST) Message-ID: <444808EE.5010506@uni-tuebingen.de> Date: Fri, 21 Apr 2006 00:19:26 +0200 From: Ali Fessi User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: nsis Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new (McAfee AntiVirus) at informatik.uni-tuebingen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Subject: [NSIS] NATFW NSLP; ingress filtering X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi, in Section 5.12, there is an extensive explanation of the term "ingress filtering" with a figure 46. I think "ingress filtering" is so common. There is actually no need to have such an explanation in the draft. a reference, for example to RFC 2827, could be more appropriate. Cheers, ali -- Ali Fessi University of Tuebingen, Germany _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Apr 21 07:20:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWtfx-0004wI-0o; Fri, 21 Apr 2006 07:19:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWtfv-0004wD-3z for nsis@ietf.org; Fri, 21 Apr 2006 07:19:47 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FWtfu-0001bx-Ma for nsis@ietf.org; Fri, 21 Apr 2006 07:19:47 -0400 Received: (qmail invoked by alias); 21 Apr 2006 11:19:45 -0000 Received: from socks2.netz.sbs.de (EHLO [192.35.17.25]) [192.35.17.25] by mail.gmx.net (mp001) with SMTP; 21 Apr 2006 13:19:45 +0200 X-Authenticated: #29516787 Message-ID: <4448BFD1.1070003@gmx.net> Date: Fri, 21 Apr 2006 13:19:45 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ali Fessi Subject: Re: [NSIS] NATFW NSLP; No solution provided for attack described in section 5.5.3 References: <44480714.2000907@uni-tuebingen.de> In-Reply-To: <44480714.2000907@uni-tuebingen.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: nsis X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Ali, thanks for looking at these issues. Ali Fessi wrote: > Dear NATFW NSLP authors, > > there is currently no security requirement derived from the threat > described in Section 5.5.3 (Data Receiver (DR) behind a firewall); > > although it is a very realistic attack! > I think some additional text is needed to indicate that this type of attack can be addressed in the following case: * The DR might want to place restrictions on the data senders it wants to talk. This is possible with the DTINFO object. If he knows that he is going to talk to someone but does not know to whom then this is obviously a little bit difficult. * The authorization policy solutions (done in the context of SIP), for example, could certainly help to prevent an adversary from learning the contact address of the data receiver. I think we should add this text to the section instead of saying that there is no requirement raised. Since the authorization tokens are not dealt with in this document there is actually no requirement raised here. > However, looking at the whole document, a solution for resolving this > attack can be actually provided: > > - either by relying on an authorization framework (authorization tokens, > SAML, etc.) > > - or by relying upon GIST or underlying protocols, for providing > hop-by-hop authentication; I agree that these mechanisms could prevent an "attack". However, the current text already indicates that the middlebox could authorize the end host. As such, I think it is already addressed. Since this is the threat/scenario section I guess we don't need to describe possible solutions. > > So the derived security requirements could be updated accordingly (i > could provide a suggestions for some text, if you want) > > Also: the attack described in section 5.5.4 is actually the same except > the middlebox function is a NAT instead of firewall; but this doesn't > make a difference. With a DR behind a NAT the DS will send the NSIS signaling message (and the data traffic through the NAT) while this is not necessarily true for the Firewall case. Still, I agree that both sections should be merged due to heir similiarity. > > Regards, > Ali > > Ciao Hannes > ------------------------------------------------------------------------ > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Apr 21 07:23:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWtj5-00060k-TM; Fri, 21 Apr 2006 07:23:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWtj4-00060f-3V for nsis@ietf.org; Fri, 21 Apr 2006 07:23:02 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FWtj2-0001ih-MR for nsis@ietf.org; Fri, 21 Apr 2006 07:23:02 -0400 Received: (qmail invoked by alias); 21 Apr 2006 11:22:48 -0000 Received: from socks2.netz.sbs.de (EHLO [192.35.17.25]) [192.35.17.25] by mail.gmx.net (mp038) with SMTP; 21 Apr 2006 13:22:48 +0200 X-Authenticated: #29516787 Message-ID: <4448C088.8020906@gmx.net> Date: Fri, 21 Apr 2006 13:22:48 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ali Fessi Subject: Re: [NSIS] NATFW NSLP; attack in Section 5.10.1 is not specific to NATs References: <44480737.4000202@uni-tuebingen.de> In-Reply-To: <44480737.4000202@uni-tuebingen.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: nsis X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Ali, it is true that we should also depict a firewall in the scenario. The difference between the NAT and the Firewall scenario is that an adversary could be able to modify the NAT binding and would be able to also see the data traffic. If the policy rule at the firewall is changed by an adversary then the firewall would, for example, block the traffic. Ciao Hannes Ali Fessi wrote: > Hi, > > the attack described in Section 5.10.1 (Misuse of mobility in NAT > handling) is actually not specific to NATs. Firewalls need also to > update their policy rules to support mobility. > > I would modify the description of the attack accordingly and call it > "Miuse of Mobility Support" or something like this. > > Also: in the figure 42, the end host does not necessarly need to be on > the private side of the network. a Mobile Node can be on both sides of > the network; and in both cases, policy rules need to be updated. > > So there shouldn't be a difference between the public and the private > network sides. > > Regards, > Ali _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Apr 21 07:53:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWuCI-0000xN-VX; Fri, 21 Apr 2006 07:53:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWuCH-0000xI-Ep for nsis@ietf.org; Fri, 21 Apr 2006 07:53:13 -0400 Received: from mx5.informatik.uni-tuebingen.de ([134.2.12.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWuCF-0002VX-SK for nsis@ietf.org; Fri, 21 Apr 2006 07:53:13 -0400 Received: from localhost (loopback [127.0.0.1]) by mx5.informatik.uni-tuebingen.de (Postfix) with ESMTP id 9F3E911C; Fri, 21 Apr 2006 13:53:10 +0200 (MST) Received: from mx5.informatik.uni-tuebingen.de ([127.0.0.1]) by localhost (mx5 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 36772-04; Fri, 21 Apr 2006 13:53:08 +0200 (DFT) Received: from [127.0.0.1] (rouen.Informatik.Uni-Tuebingen.De [134.2.11.152]) by mx5.informatik.uni-tuebingen.de (Postfix) with ESMTP id 5E50A115; Fri, 21 Apr 2006 13:53:08 +0200 (MST) Message-ID: <4448C7A3.8090100@uni-tuebingen.de> Date: Fri, 21 Apr 2006 13:53:07 +0200 From: Ali Fessi User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Hannes Tschofenig Subject: Re: [NSIS] NATFW NSLP; No solution provided for attack described in section 5.5.3 References: <44480714.2000907@uni-tuebingen.de> <4448BFD1.1070003@gmx.net> In-Reply-To: <4448BFD1.1070003@gmx.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new (McAfee AntiVirus) at informatik.uni-tuebingen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: nsis X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Hannes, Hannes Tschofenig wrote: > Hi Ali, > > thanks for looking at these issues. > > Ali Fessi wrote: > >> Dear NATFW NSLP authors, >> >> there is currently no security requirement derived from the threat >> described in Section 5.5.3 (Data Receiver (DR) behind a firewall); >> >> although it is a very realistic attack! >> > > I think some additional text is needed to indicate that this type of > attack can be addressed in the following case: > * The DR might want to place restrictions on the data senders it wants > to talk. This is possible with the DTINFO object. If he knows that he is > going to talk to someone but does not know to whom then this is > obviously a little bit difficult. > * The authorization policy solutions (done in the context of SIP), for > example, could certainly help to prevent an adversary from learning the > contact address of the data receiver. > > I think we should add this text to the section instead of saying that > there is no requirement raised. Since the authorization tokens are not > dealt with in this document there is actually no requirement raised here. sounds good. > >> However, looking at the whole document, a solution for resolving this >> attack can be actually provided: >> >> - either by relying on an authorization framework (authorization >> tokens, SAML, etc.) >> >> - or by relying upon GIST or underlying protocols, for providing >> hop-by-hop authentication; > > > I agree that these mechanisms could prevent an "attack". > However, the current text already indicates that the middlebox could > authorize the end host. As such, I think it is already addressed. Since > this is the threat/scenario section I guess we don't need to describe > possible solutions. > >> >> So the derived security requirements could be updated accordingly (i >> could provide a suggestions for some text, if you want) >> >> Also: the attack described in section 5.5.4 is actually the same >> except the middlebox function is a NAT instead of firewall; but this >> doesn't make a difference. > > > With a DR behind a NAT the DS will send the NSIS signaling message (and > the data traffic through the NAT) while this is not necessarily true for > the Firewall case. > > Still, I agree that both sections should be merged due to heir similiarity. sounds also good. Thanks, Ali > >> >> Regards, >> Ali >> >> > > Ciao > Hannes > >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> nsis mailing list >> nsis@ietf.org >> https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Apr 21 07:54:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWuDF-0001tk-Cb; Fri, 21 Apr 2006 07:54:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWuDE-0001jJ-2o for nsis@ietf.org; Fri, 21 Apr 2006 07:54:12 -0400 Received: from mx5.informatik.uni-tuebingen.de ([134.2.12.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWuDC-0002Wr-LL for nsis@ietf.org; Fri, 21 Apr 2006 07:54:12 -0400 Received: from localhost (loopback [127.0.0.1]) by mx5.informatik.uni-tuebingen.de (Postfix) with ESMTP id DED8F115; Fri, 21 Apr 2006 13:54:09 +0200 (MST) Received: from mx3.informatik.uni-tuebingen.de ([134.2.12.26]) by localhost (mx5 [134.2.12.32]) (amavisd-new, port 10024) with ESMTP id 24268-04; Fri, 21 Apr 2006 13:54:07 +0200 (DFT) Received: from [127.0.0.1] (rouen.Informatik.Uni-Tuebingen.De [134.2.11.152]) by mx3.informatik.uni-tuebingen.de (Postfix) with ESMTP id 9C978141; Fri, 21 Apr 2006 13:54:06 +0200 (MST) Message-ID: <4448C7DD.4040104@uni-tuebingen.de> Date: Fri, 21 Apr 2006 13:54:05 +0200 From: Ali Fessi User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Hannes Tschofenig Subject: Re: [NSIS] NATFW NSLP; attack in Section 5.10.1 is not specific to NATs References: <44480737.4000202@uni-tuebingen.de> <4448C088.8020906@gmx.net> In-Reply-To: <4448C088.8020906@gmx.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new (McAfee AntiVirus) at informatik.uni-tuebingen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: nsis X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi, Hannes Tschofenig wrote: > Hi Ali, > > it is true that we should also depict a firewall in the scenario. > The difference between the NAT and the Firewall scenario is that an > adversary could be able to modify the NAT binding and would be able to > also see the data traffic. > > If the policy rule at the firewall is changed by an adversary then the > firewall would, for example, block the traffic. This would be possible only if the firewall knows that it was an adversary! ;-) or did i misunderstand something? Cheers, Ali _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Apr 21 08:02:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWuLh-0004bA-Ab; Fri, 21 Apr 2006 08:02:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWuLf-0004b5-Mr for nsis@ietf.org; Fri, 21 Apr 2006 08:02:55 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FWuLe-0002pF-AK for nsis@ietf.org; Fri, 21 Apr 2006 08:02:55 -0400 Received: (qmail invoked by alias); 21 Apr 2006 12:02:53 -0000 Received: from socks2.netz.sbs.de (EHLO [192.35.17.25]) [192.35.17.25] by mail.gmx.net (mp039) with SMTP; 21 Apr 2006 14:02:53 +0200 X-Authenticated: #29516787 Message-ID: <4448C9ED.6030604@gmx.net> Date: Fri, 21 Apr 2006 14:02:53 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ali Fessi Subject: Re: [NSIS] NATFW NSLP; ingress filtering References: <444808EE.5010506@uni-tuebingen.de> In-Reply-To: <444808EE.5010506@uni-tuebingen.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: nsis X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org I agree with you. This helps to shorten the document. Ali Fessi wrote: > Hi, > > in Section 5.12, there is an extensive explanation of the term "ingress > filtering" with a figure 46. > > I think "ingress filtering" is so common. There is actually no need to > have such an explanation in the draft. > > a reference, for example to RFC 2827, could be more appropriate. > > Cheers, > ali _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Apr 21 08:14:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWuWx-0002RU-Fm; Fri, 21 Apr 2006 08:14:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWuWv-0002RP-LM for nsis@ietf.org; Fri, 21 Apr 2006 08:14:33 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FWuWu-0003AO-8m for nsis@ietf.org; Fri, 21 Apr 2006 08:14:33 -0400 Received: (qmail invoked by alias); 21 Apr 2006 12:07:51 -0000 Received: from socks2.netz.sbs.de (EHLO [192.35.17.25]) [192.35.17.25] by mail.gmx.net (mp020) with SMTP; 21 Apr 2006 14:07:51 +0200 X-Authenticated: #29516787 Message-ID: <4448CB17.1000903@gmx.net> Date: Fri, 21 Apr 2006 14:07:51 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ali Fessi Subject: Re: [NSIS] NATFW NSLP; attack in Section 5.10.1 is not specific to NATs References: <44480737.4000202@uni-tuebingen.de> <4448C088.8020906@gmx.net> <4448C7DD.4040104@uni-tuebingen.de> In-Reply-To: <4448C7DD.4040104@uni-tuebingen.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: nsis X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Ali, Ali Fessi wrote: > Hi, > > Hannes Tschofenig wrote: > >> Hi Ali, >> >> it is true that we should also depict a firewall in the scenario. >> The difference between the NAT and the Firewall scenario is that an >> adversary could be able to modify the NAT binding and would be able to >> also see the data traffic. >> >> If the policy rule at the firewall is changed by an adversary then the >> firewall would, for example, block the traffic. > > > This would be possible only if the firewall knows that it was an > adversary! ;-) or did i misunderstand something? Look at the following figure: +----------+ +----------+ +----------+ | NAT | | Host A | |Malicious | | | | | |End host | +----------+ +----------+ +----------+ | | | | Data Traffic | | |--------->----------| | | | Spurious | | | NAT binding update | |---------<----------+--------<------------| | | | | Data Traffic | | |--------->----------+-------->------------| | | | If the adversary changes the NAT binding then it could receive the data traffic that was meant to be sent towards Host A. If you replace the NAT with a firewall and if the adversary changes the policy rule at the firewall then packets might, as one possibilty, be dropped. The adversary would cause a denial of service against Host A. This attack would, however, be self-healing since Host A would periodically resend a refresh message and thereby changing the policy rule back again. Ciao Hannes > > Cheers, > Ali > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Apr 21 16:07:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FX1u8-0004Uz-0I; Fri, 21 Apr 2006 16:07:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FX1u6-0004Ia-8j for nsis@ietf.org; Fri, 21 Apr 2006 16:06:58 -0400 Received: from mail.piranho.net ([80.190.191.60]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FX1u2-0003jh-LI for nsis@ietf.org; Fri, 21 Apr 2006 16:06:58 -0400 Received: (qmail 15911 invoked from network); 21 Apr 2006 20:06:40 -0000 Received: from localhost (HELO mail.piranho.net) (127.0.0.1) by 0 with SMTP; 21 Apr 2006 20:06:40 -0000 Received: from 24.199.92.165 (SquirrelMail authenticated user zedsoy) by mail.piranho.net with HTTP; Fri, 21 Apr 2006 16:06:40 -0400 (EDT) Message-ID: <60367.24.199.92.165.1145650000.squirrel@mail.piranho.net> Date: Fri, 21 Apr 2006 16:06:40 -0400 (EDT) From: "Henning Peters" To: nsis@ietf.org User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c Subject: [NSIS] NAT/Firewall NSLP LE-MRM/DTINFO concerns X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Dear WG, dear NAT/Firewall NSLP authors, NAT/Firewall NSLP is a quite stable and usable protocol. There is running code already available that covers broad aspects of its functionality. This proves at least that from an complexity and functional viewpoint it can be considered feasible. Still, I find that some parts of the spec can be improved. Here, I would like to present my concerns connected to LE-MRM/DTINFO that I developed during working on our implementation. shortcut: the questions related to WG discussion are at 4). 1) Confusing directions Most notable, the directions are a bit confusing in this object. src port is data sender (DS) port, dst port is data receiver (DR) port. DR port is subject of rewrite, whereas DS port specifies the data sender. I would appreciate avoiding the term source and destination in this context, this would also leverage the positioning issue (see later *** when discussing the message format that confusely destination port is positioned before source port). Anyway, I will refer to DS port and DR port in the following. 2) LE-MRM / DTINFO ports After introduction of LE-MRM (loose end message routing method) to the spec last year it was found that NAT traversal in NAPTs is broken as LE-MRM does not carry port information. Ports are considered as not part of GIST routing and therefore omitted from MRI. To compensate this DTINFO object was enhanced later with the port information that was previously accessable in PC-MRM (signaling the wrong way) MRI. I believe that the current approach is not a good design decision as GIST NAT traversal would be rendered broken. GIST NAT traversal is crucial as we cannot assume a domainwide deployment of NAT/Firewall NSLP instantly. I would appreciate a deployable over a 100% clean solution as deployment will be very crucial to NAT/Firewall NSLP success anyway. See Martin's and my discussion in the issue tracker: https://kobe.netlab.nec.de/roundup/nsis-natfw-nslp/issue50 Actually, only the DR port and protocol field is needed for NAT traversal as REA/LE-MRM needs only a one-sided translation. 3) DTINFO message format The message format of the current solution is a bit confusing and lacks IPv6 support (DTINFOv6 object was removed in previous draft). Let me start with its figure: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |I|P|S| reserved | dest prefix | protocol | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (***): dst port number [DR] | src port number [DS] : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : IPsec SPI : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | data sender's IPv4 address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The purpose of this object is two-fold: - specify data sender during REA (aka: the cone-ness of the NAT) - supply DR port/protocol for NAT traversal Unfortunately, the draft heavily mixes and overloads these two different semantical aspects in this object. Specifically, I see following issues: a) The P flag specifies whether port numbers are present or not. This means that either both ports are present or none. Confusely, DR port and DS port cover different semantic aspects: DS port specifies the data sender, DR port is necessary for NAT traversal. A single flag to enable/disable two fields with different semantical meaning can be problematic. b) The I flag specifies whether the protocol field should be interpreted or not. The protocol defines the protocol used for above mentioned ports if the P flag is set aswell. Although the ports are of different semantical meaning, the protocol covers both equally. I am not sure whether this semantical overloading may introduce new problems, at least this limits flexibility compared to PC-MRM case where a protocol can be set in MRI and in DTINFO independently. c) DTINFO object might be used for firewall signaling scenarios. But LE-MRM can only cover NAT-only scenarios. That means that the NR has to know the scenario in advance to choose between PC-MRM and LE-MRM signaling. The more intelligence is put into NR the more it evolves to a probing NR. A probing NR sounds to me a bit like the situations BEHAVE working group deal with; this is not the situation I would like to see NAT/Firewall NSLP in. I think that our network states can be used more flexibly to assist the NR better. The NR should not care about the network, but only give the definitions that the network should adapt to. Surely, this is a design decision that needs WG consensus. d) DTINFO object MUST be included when using LE-MRM as NAT traversal is not possible as long as DR port is not available. Therefore, following paragraphs might need correction: > The NI+ MAY include a NATFW_DTINFO_IPv4 object in the REA message > when using the LE-MRM. The LE-MRM does not include enough also: > When the data sender's address information is known in advance the NI+ > MAY include a NATFW_DTINFO_IPv4 object in the REA message (as described > above). 4) I hope I pointed out that a discussion of following points in the WG is necessary: - How much intelligence should have the NR -> shall the network handle the deployment sceario or should the NR know/probe the network scenario? - Is a broken GIST NAT traversal worth giving up a 100% clean MRM design? The message format issues heavily depend on these discussions, therefore I would rather like to delay the message format design until both questions gained consensus. I also appreciate any feedback on our NAT/Firewall NSLP implementation available at: http://user.informatik.uni-goettingen.de/~nsis/ Thank you for your attention, Henning Peters _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Sat Apr 22 00:54:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FXA8t-0002NR-97; Sat, 22 Apr 2006 00:54:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FXA8r-0002NM-B3 for nsis@ietf.org; Sat, 22 Apr 2006 00:54:45 -0400 Received: from denhaag.ewi.utwente.nl ([130.89.10.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FXA8q-000741-QO for nsis@ietf.org; Sat, 22 Apr 2006 00:54:45 -0400 Received: from zeus.cs.utwente.nl (zeus.ewi.utwente.nl [130.89.10.12]) by denhaag.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id k3M4sf71023410; Sat, 22 Apr 2006 06:54:41 +0200 (MEST) Received: from janus.cs.utwente.nl (janus [130.89.10.26]) by zeus.cs.utwente.nl (8.12.10/8.12.10) with ESMTP id k3M4sfGM008677; Sat, 22 Apr 2006 06:54:41 +0200 (MEST) Received: (from nobody@localhost) by janus.cs.utwente.nl (8.11.7p1+Sun/8.10.2) id k3M4seK08492; Sat, 22 Apr 2006 06:54:40 +0200 (MEST) Date: Sat, 22 Apr 2006 06:54:40 +0200 (MEST) X-Authentication-Warning: janus.cs.utwente.nl: nobody set sender to karagian@cs.utwente.nl using -f To: john.loughney@nokia.com, Ruediger.Geib@t-systems.com, hannes.tschofenig@siemens.com Subject: RE: [NSIS] one or separate qos models for classic and PCN CLrespectively Received: from 84.82.109.231 (auth. user karagian@imap2.cs.utwente.nl) by webmail.cs.utwente.nl with HTTP; Sat, 22 Apr 2006 04:54:40 +0000 X-IlohaMail-Blah: karagian@ewi.utwente.nl X-IlohaMail-Method: mail() [mem] X-IlohaMail-Dummy: moo X-Mailer: IlohaMail/0.8.13 (On: webmail.cs.utwente.nl) Message-ID: In-Reply-To: <615BD9B54CB01B41838C323DB9E91AAB0C92CD@esebe100.NOE.Nokia.com> From: "Georgios Karagiannis" Bounce-To: "Georgios Karagiannis" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -5.899 () ALL_TRUSTED,BAYES_00 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0b5 (denhaag.ewi.utwente.nl [130.89.10.11]); Sat, 22 Apr 2006 06:54:42 +0200 (MEST) X-Spam-Score: 0.1 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: "nsis@ietf.org" X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi John In my opinion CL should be considered as an end to end QoS model. It should be of course possible that any local QoS model should be used in combination with this end-to-end QoS model. Best Regards, Georgios On 4/11/2006, "john.loughney@nokia.com" wrote: >Rudy, > >>the issue was raised in the minutes to be taken to the list. >> >>Arguments to support only a single QoS model are: >> >>- simplification of the end system (which doesn't have to >> worry which flavor of a CL QoS model is applied by the >> network or by the remote end system). >> >>- no mapping or interworking required. >> >>That would assume that the characteristics of the service are >>the same, no matter how it is produced. But this question will >>arise with any interworking. CL over IP/MPLS, CL over >>aggregated NSIS, CL over a network avoiding packet losses by >>provisioning. >> >>My position would be, if a carrier guarantees service, CL can >>be produced and should use a single QoS model. Independent of >>the way the CL service is produced in the backbone. > >Not quite sure what your exact opinion is - are you saying that >CL SHOULD be the default QoS handling, or are you suggesting >that if an operator wants CL, they use CL? > >Some off-line discussions indicate that there might be interest in >a basic inter-domain QoS model - for signaling QoS between different >service providers. This QoS model would be independent of how >QoS is deployed within a network. Would this be something of >interst? > >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 nsis-bounces@ietf.org Sat Apr 22 05:18:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FXEFj-0003Hx-H0; Sat, 22 Apr 2006 05:18:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FXEFh-0003Hs-GX for nsis@ietf.org; Sat, 22 Apr 2006 05:18:05 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FXEFf-00041U-Rx for nsis@ietf.org; Sat, 22 Apr 2006 05:18:05 -0400 Received: (qmail invoked by alias); 22 Apr 2006 09:18:02 -0000 Received: from p54987329.dip.t-dialin.net (EHLO [192.168.2.33]) [84.152.115.41] by mail.gmx.net (mp026) with SMTP; 22 Apr 2006 11:18:02 +0200 X-Authenticated: #29516787 Message-ID: <4449F4CA.3070803@gmx.net> Date: Sat, 22 Apr 2006 11:18:02 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henning Peters Subject: Re: [NSIS] NAT/Firewall NSLP LE-MRM/DTINFO concerns References: <60367.24.199.92.165.1145650000.squirrel@mail.piranho.net> In-Reply-To: <60367.24.199.92.165.1145650000.squirrel@mail.piranho.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: ccfb4541e989aa743998098cd315d0fd Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Henning, thanks for your comments. Please find my response below: Henning Peters wrote: > Dear WG, dear NAT/Firewall NSLP authors, > > NAT/Firewall NSLP is a quite stable and usable protocol. There is running > code already available that covers broad aspects of its functionality. > This proves at least that from an complexity and functional viewpoint it > can be considered feasible. Still, I find that some parts of the spec can > be improved. Here, I would like to present my concerns connected to > LE-MRM/DTINFO that I developed during working on our implementation. > > shortcut: the questions related to WG discussion are at 4). > > 1) Confusing directions > > Most notable, the directions are a bit confusing in this object. src port > is data sender (DS) port, dst port is data receiver (DR) port. DR port is > subject of rewrite, whereas DS port specifies the data sender. I would > appreciate avoiding the term source and destination in this context, this > would also leverage the positioning issue (see later *** when discussing > the message format that confusely destination port is positioned before > source port). I agree. > > Anyway, I will refer to DS port and DR port in the following. > > 2) LE-MRM / DTINFO ports > > After introduction of LE-MRM (loose end message routing method) to the > spec last year it was found that NAT traversal in NAPTs is broken as > LE-MRM does not carry port information. Ports are considered as not part > of GIST routing and therefore omitted from MRI. > > To compensate this DTINFO object was enhanced later with the port > information that was previously accessable in PC-MRM (signaling the wrong > way) MRI. I believe that the current approach is not a good design > decision as GIST NAT traversal would be rendered broken. GIST NAT > traversal is crucial as we cannot assume a domainwide deployment of > NAT/Firewall NSLP instantly. I would appreciate a deployable over a 100% > clean solution as deployment will be very crucial to NAT/Firewall NSLP > success anyway. The counter argument is the following: Why should someone use GIST NAT traversal when in relationship to the NATFW NSLP? Problems show up when the QoS NSLP suddenly starts to use a proxy mode configuration similar to the NATFW NSLP. I personally, however, think that the introduction of the port numbers into the LE-MRM would be cleaner. > > See Martin's and my discussion in the issue tracker: > https://kobe.netlab.nec.de/roundup/nsis-natfw-nslp/issue50 > > Actually, only the DR port and protocol field is needed for NAT traversal > as REA/LE-MRM needs only a one-sided translation. > > 3) DTINFO message format > > The message format of the current solution is a bit confusing and lacks > IPv6 support (DTINFOv6 object was removed in previous draft). Let me start > with its figure: > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |I|P|S| reserved | dest prefix | protocol | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > (***): dst port number [DR] | src port number [DS] : > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > : IPsec SPI : > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | data sender's IPv4 address | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > The purpose of this object is two-fold: > > - specify data sender during REA (aka: the cone-ness of the NAT) > > - supply DR port/protocol for NAT traversal > > Unfortunately, the draft heavily mixes and overloads these two different > semantical aspects in this object. Specifically, I see following issues: > > a) The P flag specifies whether port numbers are present or not. This > means that either both ports are present or none. Confusely, DR port and > DS port cover different semantic aspects: > > DS port specifies the data sender, DR port is necessary for NAT traversal. > A single flag to enable/disable two fields with different semantical > meaning can be problematic. I agree. > > b) The I flag specifies whether the protocol field should be interpreted > or not. The protocol defines the protocol used for above mentioned ports > if the P flag is set aswell. Although the ports are of different > semantical meaning, the protocol covers both equally. > > I am not sure whether this semantical overloading may introduce new > problems, at least this limits flexibility compared to PC-MRM case where a > protocol can be set in MRI and in DTINFO independently. > > c) DTINFO object might be used for firewall signaling scenarios. But > LE-MRM can only cover NAT-only scenarios. That means that the NR has to > know the scenario in advance to choose between PC-MRM and LE-MRM > signaling. The more intelligence is put into NR the more it evolves to a > probing NR. I don't think that the LE-MRM can only be used for NAT scenarios. In a firewall scenario an applicability statement is appropriate to deal with multi-homed networks. > > A probing NR sounds to me a bit like the situations BEHAVE working group > deal with; this is not the situation I would like to see NAT/Firewall NSLP > in. I think that our network states can be used more flexibly to assist > the NR better. The NR should not care about the network, but only give the > definitions that the network should adapt to. > > Surely, this is a design decision that needs WG consensus. > > d) DTINFO object MUST be included when using LE-MRM as NAT traversal is > not possible as long as DR port is not available. Therefore, following > paragraphs might need correction: > > >>The NI+ MAY include a NATFW_DTINFO_IPv4 object in the REA message >>when using the LE-MRM. The LE-MRM does not include enough > > > also: > > >>When the data sender's address information is known in advance the NI+ >>MAY include a NATFW_DTINFO_IPv4 object in the REA message (as described >>above). > > I agree. > 4) I hope I pointed out that a discussion of following points in the WG is > necessary: > > - How much intelligence should have the NR -> shall the network handle the > deployment sceario or should the NR know/probe the network scenario? > I think that the NR should be required to have as little information as possible. > - Is a broken GIST NAT traversal worth giving up a 100% clean MRM design? The problems particularly show up when the QoS folks decide to use the LE-MRM for a proxy solution. > > The message format issues heavily depend on these discussions, therefore I > would rather like to delay the message format design until both questions > gained consensus. > > I also appreciate any feedback on our NAT/Firewall NSLP implementation > available at: > > http://user.informatik.uni-goettingen.de/~nsis/ Ciao Hannes > > Thank you for your attention, > Henning Peters > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Apr 28 08:13:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZRqX-0005sc-1U; Fri, 28 Apr 2006 08:13:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZRqW-0005sS-8o for nsis@ietf.org; Fri, 28 Apr 2006 08:13:16 -0400 Received: from rsys002x.roke.co.uk ([193.118.201.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZRqU-0005lx-Rp for nsis@ietf.org; Fri, 28 Apr 2006 08:13:16 -0400 Received: from rsys005a.comm.ad.roke.co.uk (rsys005a [193.118.193.85]) by rsys002x.roke.co.uk (8.13.1/8.13.1) with ESMTP id k3SCCwsC025143; Fri, 28 Apr 2006 13:13:08 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] NATFW NSLP; attack in Section 5.10.1 is not specific to NATs Date: Fri, 28 Apr 2006 13:13:00 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] NATFW NSLP; attack in Section 5.10.1 is not specific to NATs Thread-Index: AcZkx5QJMHUAxf3ZQ9a0CAlMrmqQKQF9H0Ng From: "Hancock, Robert" To: "Ali Fessi" , "nsis" X-MailScanner-roke.co.uk: Found to be clean X-MailScanner-roke.co.uk-SpamCheck: X-MailScanner-From: robert.hancock@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org hi, [this is not really a follow up to Ali's question but another issue on 5.10:] I found at least the introduction of the scenario in 5.10 a=20 little difficult to follow from a motivational point of view. How common is it for IP layer mobility to be used purely on=20 the private side of a NAT? (I'm not saying that it's impossible, just that I tend to think of NATs as reducing the need for renumbering in small networks, where you wouldn't use IP mobility in the first place.) A more significant point is that the mitigation described on page 81 (second sentence) seems to depend on the end host being=20 able to prove session ownership directly to the NAT, but the=20 facilities available mainly apply to peer-peer relationships.=20 Is the last sentence here actually correct? r. > -----Original Message----- > From: Ali Fessi [mailto:ali.fessi@uni-tuebingen.de]=20 > Sent: 20 April 2006 23:12 > To: nsis > Subject: [NSIS] NATFW NSLP; attack in Section 5.10.1 is not=20 > specific to NATs >=20 >=20 > Hi, >=20 > the attack described in Section 5.10.1 (Misuse of mobility in NAT=20 > handling) is actually not specific to NATs. Firewalls need also to=20 > update their policy rules to support mobility. >=20 > I would modify the description of the attack accordingly and call it=20 > "Miuse of Mobility Support" or something like this. >=20 > Also: in the figure 42, the end host does not necessarly need=20 > to be on=20 > the private side of the network. a Mobile Node can be on both=20 > sides of=20 > the network; and in both cases, policy rules need to be updated. >=20 > So there shouldn't be a difference between the public and the private=20 > network sides. >=20 > Regards, > Ali > --=20 > Ali Fessi > University of Tuebingen, Germany >=20 > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Apr 28 08:30:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZS7Q-0005mL-NA; Fri, 28 Apr 2006 08:30:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZS7P-0005mG-06 for nsis@ietf.org; Fri, 28 Apr 2006 08:30:43 -0400 Received: from rsys002x.roke.co.uk ([193.118.201.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZS7N-0007Oe-It for nsis@ietf.org; Fri, 28 Apr 2006 08:30:42 -0400 Received: from rsys005a.comm.ad.roke.co.uk (rsys005a [193.118.193.85]) by rsys002x.roke.co.uk (8.13.1/8.13.1) with ESMTP id k3SCUR88027573; Fri, 28 Apr 2006 13:30:32 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] NATFW NSLP; ingress filtering Date: Fri, 28 Apr 2006 13:30:27 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] NATFW NSLP; ingress filtering Thread-Index: AcZlO5GrlTo3YIM+Tf62ySHywxENzAFgcZZw From: "Hancock, Robert" To: "Hannes Tschofenig" , "Ali Fessi" X-MailScanner-roke.co.uk: Found to be clean X-MailScanner-roke.co.uk-SpamCheck: X-MailScanner-From: robert.hancock@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: nsis X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi, I also don't see that this section adds much to the=20 understanding of how to implement or deploy the protocol. However, its presence did remind me that there is a related use of ingress filtering to prevent traffic injection in=20 the signalling plane - i.e. sending a packet with a header that is legitimate at the IP level but which refers to=20 traffic (via the included MRI) which the signalling source cannot have any proper interest in. The filter check is carried out by GIST (see section 5.8.1.2 of the spec), but it's left up to the NSLP to decide whether to drop the message as a result. I wonder whether the corresponding NSLP/GIST interaction should be mentioned somewhere here - it's=20 probably more relevant to the other threats (e.g. 5.5.5). r. PS two typos at the top of p83, 'IPy' and 'match ,' > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 > Sent: 21 April 2006 13:03 > To: Ali Fessi > Cc: nsis > Subject: Re: [NSIS] NATFW NSLP; ingress filtering >=20 >=20 > I agree with you. > This helps to shorten the document. >=20 > Ali Fessi wrote: > > Hi, > >=20 > > in Section 5.12, there is an extensive explanation of the=20 > term "ingress=20 > > filtering" with a figure 46. > >=20 > > I think "ingress filtering" is so common. There is actually=20 > no need to=20 > > have such an explanation in the draft. > >=20 > > a reference, for example to RFC 2827, could be more appropriate. > >=20 > > Cheers, > > ali >=20 >=20 > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Apr 28 08:33:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZSAB-0007di-H3; Fri, 28 Apr 2006 08:33:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZSAA-0007dd-Df for nsis@ietf.org; Fri, 28 Apr 2006 08:33:34 -0400 Received: from mx5.informatik.uni-tuebingen.de ([134.2.12.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZSA8-0007XX-MZ for nsis@ietf.org; Fri, 28 Apr 2006 08:33:34 -0400 Received: from localhost (loopback [127.0.0.1]) by mx5.informatik.uni-tuebingen.de (Postfix) with ESMTP id 5509F11C; Fri, 28 Apr 2006 14:33:31 +0200 (MST) Received: from mx3.informatik.uni-tuebingen.de ([134.2.12.26]) by localhost (mx5 [134.2.12.32]) (amavisd-new, port 10024) with ESMTP id 36672-05; Fri, 28 Apr 2006 14:33:29 +0200 (DFT) Received: from [127.0.0.1] (rouen.Informatik.Uni-Tuebingen.De [134.2.11.152]) by mx3.informatik.uni-tuebingen.de (Postfix) with ESMTP id E0EF6145; Fri, 28 Apr 2006 14:33:28 +0200 (MST) Message-ID: <44520B98.7070603@uni-tuebingen.de> Date: Fri, 28 Apr 2006 14:33:28 +0200 From: Ali Fessi User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Hancock, Robert" Subject: Re: [NSIS] NATFW NSLP; attack in Section 5.10.1 is not specific to NATs References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new (McAfee AntiVirus) at informatik.uni-tuebingen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: nsis X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Robert, Hancock, Robert wrote: > hi, > > [this is not really a follow up to Ali's question but another > issue on 5.10:] > > I found at least the introduction of the scenario in 5.10 a > little difficult to follow from a motivational point of view. > How common is it for IP layer mobility to be used purely on > the private side of a NAT? (I'm not saying that it's impossible, > just that I tend to think of NATs as reducing the need for > renumbering in small networks, where you wouldn't use IP > mobility in the first place.) i'm not an expert in mobility; but i think, if Hierarchical MIP is used, then the HMIP anchor point would basically behaves as a NAT. So the scenario described in this section would fit well to HMIP. Maybe someone else can provide a better explanation?! > > A more significant point is that the mitigation described on > page 81 (second sentence) seems to depend on the end host being > able to prove session ownership directly to the NAT, but the > facilities available mainly apply to peer-peer relationships. > Is the last sentence here actually correct? I guess that the mitigation is meant to be provided hop-by-hop by authenticating the user by the NAT. But I fully agree with you that this section has to be revised. Cheers, Ali > > r. > > >>-----Original Message----- >>From: Ali Fessi [mailto:ali.fessi@uni-tuebingen.de] >>Sent: 20 April 2006 23:12 >>To: nsis >>Subject: [NSIS] NATFW NSLP; attack in Section 5.10.1 is not >>specific to NATs >> >> >>Hi, >> >>the attack described in Section 5.10.1 (Misuse of mobility in NAT >>handling) is actually not specific to NATs. Firewalls need also to >>update their policy rules to support mobility. >> >>I would modify the description of the attack accordingly and call it >>"Miuse of Mobility Support" or something like this. >> >>Also: in the figure 42, the end host does not necessarly need >>to be on >>the private side of the network. a Mobile Node can be on both >>sides of >>the network; and in both cases, policy rules need to be updated. >> >>So there shouldn't be a difference between the public and the private >>network sides. >> >>Regards, >>Ali >>-- >>Ali Fessi >>University of Tuebingen, Germany >> >>_______________________________________________ >>nsis mailing list >>nsis@ietf.org >>https://www1.ietf.org/mailman/listinfo/nsis >> -- Ali Fessi Computer Networks and Internet Wilhelm Schickard Institute for Computer Science University of Tuebingen, Germany Phone: +49 7071 29-70534 / Fax: +49 7071 29-5220 EMail: ali.fessi@uni-tuebingen.de Web: http://net.informatik.uni-tuebingen.de/~fessi/ _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Apr 28 08:58:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZSYC-0002AY-V6; Fri, 28 Apr 2006 08:58:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZSYB-0002AT-PM for nsis@ietf.org; Fri, 28 Apr 2006 08:58:23 -0400 Received: from rsys002x.roke.co.uk ([193.118.201.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZSYB-0008Hk-CX for nsis@ietf.org; Fri, 28 Apr 2006 08:58:23 -0400 Received: from rsys005a.comm.ad.roke.co.uk (rsys005a [193.118.193.85]) by rsys002x.roke.co.uk (8.13.1/8.13.1) with ESMTP id k3SCwDE9031501 for ; Fri, 28 Apr 2006 13:58:18 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 28 Apr 2006 13:58:13 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: NATFW Session and address lifetime Thread-Index: AcZqw2k2npr+fYwfSlaUPkIW9WVi9w== From: "Hancock, Robert" To: "nsis" X-MailScanner-roke.co.uk: Found to be clean X-MailScanner-roke.co.uk-SpamCheck: X-MailScanner-From: robert.hancock@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Subject: [NSIS] NATFW Session and address lifetime X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org hi, some comments on the session and address lifetime issue, see sections 3.4 and 5.11 (in particular) [nb these sections should probably refer to each other]. I think the main threat here is that an IP address that was validly assigned to one node which then set up signalling sessions referring to it may get validly reassigned to another node which then re-uses those sessions.=20 One solution to this is indeed data origin authentication as mentioned in the text. However, I'm sceptical that data origin authentication could ever be used in practice to address this sort of issue (it would require the address allocation process and protocol to include time-bounded credentials for the ownership of an address which everyone else in the network was able to verify). However, it should at least be possible to ensure that the node initiating a signalling session gave it a lifetime that was smaller than the remaining validity of any dynamically=20 allocated address. That way, by the time the address is available for re-allocation, any signalling sessions would have already timed out. I would propose to add this to section 3.4. Some lesser points on 3.4: - (page 28): the lifetime value should ideally take some account of load on the signalling plane. Short lifetimes imply more frequent signalling messages. - (page 28): the lifetime value should also take account of the acceptable time for a signalling session to be present after it is no longer actually needed. (For example, if the existence of the session implies a monetary cost and teardown cannot be guaranteed, shorter lifetimes would be preferable.) - (page 29): can messages be rejected on the basis of the lifetime being too long only when a session is first created, or also on refresh? - (page 29): it strikes me that as well as the 'lifetime too big' error there should be a 'lifetime too small' error. if someone initiates a session with a lifetime of 1 second, i am compelled to use a lifetime no longer than that on the downstream segments of the path. But that lifetime may cause excessive signalling load. It would be good to indicate what approaches are available to a NATFW implementation to handle this kind of overload. - (page 29 last paragraph): i don't understand which value is being referred to as the 'proposed' value. cheers, r. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Apr 28 09:39:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZTC2-0003c6-DS; Fri, 28 Apr 2006 09:39:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZTC0-0003c1-WE for nsis@ietf.org; Fri, 28 Apr 2006 09:39:33 -0400 Received: from mx5.informatik.uni-tuebingen.de ([134.2.12.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZTBz-0002eC-DO for nsis@ietf.org; Fri, 28 Apr 2006 09:39:32 -0400 Received: from localhost (loopback [127.0.0.1]) by mx5.informatik.uni-tuebingen.de (Postfix) with ESMTP id 840B711C; Fri, 28 Apr 2006 15:39:30 +0200 (MST) Received: from mx5.informatik.uni-tuebingen.de ([127.0.0.1]) by localhost (mx5 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24178-03; Fri, 28 Apr 2006 15:39:28 +0200 (DFT) Received: from [127.0.0.1] (rouen.Informatik.Uni-Tuebingen.De [134.2.11.152]) by mx5.informatik.uni-tuebingen.de (Postfix) with ESMTP id D6E9A11B; Fri, 28 Apr 2006 15:39:27 +0200 (MST) Message-ID: <44521B0F.2060307@uni-tuebingen.de> Date: Fri, 28 Apr 2006 15:39:27 +0200 From: Ali Fessi User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Hancock Subject: Re: [NSIS] NATFW NSLP; attack in Section 5.10.1 is not specific to NATs References: <44520B98.7070603@uni-tuebingen.de> In-Reply-To: <44520B98.7070603@uni-tuebingen.de> X-Virus-Scanned: by amavisd-new (McAfee AntiVirus) at informatik.uni-tuebingen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Cc: nsis X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0842821330==" Errors-To: nsis-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============0842821330== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090406090506000704030506" This is a cryptographically signed message in MIME format. --------------ms090406090506000704030506 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi again, Ali Fessi wrote: > Hi Robert, > > Hancock, Robert wrote: > >> hi, >> >> [this is not really a follow up to Ali's question but another >> issue on 5.10:] >> >> I found at least the introduction of the scenario in 5.10 a little >> difficult to follow from a motivational point of view. >> How common is it for IP layer mobility to be used purely on the >> private side of a NAT? (I'm not saying that it's impossible, >> just that I tend to think of NATs as reducing the need for >> renumbering in small networks, where you wouldn't use IP >> mobility in the first place.) > > > i'm not an expert in mobility; but i think, if Hierarchical MIP is used, > then the HMIP anchor point would basically behaves as a NAT. So the > scenario described in this section would fit well to HMIP. > > Maybe someone else can provide a better explanation?! i've just thought about it a bit more. the setup with HMIP is similar; but with HMIP there is no need for NSIS NATFW NSLP. Instead, Mobile Nodes send their Mobile IP "Binding Updates" straightforward to the HMIP anchor point. So, the motivation for scenario 5.10 is still unclear. Cheers, Ali --------------ms090406090506000704030506 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJSTCC Av8wggJooAMCAQICECvZHKWODjLVSWiWg0FHOegwDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MDIwNzIxMzIyOFoX DTA3MDIwNzIxMzIyOFowXTEOMAwGA1UEBBMFRmVzc2kxDDAKBgNVBCoTA0FsaTESMBAGA1UE AxMJQWxpIEZlc3NpMSkwJwYJKoZIhvcNAQkBFhphbGkuZmVzc2lAdW5pLXR1ZWJpbmdlbi5k ZTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMFdryM1RfD1kn8ZQnO7w7HQwt/f n6OQIib5MSNtWEI5kz2CTCxxhLtv3LqkskAv4Mmpw1ZNOoahVOul/TbawnMGBicUfmbUfeX5 /j/qIO+j7BRwuJBEfBNQoW3OyO9WIU7bLzWfmSV5W+9UE7AeTHXEbIExPtZb3CQAYhF9Im4F xVaepDshnJvjippJTfgH8vwIOqpYEk3WGYDW5pxruaWVhy9Q+8c9TfmES1qjemOjeEXliQ+n j8ns6PAJwIXuahvH7QY2AJDnP4WW0vvrhSHApzZVRX+rriGNnvkYao9UhRoQaePDLtQfl3D3 fT0CdRkJ4+ateXT0D8FEdL5P02cCAwEAAaM3MDUwJQYDVR0RBB4wHIEaYWxpLmZlc3NpQHVu aS10dWViaW5nZW4uZGUwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQA/nk208AFH IEcT8G8OT/olmcQMCHvgIsIrTGbPvlac/5ieANG7L1UjEBKv+THkcLTAH20Ca4XyplGiU2L2 8BSWNdtHNqOS8yA1Y8w1uxitcbYappbqtMeALITQTFyRQM70dzTatBB0JYVL6DE1KGs2g995 aLEax/S57zdx8axdHzCCAv8wggJooAMCAQICECvZHKWODjLVSWiWg0FHOegwDQYJKoZIhvcN AQEEBQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkp IEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4X DTA2MDIwNzIxMzIyOFoXDTA3MDIwNzIxMzIyOFowXTEOMAwGA1UEBBMFRmVzc2kxDDAKBgNV BCoTA0FsaTESMBAGA1UEAxMJQWxpIEZlc3NpMSkwJwYJKoZIhvcNAQkBFhphbGkuZmVzc2lA dW5pLXR1ZWJpbmdlbi5kZTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMFdryM1 RfD1kn8ZQnO7w7HQwt/fn6OQIib5MSNtWEI5kz2CTCxxhLtv3LqkskAv4Mmpw1ZNOoahVOul /TbawnMGBicUfmbUfeX5/j/qIO+j7BRwuJBEfBNQoW3OyO9WIU7bLzWfmSV5W+9UE7AeTHXE bIExPtZb3CQAYhF9Im4FxVaepDshnJvjippJTfgH8vwIOqpYEk3WGYDW5pxruaWVhy9Q+8c9 TfmES1qjemOjeEXliQ+nj8ns6PAJwIXuahvH7QY2AJDnP4WW0vvrhSHApzZVRX+rriGNnvkY ao9UhRoQaePDLtQfl3D3fT0CdRkJ4+ateXT0D8FEdL5P02cCAwEAAaM3MDUwJQYDVR0RBB4w HIEaYWxpLmZlc3NpQHVuaS10dWViaW5nZW4uZGUwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0B AQQFAAOBgQA/nk208AFHIEcT8G8OT/olmcQMCHvgIsIrTGbPvlac/5ieANG7L1UjEBKv+THk cLTAH20Ca4XyplGiU2L28BSWNdtHNqOS8yA1Y8w1uxitcbYappbqtMeALITQTFyRQM70dzTa tBB0JYVL6DE1KGs2g995aLEax/S57zdx8axdHzCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcN AQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcT CUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRp ZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBG cmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNv bTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYD VQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVy c29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA xKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkV cI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUq VIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMG A1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZy ZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJp dmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIX oUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydx VyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggNkMIIDYAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGlu ZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWlu ZyBDQQIQK9kcpY4OMtVJaJaDQUc56DAJBgUrDgMCGgUAoIIBwzAYBgkqhkiG9w0BCQMxCwYJ KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNjA0MjgxMzM5MjdaMCMGCSqGSIb3DQEJBDEW BBQsMatF4zKR4iLhmayAyrjn11IHkzBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4G CCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB hQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1 bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElz c3VpbmcgQ0ECECvZHKWODjLVSWiWg0FHOegwgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYD VQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECECvZHKWODjLVSWiWg0FH OegwDQYJKoZIhvcNAQEBBQAEggEAwSJO/IakGBvhhz0nVtFHE2ck49tY8Zda60s1DjOiIbKT VouozBVSFg0sSx6lzM3vzzSE02xEc9Ju0dnEMv8KAYB2ngIuMMujCzdzHUZi7IH6fefQpoVR m50gKfRnb6iLZoHTy+gfFfAkQ2LLWRwdgn9BXe2ewfIMDKgXouGZtIi74yDFkOH6EcUWanB8 KwCPhtYvDgtLw9SJfittoVkRCvK2/yGsRXxZARwNnk6UY9Lxr5cE1v9AmdZS6Sfc9FCVYe9w E+IgxPyD2iBORDwssUz+/JSHwmRBnuLq4amrakR5NB7YNExkwR1FVkee2AgXHvDnR4ZAiEsc cA124mP5HQAAAAAAAA== --------------ms090406090506000704030506-- --===============0842821330== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis --===============0842821330==-- From nsis-bounces@ietf.org Fri Apr 28 14:17:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZXWi-0000DZ-W8; Fri, 28 Apr 2006 14:17:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZXWh-0000DU-Lh for nsis@ietf.org; Fri, 28 Apr 2006 14:17:11 -0400 Received: from courier.cs.helsinki.fi ([128.214.9.1] helo=mail.cs.helsinki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZXWg-00020k-Cf for nsis@ietf.org; Fri, 28 Apr 2006 14:17:11 -0400 Received: from sbz-30.cs.helsinki.fi (sbz-30.cs.helsinki.fi [128.214.9.98]) (TLS: TLSv1/SSLv3,256bits,AES256-SHA) by mail.cs.helsinki.fi with esmtp; Fri, 28 Apr 2006 21:17:08 +0300 id 00070487.44525C24.00004041 Date: Fri, 28 Apr 2006 21:17:08 +0300 (EEST) From: Jukka MJ Manner To: nsis@ietf.org Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Subject: [NSIS] Some questions about the NAT/FW NSLP X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi, while reviewing the NAT NSLP, several questions emerged: A. Does proxy mode for DS (3.8.7.1) work if you have more than one inbound route? A multihomed NF. B. Should the TOS byte be also available as a field for matching traffic? C. Should there be a rule for modifying a packet? Now we "allow" or "deny", but about also "modify"? D. Should there be a "log" action to store information about certain packet flows? Cheers, Jukka _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Apr 28 14:24:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZXdv-0003uf-CO; Fri, 28 Apr 2006 14:24:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZXdu-0003uW-NB for nsis@ietf.org; Fri, 28 Apr 2006 14:24:38 -0400 Received: from courier.cs.helsinki.fi ([128.214.9.1] helo=mail.cs.helsinki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZXdu-0002ce-Ec for nsis@ietf.org; Fri, 28 Apr 2006 14:24:38 -0400 Received: from sbz-30.cs.helsinki.fi (sbz-30.cs.helsinki.fi [128.214.9.98]) (TLS: TLSv1/SSLv3,256bits,AES256-SHA) by mail.cs.helsinki.fi with esmtp; Fri, 28 Apr 2006 21:24:37 +0300 id 000704B1.44525DE5.00000518 Date: Fri, 28 Apr 2006 21:24:37 +0300 (EEST) From: Jukka MJ Manner To: nsis@ietf.org Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Subject: [NSIS] Proxy mode for QoS NSLP? X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi, Since the NAT/FW NSLP provides a so-called "proxy mode" for supporting non-NSIS correspondent nodes, should the QoS NSLP also have this feature? In the NF work, the local edge NAT/FW may be the "problem", and if the CN does not "talk NSIS", we still need to get e.g. holes open on the edge firewall. Similarly, for QoS the local network may be the bottleneck, and without support from the CN, we would still like to have QoS at least locally. Jukka _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Sun Apr 30 14:24:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FaGab-0001V0-Sa; Sun, 30 Apr 2006 14:24:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FaGaa-0001Uv-Ad for nsis@ietf.org; Sun, 30 Apr 2006 14:24:12 -0400 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FaGaX-0005jD-SH for nsis@ietf.org; Sun, 30 Apr 2006 14:24:12 -0400 Received: (qmail invoked by alias); 30 Apr 2006 18:24:06 -0000 Received: from p54987E80.dip.t-dialin.net (EHLO [192.168.2.33]) [84.152.126.128] by mail.gmx.net (mp040) with SMTP; 30 Apr 2006 20:24:06 +0200 X-Authenticated: #29516787 Message-ID: <445500BE.8040409@gmx.net> Date: Sun, 30 Apr 2006 14:23:58 -0400 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jukka MJ Manner Subject: Re: [NSIS] Proxy mode for QoS NSLP? References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.1 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Jukka, Hi QoS folks, In my review mails about the NATFW NSLP I also came across these type of questions. I will post them again (each in separate mails). Ciao Hannes Jukka MJ Manner wrote: > Hi, > > Since the NAT/FW NSLP provides a so-called "proxy mode" for supporting > non-NSIS correspondent nodes, should the QoS NSLP also have this feature? > > In the NF work, the local edge NAT/FW may be the "problem", and if the CN > does not "talk NSIS", we still need to get e.g. holes open on the edge > firewall. Similarly, for QoS the local network may be the bottleneck, and > without support from the CN, we would still like to have QoS at least > locally. > > Jukka > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Sun Apr 30 14:40:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FaGqE-00070m-Nb; Sun, 30 Apr 2006 14:40:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FaGqE-00070h-0U for nsis@ietf.org; Sun, 30 Apr 2006 14:40:22 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FaGqC-0006ov-Gl for nsis@ietf.org; Sun, 30 Apr 2006 14:40:21 -0400 Received: (qmail invoked by alias); 30 Apr 2006 18:40:18 -0000 Received: from p54987E80.dip.t-dialin.net (EHLO [192.168.2.33]) [84.152.126.128] by mail.gmx.net (mp019) with SMTP; 30 Apr 2006 20:40:18 +0200 X-Authenticated: #29516787 Message-ID: <44550491.3040004@gmx.net> Date: Sun, 30 Apr 2006 14:40:17 -0400 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jukka MJ Manner Subject: Re: [NSIS] Some questions about the NAT/FW NSLP References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Jukka, a short feedback: Jukka MJ Manner wrote: > Hi, > > while reviewing the NAT NSLP, several questions emerged: > > A. Does proxy mode for DS (3.8.7.1) work if you have more than one inbound > route? A multihomed NF. Yes, It works if the edge device is a NAT. With a firewall there might be a problem if the DS does not send an NSIS message. The edge-firewalls would have to use a firewall synchronization protocol. We noted this issue in the appendix of the draft. > > B. Should the TOS byte be also available as a field for matching traffic? I still remember your old issue https://kobe.netlab.nec.de/roundup/nsis-natfw-nslp/issue46. I personally would like to see it as an extension because I want to finish the document and it is, in some sense, an extension to the base protocol from a functionality point of view. > > C. Should there be a rule for modifying a packet? Now we "allow" or > "deny", but about also "modify"? What is the scenario? I guess you are talking about a "rewrite" DSCP value or something along these lines. > > D. Should there be a "log" action to store information about certain > packet flows? Not in the base protocol. There are several problems with it and it some sense that's what the Meeting NSLP does. If you read the M-NSLP draft then you will notice the types of problems you suddenly have to deal with. Ciao Hannes > > > Cheers, > Jukka > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Sun Apr 30 14:41:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FaGr9-0007H3-2z; Sun, 30 Apr 2006 14:41:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FaGr7-0007Fr-9m for nsis@ietf.org; Sun, 30 Apr 2006 14:41:17 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FaGr6-0006u5-R7 for nsis@ietf.org; Sun, 30 Apr 2006 14:41:17 -0400 Received: (qmail invoked by alias); 30 Apr 2006 18:41:15 -0000 Received: from p54987E80.dip.t-dialin.net (EHLO [192.168.2.33]) [84.152.126.128] by mail.gmx.net (mp034) with SMTP; 30 Apr 2006 20:41:15 +0200 X-Authenticated: #29516787 Message-ID: <445504CA.30702@gmx.net> Date: Sun, 30 Apr 2006 14:41:14 -0400 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "nsis@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.5 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Subject: [NSIS] Scoping X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi all, here is a comment regarding the CREATE message scoping (relevant for the QoS NSLP and the NATFW NSLP). Section 5.1.1. of http://www.ietf.org/internet-drafts/draft-ietf-nsis-qos-nslp-10.txt defines the 'Common header' and defines a 16-bit generic flags field. The 'S' flag is one of the defined flags: " SCOPING (S) - when set, indicates that the message is scoped and should not travel down the entire path but only as far as the next QNE (scope="next hop"). By default, this flag is not set (default scope="whole path"). " Interestingly, the QoS NSLP folks haven't defined anything that would be similar to the scoping we do. I wonder what the reason is. At the moment I don't see how the two approaches could be harmonized -- this might turn out to be a problem later when we decide to run the QoS NSLP and the NATFW NSLP together (one might, for example, remember the discussion we had with Jukka about DSCP rewriting: see https://kobe.netlab.nec.de/roundup/nsis-natfw-nslp/issue46) A comment regarding the 'P' flag in the Common NSLP header that refers to the proxy support for the REATE-PROXY and REA-PROXY message. Section 3.8.7 defines it. The flag is introduced into the Common NSLP header, which is, as its name indicates, common to all NSLPs. I think that this name is, however, wrong (or the description) since it is only common for all NATFW NSLP messages. I therefore suggest to change the text from: " 4.1 NSLP Header The NSLP header is common to all NSLPs and is the first part of all NSLP messages. " to: " 4.1 NSLP Header All GIST NSLP-Data objects for the NATFW NSLP MUST contain this Common Header as the first 32 bits of the object (this is not the same as the GIST Common Header). " Is my observation correct or do I miss something here? Ciao Hannes _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Sun Apr 30 14:45:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FaGuk-0000C1-Rw; Sun, 30 Apr 2006 14:45:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FaGuk-0000Bw-29 for nsis@ietf.org; Sun, 30 Apr 2006 14:45:02 -0400 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FaGuj-000767-A9 for nsis@ietf.org; Sun, 30 Apr 2006 14:45:02 -0400 Received: (qmail invoked by alias); 30 Apr 2006 18:44:59 -0000 Received: from p54987E80.dip.t-dialin.net (EHLO [192.168.2.33]) [84.152.126.128] by mail.gmx.net (mp035) with SMTP; 30 Apr 2006 20:44:59 +0200 X-Authenticated: #29516787 Message-ID: <445505A9.7040607@gmx.net> Date: Sun, 30 Apr 2006 14:44:57 -0400 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: NSIS Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 8d89ee9312a95de8ee48d1c94511f1bb Subject: [NSIS] NATFW NSLP Issues X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi all, after I reviewed the other NSIS documents I tought about some aspects of the NATFW NSLP draft again and I came across a few issues: (Btw, there some QoS related aspects in there as well.) * Section 2.7 talks about IPv4/IPv6 traversal but gives the impression that there is only NAT-PT and it would not imply additional considerations for the NATFW NSLP. I do agree that there are no problems for the NATFW NSLP but I think that this is mainly due to the functionality provided by GIST. I wonder whether more text is needed to capture this fact. * Section 2.8 talks about "multihomed networks". When I used the term "multihomed network" in the past then I referred to networks that have multiple upstream providers. Figure 9 would refer to a multi-homed host in my terminology. The roles of NI/NR are reversed in Section 2.8. Furthermore, I don't think that the scenario depicted in Section 2.9 is challenging. * In Section 3.2 I noticed a terminology confusion since we use the term "NI" also for the DR in the REA mode. Maybe I am the only one having problems with the terminology. * Section 3.4 talks about Session Lifetime calculation. Some of the parameters the calculation are not available before the session started. Could this be a problem? * The QoS NSLP spec does not mandate protocol operations similar to those described in Section 3.8. Why do we need them? * I suggest to make it very clear that the REA mode description only allows NSIS signaling to traverse and does not create a true NAT binding very early in the text. The text about Proxy-REA starts much later in the draft but I think it is really important from a deployment point of view. * The QoS NSLP draft analyses route changes and mobility in some level of detail (see Section 5.2.5 of the http://www.ietf.org/internet-drafts/draft-ietf-nsis-qos-nslp-10.txt). The NATFW NSLP aspects are a little bit different than the QoS NSLP issues with regard to this aspect. Section 3.10 (Reacting to Route Changes) talks about this aspect. I would like to know whether people happy with the text? * In Section 3.8.7.2 (Proxy for a Data Receiver) we assume that the NI knows whether the message will be able to travel all the way to the NR. Hence, we require the NI to decide whether it wants to use CREATE or CREATE-PROXY messages. I thought that the QoS NSLP guys do not make this assumption. * The usage of the NATFW_DTINFO object might require a more detailed description. I particularly think that the case where more than one NAT is present along the path is not addressed appropriately. Text is required to state when the NATFW_DTINFO object has to be updated with the information obtained from a NAT binding allocated by each NAT. The 'NATFW_DTINFO_IPv4' has to be mandatory for the proxy REA since otherwise the CREATE message, which is sent by the edge-NAT towards the DR, does not have enough information to establish a binding at a NAPT. Here is the text from the draft: " The NI+ MAY include a NATFW_DTINFO_IPv4 object in the REA message ^^^^ when using the LE-MRM. The LE-MRM does not include enough information for some types of NATs (basically, those NATs which also translate port numbers) to perform the address translation. This information is provided in the NATFW_DTINFO_IPv4 (see Section 4.2.7). This information SHOULD include at least the 'dst port number' and 'protocol' fields, in the DTInfo object as these may be required by en-route NATs, depending on the type of the NAT. " I think that the DR MUST include the NATFW_DTINFO_IPv4 object in the REA message in order to provide enough information for a NAPT along the path towards the edge-NAT to make a reasonable decision. Hence, a MAY is not enough. The NATFW_DTINFO currently talks about IPv4 only. I think that the data sender's address could also an IPv6 address and here is the scenario: DSv6--|Edge-NAT_v4/v6_GW|--v4--|FW|--v4--|v4/v6_NAT_GW|--v6--|DRv4/v6| This requires a v6 DS address in the DTINFO object. Furthermore, I would like to comment the content of the NATFW_DTINFO_IPv4 object itself. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |I|P|S| reserved | sender prefix | protocol | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : dst port number | src port number : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : IPsec SPI : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | data sender's IPv4 address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 29: Data Terminal IPv4 Address Object The flags are: o I: I=1 means that 'protocol' should be interpreted. o P: P=1 means that 'dst port number' and 'src port number' are present and should be interpreted. The 'dst port number' and the 'src port number' always appear in pairs. Why cannot I just filter based on the DR's dst port number? o S: S=1 means that SPI is present and should be interpreted. For allow incoming IPsec traffic it is necessary to define Source/Dst IP address, SPI, Protocol Type (AH/ESP). AH and ESP is defined via the protocol field. Should we mention this somewhere or is it already obvious? There are two objects that define packet filtering capabilities: DTINFO and ICMP. It is fine for me to split the functionality into two attributes (as it is done today). Is this OK for everyone? * Terminology problem: We use the term 'NATFW_DTINFO_IPv4' and 'Data terminal information object' interchangable. This makes it quite hard to find the correct text in the draft. I am not sure whether we should change it. * Instead of putting port information into the MRI the port info is used in the 'NATFW_DTINFO_IPv4' object. This prevents GIST aware NAT traversal to work properly. Is this a problem? I wonder what the impact for NSIS unaware NAT traversal is. * I am not sure about the MRI to IP Src/Dst relationship. In some cases it is not quite obvious what to put, for example, in a CREATE message sent from the edge-NAT towards the DR. We could use the DS IP address, the IP address at the public side of the NAT, the IP address at the private side of the NAT. This might be a GIST question. * Appendix B: DR behind a Firewall I thought again about the DR behind a firewall scenario and I came to the conclusion that it is not as bad as it might seem to be. Here are my thoughts: If the DR creates policy rules (using proxy REA) at the edge-FW then a NSIS unaware DS is not able to let its data packets flow through the firewall (since they will hit the wrong firewall at the DR side where the policy rules for the data traffic are not created and the traffic is therefore blocked). The edge-FW might, however, know that its own network offers such a deployment environment and might provide the end host with some information back to the DR. I could imagine something like "This network is multi-homed. You might encounter problems." or "This network is multi-homed but state-synchronized.". If the DS is NSIS aware then a subsequent CREATE hits Firewall 2 (the proxy REA established policy rules at Firewall 1). This is, however, not a problem since this message might be able to traverse the firewall towards the DR anyway. The DR can then decide whether he honors the request. As such, I think that the situation with a DR behind multiple FWs is not so dramatic as it might seem to be. What do you think? We could rewrite some paragraphs in Appendix B. * Extensibility of the Common NSLP object header format Section 4.2 of the NATFW NSLP addresses the extensiblity of the Common NSLP object header format. We might want to state that the format is the same as the one in Section 5.1.3 of http://www.ietf.org/internet-drafts/draft-ietf-nsis-qos-nslp-10.txt. There is, however, a small difference. The AB=11 functionality provided by the draft-ietf-nsis-qos-nslp-10.txt is not offered by the NATFW NSLP: http://www.ietf.org/internet-drafts/draft-ietf-nsis-nslp-natfw-10.txt " AB=11 ("Refresh"): If the object is not understood, it should be incorporated into the locally stored signaling application state for this flow/session, forwarded in any resulting message, and also used in any refresh or repair message which is generated locally. " I gave the QoS NSLP authors the feedback that I think that the semantic of the "Refresh" behavior is strange. We have excluded it but I think we should make sure that the two NSLPs are aligned. What do the QoS authors think? * TRACE Message I noticed that the IANA registry for the 'trace type' field is missing. Currently, only two values are defined (0x01 and 0x02) but there is plenty of room for extensibility. I think that there is a need to create a registry. Generating an error if a node does not understand a particular extension might make it difficult to offer some extensions in the future. Section 4.2.8 says: " The NATFW_TRACE object may contain zero or more identifiers of visited NATFW NSLP peers. However, it is only possible to store a single type of identifier, either IPv4 or IPv6 addresses. " I think that an NSIS aware NAT/Firewall adds both interface IP addresses(incoming and outgoing). Would it be useful to use an identifier for the NSIS node (e.g., generated locally at the NSIS node, to identify a node again in case of route changes and mobility). Would we like to impose a restriction regarding a single type of identifier? (only possible to store a single type of identifier) As currently specified, the mechanism cannot be used in a v4/v6 environment. Given that the trace object is quite generic I think that it should have the following shape: " +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | trace type | hop count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Trace Values : : ... : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ " Btw, I wonder whether we actually need to define a separate message rather than attaching a Trace Object to an existing message (e.g., a CREATE) and then the corresponding debugging information is created. This would make the message immediately useful for all messages (CREATE, REA, CREATE-Proxy, REA-Proxy). This issue is just something for discussion. * Usage of the "External Address Object" The RESPONSE message may optionally carry an External address object. Below you can find a modified version of Figure 14 of http://www.ietf.org/internet-drafts/draft-ietf-nsis-nslp-natfw-11.txt NI Private Network NF Public Internet NR | | | | CREATE | | |----------------------------->| | | | | | | | | | CREATE | | |--------------------------->| | | | | | RESPONSE | | | (External Address Object) | | RESPONSE |<---------------------------| | (External Address Object) | | |<-----------------------------| | | | | | | | Figure 14: CREATE message flow with success RESPONSE Now, the following question arises: Who has to add the External Address Object. I would argue that NR MUST add it. The NF MUST verify that the information is correct. Only the edge NF can truely verify it. That's all for now. Ciao Hannes _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Sun Apr 30 14:45:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FaGuz-0000D9-42; Sun, 30 Apr 2006 14:45:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FaGuy-0000D4-85 for nsis@ietf.org; Sun, 30 Apr 2006 14:45:16 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FaGux-00076P-Rl for nsis@ietf.org; Sun, 30 Apr 2006 14:45:16 -0400 Received: (qmail invoked by alias); 30 Apr 2006 18:45:15 -0000 Received: from p54987E80.dip.t-dialin.net (EHLO [192.168.2.33]) [84.152.126.128] by mail.gmx.net (mp039) with SMTP; 30 Apr 2006 20:45:15 +0200 X-Authenticated: #29516787 Message-ID: <445505B9.1080400@gmx.net> Date: Sun, 30 Apr 2006 14:45:13 -0400 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ali Fessi Subject: Re: [NSIS] NATFW NSLP; attack in Section 5.10.1 is not specific to NATs References: <44520B98.7070603@uni-tuebingen.de> <44521B0F.2060307@uni-tuebingen.de> In-Reply-To: <44521B0F.2060307@uni-tuebingen.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: nsis , Robert Hancock X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Ali, there is no big motivation behind the mentioned scenario. It is just an end host behind a NAT that moves around and uses the NATFW NSLP protocol for NAT and Firewall signaling. This end host needs to update its NAT binding to continue to receive the data traffic at the new care-of-address. For some reason you got jumped to mobility protocols. We, however, need to ensure that the text does not give you a wrong impression. Ciao Hannes Ali Fessi wrote: > Hi again, > > Ali Fessi wrote: > >> Hi Robert, >> >> Hancock, Robert wrote: >> >>> hi, >>> >>> [this is not really a follow up to Ali's question but another >>> issue on 5.10:] >>> >>> I found at least the introduction of the scenario in 5.10 a little >>> difficult to follow from a motivational point of view. >>> How common is it for IP layer mobility to be used purely on the >>> private side of a NAT? (I'm not saying that it's impossible, >>> just that I tend to think of NATs as reducing the need for >>> renumbering in small networks, where you wouldn't use IP >>> mobility in the first place.) >> >> >> >> i'm not an expert in mobility; but i think, if Hierarchical MIP is >> used, then the HMIP anchor point would basically behaves as a NAT. So >> the scenario described in this section would fit well to HMIP. >> >> Maybe someone else can provide a better explanation?! > > > i've just thought about it a bit more. > > the setup with HMIP is similar; but with HMIP there is no need for NSIS > NATFW NSLP. Instead, Mobile Nodes send their Mobile IP "Binding Updates" > straightforward to the HMIP anchor point. > > So, the motivation for scenario 5.10 is still unclear. > > Cheers, > Ali > > > ------------------------------------------------------------------------ > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Sun Apr 30 14:45:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FaGvb-0000hU-Eu; Sun, 30 Apr 2006 14:45:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FaGva-0000hP-Ce for nsis@ietf.org; Sun, 30 Apr 2006 14:45:54 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FaGvZ-000787-V4 for nsis@ietf.org; Sun, 30 Apr 2006 14:45:54 -0400 Received: (qmail invoked by alias); 30 Apr 2006 18:45:53 -0000 Received: from p54987E80.dip.t-dialin.net (EHLO [192.168.2.33]) [84.152.126.128] by mail.gmx.net (mp027) with SMTP; 30 Apr 2006 20:45:53 +0200 X-Authenticated: #29516787 Message-ID: <445505DF.9040109@gmx.net> Date: Sun, 30 Apr 2006 14:45:51 -0400 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Hancock, Robert" Subject: Re: [NSIS] NATFW NSLP; attack in Section 5.10.1 is not specific to NATs References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Cc: nsis X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Robert, Hancock, Robert wrote: > hi, > > [this is not really a follow up to Ali's question but another > issue on 5.10:] > > I found at least the introduction of the scenario in 5.10 a > little difficult to follow from a motivational point of view. > How common is it for IP layer mobility to be used purely on > the private side of a NAT? (I'm not saying that it's impossible, > just that I tend to think of NATs as reducing the need for > renumbering in small networks, where you wouldn't use IP > mobility in the first place.) I agree with you that Section 5.10 should not give the impression that it is a mobility solution. All the text should indicate is that when a host behind a NAT moves then the contact address towards its peer does not change. An adversary can modify a NAT binding to redirect traffic. > > A more significant point is that the mitigation described on > page 81 (second sentence) seems to depend on the end host being > able to prove session ownership directly to the NAT, but the > facilities available mainly apply to peer-peer relationships. > Is the last sentence here actually correct? You are referring to this sentence: " The NSIS NATFW NSLP aware NAT MUST authorize the end host to insure that the messages are indeed belonging to the previously established session. " Well, it is up to us to specify things in a way that either ownership is shown over multiple NSIS hops or not. Given the past discussions regarding the session identifier and usage of cryptgraphic ownership I got the impression that this is not a strong requirement. Ciao Hannes > > r. > > >>-----Original Message----- >>From: Ali Fessi [mailto:ali.fessi@uni-tuebingen.de] >>Sent: 20 April 2006 23:12 >>To: nsis >>Subject: [NSIS] NATFW NSLP; attack in Section 5.10.1 is not >>specific to NATs >> >> >>Hi, >> >>the attack described in Section 5.10.1 (Misuse of mobility in NAT >>handling) is actually not specific to NATs. Firewalls need also to >>update their policy rules to support mobility. >> >>I would modify the description of the attack accordingly and call it >>"Miuse of Mobility Support" or something like this. >> >>Also: in the figure 42, the end host does not necessarly need >>to be on >>the private side of the network. a Mobile Node can be on both >>sides of >>the network; and in both cases, policy rules need to be updated. >> >>So there shouldn't be a difference between the public and the private >>network sides. >> >>Regards, >>Ali >>-- >>Ali Fessi >>University of Tuebingen, Germany >> >>_______________________________________________ >>nsis mailing list >>nsis@ietf.org >>https://www1.ietf.org/mailman/listinfo/nsis >> > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Sun Apr 30 14:49:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FaGzK-0001wv-M5; Sun, 30 Apr 2006 14:49:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FaGzJ-0001wq-9r for nsis@ietf.org; Sun, 30 Apr 2006 14:49:45 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FaGzI-0007Fd-RE for nsis@ietf.org; Sun, 30 Apr 2006 14:49:45 -0400 Received: (qmail invoked by alias); 30 Apr 2006 18:49:43 -0000 Received: from p54987E80.dip.t-dialin.net (EHLO [192.168.2.33]) [84.152.126.128] by mail.gmx.net (mp039) with SMTP; 30 Apr 2006 20:49:43 +0200 X-Authenticated: #29516787 Message-ID: <445506C6.5000608@gmx.net> Date: Sun, 30 Apr 2006 14:49:42 -0400 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Hancock, Robert" Subject: Re: [NSIS] NATFW Session and address lifetime References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Cc: nsis X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Robert, Hancock, Robert wrote: > hi, > > some comments on the session and address lifetime issue, see > sections 3.4 and 5.11 (in particular) [nb these sections should > probably refer to each other]. > > I think the main threat here is that an IP address that was > validly assigned to one node which then set up signalling > sessions referring to it may get validly reassigned to another > node which then re-uses those sessions. > > One solution to this is indeed data origin authentication as > mentioned in the text. However, I'm sceptical that data origin > authentication could ever be used in practice to address this > sort of issue (it would require the address allocation process > and protocol to include time-bounded credentials for the ownership > of an address which everyone else in the network was able to > verify). Yes; We are not suggesting this solution since this document is about non-crypgraphic data traffic filtering. If this threat is a concern then protocols that provide data origin authentication are more applicable. However, it should at least be possible to ensure that > the node initiating a signalling session gave it a lifetime that > was smaller than the remaining validity of any dynamically > allocated address. That way, by the time the address is available > for re-allocation, any signalling sessions would have already > timed out. I would propose to add this to section 3.4. That's certainly a good hint. > > Some lesser points on 3.4: > - (page 28): the lifetime value should ideally take some account of load > on the signalling plane. Short lifetimes imply more frequent > signalling messages. True. > - (page 28): the lifetime value should also take account of the > acceptable > time for a signalling session to be present after it is no longer > actually needed. (For example, if the existence of the session > implies a monetary cost and teardown cannot be guaranteed, shorter > lifetimes would be preferable.) Fine. > - (page 29): can messages be rejected on the basis of the lifetime > being too long only when a session is first created, or also on > refresh? Also on a refresh. We need to state that more precisely. > - (page 29): it strikes me that as well as the 'lifetime too big' > error there should be a 'lifetime too small' error. if someone initiates > a session with a lifetime of 1 second, i am compelled to use a lifetime > no longer than that on the downstream segments of the path. But that > lifetime may cause excessive signalling load. It would be good to > indicate what approaches are available to a NATFW implementation to > handle this kind of overload. Sounds reasonable to me. > - (page 29 last paragraph): i don't understand which value is being > referred to as the 'proposed' value. I guess you refer to the following sentences: " Each NSLP forwarder processes the RESPONSE message, reads and stores the granted lifetime value. The forwarders MUST accept the granted lifetime, as long as this value is less than or equal to their proposed value. " With "proposed" value we refer to the value that is received by the NATFW NSLP forwarder when computing the lifetime of the session. It might either accept the received lifetime or lower it. We could be a bit more specific when we talk about the "proposed" value. Ciao Hannes > > cheers, > > r. > > _______________________________________________ > 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