From nsis-bounces@ietf.org Mon Oct 01 03:27:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcFet-0003iC-GD; Mon, 01 Oct 2007 03:25:39 -0400 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1IcFes-0003i6-Hh for nsis-confirm+ok@megatron.ietf.org; Mon, 01 Oct 2007 03:25:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcFes-0003hy-87 for nsis@ietf.org; Mon, 01 Oct 2007 03:25:38 -0400 Received: from smtp0.netlab.nec.de ([195.37.70.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IcFel-0007AI-NN for nsis@ietf.org; Mon, 01 Oct 2007 03:25:38 -0400 Received: from localhost (atlas1.office [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id D62A62802DC77 for ; Mon, 1 Oct 2007 09:25:13 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office) Received: from smtp0.netlab.nec.de ([127.0.0.1]) by localhost (atlas1.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wzZDAPyMxRDf for ; Mon, 1 Oct 2007 09:25:13 +0200 (CEST) Received: from mx1.office (mx1.office [10.1.1.23]) by smtp0.netlab.nec.de (Postfix) with ESMTP id B5AB72802DC74 for ; Mon, 1 Oct 2007 09:25:08 +0200 (CEST) Received: from mx1.office ([10.1.1.23]) by mx1.office with Microsoft SMTPSVC(6.0.3790.3959); Mon, 1 Oct 2007 09:25:08 +0200 Received: from [10.1.1.109] ([10.1.1.109]) by mx1.office over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 1 Oct 2007 09:25:08 +0200 Mime-Version: 1.0 (Apple Message framework v752.3) To: nsis Message-Id: <5BAA26B6-AEB2-4539-9FA5-CCF418F6A051@netlab.nec.de> References: <8A5B41AB-2766-4D54-9208-6E724F2B3278@netlab.nec.de> From: Martin Stiemerling Subject: Fwd: [NSIS] Call for consensus draft-loughney-nsis-ext-02.txt as WG document? Date: Mon, 1 Oct 2007 09:25:06 +0200 X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 01 Oct 2007 07:25:08.0490 (UTC) FILETIME=[31F5E6A0:01C803FC] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7268a2980febc47a9fa732aba2b737ba 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="===============1618440992==" Errors-To: nsis-bounces@ietf.org --===============1618440992== Content-Type: multipart/alternative; boundary=Apple-Mail-1-315425539 --Apple-Mail-1-315425539 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hi all, Just a friendly reminder about the call for consensus. A short summary of the draft's intention, for people not that familiar with this draft: The intention of this draft is to collect information from the NSIS WG about how GIST, QoS NSLP, and NAT NSLP can be extended. This information should guide future drafts on how you do a good extension to the different protocols and probably even more important to where add those extensions. E.g., whether a new feature should go to as a GIST extension, as a NSLP extension, or new NSLP. Thanks, Martin Anfang der weitergeleiteten E-Mail: > Von: Martin Stiemerling > Datum: 27. September 2007 17:14:45 MESZ > An: nsis > Betreff: [NSIS] Call for consensus draft-loughney-nsis-ext-02.txt > as WG document? > > Hi all, > > Some time ago, John wrote the draft draft-loughney-nsis-ext-02.txt > discussing the extensibility of NSIS. > > It has been discussed on the mailing list, plus during the IETF > meetings and it seems to be a good shape to become a WG document. > > Therefore, I would like to propose draft-loughney-nsis-ext-02.txt > becoming a WG draft by now. > > This requires consensus of WG to do so. > > Please send your opinion on whether you like to see draft-loughney- > nsis-ext-02.txt as WG document or not to the NSIS mailing list by > no later than Oct 4th 5pm PST. > > Thanks, > > Martin > > stiemerling@netlab.nec.de > NEC Laboratories Europe - Network Research Division > > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, > London W3 6BL | Registered in England 2832014 > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis stiemerling@netlab.nec.de NEC Laboratories Europe - Network Research Division NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 --Apple-Mail-1-315425539 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Hi all,

Just a friendly reminder = about the call for consensus.

A short summary of the = draft's intention, for people not that familiar with this = draft:

The = intention of this draft is to collect information from the NSIS WG about = how GIST, QoS NSLP, and NAT NSLP can be extended. This information = should guide future drafts on how you do a good extension to the = different protocols and probably even more important to where add those = extensions. E.g., whether a=A0new feature should go to as a GIST = extension, as a NSLP extension, or new NSLP.=A0

Thanks,

=A0 = Martin

Anfang der weitergeleiteten E-Mail:

Von: = Martin Stiemerling <stiemerling@netlab.nec.de>= ;
Datum: 27. September 2007 17:14:45 = MESZ
An: nsis <nsis@ietf.org>
Betreff: = [NSIS] Call for consensus draft-loughney-nsis-ext-02.txt = as WG document?

Hi all,

Some = time ago, John wrote the draft draft-loughney-nsis-ext-02.txt discussing = the extensibility of NSIS.

It has been discussed on the = mailing list, plus during the IETF meetings and it seems to be a good = shape to become a WG document.

Therefore, I would like to = propose draft-loughney-nsis-ext-02.txt becoming a WG draft by = now.

This requires consensus of WG to do so.

Please = send your opinion on whether you like to see = draft-loughney-nsis-ext-02.txt as WG document or not to the NSIS mailing = list by no later than Oct 4th 5pm PST.


=A0 = Martin

stiemerling@netlab.nec.de
NEC Laboratories Europe - Network Research = Division

NEC Europe Limited | Registered Office: NEC House, 1 = Victoria Road, London W3 6BL | Registered in England 2832014


nsis mailing list

stiemerling@netlab.nec.de
NEC Laboratories Europe - Network Research = Division

NEC Europe = Limited |=A0Registered Office: NEC House, 1 Victoria Road, London W3 6BL = |=A0Registered in England 2832014

=

= --Apple-Mail-1-315425539-- --===============1618440992== 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 --===============1618440992==-- From nsis-bounces@ietf.org Mon Oct 01 03:28:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcFhi-0007SX-Ki; Mon, 01 Oct 2007 03:28:34 -0400 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1IcFhi-0007SN-7y for nsis-confirm+ok@megatron.ietf.org; Mon, 01 Oct 2007 03:28:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcFhh-0007SF-UZ for nsis@ietf.org; Mon, 01 Oct 2007 03:28:33 -0400 Received: from smtp0.netlab.nec.de ([195.37.70.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IcFhf-0007FL-D7 for nsis@ietf.org; Mon, 01 Oct 2007 03:28:33 -0400 Received: from localhost (atlas1.office [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id F2B6E2802DC76 for ; Mon, 1 Oct 2007 09:28:30 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office) Received: from smtp0.netlab.nec.de ([127.0.0.1]) by localhost (atlas1.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w-Qxl7BinSuM for ; Mon, 1 Oct 2007 09:28:30 +0200 (CEST) Received: from mx1.office (mx1.office [10.1.1.23]) by smtp0.netlab.nec.de (Postfix) with ESMTP id D34522802DC75 for ; Mon, 1 Oct 2007 09:28:25 +0200 (CEST) Received: from mx1.office ([10.1.1.23]) by mx1.office with Microsoft SMTPSVC(6.0.3790.3959); Mon, 1 Oct 2007 09:28:25 +0200 Received: from [10.1.1.109] ([10.1.1.109]) by mx1.office over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 1 Oct 2007 09:28:25 +0200 Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <8A5B41AB-2766-4D54-9208-6E724F2B3278@netlab.nec.de> References: <8A5B41AB-2766-4D54-9208-6E724F2B3278@netlab.nec.de> Message-Id: <91AD3ED0-DA5E-46CB-81CD-CBE58D67BE96@netlab.nec.de> From: Martin Stiemerling Subject: Re: [NSIS] Call for consensus draft-loughney-nsis-ext-02.txt as WG document? Date: Mon, 1 Oct 2007 09:28:25 +0200 To: nsis X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 01 Oct 2007 07:28:25.0584 (UTC) FILETIME=[A7700F00:01C803FC] X-Spam-Score: 0.0 (/) X-Scan-Signature: d890c9ddd0b0a61e8c597ad30c1c2176 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="===============0910082641==" Errors-To: nsis-bounces@ietf.org --===============0910082641== Content-Type: multipart/alternative; boundary=Apple-Mail-2-315624415 --Apple-Mail-2-315624415 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed [ writing WG chair's hat off] This draft is extremely useful for people trying to extend parts of NSIS in the future. Especially, for people not having participated during the times when NSIS has been made. Therefore, I would like to see this draft as WG document. Martin Am 27.09.2007 um 17:14 schrieb Martin Stiemerling: > Hi all, > > Some time ago, John wrote the draft draft-loughney-nsis-ext-02.txt > discussing the extensibility of NSIS. > > It has been discussed on the mailing list, plus during the IETF > meetings and it seems to be a good shape to become a WG document. > > Therefore, I would like to propose draft-loughney-nsis-ext-02.txt > becoming a WG draft by now. > > This requires consensus of WG to do so. > > Please send your opinion on whether you like to see draft-loughney- > nsis-ext-02.txt as WG document or not to the NSIS mailing list by > no later than Oct 4th 5pm PST. > > Thanks, > > Martin > > stiemerling@netlab.nec.de > NEC Laboratories Europe - Network Research Division > > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, > London W3 6BL | Registered in England 2832014 > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis stiemerling@netlab.nec.de NEC Laboratories Europe - Network Research Division NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 --Apple-Mail-2-315624415 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1
[ writing WG chair's hat = off]

This = draft is extremely useful for people trying to extend parts of NSIS in = the future. Especially, for people not having participated during the = times when NSIS has been made.=A0

Therefore, I would like to = see this draft as WG document.=A0

=A0 = Martin

Am 27.09.2007 um 17:14 schrieb Martin = Stiemerling:

Hi all,

Some time ago, John wrote = the draft=A0draft-loughney-nsis-ext-02.txt discussing the extensibility = of NSIS.=A0

It = has been discussed on the mailing list, plus during the IETF meetings = and it seems to be a good shape to=A0become a WG = document.=A0

Therefore, I would like to = propose=A0draft-loughney-nsis-ext-02.txt becoming a WG draft by = now.=A0

This = requires consensus of WG to do so.=A0

Please send your opinion on = whether you like to see=A0draft-loughney-nsis-ext-02.txt as WG document = or not to the NSIS mailing list by no later than Oct 4th 5pm = PST.

Thanks,

=A0 = Martin

stiemerling@netlab.nec.de
NEC Laboratories Europe - Network Research = Division

NEC Europe = Limited |=A0Registered Office: NEC House, 1 Victoria Road, London W3 6BL = |=A0Registered in England 2832014

=

nsis mailing list

stiemerling@netlab.nec.de
NEC Laboratories Europe - Network Research = Division

NEC Europe = Limited |=A0Registered Office: NEC House, 1 Victoria Road, London W3 6BL = |=A0Registered in England 2832014

=

= --Apple-Mail-2-315624415-- --===============0910082641== 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 --===============0910082641==-- From nsis-bounces@ietf.org Mon Oct 01 05:53:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcHwf-0003sB-6f; Mon, 01 Oct 2007 05:52:09 -0400 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1IcHwe-0003s0-BL for nsis-confirm+ok@megatron.ietf.org; Mon, 01 Oct 2007 05:52:08 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcHwe-0003rr-0V for nsis@ietf.org; Mon, 01 Oct 2007 05:52:08 -0400 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IcHwd-0005zi-EZ for nsis@ietf.org; Mon, 01 Oct 2007 05:52:07 -0400 Received: (qmail invoked by alias); 01 Oct 2007 09:52:05 -0000 Received: from socks-ic-ext.mch.sbs.de (EHLO [194.138.17.187]) [194.138.17.187] by mail.gmx.net (mp055) with SMTP; 01 Oct 2007 11:52:05 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+lNgEzqOOlQrJG4BANg47VH4McNFmPnrciM0NNot PGHrTv6mfsce2a Message-ID: <4700C345.1070801@gmx.net> Date: Mon, 01 Oct 2007 11:52:05 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Martin Stiemerling Subject: Re: [NSIS] Call for consensus draft-loughney-nsis-ext-02.txt as WG document? References: <8A5B41AB-2766-4D54-9208-6E724F2B3278@netlab.nec.de> In-Reply-To: <8A5B41AB-2766-4D54-9208-6E724F2B3278@netlab.nec.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: 4b800b1eab964a31702fa68f1ff0e955 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 Martin I agree that such a document is useful. There are, however, a few follow-up questions: a) When do you write such a document? b) What is the scope of the document? Regarding (a): In the RADEXT and the DIME working group we are currently producing documents that provide sort of design guidelines, see http://www.ietf.org/internet-drafts/draft-ietf-dime-app-design-guide-02.txt http://www.ietf.org/internet-drafts/draft-ietf-radext-design-00.txt These two documents are written based on the experience that something went wrong regarding the way how people extended the protocol. Maybe it would have been better to write these documents earlier. Now we obviously have much more bad examples to write about. Regarding (b): Should the document focus only on GIST or should it also cover the NSLPs? What happens if you define a new NSLP - do you revise the document? How far can this document go beyond the already described information found in GIST, and the NSLPs? I could, for example, imagine that someone gives details about the common design aspects where you could essentially "steal" text from existing NSLPs. Ciao Hannes Martin Stiemerling wrote: > Hi all, > > Some time ago, John wrote the draft draft-loughney-nsis-ext-02.txt > discussing the extensibility of NSIS. > > It has been discussed on the mailing list, plus during the IETF > meetings and it seems to be a good shape to become a WG document. > > Therefore, I would like to propose draft-loughney-nsis-ext-02.txt > becoming a WG draft by now. > > This requires consensus of WG to do so. > > Please send your opinion on whether you like to see > draft-loughney-nsis-ext-02.txt as WG document or not to the NSIS > mailing list by no later than Oct 4th 5pm PST. > > Thanks, > > Martin > > stiemerling@netlab.nec.de > NEC Laboratories Europe - Network Research Division > > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, > London W3 6BL | Registered in England 2832014 > > > > ------------------------------------------------------------------------ > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://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 Oct 01 05:57:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcI12-0005gi-Mq; Mon, 01 Oct 2007 05:56:40 -0400 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1IcI11-0005fW-4O for nsis-confirm+ok@megatron.ietf.org; Mon, 01 Oct 2007 05:56:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcI10-0005fO-Qy for nsis@ietf.org; Mon, 01 Oct 2007 05:56:38 -0400 Received: from mail.uc.pt ([193.137.200.37] helo=mail-1.ci.uc.pt) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IcI0u-0004J5-El for nsis@ietf.org; Mon, 01 Oct 2007 05:56:38 -0400 Received: from mail-1.ci.uc.pt (mail-1.ci.uc.pt [127.0.0.1]) by localhost.mail.uc.pt (Postfix) with ESMTP id 45EB925F6F3; Mon, 1 Oct 2007 10:56:17 +0100 (WEST) Received: from [172.16.56.150] (unknown [147.67.4.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail-1.ci.uc.pt (Postfix) with ESMTP id 9BDB925F6F2; Mon, 1 Oct 2007 10:56:16 +0100 (WEST) Message-ID: <4700C440.6060907@dei.uc.pt> Date: Mon, 01 Oct 2007 10:56:16 +0100 From: =?ISO-8859-1?Q?Lu=EDs_Cordeiro?= User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Martin Stiemerling Subject: Re: [NSIS] Call for consensus draft-loughney-nsis-ext-02.txt as WG document? References: <8A5B41AB-2766-4D54-9208-6E724F2B3278@netlab.nec.de> In-Reply-To: <8A5B41AB-2766-4D54-9208-6E724F2B3278@netlab.nec.de> X-Spam-Score: 2.6 (++) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac 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="===============1285476349==" Errors-To: nsis-bounces@ietf.org --===============1285476349== Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi all,

I think that this draft is very important for NSIS. Extensions to protocols are a part of our work to improve Internet, and so I think that it is very important to have a document that helps everyone to do it.

BR,
Luís Cordeiro

Martin Stiemerling wrote:
Hi all,

Some time ago, John wrote the draft draft-loughney-nsis-ext-02.txt discussing the extensibility of NSIS. 

It has been discussed on the mailing list, plus during the IETF meetings and it seems to be a good shape to become a WG document. 

Therefore, I would like to propose draft-loughney-nsis-ext-02.txt becoming a WG draft by now. 

This requires consensus of WG to do so. 

Please send your opinion on whether you like to see draft-loughney-nsis-ext-02.txt as WG document or not to the NSIS mailing list by no later than Oct 4th 5pm PST.

Thanks,

  Martin

NEC Laboratories Europe - Network Research Division

NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014

 


_______________________________________________
nsis mailing list
nsis@ietf.org
https://www1.ietf.org/mailman/listinfo/nsis
--===============1285476349== 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 --===============1285476349==-- From nsis-bounces@ietf.org Mon Oct 01 06:01:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcI50-0007Ah-CH; Mon, 01 Oct 2007 06:00:46 -0400 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1IcI4z-00079x-C7 for nsis-confirm+ok@megatron.ietf.org; Mon, 01 Oct 2007 06:00:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcI4z-00079J-0v for nsis@ietf.org; Mon, 01 Oct 2007 06:00:45 -0400 Received: from rsys002x.roke.co.uk ([193.118.201.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IcI4s-0004Qv-1X for nsis@ietf.org; Mon, 01 Oct 2007 06:00:45 -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 l91A09XI023918; Mon, 1 Oct 2007 11:00:09 +0100 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] Call for consensus draft-loughney-nsis-ext-02.txt as WGdocument? Date: Mon, 1 Oct 2007 11:00:39 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] Call for consensus draft-loughney-nsis-ext-02.txt as WGdocument? Thread-Index: AcgEEPVzVd2ShBWoS+iZ+zE9WVcxEgAADwHg References: <8A5B41AB-2766-4D54-9208-6E724F2B3278@netlab.nec.de> <4700C345.1070801@gmx.net> From: "Hancock, Robert" To: "Hannes Tschofenig" , "Martin Stiemerling" 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.1 (/) 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: , Errors-To: nsis-bounces@ietf.org hi all, imho the document is needed. in terms of scope, I believe that the questions to be answered are - what policies to adopt in extending GIST - and then, since GIST defines the NSLPID, what policies to adopt in deciding to create a new NSLP vs. extending an existing one I believe it's possible to write useful general guidance on the=20 second topic, without going into details on the extensibility issues for specific NSLPs. With respect to the first topic, the GIST spec already depends on the existence of this document (at the moment implicitly, since it is so long expired ...) it would certainly be good to draw on other protocol extensibility discussions for both of these, such as the AAA documents hannes refers to below (there is also Brian's extensibility guidelines document, not sure of its current status). robert h. > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 > Sent: 01 October 2007 10:52 > To: Martin Stiemerling > Cc: nsis > Subject: Re: [NSIS] Call for consensus=20 > draft-loughney-nsis-ext-02.txt as WGdocument? >=20 > Hi Martin >=20 > I agree that such a document is useful. >=20 > There are, however, a few follow-up questions: > a) When do you write such a document? > b) What is the scope of the document? >=20 > Regarding (a): In the RADEXT and the DIME working group we=20 > are currently producing documents that provide sort of design=20 > guidelines, see=20 > http://www.ietf.org/internet-drafts/draft-ietf-dime-app-design > -guide-02.txt > http://www.ietf.org/internet-drafts/draft-ietf-radext-design-00.txt >=20 > These two documents are written based on the experience that=20 > something went wrong regarding the way how people extended=20 > the protocol. Maybe it would have been better to write these=20 > documents earlier. Now we obviously have much more bad=20 > examples to write about. >=20 > Regarding (b): Should the document focus only on GIST or=20 > should it also cover the NSLPs? What happens if you define a=20 > new NSLP - do you revise the document? >=20 > How far can this document go beyond the already described=20 > information found in GIST, and the NSLPs? I could, for=20 > example, imagine that someone gives details about the common=20 > design aspects where you could essentially "steal" text from=20 > existing NSLPs. >=20 > Ciao > Hannes >=20 >=20 >=20 > Martin Stiemerling wrote: > > Hi all, > > > > Some time ago, John wrote the draft draft-loughney-nsis-ext-02.txt=20 > > discussing the extensibility of NSIS. > > > > It has been discussed on the mailing list, plus during the IETF=20 > > meetings and it seems to be a good shape to become a WG document. > > > > Therefore, I would like to propose draft-loughney-nsis-ext-02.txt=20 > > becoming a WG draft by now. > > > > This requires consensus of WG to do so. > > > > Please send your opinion on whether you like to see=20 > > draft-loughney-nsis-ext-02.txt as WG document or not to the NSIS=20 > > mailing list by no later than Oct 4th 5pm PST. > > > > Thanks, > > > > Martin > > > > stiemerling@netlab.nec.de > > NEC Laboratories Europe - Network Research Division > > > > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road,=20 > > London W3 6BL | Registered in England 2832014 > > > > > > > >=20 > ---------------------------------------------------------------------- > > -- > > > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > > =20 >=20 >=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 Mon Oct 01 13:19:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcOvS-0002AD-Vi; Mon, 01 Oct 2007 13:19:22 -0400 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1IcOvR-0002A8-N6 for nsis-confirm+ok@megatron.ietf.org; Mon, 01 Oct 2007 13:19:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcOvR-0002A0-3O for nsis@ietf.org; Mon, 01 Oct 2007 13:19:21 -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 1IcOvK-0006cS-T6 for nsis@ietf.org; Mon, 01 Oct 2007 13:19:21 -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; Mon, 01 Oct 2007 20:18:58 +0300 id 00080559.47012C02.00002FCA Date: Mon, 1 Oct 2007 20:18:58 +0300 (EEST) From: Jukka MJ Manner To: Martin Stiemerling Subject: Re: [NSIS] Call for consensus draft-loughney-nsis-ext-02.txt as WG document? In-Reply-To: <91AD3ED0-DA5E-46CB-81CD-CBE58D67BE96@netlab.nec.de> Message-ID: References: <8A5B41AB-2766-4D54-9208-6E724F2B3278@netlab.nec.de> <91AD3ED0-DA5E-46CB-81CD-CBE58D67BE96@netlab.nec.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 2870a44b67ee17965ce5ad0177e150f4 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 also think the draft is important and it should progress to WG status. Jukka _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Oct 02 04:36:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcdDs-0003O1-6m; Tue, 02 Oct 2007 04:35:20 -0400 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1IcdDq-0003NJ-SA for nsis-confirm+ok@megatron.ietf.org; Tue, 02 Oct 2007 04:35:18 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcdDq-0003N6-Hq for nsis@ietf.org; Tue, 02 Oct 2007 04:35:18 -0400 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IcdDq-0004Ka-0p for nsis@ietf.org; Tue, 02 Oct 2007 04:35:18 -0400 Received: (qmail invoked by alias); 02 Oct 2007 08:35:17 -0000 Received: from socks-ic-ext.mch.sbs.de (EHLO [194.138.17.187]) [194.138.17.187] by mail.gmx.net (mp033) with SMTP; 02 Oct 2007 10:35:17 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+pDxAhKMmpLwCjdh8QPY5PiOaGqMRBwYanzSYUdH sqbo3K+h4LBrb9 Message-ID: <470202C4.4000909@gmx.net> Date: Tue, 02 Oct 2007 10:35:16 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: dime@ietf.org, tsvwg IETF list , "nsis@ietf.org" , 'radext mailing list' 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: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: Subject: [NSIS] WGLC for draft-ietf-dime-qos-attributes-02 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, this message marks the issuance of a working group last call (WGLC) on DIME's Internet Draft entitled "Quality of Service Attributes for Diameter" (draft-ietf-dime-qos-attributes-02). You may view this document at http://tools.ietf.org/html/draft-ietf-dime-qos-attributes-02 Please post comments and questions to the DIME mailing list (or to the authors) no later than 16 October 2007. Ciao Hannes & Dave _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Oct 02 04:36:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcdDm-0003KW-EQ; Tue, 02 Oct 2007 04:35:14 -0400 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1IcdDl-0003KH-G3 for nsis-confirm+ok@megatron.ietf.org; Tue, 02 Oct 2007 04:35:13 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcdDl-0003Jr-5m for nsis@ietf.org; Tue, 02 Oct 2007 04:35:13 -0400 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IcdDk-0004KI-IN for nsis@ietf.org; Tue, 02 Oct 2007 04:35:13 -0400 Received: (qmail invoked by alias); 02 Oct 2007 08:35:11 -0000 Received: from socks-ic-ext.mch.sbs.de (EHLO [194.138.17.187]) [194.138.17.187] by mail.gmx.net (mp029) with SMTP; 02 Oct 2007 10:35:11 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+30LB26ly3LJYamr0oFPTjcEUKtKq8GDj1W3gnou 93XYkhFh/5ziXW Message-ID: <470202BF.4000701@gmx.net> Date: Tue, 02 Oct 2007 10:35:11 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: dime@ietf.org, 'radext mailing list' , "nsis@ietf.org" , tsvwg IETF list 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: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: Subject: [NSIS] WGLC for draft-ietf-dime-qos-parameters-01 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, this message marks the issuance of a working group last call (WGLC) on DIME's Internet Draft entitled "Quality of Service Parameters for Usage with the AAA Framework " (draft-ietf-dime-qos-parameters-01). You may view this document at http://tools.ietf.org/html/draft-ietf-dime-qos-parameters-01 Please post comments and questions to the DIME mailing list (or to the authors) no later than 16 October 2007. Ciao Hannes & Dave _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Oct 02 04:36:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcdDs-0003O1-6m; Tue, 02 Oct 2007 04:35:20 -0400 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1IcdDq-0003NJ-SA for nsis-confirm+ok@megatron.ietf.org; Tue, 02 Oct 2007 04:35:18 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcdDq-0003N6-Hq for nsis@ietf.org; Tue, 02 Oct 2007 04:35:18 -0400 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IcdDq-0004Ka-0p for nsis@ietf.org; Tue, 02 Oct 2007 04:35:18 -0400 Received: (qmail invoked by alias); 02 Oct 2007 08:35:17 -0000 Received: from socks-ic-ext.mch.sbs.de (EHLO [194.138.17.187]) [194.138.17.187] by mail.gmx.net (mp033) with SMTP; 02 Oct 2007 10:35:17 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+pDxAhKMmpLwCjdh8QPY5PiOaGqMRBwYanzSYUdH sqbo3K+h4LBrb9 Message-ID: <470202C4.4000909@gmx.net> Date: Tue, 02 Oct 2007 10:35:16 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: dime@ietf.org, tsvwg IETF list , "nsis@ietf.org" , 'radext mailing list' 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: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: Subject: [NSIS] WGLC for draft-ietf-dime-qos-attributes-02 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, this message marks the issuance of a working group last call (WGLC) on DIME's Internet Draft entitled "Quality of Service Attributes for Diameter" (draft-ietf-dime-qos-attributes-02). You may view this document at http://tools.ietf.org/html/draft-ietf-dime-qos-attributes-02 Please post comments and questions to the DIME mailing list (or to the authors) no later than 16 October 2007. Ciao Hannes & Dave _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Oct 02 04:36:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcdDm-0003KW-EQ; Tue, 02 Oct 2007 04:35:14 -0400 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1IcdDl-0003KH-G3 for nsis-confirm+ok@megatron.ietf.org; Tue, 02 Oct 2007 04:35:13 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcdDl-0003Jr-5m for nsis@ietf.org; Tue, 02 Oct 2007 04:35:13 -0400 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IcdDk-0004KI-IN for nsis@ietf.org; Tue, 02 Oct 2007 04:35:13 -0400 Received: (qmail invoked by alias); 02 Oct 2007 08:35:11 -0000 Received: from socks-ic-ext.mch.sbs.de (EHLO [194.138.17.187]) [194.138.17.187] by mail.gmx.net (mp029) with SMTP; 02 Oct 2007 10:35:11 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+30LB26ly3LJYamr0oFPTjcEUKtKq8GDj1W3gnou 93XYkhFh/5ziXW Message-ID: <470202BF.4000701@gmx.net> Date: Tue, 02 Oct 2007 10:35:11 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: dime@ietf.org, 'radext mailing list' , "nsis@ietf.org" , tsvwg IETF list 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: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: Subject: [NSIS] WGLC for draft-ietf-dime-qos-parameters-01 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, this message marks the issuance of a working group last call (WGLC) on DIME's Internet Draft entitled "Quality of Service Parameters for Usage with the AAA Framework " (draft-ietf-dime-qos-parameters-01). You may view this document at http://tools.ietf.org/html/draft-ietf-dime-qos-parameters-01 Please post comments and questions to the DIME mailing list (or to the authors) no later than 16 October 2007. Ciao Hannes & Dave _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Oct 02 07:22:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Icfnm-0000YP-Fv; Tue, 02 Oct 2007 07:20:34 -0400 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1Icfnl-0000Xm-GG for nsis-confirm+ok@megatron.ietf.org; Tue, 02 Oct 2007 07:20:33 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Icfnl-0000Xd-3s for nsis@ietf.org; Tue, 02 Oct 2007 07:20:33 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Icfnk-0008Od-Pj for nsis@ietf.org; Tue, 02 Oct 2007 07:20:33 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 8722A20738 for ; Tue, 2 Oct 2007 13:20:17 +0200 (CEST) X-AuditID: c1b4fb3c-b1681bb0000007e1-c7-4702297130a6 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 7AA8C203F4 for ; Tue, 2 Oct 2007 13:20:17 +0200 (CEST) Received: from esealmw116.eemea.ericsson.se ([153.88.200.7]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 2 Oct 2007 13:20:17 +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: RE: [NSIS] Call for consensus draft-loughney-nsis-ext-02.txt as WGdocument? Date: Tue, 2 Oct 2007 13:20:15 +0200 Message-ID: <53CCFDD6E346CB43994852666C210E91D0860D@esealmw116.eemea.ericsson.se> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] Call for consensus draft-loughney-nsis-ext-02.txt as WGdocument? Thread-Index: AcgET6x3vvNBVt5HTziTMaJYg7egfQAlnA0Q References: <8A5B41AB-2766-4D54-9208-6E724F2B3278@netlab.nec.de><91AD3ED0-DA5E-46CB-81CD-CBE58D67BE96@netlab.nec.de> From: =?iso-8859-1?Q?Attila_B=E1der?= To: "nsis" X-OriginalArrivalTime: 02 Oct 2007 11:20:17.0380 (UTC) FILETIME=[35ED6A40:01C804E6] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab 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 also support it,=20 Best regards, Attila -----Original Message----- From: Jukka MJ Manner [mailto:jmanner@cs.Helsinki.FI]=20 Sent: Monday, October 01, 2007 7:19 PM To: Martin Stiemerling Cc: nsis Subject: Re: [NSIS] Call for consensus draft-loughney-nsis-ext-02.txt as = WGdocument? I also think the draft is important and it should progress to WG status. 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 Tue Oct 02 20:53:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcsTU-0000o2-5p; Tue, 02 Oct 2007 20:52:28 -0400 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1IcsTS-0000iY-OK for nsis-confirm+ok@megatron.ietf.org; Tue, 02 Oct 2007 20:52:26 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcsTS-0000bz-Dq; Tue, 02 Oct 2007 20:52:26 -0400 Received: from mta1.dhs.gov ([152.121.181.36]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IcsTQ-0005nR-2v; Tue, 02 Oct 2007 20:52:24 -0400 Received: from dhsmail2.dhs.gov (dhsmail2.dhs.gov [161.214.63.27]) by mta1.dhs.gov with ESMTP; Tue, 2 Oct 2007 20:52:23 -0400 Received: from dhsmail2.dhs.gov (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 78DEB2357; Tue, 2 Oct 2007 20:52:22 -0400 (EDT) Received: from ZAU1UG-0351.DHSNET.DS1.DHS (mx7.hq.dhs.gov [161.214.98.195]) by dhsmail2.dhs.gov (Postfix) with ESMTP id 6B25A234F; Tue, 2 Oct 2007 20:52:22 -0400 (EDT) Received: from ZAU1UG-0308.DHSNET.DS1.DHS ([10.15.18.79]) by ZAU1UG-0351.DHSNET.DS1.DHS with Microsoft SMTPSVC(6.0.3790.1830); Tue, 2 Oct 2007 20:49:48 -0400 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 Date: Tue, 2 Oct 2007 20:49:48 -0400 Message-Id: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Tsvwg] WGLC for draft-ietf-dime-qos-parameters-01 Thread-Index: AcgEz4SaZT+XWIPvRx6Rtb+XW3YE5gAheSPi References: <470202BF.4000701@gmx.net> From: "Nguyen, An P" To: "Hannes Tschofenig" , , "radext mailing list" , , "tsvwg IETF list" X-OriginalArrivalTime: 03 Oct 2007 00:49:48.0808 (UTC) FILETIME=[4CC12880:01C80557] X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: Subject: [NSIS] RE: [Tsvwg] WGLC for draft-ietf-dime-qos-parameters-01 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 Dave/Hannes, I really like the draft, which I think it is short and sweet. It = captures most, if not all, important QoS paramters.=20 I'd like to support this draft going for WGLC.=20 Regards, An -----Original Message----- From: tsvwg-bounces@ietf.org on behalf of Hannes Tschofenig Sent: Tue 10/2/2007 4:35 AM To: dime@ietf.org; 'radext mailing list'; nsis@ietf.org; tsvwg IETF list Subject: [Tsvwg] WGLC for draft-ietf-dime-qos-parameters-01 =20 Hi all, this message marks the issuance of a working group last call (WGLC) on=20 DIME's Internet Draft entitled "Quality of Service Parameters for Usage=20 with the AAA Framework " (draft-ietf-dime-qos-parameters-01). You may=20 view this document at http://tools.ietf.org/html/draft-ietf-dime-qos-parameters-01 Please post comments and questions to the DIME mailing list (or to the=20 authors) no later than 16 October 2007. Ciao Hannes & Dave _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Oct 04 01:00:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdIo1-0002im-Pj; Thu, 04 Oct 2007 00:59:25 -0400 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1IdInz-0002Yf-KY for nsis-confirm+ok@megatron.ietf.org; Thu, 04 Oct 2007 00:59:23 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdInz-0002W0-6F for nsis@ietf.org; Thu, 04 Oct 2007 00:59:23 -0400 Received: from smtp.mei.co.jp ([133.183.129.25]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IdIny-0004Ao-FG for nsis@ietf.org; Thu, 04 Oct 2007 00:59:23 -0400 Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/jazz) with ESMTP id l944xEs5005859; Thu, 4 Oct 2007 13:59:14 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx3) with ESMTP id l944xEY04019; Thu, 4 Oct 2007 13:59:14 +0900 (JST) Received: from epochmail.jp.panasonic.com (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/phillies) with ESMTP id l944xFb01654; Thu, 4 Oct 2007 13:59:15 +0900 (JST) Received: by epochmail.jp.panasonic.com (8.12.11.20060308/3.7W/soml22) id l944xENv011180; Thu, 4 Oct 2007 13:59:14 +0900 (JST) Received: from [10.68.136.102] by soml22.jp.panasonic.com (8.12.11.20060308/3.7W) with ESMTP id l944xDkU011151; Thu, 4 Oct 2007 13:59:13 +0900 (JST) Date: Thu, 04 Oct 2007 14:00:37 +0900 From: Takako Sanda To: Martin Stiemerling Subject: Re: [NSIS] Call for consensus draft-loughney-nsis-ext-02.txt as WG document? In-Reply-To: <8A5B41AB-2766-4D54-9208-6E724F2B3278@netlab.nec.de> References: <8A5B41AB-2766-4D54-9208-6E724F2B3278@netlab.nec.de> Message-Id: <20071004135005.E176.SANDA.TAKAKO@jp.panasonic.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.24.02 [ja] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d 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 think this draft is useful, and agree to being progressed to WG draft. cheers, Takako On Thu, 27 Sep 2007 17:14:45 +0200 Martin Stiemerling wrote: > Hi all, > > Some time ago, John wrote the draft draft-loughney-nsis-ext-02.txt > discussing the extensibility of NSIS. > > It has been discussed on the mailing list, plus during the IETF > meetings and it seems to be a good shape to become a WG document. > > Therefore, I would like to propose draft-loughney-nsis-ext-02.txt > becoming a WG draft by now. > > This requires consensus of WG to do so. > > Please send your opinion on whether you like to see draft-loughney- > nsis-ext-02.txt as WG document or not to the NSIS mailing list by no > later than Oct 4th 5pm PST. > > Thanks, > > Martin > > stiemerling@netlab.nec.de > NEC Laboratories Europe - Network Research Division > > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, > London W3 6BL | Registered in England 2832014 > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Oct 04 08:56:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdQES-0000VS-Pf; Thu, 04 Oct 2007 08:55:12 -0400 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1IdQES-0000VI-5n for nsis-confirm+ok@megatron.ietf.org; Thu, 04 Oct 2007 08:55:12 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdQER-0000T5-Q3 for nsis@ietf.org; Thu, 04 Oct 2007 08:55:11 -0400 Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IdQER-0005R1-A9 for nsis@ietf.org; Thu, 04 Oct 2007 08:55:11 -0400 Received: from irams2.ira.uni-karlsruhe.de ([141.3.10.82]) by iramx2.ira.uni-karlsruhe.de with esmtps id 1IdQEO-0007xk-T0; Thu, 04 Oct 2007 14:55:10 +0200 Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5]) by irams2.ira.uni-karlsruhe.de with esmtps id 1IdQEN-0007vo-RN; Thu, 04 Oct 2007 14:55:08 +0200 Received: from i72ms.tm.uni-karlsruhe.de ([141.3.70.5] helo=smtp.ipv6.tm.uni-karlsruhe.de) by irams1.ira.uni-karlsruhe.de with esmtps id 1IdQEM-00036K-8u; Thu, 04 Oct 2007 14:55:06 +0200 Received: from vorta.ipv6.tm.uni-karlsruhe.de (vorta.ipv6.tm.uni-karlsruhe.de [IPv6:2001:638:204:6:207:e9ff:fe0c:5e44]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id 7EAC92FC00D; Thu, 4 Oct 2007 14:55:02 +0200 (CEST) Received: from localhost ([127.0.0.1]) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.44) id 1IdQEH-0001M9-TQ; Thu, 04 Oct 2007 14:55:02 +0200 Message-ID: <4704E2A5.90103@tm.uka.de> Date: Thu, 04 Oct 2007 14:55:01 +0200 From: Roland Bless Organization: Institute of Telematics, University of Karlsruhe User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060111 Thunderbird/1.5 Mnenhy/0.7.3.0 MIME-Version: 1.0 To: Martin Stiemerling Subject: Re: [NSIS] Call for consensus draft-loughney-nsis-ext-02.txt as WG document? References: <8A5B41AB-2766-4D54-9208-6E724F2B3278@netlab.nec.de> In-Reply-To: <8A5B41AB-2766-4D54-9208-6E724F2B3278@netlab.nec.de> X-Enigmail-Version: 0.94.4.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Status: No X-Spam-Score: -1.3 (-) X-Spam-Report: -1.4 ALL_TRUSTED Passed through trusted hosts only via SMTP 0.1 AWL AWL: From: address is in the auto white-list X-Spam-Host: irams2.ira.uni-karlsruhe.de X-ATIS-Checksum: v3zoCAcc32ckk X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d 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 Martin and all, Martin Stiemerling wrote: > Some time ago, John wrote the draft draft-loughney-nsis-ext-02.txt > discussing the extensibility of NSIS. > > It has been discussed on the mailing list, plus during the IETF meetings > and it seems to be a good shape to become a WG document. > > Therefore, I would like to propose draft-loughney-nsis-ext-02.txt > becoming a WG draft by now. > > This requires consensus of WG to do so. > > Please send your opinion on whether you like to see > draft-loughney-nsis-ext-02.txt as WG document or not to the NSIS mailing > list by no later than Oct 4th 5pm PST. I guess that it is important to have a document like this, it is also referred to by other drafts (e.g. GIST) and would be especially useful for folks in the future who want to extend NSIS (esp. those from other SDOs etc). Probably it needs some more discussion within the WG, but basically it seems to be a good start... So I'm in favor of WG adoption of this draft. Regards, Roland _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Oct 04 19:07:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdZly-0001ev-A1; Thu, 04 Oct 2007 19:06:26 -0400 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1IdZlw-0001eq-Rn for nsis-confirm+ok@megatron.ietf.org; Thu, 04 Oct 2007 19:06:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdZlw-0001du-6k for nsis@ietf.org; Thu, 04 Oct 2007 19:06:24 -0400 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IdZlp-0005dq-2X for nsis@ietf.org; Thu, 04 Oct 2007 19:06:24 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l94N5tx6025611 for ; Fri, 5 Oct 2007 02:06:05 +0300 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 5 Oct 2007 02:05:20 +0300 Received: from daebe104.NOE.Nokia.com ([10.241.36.13]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 4 Oct 2007 18:05:19 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C806DB.08B96751" Date: Thu, 4 Oct 2007 18:05:18 -0500 Message-ID: <19EBBEC503C3B5469070E0A6674A533A9AE127@daebe104.NOE.Nokia.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: Chair write-up of: "GIST: General Internet Signaling Transport" Thread-Index: AcgG2n0w3orF0QuaSZ+QTaWBRp708gAAHwng From: To: X-OriginalArrivalTime: 04 Oct 2007 23:05:19.0545 (UTC) FILETIME=[08CF0A90:01C806DB] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: c119f9923e40f08a1d7f390ce651ea92 Subject: [NSIS] FW: Chair write-up of: "GIST: General Internet Signaling Transport" 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 a multi-part message in MIME format. ------_=_NextPart_001_01C806DB.08B96751 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Martin and I have sent this to our Ads, so that GIST can be resubmitted to the IESG. John=20 >-----Original Message----- >From: Loughney John (Nokia-NRC/PaloAlto)=20 >Sent: 04 October, 2007 16:01 >To: 'Magnus Westerlund'; Eggert Lars (Nokia-NRC/Helsinki) >Cc: 'Hannes.Tschofenig@gmx.net'; 'robert.hancock@roke.co.uk';=20 >Martin Stiemerling >Subject: Chair write-up of: "GIST: General Internet Signaling=20 >Transport" > >The "GIST: General Internet Signaling Transport" has been=20 >reviewed by the IESG, and there were several discusses issued=20 >against the draft. We feel that all open issues from the IESG=20 >have been resolved. > >There was a working group last call that ended on June 25th. =20 >Additionally, there was a GIST Interop event, that raised a=20 >few more issues, that have all been resolved in the Working=20 >Group and were part of the WGLC. Attached is the Interop=20 >Summary report. >=20 >The I-D is now ready for AD and IESG review. Below are details=20 >about the I-D: > >Title: GIST: General Internet Signaling Transport >I-D: http://www.ietf.org/internet-drafts/draft-ietf-nsis-ntlp-14.txt > >Status: Proposed Standard > >Response to template: > >1) Have the chairs personally reviewed this version of the ID and do > they believe this ID is sufficiently baked to forward to the IESG > for publication?=20 > >Yes. > >2) Has the document had adequate review from both key WG members and > key non-WG members? Do you have any concerns about the depth or > breadth of the reviews that have been performed? > >Yes. The ID has passed working group last calls, has had good=20 >reviews during the process, including an early reviews by Bob=20 >Braden and Brian Carpenter prior to acceptance as a working=20 >group document. It has been reviewed by the IESG, and we feel=20 >that all DISCUSSes from the IESG have been cleared. > >3) Do you have concerns that the document needs more review from a > particular (broader) perspective (e.g., security, operational > complexity, etc.)?=20 > >No concerns. The document has undergone extensive Working=20 >Group review, and has several (at least 6) interoperable=20 >implementations. > > =20 >4) Do you have any specific concerns/issues with this document that > you believe the ADs and/or IESG should be aware of? For example, > perhaps you are uncomfortable with certain parts of the document, > or whether there really is a need for it, etc., but at the same > time these issues have been discussed in the WG and the WG has > indicated it wishes to advance the document anyway. > >No > =20 >5) How solid is the WG consensus behind this document? Does it > represent the strong concurrence of a few individuals, with others > being silent, or does the WG as a whole understand and agree with > it? > >There is a strong consensus in the WG supporting this work, at=20 >this point there is no disenting voices about the protocol in the WG. > >6) Has anyone threatened an appeal or otherwise indicated extreme > discontent? If so, please summarize what are they upset about. > >No.=20 > =20 >7) Have the chairs verified that the document adheres to _all_ of the > ID nits? (see http://www.ietf.org/ID-nits.html). > >Yes. > >8) Does the document a) split references into normative/informative, > and b) are there normative references to IDs, where the IDs are not > also ready for advancement or are otherwise in an unclear state? > (Note: the RFC editor will not publish an RFC with normative > references to IDs, it will delay publication until all such IDs are > also ready for publication as RFCs.) > >The document does split references into normative and=20 >informative ones.=20 > >9) For Standards Track and BCP documents, the IESG approval > announcement includes a writeup section with the following > sections: > > - Technical Summary > >This draft proposes a general signaling transport protocol. =20 >It is based on the use of existing transport and security=20 >protocols under a common messaging layer. GIST does not handle=20 >signaling application state itself; in that crucial respect,=20 >it differs from application signaling protocols such as SIP,=20 >RTSP, and the control component of FTP, but this follows the=20 >basic NSIS 2-layer signaling model defined in RFC 4080. > > - Working Group Summary > >There have been several WGLC on the document, plus several=20 >pre-WGLCs on the document. >The editors have gotten extensive feedback from implementors=20 >and have clarified text based upon the feedback. There are 6=20 >or more independent implementations of GIST, and there was an=20 >interop event prior to the Paris IETF meeting. > > - Protocol Quality > >This document was reviewed by the working group chair as well=20 >as the WG. We feel that this document is ready, and=20 >implementors feel that the specification is implementatble. ------_=_NextPart_001_01C806DB.08B96751 Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit X-MimeOLE: Produced By Microsoft Exchange V6.5 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by daebe103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 Jun 2007 18:47:24 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable Received: from esebh106.NOE.Nokia.com ([172.21.138.213]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 Jun 2007 18:47:24 -0500 Received: from mgw-mx01.nokia.com ([192.100.122.228]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 Jun 2007 02:47:22 +0300 Received: from merlot.tools.ietf.org (merlot.tools.ietf.org [194.146.105.14]) by mgw-mx01.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id l5INlJvm010211 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Tue, 19 Jun 2007 02:47:20 +0300 Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81]) by merlot.tools.ietf.org with esmtp (Exim 4.67) (envelope-from ) id 1I0QwI-0003GV-8B for nsis-chairs@tools.ietf.org; Tue, 19 Jun 2007 01:47:19 +0200 Received: from i72ms.tm.uni-karlsruhe.de ([141.3.70.5] helo=smtp.ipv6.tm.uni-karlsruhe.de) by iramx2.ira.uni-karlsruhe.de with esmtps id 1I0QwF-0003Z2-8a; Tue, 19 Jun 2007 01:47:17 +0200 Received: from vorta.ipv6.tm.uni-karlsruhe.de (vorta.ipv6.tm.uni-karlsruhe.de [IPv6:2001:638:204:6:207:e9ff:fe0c:5e44]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id 163162FC1F2; Tue, 19 Jun 2007 01:47:15 +0200 (CEST) Received: from localhost ([127.0.0.1]) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.44) id 1I0QwE-00040Z-CN; Tue, 19 Jun 2007 01:47:14 +0200 Content-class: urn:content-classes:message Subject: NSIS Interop Summary Report from Karlsruhe Date: Mon, 18 Jun 2007 18:47:13 -0500 Message-ID: <46771981.60907@tm.uka.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: NSIS Interop Summary Report from Karlsruhe Thread-Index: AceyAwUWtHHANiYvRR2wxMqmVoL3Fg== From: To: , Hi all, the WG chairs solicited feedback about the latest NSIS interop in Karlsruhe. So here it is (sorry for the long delay): Overview: =3D=3D=3D=3D=3D=3D=3D=3D=3D * Implementation teams: - University of Coimbra (GIST, QoS NSLP, NAT/FW) each Draft -13 - Uni Goettingen (GIST, QoS NSLP, NAT/FW) each Draft-13 - Uni Karlsruhe (GIST, QoS NSLP, NAT/FW) each Draft-13 - Siemens Roke Manor Research was planned to participate but could not make it. * We mainly concentrated on GIST tests, because this spec has to be off the table first. * We used test cases that were defined by Christian Dickmann (and discussed at last IETF among Christian, Alan Ford, Andrew McDonald and partially me). You can find the document here (though in a format of an internet-draft, it is not published as such yet) http://user.informatik.uni-goettingen.de/~cdickman/draft-dickmann-nsis-nt= lp-interop-00.txt * Christian did a great job in setting up tools for performing automated tests. This sped up testing a lot. * GIST was quite thoroughly tested with Goettingen vs. Karlsruhe (in both directions, see below). We tested all the main protocol features like D-Mode, C-Mode, TLS+TCP, v4,v6, late state installation, etc. * The GIST Spec is implementable; we found no major issues with the GIST spec, only the need for some clarifications that can be found here in our tracker: https://projekte.tm.uka.de/trac/NSIS/report/10 (I entered some additional tickets after the interop event). * A major open issue is, however, NAT traversal functionality that could not be tested yet. * Interop URL: = https://projekte.tm.uka.de/trac/NSIS/wiki/Interop-20070509 Details (as written in a mail from Christian) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Christian created a report based on the data collected by the Interop Tools. Take a look at: http://dickmann.homeunix.org/nsis/displayReportList.php --------------------------------------------------------------------- Christian's mail: Of course, this is only a subset of all tests that were made (and only the last run of each test case), but I guess we are close to 90 or 95% coverage. A lot of test cases come with captures so that you can look up the message exchange for successful or failed tests. I set the success-flag for most tests directly during the interop event once the test was completed. However, for some test cases I set the flag today based on my notes (and my memory). As you know the test cases were based on [1]. Each test case belongs into one of these categories: "normal operation", "recoverable problems", "unrecoverable problems". I analyzed the report based on these categories (notation "X vs. Y" means X is Initiator and Y is Responder): Normal operation: Goettingen vs. Karlsruhe: 3-Way Handshake: 7 PASSED, 10 run of 11 test cases Refresh of soft state: 2 PASSED, 2 run of 5 test cases Setup of multiple sessions: 3 PASSED, 3 run of 4 test cases Interception on NSIS forwarders: 3 PASSED, 4 run of 4 test cases GIST Stateless operation: 0 PASSED, 1 run of 2 test cases Karlsruhe vs. Goettingen: 3-Way Handshake: 8 PASSED, 9 run of 11 test cases Refresh of soft state: 0 PASSED, 1 run of 5 test cases Goettingen vs. Coimbra: 3-Way Handshake: 8 PASSED, 9 run of 11 test cases Refresh of soft state: 2 PASSED, 2 run of 5 test cases Coimbra vs. Goettingen: 3-Way Handshake: 2 PASSED, 3 run of 11 test cases Karlsruhe vs. Coimbra: 3-Way Handshake: 5 PASSED, 5 run of 11 test cases Recoverable problems: Goettingen vs. Karlsruhe: 3-Way Handshake: 2 PASSED, 3 run of 3 test cases Refresh of soft state: 4 PASSED, 4 run of 5 test cases Karlsruhe vs. Goettingen: 3-Way Handshake: 1 PASSED, 1 run of 3 test cases Goettingen vs. Coimbra: 3-Way Handshake: 2 PASSED, 2 run of 3 test cases Refresh of soft state: 4 PASSED, 4 run of 5 test cases Unrecoverable problems: Goettingen vs. Karlsruhe: 3-Way Handshake: 5 PASSED, 5 run of 5 test cases Karlsruhe vs. Goettingen: 3-Way Handshake: 3 PASSED, 4 run of 5 test cases Goettingen vs. Coimbra: 3-Way Handshake: 4 PASSED, 5 run of 5 test cases As we can see, we did not test all test cases, even for Goettingen vs. Karlsruhe. However, for Goe vs. Ka we can say that we covered a really good part of the GIST specification. In particular we tested all important features (except for NAT traversal and Stateless mode). This makes me very confident that the spec is implementable (except for NAT traversal, see NSIS mailing list). I think we tested Goettingen against Karlsruhe quite thoroughly (in both directions). We ran 47 test cases (IPv4 only) and passed 38 of these. That's a success rate of 80%. The tests against Coimbra were not as complete. We ran 25 test cases (IPv4 only) between G=F6ttingen and = Coimbra and passed 22 of them (=3D 88%). Thus, the test cases we tested were = quite successful, but we ran only half of the test cases compared to Goe/Ka. Also note that we did only very few test cases with IPv6 and only with G=F6ttingen vs. Karlsruhe. However, those were all successful. My personal lessons learned from this interop: - Even 3 days were not enough. Considering that we only had 3 GIST implementations to test, this sounds like we wasted too much time. I try to find reasons below. - I guess 70% of the problems we found between G=F6ttingen and Karlsruhe were NOT related to interop problems. On the other hand, all bugs found in our (G=F6ttingen) implementation (very few overall) were related to real interop issues. I guess the reason is quite simple: I ran ALL test cases defined in [1] with G=F6ttingen vs. G=F6ttingen and so found and = fixed a lot of bugs before arriving in Karlsruhe. I suppose the other participants did not do internal tests as thorough as ours, which resulted in this rate of non-interop issues. - More internal tests (see above) but also remote tests before the actual interop event can save a lot of time. I did some remote tests with Karlsruhe and we were able to detect and fix some problems before meeting in person. With Coimbra I also performed some remote tests (just basic D-Mode and C-Mode, both failed), but not as thorough as with Karlsruhe. We ended up having problems with TLS for many hours during the interop event. We should do much more remote testing to avoid these lengthy debugging phases! - The interop draft [1] helped a lot. First, it has so many test cases that you would not think of during an interop event. Second, for complex tests the expected behavior and useful triggers are not always obvious. Having them written down with one or two rounds of review saves time and avoids mistakes during the interop event. Third, the interop draft now helps to write this report, as we can "measure" the success. - The interop tools helped a lot and saved a lot of time. I guess the tools saved roughly 50% of my time. Maybe even more. Considering that we are very short on time, this is a huge improvement. Besides that, many test cases are simply not feasible without tools (for example attack scenarios, corrupted objects, etc.). We should continue to use the tools and extend them so that they can become the default tool to do the interop. That would also help in remote testing. - The organization by Roland was very good. We had enough switches, cables, spare machines, space, etc. The network setup we discussed on this mailing list a week before the interop was well set up and avoided long setup and re-plugging phases. You can see that this is important when you look at Luis and Vitor who tried to configure their network on site to correspond to the network layout. It took them quite a while of debugging to configure their machines correctly. More preparation from all sides and an agreed-upon network setup help to avoid these kinds of delay. - Taking all these issues into account, I think that 3 days CAN be enough time, if and only if enough preparation is done in form of defining test cases, writing tools to help with testing, testing internally against the test cases, doing remote tests and organizing and preparing for the event itself. Overall I am quite satisfied with the interop. I think we made a big step ahead towards mature and interoperable implementations. We tested and discussed a good portion of the spec and found no (or very few and minor) real problems. And we tested quite a lot of test cases and had a reasonable success rate that is even going to improve with remote tests taking place in the next few weeks. Thank you all. I had a great time at the interop and special thanks go to Roland and the University of Karlsruhe for doing a very good job of hosting this interop event. Regards, Christian Dickmann [1] http://user.informatik.uni-goettingen.de/~cdickman/draft-dickmann-nsis-nt= lp-interop-00.txt -------------------------------------------------------------------- ------_=_NextPart_001_01C806DB.08B96751 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_001_01C806DB.08B96751-- From nsis-bounces@ietf.org Fri Oct 05 07:02:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdkvJ-0005rp-0y; Fri, 05 Oct 2007 07:00:49 -0400 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1IdkvH-0005l4-DC for nsis-confirm+ok@megatron.ietf.org; Fri, 05 Oct 2007 07:00:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdkvH-0005jT-2W for nsis@ietf.org; Fri, 05 Oct 2007 07:00:47 -0400 Received: from smtp0.netlab.nec.de ([195.37.70.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IdkvB-0000Dj-CA for nsis@ietf.org; Fri, 05 Oct 2007 07:00:47 -0400 Received: from localhost (atlas1.office [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id E79222800038D; Fri, 5 Oct 2007 13:00:40 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office) Received: from smtp0.netlab.nec.de ([127.0.0.1]) by localhost (atlas1.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pOBHz9rh0tXL; Fri, 5 Oct 2007 13:00:40 +0200 (CEST) Received: from mx1.office (mx1.office [10.1.1.23]) by smtp0.netlab.nec.de (Postfix) with ESMTP id C09C228000340; Fri, 5 Oct 2007 13:00:30 +0200 (CEST) Received: from mx1.office ([10.1.1.23]) by mx1.office with Microsoft SMTPSVC(6.0.3790.3959); Fri, 5 Oct 2007 13:00:29 +0200 Received: from [10.1.1.109] ([10.1.1.109]) by mx1.office over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Fri, 5 Oct 2007 13:00:29 +0200 In-Reply-To: <4700C345.1070801@gmx.net> References: <8A5B41AB-2766-4D54-9208-6E724F2B3278@netlab.nec.de> <4700C345.1070801@gmx.net> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <06F326B1-6A9E-4955-9A38-671B0581AA36@netlab.nec.de> From: Martin Stiemerling Subject: Re: [NSIS] Call for consensus draft-loughney-nsis-ext-02.txt as WG document? Date: Fri, 5 Oct 2007 13:00:26 +0200 To: Hannes Tschofenig X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 05 Oct 2007 11:00:29.0087 (UTC) FILETIME=[F0E38AF0:01C8073E] X-Spam-Score: 0.0 (/) X-Scan-Signature: f6ef73100908d67495ce675c3fe8f472 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="===============0169884398==" Errors-To: nsis-bounces@ietf.org --===============0169884398== Content-Type: multipart/alternative; boundary=Apple-Mail-6-673945672 --Apple-Mail-6-673945672 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hi Hannes, Am 01.10.2007 um 11:52 schrieb Hannes Tschofenig: > Hi Martin > > I agree that such a document is useful. > > There are, however, a few follow-up questions: > a) When do you write such a document? > b) What is the scope of the document? > > Regarding (a): In the RADEXT and the DIME working group we are > currently producing documents that provide sort of design > guidelines, see > http://www.ietf.org/internet-drafts/draft-ietf-dime-app-design- > guide-02.txt > http://www.ietf.org/internet-drafts/draft-ietf-radext-design-00.txt > > These two documents are written based on the experience that > something went wrong regarding the way how people extended the > protocol. Maybe it would have been better to write these documents > earlier. Now we obviously have much more bad examples to write about. We are in the lucky situation to write such a document before things can go wrong. That is a good reasons to start now. > > Regarding (b): Should the document focus only on GIST or should it > also cover the NSLPs? What happens if you define a new NSLP - do > you revise the document? It should cover the whole NSIS stack, i.e., GIST and the NSLPs. When you are tying to extend NSIS as such, you first need to find out the right place to do the extension. > > How far can this document go beyond the already described > information found in GIST, and the NSLPs? I could, for example, > imagine that someone gives details about the common design aspects > where you could essentially "steal" text from existing NSLPs. This is a good point. Martin > > Ciao > Hannes > > > > Martin Stiemerling wrote: >> Hi all, >> >> Some time ago, John wrote the draft draft-loughney-nsis-ext-02.txt >> discussing the extensibility of NSIS. >> >> It has been discussed on the mailing list, plus during the IETF >> meetings and it seems to be a good shape to become a WG document. >> >> Therefore, I would like to propose draft-loughney-nsis-ext-02.txt >> becoming a WG draft by now. >> >> This requires consensus of WG to do so. >> >> Please send your opinion on whether you like to see draft-loughney- >> nsis-ext-02.txt as WG document or not to the NSIS mailing list by >> no later than Oct 4th 5pm PST. >> >> Thanks, >> >> Martin >> >> stiemerling@netlab.nec.de >> NEC Laboratories Europe - Network Research Division >> >> NEC Europe Limited | Registered Office: NEC House, 1 Victoria >> Road, London W3 6BL | Registered in England 2832014 >> >> >> >> --------------------------------------------------------------------- >> --- >> >> _______________________________________________ >> nsis mailing list >> nsis@ietf.org >> https://www1.ietf.org/mailman/listinfo/nsis >> > stiemerling@netlab.nec.de NEC Laboratories Europe - Network Research Division NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 --Apple-Mail-6-673945672 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Hi Hannes,


Am 01.10.2007 = um 11:52 schrieb Hannes Tschofenig:

Hi Martin

I agree that such a document is = useful.

There are, however, a few follow-up = questions:
a) When do you write such a = document?
b) What is the scope of the = document?

Regarding (a): In the RADEXT and the DIME working = group we are currently producing documents that provide sort of design = guidelines, see

These two documents are written based on the = experience that something went wrong regarding the way how people = extended the protocol. Maybe it would have been better to write these = documents earlier. Now we obviously have much more bad examples to write = about.

We are in the lucky = situation to write such a document before things can go wrong. That is a = good reasons to start now.


It should cover the whole = NSIS stack, i.e., GIST and the NSLPs. When you are tying to extend NSIS = as such, you first need to find out the right place to do the = extension.=A0


How far can = this document go beyond the already described information found in GIST, = and the NSLPs? I could, for example, imagine that someone gives details = about the common design aspects where you could essentially "steal" text = from existing NSLPs.

This is a good = point.=A0

=A0 = Martin


Ciao
Hannes



Martin = Stiemerling wrote:
Hi all,

Some time ago, John wrote the = draft draft-loughney-nsis-ext-02.txt discussing the extensibility of = NSIS.

It has been discussed on the mailing list, plus = during the IETF meetings and it seems to be a good shape to become a WG = document.

Therefore, I would like to propose = draft-loughney-nsis-ext-02.txt becoming a WG draft by now.

This = requires consensus of WG to do so.

Please send your opinion on = whether you like to see draft-loughney-nsis-ext-02.txt as WG document or = not to the NSIS mailing list by no later than Oct 4th 5pm PST.


=A0 = Martin

stiemerling@netlab.nec.de
NEC Laboratories Europe - Network Research = Division

NEC Europe Limited | Registered Office: NEC House, 1 = Victoria Road, London W3 6BL | Registered in England 2832014




nsis mailing list

=A0=A0


=

stiemerling@netlab.nec.de
NEC Laboratories Europe - Network Research = Division

NEC Europe = Limited |=A0Registered Office: NEC House, 1 Victoria Road, London W3 6BL = |=A0Registered in England 2832014

=

= --Apple-Mail-6-673945672-- --===============0169884398== 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 --===============0169884398==-- From nsis-bounces@ietf.org Fri Oct 05 07:16:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Idl97-00045m-9h; Fri, 05 Oct 2007 07:15:05 -0400 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1Idl95-00045d-Mq for nsis-confirm+ok@megatron.ietf.org; Fri, 05 Oct 2007 07:15:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Idl95-00045U-D3 for nsis@ietf.org; Fri, 05 Oct 2007 07:15:03 -0400 Received: from smtp0.netlab.nec.de ([195.37.70.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Idl93-00016N-7W for nsis@ietf.org; Fri, 05 Oct 2007 07:15:03 -0400 Received: from localhost (atlas1.office [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id C62032800038D for ; Fri, 5 Oct 2007 13:15:00 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office) Received: from smtp0.netlab.nec.de ([127.0.0.1]) by localhost (atlas1.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aduEz5Ih1llI for ; Fri, 5 Oct 2007 13:15:00 +0200 (CEST) Received: from mx1.office (mx1.office [10.1.1.23]) by smtp0.netlab.nec.de (Postfix) with ESMTP id A7EF728000340 for ; Fri, 5 Oct 2007 13:14:55 +0200 (CEST) Received: from mx1.office ([10.1.1.23]) by mx1.office with Microsoft SMTPSVC(6.0.3790.3959); Fri, 5 Oct 2007 13:14:55 +0200 Received: from [10.1.1.109] ([10.1.1.109]) by mx1.office over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Fri, 5 Oct 2007 13:14:54 +0200 Mime-Version: 1.0 (Apple Message framework v752.3) To: nsis Message-Id: <7AC83118-3D31-4F8C-8881-A3192F7B49EC@netlab.nec.de> From: Martin Stiemerling Date: Fri, 5 Oct 2007 13:14:53 +0200 X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 05 Oct 2007 11:14:54.0931 (UTC) FILETIME=[F4F8DA30:01C80740] X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Subject: [NSIS] WG status update from the chairs 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="===============0622506151==" Errors-To: nsis-bounces@ietf.org --===============0622506151== Content-Type: multipart/alternative; boundary=Apple-Mail-10-674812487 --Apple-Mail-10-674812487 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Dear all, This email is an update about the current status of the NSIS WG. Our milestones/WG drafts: - GIST is now again with our AD for review and later on, on its way to the IESG - John and me are about to do the WG chair's review for the QoS NSLP and the QSPEC. - There will be a new WG last call for the NATFW NSLP soon, right after submission of the latest update - RMD, Y.1541, and Applicability Statement of NSIS Protocols in Mobile Environment are work in progress Further: - The chairs and ADs are discussing an updated list of milestones (i.e., mainly updated deadlines and one updated milestone) - Upcoming IETF#70 in Vancouver: There will be an NSIS session of 2 hours length to discuss remaining issues of the "finished" milestones, such as GIST, QoS NSLP, etc. Plus the regular discussions on the open milestones, such as, e.g., NATFW NSLP, mobility, etc. With best regards, Martin stiemerling@netlab.nec.de NEC Laboratories Europe - Network Research Division NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 --Apple-Mail-10-674812487 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Dear all,

This email is an update = about the current status of the NSIS WG.=A0

Our milestones/WG = drafts:
- GIST is now again with our AD for review and later = on, on its way
=A0 to the IESG
- John and me are = about to do the WG chair's review for the QoS
=A0 NSLP=A0and = the QSPEC.=A0
- There will be a new WG last call for the NATFW = NSLP soon, right
=A0 after submission of the latest = update
- RMD, Y.1541, and=A0Applicability Statement of NSIS = Protocols in
=A0 Mobile Environment are work in = progress

Further:
- The = chairs and ADs are discussing an updated list of milestones
=A0 = (i.e., mainly updated deadlines and one updated milestone)
- = Upcoming IETF#70 in Vancouver:
=A0 There will be an NSIS = session of 2 hours length to discuss remaining
=A0 issues of = the "finished" milestones, such as GIST, QoS NSLP, etc.
=A0 = Plus the regular discussions on the open milestones, such as, = e.g.,
=A0 NATFW NSLP, mobility, etc.

With best = regards,

=A0 = Martin

stiemerling@netlab.nec.de
NEC Laboratories Europe - Network Research = Division

NEC Europe = Limited |=A0Registered Office: NEC House, 1 Victoria Road, London W3 6BL = |=A0Registered in England 2832014

=

= --Apple-Mail-10-674812487-- --===============0622506151== 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 --===============0622506151==-- From nsis-bounces@ietf.org Mon Oct 08 06:16:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iepe0-0007L3-Vm; Mon, 08 Oct 2007 06:15:24 -0400 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1Iepdy-0007Ko-WE for nsis-confirm+ok@megatron.ietf.org; Mon, 08 Oct 2007 06:15:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iepdy-0007Kf-L3 for nsis@ietf.org; Mon, 08 Oct 2007 06:15:22 -0400 Received: from amailer.gwdg.de ([134.76.10.18]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iepds-0001B7-A1 for nsis@ietf.org; Mon, 08 Oct 2007 06:15:22 -0400 Received: from s5.ifi.informatik.uni-goettingen.de ([134.76.81.25] helo=[172.23.0.2]) by mailer.gwdg.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1Iepdf-0006GV-QJ for nsis@ietf.org; Mon, 08 Oct 2007 12:15:03 +0200 Message-ID: <470A0349.6040901@cs.uni-goettingen.de> Date: Mon, 08 Oct 2007 12:15:37 +0200 From: Xiaoming Fu User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: nsis Subject: Re: [NSIS] Call for consensus draft-loughney-nsis-ext-02.txt as WG document? References: <8A5B41AB-2766-4D54-9208-6E724F2B3278@netlab.nec.de> <4700C345.1070801@gmx.net> <06F326B1-6A9E-4955-9A38-671B0581AA36@netlab.nec.de> In-Reply-To: <06F326B1-6A9E-4955-9A38-671B0581AA36@netlab.nec.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated: Id:xfu X-Spam-Level: - X-Virus-Scanned: (clean) by exiscan+sophie X-Spam-Score: 0.0 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 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 it is really good to have this document to become WG doc. Xiaoming Martin Stiemerling wrote: > Hi Hannes, > > > Am 01.10.2007 um 11:52 schrieb Hannes Tschofenig: > >> Hi Martin >> >> I agree that such a document is useful. >> >> There are, however, a few follow-up questions: >> a) When do you write such a document? >> b) What is the scope of the document? >> >> Regarding (a): In the RADEXT and the DIME working group we are >> currently producing documents that provide sort of design guidelines, see >> http://www.ietf.org/internet-drafts/draft-ietf-dime-app-design-guide-02.txt >> http://www.ietf.org/internet-drafts/draft-ietf-radext-design-00.txt >> >> These two documents are written based on the experience that something >> went wrong regarding the way how people extended the protocol. Maybe >> it would have been better to write these documents earlier. Now we >> obviously have much more bad examples to write about. > > We are in the lucky situation to write such a document before things can > go wrong. That is a good reasons to start now. > >> >> Regarding (b): Should the document focus only on GIST or should it >> also cover the NSLPs? What happens if you define a new NSLP - do you >> revise the document? > > It should cover the whole NSIS stack, i.e., GIST and the NSLPs. When you > are tying to extend NSIS as such, you first need to find out the right > place to do the extension. > >> >> How far can this document go beyond the already described information >> found in GIST, and the NSLPs? I could, for example, imagine that >> someone gives details about the common design aspects where you could >> essentially "steal" text from existing NSLPs. > > This is a good point. > > Martin > >> >> Ciao >> Hannes >> >> >> >> Martin Stiemerling wrote: >>> Hi all, >>> >>> Some time ago, John wrote the draft draft-loughney-nsis-ext-02.txt >>> discussing the extensibility of NSIS. >>> >>> It has been discussed on the mailing list, plus during the IETF >>> meetings and it seems to be a good shape to become a WG document. >>> >>> Therefore, I would like to propose draft-loughney-nsis-ext-02.txt >>> becoming a WG draft by now. >>> >>> This requires consensus of WG to do so. >>> >>> Please send your opinion on whether you like to see >>> draft-loughney-nsis-ext-02.txt as WG document or not to the NSIS >>> mailing list by no later than Oct 4th 5pm PST. >>> >>> Thanks, >>> >>> Martin >>> >>> stiemerling@netlab.nec.de >>> NEC Laboratories Europe - Network Research Division >>> >>> NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, >>> London W3 6BL | Registered in England 2832014 >>> >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> nsis mailing list >>> nsis@ietf.org >>> https://www1.ietf.org/mailman/listinfo/nsis >>> >>> >>> >> > > stiemerling@netlab.nec.de > NEC Laboratories Europe - Network Research Division > > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, > London W3 6BL | Registered in England 2832014 > > > > ------------------------------------------------------------------------ > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://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 Oct 11 07:59:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfwgF-0002Wa-Nf; Thu, 11 Oct 2007 07:58:19 -0400 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1IfwgD-0002Vw-Nx for nsis-confirm+ok@megatron.ietf.org; Thu, 11 Oct 2007 07:58:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfwgD-0002Vl-CV for nsis@ietf.org; Thu, 11 Oct 2007 07:58:17 -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 1IfwgC-0005Kw-4V for nsis@ietf.org; Thu, 11 Oct 2007 07:58:17 -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; Thu, 11 Oct 2007 14:58:15 +0300 id 000706CE.470E0FD7.00000348 Date: Thu, 11 Oct 2007 14:58:15 +0300 (EEST) From: Jukka MJ Manner To: int-area@lists.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: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: NSIS Working Group Subject: [NSIS] RAO for IPv4 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 all, We have written the following I-D about the problem with current RAO allocations for IPv4 and IPv6. I would appreciate some feedback on the draft, and whether you feel something should be done, as we propose. "IANA Considerations for the IPv4 and IPv6 Router Alert Option" Andrew McDonald, Jukka Manner http://www.ietf.org/internet-drafts/draft-manner-router-alert-iana-00.txt The NSIS WG is CC:d, because the problem was identified while working on GIST. Regards, Jukka _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Oct 11 08:59:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfxdA-000210-Px; Thu, 11 Oct 2007 08:59:12 -0400 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1Ifxd9-00020a-Sw for nsis-confirm+ok@megatron.ietf.org; Thu, 11 Oct 2007 08:59:11 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ifxd9-00020S-Gq for nsis@ietf.org; Thu, 11 Oct 2007 08:59:11 -0400 Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ifxd9-00010M-59 for nsis@ietf.org; Thu, 11 Oct 2007 08:59:11 -0400 Received: from irams2.ira.uni-karlsruhe.de ([141.3.10.82]) by iramx2.ira.uni-karlsruhe.de with esmtps id 1Ifxd5-00053q-Jx; Thu, 11 Oct 2007 14:59:09 +0200 Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5]) by irams2.ira.uni-karlsruhe.de with esmtps id 1Ifxd4-0004NS-OF; Thu, 11 Oct 2007 14:59:07 +0200 Received: from i72ms.tm.uni-karlsruhe.de ([141.3.70.5] helo=smtp.ipv6.tm.uni-karlsruhe.de) by irams1.ira.uni-karlsruhe.de with esmtps id 1Ifxd4-0006Is-GI; Thu, 11 Oct 2007 14:59:06 +0200 Received: from vorta.ipv6.tm.uni-karlsruhe.de (vorta.ipv6.tm.uni-karlsruhe.de [IPv6:2001:638:204:6:207:e9ff:fe0c:5e44]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id 02D552FC00C; Thu, 11 Oct 2007 14:59:06 +0200 (CEST) Received: from localhost ([127.0.0.1]) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.44) id 1Ifxd3-0000X5-6Z; Thu, 11 Oct 2007 14:59:05 +0200 Message-ID: <470E1E18.5010700@tm.uka.de> Date: Thu, 11 Oct 2007 14:59:04 +0200 From: Roland Bless Organization: Institute of Telematics, University of Karlsruhe User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060111 Thunderbird/1.5 Mnenhy/0.7.3.0 MIME-Version: 1.0 To: Thomas Narten References: <200710111233.l9BCXhrU011347@localhost.localdomain> In-Reply-To: <200710111233.l9BCXhrU011347@localhost.localdomain> X-Enigmail-Version: 0.94.4.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-Spam-Status: No X-Spam-Score: -1.3 (-) X-Spam-Report: -1.4 ALL_TRUSTED Passed through trusted hosts only via SMTP 0.1 AWL AWL: From: address is in the auto white-list X-Spam-Host: irams2.ira.uni-karlsruhe.de X-ATIS-Checksum: v3zoCAcc32ckk X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: Jukka MJ Manner , NSIS Working Group , int-area@lists.ietf.org Subject: [NSIS] Re: [Int-area] RAO for IPv4 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 Thomas, Thomas Narten wrote: > Why exactly is it necessary to have the IPv4 and IPv6 number space be > consistent? What is the technical requirement/benefit here? > > My own sense is that this would be "nice to have", but it is certainly > not required, and I don't see that having the numbering space be strictly > synchronized as providing compelling technical benefit. > > What am I missing? I would say: If the numbers are aligned you don't need separate mapping tables for IPv4 and IPv6. The idea is that you map an NSLP ID, i.e. a an identifier for a specific signaling application like QoS NSLP or NAT/FW NSLP to an RAO value as demultiplexer. In this case you would only need one mapping table and not two different tables for v4/v6. Technically you can have separate v4/v6 RAO tables, but using only one would be easier to implement etc. Roland _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Oct 11 10:09:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfyiI-0003Zq-D3; Thu, 11 Oct 2007 10:08:34 -0400 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1IfyiH-0003Zd-IM for nsis-confirm+ok@megatron.ietf.org; Thu, 11 Oct 2007 10:08:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfyiH-0003ZM-8a for nsis@ietf.org; Thu, 11 Oct 2007 10:08:33 -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 1IfyiA-00030Z-PA for nsis@ietf.org; Thu, 11 Oct 2007 10:08:33 -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; Thu, 11 Oct 2007 17:08:10 +0300 id 0008056B.470E2E4A.000059EB Date: Thu, 11 Oct 2007 17:08:09 +0300 (EEST) From: Jukka MJ Manner To: Roland Bless In-Reply-To: <470E1E18.5010700@tm.uka.de> Message-ID: References: <200710111233.l9BCXhrU011347@localhost.localdomain> <470E1E18.5010700@tm.uka.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: Thomas Narten , int-area@lists.ietf.org, NSIS Working Group Subject: [NSIS] Re: [Int-area] RAO for IPv4 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 Exactly. There is no technical reason that forces a unified mapping, but it makes things simpler (which is always a good idea). Jukka On Thu, 11 Oct 2007, Roland Bless wrote: > Hi Thomas, > > Thomas Narten wrote: > > Why exactly is it necessary to have the IPv4 and IPv6 number space be > > consistent? What is the technical requirement/benefit here? > > > > My own sense is that this would be "nice to have", but it is certainly > > not required, and I don't see that having the numbering space be strictly > > synchronized as providing compelling technical benefit. > > > > What am I missing? > > I would say: > If the numbers are aligned you don't need separate > mapping tables for IPv4 and IPv6. > The idea is that you map an NSLP ID, i.e. a an identifier > for a specific signaling application like QoS NSLP or > NAT/FW NSLP to an RAO value as demultiplexer. > In this case you would only > need one mapping table and not two different tables for > v4/v6. Technically you can have separate v4/v6 RAO tables, > but using only one would be easier to implement etc. > > Roland > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Oct 11 10:31:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ifz48-0004eM-EP; Thu, 11 Oct 2007 10:31:08 -0400 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1Ifz47-0004dn-Ha for nsis-confirm+ok@megatron.ietf.org; Thu, 11 Oct 2007 10:31:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ifz47-0004dU-7i; Thu, 11 Oct 2007 10:31:07 -0400 Received: from mta3.dhs.gov ([152.121.181.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ifz3y-0003uJ-KD; Thu, 11 Oct 2007 10:31:07 -0400 Received: from dhsmail2.dhs.gov (dhsmail2.dhs.gov [161.214.63.27]) by mta3.dhs.gov with ESMTP; Thu, 11 Oct 2007 10:30:43 -0400 Received: from dhsmail2.dhs.gov (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 9B4EE2C00; Thu, 11 Oct 2007 10:30:42 -0400 (EDT) Received: from ZAU1UG-0351.DHSNET.DS1.DHS (mx7.hq.dhs.gov [161.214.98.195]) by dhsmail2.dhs.gov (Postfix) with ESMTP id 907522508; Thu, 11 Oct 2007 10:30:42 -0400 (EDT) Received: from ZAU1UG-0308.DHSNET.DS1.DHS ([10.15.18.80]) by ZAU1UG-0351.DHSNET.DS1.DHS with Microsoft SMTPSVC(6.0.3790.1830); Thu, 11 Oct 2007 10:30:36 -0400 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 Date: Thu, 11 Oct 2007 10:29:19 -0400 Message-Id: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Tsvwg] WGLC for draft-ietf-dime-qos-parameters-01 Thread-Index: AcgEz4SaZT+XWIPvRx6Rtb+XW3YE5gHQ5dBt References: <470202BF.4000701@gmx.net> From: "Nguyen, An P" To: "Hannes Tschofenig" , , "radext mailing list" , , "tsvwg IETF list" X-OriginalArrivalTime: 11 Oct 2007 14:30:36.0776 (UTC) FILETIME=[4A22B680:01C80C13] X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: Subject: [NSIS] RE: [Tsvwg] WGLC for draft-ietf-dime-qos-parameters-01 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, Just a minor comment... Obviously, there are 14 QoS parameter IDs in the = draft. It is not clear to me that whether the QoS ID values are in the = 2nd or the 3rd bit of the second byte of TLV format. Pictorially, they = stay between the 2nd and the 3rd bits. :-) Regards, An -----Original Message----- From: tsvwg-bounces@ietf.org on behalf of Hannes Tschofenig Sent: Tue 10/2/2007 4:35 AM To: dime@ietf.org; 'radext mailing list'; nsis@ietf.org; tsvwg IETF list Subject: [Tsvwg] WGLC for draft-ietf-dime-qos-parameters-01 =20 Hi all, this message marks the issuance of a working group last call (WGLC) on=20 DIME's Internet Draft entitled "Quality of Service Parameters for Usage=20 with the AAA Framework " (draft-ietf-dime-qos-parameters-01). You may=20 view this document at http://tools.ietf.org/html/draft-ietf-dime-qos-parameters-01 Please post comments and questions to the DIME mailing list (or to the=20 authors) no later than 16 October 2007. Ciao Hannes & Dave _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Oct 12 03:45:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgFBb-0004h8-Ri; Fri, 12 Oct 2007 03:43:55 -0400 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1IgFBa-0004gF-Bt for nsis-confirm+ok@megatron.ietf.org; Fri, 12 Oct 2007 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 1IgFBa-0004fm-1z for nsis@ietf.org; Fri, 12 Oct 2007 03:43:54 -0400 Received: from smtp0.netlab.nec.de ([195.37.70.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IgFBT-0008RX-Ei for nsis@ietf.org; Fri, 12 Oct 2007 03:43:54 -0400 Received: from localhost (atlas1.office [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id CFB6A2804A576 for ; Fri, 12 Oct 2007 09:43:36 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office) Received: from smtp0.netlab.nec.de ([127.0.0.1]) by localhost (atlas1.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q-OXktyEvmmK for ; Fri, 12 Oct 2007 09:43:36 +0200 (CEST) Received: from mx1.office (mx1.office [10.1.1.23]) by smtp0.netlab.nec.de (Postfix) with ESMTP id AC3272804A575 for ; Fri, 12 Oct 2007 09:43:31 +0200 (CEST) Received: from mx1.office ([10.1.1.23]) by mx1.office with Microsoft SMTPSVC(6.0.3790.3959); Fri, 12 Oct 2007 09:43:31 +0200 Received: from [192.168.1.2] ([10.17.6.253]) by mx1.office over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Fri, 12 Oct 2007 09:43:31 +0200 Mime-Version: 1.0 (Apple Message framework v752.3) To: nsis Message-Id: <47289FF0-16B9-4B65-A83E-F61225BC93D2@netlab.nec.de> References: From: Martin Stiemerling Date: Fri, 12 Oct 2007 09:43:30 +0200 X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 12 Oct 2007 07:43:31.0673 (UTC) FILETIME=[960D8490:01C80CA3] X-Spam-Score: 0.6 (/) X-Scan-Signature: 187ae6c2eea74946c0ab707161f6256d Subject: [NSIS] Fwd: Internet-Drafts Submission Cutoff Dates for the 70th IETF Meeting in Vancouver, BC, Canada 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="===============0605250158==" Errors-To: nsis-bounces@ietf.org --===============0605250158== Content-Type: multipart/alternative; boundary=Apple-Mail-20--880554059 --Apple-Mail-20--880554059 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed FYI. Anfang der weitergeleiteten E-Mail: > Von: ietf-secretariat@ietf.org > Datum: 12. Oktober 2007 06:00:02 MESZ > An: ietf-announce@ietf.org > Betreff: Internet-Drafts Submission Cutoff Dates for the 70th IETF > Meeting in Vancouver, BC, Canada > > > There are two (2) Internet-Draft cutoff dates for the 70th > IETF Meeting in Vancouver, BC, Canada: > > November 12th: Cutoff Date for Initial (i.e., version -00) > Internet-Draft Submissions > > All initial Internet-Drafts (version -00) must be submitted by Monday, > November 12th at 9:00 AM ET (14:00 UTC/GMT). As always, all initial > submissions with a > filename beginning with "draft-ietf" must be approved by the > appropriate WG Chair before they can be processed or announced. The > Secretariat would appreciate receiving WG Chair approval by Monday, > November 5th at 9:00 AM ET (14:00 UTC/GMT). > > November (14:00 UTC/GMT): Cutoff Date for Revised (i.e., version > -01 and higher) > Internet-Draft Submissions > > All revised Internet-Drafts (version -01 and higher) must be submitted > by Monday, November 19th at 9:00 AM ET (14:00 UTC/GMT). > > Initial and revised Internet-Drafts received after their respective > cutoff dates will not be made available in the Internet-Drafts > directory or announced until on or after Monday, December 3rd at 9:00 > AM ET (14:00 UTC/GMT), when Internet-Draft posting resumes. Please > do not wait until > the last minute to submit. > > Thank you for your understanding and cooperation. If you have any > questions or concerns, then please send a message to > internet-drafts@ietf.org. > > The IETF Secretariat > > FYI: The Internet-Draft cutoff dates as well as other significant > dates > for the 70th IETF Meeting can be found at http://www.ietf.org/ > meetings/cutoff_dates_70.html. > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf-announce stiemerling@netlab.nec.de NEC Laboratories Europe - Network Research Division NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 --Apple-Mail-20--880554059 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 FYI.

Anfang der = weitergeleiteten E-Mail:

Datum: 12. Oktober 2007 06:00:02 = MESZ
An: ietf-announce@ietf.org
Betreff: Internet-Drafts Submission Cutoff = Dates for the 70th IETF=A0 = Meeting in Vancouver, BC, Canada=A0


There are two = (2) Internet-Draft cutoff dates for the 70th=A0
IETF = Meeting in Vancouver, BC, Canada:

November 12th: Cutoff Date for = Initial (i.e., version -00)=A0
=A0

All initial = Internet-Drafts (version -00) must be submitted by Monday,=A0
November = 12th at 9:00 AM ET (14:00 UTC/GMT). As always, all initial submissions = with a=A0
filename beginning with "draft-ietf" must be = approved by the=A0
appropriate WG Chair before they can be processed or = announced.=A0 The=A0
=A0
November 5th at 9:00 AM ET (14:00 = UTC/GMT).

November=A0 = (14:00 UTC/GMT): Cutoff Date for Revised (i.e., version -01 and = higher)=A0
Internet-Draft Submissions=A0

All revised = Internet-Drafts (version -01 and higher) must be submitted=A0
by = Monday, November 19th at 9:00 AM ET (14:00 UTC/GMT).

Initial = and revised Internet-Drafts received after their respective=A0
cutoff = dates will not be made available in the Internet-Drafts=A0
=A0
AM ET (14:00 UTC/GMT), when Internet-Draft posting = resumes.=A0 Please do not = wait until=A0
the last minute to submit.

Thank = you for your understanding and cooperation. If you have any=A0
=A0
internet-drafts@ietf.org.

The IETF = Secretariat

FYI: The Internet-Draft cutoff dates as well as = other significant dates
for the 70th = IETF Meeting can be found at http://www.ietf= .org/meetings/cutoff_dates_70.html.

IETF-Announce mailing list
https://www1= .ietf.org/mailman/listinfo/ietf-announce
=

stiemerling@netlab.nec.de
NEC Laboratories Europe - Network Research = Division

NEC Europe = Limited |=A0Registered Office: NEC House, 1 Victoria Road, London W3 6BL = |=A0Registered in England 2832014

=

= --Apple-Mail-20--880554059-- --===============0605250158== 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 --===============0605250158==-- From nsis-bounces@ietf.org Sun Oct 14 14:46:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ih8SG-0004wL-D0; Sun, 14 Oct 2007 14:44:48 -0400 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1Ih8SF-0004sH-Ov for nsis-confirm+ok@megatron.ietf.org; Sun, 14 Oct 2007 14:44:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ih8SF-0004rU-Ep for nsis@ietf.org; Sun, 14 Oct 2007 14:44:47 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Ih8S6-0001na-Tz for nsis@ietf.org; Sun, 14 Oct 2007 14:44:45 -0400 Received: (qmail invoked by alias); 14 Oct 2007 18:44:10 -0000 Received: from p549861B9.dip.t-dialin.net (EHLO [192.168.1.4]) [84.152.97.185] by mail.gmx.net (mp004) with SMTP; 14 Oct 2007 20:44:10 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+kyvV3IRWk+nxroEIrC9Sku8W4xLaasW5lJGuq+b 7NzNEgEmi3KhJO Message-ID: <4712637A.2020500@gmx.net> Date: Sun, 14 Oct 2007 21:44:10 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: tsvwg IETF list , "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.2 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Cc: dime@ietf.org Subject: [NSIS] draft-ietf-tsvwg-emergency-rsvp-03.txt and draft-ietf-nsis-qspec-17.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 Hi all, during the WGLC review comments for draft-ietf-dime-qos-attributes-02.txt and draft-ietf-dime-qos-parameters-01 we noticed that there is a mismatch regarding the IANA considerations for Resource Priority elements. Section 5 of says: " This document defines an ALRP Priority field in section 3.2 that contains a numerical value identifying the namespace of the application-level resource priority. The IANA already maintains the Resource-Priority Namespaces registry (under the SIP Parameters) listing all such namespace. However, that registry does not currently allocate a numerical value to each namespace. Hence, this document requests the IANA to extend the Resource-Priority Namespace registry in the following ways: - a new column should be added to the registry - the title of the new column should be "Namespace numerical Value *" - in the Legend, add a line saying "Namespace numerical Value = the unique numerical value identifying the namespace" - add a line at the bottom of the registry stating the following "* : [RFCXXX] " where XXX is the RFC number of the present document - allocate an actual numerical value to each namespace in the registry and state that value in the new "Namespace numerical Value *" column. A numerical value should be allocated immediately by IANA to all existing namespace. Then, in the future, IANA should automatically allocate a numerical value to any new namespace added to the registry. [draft-ietf-nsis-qspec] also uses numerical values for Resource- Priority Namespaces. The request IANA to create a new registry to allocate numerical values to each namespace. We suggest that the approach above be followed instead (i.e. extend the existing registry) and that [draft-ietf-nsis-qspec] also makes use of the values defined in the new "Namespace numerical Value *" column of the extended existing Resource-Priority Namespace registry. In any case, the IANA should only do one of the two approaches (an not both). " draft-ietf-nsis-qspec-17.txt says the following " RPH Priority Parameter (8 bits): dsn namespace: The allocation policies are as follows: 0-63: Standards Action 64-255: Reserved drsn namespace: The allocation policies are as follows: 0-63: Standards Action 64-255: Reserved Q735 namespace: The following values are allocated by this specification: 0-4: assigned as specified in Section 6.2.10: Q735 priority 4: q735.4 3: q735.3 2: q735.2 1: q735.1 0: q735.0 The allocation policies for further values are as follows: 5-63: Standards Action 64-255: Reserved ets namespace: The following values are allocated by this specification: 0-4: assigned as specified in Section 6.2.10: ETS priority 4: ets.4 3: ets.3 2: ets.2 1: ets.1 0: ets.0 The allocation policies for further values are as follows: 5-63: Standards Action 64-255: Reserved wts namespace: The following values are allocated by this specification: 0-4: assigned as specified in Section 6.2.10: WPS priority 4: wps.4 3: wps.3 2: wps.2 1: wps.1 0: wps.0 The allocation policies for further values are as follows: 5-63: Standards Action 64-255: Reserved " Clearly, there is a mismatch regarding the registration of the same values. I would therefore suggest that the authors get together and determine a solution. In draft-ietf-dime-qos-parameters-01 we unfortunately need to refer to a registry and would therefore appreciate to have a resolution soon. Furthermore, Ken posted a review of draft-ietf-dime-qos-parameters-01 to the DIME list that also points to an unnecessary constraint (in his view) regarding the usage of the priority parameters listed in Section 6.2.10. Ken's review can be found at: http://www1.ietf.org/mail-archive/web/dime/current/msg02089.html Ciao Hannes _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Oct 15 03:59:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhKpP-0006Hd-H5; Mon, 15 Oct 2007 03:57:31 -0400 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1IhKpO-0006H8-5J for nsis-confirm+ok@megatron.ietf.org; Mon, 15 Oct 2007 03:57:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhKpN-0006Gm-Ch for nsis@ietf.org; Mon, 15 Oct 2007 03:57:29 -0400 Received: from smtp0.netlab.nec.de ([195.37.70.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IhKpG-0006Bl-Ks for nsis@ietf.org; Mon, 15 Oct 2007 03:57:29 -0400 Received: from localhost (atlas1.office [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 39EEA2804A9A4 for ; Mon, 15 Oct 2007 09:57:22 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office) Received: from smtp0.netlab.nec.de ([127.0.0.1]) by localhost (atlas1.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u04+PFxKwIhC for ; Mon, 15 Oct 2007 09:57:22 +0200 (CEST) Received: from mx1.office (mx1.office [10.1.1.23]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 1529F2801E240 for ; Mon, 15 Oct 2007 09:57:17 +0200 (CEST) Received: from mx1.office ([10.1.1.23]) by mx1.office with Microsoft SMTPSVC(6.0.3790.3959); Mon, 15 Oct 2007 09:57:17 +0200 Received: from [10.1.1.109] ([10.1.1.109]) by mx1.office over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 15 Oct 2007 09:57:17 +0200 Mime-Version: 1.0 (Apple Message framework v752.3) To: nsis Message-Id: References: From: Martin Stiemerling Date: Mon, 15 Oct 2007 09:57:15 +0200 X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 15 Oct 2007 07:57:17.0040 (UTC) FILETIME=[013FC700:01C80F01] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7118f330e2af0a096ba071c5e99ca10e Subject: [NSIS] Fwd: REVISED Internet-Draft Submission Cutoff Dates for the 70th IETF Meeting in Vancouver, BC, Canada 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="===============0695448142==" Errors-To: nsis-bounces@ietf.org --===============0695448142== Content-Type: multipart/alternative; boundary=Apple-Mail-17--620529514 --Apple-Mail-17--620529514 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed FYI, especially for the new I-D submission tool: > https://datatracker.ietf.org/idst/upload.cgi Martin Anfang der weitergeleiteten E-Mail: > Von: IETF Secretariat > Datum: 12. Oktober 2007 17:45:00 MESZ > An: IETF Announcement list > Betreff: REVISED Internet-Draft Submission Cutoff Dates for the > 70th IETF Meeting in Vancouver, BC, Canada > > There are two (2) Internet-Draft cutoff dates for the 70th IETF > Meeting in Vancouver, BC, Canada: > > November 12th: Cutoff Date for Initial (i.e., version -00) Internet- > Draft > Submissions > > All initial Internet-Drafts (version -00) must be submitted by Monday, > November 12th at 9:00 AM ET (14:00 UTC/GMT). The only exception is for > version -00 WG drafts that replace existing non-WG drafts. Such > drafts > may be submitted until the cutoff date for version -01 and higher > drafts. > As always, all initial submissions with a filename beginning with > "draft-ietf" must be approved by the appropriate WG Chair before > they can > be processed or announced. The Secretariat would appreciate > receiving WG > Chair approval by Monday, November 5th at 9:00 AM ET (14:00 UTC/GMT). > > November 19th: Cutoff Date for Revised (i.e., version -01 and higher) > Internet-Draft Submissions > > All revised Internet-Drafts (version -01 and higher) must be > submitted by > Monday, November 19th at 9:00 AM ET (14:00 UTC/GMT). > > Initial and revised Internet-Drafts submitted after their respective > cutoff dates will not be made available in the Internet-Drafts > directory > or announced until on or after Monday, December 3rd at 9:00 AM ET > (14:00 > UTC/GMT), when Internet-Draft posting resumes. Please do not wait > until > the last minute to submit. > > The Secretariat encourages you to submit your Internet-Drafts via the > Internet-Draft Submission Tool (IDST) > https://datatracker.ietf.org/idst/upload.cgi. If you are unable to > do so, > then you may still submit your Internet-Drafts manually by sending > them to > internet-drafts@ietf.org. If you are submitting a version -00 WG > draft > that replaces non-WG draft, then you must submit it manually as the > current IDST cannot handle replacements. Please be sure to state > that one > draft replaces another in the cover note that accompanies your > submission. Also, please note that the IDST will not accept drafts > submitted after their respective cutoff dates. > > Thank you for your understanding and cooperation. If you have any > questions or concerns, then please send a message to > internet-drafts@ietf.org. > > The IETF Secretariat > > FYI: The Internet-Draft cutoff dates as well as other significant > dates > for the 70th IETF Meeting can be found at > http://www3.ietf.org/meetings/70-cutoff_dates.html. > > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf-announce stiemerling@netlab.nec.de NEC Laboratories Europe - Network Research Division NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 --Apple-Mail-17--620529514 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 FYI,=A0especially for the new = I-D submission tool:
https://datatracker.= ietf.org/idst/upload.cgi

=A0 = Martin

Anfang der weitergeleiteten E-Mail:

Von: = IETF Secretariat <ietf-secretariat@ietf.org>= ;
Datum: 12. Oktober 2007 17:45:00 = MESZ
An: IETF Announcement list <ietf-announce@ietf.org>
Betreff: REVISED Internet-Draft Submission = Cutoff Dates for the 70th IETF=A0 = Meeting in Vancouver, BC, Canada=A0

There = are two (2) Internet-Draft cutoff dates for the 70th IETF=A0
Meeting = in Vancouver, BC, Canada:

November 12th: Cutoff Date for = Initial (i.e., version -00) Internet-Draft
=A0

All = initial Internet-Drafts (version -00) must be submitted by = Monday,
November 12th at 9:00 AM ET = (14:00 UTC/GMT). The only exception is for
version = -00 WG drafts that replace existing non-WG drafts.=A0 Such drafts
may be submitted until the cutoff date for version = -01 and higher drafts.
As always, all initial = submissions with a filename beginning with
be processed or announced.=A0 The Secretariat would = appreciate receiving WG
Chair = approval by Monday, November 5th at 9:00 AM ET (14:00 = UTC/GMT).

November 19th: Cutoff Date for Revised (i.e., = version -01 and higher)
=A0

All revised = Internet-Drafts (version -01 and higher) must be submitted by
Monday, November 19th at 9:00 AM ET (14:00 = UTC/GMT).

Initial and revised Internet-Drafts submitted after = their respective
cutoff dates will not be made = available in the Internet-Drafts directory
or = announced until on or after Monday, December 3rd at 9:00 AM ET = (14:00
UTC/GMT), when Internet-Draft = posting resumes.=A0 Please = do not wait until
the last minute to = submit.

The Secretariat encourages you to submit your = Internet-Drafts via the
then you may still submit your Internet-Drafts = manually by sending them to
internet-drafts@ietf.org.=A0 If you are submitting a = version -00 WG draft
that replaces non-WG draft, = then you must submit it manually as the
current = IDST cannot handle replacements.=A0 = Please be sure to state that one
draft = replaces another in the cover note that accompanies your=A0
=A0 Also, = please note that the IDST will not accept drafts
submitted after their respective cutoff = dates.

Thank you for your understanding and cooperation. If = you have any
questions or concerns, then = please send a message to
internet-drafts@ietf.org.

The IETF = Secretariat

FYI: The Internet-Draft cutoff dates as well as = other significant dates
for the 70th = IETF Meeting can be found at


IETF-Announce mailing list
https://www1= .ietf.org/mailman/listinfo/ietf-announce
=

stiemerling@netlab.nec.de
NEC Laboratories Europe - Network Research = Division

NEC Europe = Limited |=A0Registered Office: NEC House, 1 Victoria Road, London W3 6BL = |=A0Registered in England 2832014

=

= --Apple-Mail-17--620529514-- --===============0695448142== 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 --===============0695448142==-- From nsis-bounces@ietf.org Mon Oct 15 08:17:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhOsM-0001Ut-8n; Mon, 15 Oct 2007 08:16:50 -0400 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1IfxEv-0001N7-2y for nsis-confirm+ok@megatron.ietf.org; Thu, 11 Oct 2007 08:34:09 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfxEu-0001HM-Oz for nsis@ietf.org; Thu, 11 Oct 2007 08:34:08 -0400 Received: from e36.co.us.ibm.com ([32.97.110.154]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IfxEa-000051-6V for nsis@ietf.org; Thu, 11 Oct 2007 08:33:48 -0400 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e36.co.us.ibm.com (8.13.8/8.13.8) with ESMTP id l9BCXlGU008839 for ; Thu, 11 Oct 2007 08:33:47 -0400 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d03relay04.boulder.ibm.com (8.13.8/8.13.8/NCO v8.5) with ESMTP id l9BCXknW420844 for ; Thu, 11 Oct 2007 06:33:46 -0600 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l9BCXkxL019034 for ; Thu, 11 Oct 2007 06:33:46 -0600 Received: from localhost.localdomain (wecm-9-67-191-97.wecm.ibm.com [9.67.191.97]) by d03av02.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l9BCXi40018917 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 11 Oct 2007 06:33:46 -0600 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.14.1/8.12.5) with ESMTP id l9BCXhrU011347; Thu, 11 Oct 2007 08:33:43 -0400 Message-Id: <200710111233.l9BCXhrU011347@localhost.localdomain> To: Jukka MJ Manner In-reply-to: References: Comments: In-reply-to Jukka MJ Manner message dated "Thu, 11 Oct 2007 14:58:15 +0300." Date: Thu, 11 Oct 2007 08:33:43 -0400 From: Thomas Narten X-Spam-Score: -4.0 (----) X-Scan-Signature: 93238566e09e6e262849b4f805833007 X-Mailman-Approved-At: Mon, 15 Oct 2007 08:16:49 -0400 Cc: int-area@lists.ietf.org, NSIS Working Group Subject: [NSIS] Re: [Int-area] RAO for IPv4 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 >From the draft: > 4.2. IANA Considerations for IPv6 Router Alert Option Values > > The registry for IPv6 Router Alert Option Values should continue to > be maintained as specified in [RFC2711]. However, when a new > allocation is made in this registry an identical registration MUST be > made in the IPv4 Router Alert Option Values registry, or that value > MUST be reserved. In the case that it is reserved rather than > allocated, the registry entry should say "Reserved (not to be > allocated) - Note: This value is allocated in the IPv4 Router Alert > Options registry". Why exactly is it necessary to have the IPv4 and IPv6 number space be consistent? What is the technical requirement/benefit here? My own sense is that this would be "nice to have", but it is certainly not required, and I don't see that having the numbering space be strictly synchronized as providing compelling technical benefit. What am I missing? Thomas _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Oct 15 08:18:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhOsM-0001Uy-GO; Mon, 15 Oct 2007 08:16:50 -0400 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1IgHWP-0000Fi-4r for nsis-confirm+ok@megatron.ietf.org; Fri, 12 Oct 2007 06:13:33 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgHWO-0000Fa-R1 for nsis@ietf.org; Fri, 12 Oct 2007 06:13:32 -0400 Received: from kuber.nabble.com ([216.139.236.158]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IgHWO-0006eF-IU for nsis@ietf.org; Fri, 12 Oct 2007 06:13:32 -0400 Received: from isper.nabble.com ([192.168.236.156]) by kuber.nabble.com with esmtp (Exim 4.63) (envelope-from ) id 1IgHWN-0005Ez-Ue for nsis@ietf.org; Fri, 12 Oct 2007 03:13:31 -0700 Message-ID: <13172463.post@talk.nabble.com> Date: Fri, 12 Oct 2007 03:13:31 -0700 (PDT) From: ranu_hai To: nsis@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Nabble-From: ranu2006@gmail.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 X-Mailman-Approved-At: Mon, 15 Oct 2007 08:16:49 -0400 Subject: [NSIS] Displaying Japanese text in Message Box 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 want to dispaly Japanese text in Message box .But I was not able to add Japanese text in NSIS Script file nor I was able to save that file . Is there any way where in I can add Japanese text in NSIS Script file ? -- View this message in context: http://www.nabble.com/Displaying-Japanese-text-in-Message-Box-tf4612535.html#a13172463 Sent from the IETF - nsis mailing list archive at Nabble.com. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Oct 16 03:05:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhgTV-0000SE-Vz; Tue, 16 Oct 2007 03:04:22 -0400 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1IhgTT-0000Ru-Gr for nsis-confirm+ok@megatron.ietf.org; Tue, 16 Oct 2007 03:04:19 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhgT2-0000Ex-05; Tue, 16 Oct 2007 03:03:52 -0400 Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IhgT1-0007OT-FL; Tue, 16 Oct 2007 03:03:51 -0400 Received: from irams2.ira.uni-karlsruhe.de ([141.3.10.82]) by iramx2.ira.uni-karlsruhe.de with esmtps id 1IhgSx-0002FA-Mt; Tue, 16 Oct 2007 09:03:49 +0200 Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5]) by irams2.ira.uni-karlsruhe.de with esmtps id 1IhgSw-0006Z3-JG; Tue, 16 Oct 2007 09:03:47 +0200 Received: from i72ms.tm.uni-karlsruhe.de ([141.3.70.5] helo=smtp.ipv6.tm.uni-karlsruhe.de) by irams1.ira.uni-karlsruhe.de with esmtps id 1IhgSw-0000as-BL; Tue, 16 Oct 2007 09:03:46 +0200 Received: from vorta.ipv6.tm.uni-karlsruhe.de (vorta.ipv6.tm.uni-karlsruhe.de [IPv6:2001:638:204:6:207:e9ff:fe0c:5e44]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id 922092FC00C; Tue, 16 Oct 2007 09:03:45 +0200 (CEST) Received: from localhost ([127.0.0.1]) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.44) id 1IhgSv-0004xz-7D; Tue, 16 Oct 2007 09:03:45 +0200 Message-ID: <47146250.1000504@tm.uka.de> Date: Tue, 16 Oct 2007 09:03:44 +0200 From: Roland Bless Organization: Institute of Telematics, University of Karlsruhe User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060111 Thunderbird/1.5 Mnenhy/0.7.3.0 MIME-Version: 1.0 Subject: Re: [NSIS] WGLC for draft-ietf-dime-qos-parameters-01 References: <470202BF.4000701@gmx.net> In-Reply-To: <470202BF.4000701@gmx.net> X-Enigmail-Version: 0.94.4.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Status: No X-Spam-Score: -1.2 (-) X-Spam-Report: -1.4 ALL_TRUSTED Passed through trusted hosts only via SMTP 0.2 MISSING_HEADERS Missing To: header 0.0 AWL AWL: From: address is in the auto white-list X-Spam-Host: irams2.ira.uni-karlsruhe.de X-ATIS-Checksum: v3zoCAcc32ckk X-Spam-Score: 1.6 (+) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: dime@ietf.org, 'radext mailing list' , "nsis@ietf.org" , tsvwg IETF list 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, Hannes Tschofenig wrote: > http://tools.ietf.org/html/draft-ietf-dime-qos-parameters-01 I'm not a AAA expert, so probably I don't get the point. Unfortunately, I'm not very content with the draft, so I have some major comments: 1) The draft says: "The payloads used to carry these QoS parameters are opaque for the AAA client and the AAA server itself and interpreted by the respective Resource Management Function." Since the rest of the draft seems to contain larger copy&paste regions from the NSIS-QSPEC-Draft I'd like to ask: why is it not sufficient to use a QSPEC object as it is. To me it makes no sense to do another format rewriting when creating a Diameter request (QAR) from an NSIS RESERVE for example. Is there any technical reason to not use a QSPEC object as it is? This would allow for an easy interworking between NSIS and AAA and to re-use larger parts of the RMF code. Conveying the parameters for AAA in a different way is IMHO not necessary and source for new implementation errors... If there are technical reasons why using the QSPEC directly doesn't work, please state it in the draft. 2) The draft doesn't provide a meaningful definition of which parameters should be present together etc. It is only an unstructured list of parameter objects and there is no hint given about which combinations are allowed or meaningful etc. Regards, Roland _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Oct 16 03:59:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhhJX-0002QL-2g; Tue, 16 Oct 2007 03:58:07 -0400 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1IhhJV-0002Ot-Le for nsis-confirm+ok@megatron.ietf.org; Tue, 16 Oct 2007 03:58:05 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhhFY-0008AK-0n for nsis@ietf.org; Tue, 16 Oct 2007 03:54:00 -0400 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IhhFX-0000V2-2v for nsis@ietf.org; Tue, 16 Oct 2007 03:53:59 -0400 Received: (qmail invoked by alias); 16 Oct 2007 07:53:58 -0000 Received: from socks-ic-ext.mch.sbs.de (EHLO [194.138.17.187]) [194.138.17.187] by mail.gmx.net (mp029) with SMTP; 16 Oct 2007 09:53:58 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18Mih0EbSUMqmR8RStrVgbqMia9B08oTuc3ft9U2g DhFMm2pfWl6Bym Message-ID: <47146E15.9090200@gmx.net> Date: Tue, 16 Oct 2007 10:53:57 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Roland Bless Subject: Re: [NSIS] WGLC for draft-ietf-dime-qos-parameters-01 References: <470202BF.4000701@gmx.net> <47146250.1000504@tm.uka.de> In-Reply-To: <47146250.1000504@tm.uka.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: 5ebbf074524e58e662bc8209a6235027 Cc: dime@ietf.org, 'radext mailing list' , "nsis@ietf.org" , tsvwg IETF list 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 Roland, thanks for your review. Please find a few comments below: Roland Bless wrote: > Hi Hannes and all, > > Hannes Tschofenig wrote: > > >> http://tools.ietf.org/html/draft-ietf-dime-qos-parameters-01 >> > > I'm not a AAA expert, so probably I don't get the point. > Unfortunately, I'm not very content with the draft, so I have some major > comments: > 1) The draft says: > "The payloads used to carry these QoS parameters are opaque for the > AAA client and the AAA server itself and interpreted by the > respective Resource Management Function." > > Since the rest of the draft seems to contain larger copy&paste > regions from the NSIS-QSPEC-Draft I'd like to ask: why is it not > sufficient to use a QSPEC object as it is. To me it makes no sense > to do another format rewriting when creating a Diameter request > (QAR) from an NSIS RESERVE for example. Is there any technical > reason to not use a QSPEC object as it is? This would allow for > an easy interworking between NSIS and AAA and to re-use larger parts > of the RMF code. Conveying the parameters for AAA > in a different way is IMHO not necessary and source for new > implementation errors... > If there are technical reasons why using the QSPEC directly doesn't > work, please state it in the draft. > There are a couple of reasons why we did not want to re-use the QSPEC draft as is. The first reason is that the Diameter QoS attribute document and the Diameter QoS application document, see http://www.ietf.org/internet-drafts/draft-ietf-dime-diameter-qos-01.txt http://www.ietf.org/internet-drafts/draft-ietf-dime-qos-attributes-02.txt are independent of NSIS. There is no dependency between NSIS and these documents although the Diameter interworking may also be used for NSIS. The second reason is that the QSPEC draft has a different focus in the sense that the description that is used for the front-end protocol (in this case NSIS) is somewhat different to the interaction that takes place at the backend. If you go through the QSPEC draft then you will notice that many aspects in the draft are so specific to the NSIS interactions. Unfortunately, the QSPEC is not just a collection of parameters. We did not want to let the reader figure out which parts of the document are relevant for them even if they use the Diameter QoS work for a different purpose (such as in the interaction with RSVP). In fact, in previous draft versions we just made references to the QSPEC and when this was brought to other SDOs then this was a real show stopper since people got totally confused. The third reason is that we are changing the format of the QSPEC headers. We tried to keep the changes at a minimum but still they are different. Some time back we even considered to use a Diameter specific format. There are still comments floating around suggesting it but at the moment the plain QoS parameters are still in the format of the QSPEC. We also make use of the registry created for the QoS parameters; some of my recent mails referred to the mismatch between the QSPEC registry and the registry created by a document in the TSVWG. The final reason is that we are changing the semantic of the extensibility mechanism. The concept of QoS models (QoSM) as defined in the QSPEC and the requirements for defining a QoSM does not work with the Diameter usage. Hence, we had to change it. See Section 5 and 6 of http://www.ietf.org/internet-drafts/draft-ietf-dime-qos-parameters-01.txt I believe these reasons justify a new document. > 2) The draft doesn't provide a meaningful definition of which parameters > should be present together etc. It is only an unstructured list of > parameter objects and there is no hint given about which combinations > are allowed or meaningful etc. > That's true and I don't think draft-ietf-dime-qos-parameters-01 needs to say anything about it. draft-ietf-dime-diameter-qos-01.txt and draft-ietf-dime-qos-attributes-02.txt provide some minimum semantic. For example, when someone wants to use the IntServ Controlled-Load Service QoSM http://tools.ietf.org/wg/nsis/draft-kappler-nsis-qosmodel-controlledload-05.txt and if an interaction with the Diameter backend infrastructure is desired then they would take the respective parameters from the received NSIS message and copy them into a Diameter message. The QoS profile would be set to a value as defined in the IntServ Controlled-Load Service QoSM (note that it has not been done yet). If there are specific issues that need to be said about the backend infrastructure interaction then they may be discussed in the respective QoSM but so far I have not heard about anything. For some other QoSMs, such as RMD, I have never heard that a AAA interaction would be desired. There, the usage model is different. Does this make sense to you? Ciao Hannes > Regards, > Roland > > > > _______________________________________________ > 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 Oct 16 07:10:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhkJQ-0006cF-UY; Tue, 16 Oct 2007 07:10:12 -0400 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1IhkJN-0006bH-Hs for nsis-confirm+ok@megatron.ietf.org; Tue, 16 Oct 2007 07:10:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhkJM-0006ad-K8; Tue, 16 Oct 2007 07:10:08 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IhkJL-0006lY-H8; Tue, 16 Oct 2007 07:10:08 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 560CA26E63; Tue, 16 Oct 2007 11:10:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IhkJG-00047a-7f; Tue, 16 Oct 2007 07:10:02 -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, 16 Oct 2007 07:10:02 -0400 X-Spam-Score: -1.2 (-) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: nsis@ietf.org Subject: [NSIS] I-D Action:draft-ietf-nsis-qspec-18.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 : QoS NSLP QSPEC Template Author(s) : G. Ash, et al. Filename : draft-ietf-nsis-qspec-18.txt Pages : 48 Date : 2007-10-16 The QoS NSLP protocol is used to signal QoS reservations and is independent of a specific QoS model (QOSM) such as IntServ or DiffServ. Rather, all information specific to a QOSM is encapsulated in a separate object, the QSPEC. This document defines a template for the QSPEC including a number of QSPEC parameters. The QSPEC parameters provide a common language to be re-used in several QOSMs and thereby aim to ensure the extensibility and interoperability of QoS NSLP. The node initiating the NSIS signaling adds an initiator QSPEC, which indicates the QSPEC parameters that must be interpreted by the downstream nodes less the reservation fails, thereby ensuring the intention of the NSIS initiator is preserved along the signaling path. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nsis-qspec-18.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-qspec-18.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-qspec-18.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: <2007-10-16070415.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nsis-qspec-18.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nsis-qspec-18.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-10-16070415.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 Tue Oct 16 07:17:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhkPB-0006eS-Nu; Tue, 16 Oct 2007 07:16:09 -0400 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1IhkP9-0006bx-QE for nsis-confirm+ok@megatron.ietf.org; Tue, 16 Oct 2007 07:16:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhkP9-0006bC-38 for nsis@ietf.org; Tue, 16 Oct 2007 07:16:07 -0400 Received: from demumfd001.nsn-inter.net ([217.115.75.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IhkP3-0006xC-JW for nsis@ietf.org; Tue, 16 Oct 2007 07:16:07 -0400 Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id l9GBFmYP028434 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 16 Oct 2007 13:15:48 +0200 Received: from demuexc023.nsn-intra.net (webmail.nsn-intra.net [10.150.128.36]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id l9GBFlMn016119 for ; Tue, 16 Oct 2007 13:15:48 +0200 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 Oct 2007 13:15:48 +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 Date: Tue, 16 Oct 2007 13:14:50 +0200 Message-ID: <0A24C3E434FAE8478BA72FEE30ACD274211E2A@DEMUEXC005.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New Version Notification for draft-ietf-nsis-qspec-18 - and Good Bye Thread-Index: AcgP5GfgJ7kkhCGgQ/irXiq/5zDiwwAAJRdg From: "Kappler, Cornelia (NSN - DE/Berlin)" To: X-OriginalArrivalTime: 16 Oct 2007 11:15:48.0417 (UTC) FILETIME=[E7656B10:01C80FE5] X-Spam-Score: 0.2 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Subject: [NSIS] WG: New Version Notification for draft-ietf-nsis-qspec-18 - and Good Bye 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 =20 Dear all,=20 this last update of the QSPEC just contains minor fixes that have come = up since June (thanks to Hannes and Bernd!), particularly: - clarified handling of Traffic Handling Directives in QoS Available = in Sec. 4.3.3 - classified Priority Parameters as Traffic Handling Directives = (Previously and erroneously were classified as Constraint Parameters) = (i.e. moved from 4.3.2 to 4.3.3) - added units to TMOD parameter in 6.2.1 - fixed error in possible object combination for Resource Queries in = Sec 6.1 - streamlined usage of QSPEC Type and added QSPEC Type to terminology Since is probably the last email you'll receive from me - I am changing = jobs. I very much enjoyed working with you all, it was a good time with = nsis.=20 So good bye - Cornelia -----Urspr=FCngliche Nachricht----- Von: ext IETF I-D Submission Tool [mailto:idsubmission@ietf.org]=20 Gesendet: Dienstag, 16. Oktober 2007 13:04 An: cornelia.kappler@googlemail.com Cc: nsis@ietf.org; gash5107@yahoo.com; Attila.Bader@ericsson.com; = oran@cisco.com Betreff: New Version Notification for draft-ietf-nsis-qspec-18=20 A new version of I-D, draft-ietf-nsis-qspec-18.txt has been successfuly = submitted by Cornelia Kappler and posted to the IETF repository. Filename: draft-ietf-nsis-qspec Revision: 18 Title: QoS NSLP QSPEC Template Creation_date: 2007-10-16 WG ID: nsis Number_of_pages: 48 Abstract: The QoS NSLP protocol is used to signal QoS reservations and is independent of a specific QoS model (QOSM) such as IntServ or DiffServ. Rather, all information specific to a QOSM is encapsulated in a separate object, the QSPEC. This document defines a template for the QSPEC including a number of QSPEC parameters. The QSPEC parameters provide a common language to be re-used in several QOSMs and thereby aim to ensure the extensibility and interoperability of QoS NSLP. The node initiating the NSIS signaling adds an initiator QSPEC, which indicates the QSPEC parameters that must be interpreted by the downstream nodes less the reservation fails, thereby ensuring the intention of the NSIS initiator is preserved along the signaling path. = =20 The IETF Secretariat. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Oct 16 08:34:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ihlbl-0004Nw-Nu; Tue, 16 Oct 2007 08:33:13 -0400 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1IhkDu-0001ZS-GT for nsis-confirm+ok@megatron.ietf.org; Tue, 16 Oct 2007 07:04:30 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhkDt-0001Z5-Ke for nsis@ietf.org; Tue, 16 Oct 2007 07:04:29 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IhkDt-0006PG-Ce for nsis@ietf.org; Tue, 16 Oct 2007 07:04:29 -0400 Received: from ietf.org (stiedprweb1.va.neustar.com [10.91.34.42]) by ns3.neustar.com (Postfix) with ESMTP id E6D0B175AB; Tue, 16 Oct 2007 11:04:18 +0000 (GMT) Received: from mirror by ietf.org with local (Exim 4.43) id 1IhkDh-0002Ge-Us; Tue, 16 Oct 2007 07:04:17 -0400 Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 To: cornelia.kappler@googlemail.com From: IETF I-D Submission Tool Message-Id: Date: Tue, 16 Oct 2007 07:04:17 -0400 X-Spam-Score: 0.2 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d X-Mailman-Approved-At: Tue, 16 Oct 2007 08:33:12 -0400 Cc: gash5107@yahoo.com, oran@cisco.com, nsis@ietf.org, Attila.Bader@ericsson.com Subject: [NSIS] New Version Notification for draft-ietf-nsis-qspec-18 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 A new version of I-D, draft-ietf-nsis-qspec-18.txt has been successfuly submitted by Cornelia Kappler and posted to the IETF repository. Filename: draft-ietf-nsis-qspec Revision: 18 Title: QoS NSLP QSPEC Template Creation_date: 2007-10-16 WG ID: nsis Number_of_pages: 48 Abstract: The QoS NSLP protocol is used to signal QoS reservations and is independent of a specific QoS model (QOSM) such as IntServ or DiffServ. Rather, all information specific to a QOSM is encapsulated in a separate object, the QSPEC. This document defines a template for the QSPEC including a number of QSPEC parameters. The QSPEC parameters provide a common language to be re-used in several QOSMs and thereby aim to ensure the extensibility and interoperability of QoS NSLP. The node initiating the NSIS signaling adds an initiator QSPEC, which indicates the QSPEC parameters that must be interpreted by the downstream nodes less the reservation fails, thereby ensuring the intention of the NSIS initiator is preserved along the signaling path. The IETF Secretariat. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Oct 16 09:22:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhmM0-0006Gq-0T; Tue, 16 Oct 2007 09:21:00 -0400 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1IhmLy-0006FV-LU for nsis-confirm+ok@megatron.ietf.org; Tue, 16 Oct 2007 09:20:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhmLw-0006Cl-1K; Tue, 16 Oct 2007 09:20:56 -0400 Received: from mta2.dhs.gov ([152.121.181.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IhmLl-0003Fl-9R; Tue, 16 Oct 2007 09:20:53 -0400 Received: from dhsmail3.dhs.gov (dhsmail3.dhs.gov [161.214.63.41]) by mta2.dhs.gov with ESMTP; Tue, 16 Oct 2007 09:20:24 -0400 Received: from dhsmail3.dhs.gov (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 3619722F7; Tue, 16 Oct 2007 09:20:23 -0400 (EDT) Received: from ZAU1UG-0351.DHSNET.DS1.DHS (mx7.hq.dhs.gov [161.214.98.195]) by dhsmail3.dhs.gov (Postfix) with ESMTP id 2B6FC2145; Tue, 16 Oct 2007 09:20:23 -0400 (EDT) Received: from ZAU1UG-0308.DHSNET.DS1.DHS ([10.15.18.80]) by ZAU1UG-0351.DHSNET.DS1.DHS with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 Oct 2007 09:20:35 -0400 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 Date: Tue, 16 Oct 2007 09:20:35 -0400 Message-Id: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Tsvwg] WGLC for draft-ietf-dime-qos-parameters-01 Thread-Index: AcgEz4SaZT+XWIPvRx6Rtb+XW3YE5gLJjEI8 References: <470202BF.4000701@gmx.net> From: "Nguyen, An P" To: "Hannes Tschofenig" , , "radext mailing list" , , "tsvwg IETF list" X-OriginalArrivalTime: 16 Oct 2007 13:20:35.0762 (UTC) FILETIME=[56339920:01C80FF7] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: Subject: [NSIS] RE: [Tsvwg] WGLC for draft-ietf-dime-qos-parameters-01 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, Just a comment on a reference in Sect 4.10 - Admission Priority = Parameter: Change the Y.1571 to Y.2171. The ITU SG-13 changed Y.1571 to Y.2171 ( = Admission Control Priority Levels in Next Generation Networks, Sept = 2006) to reflect the NGN work. I think you should add Y.2171 to Sect 9.2 - Informative References as = well. Regards, An =20 -----Original Message----- From: tsvwg-bounces@ietf.org on behalf of Hannes Tschofenig Sent: Tue 10/2/2007 4:35 AM To: dime@ietf.org; 'radext mailing list'; nsis@ietf.org; tsvwg IETF list Subject: [Tsvwg] WGLC for draft-ietf-dime-qos-parameters-01 =20 Hi all, this message marks the issuance of a working group last call (WGLC) on=20 DIME's Internet Draft entitled "Quality of Service Parameters for Usage=20 with the AAA Framework " (draft-ietf-dime-qos-parameters-01). You may=20 view this document at http://tools.ietf.org/html/draft-ietf-dime-qos-parameters-01 Please post comments and questions to the DIME mailing list (or to the=20 authors) no later than 16 October 2007. Ciao Hannes & Dave _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Oct 16 09:46:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhmkK-0000ws-Nu; Tue, 16 Oct 2007 09:46:08 -0400 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1IhmkI-0000vI-VZ for nsis-confirm+ok@megatron.ietf.org; Tue, 16 Oct 2007 09:46:06 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhmkH-0000uR-TH for nsis@ietf.org; Tue, 16 Oct 2007 09:46:05 -0400 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IhmkH-0003mY-BD for nsis@ietf.org; Tue, 16 Oct 2007 09:46:05 -0400 Received: (qmail invoked by alias); 16 Oct 2007 13:46:02 -0000 Received: from socks-ic-ext.mch.sbs.de (EHLO [194.138.17.187]) [194.138.17.187] by mail.gmx.net (mp053) with SMTP; 16 Oct 2007 15:46:02 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19TvRJ6wWxTMeD5NL9omqHgEw9NhPo/8yaC98hRgL HI/vGD2RBrVB68 Message-ID: <4714C099.1050808@gmx.net> Date: Tue, 16 Oct 2007 16:46:01 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: nsis@ietf.org References: <470202BF.4000701@gmx.net> 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: cab78e1e39c4b328567edb48482b6a69 Cc: "Nguyen, An P" Subject: [NSIS] Re: [Tsvwg] WGLC for draft-ietf-dime-qos-parameters-01 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 Thanks for pointing this out. To the QSPEC authors: I believe that's a fix that might also affect the QSPEC document. Ciao Hannes Nguyen, An P wrote: > Hannes, > > Just a comment on a reference in Sect 4.10 - Admission Priority Parameter: > > Change the Y.1571 to Y.2171. The ITU SG-13 changed Y.1571 to Y.2171 ( Admission Control Priority Levels in Next Generation Networks, Sept 2006) to reflect the NGN work. > > I think you should add Y.2171 to Sect 9.2 - Informative References as well. > > Regards, > > An > > > -----Original Message----- > From: tsvwg-bounces@ietf.org on behalf of Hannes Tschofenig > Sent: Tue 10/2/2007 4:35 AM > To: dime@ietf.org; 'radext mailing list'; nsis@ietf.org; tsvwg IETF list > Subject: [Tsvwg] WGLC for draft-ietf-dime-qos-parameters-01 > > Hi all, > > this message marks the issuance of a working group last call (WGLC) on > DIME's Internet Draft entitled "Quality of Service Parameters for Usage > with the AAA Framework " (draft-ietf-dime-qos-parameters-01). You may > view this document at > http://tools.ietf.org/html/draft-ietf-dime-qos-parameters-01 > > Please post comments and questions to the DIME mailing list (or to the > authors) no later than 16 October 2007. > > Ciao > Hannes & Dave > > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Oct 24 10:32:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkhHP-00066T-OV; Wed, 24 Oct 2007 10:32:19 -0400 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1IkhHO-00066D-Qa for nsis-confirm+ok@megatron.ietf.org; Wed, 24 Oct 2007 10:32:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkhHO-000665-0q for nsis@ietf.org; Wed, 24 Oct 2007 10:32:18 -0400 Received: from e6.ny.us.ibm.com ([32.97.182.146]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IkhHH-0008Q2-Sq for nsis@ietf.org; Wed, 24 Oct 2007 10:32:18 -0400 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e6.ny.us.ibm.com (8.13.8/8.13.8) with ESMTP id l9OEXSR8016908 for ; Wed, 24 Oct 2007 10:33:28 -0400 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v8.5) with ESMTP id l9OEVtSc126448 for ; Wed, 24 Oct 2007 10:31:55 -0400 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l9OEVs7Q005413 for ; Wed, 24 Oct 2007 10:31:55 -0400 Received: from cichlid.raleigh.ibm.com (wecm-9-67-176-89.wecm.ibm.com [9.67.176.89]) by d01av02.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l9OEVrFi005258 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 24 Oct 2007 10:31:54 -0400 Received: from cichlid.raleigh.ibm.com (localhost.localdomain [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.1/8.12.5) with ESMTP id l9OEVqIO030663; Wed, 24 Oct 2007 10:31:52 -0400 Message-Id: <200710241431.l9OEVqIO030663@cichlid.raleigh.ibm.com> To: Jukka MJ Manner , int-area@lists.ietf.org, NSIS Working Group , Bob Hinden In-reply-to: <200710111233.l9BCXhrU011347@localhost.localdomain> References: <200710111233.l9BCXhrU011347@localhost.localdomain> Comments: In-reply-to Thomas Narten message dated "Thu, 11 Oct 2007 08:33:43 -0400." Date: Wed, 24 Oct 2007 10:31:52 -0400 From: Thomas Narten X-Spam-Score: -4.0 (----) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: Subject: [NSIS] Re: [Int-area] RAO for IPv4 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 Bob Hinden and I had some further offlist discussion about this. My understanding is that the IPv4 RA option is very basic. It says "look at this packet". The option itself doesn't contain any additional information or "hint" as to what to look for or what the packet contains. The semantics of the IPv6 router alert option are different. The value itself is used to convey additional "hints" about processing. My sense is that the semantics of the IPv4 and IPv6 Router Alert option are sufficiently different that sharing the name space just doesn't make any sense. That is, the ID says: This document proposes the creation of a new IANA registry for managing IPv4 Router Alert Option Values. In conjunction with this, it also proposes an update to the way in which IPv6 Router Alert Option Values are assigned in the existing IANA registry. But there are no defined IPv4 Router Alert Option values (other than zero), and it would be inappropriate to change the semantics of any existing usages (too late for that) and it would also be inappropriate to consider doing this in the absense of a specific new application that would make use of a new value. This document does not propose such a new usage. Hence, at this point, I'm opposed to the actions called for in the document. Thomas _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Oct 24 12:57:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkjWu-0000yo-Ad; Wed, 24 Oct 2007 12:56:28 -0400 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1IkjWs-0000x2-Lh for nsis-confirm+ok@megatron.ietf.org; Wed, 24 Oct 2007 12:56:26 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkjWs-0000wu-Ap for nsis@ietf.org; Wed, 24 Oct 2007 12:56:26 -0400 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IkjWr-0002VU-P9 for nsis@ietf.org; Wed, 24 Oct 2007 12:56:26 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l9OGuJhE011234; Wed, 24 Oct 2007 19:56:22 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 24 Oct 2007 19:56:19 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 24 Oct 2007 19:56:19 +0300 Received: from mgw-int01.ntc.nokia.com ([172.21.143.96]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Wed, 24 Oct 2007 19:56:18 +0300 Received: from [10.186.158.57] (essapo-nirac253229.europe.nokia.com [10.162.253.229]) by mgw-int01.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l9OGuFhn017986; Wed, 24 Oct 2007 19:56:16 +0300 In-Reply-To: <200710241431.l9OEVqIO030663@cichlid.raleigh.ibm.com> References: <200710111233.l9BCXhrU011347@localhost.localdomain> <200710241431.l9OEVqIO030663@cichlid.raleigh.ibm.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <2C14B2ED-0996-4401-BAA7-430D96958073@nokia.com> Content-Transfer-Encoding: 7bit From: Bob Hinden Date: Wed, 24 Oct 2007 09:56:24 -0700 To: Jukka MJ Manner , int-area@lists.ietf.org, NSIS Working Group X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 24 Oct 2007 16:56:18.0574 (UTC) FILETIME=[CC05FAE0:01C8165E] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: Thomas Narten Subject: [NSIS] Re: [Int-area] RAO for IPv4 X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bob.hinden@nokia.com List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org I agree with Thomas on this document. Bob On Oct 24, 2007, at 7:31 AM, ext Thomas Narten wrote: > Bob Hinden and I had some further offlist discussion about this. > > My understanding is that the IPv4 RA option is very basic. It says > "look at this packet". The option itself doesn't contain any > additional information or "hint" as to what to look for or what the > packet contains. > > The semantics of the IPv6 router alert option are different. The value > itself is used to convey additional "hints" about processing. > > My sense is that the semantics of the IPv4 and IPv6 Router Alert > option are sufficiently different that sharing the name space just > doesn't make any sense. > > That is, the ID says: > > This document proposes the creation of a new IANA registry for > managing IPv4 Router Alert Option Values. In conjunction with > this, it also proposes an update to the way in which IPv6 Router > Alert Option Values are assigned in the existing IANA registry. > > But there are no defined IPv4 Router Alert Option values (other than > zero), and it would be inappropriate to change the semantics of any > existing usages (too late for that) and it would also be inappropriate > to consider doing this in the absense of a specific new application > that would make use of a new value. This document does not propose > such a new usage. > > Hence, at this point, I'm opposed to the actions called for in the > document. > > Thomas _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Oct 24 15:57:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkmLb-0005Fh-3x; Wed, 24 Oct 2007 15:56:59 -0400 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1IkmLZ-0005Eo-FK for nsis-confirm+ok@megatron.ietf.org; Wed, 24 Oct 2007 15:56:57 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkmLY-0005Eg-Uo for nsis@ietf.org; Wed, 24 Oct 2007 15:56:56 -0400 Received: from courier.cs.helsinki.fi ([128.214.9.1] helo=mail.cs.helsinki.fi) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IkmLY-0008Nl-BV for nsis@ietf.org; Wed, 24 Oct 2007 15:56:56 -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; Wed, 24 Oct 2007 22:56:55 +0300 id 0007042C.471FA387.000006D0 Date: Wed, 24 Oct 2007 22:56:54 +0300 (EEST) From: Jukka MJ Manner To: Thomas Narten In-Reply-To: <200710241431.l9OEVqIO030663@cichlid.raleigh.ibm.com> Message-ID: References: <200710111233.l9BCXhrU011347@localhost.localdomain> <200710241431.l9OEVqIO030663@cichlid.raleigh.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: Bob Hinden , int-area@lists.ietf.org, NSIS Working Group Subject: [NSIS] Re: [Int-area] RAO for IPv4 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 Thomas, Bob, Thanks for the discussion. The specific application that needs (well, to be precise, would greatly benefit) RAO is NSIS. That is why NSIS ML is CC:d. Moreover, the RSVP spec talks about multiple RAO values, but lets it open as to whether IPv4 should also have those, not just IPv6. RFC2113 also says that "The semantics of other values in the Value field are for further study." The point is, is it time to study those "other values" further? At least GIST and the whole NSIS framework would greatly benefit from more values than just "0" for IPv4, and these values should be the same for IPv6 also, for simplified implementations. There is a lot of discussions about RAO in the GIST spec, e.g., Sections 4.3.1., 4.3.4., 5.3.2.1., 5.3.2.2., 6. IANA Considerations and Appendix C: http://tools.ietf.org/wg/nsis/draft-ietf-nsis-ntlp/ Regards, Jukka On Wed, 24 Oct 2007, Thomas Narten wrote: > Bob Hinden and I had some further offlist discussion about this. > > My understanding is that the IPv4 RA option is very basic. It says > "look at this packet". The option itself doesn't contain any > additional information or "hint" as to what to look for or what the > packet contains. > > The semantics of the IPv6 router alert option are different. The value > itself is used to convey additional "hints" about processing. > > My sense is that the semantics of the IPv4 and IPv6 Router Alert > option are sufficiently different that sharing the name space just > doesn't make any sense. > > That is, the ID says: > > This document proposes the creation of a new IANA registry for > managing IPv4 Router Alert Option Values. In conjunction with > this, it also proposes an update to the way in which IPv6 Router > Alert Option Values are assigned in the existing IANA registry. > > But there are no defined IPv4 Router Alert Option values (other than > zero), and it would be inappropriate to change the semantics of any > existing usages (too late for that) and it would also be inappropriate > to consider doing this in the absense of a specific new application > that would make use of a new value. This document does not propose > such a new usage. > > Hence, at this point, I'm opposed to the actions called for in the > document. > > Thomas > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Oct 24 18:30:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ikoia-0003gT-9s; Wed, 24 Oct 2007 18:28:52 -0400 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1IkoiY-0003cw-Ne for nsis-confirm+ok@megatron.ietf.org; Wed, 24 Oct 2007 18:28:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkoiY-0003c8-32; Wed, 24 Oct 2007 18:28:50 -0400 Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IkoiR-00089v-O9; Wed, 24 Oct 2007 18:28:50 -0400 Received: from irams2.ira.uni-karlsruhe.de ([141.3.10.82]) by iramx2.ira.uni-karlsruhe.de with esmtps id 1IkoiJ-0005kf-42; Thu, 25 Oct 2007 00:28:36 +0200 Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5]) by irams2.ira.uni-karlsruhe.de with esmtps id 1IkoiH-0000qC-Sz; Thu, 25 Oct 2007 00:28:34 +0200 Received: from i72ms.tm.uni-karlsruhe.de ([141.3.70.5] helo=smtp.ipv6.tm.uni-karlsruhe.de) by irams1.ira.uni-karlsruhe.de with esmtps id 1IkoiH-0000lE-Ly; Thu, 25 Oct 2007 00:28:33 +0200 Received: from vorta.ipv6.tm.uni-karlsruhe.de (vorta.ipv6.tm.uni-karlsruhe.de [IPv6:2001:638:204:6:207:e9ff:fe0c:5e44]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id 47C612FC00C; Thu, 25 Oct 2007 00:28:32 +0200 (CEST) Received: from localhost ([127.0.0.1]) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.44) id 1IkoiH-000670-G0; Thu, 25 Oct 2007 00:28:33 +0200 Message-ID: <471FC70E.4010405@tm.uka.de> Date: Thu, 25 Oct 2007 00:28:30 +0200 From: Roland Bless Organization: Institute of Telematics, University of Karlsruhe User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060111 Thunderbird/1.5 Mnenhy/0.7.3.0 MIME-Version: 1.0 To: Tony Li References: <200710111233.l9BCXhrU011347@localhost.localdomain> <200710241431.l9OEVqIO030663@cichlid.raleigh.ibm.com> <67DBA10E-1363-4C73-ABB8-0CF3BF739C1E@cisco.com> In-Reply-To: <67DBA10E-1363-4C73-ABB8-0CF3BF739C1E@cisco.com> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Status: No X-Spam-Score: -1.3 (-) X-Spam-Report: -1.4 ALL_TRUSTED Passed through trusted hosts only via SMTP 0.1 AWL AWL: From: address is in the auto white-list X-Spam-Host: irams2.ira.uni-karlsruhe.de X-ATIS-Checksum: v3zoCAcc32ckk X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: Jukka MJ Manner , NSIS Working Group , int-area@lists.ietf.org Subject: [NSIS] Re: [Int-area] RAO for IPv4 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 Tony, Tony Li wrote: > I've got an architectural issue with any protocol having specific values > in the RAO. In general, that's > a poor approach, as it will (in the long term) lead to multiple > protocols piggybacking on RAO. Why not simply allocate another option > on a per-protocol basis? > > This also has the nice side effect that it ensures that things are > backward compatible. Thanks for your comments. If you're interested in this topic I'd like to point at Appendix C of the GIST draft that provides more background information: http://tools.ietf.org/html/draft-ietf-nsis-ntlp-14#appendix-C We had already some discussions about this and I'll try to summarize why we choose to use the RAO (maybe other NSIS WG members or Robert can jump in here) approach. It was mainly driven by RSVP experience: 1) better chances of NAT and Firewall traversal, an own protocol number didn't work too well for RSVP (raw IP with protocol #46) 2) RSVP already used the RAO mechanism, thus lets re-use it. The basic concept is: due to path-coupled signaling we want to intercept signaling packets that are sent to the data flow's destination. Each NSIS signaling protocol (e.g, QoS NSLP or NAT/FW NSLP) uses a specific RAO value, so a packet can bypass easily if it carries the "wrong" RAO value. This assumes that an implementation can specifically intercept packets depending on the RAO value and let non-matching packets bypass in the fast path. I don't see the danger that "multiple protocols are piggybacking on RAO", because only protocols will use this mechanism if they need to _intercept_ packets, like GIST does for discovering signaling nodes along a flow's path. I don't understand what you mean by "allocate another option on a per-protocol basis". Do you mean an own protocol number or a new IP option or demultiplexing within the protocol itself (which we also do). Could you explain this a little bit more? Regards, Roland _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Oct 24 19:09:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkpJP-0006MO-ER; Wed, 24 Oct 2007 19:06:55 -0400 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1IkpJO-0006MJ-5e for nsis-confirm+ok@megatron.ietf.org; Wed, 24 Oct 2007 19:06:54 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkpJN-0006LS-R6 for nsis@ietf.org; Wed, 24 Oct 2007 19:06:53 -0400 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IkpJN-0004XI-9d for nsis@ietf.org; Wed, 24 Oct 2007 19:06:53 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l9ON6nLP013389 for ; Thu, 25 Oct 2007 02:06:51 +0300 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 25 Oct 2007 02:06:50 +0300 Received: from daebe104.NOE.Nokia.com ([10.241.36.13]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 24 Oct 2007 18:06:48 -0500 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: Wed, 24 Oct 2007 18:06:45 -0500 Message-ID: <19EBBEC503C3B5469070E0A6674A533AABEFC9@daebe104.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ID Tracker State Update Notice: draft-ietf-nsis-ntlp Thread-Index: AcgWT5M0HIEWz0moStGFWaVuQW+sdgAQvQkg From: To: X-OriginalArrivalTime: 24 Oct 2007 23:06:48.0322 (UTC) FILETIME=[8DFC5620:01C81692] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Subject: [NSIS] FW: ID Tracker State Update Notice: draft-ietf-nsis-ntlp 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 FYI >-----Original Message----- >From: ext The IESG [mailto:iesg-secretary@ietf.org]=20 >Sent: 24 October, 2007 08:07 >To: nsis-chairs@tools.ietf.org; robert.hancock@roke.co.uk;=20 >hgs+nsis@cs.columbia.edu >Subject: ID Tracker State Update Notice: draft-ietf-nsis-ntlp > >'State Changes to AD Evaluation from Publication Requested by=20 >Magnus Westerlund' >ID Tracker URL:=20 >https://datatracker.ietf.org/public/pidtracker.cgi?command=3Dview >_id&dTag=3D11113&rfc_flag=3D0 > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Oct 24 20:08:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkqFp-0001PH-K0; Wed, 24 Oct 2007 20:07:17 -0400 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1IknWD-0001qc-B9 for nsis-confirm+ok@megatron.ietf.org; Wed, 24 Oct 2007 17:12:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IknWC-0001qC-Ue for nsis@ietf.org; Wed, 24 Oct 2007 17:12:00 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IknWA-0006Iy-Jo for nsis@ietf.org; Wed, 24 Oct 2007 17:12:00 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-5.cisco.com with ESMTP; 24 Oct 2007 14:11:57 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l9OLBvjD010918; Wed, 24 Oct 2007 14:11:57 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l9OLBqFp000465; Wed, 24 Oct 2007 21:11:57 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 24 Oct 2007 14:11:55 -0700 Received: from [171.70.245.121] ([171.70.245.121]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 24 Oct 2007 14:11:55 -0700 In-Reply-To: References: <200710111233.l9BCXhrU011347@localhost.localdomain> <200710241431.l9OEVqIO030663@cichlid.raleigh.ibm.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <67DBA10E-1363-4C73-ABB8-0CF3BF739C1E@cisco.com> Content-Transfer-Encoding: 7bit From: Tony Li Date: Wed, 24 Oct 2007 14:11:44 -0700 To: Jukka MJ Manner X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 24 Oct 2007 21:11:55.0563 (UTC) FILETIME=[8194C7B0:01C81682] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3090; t=1193260317; x=1194124317; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=tli@cisco.com; z=From:=20Tony=20Li=20 |Subject:=20Re=3A=20[Int-area]=20RAO=20for=20IPv4 |Sender:=20; bh=vkthdi+u2wwYAcV1K+1pMK9RTw8RVK28glMFkvtD9Uw=; b=B6HHfVQRXysTSOQldCHVKOMdrspiHJlBezQtR+q2iOUdGAfrkCw217JltHn+gcqFNBr1Ssh2 U3Y7yhL6ipYTFEo4ECz1AM2/e2bVtEEXytl/1q1G9V2VuDtq0uEY07Qh; Authentication-Results: sj-dkim-3; header.From=tli@cisco.com; dkim=pass (sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 X-Mailman-Approved-At: Wed, 24 Oct 2007 20:07:17 -0400 Cc: Thomas Narten , int-area@lists.ietf.org, NSIS Working Group Subject: [NSIS] Re: [Int-area] RAO for IPv4 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've got an architectural issue with any protocol having specific values in the RAO. In general, that's a poor approach, as it will (in the long term) lead to multiple protocols piggybacking on RAO. Why not simply allocate another option on a per-protocol basis? This also has the nice side effect that it ensures that things are backward compatible. Tony On Oct 24, 2007, at 12:56 PM, Jukka MJ Manner wrote: > > Hi Thomas, Bob, > > Thanks for the discussion. > > The specific application that needs (well, to be precise, would > greatly > benefit) RAO is NSIS. That is why NSIS ML is CC:d. > > Moreover, the RSVP spec talks about multiple RAO values, but lets > it open > as to whether IPv4 should also have those, not just IPv6. > > RFC2113 also says that "The semantics of other values in the Value > field > are for further study." > > The point is, is it time to study those "other values" further? At > least > GIST and the whole NSIS framework would greatly benefit from more > values > than just "0" for IPv4, and these values should be the same for > IPv6 also, > for simplified implementations. > > There is a lot of discussions about RAO in the GIST spec, e.g., > Sections > 4.3.1., 4.3.4., 5.3.2.1., 5.3.2.2., 6. IANA Considerations and > Appendix C: > > http://tools.ietf.org/wg/nsis/draft-ietf-nsis-ntlp/ > > > Regards, > Jukka > > > On Wed, 24 Oct 2007, Thomas Narten wrote: > >> Bob Hinden and I had some further offlist discussion about this. >> >> My understanding is that the IPv4 RA option is very basic. It says >> "look at this packet". The option itself doesn't contain any >> additional information or "hint" as to what to look for or what the >> packet contains. >> >> The semantics of the IPv6 router alert option are different. The >> value >> itself is used to convey additional "hints" about processing. >> >> My sense is that the semantics of the IPv4 and IPv6 Router Alert >> option are sufficiently different that sharing the name space just >> doesn't make any sense. >> >> That is, the ID says: >> >> This document proposes the creation of a new IANA registry for >> managing IPv4 Router Alert Option Values. In conjunction with >> this, it also proposes an update to the way in which IPv6 Router >> Alert Option Values are assigned in the existing IANA registry. >> >> But there are no defined IPv4 Router Alert Option values (other than >> zero), and it would be inappropriate to change the semantics of any >> existing usages (too late for that) and it would also be >> inappropriate >> to consider doing this in the absense of a specific new application >> that would make use of a new value. This document does not propose >> such a new usage. >> >> Hence, at this point, I'm opposed to the actions called for in the >> document. >> >> Thomas >> > > > _______________________________________________ > Int-area mailing list > Int-area@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/int-area _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Oct 24 20:08:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkqFp-0001PM-Q7; Wed, 24 Oct 2007 20:07:17 -0400 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1Ikpp9-00067P-CI for nsis-confirm+ok@megatron.ietf.org; Wed, 24 Oct 2007 19:39:43 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ikpp9-000673-1E for nsis@ietf.org; Wed, 24 Oct 2007 19:39:43 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ikpp8-00055b-Ga for nsis@ietf.org; Wed, 24 Oct 2007 19:39:42 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 24 Oct 2007 16:39:42 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l9ONdf3L031721; Wed, 24 Oct 2007 16:39:41 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l9ONddj1005262; Wed, 24 Oct 2007 23:39:41 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); From nsis-bounces@ietf.org Wed Oct 24 20:08:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkqFp-0001PH-K0; Wed, 24 Oct 2007 20:07:17 -0400 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1IknWD-0001qc-B9 for nsis-confirm+ok@megatron.ietf.org; Wed, 24 Oct 2007 17:12:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IknWC-0001qC-Ue for nsis@ietf.org; Wed, 24 Oct 2007 17:12:00 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IknWA-0006Iy-Jo for nsis@ietf.org; Wed, 24 Oct 2007 17:12:00 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-5.cisco.com with ESMTP; 24 Oct 2007 14:11:57 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l9OLBvjD010918; Wed, 24 Oct 2007 14:11:57 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l9OLBqFp000465; Wed, 24 Oct 2007 21:11:57 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 24 Oct 2007 14:11:55 -0700 Received: from [171.70.245.121] ([171.70.245.121]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 24 Oct 2007 14:11:55 -0700 In-Reply-To: References: <200710111233.l9BCXhrU011347@localhost.localdomain> <200710241431.l9OEVqIO030663@cichlid.raleigh.ibm.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <67DBA10E-1363-4C73-ABB8-0CF3BF739C1E@cisco.com> Content-Transfer-Encoding: 7bit From: Tony Li Date: Wed, 24 Oct 2007 14:11:44 -0700 To: Jukka MJ Manner X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 24 Oct 2007 21:11:55.0563 (UTC) FILETIME=[8194C7B0:01C81682] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3090; t=1193260317; x=1194124317; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=tli@cisco.com; z=From:=20Tony=20Li=20 |Subject:=20Re=3A=20[Int-area]=20RAO=20for=20IPv4 |Sender:=20; bh=vkthdi+u2wwYAcV1K+1pMK9RTw8RVK28glMFkvtD9Uw=; b=B6HHfVQRXysTSOQldCHVKOMdrspiHJlBezQtR+q2iOUdGAfrkCw217JltHn+gcqFNBr1Ssh2 U3Y7yhL6ipYTFEo4ECz1AM2/e2bVtEEXytl/1q1G9V2VuDtq0uEY07Qh; Authentication-Results: sj-dkim-3; header.From=tli@cisco.com; dkim=pass (sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 X-Mailman-Approved-At: Wed, 24 Oct 2007 20:07:17 -0400 Cc: Thomas Narten , int-area@lists.ietf.org, NSIS Working Group Subject: [NSIS] Re: [Int-area] RAO for IPv4 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've got an architectural issue with any protocol having specific values in the RAO. In general, that's a poor approach, as it will (in the long term) lead to multiple protocols piggybacking on RAO. Why not simply allocate another option on a per-protocol basis? This also has the nice side effect that it ensures that things are backward compatible. Tony On Oct 24, 2007, at 12:56 PM, Jukka MJ Manner wrote: Wed, 24 Oct 2007 16:39:39 -0700 Received: from [171.70.246.92] ([171.70.246.92]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 24 Oct 2007 16:39:39 -0700 In-Reply-To: <471FC70E.4010405@tm.uka.de> References: <200710111233.l9BCXhrU011347@localhost.localdomain> <200710241431.l9OEVqIO030663@cichlid.raleigh.ibm.com> <67DBA10E-1363-4C73-ABB8-0CF3BF739C1E@cisco.com> <471FC70E.4010405@tm.uka.de> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0C9555DB-F6F9-4A3F-A379-31E68F5B585F@cisco.com> Content-Transfer-Encoding: 7bit From: Tony Li Date: Wed, 24 Oct 2007 16:39:28 -0700 To: Roland Bless X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 24 Oct 2007 23:39:39.0016 (UTC) FILETIME=[249C6080:01C81697] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2944; t=1193269181; x=1194133181; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=tli@cisco.com; z=From:=20Tony=20Li=20 |Subject:=20Re=3A=20[Int-area]=20RAO=20for=20IPv4 |Sender:=20; bh=/bt2iEbFlWJvnY0ZBbQJmU4eWIwQVrgqwwvYptSJeSw=; b=SSQwifu0HVzLSm+h9QvQlgr9DVklNH+HgPqYfIcsj0o+MLgXwS3p3aneF+clLzH+6eRsj8bl OC4CdgaENimyXFq9qUiVBfkZF65N39V0tQNZ6WuK2x0SqTgoyv+0mDzE0Wsxwb5QoySTenaPZS IDWKaseW6DV2K9hcNZujfY1Sk=; Authentication-Results: sj-dkim-1; header.From=tli@cisco.com; dkim=pass (sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a X-Mailman-Approved-At: Wed, 24 Oct 2007 20:07:17 -0400 Cc: Jukka MJ Manner , NSIS Working Group , int-area@lists.ietf.org Subject: [NSIS] Re: [Int-area] RAO for IPv4 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 Roland, > Thanks for your comments. If you're interested in this topic > I'd like to point at Appendix C of the GIST draft that provides > more background information: > http://tools.ietf.org/html/draft-ietf-nsis-ntlp-14#appendix-C Thanks for the reference. I'm afraid that I don't agree with all of the rationale presented there. > We had already some discussions about this and I'll > try to summarize why we choose to use the RAO (maybe other NSIS WG > members or Robert can jump in here) approach. > It was mainly driven by RSVP experience: > 1) better chances of NAT and Firewall traversal, an own protocol > number didn't work too well for RSVP (raw IP with protocol #46) > 2) RSVP already used the RAO mechanism, thus lets re-use it. I'm fine with reusing RAO. That is in fact exactly what it's there for. However, RSVP does not attempt to piggyback any data into RAO. That's where you're diverging from the previous model and exactly where I have an issue. > Each NSIS signaling protocol (e.g, QoS NSLP or NAT/FW NSLP) > uses a specific RAO value, so a packet can bypass easily > if it carries the "wrong" RAO value. This assumes that > an implementation can specifically intercept packets > depending on the RAO value and let non-matching packets > bypass in the fast path. The whole point of RAO is to take the packet out of the fast path, regardless of the value. An NSIS implementation could, if it was carefully and specifically constructed to do so, have a fast path that did understand the signaling protocol and passed uninteresting versions in the fast path. There's no reason that this could not be done with an option independent of RAO. > I don't see the> > Hi Thomas, Bob, > > Thanks for the discussion. > > The specific application that needs (well, to be precise, would > greatly > benefit) RAO is NSIS. That is why NSIS ML is CC:d. > > Moreover, the RSVP spec talks about multiple RAO values, but lets > it open > as to whether IPv4 should also have those, not just IPv6. > > RFC2113 also says that "The semantics of other values in the Value > field > are for further study." > > The point is, is it time to study those "other values" further? At > least > GIST and the whole NSIS framework would greatly benefit from more > values > than just "0" for IPv4, and these values should be the same for > IPv6 also, > for simplified implementations. > > There is a lot of discussions about RAO in the GIST spec, e.g., > Sections > 4.3.1., 4.3.4., 5.3.2.1., 5.3.2.2., 6. IANA Considerations and > Appendix C: > > http://tools.ietf.org/wg/nsis/draft-ietf-nsis-ntlp/ > > > Regards, > Jukka > > > On Wed, 24 Oct 2007, Thomas Narten wrote: > >> Bob Hinden and I had some further offlist discussion about this. >> >> My understanding is that the IPv4 RA option is very basic. It says >> "look at this packet". The option itself doesn't contain any >> additional information or "hint" as to what to look for or what the >> packet contains. >> >> The semantics of the IPv6 router alert option are different. The >> value >> itself is used to convey additional "hints" about processing. >> >> My sense is that the semantics of the IPv4 and IPv6 Router Alert >> option are sufficiently different that sharing the name space just >> doesn't make any sense. >> >> That is, the ID says: >> >> This document proposes the creation of a new IANA registry for >> managing IPv4 Router Alert Option Values. In conjunction with >> this, it also proposes an update to the way in which IPv6 Router >> Alert Option Values are assigned in the existing IANA registry. >> >> But there are no defined IPv4 Router Alert Option values (other than >> zero), and it would be inappropriate to change the semantics of any >> existing usages (too late for that) and it would also be >> inappropriate >> to consider doing this in the absense of a specific new application >> that would make use of a new value. This document does not propose >> such a new usage. >> >> Hence, at this point, I'm opposed to the actions called for in the >> document. >> >> Thomas >> > > > _______________________________________________ > Int-area mailing list > Int-area@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/int-area _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Oct 24 20:08:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkqFp-0001PM-Q7; Wed, 24 Oct 2007 20:07:17 -0400 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1Ikpp9-00067P-CI for nsis-confirm+ok@megatron.ietf.org; Wed, 24 Oct 2007 19:39:43 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ikpp9-000673-1E for nsis@ietf.org; Wed, 24 Oct 2007 19:39:43 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ikpp8-00055b-Ga for nsis@ietf.org; Wed, 24 Oct 2007 19:39:42 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 24 Oct 2007 16:39:42 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l9ONdf3L031721; Wed, 24 Oct 2007 16:39:41 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l9ONddj1005262; Wed, 24 Oct 2007 23:39:41 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); danger that "multiple protocols are piggybacking > on RAO", because only protocols will use this mechanism if > they need to _intercept_ packets, like GIST does for discovering > signaling nodes along a flow's path. This results in GIST using RAO as a transport, which is simply a layering violation. Again, there's no reason to not allocate a separate option for carrying this value. Please consider the case of GISTv2. What do you? Allocate more RAO values? What happens if there's some other subsequent protocol that wants hop-by-hop visibility. Do you allocate bits for that protocol from RAO as well? Suppose that it needs to co-exist with GIST. Do you allocate code points for the cross product of the two protocol code points? What happens if there's a third protocol? > I don't understand what you mean by "allocate another option on a > per-protocol basis". Do you mean an own protocol number or a new IP > option or demultiplexing within the protocol itself (which we also > do). > Could you explain this a little bit more? I'm suggesting another IP option that has semantics independent from RAO that would be wholly used for GIST. Tony _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis Wed, 24 Oct 2007 16:39:39 -0700 Received: from [171.70.246.92] ([171.70.246.92]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 24 Oct 2007 16:39:39 -0700 In-Reply-To: <471FC70E.4010405@tm.uka.de> References: <200710111233.l9BCXhrU011347@localhost.localdomain> <200710241431.l9OEVqIO030663@cichlid.raleigh.ibm.com> <67DBA10E-1363-4C73-ABB8-0CF3BF739C1E@cisco.com> <471FC70E.4010405@tm.uka.de> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0C9555DB-F6F9-4A3F-A379-31E68F5B585F@cisco.com> Content-Transfer-Encoding: 7bit From: Tony Li Date: Wed, 24 Oct 2007 16:39:28 -0700 To: Roland Bless X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 24 Oct 2007 23:39:39.0016 (UTC) FILETIME=[249C6080:01C81697] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2944; t=1193269181; x=1194133181; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=tli@cisco.com; z=From:=20Tony=20Li=20 |Subject:=20Re=3A=20[Int-area]=20RAO=20for=20IPv4 |Sender:=20; bh=/bt2iEbFlWJvnY0ZBbQJmU4eWIwQVrgqwwvYptSJeSw=; b=SSQwifu0HVzLSm+h9QvQlgr9DVklNH+HgPqYfIcsj0o+MLgXwS3p3aneF+clLzH+6eRsj8bl OC4CdgaENimyXFq9qUiVBfkZF65N39V0tQNZ6WuK2x0SqTgoyv+0mDzE0Wsxwb5QoySTenaPZS IDWKaseW6DV2K9hcNZujfY1Sk=; Authentication-Results: sj-dkim-1; header.From=tli@cisco.com; dkim=pass (sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a X-Mailman-Approved-At: Wed, 24 Oct 2007 20:07:17 -0400 Cc: Jukka MJ Manner , NSIS Working Group , int-area@lists.ietf.org Subject: [NSIS] Re: [Int-area] RAO for IPv4 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 Roland, > Thanks for your comments. If you're interested in this topic > I'd like to point at Appendix C of the GIST draft that provides > more background information: > http://tools.ietf.org/html/draft-ietf-nsis-ntlp-14#appendix-C Thanks for the reference. I'm afraid that I don't agree with all of the rationale presented there. > We had already some discussions about this and I'll > try to summarize why we choose to use the RAO (maybe other NSIS WG > members or Robert can jump in here) approach. > It was mainly driven by RSVP experience: > 1) better chances of NAT and Firewall traversal, an own protocol > number didn't work too well for RSVP (raw IP with protocol #46) > 2) RSVP already used the RAO mechanism, thus lets re-use it. I'm fine with reusing RAO. That is in fact exactly what it's there for. However, RSVP does not attempt to piggyback any data into RAO. That's where you're diverging from the previous model and exactly where I have an issue. > Each NSIS signaling protocol (e.g, QoS NSLP or NAT/FW NSLP) > uses a specific RAO value, so a packet can bypass easily > if it carries the "wrong" RAO value. This assumes that > an implementation can specifically intercept packets > depending on the RAO value and let non-matching packets > bypass in the fast path. The whole point of RAO is to take the packet out of the fast path, regardless of the value. An NSIS implementation could, if it was carefully and specifically constructed to do so, have a fast path that did understand the signaling protocol and passed uninteresting versions in the fast path. There's no reason that this could not be done with an option independent of RAO. > I don't see the danger that "multiple protocols are piggybacking > on RAO", because only protocols will use this mechanism if > they need to _intercept_ packets, like GIST does for discovering > signaling nodes along a flow's path. This results in GIST using RAO as a transport, which is simply a layering violation. Again, there's no reason to not allocate a separate option for carrying this value. Please consider the case of GISTv2. What do you? Allocate more RAO values? What happens if there's some other subsequent protocol that wants hop-by-hop visibility. Do you allocate bits for that protocol from RAO as well? Suppose that it needs to co-exist with GIST. Do you allocate code points for the cross product of the two protocol code points? What happens if there's a third protocol? > I don't understand what you mean by "allocate another option on a > per-protocol basis". Do you mean an own protocol number or a new IP > option or demultiplexing within the protocol itself (which we also > do). > Could you explain this a little bit more? I'm suggesting another IP option that has semantics independent from RAO that would be wholly used for GIST. Tony _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Oct 25 08:41:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Il20u-0006lT-3p; Thu, 25 Oct 2007 08:40:40 -0400 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1Il20t-0006lH-Go for nsis-confirm+ok@megatron.ietf.org; Thu, 25 Oct 2007 08:40:39 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Il20s-0006kN-Jf for nsis@ietf.org; Thu, 25 Oct 2007 08:40:38 -0400 Received: from rsys002x.roke.co.uk ([193.118.201.109]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Il20s-0005SZ-2w for nsis@ietf.org; Thu, 25 Oct 2007 08:40:38 -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 l9PCeRsr021811; Thu, 25 Oct 2007 13:40:27 +0100 Received: from [193.118.198.149] ([193.118.198.149]) by rsys005a.comm.ad.roke.co.uk with Microsoft SMTPSVC(6.0.3790.1830); Thu, 25 Oct 2007 13:40:27 +0100 Message-ID: <47208EC0.4080600@roke.co.uk> Date: Thu, 25 Oct 2007 13:40:32 +0100 From: Andrew McDonald User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Thomas Narten References: <200710111233.l9BCXhrU011347@localhost.localdomain> <200710241431.l9OEVqIO030663@cichlid.raleigh.ibm.com> In-Reply-To: <200710241431.l9OEVqIO030663@cichlid.raleigh.ibm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Oct 2007 12:40:27.0055 (UTC) FILETIME=[3837D3F0:01C81704] 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: Bob Hinden , Jukka MJ Manner , NSIS Working Group , int-area@lists.ietf.org Subject: [NSIS] Re: [Int-area] RAO for IPv4 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 Thomas Narten wrote: > But there are no defined IPv4 Router Alert Option values (other than > zero), and it would be inappropriate to change the semantics of any > existing usages (too late for that) and it would also be inappropriate > to consider doing this in the absense of a specific new application > that would make use of a new value. This document does not propose > such a new usage. It is not clear to me that there are "no defined IPv4 Router Alert Option values (other than zero)". The counter-example (as identified in section 3 of the draft we're discussing) is RSVP aggregation in RFC3175 (in particular sections 1.4.9 and 6). Andrew _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Oct 25 09:18:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Il2aL-0003Og-Gr; Thu, 25 Oct 2007 09:17:17 -0400 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1Il2aK-0003Ob-R4 for nsis-confirm+ok@megatron.ietf.org; Thu, 25 Oct 2007 09:17:16 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Il2aK-0003OQ-Dg for nsis@ietf.org; Thu, 25 Oct 2007 09:17:16 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Il2aJ-0006R6-Rx for nsis@ietf.org; Thu, 25 Oct 2007 09:17:16 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by sj-iport-6.cisco.com with ESMTP; 25 Oct 2007 06:17:10 -0700 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l9PDHAoi004775; Thu, 25 Oct 2007 09:17:10 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l9PDH9Qq000678; Thu, 25 Oct 2007 13:17:09 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 25 Oct 2007 09:16:46 -0400 Received: from swbmbp.local.employees.org ([10.86.242.230]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 25 Oct 2007 09:16:46 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18208.38717.382619.873033@swbmbp.local> Date: Thu, 25 Oct 2007 09:16:45 -0400 From: Scott Brim To: Tony Li In-Reply-To: <0C9555DB-F6F9-4A3F-A379-31E68F5B585F@cisco.com> References: <200710111233.l9BCXhrU011347@localhost.localdomain> <200710241431.l9OEVqIO030663@cichlid.raleigh.ibm.com> <67DBA10E-1363-4C73-ABB8-0CF3BF739C1E@cisco.com> <471FC70E.4010405@tm.uka.de> <0C9555DB-F6F9-4A3F-A379-31E68F5B585F@cisco.com> X-Mailer: VM 8.0.3-495 under Emacs 22.1.1 (i386-apple-darwin8.10.1) X-OriginalArrivalTime: 25 Oct 2007 13:16:46.0357 (UTC) FILETIME=[4B2EEC50:01C81709] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15504.002 X-TM-AS-Result: No--30.093800-8.000000-2 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Authentication-Results: rtp-dkim-2; header.From=swb@employees.org; dkim=neutral X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: Roland Bless , Jukka MJ Manner , NSIS Working Group , int-area@lists.ietf.org Subject: [NSIS] Re: [Int-area] RAO for IPv4 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 not paid attention to NSIS recently but architecturally I find Tony's arguments to be very persuasive. swb On 24 Oct 2007 at 16:39 -0700, Tony Li allegedly wrote: > > Hi Roland, > > > Thanks for your comments. If you're interested in this topic > > I'd like to point at Appendix C of the GIST draft that provides > > more background information: > > http://tools.ietf.org/html/draft-ietf-nsis-ntlp-14#appendix-C > > > Thanks for the reference. I'm afraid that I don't agree with all of the > rationale presented there. > > > > We had already some discussions about this and I'll > > try to summarize why we choose to use the RAO (maybe other NSIS WG > > members or Robert can jump in here) approach. > > It was mainly driven by RSVP experience: > > 1) better chances of NAT and Firewall traversal, an own protocol > > number didn't work too well for RSVP (raw IP with protocol #46) > > 2) RSVP already used the RAO mechanism, thus lets re-use it. > > > I'm fine with reusing RAO. That is in fact exactly what it's there > for. However, > RSVP does not attempt to piggyback any data into RAO. That's where > you're diverging from the previous model and exactly where I have an > issue. > > > > Each NSIS signaling protocol (e.g, QoS NSLP or NAT/FW NSLP) > > uses a specific RAO value, so a packet can bypass easily > > if it carries the "wrong" RAO value. This assumes that > > an implementation can specifically intercept packets > > depending on the RAO value and let non-matching packets > > bypass in the fast path. > > > The whole point of RAO is to take the packet out of the fast path, > regardless of the value. An NSIS implementation could, if it was > carefully and specifically constructed to do so, have a fast path > that did understand the signaling protocol and passed uninteresting > versions in the fast path. There's no reason that this could not > be done with an option independent of RAO. > > > > I don't see the danger that "multiple protocols are piggybacking > > on RAO", because only protocols will use this mechanism if > > they need to _intercept_ packets, like GIST does for discovering > > signaling nodes along a flow's path. > > > This results in GIST using RAO as a transport, which is simply > a layering violation. Again, there's no reason to not allocate a > separate > option for carrying this value. Please consider the case of > GISTv2. What do you? Allocate more RAO values? What happens if > there's some other subsequent protocol that wants hop-by-hop > visibility. Do you allocate bits for that protocol from RAO as well? > Suppose that it needs to co-exist with GIST. Do you allocate code > points for the cross product of the two protocol code points? What > happens if there's a third protocol? > > > > I don't understand what you mean by "allocate another option on a > > per-protocol basis". Do you mean an own protocol number or a new IP > > option or demultiplexing within the protocol itself (which we also > > do). > > Could you explain this a little bit more? > > > I'm suggesting another IP option that has semantics independent > from RAO that would be wholly used for GIST. > > Tony > > > _______________________________________________ > Int-area mailing list > Int-area@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/int-area _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Oct 25 11:27:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Il4bQ-0001Iy-1u; Thu, 25 Oct 2007 11:26:32 -0400 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1Il4bO-0001IX-OJ for nsis-confirm+ok@megatron.ietf.org; Thu, 25 Oct 2007 11:26:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Il4bO-0001H4-2T; Thu, 25 Oct 2007 11:26:30 -0400 Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Il4bG-00081U-Pn; Thu, 25 Oct 2007 11:26:30 -0400 Received: from irams2.ira.uni-karlsruhe.de ([141.3.10.82]) by iramx2.ira.uni-karlsruhe.de with esmtps id 1Il4b4-0007Np-Un; Thu, 25 Oct 2007 17:26:13 +0200 Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5]) by irams2.ira.uni-karlsruhe.de with esmtps id 1Il4b3-00010v-GR; Thu, 25 Oct 2007 17:26:10 +0200 Received: from i72ms.tm.uni-karlsruhe.de ([141.3.70.5] helo=smtp.ipv6.tm.uni-karlsruhe.de) by irams1.ira.uni-karlsruhe.de with esmtps id 1Il4b3-0007C8-6a; Thu, 25 Oct 2007 17:26:09 +0200 Received: from vorta.ipv6.tm.uni-karlsruhe.de (vorta.ipv6.tm.uni-karlsruhe.de [IPv6:2001:638:204:6:207:e9ff:fe0c:5e44]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id 296C12FC00E; Thu, 25 Oct 2007 17:26:08 +0200 (CEST) Received: from localhost ([127.0.0.1]) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.44) id 1Il4b1-0006qh-Qa; Thu, 25 Oct 2007 17:26:07 +0200 Message-ID: <4720B58F.9010209@tm.uka.de> Date: Thu, 25 Oct 2007 17:26:07 +0200 From: Roland Bless Organization: Institute of Telematics, University of Karlsruhe User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060111 Thunderbird/1.5 Mnenhy/0.7.3.0 MIME-Version: 1.0 To: Tony Li Subject: Re: [NSIS] Re: [Int-area] RAO for IPv4 References: <200710111233.l9BCXhrU011347@localhost.localdomain> <200710241431.l9OEVqIO030663@cichlid.raleigh.ibm.com> <67DBA10E-1363-4C73-ABB8-0CF3BF739C1E@cisco.com> <471FC70E.4010405@tm.uka.de> <0C9555DB-F6F9-4A3F-A379-31E68F5B585F@cisco.com> In-Reply-To: <0C9555DB-F6F9-4A3F-A379-31E68F5B585F@cisco.com> X-Enigmail-Version: 0.94.4.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Status: No X-Spam-Score: -1.3 (-) X-Spam-Report: -1.4 ALL_TRUSTED Passed through trusted hosts only via SMTP 0.1 AWL AWL: From: address is in the auto white-list X-Spam-Host: irams2.ira.uni-karlsruhe.de X-ATIS-Checksum: v3zoCAcc32ckk X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: Jukka MJ Manner , NSIS Working Group , int-area@lists.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 Tony, Tony Li wrote: > Thanks for the reference. I'm afraid that I don't agree with all of the > rationale presented there. Oops, good to hear another opinion. > I'm fine with reusing RAO. That is in fact exactly what it's there > for. However, > RSVP does not attempt to piggyback any data into RAO. That's where > you're diverging from the previous model and exactly where I have an > issue. Ok. You are referring to the fact that the NSLP-ID is somehow mapped to the RAO value. Probably that's new, because RSVP is only one signaling application whereas GIST was designed to support different signaling applications like QoS-NSLP and NAT/FW-NSLP. > The whole point of RAO is to take the packet out of the fast path, > regardless of the value. An NSIS implementation could, if it was > carefully and specifically constructed to do so, have a fast path > that did understand the signaling protocol and passed uninteresting > versions in the fast path. There's no reason that this could not > be done with an option independent of RAO. There is no need that the fast path understands the signaling protocol. It simply takes only those packets out of the fast path that have a particular matching set of RAO values, and ideally packets with other RAO values are simply forwarded without leaving the fast path. This is especially useful for aggregation techniques (e.g., RFC 3175). However, if you think about inter-domain aggregation RAO values do not help much and that's where using a new option could be interesting indeed. So I guess you are correct: conceptually the RAO values are shared between different applications depending on such a functionality. Currently, that would be: RSVP + RSVP Aggregation, GIST per NSLP + Aggregation for QoS NSLP. We discussed RAO things also last year at IETF-67: see http://www3.ietf.org/proceedings/06nov/slides/nsis-1/sld13.htm and http://www3.ietf.org/proceedings/06nov/minutes/nsis.txt One conclusion was that some existing implementations for RAO are definitely broken, but should be fixed for RSVP anyway. Problem with Firewalls are always expected, too. > This results in GIST using RAO as a transport, which is simply > a layering violation. Again, there's no reason to not allocate a separate > option for carrying this value. Please consider the case of > GISTv2. What do you? Allocate more RAO values? What happens if > there's some other subsequent protocol that wants hop-by-hop > visibility. Do you allocate bits for that protocol from RAO as well? > Suppose that it needs to co-exist with GIST. Do you allocate code > points for the cross product of the two protocol code points? What > happens if there's a third protocol? These are indeed good questions. For NSLP versions: I vaguely remember discussing last year on the NSIS list that different NSLP versions must be demultiplexed within the NSLP itself and we do not consider to allocated a NSLP-ID per version. > I'm suggesting another IP option that has semantics independent > from RAO that would be wholly used for GIST. Ok. This would probably make chances smaller that GIST packets pass firewalls or NATs. However, GIST will not work very well through NATs without special NAT support anyway, so the new option should be implemented together with GIST support in these boxes. But legacy middleboxes may break the connectivity for GIST then. What do others think? Regards, Roland _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Oct 25 11:36:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Il4jl-0008Os-3M; Thu, 25 Oct 2007 11:35:09 -0400 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1Il4jj-0008MG-4y for nsis-confirm+ok@megatron.ietf.org; Thu, 25 Oct 2007 11:35:07 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Il4ji-0008M7-Oo for nsis@ietf.org; Thu, 25 Oct 2007 11:35:06 -0400 Received: from rsys002x.roke.co.uk ([193.118.201.109]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Il4jh-0002p7-7J for nsis@ietf.org; Thu, 25 Oct 2007 11:35:06 -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 l9PFYdfo020904; Thu, 25 Oct 2007 16:34:39 +0100 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: [Int-area] RAO for IPv4 Date: Thu, 25 Oct 2007 16:34:37 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] Re: [Int-area] RAO for IPv4 Thread-Index: AcgXCa2oEOQL6ADuSUmP7uXFquRiswADFICg References: <200710111233.l9BCXhrU011347@localhost.localdomain><200710241431.l9OEVqIO030663@cichlid.raleigh.ibm.com><67DBA10E-1363-4C73-ABB8-0CF3BF739C1E@cisco.com><471FC70E.4010405@tm.uka.de><0C9555DB-F6F9-4A3F-A379-31E68F5B585F@cisco.com> <18208.38717.382619.873033@swbmbp.local> From: "Hancock, Robert" To: "Scott Brim" , "Tony Li" 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: bfe538a859d88717fa3c8a6377d62f90 Cc: Roland Bless , Jukka MJ Manner , NSIS Working Group , int-area@lists.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 ok, I'll bite:=20 > -----Original Message----- > From: Scott Brim [mailto:swb@employees.org]=20 > Sent: 25 October 2007 14:17 > To: Tony Li > Cc: Roland Bless; Jukka MJ Manner; NSIS Working Group;=20 > int-area@lists.ietf.org > Subject: [NSIS] Re: [Int-area] RAO for IPv4 >=20 > I have not paid attention to NSIS recently but=20 > architecturally I find Tony's arguments to be very persuasive. >=20 > swb >=20 > On 24 Oct 2007 at 16:39 -0700, Tony Li allegedly wrote: > >=20 > > Hi Roland, > >=20 > > > Thanks for your comments. If you're interested in this topic I'd=20 > > > like to point at Appendix C of the GIST draft that provides more=20 > > > background information: > > > http://tools.ietf.org/html/draft-ietf-nsis-ntlp-14#appendix-C > >=20 > >=20 > > Thanks for the reference. I'm afraid that I don't agree=20 > with all of=20 > > the rationale presented there. That appendix was an attempt to capture quite intense discussions between the authors, routing area reviewer, and our chairs and ADs. Quite possibly there are things which are not ideal about it - if you have concerns I'd be keen to understand them (might be easier not to influct that on the mailing lists in the first instance, however). > >=20 > >=20 > > > We had already some discussions about this and I'll try=20 > to summarize=20 > > > why we choose to use the RAO (maybe other NSIS WG members=20 > or Robert=20 > > > can jump in here) approach. > > > It was mainly driven by RSVP experience: > > > 1) better chances of NAT and Firewall traversal, an own protocol > > > number didn't work too well for RSVP (raw IP with protocol #46) > > > 2) RSVP already used the RAO mechanism, thus lets re-use it. > >=20 > >=20 > > I'm fine with reusing RAO. That is in fact exactly what it's there=20 > > for. However, RSVP does not attempt to piggyback any data=20 > into RAO. =20 > > That's where you're diverging from the previous model and exactly=20 > > where I have an issue. I don't believe either RSVP or NSIS or any other protocol is piggybacking data in the RAO, either for v4 or v6. (Except possibly in the case of RSVP aggregation, see below.) > >=20 > >=20 > > > Each NSIS signaling protocol (e.g, QoS NSLP or NAT/FW=20 > NSLP) uses a=20 > > > specific RAO value, so a packet can bypass easily if it=20 > carries the=20 > > > "wrong" RAO value. This assumes that an implementation can=20 > > > specifically intercept packets depending on the RAO value and let=20 > > > non-matching packets bypass in the fast path. > >=20 > >=20 > > The whole point of RAO is to take the packet out of the fast path,=20 > > regardless of the value. =20 That is currently the case for v4. That is not the case for v6, at least, not according to my reading of paragraph 2 of section 2.2 of rfc2711:=20 " Routers that recognize the option will examine datagrams carrying it more closely to determine whether or not further processing is necessary. The router only needs to parse the packet in sufficient detail to decide whether the packet contains something of interest. The value field can be used by an implementation to speed processing of the datagram within the transit router." So, the question on the table is whether that ability (to speed processing by looking at the value field) would be useful in the v4 case or whether for some reason it could only ever be useful for the IPv6 case. > > An NSIS implementation could, if it was=20 > > carefully and specifically constructed to do so, have a=20 > fast path that=20 > > did understand the signaling protocol and passed uninteresting=20 > > versions in the fast path. There's no reason that this=20 > could not be=20 > > done with an option independent of RAO. See below on the question of a separate option. > >=20 > >=20 > > > I don't see the danger that "multiple protocols are=20 > piggybacking on=20 > > > RAO", because only protocols will use this mechanism if=20 > they need to=20 > > > _intercept_ packets, like GIST does for discovering=20 > signaling nodes=20 > > > along a flow's path. > >=20 > >=20 > > This results in GIST using RAO as a transport, which is simply a=20 > > layering violation. =20 I'm afraid that when we are talking about relying on packet interception in the forwarding layer to pass data to a signalling protocol handler, the layering model is already being molested. But I agree that there can be layering concerns. Let me consider the v6 case again, for which there are (at least) two RAO values assigned, rsvp and mld. There are two ways to interpret the usage of RAO-carrying packets: 1) The router logic is: - if the packet carries RAO value =3D 0 it is an ICMPv6 message (IP = proto 58) with type field 130/131/132: therefore, pass it to the MLD process; - if the packet carries RAO value =3D 1 it is an RSVP message (IP proto 46) with RSVP Msg Type =3D 1 - otherwise forward the packet 2) The router logic is: - I want to intercept RSVP path messages, so pick packets with RAO value=3D1 out of the forwarding path and examine them more closely - I want to intercept MLD messages, so pick packets with RAO value=3D0 = out of the forwarding path and examine them more closely (1) certainly feels like a layering violation, and I think (2) is more architecturally sound; however, the end result is pretty much the same: RAO values are associated with specific protocols, or sub-protocols of protocols. And RAO values for IPv6 can be associated with subprotocols of NSIS in exactly the same way. If this is moral for IPv6 why can it not be for IPv4? (I'm well aware of the fact that RAO per se is much more=20 important for v4 than v6 because of header chain processing issues; however, the ability to differentiate between different RAO users in the RAO itself would seem similar.) As an aside, rfc3175 really would seem to involve a layering violation, since the aggregation level, which is very semantically signficant for the RSVP processing, is carried *only* in the RAO value field and not the RSVP messages itself. But it may be that I've misunderstood this aspect of 3175. > > Again, there's no reason to not allocate a=20 > > separate option for carrying this value. Please consider=20 > the case of=20 > > GISTv2. What do you? Allocate more RAO values? What happens if=20 > > there's some other subsequent protocol that wants hop-by-hop=20 > > visibility. Do you allocate bits for that protocol from=20 > RAO as well? > > Suppose that it needs to co-exist with GIST. Do you allocate code=20 > > points for the cross product of the two protocol code points? What=20 > > happens if there's a third protocol? There will certainly be an art to allocating new RAO values. That problem already exists for IPv6, although the IANA considerations section of 2711 is (by today's standards) somewhat brief. That does not per se show that the concept is not valid (but see further below). > >=20 > >=20 > > > I don't understand what you mean by "allocate another option on a=20 > > > per-protocol basis". Do you mean an own protocol number=20 > or a new IP=20 > > > option or demultiplexing within the protocol itself=20 > (which we also=20 > > > do). > > > Could you explain this a little bit more? > >=20 > >=20 > > I'm suggesting another IP option that has semantics=20 > independent from=20 > > RAO that would be wholly used for GIST. OK: I was initially very confused by this suggestion, because you would end up with the 'do I look at this more closely?' check on the fast path being something like IF (rao-present OR (new-option-present AND value in {interesting_values})) rather than IF (rao-present AND value in {interesting_values}) which certainly *looks* simpler. And in the first case, packets with new-option=20 would be forced onto the slow path in all existing routers, whereas in the second, marked packets could still be forwarded on the fast path in routers=20 not interested in the signalling. So while a new option is certainly possible (logically), I don't understand the backwards compatibility advantages.=20 However, it may be the case that the current facts of life are that in reality, the presence of options in IPv4 packets will just be ignored; in that case, defining a new option might be a cleaner approach. It still seems weird to me that the approach to replicate IPv6 RAO functionality in IPv4 is not to extend the IPv4 RAO spec but to introduce a new option, but backwards compatibility does lead to this sort of oddity (and far worse, of course). Bottom line: - IPv6 RAO value filtering functionality appears to be useful. If actually the modern consensus is that it is overspecified and a simpler (possibly less optimised for certain scenarios) approach is architecturally and practically better, then that is a fair view. We can forget the question for IPv4 and use a single value for IPv6; the consequence is that all nodes that process any signalling messages will have to process all signalling messages off the fast path. - If it is still the view that value-based filtering is useful for IPv6, there=20 may still be a view that it is not useful for IPv4. However, I haven't seen that argument. - If value-based filtering is useful for IPv4, you can either achieve it by extending rfc2113 or defining a new option for IPv4. And we can then work out the pros and cons of those approaches. thanks for reading, robert h. > >=20 > > Tony > >=20 > >=20 > > _______________________________________________ > > Int-area mailing list > > Int-area@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/int-area >=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 Thu Oct 25 11:45:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Il4tl-0003lf-RU; Thu, 25 Oct 2007 11:45:29 -0400 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1Il4tk-0003kO-8H for nsis-confirm+ok@megatron.ietf.org; Thu, 25 Oct 2007 11:45:28 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Il4tj-0003kF-TS for nsis@ietf.org; Thu, 25 Oct 2007 11:45:27 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Il4tj-0003D9-Fr for nsis@ietf.org; Thu, 25 Oct 2007 11:45:27 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 25 Oct 2007 08:45:27 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l9PFjQhA026855; Thu, 25 Oct 2007 08:45:26 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l9PFjP7F006359; Thu, 25 Oct 2007 15:45:26 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 25 Oct 2007 08:45:24 -0700 Received: from [192.168.0.110] ([10.21.70.135]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 25 Oct 2007 08:45:24 -0700 In-Reply-To: <47208EC0.4080600@roke.co.uk> References: <200710111233.l9BCXhrU011347@localhost.localdomain> <200710241431.l9OEVqIO030663@cichlid.raleigh.ibm.com> <47208EC0.4080600@roke.co.uk> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <215B4BB6-3C10-4965-A710-624DECEE137A@cisco.com> Content-Transfer-Encoding: 7bit From: Tony Li Date: Thu, 25 Oct 2007 08:45:23 -0700 To: Andrew McDonald X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 25 Oct 2007 15:45:24.0249 (UTC) FILETIME=[0EA94090:01C8171E] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1843; t=1193327126; x=1194191126; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=tli@cisco.com; z=From:=20Tony=20Li=20 |Subject:=20Re=3A=20[Int-area]=20RAO=20for=20IPv4 |Sender:=20; bh=RQOu3tM5KWfM5tdsJRjfzYakRaSXD1lXNQNLiQFEO5A=; b=jZwMCR/0jX0Yr6HEw3qamQZBec65chWMJA4sszke9s5aEzw3MysAN/LOs00WQutnczRAELys K0zmMnDL+A9VnzC9ZqkBhi+hnbDV///OaHbjB+ybTejiviiyRWFT8u1F; Authentication-Results: sj-dkim-3; header.From=tli@cisco.com; dkim=pass (sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: Thomas Narten , Jukka MJ Manner , NSIS Working Group , int-area@lists.ietf.org Subject: [NSIS] Re: [Int-area] RAO for IPv4 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 On Oct 25, 2007, at 5:40 AM, Andrew McDonald wrote: > Thomas Narten wrote: >> But there are no defined IPv4 Router Alert Option values (other than >> zero), and it would be inappropriate to change the semantics of any >> existing usages (too late for that) and it would also be >> inappropriate >> to consider doing this in the absense of a specific new application >> that would make use of a new value. This document does not propose >> such a new usage. > > It is not clear to me that there are "no defined IPv4 Router Alert > Option values (other than zero)". The counter-example (as > identified in section 3 of the draft we're discussing) is RSVP > aggregation in RFC3175 (in particular sections 1.4.9 and 6). Thanks for this reference. After digging around some more, it appears clear to me that there's a little bit of a disconnect someplace. I would have expected the code points defined for IPv6 and IPv4 to be wholly identical, down to the point of there being a single IANA registry. As it stands right now, there is no registry for IPv4, so the real reference is 2113, which only defines 0. Yes, 3175 talk about defining other values but if you read the IANA considerations section it is not at all clear that they meant to extend this to IPv4, tho they certainly should have. In any case, I agree that this is ample precedent for allocating code points for RAO, and undercuts my arguments completely. Given that I no longer have a leg to stand on, I'll sit down and shut up. ;-) One request tho: while you're allocating a new code point, could you please clean up the IANA situation? Please request that there be a single code point registry for both IPv6 and IPv4 RAO that includes all of the currently defined code points. Thanks, Tony _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Oct 25 11:52:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Il4z4-00075Q-MS; Thu, 25 Oct 2007 11:50:58 -0400 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1Il4z2-00074q-N8 for nsis-confirm+ok@megatron.ietf.org; Thu, 25 Oct 2007 11:50:56 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Il4z2-00074h-Bd for nsis@ietf.org; Thu, 25 Oct 2007 11:50:56 -0400 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Il4z1-0003Py-Qo for nsis@ietf.org; Thu, 25 Oct 2007 11:50:56 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l9PFodCL003464; Thu, 25 Oct 2007 18:50:45 +0300 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 25 Oct 2007 18:50:41 +0300 Received: from daebe104.NOE.Nokia.com ([10.241.36.13]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 25 Oct 2007 10:50:38 -0500 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, 25 Oct 2007 10:50:37 -0500 Message-ID: <19EBBEC503C3B5469070E0A6674A533AABF32C@daebe104.NOE.Nokia.com> In-Reply-To: <215B4BB6-3C10-4965-A710-624DECEE137A@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Int-area] RAO for IPv4 Thread-Index: AcgXHnxzxJ87kG8fSdybHcd1eW+/GQAACCtw References: <200710111233.l9BCXhrU011347@localhost.localdomain><200710241431.l9OEVqIO030663@cichlid.raleigh.ibm.com><47208EC0.4080600@roke.co.uk> <215B4BB6-3C10-4965-A710-624DECEE137A@cisco.com> From: To: , X-OriginalArrivalTime: 25 Oct 2007 15:50:38.0442 (UTC) FILETIME=[C9EF4CA0:01C8171E] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: jmanner@cs.Helsinki.FI, nsis@ietf.org, int-area@lists.ietf.org Subject: [NSIS] RE: [Int-area] RAO for IPv4 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 Tony, >As it stands right now, there is no registry for IPv4, so the=20 >real reference is 2113, which only defines 0. Yes, 3175 talk=20 >about defining other values but if you read the IANA=20 >considerations section it is not at all clear that they meant=20 >to extend this to IPv4, tho they certainly should have. > >In any case, I agree that this is ample precedent for=20 >allocating code points for RAO, and undercuts my arguments completely. > >Given that I no longer have a leg to stand on, I'll sit down=20 >and shut up. ;-) > >One request tho: while you're allocating a new code point,=20 >could you please clean up the IANA situation? Please request=20 >that there be a single code point registry for both IPv6 and=20 >IPv4 RAO that includes all of the currently defined code points. Well, I think we in NSIS really want to do the 'right thing' so=20 to speak, and we came to the conclusion that you have. The authors of the draft are seeking some consensus on how to move forward with this, as this area is definitely murky. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis