From nsis-bounces@ietf.org Sun Apr 01 14:15:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HY4Yw-00079s-FS; Sun, 01 Apr 2007 14:13:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HY4Yv-00079m-88 for nsis@ietf.org; Sun, 01 Apr 2007 14:13:57 -0400 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HY4Yt-0004wr-RC for nsis@ietf.org; Sun, 01 Apr 2007 14:13:57 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l31IDoeH021280 for ; Sun, 1 Apr 2007 21:13:53 +0300 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 1 Apr 2007 21:13:51 +0300 Received: from daebe103.NOE.Nokia.com ([10.241.35.24]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 1 Apr 2007 13:13:49 -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: Sun, 1 Apr 2007 13:13:48 -0500 Message-ID: <071568CA7B789D4AA170CEF8C9613B4F61FB99@daebe103.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RMD WGLC Extension Thread-Index: Acd0iX5V0EYZvza0RTeu2r31X3eCZQ== From: To: X-OriginalArrivalTime: 01 Apr 2007 18:13:49.0331 (UTC) FILETIME=[7EFEAE30:01C77489] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070401211353-4D3E4BB0-7B1F80BB/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Subject: [NSIS] RMD WGLC Extension 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 discussed this with Martin and agree that we should extend the WGLC by one week. We need to get comments that the WG has read the document and is comfortable with forwarding this to the IESG. As noted during the IESG Review of GIST, the IESG will take a very critical review of all of our WG's documents, so we need to be sure that we have consensus behind this. John > Hi all, > > Noone has commented about the RMD document during the WGLC. Does this > mean everyone is OK with the current document and feel it accurately=20 > reflects WG concensus? Or does it mean noone has read it, and the=20 > interest level is low from the WG? > > Could people who have read the document please send a mail saying so? > For people who have an opinion, > please comment. I need this information before I can send this=20 > forward to the IESG. > > John > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Apr 02 05:39:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYIzN-0002bc-QS; Mon, 02 Apr 2007 05:38:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYIzM-0002bP-Mm for nsis@ietf.org; Mon, 02 Apr 2007 05:38:12 -0400 Received: from smtp.dei.uc.pt ([193.137.203.228] helo=smtp2.dei.uc.pt) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYIzK-0007A3-Ju for nsis@ietf.org; Mon, 02 Apr 2007 05:38:12 -0400 Received: from kanito (gisttest1.dei.uc.pt [193.136.212.207]) (authenticated bits=0) by smtp2.dei.uc.pt (8.13.8/8.13.8) with ESMTP id l329c0Fm024486 for ; Mon, 2 Apr 2007 10:38:00 +0100 Message-Id: <200704020938.l329c0Fm024486@smtp2.dei.uc.pt> From: "David Palma" To: Date: Mon, 2 Apr 2007 10:38:02 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: Acd1CpthXl44Oh84Qz2XRZxaaiusxA== X-FCTUC-DEI-SIC-MailScanner-Information: Please contact helpdesk@dei.uc.pt for more information X-FCTUC-DEI-SIC-MailScanner: Found to be clean X-FCTUC-DEI-SIC-MailScanner-SpamCheck: not spam (whitelisted), SpamAssassin (not cached, score=-41.159, required 3, autolearn=not spam, ALL_TRUSTED -1.80, AWL 10.64, L_SMTP_AUTH -50.00) X-FCTUC-DEI-SIC-MailScanner-From: palma@student.dei.uc.pt X-Spam-Status: No X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Subject: [NSIS] Summary Refreshes on QoS NSLP X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi all, I'm from the University of Coimbra and I've been working on QoS NSLP v13. When reading about summary refreshes I wondered how we could decide what sessions to include in the summary refreshes list. I believe that we could not only include ready to refresh sessions but also sessions that in will shortly (less than one second or so) be ready to refresh. Is this assumption correct? Is there any way to calculate whether we should refresh a session earlier or not, so that we can include it in the summary refresh list? Thank you in advance, David Palma -- Checked by AVG Free Edition. Version: 7.1.413 / Virus Database: 268.18.22/739 - Release Date: 29-03-2007 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Apr 02 07:07: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 1HYKMz-00080A-9P; Mon, 02 Apr 2007 07:06:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYKMx-000805-7K for nsis@ietf.org; Mon, 02 Apr 2007 07:06:39 -0400 Received: from smtp2.smtp.bt.com ([217.32.164.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYKMr-0006p4-QR for nsis@ietf.org; Mon, 02 Apr 2007 07:06:39 -0400 Received: from i2kc07-ukbr.domain1.systemhost.net ([193.113.197.14]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Apr 2007 12:06:25 +0100 Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.61]) by i2kc07-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Apr 2007 12:06:25 +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] RMD WGLC Extension Date: Mon, 2 Apr 2007 12:06:24 +0100 Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA5019DC074@E03MVZ1-UKDY.domain1.systemhost.net> In-Reply-To: <071568CA7B789D4AA170CEF8C9613B4F61FB99@daebe103.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] RMD WGLC Extension Thread-Index: Acd0iX5V0EYZvza0RTeu2r31X3eCZQAjIZOA From: To: , X-OriginalArrivalTime: 02 Apr 2007 11:06:25.0186 (UTC) FILETIME=[F44E7020:01C77516] X-Spam-Score: 0.2 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Do you think the document should mention the PCN WG? To me, the relationship with PCN seems an obvious thing for the iesg to ask. For example maybe the doc could explain that part of RMD forms "part of some research or development effort" that has (is) contributing to PCN WG standardisation [quote from BCP9 about Experimental docs]. I don't know if something more detailed would be expected? Best wishes Philip Eardley=20 > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > Sent: 01 April 2007 19:14 > To: nsis@ietf.org > Subject: [NSIS] RMD WGLC Extension >=20 > I discussed this with Martin and agree that we should extend the WGLC by > one week. We need to get comments that the WG has read the document and > is comfortable with forwarding this to the IESG. As noted during the > IESG Review of GIST, the IESG will take a very critical review of all of > our WG's documents, so we need to be sure that we have consensus behind > this. >=20 > John >=20 > > Hi all, > > > > Noone has commented about the RMD document during the WGLC. Does this >=20 > > mean everyone is OK with the current document and feel it accurately > > reflects WG concensus? Or does it mean noone has read it, and the > > interest level is low from the WG? > > > > Could people who have read the document please send a mail saying so? > > For people who have an opinion, > > please comment. I need this information before I can send this > > forward to the IESG. > > > > John > > >=20 > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Apr 02 13:26:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYQHp-0000ne-Je; Mon, 02 Apr 2007 13:25:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYQHo-0000mU-N3 for nsis@ietf.org; Mon, 02 Apr 2007 13:25:44 -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 1HYQHn-0003tO-Dv for nsis@ietf.org; Mon, 02 Apr 2007 13:25:44 -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, 02 Apr 2007 20:25:33 +0300 id 0005FEAD.46113C8D.0000672E Date: Mon, 2 Apr 2007 20:25:33 +0300 (EEST) From: Jukka MJ Manner To: David Palma Subject: Re: [NSIS] Summary Refreshes on QoS NSLP In-Reply-To: <200704020938.l329c0Fm024486@smtp2.dei.uc.pt> Message-ID: References: <200704020938.l329c0Fm024486@smtp2.dei.uc.pt> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi David, What you describe is an implementation issue and depends on the deployment. Thus, we can't give any solution. Something along your description could be one way forward. Cheers, Jukka On Mon, 2 Apr 2007, David Palma wrote: > Hi all, > > I'm from the University of Coimbra and I've been working on QoS NSLP v13. > > When reading about summary refreshes I wondered how we could decide what > sessions to include in the summary refreshes list. I believe that we could > not only include ready to refresh sessions but also sessions that in will > shortly (less than one second or so) be ready to refresh. > > Is this assumption correct? Is there any way to calculate whether we should > refresh a session earlier or not, so that we can include it in the summary > refresh list? > > Thank you in advance, > David Palma > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Apr 02 18:50: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 1HYVLn-00082u-6j; Mon, 02 Apr 2007 18:50:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYVLi-000829-V8; Mon, 02 Apr 2007 18:50:06 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYVLi-0004E5-Mg; Mon, 02 Apr 2007 18:50:06 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 873A626EBB; Mon, 2 Apr 2007 22:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HYVLe-0002G8-EK; Mon, 02 Apr 2007 18:50: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: Mon, 02 Apr 2007 18:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: nsis@ietf.org Subject: [NSIS] I-D ACTION:draft-ietf-nsis-y1541-qosm-04.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 : Y.1541-QOSM -- Y.1541 QoS Model for Networks Using Y.1541 QoS Classes Author(s) : J. Ash, et al. Filename : draft-ietf-nsis-y1541-qosm-04.txt Pages : 11 Date : 2007-4-2 This draft describes a QoS-NSLP QoS model (QOSM) based on ITU-T Recommendation Y.1541 QoS signaling requirements. Y.1541 specifies 8 standard QoS classes, and the Y.1541-QOSM extensions include additional QSPEC parameters and QOSM processing guidelines. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nsis-y1541-qosm-04.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-y1541-qosm-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-nsis-y1541-qosm-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --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-4-2150510.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nsis-y1541-qosm-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nsis-y1541-qosm-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-4-2150510.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 Mon Apr 02 18:51: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 1HYVMG-00087B-Hh; Mon, 02 Apr 2007 18:50:40 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYVMA-00085p-1P; Mon, 02 Apr 2007 18:50:34 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HYVM8-0000Fj-N3; Mon, 02 Apr 2007 18:50:33 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id A218E175BD; Mon, 2 Apr 2007 22:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HYVLe-0002G5-Dn; Mon, 02 Apr 2007 18:50: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: Mon, 02 Apr 2007 18:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: nsis@ietf.org Subject: [NSIS] I-D ACTION:draft-ietf-nsis-y1541-qosm-04.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 : Y.1541-QOSM -- Y.1541 QoS Model for Networks Using Y.1541 QoS Classes Author(s) : J. Ash, et al. Filename : draft-ietf-nsis-y1541-qosm-04.txt Pages : 11 Date : 2007-4-2 This draft describes a QoS-NSLP QoS model (QOSM) based on ITU-T Recommendation Y.1541 QoS signaling requirements. Y.1541 specifies 8 standard QoS classes, and the Y.1541-QOSM extensions include additional QSPEC parameters and QOSM processing guidelines. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nsis-y1541-qosm-04.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-y1541-qosm-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-nsis-y1541-qosm-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --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-4-2150412.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nsis-y1541-qosm-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nsis-y1541-qosm-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-4-2150412.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 Mon Apr 02 19:30:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYVyB-000099-Sg; Mon, 02 Apr 2007 19:29:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYVy9-0008Vh-Sq for nsis@ietf.org; Mon, 02 Apr 2007 19:29:49 -0400 Received: from mail120.messagelabs.com ([216.82.250.83]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HYVy3-0005rf-5W for nsis@ietf.org; Mon, 02 Apr 2007 19:29:49 -0400 X-VirusChecked: Checked X-Env-Sender: gash@att.com X-Msg-Ref: server-4.tower-120.messagelabs.com!1175556581!20595136!1 X-StarScan-Version: 5.5.10.7.1; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 25502 invoked from network); 2 Apr 2007 23:29:42 -0000 Received: from unknown (HELO attrh3i.attrh.att.com) (134.24.146.4) by server-4.tower-120.messagelabs.com with SMTP; 2 Apr 2007 23:29:42 -0000 Received: from attrh.att.com (localhost [127.0.0.1]) by attrh3i.attrh.att.com (8.13.8/8.13.8) with ESMTP id l32NTfei025254 for ; Mon, 2 Apr 2007 19:29:41 -0400 (EDT) Received: from kcclust06evs1.ugd.att.com ([135.38.164.88]) by attrh3i.attrh.att.com (8.13.8/8.13.8) with ESMTP id l32NTSIA025188 for ; Mon, 2 Apr 2007 19:29:36 -0400 (EDT) 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] I-D ACTION:draft-ietf-nsis-y1541-qosm-04.txt Date: Mon, 2 Apr 2007 18:29:18 -0500 Message-ID: <9473683187ADC049A855ED2DA739ABCA0DDC837E@KCCLUST06EVS1.ugd.att.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] I-D ACTION:draft-ietf-nsis-y1541-qosm-04.txt Thread-Index: Acd1eXLD2aAH7+hNTwqnLqb/C3XLmwAA0IKQ References: From: "ASH, GERALD R, ATTLABS" To: "NSIS Working Group" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: "ASH, GERALD R, ATTLABS" 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, Editorial changes have been made to "Y.1541-QOSM -- Y.1541 QoS Model for Networks Using Y.1541 QoS Classes" (http://www.ietf.org/internet-drafts/draft-ietf-nsis-y1541-qosm-04.txt) to conform to changes in the QSPEC draft over the last few months. Also updated the IANA Considerations section to specify required QSPEC parameter IDs and new registry. The draft should now be ready for WGLC.=20 Thanks, Jerry -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]=20 Sent: Monday, April 02, 2007 6:50 PM To: i-d-announce@ietf.org Cc: nsis@ietf.org Subject: [NSIS] I-D ACTION:draft-ietf-nsis-y1541-qosm-04.txt=20 A New Internet-Draft is available from the on-line Internet-Drafts=20 directories. This draft is a work item of the Next Steps in Signaling Working Group of the IETF. Title : Y.1541-QOSM -- Y.1541 QoS Model for Networks Using Y.1541 QoS Classes Author(s) : J. Ash, et al. Filename : draft-ietf-nsis-y1541-qosm-04.txt Pages : 11 Date : 2007-4-2 =09 This draft describes a QoS-NSLP QoS model (QOSM) based on ITU-T Recommendation Y.1541 QoS signaling requirements. Y.1541 specifies 8 standard QoS classes, and the Y.1541-QOSM extensions include additional QSPEC parameters and QOSM processing guidelines. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nsis-y1541-qosm-04.txt _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Apr 03 05:25:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYfFq-0007yC-HC; Tue, 03 Apr 2007 05:24:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYfFo-0007xi-FG for nsis@ietf.org; Tue, 03 Apr 2007 05:24:40 -0400 Received: from rsys002x.roke.co.uk ([193.118.201.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYfFk-0004eS-1I for nsis@ietf.org; Tue, 03 Apr 2007 05:24:40 -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 l339OL4c013036; Tue, 3 Apr 2007 10:24:22 +0100 Received: from [193.118.197.222] ([193.118.197.222]) by rsys005a.comm.ad.roke.co.uk with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Apr 2007 10:24:21 +0100 Message-ID: <46121D45.8010606@roke.co.uk> Date: Tue, 03 Apr 2007 10:24:21 +0100 From: Andrew McDonald User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: gash@att.com, nsis Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 Apr 2007 09:24:21.0715 (UTC) FILETIME=[DCD8AA30:01C775D1] 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: b19722fc8d3865b147c75ae2495625f2 Cc: Subject: [NSIS] Parsing QSpec with Initiator/Local QSpec 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 Jerry, I'm currently trying to work out how to correctly parse QSpec objects where there are both Local and Initiator QSpecs. My understanding is that the format is roughly: QSpec Header [1 or more QSpec objects] QSpec Header [1 or more QSpec objects] On my current understanding, I seem to be able to reach a situation where I'm processing the first set of QSpec objects, and I don't know whether the next thing I'm looking at is another QSpec object or the second QSpec header. I thought that the combination of QoS NSLP message type and QSpec Proc (Msg Seq + Obj Comb) should tell me what set of QSpec objects to expect in each case. However, there is one case where this is unclear, i.e.: Message Sequence = 1 Object Combination = 2 QoS NSLP Message = RESERVE (see section 5.3.2) I'm a little unclear, but I think the (Min QoS) is not always there. Is that a correct interpretation? If so, then at this point in processing the QSpec I can't be sure whether the next thing I expect is a Min QoS object or a second QSpec header. regards, Andrew _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Apr 03 06:02:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYfol-0001oy-1R; Tue, 03 Apr 2007 06:00:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYfoj-0001oo-T3 for nsis@ietf.org; Tue, 03 Apr 2007 06:00:45 -0400 Received: from rotterdam.ewi.utwente.nl ([130.89.10.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYfoV-0007Yg-2b for nsis@ietf.org; Tue, 03 Apr 2007 06:00:32 -0400 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by rotterdam.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id l33A0PiL006650; Tue, 3 Apr 2007 12:00:29 +0200 (MEST) From: "Georgios Karagiannis" To: References: <071568CA7B789D4AA170CEF8C9613B4F61FB99@daebe103.NOE.Nokia.com> Subject: RE: [NSIS] RMD WGLC Extension Date: Tue, 3 Apr 2007 12:00:20 +0200 Message-ID: <000701c775d6$e6c9e270$4c0d5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <071568CA7B789D4AA170CEF8C9613B4F61FB99@daebe103.NOE.Nokia.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: Acd0iX5V0EYZvza0RTeu2r31X3eCZQBTRVxw X-Spam-Score: 0.088 () AWL X-Scanned-By: MIMEDefang 2.52 on 130.89.10.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (rotterdam.ewi.utwente.nl [130.89.10.5]); Tue, 03 Apr 2007 12:00:30 +0200 (MEST) X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi John Note that we need to do some few changes that are related to the current discussion status of QSPEC template draft. Further I had a comment on retransmissions on the RMD-QOSM aware domain. We will also have to work this out! Best Regards, Georgios > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > Sent: zondag 1 april 2007 20:14 > To: nsis@ietf.org > Subject: [NSIS] RMD WGLC Extension > > I discussed this with Martin and agree that we should extend > the WGLC by one week. We need to get comments that the WG > has read the document and is comfortable with forwarding this > to the IESG. As noted during the IESG Review of GIST, the > IESG will take a very critical review of all of our WG's > documents, so we need to be sure that we have consensus behind this. > > John > > > Hi all, > > > > Noone has commented about the RMD document during the WGLC. > Does this > > > mean everyone is OK with the current document and feel it > accurately > > reflects WG concensus? Or does it mean noone has read it, and the > > interest level is low from the WG? > > > > Could people who have read the document please send a mail > saying so? > > For people who have an opinion, > > please comment. I need this information before I can send this > > forward to the IESG. > > > > John > > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Apr 03 06:05:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYfsV-0005b3-2d; Tue, 03 Apr 2007 06:04:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYfsT-0005ah-Su; Tue, 03 Apr 2007 06:04:37 -0400 Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYfsR-0000Jy-IU; Tue, 03 Apr 2007 06:04:37 -0400 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 1HYfsM-0006ZN-MK; Tue, 03 Apr 2007 12:04:32 +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 7F9502FC012; Tue, 3 Apr 2007 12:04:30 +0200 (CEST) Received: from localhost ([127.0.0.1]) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.44) id 1HYfsM-0003Dg-3K; Tue, 03 Apr 2007 12:04:30 +0200 Message-ID: <461226AD.9040707@tm.uka.de> Date: Tue, 03 Apr 2007 12:04:29 +0200 From: Roland Bless Organization: Institute of Telematics, University of Karlsruhe User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060111 Thunderbird/1.5 Mnenhy/0.7.3.0 MIME-Version: 1.0 To: "nsis@ietf.org" , nsis-imp@ietf.org X-Enigmail-Version: 0.94.1.1 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-Spam-Status: No X-Spam-Score: -1.4 (-) 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-ATIS-Checksum: v3zoCAcc32ckk X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: Subject: [NSIS] Next NSIS Interop Test Event 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, as already announced, the next NSIS Interop is taking place in Karlsruhe Germany, hosted by the Institute of Telematics, May 9th - 11th, 2007. Please find more information at the following link: https://projekte.tm.uka.de/trac/NSIS/wiki/Interop-20070509 Regards, Roland _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Apr 03 15:50: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 1HYp18-0003db-3K; Tue, 03 Apr 2007 15:50:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYp14-0003Vd-NG; Tue, 03 Apr 2007 15:50:06 -0400 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYp12-0003TI-EW; Tue, 03 Apr 2007 15:50:06 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id C3B4F32A21; Tue, 3 Apr 2007 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HYp10-0007oZ-M9; Tue, 03 Apr 2007 15:50: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, 03 Apr 2007 15:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: nsis@ietf.org Subject: [NSIS] I-D ACTION:draft-ietf-nsis-ntlp-13.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 : GIST: General Internet Signalling Transport Author(s) : H. Schulzrinne, R. Hancock Filename : draft-ietf-nsis-ntlp-13.txt Pages : 177 Date : 2007-4-3 This document specifies protocol stacks for the routing and transport of per-flow signalling messages along the path taken by that flow through the network. The design uses existing transport and security protocols under a common messaging layer, the General Internet Signalling Transport (GIST), which provides a common service for diverse signalling applications. GIST does not handle signalling application state itself, but manages its own internal state and the configuration of the underlying transport and security protocols to enable the transfer of messages in both directions along the flow path. The combination of GIST and the lower layer transport and security protocols provides a solution for the base protocol component of the "Next Steps in Signalling" framework. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nsis-ntlp-13.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-ntlp-13.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-nsis-ntlp-13.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-4-3114531.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nsis-ntlp-13.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nsis-ntlp-13.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-4-3114531.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 Apr 03 18:33: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 1HYrXv-0005Vc-CL; Tue, 03 Apr 2007 18:32:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYrXt-0005UM-Gz for nsis@ietf.org; Tue, 03 Apr 2007 18:32:09 -0400 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYrXr-0005CD-UW for nsis@ietf.org; Tue, 03 Apr 2007 18:32:09 -0400 Received: from [192.168.178.25] (mnhm-590c19ca.pool.einsundeins.de [89.12.25.202]) by kyoto.netlab.nec.de (Postfix) with ESMTP id CE46913CF81 for ; Wed, 4 Apr 2007 00:31:50 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v752.3) To: nsis Message-Id: <00C1366D-224E-480F-9FE8-835C80B8DF8A@netlab.nec.de> Content-Type: multipart/mixed; boundary=Apple-Mail-4--236189961 References: From: Martin Stiemerling Date: Wed, 4 Apr 2007 00:31:45 +0200 X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 200d029292fbb60d25b263122ced50fc Subject: [NSIS] WGLC for draft-ietf-nsis-ntlp-13.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 --Apple-Mail-4--236189961 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Dear all, We are starting an extended WGLC for GIST. The WGLC starts on April 4th and will run for *three* weeks. Everybody of the NSIS WG should review GIST once again, especially all **implementers** and **NSLP authors**. Thank you and looking forward to your reviews and comments Martin Anfang der weitergeleiteten E-Mail: > Von: > Datum: 3. April 2007 21:50:02 MESZ > An: > Kopie: > Betreff: [NSIS] I-D ACTION:draft-ietf-nsis-ntlp-13.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Next Steps in Signaling Working > Group of the IETF. > > Title : GIST: General Internet Signalling Transport > Author(s) : H. Schulzrinne, R. Hancock > Filename : draft-ietf-nsis-ntlp-13.txt > Pages : 177 > Date : 2007-4-3 > > This document specifies protocol stacks for the routing and transport > of per-flow signalling messages along the path taken by that flow > through the network. The design uses existing transport and > security > protocols under a common messaging layer, the General Internet > Signalling Transport (GIST), which provides a common service for > diverse signalling applications. GIST does not handle signalling > application state itself, but manages its own internal state and > the > configuration of the underlying transport and security protocols to > enable the transfer of messages in both directions along the flow > path. The combination of GIST and the lower layer transport and > security protocols provides a solution for the base protocol > component of the "Next Steps in Signalling" framework. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-nsis-ntlp-13.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-ntlp-13.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-nsis-ntlp-13.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. --Apple-Mail-4--236189961 Content-Transfer-Encoding: quoted-printable Content-Type: application/octet-stream; x-unix-mode=0666; name=ATT966628.TXT Content-Disposition: attachment; filename=ATT966628.TXT Content-Type:=20Message/External-body;=20access-type=3D"mail-server";=0D=0A= =09server=3D"mailserv@ietf.org"=0D=0A=0D=0AContent-Type:=20text/plain=0D=0A= Content-ID:=20<2007-4-3114531.I-D@ietf.org>=0D=0A=0D=0AENCODING=20mime=0D= =0AFILE=20/internet-drafts/draft-ietf-nsis-ntlp-13.txt=0D=0A= --Apple-Mail-4--236189961 Content-Transfer-Encoding: quoted-printable Content-Type: application/octet-stream; x-unix-mode=0666; name=draft-ietf-nsis-ntlp-13.URL Content-Disposition: attachment; filename=draft-ietf-nsis-ntlp-13.URL [InternetShortcut]=0D=0A= URL=3Dftp://ftp.ietf.org/internet-drafts/draft-ietf-nsis-ntlp-13.txt=0D=0A= --Apple-Mail-4--236189961 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; x-unix-mode=0666; name=ATT966629.txt Content-Disposition: attachment; filename=ATT966629.txt _______________________________________________=0D nsis mailing list=0D nsis@ietf.org=0D https://www1.ietf.org/mailman/listinfo/nsis=0D --Apple-Mail-4--236189961 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed stiemerling@netlab.nec.de NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 --Apple-Mail-4--236189961 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 --Apple-Mail-4--236189961-- From nsis-bounces@ietf.org Wed Apr 04 05:10: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 1HZ1Uq-0002up-9v; Wed, 04 Apr 2007 05:09:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZ1Um-0002tK-55 for nsis@ietf.org; Wed, 04 Apr 2007 05:09:36 -0400 Received: from rsys002x.roke.co.uk ([193.118.201.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZ1Uk-0002CJ-LK for nsis@ietf.org; Wed, 04 Apr 2007 05:09:36 -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 l3499KMo005415; Wed, 4 Apr 2007 10:09:20 +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] GIST Q-Mode Encapsulation Magic Number Date: Wed, 4 Apr 2007 10:09:20 +0100 Message-ID: <2181C5F19DD0254692452BFF3EAF1D6802FE4F36@rsys005a.comm.ad.roke.co.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] GIST Q-Mode Encapsulation Magic Number Thread-Index: Acdyqn9KaeZuYJVqRH+h52F5Du1pSAD7WVxQ From: "Ford, Alan" To: "Martin Stiemerling" X-MailScanner-roke-co-uk: Found to be clean X-MailScanner-roke-co-uk-SpamCheck: X-MailScanner-From: alan.ford@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi all, > > for the case where an end system receives a GIST message without > > the magic number, I am still unclear on whether to generate an > > error or silently discard. >=20 > I tend so say "send an error" message, given that the magic number =20 > MUST be present anyway. From an implementer's point-of-view, I'm not so sure. An error message includes the GIST common header, but the magic number precedes the common header. If I fail to parse the magic number, how can I give the common header in the error message? Surely a missing magic number is a mangled packet and should just be silently ignored? I think that this is particularly relevant given that the magic number is seen as part of the encapsulation, not the message. Regards, Alan _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Apr 04 12:36: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 1HZ8Sk-0004SW-Fa; Wed, 04 Apr 2007 12:35:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZ8Si-0004S9-GQ; Wed, 04 Apr 2007 12:35:56 -0400 Received: from mail.uc.pt ([193.137.200.38] helo=mail-2.ci.uc.pt) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZ8Sg-0003bO-4q; Wed, 04 Apr 2007 12:35:56 -0400 Received: from mail-2.ci.uc.pt (mail.uc.pt [127.0.0.1]) by localhost.mail.uc.pt (Postfix) with ESMTP id C052E88DE38; Wed, 4 Apr 2007 17:35:42 +0100 (WEST) Received: from [127.0.0.1] (dhcp-eucpii-185.ci.uc.pt [193.136.207.185]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail-2.ci.uc.pt (Postfix) with ESMTP id 8F30C88DE36; Wed, 4 Apr 2007 17:35:42 +0100 (WEST) Message-ID: <4613D3C8.1030708@dei.uc.pt> Date: Wed, 04 Apr 2007 17:35:20 +0100 From: =?ISO-8859-15?Q?Lu=EDs_Cordeiro?= User-Agent: Thunderbird 2.0b2 (Windows/20070116) MIME-Version: 1.0 To: Roland Bless Subject: Re: [NSIS] Next NSIS Interop Test Event References: <461226AD.9040707@tm.uka.de> In-Reply-To: <461226AD.9040707@tm.uka.de> X-Spam-Score: 1.3 (+) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: nsis-imp@ietf.org, "nsis@ietf.org" X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0018506257==" Errors-To: nsis-bounces@ietf.org --===============0018506257== Content-Type: text/html; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable Roland and all,

I would like also to agree on the QoS NSLP and NATFW versions for the interop.

Due to the time constraint I propose:
=A0=A0=A0 QoS NLSP v13
=A0=A0=A0 NATFW NSLP v13

Do you agree?

BR,
Lu=EDs Cordeiro

Roland Bless wrote: 
Hi all,

as already announced, the next NSIS Interop is taking place
in Karlsruhe Germany, hosted by the Institute of Telematics,
May 9th - 11th, 2007.

Please find more information at the following link:
https://projekte.tm.uka.de/trac/NSIS/wiki/I=
nterop-20070509

Regards,
 Roland

_______________________________________________
nsis mailing list
nsis@=
ietf.org
https://www1.ietf.org/mailman/listinfo/nsis
--===============0018506257== 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 --===============0018506257==-- From nsis-bounces@ietf.org Wed Apr 04 12: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 1HZ8c9-0006O5-L6; Wed, 04 Apr 2007 12:45:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZ8c7-0006Nz-N5 for nsis@ietf.org; Wed, 04 Apr 2007 12:45:39 -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 1HZ8c4-0008Jt-VK for nsis@ietf.org; Wed, 04 Apr 2007 12:45:39 -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 5D06C25F6EF; Wed, 4 Apr 2007 17:45:36 +0100 (WEST) Received: from [127.0.0.1] (dhcp-eucpii-185.ci.uc.pt [193.136.207.185]) (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 3CC7625F6DF; Wed, 4 Apr 2007 17:45:36 +0100 (WEST) Message-ID: <4613D619.4050404@dei.uc.pt> Date: Wed, 04 Apr 2007 17:45:13 +0100 From: =?ISO-8859-1?Q?Lu=EDs_Cordeiro?= User-Agent: Thunderbird 2.0b2 (Windows/20070116) MIME-Version: 1.0 To: "Ford, Alan" Subject: Re: [NSIS] GIST Q-Mode Encapsulation Magic Number References: <2181C5F19DD0254692452BFF3EAF1D6802FE4F36@rsys005a.comm.ad.roke.co.uk> In-Reply-To: <2181C5F19DD0254692452BFF3EAF1D6802FE4F36@rsys005a.comm.ad.roke.co.uk> X-Spam-Score: 1.3 (+) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: Martin Stiemerling , nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1959185686==" Errors-To: nsis-bounces@ietf.org --===============1959185686== Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi all,

I agree with Alan, we should assume that if the magic number is different the message received is not GIST, so no Error message should be sent.

This would benefit GIST in a scenario where messages (with the same IP RAO as GIST) flood the network. In this scenario GIST would not help the flood. But on the other hand this would require the packets to have the same IP RAO as GIST, is this usual?

BR,
Luís Cordeiro

Ford, Alan wrote: 
Hi all,

  
for the case where an end system receives a GIST message without
the magic number, I am still unclear on whether to generate an
error or silently discard.
      
I tend so say "send an error" message, given that the magic number  
MUST be present anyway.
    

 From an implementer's point-of-view, I'm not so sure. An error message
includes the GIST common header, but the magic number precedes the
common header. If I fail to parse the magic number, how can I give the
common header in the error message? Surely a missing magic number is a
mangled packet and should just be silently ignored? I think that this is
particularly relevant given that the magic number is seen as part of the
encapsulation, not the message.

Regards,
Alan

_______________________________________________
nsis mailing list
nsis@ietf.org
https://www1.ietf.org/mailman/listinfo/nsis
--===============1959185686== 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 --===============1959185686==-- From nsis-bounces@ietf.org Wed Apr 04 14:54: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 1HZAcf-0003Io-P0; Wed, 04 Apr 2007 14:54:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZAce-0003Ie-TA for nsis@ietf.org; Wed, 04 Apr 2007 14:54:20 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HZAcd-0006gs-Du for nsis@ietf.org; Wed, 04 Apr 2007 14:54:20 -0400 Received: (qmail invoked by alias); 04 Apr 2007 18:54:17 -0000 Received: from p549849C9.dip.t-dialin.net (EHLO [192.168.178.21]) [84.152.73.201] by mail.gmx.net (mp038) with SMTP; 04 Apr 2007 20:54:17 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18GaoUMzEYGqrnb4HTaxXEjQPssIqY/eT2CDmFHSj 1bizXAu7pTDQmI Message-ID: <4613F458.3030602@gmx.net> Date: Wed, 04 Apr 2007 20:54:16 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0b2 (Windows/20070116) MIME-Version: 1.0 To: =?ISO-8859-15?Q?Lu=EDs_Cordeiro?= Subject: Re: [NSIS] Next NSIS Interop Test Event References: <461226AD.9040707@tm.uka.de> <4613D3C8.1030708@dei.uc.pt> In-Reply-To: <4613D3C8.1030708@dei.uc.pt> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: Roland Bless , nsis-imp@ietf.org, "nsis@ietf.org" X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi all, I wonder whether you guys have already prepared a document with the test cases. We scheduled two interop tests in the DIME WG and used the following document for our tests: http://tools.ietf.org/wg/dime/draft-fajardo-dime-interop-test-suite-04.txt Having a document with test cases makes it easier to write the interop report. Ciao Hannes Luís Cordeiro wrote: > Roland and all, > > I would like also to agree on the QoS NSLP and NATFW versions for the interop. > > Due to the time constraint I propose: > QoS NLSP v13 > NATFW NSLP v13 > > Do you agree? > > BR, > Luís Cordeiro > > Roland Bless wrote: > > Hi all, > > > > as already announced, the next NSIS Interop is taking place > > in Karlsruhe Germany, hosted by the Institute of Telematics, > > May 9th - 11th, 2007. > > > > Please find more information at the following link: > > https://projekte.tm.uka.de/trac/NSIS/wiki/Interop-20070509 > > > > 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 > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Apr 04 15:02: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 1HZAjg-0007uC-06; Wed, 04 Apr 2007 15:01:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZAje-0007sj-Km; Wed, 04 Apr 2007 15:01:34 -0400 Received: from difra-computer.de ([81.169.157.103] helo=www.difra-computer.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZAjd-0000RJ-5a; Wed, 04 Apr 2007 15:01:34 -0400 Received: from win2003.dickmann2003.home (p548A6D14.dip.t-dialin.net [84.138.109.20]) by www.difra-computer.de (Postfix) with ESMTP id DFEEC3E4030; Wed, 4 Apr 2007 20:54:04 +0200 (CEST) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] Next NSIS Interop Test Event X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Date: Wed, 4 Apr 2007 20:47:46 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] Next NSIS Interop Test Event Thread-Index: Acd26TUxH1+WnvF0Ri+QMCOUqQZ2ZgAAW51A From: "Christian Dickmann" To: "Hannes Tschofenig" , =?iso-8859-1?Q?Lu=EDs_Cordeiro?= X-Spam-Score: 0.1 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: Roland Bless , nsis-imp@ietf.org, nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Hannes, I am working on such a document and we (including Andrew, Alan Ford, = Roland and Luis) are discussing it off-line. I will share it with the = Working Group soon (still a lot of gaps to fill). Regards, Christian > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > Sent: Wednesday, April 04, 2007 8:54 PM > To: Lu=EDs Cordeiro > Cc: Roland Bless; nsis-imp@ietf.org; nsis@ietf.org > Subject: Re: [NSIS] Next NSIS Interop Test Event >=20 > Hi all, >=20 > I wonder whether you guys have already prepared a document with the > test > cases. > We scheduled two interop tests in the DIME WG and used the following > document for our tests: > http://tools.ietf.org/wg/dime/draft-fajardo-dime-interop-test-suite- > 04.txt >=20 > Having a document with test cases makes it easier to write the interop > report. >=20 > Ciao > Hannes >=20 > Lu=EDs Cordeiro wrote: > > Roland and all, > > > > I would like also to agree on the QoS NSLP and NATFW versions for = the > interop. > > > > Due to the time constraint I propose: > > QoS NLSP v13 > > NATFW NSLP v13 > > > > Do you agree? > > > > BR, > > Lu=EDs Cordeiro > > > > Roland Bless wrote: > > > Hi all, > > > > > > as already announced, the next NSIS Interop is taking place > > > in Karlsruhe Germany, hosted by the Institute of Telematics, > > > May 9th - 11th, 2007. > > > > > > Please find more information at the following link: > > > https://projekte.tm.uka.de/trac/NSIS/wiki/Interop-20070509 > > > > > > 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 > > >=20 >=20 > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Apr 05 05:52:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZOdL-0008Uk-RX; Thu, 05 Apr 2007 05:51:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZOdK-0008Uc-Q6 for nsis@ietf.org; Thu, 05 Apr 2007 05:51:58 -0400 Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZOdH-0001sJ-Cc for nsis@ietf.org; Thu, 05 Apr 2007 05:51:58 -0400 Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5]) by iramx2.ira.uni-karlsruhe.de with esmtps id 1HZOcz-0001ou-QZ; Thu, 05 Apr 2007 11:51:39 +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 1HZOcz-0000ws-FB; Thu, 05 Apr 2007 11:51:37 +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 0EC042FC012; Thu, 5 Apr 2007 11:51:37 +0200 (CEST) Received: from localhost ([127.0.0.1]) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.44) id 1HZOcy-0001T5-Il; Thu, 05 Apr 2007 11:51:36 +0200 Message-ID: <4614C6A7.5030902@tm.uka.de> Date: Thu, 05 Apr 2007 11:51:35 +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: "Ash, Gerald R (Jerry), ALABS" Subject: Re: [NSIS] QSPEC Draft Review References: <45F15DE3.3040201@gmx.net> In-Reply-To: <45F15DE3.3040201@gmx.net> X-Enigmail-Version: 0.94.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Status: No X-Spam-Score: -1.4 (-) 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-ATIS-Checksum: v3zoCAcc32ckk X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: "nsis@ietf.org" X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Jerry, Hannes Tschofenig wrote: > * Acknowledgments and Contributors > > Dave Oran is still listed in the acknowledgments section. There are many > contributors listed even though, for most of them, I have not seen them > discussing anything on the list while some of the listed persons in the > acknowledgment list have spent a lot of time fixing the document over > several years. There might be a misbalance. I must admit that I am in > general not excited about the way how people are acknowledged in IETF > drafts in general given that they are "allowed" to fix documents of > draft authors but they get no reward. I agree with Hannes here. I'm also not listed there in v16 yet. Regards, Roland _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Apr 05 07:25:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZQ5B-0001Yq-VR; Thu, 05 Apr 2007 07:24:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZQ5A-0001X4-8h for nsis@ietf.org; Thu, 05 Apr 2007 07:24:48 -0400 Received: from mail121.messagelabs.com ([216.82.241.195]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HZQ53-0004WB-Ur for nsis@ietf.org; Thu, 05 Apr 2007 07:24:48 -0400 X-VirusChecked: Checked X-Env-Sender: gash@att.com X-Msg-Ref: server-12.tower-121.messagelabs.com!1175772281!14016167!1 X-StarScan-Version: 5.5.10.7.1; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 21796 invoked from network); 5 Apr 2007 11:24:41 -0000 Received: from unknown (HELO attrh3i.attrh.att.com) (134.24.146.4) by server-12.tower-121.messagelabs.com with SMTP; 5 Apr 2007 11:24:41 -0000 Received: from attrh.att.com (localhost [127.0.0.1]) by attrh3i.attrh.att.com (8.13.8/8.13.8) with ESMTP id l35BOeNl001760; Thu, 5 Apr 2007 07:24:40 -0400 (EDT) Received: from kcclust06evs1.ugd.att.com ([135.38.164.88]) by attrh3i.attrh.att.com (8.13.8/8.13.8) with ESMTP id l35BOaFe001747; Thu, 5 Apr 2007 07:24:36 -0400 (EDT) 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] QSPEC Draft Review Date: Thu, 5 Apr 2007 06:24:36 -0500 Message-ID: <9473683187ADC049A855ED2DA739ABCA0DDC8392@KCCLUST06EVS1.ugd.att.com> In-Reply-To: <4614C6A7.5030902@tm.uka.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] QSPEC Draft Review Thread-Index: Acd3aAbVDpl0PvkzRtiEiQvMwx6NJwACl1zg References: <45F15DE3.3040201@gmx.net> <4614C6A7.5030902@tm.uka.de> From: "ASH, GERALD R, ATTLABS" To: "Roland Bless" X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: "ASH, GERALD R, ATTLABS" , nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Roland,=20 > -----Original Message----- > From: Roland Bless [mailto:bless@tm.uka.de]=20 > Sent: Thursday, April 05, 2007 5:52 AM > To: ASH, GERALD R, ATTLABS > Cc: Hannes Tschofenig; nsis@ietf.org > Subject: Re: [NSIS] QSPEC Draft Review >=20 > Hi Jerry, >=20 > Hannes Tschofenig wrote: > > * Acknowledgments and Contributors > >=20 > > Dave Oran is still listed in the acknowledgments section.=20 > > There are many > > contributors listed even though, for most of them, I have=20 > > not seen them > > discussing anything on the list while some of the listed=20 > > persons in the > > acknowledgment list have spent a lot of time fixing the=20 > > document over > > several years. There might be a misbalance. I must admit=20 > > that I am in > > general not excited about the way how people are=20 > > acknowledged in IETF > > drafts in general given that they are "allowed" to fix documents of > > draft authors but they get no reward. > I agree with Hannes here. I'm also not listed there in v16 yet. You *certainly* should be acknowledged for your continued, substantial, and important contributions to the QSPEC draft and to NSIS in general. You will be and my sincere apologies for the oversight. I think Hannes' does have a point that perhaps there is sometimes some imbalance in 'acknowledgements', and I would add 'contributors' as well. That is, some people listed in acknowledgements (e.g., Section 9 in http://ietf.org/internet-drafts/draft-ietf-nsis-qspec-16.txt) should probably be listed as contributors (e.g., Section 1), and visa versa, depending on actual contribution. Thanks for pointing this out. Best Regards, Jerry >=20 > Regards, > Roland >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Sun Apr 08 15:06: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 1Hach6-0000vx-3S; Sun, 08 Apr 2007 15:04:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hach4-0000oh-P5; Sun, 08 Apr 2007 15:04:54 -0400 Received: from [202.99.23.227] (helo=people.com.cn) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Hach2-00010V-SA; Sun, 08 Apr 2007 15:04:54 -0400 Received: from people.com.cn([127.0.0.1]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jmc4619aded; Mon, 09 Apr 2007 03:15:36 +0800 Received: from megatron.ietf.org([127.0.0.1]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jmd246147e13; Thr, 05 Apr 2007 08:49:24 +0800 Received: from megatron.ietf.org([156.154.16.145]) by people.com.cn(AIMC 2.9.5.8) with SMTP id AISP action; Thr, 05 Apr 2007 08:49:24 +0800 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYp17-0003aZ-QZ; Tue, 03 Apr 2007 15:50:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYp14-0003Vd-NG; Tue, 03 Apr 2007 15:50:06 -0400 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYp12-0003TI-EW; Tue, 03 Apr 2007 15:50:06 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id C3B4F32A21; Tue, 3 Apr 2007 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HYp10-0007oZ-M9; Tue, 03 Apr 2007 15:50: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, 03 Apr 2007 15:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 386e0819b1192672467565a524848168 X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Archive: X-AIMC-AUTH: (null) X-AIMC-MAILFROM: i-d-announce-bounces@ietf.org X-AIMC-AUTH: (null) X-AIMC-MAILFROM: Internet-Drafts@ietf.org X-Spam-Score: 2.2 (++) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Cc: nsis@ietf.org Subject: [NSIS] I-D ACTION:draft-ietf-nsis-ntlp-13.txt X-BeenThere: nsis@ietf.org Reply-To: internet-drafts@ietf.org 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 : GIST: General Internet Signalling Transport Author(s) : H. Schulzrinne, R. Hancock Filename : draft-ietf-nsis-ntlp-13.txt Pages : 177 Date : 2007-4-3 This document specifies protocol stacks for the routing and transport of per-flow signalling messages along the path taken by that flow through the network. The design uses existing transport and security protocols under a common messaging layer, the General Internet Signalling Transport (GIST), which provides a common service for diverse signalling applications. GIST does not handle signalling application state itself, but manages its own internal state and the configuration of the underlying transport and security protocols to enable the transfer of messages in both directions along the flow path. The combination of GIST and the lower layer transport and security protocols provides a solution for the base protocol component of the "Next Steps in Signalling" framework. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nsis-ntlp-13.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-ntlp-13.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-nsis-ntlp-13.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-4-3114531.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nsis-ntlp-13.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nsis-ntlp-13.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-4-3114531.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis --NextPart-- From nsis-bounces@ietf.org Wed Apr 11 04:05: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 1HbXoi-0004gz-My; Wed, 11 Apr 2007 04:04:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbXog-0004gm-NK for nsis@ietf.org; Wed, 11 Apr 2007 04:04:34 -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 1HbXoW-0002a2-Eh for nsis@ietf.org; Wed, 11 Apr 2007 04:04:34 -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, 11 Apr 2007 11:04:17 +0300 id 000703DD.461C9681.0000393C Date: Wed, 11 Apr 2007 11:04:17 +0300 (EEST) From: Jukka MJ Manner To: "Hancock, Robert" Subject: RE: [NSIS] GIST: NSLP data in QUERY In-Reply-To: Message-ID: References: <460395CF.1010405@tm.uka.de> <460A202C.8060300@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: ded6070f7eed56e10c4f4d0d5043d9c7 Cc: Roland Bless , NSIS Working Group X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi all, Some comments below (finally). On Wed, 28 Mar 2007, Hancock, Robert wrote: > hi all, > > it's good to keep working through this, because there are several > subtleties. but i think the current design and API handles nearly > everything i have seen mentioned so far. the main points are more NSLP > (or, in fact, signalling application) design issues rather than GIST > issues. > > specifically: > > - a signalling application has to define the algorithm that it uses > when deciding whether to peer. if the algorithm is 'always true' > then there is nothing else to do. if the algorithm depends on > information > beyond the information in the MRI/SID/NSLPID then this information has > to be defined as part of the NSLP specification. Yes, it does. Yet, the problem is, how to get this "peering data (PD)" to the next NSLP hop. > > - almost by definition, this information cannot need security > protection from GIST, because that is only possible after peering. > (if security protection is needed, that would have to be done in > the NLSP itself; or else one needs something much more complex, > probably involving multiple NSLPIDs.) Yes, exactly. This PD is sent in unsecure mode, and the NSLP designer must be aware of that. > > - so far as reliability is concerned, again this is more a matter of > NSLP design. if one is probing for a peer, the response from the peer > indicates that the original message was delivered. if you get no > response within some timeout, there is no peer to respond. the NSLP > needs to make sure that it doesn't retransmit within the validity > time it provides with the message (since the GIST level can retransmit > Queries during this period). the more important thing to note is that > the NSLP payload can be delivered multiple times, so it needs to be > idempotent. Yes. > > - the API already provides the hooks to express reliability and > security requirements. so, for a probing message, you just leave these > unset. Yes. > > - and the API also allows the NSLP to be aware of the routing status: > at the querying node the fact that there is no SII means that no > routing state exists; at the responding node, the fact that this is > done with the routing state check flag set in RecvMessage means that > this decision is being made. > > - another issue is how the NSLP influences the refresh of this > conditional peering. GIST handles making sure that the routing state > as defined by the MRM is up to date, but if there is NSLP-dependent > information that should be used in the peering decision that will not > be taken care of. OTOH, the timescales over which MRM-related state > and NSLP-related state might need to be checked can be quite > independent, > so I don't think there is a need to extend the definition of normal GIST > routing state refresh to cover this. if the NSLP really does want to > check that the NSLP-dependent peering is still valid, it can always > force a refresh with the InvalidateState call. This will start a > refresh at some point in the future. > > - what is slightly messy is that the NSLP would have to do Invalidate > and then SendMessage to provide the NSLP data for the Query payload, > so there are API-internal race conditions. One could regard this as > just an implementation issue; another possibility would be to extend > Invalidate with the option to provide an NSLP payload and associated > fields (excluding transfer attributes, since they must be null). I think you misunderstood our idea. The point is that the SendMessage primitive would carry an additional PD object. This PD data is included in the QUERY and used on the next hop to make a decision whether to peer, or forward the QUERY downstream (and forget about it). Retransmission is set by the signaling initiator. The scenario is the following: [N1: Initiator, NSLP-Xa] --- [N2: NSLP_Xb] --- [N3: NSLP_Xa] We have three nodes, all running NSLP-X, but two are running version "a" of that NSLP, and one is running version "b". Now N1 wants to send a message to its next hop NSLP-Xa peer in a reliable way. What would happen: 1. N1 sends a GIST QUERY and includes a PD="a" 2. N2 receives the QUERY, has the NSLP-X running, but the PD indicates "a". 3. Since N2 is not running "a", it forwards the QUERY downstream towards N3, and forgets it never saw the message 4. N3 receives the QUERY, has the NSLP-X running and PD also indicates "a". 5. N3 thus decides that it wants to peer with N1, and sets up the reliable MA with N1 6. N2 in the middle just routes messages between the peers N1 and N3 _Without_ such a PD in the initial QUERY, N1 would need to set up an MA with N2, send the NSLP data to N2, which then needs to set a separate MA with N3 to send that data forward (since it does not run the requested NSLP-X version "a"). Any other solution, where we need some NSLP leve tricks gets really messy. We have gone through various scenarios, and the possibility to include this unsecured and idempotent peering data in a QUERY (besides the NSLP ID and MRI) is a very elegant and simple mechanism. Cheers, Jukka > > i created > http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-ntlp-issues/issue213 > to cover this specific point. > > r. > > > -----Original Message----- > > From: Jukka MJ Manner [mailto:jmanner@cs.Helsinki.FI] > > Sent: 28 March 2007 10:32 > > To: Roland Bless > > Cc: NSIS Working Group; Hancock, Robert > > Subject: Re: [NSIS] GIST: NSLP data in QUERY > > > > > > Hi, > > Yes, good point. > > > > Yet... on the other hand, if you don't get a QUERY through, > > then you won't get to set up an MA anyway, so basically the > > extra data is also sent in a reliable way. But it is not secured. > > > > Jukka > > > > On Wed, 28 Mar 2007, Roland Bless wrote: > > > > > Hi, > > > > > > Jukka MJ Manner wrote: > > > > On Fri, 23 Mar 2007, Roland Bless wrote: > > > >> Jukka MJ Manner wrote: > > > >>> I've been thinking about how GIST uses the Q-mode. If > > an NSLP asks > > > >>> for reliable or secure mode, GIST will send the query > > without NSLP payload. > > > >>> Yet, would it be possible to still allow an NSLP to include > > > >>> information carried in the query. > > > >> If the semantics for this data is different, yes. > > > > > > > > It can be different, or copies of certain NSLP objects. > > GIST doesn't > > > > need to care anyway, it's just a feature of NSLPs. > > > > > > I meant the transport semantics, e.g. reliable/unreliable > > transport of > > > this NSLP data. So the NSLP would transfer a first data chunk > > > unreliably/unsecured in the Query and after the handshake then > > > reliable... > > > So this first data chunk has different semantics within > > NSLP than the > > > other NSLP data that follow and this must be made > > explicitly visible > > > at the API. That was my point. > > > > > > Regards, > > > Roland > > > > > > > > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Apr 11 05:34: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 1HbZCi-0007qh-W3; Wed, 11 Apr 2007 05:33:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbZCh-0007qV-7a; Wed, 11 Apr 2007 05:33:27 -0400 Received: from rsys001x.roke.co.uk ([193.118.201.108]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbZCZ-00055y-P5; Wed, 11 Apr 2007 05:33:27 -0400 Received: from rsys005a.comm.ad.roke.co.uk ([193.118.193.85]) by rsys001x.roke.co.uk (8.13.1/8.13.1) with ESMTP id l3B9UL8N014020; Wed, 11 Apr 2007 10:30:21 +0100 Received: from [193.118.197.222] ([193.118.197.222]) by rsys005a.comm.ad.roke.co.uk with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Apr 2007 10:30:05 +0100 Message-ID: <461CAA9C.3050303@roke.co.uk> Date: Wed, 11 Apr 2007 10:30:04 +0100 From: Andrew McDonald User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: nsis-imp@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Apr 2007 09:30:05.0461 (UTC) FILETIME=[FD0A2450:01C77C1B] 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: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: nsis@ietf.org Subject: [NSIS] NSIS protocol dissectors for Wireshark 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, When you need a break from doing your GIST WGLC review, you might want to play with some code, so... We are pleased to announce that our NSIS protocol dissectors for Wireshark are now publicly available from: http://nsis.srmr.co.uk/nsis/wireshark.html These provide support in Wireshark for: * GIST (draft-ietf-nsis-ntlp-13.txt), with SCTP MA support (draft-ietf-nsis-ntlp-sctp-01.txt) * QoS NSLP (draft-ietf-nsis-qos-nslp-13.txt), with QSpec (draft-ietf-nsis-qspec-16.txt) * NAT/Firewall NSLP (draft-ietf-nsis-nslp-natfw-14.txt) * 'Ping' NSLP (draft-juchem-nsis-ping-tool-01.txt) The current version of these patches is 20070404. If you are running Windows, then you can simply grab the binary Wireshark installer. If you're running some other OS, then you're probably intelligent enough to build your own using the source code. Bugs and comments can be sent to me. Regards, Andrew _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Apr 11 16:49:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hbjkd-0001cC-Ve; Wed, 11 Apr 2007 16:49:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hbjkb-0001Wf-4C for nsis@ietf.org; Wed, 11 Apr 2007 16:49:09 -0400 Received: from mail120.messagelabs.com ([216.82.250.83]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HbjkX-00014M-MD for nsis@ietf.org; Wed, 11 Apr 2007 16:49:09 -0400 X-VirusChecked: Checked X-Env-Sender: gash@att.com X-Msg-Ref: server-13.tower-120.messagelabs.com!1176324543!9952443!1 X-StarScan-Version: 5.5.10.7.1; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 9504 invoked from network); 11 Apr 2007 20:49:04 -0000 Received: from unknown (HELO attrh3i.attrh.att.com) (134.24.146.4) by server-13.tower-120.messagelabs.com with SMTP; 11 Apr 2007 20:49:04 -0000 Received: from attrh.att.com (localhost [127.0.0.1]) by attrh3i.attrh.att.com (8.13.8/8.13.8) with ESMTP id l3BKn3rB025113; Wed, 11 Apr 2007 16:49:03 -0400 (EDT) Received: from kcclust06evs1.ugd.att.com ([135.38.164.88]) by attrh3i.attrh.att.com (8.13.8/8.13.8) with ESMTP id l3BKmluQ024959; Wed, 11 Apr 2007 16:48:47 -0400 (EDT) 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: Wed, 11 Apr 2007 15:48:47 -0500 Message-ID: <9473683187ADC049A855ED2DA739ABCA0DDC83B3@KCCLUST06EVS1.ugd.att.com> In-Reply-To: <9473683187ADC049A855ED2DA739ABCA0DDC8396@KCCLUST06EVS1.ugd.att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Parsing QSpec with Initiator/Local QSpec Thread-index: Acd10eYeVuLGoMdPRXWhR/DRvWJzzABt1dfwATupJ6A= References: <46121D45.8010606@roke.co.uk> <9473683187ADC049A855ED2DA739ABCA0DDC8396@KCCLUST06EVS1.ugd.att.com> From: "ASH, GERALD R, ATTLABS" To: "Andrew McDonald" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: "ASH, GERALD R, ATTLABS" , Cornelia Kappler , David R Oran , =?iso-8859-1?Q?Attila_B=E1der_=28IJ/ETH=29?= , "Kappler, Cornelia" Subject: [NSIS] RE: Parsing QSpec with Initiator/Local QSpec 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 Andrew, I've been discussing this with Cornelia, and she made a couple of good = suggestions to resolve the issue you raise. The issue you raise is a = very practical one: How does the RMF know it is parsing a new QSPEC = rather than the Minimum QoS Object. The QSPEC header field "QSPEC = Procedure" does not allow to determine the number of QSPEC objects as it = leaves open whether Minimum QoS is present or not. Therefore we propose = two solutions to the issue, and maybe we should do both for redundancy: 1. In Section 5.3.2 in = http://ietf.org/internet-drafts/draft-ietf-nsis-qspec-16.txt we add = another value "4" to the Obj Cmb field which makes unique the mapping = QSPEC Procedure -> number and type of QoS Objects, as follows: ID| QUERY | RESERVE | RESPONSE --------------------------------------------------------------------- 1 |QoS Des. | QoS Des. | QoS Res. 2 |QoS Des.,Min. QoS | QoS Des.,QoS Avl.,Min QoS | QoS Res.,QoS Avl. 3 |QoS Des. | QoS Des.,QoS Avl. | QoS Res.,QoS Avl. 4 |Qos Des.,QoS Avl. | QoS Des.,QoS Avl. | QoS Res. The descriptive words would be changed accordingly. 2. We add a field "QSPEC length" in the Reserved portion of the QSPEC = header (note we have a corresponding field for the QoS Objects), as = follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vers. |Q. Type| QSPEC Proc. |I|r| Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 'Version' and 'QSPEC Type' are reduced down to 4 bits (16 values) to = allow 14 bits for 'Length' (QSPEC Proc. and I are the same, r is = reserved). We'd like to get your reaction/suggestions and that of other = implementers regarding this proposal. Thanks, Regards, Jerry > -----Original Message----- > From: Andrew McDonald [mailto:andrew.mcdonald@roke.co.uk]=20 > Sent: Tuesday, April 03, 2007 5:24 AM > To: ASH, GERALD R, ATTLABS; nsis > Subject: Parsing QSpec with Initiator/Local QSpec >=20 > Hi Jerry, >=20 > I'm currently trying to work out how to correctly parse QSpec objects=20 > where there are both Local and Initiator QSpecs. >=20 > My understanding is that the format is roughly: > QSpec Header > [1 or more QSpec objects] > QSpec Header > [1 or more QSpec objects] >=20 > On my current understanding, I seem to be able to reach a situation=20 > where I'm processing the first set of QSpec objects, and I don't know=20 > whether the next thing I'm looking at is another QSpec object or the=20 > second QSpec header. >=20 > I thought that the combination of QoS NSLP message type and=20 > QSpec Proc=20 > (Msg Seq + Obj Comb) should tell me what set of QSpec objects=20 > to expect=20 > in each case. However, there is one case where this is unclear, i.e.: > Message Sequence =3D 1 > Object Combination =3D 2 > QoS NSLP Message =3D RESERVE > (see section 5.3.2) >=20 > I'm a little unclear, but I think the (Min QoS) is not always=20 > there. Is=20 > that a correct interpretation? >=20 > If so, then at this point in processing the QSpec I can't be sure=20 > whether the next thing I expect is a Min QoS object or a second QSpec=20 > header. >=20 > regards, > Andrew >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Apr 12 03:57: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 1HbuBQ-0005fb-5a; Thu, 12 Apr 2007 03:57:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbuBP-0005fW-2A for nsis@ietf.org; Thu, 12 Apr 2007 03:57:31 -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 1HbuBN-00066m-9A for nsis@ietf.org; Thu, 12 Apr 2007 03:57:31 -0400 Received: from scrooge-15.cs.helsinki.fi (scrooge-15.cs.helsinki.fi [128.214.48.215]) (AUTH: PLAIN cs-relay, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by mail.cs.helsinki.fi with esmtp; Thu, 12 Apr 2007 10:57:28 +0300 id 0007042F.461DE668.00001DDA Received: from localhost (localhost [127.0.0.1]) by scrooge-15.cs.helsinki.fi (Postfix) with ESMTP id ED7E31009D0 for ; Thu, 12 Apr 2007 10:57:34 +0300 (EEST) From: Lauri J T Liuhto To: nsis@ietf.org Subject: Re: [NSIS] GIST: NSLP data in QUERY Date: Thu, 12 Apr 2007 10:57:33 +0300 User-Agent: KMail/1.7.2 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200704121057.33785.lliuhto@cs.helsinki.fi> X-Spam-Score: 0.0 (/) X-Scan-Signature: 1e467ff145ef391eb7b594ef62b8301f X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi all, I think that conditional peering can not be (at least not elegantly) done without "early data". Inclusion of NSLP Data into InvalidRoutingState(..) API call (Appendix B.6, see also http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-ntlp-issues/issue213) in the gist draft version -13 did not help with conditional peering, at least not in all scenarios. I think that the modifications to GIST are not too big if we want to support NSLP data ("early data") also with queries for secure and/or reliable MAs. If NSLP is sending a query with unsecured/unreliable transfer attributes, no changes are needed. In the case of NSLP sending a query with secure and/or reliable transfer attributes, we need to modify the GIST specification a bit. We need to point out, that "early data" is _never_ secure/reliable even if NSLP requested secure/reliable transport. In other words: NSLP *should be able to* send early data if it really knows what it is doing. There are several sections needing modifications to support "early data", but I think that at least most of the modifications are quite small. My opinion is, that a new TLV object, similar to the NSLP Data Object is needed for "early data". This is to make a clear distinction between NSLP Data and "early data", because their security and reliability attributes differ. Some modifications are also needed to the NSLP API: SendMessage(..) API call needs two new parameters, for example 'Early-NSLP-Data' and 'Early-NSLP-Data-Size'. A NSLP making use of "early data" should always include it into SendMessage(..) call, because the NSLP usually can not know whether a GIST Data or Query is going to be sent. For RecvMessage(..) call we have many alternative ways to get things working, but I think that the most clear approach is similar to SendMessage(...), just add two parameters 'Early-NSLP-Data-Size' and 'Early-NSLP-Data'. Best Regards, Lauri On Wednesday 11 April 2007 11:04, Jukka MJ Manner wrote: > Hi all, > > Some comments below (finally). > > On Wed, 28 Mar 2007, Hancock, Robert wrote: > > hi all, > > > > it's good to keep working through this, because there are several > > subtleties. but i think the current design and API handles nearly > > everything i have seen mentioned so far. the main points are more > > NSLP (or, in fact, signalling application) design issues rather > > than GIST issues. > > > > specifically: > > > > - a signalling application has to define the algorithm that it uses > > when deciding whether to peer. if the algorithm is 'always true' > > then there is nothing else to do. if the algorithm depends on > > information > > beyond the information in the MRI/SID/NSLPID then this information > > has to be defined as part of the NSLP specification. > > Yes, it does. Yet, the problem is, how to get this "peering data > (PD)" to the next NSLP hop. > > > - almost by definition, this information cannot need security > > protection from GIST, because that is only possible after peering. > > (if security protection is needed, that would have to be done in > > the NLSP itself; or else one needs something much more complex, > > probably involving multiple NSLPIDs.) > > Yes, exactly. This PD is sent in unsecure mode, and the NSLP designer > must be aware of that. > > > - so far as reliability is concerned, again this is more a matter > > of NSLP design. if one is probing for a peer, the response from the > > peer indicates that the original message was delivered. if you get > > no response within some timeout, there is no peer to respond. the > > NSLP needs to make sure that it doesn't retransmit within the > > validity time it provides with the message (since the GIST level > > can retransmit Queries during this period). the more important > > thing to note is that the NSLP payload can be delivered multiple > > times, so it needs to be idempotent. > > Yes. > > > - the API already provides the hooks to express reliability and > > security requirements. so, for a probing message, you just leave > > these unset. > > Yes. > > > - and the API also allows the NSLP to be aware of the routing > > status: at the querying node the fact that there is no SII means > > that no routing state exists; at the responding node, the fact that > > this is done with the routing state check flag set in RecvMessage > > means that this decision is being made. > > > > - another issue is how the NSLP influences the refresh of this > > conditional peering. GIST handles making sure that the routing > > state as defined by the MRM is up to date, but if there is > > NSLP-dependent information that should be used in the peering > > decision that will not be taken care of. OTOH, the timescales over > > which MRM-related state and NSLP-related state might need to be > > checked can be quite independent, > > so I don't think there is a need to extend the definition of normal > > GIST routing state refresh to cover this. if the NSLP really does > > want to check that the NSLP-dependent peering is still valid, it > > can always force a refresh with the InvalidateState call. This will > > start a refresh at some point in the future. > > > > - what is slightly messy is that the NSLP would have to do > > Invalidate and then SendMessage to provide the NSLP data for the > > Query payload, so there are API-internal race conditions. One could > > regard this as just an implementation issue; another possibility > > would be to extend Invalidate with the option to provide an NSLP > > payload and associated fields (excluding transfer attributes, since > > they must be null). > > I think you misunderstood our idea. The point is that the SendMessage > primitive would carry an additional PD object. This PD data is > included in the QUERY and used on the next hop to make a decision > whether to peer, or forward the QUERY downstream (and forget about > it). Retransmission is set by the signaling initiator. > > The scenario is the following: > > [N1: Initiator, NSLP-Xa] --- [N2: NSLP_Xb] --- [N3: NSLP_Xa] > > We have three nodes, all running NSLP-X, but two are running version > "a" of that NSLP, and one is running version "b". Now N1 wants to > send a message to its next hop NSLP-Xa peer in a reliable way. What > would happen: > > 1. N1 sends a GIST QUERY and includes a PD="a" > 2. N2 receives the QUERY, has the NSLP-X running, but the PD > indicates "a". > 3. Since N2 is not running "a", it forwards the QUERY downstream > towards N3, and forgets it never saw the message > 4. N3 receives the QUERY, has the NSLP-X running and PD also > indicates "a". > 5. N3 thus decides that it wants to peer with N1, and sets up the > reliable MA with N1 > 6. N2 in the middle just routes messages between the peers N1 and N3 > > _Without_ such a PD in the initial QUERY, N1 would need to set up an > MA with N2, send the NSLP data to N2, which then needs to set a > separate MA with N3 to send that data forward (since it does not run > the requested NSLP-X version "a"). > > Any other solution, where we need some NSLP leve tricks gets really > messy. We have gone through various scenarios, and the possibility to > include this unsecured and idempotent peering data in a QUERY > (besides the NSLP ID and MRI) is a very elegant and simple mechanism. > > Cheers, > Jukka > > > i created > > http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-ntlp-issues/issue21 > >3 to cover this specific point. > > > > r. > > > > > -----Original Message----- > > > From: Jukka MJ Manner [mailto:jmanner@cs.Helsinki.FI] > > > Sent: 28 March 2007 10:32 > > > To: Roland Bless > > > Cc: NSIS Working Group; Hancock, Robert > > > Subject: Re: [NSIS] GIST: NSLP data in QUERY > > > > > > > > > Hi, > > > Yes, good point. > > > > > > Yet... on the other hand, if you don't get a QUERY through, > > > then you won't get to set up an MA anyway, so basically the > > > extra data is also sent in a reliable way. But it is not secured. > > > > > > Jukka > > > > > > On Wed, 28 Mar 2007, Roland Bless wrote: > > > > Hi, > > > > > > > > Jukka MJ Manner wrote: > > > > > On Fri, 23 Mar 2007, Roland Bless wrote: > > > > >> Jukka MJ Manner wrote: > > > > >>> I've been thinking about how GIST uses the Q-mode. If > > > > > > an NSLP asks > > > > > > > >>> for reliable or secure mode, GIST will send the query > > > > > > without NSLP payload. > > > > > > > >>> Yet, would it be possible to still allow an NSLP to include > > > > >>> information carried in the query. > > > > >> > > > > >> If the semantics for this data is different, yes. > > > > > > > > > > It can be different, or copies of certain NSLP objects. > > > > > > GIST doesn't > > > > > > > > need to care anyway, it's just a feature of NSLPs. > > > > > > > > I meant the transport semantics, e.g. reliable/unreliable > > > > > > transport of > > > > > > > this NSLP data. So the NSLP would transfer a first data chunk > > > > unreliably/unsecured in the Query and after the handshake then > > > > reliable... > > > > So this first data chunk has different semantics within > > > > > > NSLP than the > > > > > > > other NSLP data that follow and this must be made > > > > > > explicitly visible > > > > > > > at the API. That was my point. > > > > > > > > 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 Thu Apr 12 04:56:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hbv6A-0004Ny-4Q; Thu, 12 Apr 2007 04:56:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hbv68-0004Iu-R3 for nsis@ietf.org; Thu, 12 Apr 2007 04:56:08 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hbv66-0003BG-SV for nsis@ietf.org; Thu, 12 Apr 2007 04:56:08 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 3F07820582; Thu, 12 Apr 2007 10:56:04 +0200 (CEST) X-AuditID: c1b4fb3e-ae9ecbb0000061ca-c2-461df4243a63 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 219F72006E; Thu, 12 Apr 2007 10:56:04 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Apr 2007 10:56:01 +0200 Received: from [147.214.30.247] ([147.214.30.247]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Apr 2007 10:55:41 +0200 Message-ID: <461DF40D.30403@ericsson.com> Date: Thu, 12 Apr 2007 10:55:41 +0200 From: Magnus Westerlund User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Martin Stiemerling Subject: Re: [NSIS] WGLC for draft-ietf-nsis-ntlp-13.txt References: <00C1366D-224E-480F-9FE8-835C80B8DF8A@netlab.nec.de> In-Reply-To: <00C1366D-224E-480F-9FE8-835C80B8DF8A@netlab.nec.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Apr 2007 08:55:41.0559 (UTC) FILETIME=[59457070:01C77CE0] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 3fbd9b434023f8abfcb1532abaec7a21 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 would like to raise a warning from my side regarding this WG last call. Unless I actually see a number of persons stating that they have read the document in this version I will refuse to process into a second AD review. There need to be clear consensus from the WG that this is what you want and that it doesn't contain any serious errors. Please remember that unless you actually get GIST published all your work on NSLPs will be for nothing. And unless you actually help ensure that the document really is ready this time for publication the whole WG effort can be terminated. I need to convince a number of ADs that you actually taken serious looking on the problems raised and are agreeing on how to resolve them. Magnus Westerlund Your AD Martin Stiemerling skrev: > Dear all, > > We are starting an extended WGLC for GIST. The WGLC starts on April 4th > and will run for *three* weeks. > > Everybody of the NSIS WG should review GIST once again, especially all > **implementers** and **NSLP authors**. > > Thank you and looking forward to your reviews and comments > > Martin > > Anfang der weitergeleiteten E-Mail: > >> Von: >> Datum: 3. April 2007 21:50:02 MESZ >> An: >> Kopie: >> Betreff: [NSIS] I-D ACTION:draft-ietf-nsis-ntlp-13.txt >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Next Steps in Signaling Working Group >> of the IETF. >> >> Title : GIST: General Internet Signalling Transport >> Author(s) : H. Schulzrinne, R. Hancock >> Filename : draft-ietf-nsis-ntlp-13.txt >> Pages : 177 >> Date : 2007-4-3 >> >> This document specifies protocol stacks for the routing and transport >> of per-flow signalling messages along the path taken by that flow >> through the network. The design uses existing transport and security >> protocols under a common messaging layer, the General Internet >> Signalling Transport (GIST), which provides a common service for >> diverse signalling applications. GIST does not handle signalling >> application state itself, but manages its own internal state and the >> configuration of the underlying transport and security protocols to >> enable the transfer of messages in both directions along the flow >> path. The combination of GIST and the lower layer transport and >> security protocols provides a solution for the base protocol >> component of the "Next Steps in Signalling" framework. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-nsis-ntlp-13.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-ntlp-13.txt". >> >> A list of Internet-Drafts directories can be found in >> http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> >> Internet-Drafts can also be obtained by e-mail. >> >> Send a message to: >> mailserv@ietf.org. >> In the body type: >> "FILE /internet-drafts/draft-ietf-nsis-ntlp-13.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. > > ------------------------------------------------------------------------ > > FILE DELETED > ------------ > > Warning! > > The attached file draft-ietf-nsis-ntlp-13.URL has not been delivered. > The reason is due to that the filter FILE FILTER= unnamed: *.url is in effect. > > > Ericsson Group IT > > > ------------------------------------------------------------------------ > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > > > > ------------------------------------------------------------------------ > > > > > stiemerling@netlab.nec.de > 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 -- Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM/M ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Apr 12 05:00:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbvAJ-0006Ua-05; Thu, 12 Apr 2007 05:00:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbvAI-0006UV-2a for nsis@ietf.org; Thu, 12 Apr 2007 05:00:26 -0400 Received: from rsys002x.roke.co.uk ([193.118.201.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbvAE-0003vc-Je for nsis@ietf.org; Thu, 12 Apr 2007 05:00:26 -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 l3C905Ba011872; Thu, 12 Apr 2007 10:00:05 +0100 Received: from [193.118.197.222] ([193.118.197.222]) by rsys005a.comm.ad.roke.co.uk with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Apr 2007 10:00:05 +0100 Message-ID: <461DF515.6060107@roke.co.uk> Date: Thu, 12 Apr 2007 10:00:05 +0100 From: Andrew McDonald User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: "ASH, GERALD R, ATTLABS" References: <46121D45.8010606@roke.co.uk> <9473683187ADC049A855ED2DA739ABCA0DDC8396@KCCLUST06EVS1.ugd.att.com> <9473683187ADC049A855ED2DA739ABCA0DDC83B3@KCCLUST06EVS1.ugd.att.com> In-Reply-To: <9473683187ADC049A855ED2DA739ABCA0DDC83B3@KCCLUST06EVS1.ugd.att.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Apr 2007 09:00:05.0013 (UTC) FILETIME=[F64D5450:01C77CE0] 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: 0a7aa2e6e558383d84476dc338324fab Cc: nsis@ietf.org, Cornelia Kappler , =?ISO-8859-1?Q?=22Attila_B=E1der_=28I?=, David R Oran , =?ISO-8859-1?Q?J/ETH=29=22?= , "Kappler, Cornelia" Subject: [NSIS] Re: Parsing QSpec with Initiator/Local QSpec 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 Jerry, ASH, GERALD R, ATTLABS wrote: > I've been discussing this with Cornelia, and she made a couple of > good suggestions to resolve the issue you raise. The issue you raise > is a very practical one: How does the RMF know it is parsing a new > QSPEC rather than the Minimum QoS Object. The QSPEC header field > "QSPEC Procedure" does not allow to determine the number of QSPEC > objects as it leaves open whether Minimum QoS is present or not. > Therefore we propose two solutions to the issue, and maybe we should > do both for redundancy: > > 1. In Section 5.3.2 in > http://ietf.org/internet-drafts/draft-ietf-nsis-qspec-16.txt we add > another value "4" to the Obj Cmb field which makes unique the mapping > QSPEC Procedure -> number and type of QoS Objects, as follows: > ID| QUERY | RESERVE | RESPONSE > --------------------------------------------------------------------- > 1 |QoS Des. | QoS Des. | QoS Res. > 2 |QoS Des.,Min. QoS | QoS Des.,QoS Avl.,Min QoS | QoS Res.,QoS Avl. > 3 |QoS Des. | QoS Des.,QoS Avl. | QoS Res.,QoS Avl. > 4 |Qos Des.,QoS Avl. | QoS Des.,QoS Avl. | QoS Res. > > The descriptive words would be changed accordingly. This looks like a sensible idea. > 2. We add a field "QSPEC length" in the Reserved portion of the QSPEC > header (note we have a corresponding field for the QoS Objects), as > follows: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Vers. |Q. Type| QSPEC Proc. |I|r| Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > 'Version' and 'QSPEC Type' are reduced down to 4 bits (16 values) to > allow 14 bits for 'Length' (QSPEC Proc. and I are the same, r is > reserved). From a packet parsing perspective having some sort of length field is a useful. If only (1) was implemented, then you need to look at the message type, obj cmb and have a look-up table to know how many objects to expect. This may have extensibility issues (i.e. you can't parse the packet if the message-type/obj-cmb pair is not in your look-up table). I'd suggest going with both (1) and (2). A possible variation of (2) would be to put the number of QSpec Objects instead of the length. This would allow you to have a shorter 'length' field. However, I think the proposal you give fits better with the packet structures in other parts of the protocol (GIST, QoS NSLP, QSpec headers and object headers) where 14-bit length fields are used. regards, Andrew _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Apr 12 10:54: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 1Hc0gT-0004Og-25; Thu, 12 Apr 2007 10:54:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hc0gR-0004MK-Kc for nsis@ietf.org; Thu, 12 Apr 2007 10:53:59 -0400 Received: from rsys001x.roke.co.uk ([193.118.201.108]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hc0gJ-0005ly-Tr for nsis@ietf.org; Thu, 12 Apr 2007 10:53:59 -0400 Received: from rsys005a.comm.ad.roke.co.uk ([193.118.193.85]) by rsys001x.roke.co.uk (8.13.1/8.13.1) with ESMTP id l3CEolRP016511; Thu, 12 Apr 2007 15:50:48 +0100 Received: from [193.118.197.222] ([193.118.197.222]) by rsys005a.comm.ad.roke.co.uk with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Apr 2007 15:50:47 +0100 Message-ID: <461E4747.5040003@roke.co.uk> Date: Thu, 12 Apr 2007 15:50:47 +0100 From: Andrew McDonald User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: "ASH, GERALD R, ATTLABS" Subject: Re: [NSIS] Re: Parsing QSpec with Initiator/Local QSpec References: <46121D45.8010606@roke.co.uk> <9473683187ADC049A855ED2DA739ABCA0DDC8396@KCCLUST06EVS1.ugd.att.com> <9473683187ADC049A855ED2DA739ABCA0DDC83B3@KCCLUST06EVS1.ugd.att.com> <461DF515.6060107@roke.co.uk> In-Reply-To: <461DF515.6060107@roke.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Apr 2007 14:50:47.0826 (UTC) FILETIME=[F4CBC720:01C77D11] 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: 0ddefe323dd869ab027dbfff7eff0465 Cc: Cornelia Kappler , oran@cisco.com, attila.bader@ericsson.com, nsis@ietf.org, "Kappler, Cornelia" 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 Jerry (again), A further comment below: Andrew McDonald wrote: > ASH, GERALD R, ATTLABS wrote: >> 2. We add a field "QSPEC length" in the Reserved portion of the QSPEC >> header (note we have a corresponding field for the QoS Objects), as >> follows: >> >> 0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Vers. |Q. Type| QSPEC Proc. |I|r| Length | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> 'Version' and 'QSPEC Type' are reduced down to 4 bits (16 values) to >> allow 14 bits for 'Length' (QSPEC Proc. and I are the same, r is >> reserved). > > From a packet parsing perspective having some sort of length field is a > useful. If only (1) was implemented, then you need to look at the > message type, obj cmb and have a look-up table to know how many objects > to expect. This may have extensibility issues (i.e. you can't parse the > packet if the message-type/obj-cmb pair is not in your look-up table). > > I'd suggest going with both (1) and (2). > > A possible variation of (2) would be to put the number of QSpec Objects > instead of the length. This would allow you to have a shorter 'length' > field. However, I think the proposal you give fits better with the > packet structures in other parts of the protocol (GIST, QoS NSLP, QSpec > headers and object headers) where 14-bit length fields are used. Having just been looking at the QoS NSLP and GIST drafts again, I realise that I was slightly mistaken. They actually use 12-bit length fields in the object headers, not 14-bits. I'd suggest reducing the Length similarly to 12 bits here, since the maximum length must be less than the maximum length of the QoS NSLP QSPEC object. i.e. I'd make the header: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vers. |Q. Type| QSPEC Proc. |I|r|r|r| Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ regards, Andrew _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Apr 18 05:21: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 1He6MA-0001P3-Uc; Wed, 18 Apr 2007 05:21:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1He6M9-0001Op-Mx for nsis@ietf.org; Wed, 18 Apr 2007 05:21:41 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1He6M8-0000ED-DO for nsis@ietf.org; Wed, 18 Apr 2007 05:21:41 -0400 Received: (qmail invoked by alias); 18 Apr 2007 09:21:39 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp037) with SMTP; 18 Apr 2007 11:21:39 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+yvogWnnOyelzmWos5ko7+ApaaG6rfrk3yiwk2No cvs18Qc23oipPA Message-ID: <4625E322.7000005@gmx.net> Date: Wed, 18 Apr 2007 11:21:38 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: "nsis@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.5 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Subject: [NSIS] NSIS Meeting Minutes X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi all, please take a look at the meeting minutes: http://www3.ietf.org/proceedings/07mar/minutes/nsis.txt Ciao Hannes _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Apr 18 05:37: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 1He6bL-00028y-4b; Wed, 18 Apr 2007 05:37:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1He6bJ-00026E-ME for nsis@ietf.org; Wed, 18 Apr 2007 05:37:21 -0400 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1He6bJ-0003yG-39 for nsis@ietf.org; Wed, 18 Apr 2007 05:37:21 -0400 Received: from [127.0.0.1] (kobe.netlab.nec.de [195.37.70.60]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 7489613CF81 for ; Wed, 18 Apr 2007 11:37:20 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <00C1366D-224E-480F-9FE8-835C80B8DF8A@netlab.nec.de> References: <00C1366D-224E-480F-9FE8-835C80B8DF8A@netlab.nec.de> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <987892BF-91A6-4FBE-90DF-0DA38BB4B312@netlab.nec.de> Content-Transfer-Encoding: 7bit From: Martin Stiemerling Date: Wed, 18 Apr 2007 11:37:22 +0200 To: nsis X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab Subject: [NSIS] Reminder: WGLC for draft-ietf-nsis-ntlp-13.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 Dear all, This is a friendly reminder for the currently running WGLC for GIST. Apparently, there have not been much reviews and/or comments on GIST. I interpret this as *nobody* has read the document. Consider also Magnus' email response to the original WGLC! In any case, I would like to encourage all WG memmbers and especially *all* implementers and NSLP authors to review GIST and to send their comments to the list. It is even good to send something along the lines "yes, I have read the document and it is fine with me." Thanks and looking forward to your reviews, Martin Am 04.04.2007 um 00:31 schrieb Martin Stiemerling: > Dear all, > > We are starting an extended WGLC for GIST. The WGLC starts on April > 4th and will run for *three* weeks. > > Everybody of the NSIS WG should review GIST once again, especially > all **implementers** and **NSLP authors**. > > Thank you and looking forward to your reviews and comments > > Martin > > Anfang der weitergeleiteten E-Mail: > >> Von: >> Datum: 3. April 2007 21:50:02 MESZ >> An: >> Kopie: >> Betreff: [NSIS] I-D ACTION:draft-ietf-nsis-ntlp-13.txt >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Next Steps in Signaling Working >> Group of the IETF. >> >> Title : GIST: General Internet Signalling Transport >> Author(s) : H. Schulzrinne, R. Hancock >> Filename : draft-ietf-nsis-ntlp-13.txt >> Pages : 177 >> Date : 2007-4-3 >> >> This document specifies protocol stacks for the routing and transport >> of per-flow signalling messages along the path taken by that flow >> through the network. The design uses existing transport and >> security >> protocols under a common messaging layer, the General Internet >> Signalling Transport (GIST), which provides a common service for >> diverse signalling applications. GIST does not handle signalling >> application state itself, but manages its own internal state >> and the >> configuration of the underlying transport and security >> protocols to >> enable the transfer of messages in both directions along the flow >> path. The combination of GIST and the lower layer transport and >> security protocols provides a solution for the base protocol >> component of the "Next Steps in Signalling" framework. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-nsis-ntlp-13.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-ntlp-13.txt". >> >> A list of Internet-Drafts directories can be found in >> http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> >> Internet-Drafts can also be obtained by e-mail. >> >> Send a message to: >> mailserv@ietf.org. >> In the body type: >> "FILE /internet-drafts/draft-ietf-nsis-ntlp-13.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. >> >> >> > > > > stiemerling@netlab.nec.de > 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 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 Apr 19 07:35:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeUvZ-0008DH-J9; Thu, 19 Apr 2007 07:35:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeUvZ-0008D3-39 for nsis@ietf.org; Thu, 19 Apr 2007 07:35:53 -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 1HeUvW-0000dI-Ul for nsis@ietf.org; Thu, 19 Apr 2007 07:35:52 -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, 19 Apr 2007 14:35:50 +0300 id 0007BD97.46275416.00004EE1 Date: Thu, 19 Apr 2007 14:35:49 +0300 (EEST) From: Jukka MJ Manner To: nsis Subject: Re: [NSIS] WGLC for draft-ietf-nsis-ntlp-13.txt In-Reply-To: <00C1366D-224E-480F-9FE8-835C80B8DF8A@netlab.nec.de> Message-ID: References: <00C1366D-224E-480F-9FE8-835C80B8DF8A@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: f66b12316365a3fe519e75911daf28a8 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, I have reviewed the GIST spec and have no major concerns. A couple of small nits and editorial things are mentioned below. Yet, in a separate email I have suggested the addition of "Peering data" that could be used by NSLPs to give more details for the peering decision when receiving a QUERY. This is an important function I would like to be enabled. I can provide e.g. text for a small subsection that identifies the issue, shows the solution and discusses its implications on the NSLP layer. The nits: - It is sometimes difficult to follow, what is meant by "flow" in the document. Mostly it seems to be used for data flows, but sometimes it seems it is used in signaling flows, or left otherwise unspecified. A couple examples: p.20 6.A "for that flow" (what flow?), p.22 "Section 4.2 describes the per-flow and" (what flow?). SUGGESTION: add "data" in front of "flow" where the text really talks about the data flow being signaled for. - p.7: Would the use of DTLS be counted as "C-mode" or "D-mode"? - p.15: s/which are nothing/which have nothing/ - Section 3.10: A figure would help understand the example - p.28: s/match, the GIST/match, GIST/ - p.28, S4.3.1, last paragraph: A node receives a packet with a hop count of zero, but I think this would be a special error case. Why would the previous GIST hop send a message out with a hop count of zero, since it knows the message will be discarded by the recipient? - p.30 "GIST MUST verify that it is not the direct destination of an outgoing message...": don't get the meaning of this sentence. A node is sending a packet to itself, internally? - p.38: s/a abstract/an abstract/ - p.42, S4.4.4: You could make the timer description clearer, e.g., separate it from the main body of the paragraph, e.g., a formulae, and could also add some examples. - p.47, Section 5 could have a short introduction - p.47: why MUST the objects be carried in the proposed order? It would put this as a SHOULD. At least the QoS NSLP says "SHOULD" for this. - p.47: s/the MRI SID/the MRI, SiD/ - p.48, middle of page: The Confirm echos something, yet, the information is something the querying node included in the first place. Can this information change as it comes back from the responding node? I would rephrase this to "The Confirm MUST include the MRI and SID, and echo the Responder-Cookie if the Response carried one." - p.54: I would make the magic number clearly visible, and even mention earlier in the document. Now one has to be very careful to find the value of the magic number. - p.55: "If the MRM defines the use of RAO, the sender MUST include it by default." This latter "by default" sounds wierd. Is it needed at all, isn't "MUST include it." enough? - p.55: "Note that all MRMs require S=1 for at least some retransmissions, so ICMP errors related to fragmentation will be seen at the Querying node". Could you elaborate a bit on this? Didn't quite get it. - p.56: "within the networ which" - p.60: "except that that the" - p.63, S.5.7.1: The discussion about the stack proposal object would need an example, a figure, to illustrate how the object is composed. - p.63: What is "SCD" the acronym? Stack-Configuration-Data? First time it is used in the text body. - S.5.7 in general: should there be a section about using UDP as the MA transport protocol? This is not really presented anywhere. - p.85: s/to a change the opposite/to a change in the opposite/ Jukka _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Apr 19 10:47: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 1HeXv8-00038t-0k; Thu, 19 Apr 2007 10:47:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeXv7-00034r-9d for nsis@ietf.org; Thu, 19 Apr 2007 10:47:37 -0400 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeXv5-0006Mb-Qy for nsis@ietf.org; Thu, 19 Apr 2007 10:47:37 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l3JElD4x000853; Thu, 19 Apr 2007 17:47:33 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Apr 2007 17:47:22 +0300 Received: from mgw-int01.ntc.nokia.com ([172.21.143.96]) by esebh103.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Apr 2007 17:47:22 +0300 Received: from [172.21.35.232] (esdhcp035232.research.nokia.com [172.21.35.232]) by mgw-int01.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l3JElKaZ028140; Thu, 19 Apr 2007 17:47:21 +0300 In-Reply-To: References: <00C1366D-224E-480F-9FE8-835C80B8DF8A@netlab.nec.de> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Lars Eggert Subject: Re: [NSIS] WGLC for draft-ietf-nsis-ntlp-13.txt Date: Thu, 19 Apr 2007 17:47:05 +0300 To: ext Jukka MJ Manner X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 19 Apr 2007 14:47:22.0658 (UTC) FILETIME=[A365E020:01C78291] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a 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 On 2007-4-19, at 14:35, ext Jukka MJ Manner wrote: > Yet, in a separate email I have suggested the addition of "Peering > data" > that could be used by NSLPs to give more details for the peering > decision > when receiving a QUERY. This is an important function I would like > to be > enabled. I can provide e.g. text for a small subsection that > identifies > the issue, shows the solution and discusses its implications on the > NSLP > layer. One of the points that came up during the IESG evaluation was that GIST was already very complex, and other ADs were questioning whether all the features were really needed or if it could even be understood and implemented. I think Magnus and me got the point across that a generic signaling framework comes with a certain level of complexity, but if the next revision that hits the IESG adds more features - esp. ones that apparently aren't required for any existing NSLP - that probably would send a very wrong message. The WG needs to really think carefully about this. Lars _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Apr 19 11:32: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 1HeYcH-0006TS-Dx; Thu, 19 Apr 2007 11:32:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeYcG-0006TJ-31 for nsis@ietf.org; Thu, 19 Apr 2007 11:32:12 -0400 Received: from rsys001x.roke.co.uk ([193.118.201.108]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeYcB-0001IL-Ke for nsis@ietf.org; Thu, 19 Apr 2007 11:32:12 -0400 Received: from rsys005a.comm.ad.roke.co.uk ([193.118.193.85]) by rsys001x.roke.co.uk (8.13.1/8.13.1) with ESMTP id l3JFW32v015668; Thu, 19 Apr 2007 16:32:03 +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: (un)necessary features (was: RE: [NSIS] WGLC for draft-ietf-nsis-ntlp-13.txt) Date: Thu, 19 Apr 2007 16:32:03 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: (un)necessary features (was: RE: [NSIS] WGLC for draft-ietf-nsis-ntlp-13.txt) Thread-Index: AceCkcGBz2SteQtdTpmi+MxA9W54rQAA+iEA References: <00C1366D-224E-480F-9FE8-835C80B8DF8A@netlab.nec.de> From: "Hancock, Robert" To: "Lars Eggert" , "ext Jukka MJ Manner" 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: 6cca30437e2d04f45110f2ff8dc1b1d5 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, > -----Original Message----- > From: Lars Eggert [mailto:lars.eggert@nokia.com]=20 > Sent: 19 April 2007 15:47 > To: ext Jukka MJ Manner > Cc: nsis > Subject: Re: [NSIS] WGLC for draft-ietf-nsis-ntlp-13.txt >=20 > On 2007-4-19, at 14:35, ext Jukka MJ Manner wrote: > > Yet, in a separate email I have suggested the addition of "Peering=20 > > data" > > that could be used by NSLPs to give more details for the peering=20 > > decision when receiving a QUERY. This is an important=20 > function I would=20 > > like to be enabled. I can provide e.g. text for a small subsection=20 > > that identifies the issue, shows the solution and discusses its=20 > > implications on the NSLP layer. >=20 > One of the points that came up during the IESG evaluation was=20 > that GIST was already very complex, and other ADs were=20 > questioning whether all the features were really needed or if=20 > it could even be understood and implemented. >=20 > I think Magnus and me got the point across that a generic=20 > signaling framework comes with a certain level of complexity,=20 > but if the next revision that hits the IESG adds more=20 > features - esp. ones that apparently aren't required for any=20 > existing NSLP - that probably would send a very wrong message. >=20 > The WG needs to really think carefully about this. there are a couple of points here. 1. for this particular case of early peering data, I believe that the functionality necessary is already in the spec (has been since version 7) and is used by the QoS-NSLP among others. I don't believe anything extra is needed but I'll explain why in a separate mail. 2. as a more general point, if people spot functionality or text that they feel is unecessary (for whatever reason) then that would be fine to highlight during the WGLC process. The list of things that have been added recently can be found in the change history (E.1 and E.2), and it would be good to focus here particularly if the additions seem worthwhile. some highlights: - the authorisation model (mainly 4.4.2) and TLS name checking rules (5.7.3.1) - recommendations on evolvability of D-mode (3.2) - details on IP option handling (5.3.2) - guidance on overload protection (mainly 8.4) - multipath handling (7.1.4) in particular, for the last two it would be good to know if people find the text helpful or not (since it is mainly=20 informative). Related to the multipath handling discussion is the question of whether GIST should have an explicit routing state removal functionality, which strikes me as a case of premature optimisation compared to what is already possible in the protocol, but which some people have asked for in general terms in the past. At the moment I am unaware of any outstanding specific 'feature=20 XXX could be removed' suggestions (there have only ever been=20 very few) but that does not mean that some could not be made. r. >=20 > Lars >=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 Thu Apr 19 11:53:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeYx9-00047J-Ue; Thu, 19 Apr 2007 11:53:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeYx8-00046v-G3 for nsis@ietf.org; Thu, 19 Apr 2007 11:53:46 -0400 Received: from rsys002x.roke.co.uk ([193.118.201.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeYx6-0007qj-Rg for nsis@ietf.org; Thu, 19 Apr 2007 11:53:46 -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 l3JFrXCS025629; Thu, 19 Apr 2007 16:53:34 +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] GIST: NSLP data in QUERY Date: Thu, 19 Apr 2007 16:53:34 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] GIST: NSLP data in QUERY Thread-Index: Acd8XL6h7Jly0TUeQI+sodGzEAG56wGO2rxg References: <460395CF.1010405@tm.uka.de> <460A202C.8060300@tm.uka.de> From: "Hancock, Robert" To: "Jukka MJ Manner" 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: 97c820c82c68af374c4e382a80dc5017 Cc: NSIS Working Group 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 Jukka, Lauri, [replying to Jukka's mail since that has the example that I need to react to, but hopefully covering both your points]: [snipping stuff we all agree on] > >=20 > > - another issue is how the NSLP influences the refresh of this=20 > > conditional peering. GIST handles making sure that the=20 > routing state=20 > > as defined by the MRM is up to date, but if there is NSLP-dependent=20 > > information that should be used in the peering decision=20 > that will not=20 > > be taken care of. OTOH, the timescales over which MRM-related state=20 > > and NSLP-related state might need to be checked can be quite=20 > > independent, so I don't think there is a need to extend the=20 > definition=20 > > of normal GIST routing state refresh to cover this. if the=20 > NSLP really=20 > > does want to check that the NSLP-dependent peering is still=20 > valid, it=20 > > can always force a refresh with the InvalidateState call. This will=20 > > start a refresh at some point in the future. > >=20 > > - what is slightly messy is that the NSLP would have to do=20 > Invalidate=20 > > and then SendMessage to provide the NSLP data for the Query=20 > payload,=20 > > so there are API-internal race conditions. One could regard this as=20 > > just an implementation issue; another possibility would be=20 > to extend=20 > > Invalidate with the option to provide an NSLP payload and=20 > associated=20 > > fields (excluding transfer attributes, since they must be null). >=20 > I think you misunderstood our idea. The point is that the=20 > SendMessage primitive would carry an additional PD object.=20 > This PD data is included in the QUERY and used on the next=20 > hop to make a decision whether to peer, or forward the QUERY=20 > downstream (and forget about it). Retransmission is set by=20 > the signaling initiator. i don't believe there is a need for an additional object type or API extension for this. the NSLP knows whether routing state exists or not. If it does, the peering has already taken place and it is too late to change it's mind. If it does not, then the NSLP knows that any data it provides without reliability/ security transfer attributes can be used in the conditional=20 peering decision. (There are two cases: when there has never been any routing state, and when the NSLP has just invalidated it.) >=20 > The scenario is the following: >=20 > [N1: Initiator, NSLP-Xa] --- [N2: NSLP_Xb] --- [N3: NSLP_Xa]=20 >=20 > We have three nodes, all running NSLP-X, but two are running=20 > version "a"=20 > of that NSLP, and one is running version "b". Now N1 wants to=20 > send a message to its next hop NSLP-Xa peer in a reliable=20 > way. What would happen: >=20 > 1. N1 sends a GIST QUERY and includes a PD=3D"a" > 2. N2 receives the QUERY, has the NSLP-X running, but the PD=20 > indicates=20 > "a". > 3. Since N2 is not running "a", it forwards the QUERY=20 > downstream towards=20 > N3, and forgets it never saw the message 4. N3 receives=20 > the QUERY, has the NSLP-X running and PD also indicates=20 > "a". > 5. N3 thus decides that it wants to peer with N1, and sets up=20 > the reliable=20 > MA with N1 > 6. N2 in the middle just routes messages between the peers N1 and N3 >=20 > _Without_ such a PD in the initial QUERY, N1 would need to=20 > set up an MA with N2, send the NSLP data to N2, which then=20 > needs to set a separate MA with N3 to send that data forward=20 > (since it does not run the requested NSLP-X version "a"). The problem with this example is that it is unclear exactly how many signalling applications and peering relationships there really are in existence. If we follow the example through, it would seem that sometimes N1 is talking to N2 and sometimes to=20 N3, depending on the data transfer characteristics involved.=20 But that is bad news: does N1 now have two downstream peers for the same signalling application? or is it swapping between the two (like a route change)? The way I see it is that either N1 is peered with N2 or with N3. If N1 wants to bypass N2 then it should peer directly with N3,=20 and it can do this by including the PD as normal (unsecured,=20 unreliable) data in messages it sends when there is no routing state. That is, the existing spec already allows this behaviour: for the sending NSLP as just noted, and for the receiving NSLP because there is the Routing-State-Check boolean in the RecvMessage API call and the bypass processing described in 4.3.2. Note that just adding additional PD objects to the RecvMessage API call is *not* sufficient: GIST *has* to enforce the correctness of the cookie/MRI/TTL/GHC processing, and so conditional forwarding *cannot* be modelled simply as a RecvMessage to the NSLP followed by a SendMesssage to propagate the data. If N1 wants to talk to N2 sometimes and N3 other times, then there are two choices: - define a proxy mode for the NSLP (so N2 can forward data transparently) - split X into two separate NSLPs with different NSLPIDs, and peer for each one separately. Note finally that if we later come across other conditional peering cases where the conditionality does not fit nicely with an NSLP-level request/reply exchange (which is the implicit assumption so far), then the existing GIST extensibility mechansisms can already handle it within the current protocol design (specifically, I would define a new MRM which included the input to the conditional peering=20 decision in the MRI). hope this makes sense, robert h. >=20 > Any other solution, where we need some NSLP leve tricks gets=20 > really messy.=20 > We have gone through various scenarios, and the possibility=20 > to include this unsecured and idempotent peering data in a=20 > QUERY (besides the NSLP ID and MRI) is a very elegant and=20 > simple mechanism. >=20 > Cheers, > Jukka >=20 > >=20 > > i created > > http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-ntlp-issues/issue213 > > to cover this specific point. > >=20 > > r. > >=20 > > > -----Original Message----- > > > From: Jukka MJ Manner [mailto:jmanner@cs.Helsinki.FI] > > > Sent: 28 March 2007 10:32 > > > To: Roland Bless > > > Cc: NSIS Working Group; Hancock, Robert > > > Subject: Re: [NSIS] GIST: NSLP data in QUERY > > >=20 > > >=20 > > > Hi, > > > Yes, good point. > > >=20 > > > Yet... on the other hand, if you don't get a QUERY=20 > through, then you=20 > > > won't get to set up an MA anyway, so basically the extra data is=20 > > > also sent in a reliable way. But it is not secured. > > >=20 > > > Jukka > > >=20 > > > On Wed, 28 Mar 2007, Roland Bless wrote: > > >=20 > > > > Hi, > > > >=20 > > > > Jukka MJ Manner wrote: > > > > > On Fri, 23 Mar 2007, Roland Bless wrote: > > > > >> Jukka MJ Manner wrote: > > > > >>> I've been thinking about how GIST uses the Q-mode. If > > > an NSLP asks > > > > >>> for reliable or secure mode, GIST will send the query > > > without NSLP payload. > > > > >>> Yet, would it be possible to still allow an NSLP to include=20 > > > > >>> information carried in the query. > > > > >> If the semantics for this data is different, yes. > > > > >=20 > > > > > It can be different, or copies of certain NSLP objects.=20 > > > GIST doesn't > > > > > need to care anyway, it's just a feature of NSLPs. > > > >=20 > > > > I meant the transport semantics, e.g. reliable/unreliable > > > transport of > > > > this NSLP data. So the NSLP would transfer a first data chunk=20 > > > > unreliably/unsecured in the Query and after the handshake then=20 > > > > reliable... > > > > So this first data chunk has different semantics within > > > NSLP than the > > > > other NSLP data that follow and this must be made > > > explicitly visible > > > > at the API. That was my point. > > > >=20 > > > > Regards, > > > > Roland > > > >=20 > > > >=20 > > >=20 > >=20 >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Apr 19 12:55: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 1HeZuN-0000zd-Po; Thu, 19 Apr 2007 12:54:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeZuM-0000zV-AY for nsis@ietf.org; Thu, 19 Apr 2007 12:54:58 -0400 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeZuK-0001B7-PZ for nsis@ietf.org; Thu, 19 Apr 2007 12:54:58 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l3JGsOEd006580; Thu, 19 Apr 2007 19:54:49 +0300 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Apr 2007 19:54:33 +0300 Received: from daebe103.NOE.Nokia.com ([10.241.35.24]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Apr 2007 11:54:29 -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 Subject: RE: [NSIS] WGLC for draft-ietf-nsis-ntlp-13.txt Date: Thu, 19 Apr 2007 11:54:28 -0500 Message-ID: <071568CA7B789D4AA170CEF8C9613B4F760F1C@daebe103.NOE.Nokia.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] WGLC for draft-ietf-nsis-ntlp-13.txt Thread-Index: AceCkbOmlBLG5w+sTqObFFxngfu0kgAEYwDw References: <00C1366D-224E-480F-9FE8-835C80B8DF8A@netlab.nec.de> From: To: , X-OriginalArrivalTime: 19 Apr 2007 16:54:29.0493 (UTC) FILETIME=[65588A50:01C782A3] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org I strongly support Lars on this. I do not thing we should be considering additional features at this point. I think we need to get this complete and if there are any additional features which are needed, we should address them after we have some=20 deployment experience. John=20 >-----Original Message----- >From: ext Lars Eggert [mailto:lars.eggert@nokia.com]=20 >Sent: 19 April, 2007 07:47 >To: ext Jukka MJ Manner >Cc: nsis >Subject: Re: [NSIS] WGLC for draft-ietf-nsis-ntlp-13.txt > >On 2007-4-19, at 14:35, ext Jukka MJ Manner wrote: >> Yet, in a separate email I have suggested the addition of "Peering data" >> that could be used by NSLPs to give more details for the peering=20 >> decision when receiving a QUERY. This is an important function I would=20 >> like to be enabled. I can provide e.g. text for a small subsection=20 >> that identifies the issue, shows the solution and discusses its=20 >> implications on the NSLP layer. > >One of the points that came up during the IESG evaluation was=20 >that GIST was already very complex, and other ADs were=20 >questioning whether all the features were really needed or if=20 >it could even be understood and implemented. > >I think Magnus and me got the point across that a generic=20 >signaling framework comes with a certain level of complexity,=20 >but if the next revision that hits the IESG adds more features=20 >- esp. ones that apparently aren't required for any existing=20 >NSLP - that probably would send a very wrong message. > >The WG needs to really think carefully about this. > >Lars > > > >_______________________________________________ >nsis mailing list >nsis@ietf.org >https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Apr 20 03:05: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 1HenBf-0004Ij-Es; Fri, 20 Apr 2007 03:05:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HenBe-0004He-Ep for nsis@ietf.org; Fri, 20 Apr 2007 03:05:42 -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 1HenBc-0007kr-Vq for nsis@ietf.org; Fri, 20 Apr 2007 03:05:42 -0400 Received: from sbz-31.cs.helsinki.fi (sbz-31.cs.helsinki.fi [128.214.9.99]) (TLS: TLSv1/SSLv3,256bits,AES256-SHA) by mail.cs.helsinki.fi with esmtp; Fri, 20 Apr 2007 10:05:39 +0300 id 0007BD5B.46286643.000040E0 Date: Fri, 20 Apr 2007 10:05:39 +0300 (EEST) From: Jukka MJ Manner To: Lars Eggert , John Loughney Subject: Re: [NSIS] WGLC for draft-ietf-nsis-ntlp-13.txt In-Reply-To: Message-ID: References: <00C1366D-224E-480F-9FE8-835C80B8DF8A@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: 769a46790fb42fbb0b0cc700c82f7081 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 Lars (& John), GIST already does this. It sends the NSLP ID and MRI as "peering data", every time unprotected. NSLPs must be aware of that, especially if privacy is an issue. Tracking NSLP+MRI combinations, you can track a user and his signaling in the network. The proposal on the table is to allow more information besides the above two data items. This data is up to the NSLPs, and has the same concerns as the NSLP ID and MRI currently. This affects only the GIST API. We are working on two new NSLPs. At least of the NSLPs would really need this additional peering data. Otherwise the whole NSLP gets really, and unnecessary, complex. We will release the spec of this NSLP as soon as it is sensible to propose new work items in NSIS. We are working on our own GIST implementation, and it will be providing the enhanced API as discussed above. Regards, Jukka On Thu, 19 Apr 2007, Lars Eggert wrote: > On 2007-4-19, at 14:35, ext Jukka MJ Manner wrote: > >Yet, in a separate email I have suggested the addition of "Peering data" > >that could be used by NSLPs to give more details for the peering decision > >when receiving a QUERY. This is an important function I would like to be > >enabled. I can provide e.g. text for a small subsection that identifies > >the issue, shows the solution and discusses its implications on the NSLP > >layer. > > One of the points that came up during the IESG evaluation was that GIST was > already very complex, and other ADs were questioning whether all the features > were really needed or if it could even be understood and implemented. > > I think Magnus and me got the point across that a generic signaling framework > comes with a certain level of complexity, but if the next revision that hits > the IESG adds more features - esp. ones that apparently > aren't required for any existing NSLP - that probably would send a very wrong > message. > > The WG needs to really think carefully about this. > > Lars > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Apr 20 04:36:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeobA-0002CR-0R; Fri, 20 Apr 2007 04:36:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Heob7-0002BR-NI for nsis@ietf.org; Fri, 20 Apr 2007 04:36:05 -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 1Heob7-0004x4-6m for nsis@ietf.org; Fri, 20 Apr 2007 04:36:05 -0400 Received: from sbz-31.cs.helsinki.fi (sbz-31.cs.helsinki.fi [128.214.9.99]) (TLS: TLSv1/SSLv3,256bits,AES256-SHA) by mail.cs.helsinki.fi with esmtp; Fri, 20 Apr 2007 11:36:04 +0300 id 0007BD2C.46287B74.00004772 Date: Fri, 20 Apr 2007 11:36:03 +0300 (EEST) From: Jukka MJ Manner To: "Hancock, Robert" Subject: RE: [NSIS] WGLC for draft-ietf-nsis-ntlp-13.txt In-Reply-To: Message-ID: References: <00C1366D-224E-480F-9FE8-835C80B8DF8A@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: 932cba6e0228cc603da43d861a7e09d8 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, a few comments below. Jukka On Thu, 19 Apr 2007, Hancock, Robert wrote: > > - p.7: Would the use of DTLS be counted as "C-mode" or "D-mode"? > DTLS requires the establishment of state between the endpoints, > and so is (clearly?) C-mode. Ok. :) > > - p.28, S4.3.1, last paragraph: A node receives a packet with > > a hop count > > of zero, but I think this would be a special error case. > > Why would the > > previous GIST hop send a message out with a hop count of > > zero, since it > > knows the message will be discarded by the recipient? > if it was a broken implementation ;-) > Are you suggesting we should have a different error code? A GIST implementation should never send a packet out with a hop count of zero, that was my point. Not the error code itself. But a node may anyway do as you wrote, just in case the previous hop is misbehaving. > > - p.42, S4.4.4: You could make the timer description clearer, e.g., > > separate it from the main body of the paragraph, e.g., a > > formulae, and > > could also add some examples. > > could you make a suggestion? (which part of the timer description, > etc.) "the refresh of existing ones. A suitable value is 2 * routing states / rate limit (pkts/s) which leaves a factor of two headroom for new routing state creation and Query retransmissions." Then you could 1-2 examples. (I don't really get this timer value, but maybe it's just me) > > > > - p.48, middle of page: The Confirm echos something, yet, the > > information > > is something the querying node included in the first place. Can this > > information change as it comes back from the responding > > node? I would > > rephrase this to "The Confirm MUST include the MRI and SID, > > and echo the > > Responder-Cookie if the Response carried one." > i've made this change (but to me, the meaning is still the same). Yes, the meaning is quite similar, but somehow more logical to me, at least. :) > > > > > - p.54: I would make the magic number clearly visible, and > > even mention > > earlier in the document. Now one has to be very careful to find the > > value of the magic number. > would a skeleton box diagram in 5.3.1 be a good solution? For example, yes. > > > > > - p.55: "If the MRM defines the use of RAO, the sender MUST > > include it by > > default." This latter "by default" sounds wierd. Is it > > needed at all, > > isn't "MUST include it." enough? > no, because you are allowed not to include it (see the remainder > of the same paragraph). Suggested rephrasing? So, is this then a "SHOULD", since you can do otherwise, if you have a good reason for it. > > > > > - p.55: "Note that all MRMs require S=1 for at least some > > retransmissions, > > so ICMP errors related to fragmentation will be seen at the Querying > > node". Could you elaborate a bit on this? Didn't quite get it. > if S=0, and a message is too big to be forwarded, the node > with the constrained link will generate an ICMP "too big" message > but send it to the source address in the IP header (which is > not the source of the signalling message). So this ICMP message > is probably wasted. However, eventually one of these packets will > be sent with S=1 which means that the ICMP message will be addressed > to the signalling node. the point is not that the S flag setting > changes the way the ICMP message is generated, but that the value > of the S-flag tells you whether the message is going to go somewhere > useful. Right. This would be good to include in the spec. > > > > > - p.63, S.5.7.1: The discussion about the stack proposal > > object would need > > an example, a figure, to illustrate how the object is composed. > could we refer to Appendix D (which is a fairly complete example). Ok. > > > > > - p.63: What is "SCD" the acronym? Stack-Configuration-Data? > > First time it > > is used in the text body. > see p52 ;-) But not in the _body text_, just in a list item's title > > > > > - S.5.7 in general: should there be a section about using UDP > > as the MA > > transport protocol? This is not really presented anywhere. > probably not; while it is theoretically possible to negotiate > UDP (if someone defines an MA-Protocol option for it), in > practice we would not allow it (because there is no congestion > control provided with it). So I would not emphasise this possibility. So, if I am a mobile node, then I always have to use TCP over the wireless link? Sounds "interesting". If an edge (access) router is the default router for, say, 10'000 mobile nodes, then there are at least as many TCP-states. With UDP, you could have a single port and use DTLS or IPsec. With mobile nodes coming and going, you would have more than that number of TCP states, e.g., the states for closing TCP connections. Jukka _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Apr 20 04:41: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 1Heog7-0007a1-2E; Fri, 20 Apr 2007 04:41:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Heog5-0007Zh-Eh for nsis@ietf.org; Fri, 20 Apr 2007 04:41:13 -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 1Heog4-00063H-52 for nsis@ietf.org; Fri, 20 Apr 2007 04:41:13 -0400 Received: from sbz-31.cs.helsinki.fi (sbz-31.cs.helsinki.fi [128.214.9.99]) (TLS: TLSv1/SSLv3,256bits,AES256-SHA) by mail.cs.helsinki.fi with esmtp; Fri, 20 Apr 2007 11:41:11 +0300 id 0007BD64.46287CA7.00002E64 Date: Fri, 20 Apr 2007 11:41:11 +0300 (EEST) From: Jukka MJ Manner To: "Hancock, Robert" Subject: RE: [NSIS] WGLC for draft-ietf-nsis-ntlp-13.txt In-Reply-To: Message-ID: References: <00C1366D-224E-480F-9FE8-835C80B8DF8A@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: 79899194edc4f33a41f49410777972f8 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 Rob, On Thu, 19 Apr 2007, Hancock, Robert wrote: > > - S.5.7 in general: should there be a section about using UDP > > as the MA > > transport protocol? This is not really presented anywhere. > probably not; while it is theoretically possible to negotiate > UDP (if someone defines an MA-Protocol option for it), in > practice we would not allow it (because there is no congestion > control provided with it). So I would not emphasise this possibility. Reading again Section 3.2, it specifically talks about using D-mode on the edges of the network. Yet, the spec does not present how to use it with the MA in Section 5.7. I think there is a bit of a mismatch. Jukka _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Apr 20 04:49:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeooQ-00087k-Rt; Fri, 20 Apr 2007 04:49:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeooO-000825-KT for nsis@ietf.org; Fri, 20 Apr 2007 04:49:48 -0400 Received: from difra-computer.de ([81.169.157.103] helo=www.difra-computer.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeooN-0000Ya-BP for nsis@ietf.org; Fri, 20 Apr 2007 04:49:48 -0400 Received: from win2003.dickmann2003.home (p548A68A8.dip.t-dialin.net [84.138.104.168]) by www.difra-computer.de (Postfix) with ESMTP id D5A8B3E4030 for ; Fri, 20 Apr 2007 10:40:48 +0200 (CEST) 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] WGLC for draft-ietf-nsis-ntlp-13.txt X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Date: Fri, 20 Apr 2007 10:34:09 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] WGLC for draft-ietf-nsis-ntlp-13.txt Thread-Index: AceDJd0+yjiT63QwRBmGnqPyvVvxEQAAdymw From: "Christian Dickmann" To: "Jukka MJ Manner" , "Hancock, Robert" X-Spam-Score: 0.1 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 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, > Reading again Section 3.2, it specifically talks about using D-mode on > the > edges of the network. Yet, the spec does not present how to use it with > the MA in Section 5.7. I think there is a bit of a mismatch. If you know what you are doing the spec allows you to use D-Mode and no MA at all. In other words, you can use pure UDP to send your data. If you want DTLS over UDP, this will require to specify UDP and DTLS as protocols that can be used in MAs. Then DTLS over UDP is one profile that could be used in C-Mode. The current spec does not provide any secure UDP transport, but highlights how you could add it (by defining it for C-Mode, as said above).=20 I do not see any mismatch or problem here. Regards, Christian Dickmann _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Apr 20 05:06: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 1Hep4b-0001eK-0Y; Fri, 20 Apr 2007 05:06:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hep4Y-0001RW-Ar for nsis@ietf.org; Fri, 20 Apr 2007 05:06:30 -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 1Hep4W-0007TM-Nn for nsis@ietf.org; Fri, 20 Apr 2007 05:06:30 -0400 Received: from sbz-31.cs.helsinki.fi (sbz-31.cs.helsinki.fi [128.214.9.99]) (TLS: TLSv1/SSLv3,256bits,AES256-SHA) by mail.cs.helsinki.fi with esmtp; Fri, 20 Apr 2007 12:06:27 +0300 id 0007BD3F.46288293.00002664 Date: Fri, 20 Apr 2007 12:06:27 +0300 (EEST) From: Jukka MJ Manner To: "Hancock, Robert" Subject: RE: [NSIS] GIST: NSLP data in QUERY In-Reply-To: Message-ID: References: <460395CF.1010405@tm.uka.de> <460A202C.8060300@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: dbb8771284c7a36189745aa720dc20ab Cc: NSIS Working Group 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 Rob, Some comments below. On Thu, 19 Apr 2007, Hancock, Robert wrote: > > I think you misunderstood our idea. The point is that the > > SendMessage primitive would carry an additional PD object. > > This PD data is included in the QUERY and used on the next > > hop to make a decision whether to peer, or forward the QUERY > > downstream (and forget about it). Retransmission is set by > > the signaling initiator. > > i don't believe there is a need for an additional object type > or API extension for this. the NSLP knows whether routing state > exists or not. If it does, the peering has already taken place > and it is too late to change it's mind. If it does not, then > the NSLP knows that any data it provides without reliability/ > security transfer attributes can be used in the conditional > peering decision. (There are two cases: when there has never > been any routing state, and when the NSLP has just invalidated > it.) Yes, true for the existing state. Yet, if I want to set up a secure and/or reliable MA, then I can't get additional peering data through, until the MA is set up. This wastes resouces and adds delay, since I need to set up an MA first to the next NSLP peer, and then see if it really should be my next peer, or not. > > > > > The scenario is the following: > > > > [N1: Initiator, NSLP-Xa] --- [N2: NSLP_Xb] --- [N3: NSLP_Xa] > > > > We have three nodes, all running NSLP-X, but two are running > > version "a" > > of that NSLP, and one is running version "b". Now N1 wants to > > send a message to its next hop NSLP-Xa peer in a reliable > > way. What would happen: > > > > 1. N1 sends a GIST QUERY and includes a PD="a" > > 2. N2 receives the QUERY, has the NSLP-X running, but the PD > > indicates > > "a". > > 3. Since N2 is not running "a", it forwards the QUERY > > downstream towards > > N3, and forgets it never saw the message 4. N3 receives > > the QUERY, has the NSLP-X running and PD also indicates > > "a". > > 5. N3 thus decides that it wants to peer with N1, and sets up > > the reliable > > MA with N1 > > 6. N2 in the middle just routes messages between the peers N1 and N3 > > > > _Without_ such a PD in the initial QUERY, N1 would need to > > set up an MA with N2, send the NSLP data to N2, which then > > needs to set a separate MA with N3 to send that data forward > > (since it does not run the requested NSLP-X version "a"). > > The problem with this example is that it is unclear exactly > how many signalling applications and peering relationships there > really are in existence. If we follow the example through, it > would seem that sometimes N1 is talking to N2 and sometimes to > N3, depending on the data transfer characteristics involved. > But that is bad news: does N1 now have two downstream peers for > the same signalling application? or is it swapping between the > two (like a route change)? If N1 has both "a" and "b" versions, then it may have MAs with both N2 and N3. The data transfer attributes do not matter, only the peering data specifies who we are talking with. And N1 then has two separate sessions, one with N2 and one with N3. > > The way I see it is that either N1 is peered with N2 or with N3. > If N1 wants to bypass N2 then it should peer directly with N3, > and it can do this by including the PD as normal (unsecured, > unreliable) data in messages it sends when there is no routing > state. That is, the existing spec already allows this behaviour: > for the sending NSLP as just noted, and for the receiving NSLP > because there is the Routing-State-Check boolean in the RecvMessage > API call and the bypass processing described in 4.3.2. Note that > just adding additional PD objects to the RecvMessage API call > is *not* sufficient: GIST *has* to enforce the correctness of the > cookie/MRI/TTL/GHC processing, and so conditional forwarding > *cannot* be modelled simply as a RecvMessage to the NSLP followed > by a SendMesssage to propagate the data. Right. If you want to set up a C-mode MA, then this additional data is not available currently in the spec. > > If N1 wants to talk to N2 sometimes and N3 other times, then > there are two choices: > - define a proxy mode for the NSLP (so N2 can forward data > transparently) So, you need - to set an MA first between N1 and N2, then - N2 gets the NSLP, - has to process it to figure out it can't really do nothing with, - initiate the setting up of a new MA to next peer - all communications with N1 and N3 would then always go though N2. Instead, N1 sends a QUERY that has enough information for N2 to figure out it should send the QUERY forward, and forget about it. > - split X into two separate NSLPs with different NSLPIDs, and peer > for each one separately. What if you have a million different combinations of peering data? Ask a million NSLP IDs from IANA? > > Note finally that if we later come across other conditional peering > cases where the conditionality does not fit nicely with an NSLP-level > request/reply exchange (which is the implicit assumption so far), > then the existing GIST extensibility mechansisms can already handle > it within the current protocol design (specifically, I would define > a new MRM which included the input to the conditional peering > decision in the MRI). Right, so instead of making a generic peering data possible, we could define a new MRM where the MRI includes additional fields. Sounds good to me. And seems to solve our problem. A related question: what does a GIST node do, if it encounters an unknown MRM? I guess the node drops the message, since it doesn't know how to route it. Thanks for the feedback, Jukka _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Apr 20 05:09:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hep7v-0003Ww-FX; Fri, 20 Apr 2007 05:09:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hep7u-0003Wq-45 for nsis@ietf.org; Fri, 20 Apr 2007 05:09:58 -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 1Hep7s-0007mq-My for nsis@ietf.org; Fri, 20 Apr 2007 05:09:58 -0400 Received: from sbz-31.cs.helsinki.fi (sbz-31.cs.helsinki.fi [128.214.9.99]) (TLS: TLSv1/SSLv3,256bits,AES256-SHA) by mail.cs.helsinki.fi with esmtp; Fri, 20 Apr 2007 12:09:56 +0300 id 0007BD3F.46288364.00007427 Date: Fri, 20 Apr 2007 12:09:56 +0300 (EEST) From: Jukka MJ Manner To: Christian Dickmann Subject: RE: [NSIS] WGLC for draft-ietf-nsis-ntlp-13.txt In-Reply-To: Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: nsis , "Hancock, Robert" 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 The point was that the spec could say it clearly, how one uses "Forwards-UDP", e.g., do you send the Confirm to the GIST port, or do you get an alternative port number in the Response? Jukka On Fri, 20 Apr 2007, Christian Dickmann wrote: > Hi, > > > Reading again Section 3.2, it specifically talks about using D-mode on > > the > > edges of the network. Yet, the spec does not present how to use it > with > > the MA in Section 5.7. I think there is a bit of a mismatch. > > If you know what you are doing the spec allows you to use D-Mode and no > MA at all. In other words, you can use pure UDP to send your data. If > you want DTLS over UDP, this will require to specify UDP and DTLS as > protocols that can be used in MAs. Then DTLS over UDP is one profile > that could be used in C-Mode. The current spec does not provide any > secure UDP transport, but highlights how you could add it (by defining > it for C-Mode, as said above). > > I do not see any mismatch or problem here. > > Regards, > Christian Dickmann > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Apr 20 05:17: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 1HepEy-00036h-TV; Fri, 20 Apr 2007 05:17:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HepEx-00036H-0z for nsis@ietf.org; Fri, 20 Apr 2007 05:17:15 -0400 Received: from difra-computer.de ([81.169.157.103] helo=www.difra-computer.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HepEv-0001vy-OI for nsis@ietf.org; Fri, 20 Apr 2007 05:17:15 -0400 Received: from win2003.dickmann2003.home (p548A68A8.dip.t-dialin.net [84.138.104.168]) by www.difra-computer.de (Postfix) with ESMTP id 840173E4030 for ; Fri, 20 Apr 2007 11:08:17 +0200 (CEST) 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] WGLC for draft-ietf-nsis-ntlp-13.txt X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Date: Fri, 20 Apr 2007 11:03:40 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] WGLC for draft-ietf-nsis-ntlp-13.txt Thread-Index: AceDKg4uvtzNHy4QR/O1iFJD8UFqTQAAdITA From: "Christian Dickmann" To: "Jukka MJ Manner" X-Spam-Score: 0.1 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: nsis , "Hancock, Robert" X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Jukka. > The point was that the spec could say it clearly, how one uses > "Forwards-UDP", e.g., do you send the Confirm to the GIST port, or do > you > get an alternative port number in the Response? No, the point is: The spec does NOT define "Forwards-UDP" and does not intend to do so. If you want insecure UDP, just use D-Mode. If you want secure UDP, then this is not supported at the moment. And as Lars and John pointed out in their mails, we should not add new features (which a "Forwards-UDP" would be) without any really good reason. If you really need this mode, you can write an additional document that specifies "Forwards-UDP" (similar to our doc that specifies "Forwards-SCTP"). Christian _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Apr 20 05:38: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 1HepZ3-0001sK-2R; Fri, 20 Apr 2007 05:38:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HepYz-0001mW-UJ for nsis@ietf.org; Fri, 20 Apr 2007 05:37:57 -0400 Received: from rsys002x.roke.co.uk ([193.118.201.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HepYz-0006zx-GE for nsis@ietf.org; Fri, 20 Apr 2007 05:37:57 -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 l3K9bh2Z030613; Fri, 20 Apr 2007 10:37:43 +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: UDP for signalling (was: RE: [NSIS] WGLC for draft-ietf-nsis-ntlp-13.txt) Date: Fri, 20 Apr 2007 10:37:41 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: UDP for signalling (was: RE: [NSIS] WGLC for draft-ietf-nsis-ntlp-13.txt) Thread-Index: AceDKg4uvtzNHy4QR/O1iFJD8UFqTQAAdITAAABRPbA= References: From: "Hancock, Robert" To: "Christian Dickmann" , "Jukka MJ Manner" 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: fb6060cb60c0cea16e3f7219e40a0a81 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,=20 > -----Original Message----- > From: Christian Dickmann [mailto:mail@christian-dickmann.de]=20 > Sent: 20 April 2007 10:04 > To: Jukka MJ Manner > Cc: nsis; Hancock, Robert > Subject: RE: [NSIS] WGLC for draft-ietf-nsis-ntlp-13.txt >=20 > Hi Jukka. >=20 > > The point was that the spec could say it clearly, how one uses=20 > > "Forwards-UDP", e.g., do you send the Confirm to the GIST=20 > port, or do=20 > > you get an alternative port number in the Response? >=20 > No, the point is: The spec does NOT define "Forwards-UDP" and=20 > does not intend to do so. If you want insecure UDP, just use=20 > D-Mode. If you want secure UDP, then this is not supported at=20 > the moment. And as Lars and John pointed out in their mails,=20 > we should not add new features (which a "Forwards-UDP" would=20 > be) without any really good reason. If you really need this=20 > mode, you can write an additional document that specifies=20 > "Forwards-UDP" (similar to our doc that specifies "Forwards-SCTP"). this is precisely what one would have to do. we haven't done it yet but there is nothing in the protocol architecture that prevents it being done if there is a need for it. there is something in the 'acceptability rules for extensions' that would prevent a simple definition of a Forwards-UDP option. That is, we require congestion control for signalling traffic unless one of two conditions applies: i) it is logically impossible (i.e. for Query messages and Responses), in which case the rate limit applies ii) you can engineer capacity for signalling traffic and rate limit to that. the way this restriction is phrased in the spec is to say that you have to use C-mode unless conditions (i) or (ii) applies. but defining a Forwards-UDP with no other constraints would invalidate this. What I think would be rational would be to=20 define Forwards-UDP with the same applicability restrictions as D-mode (i.e. MUST NOT offer or accept unless capacity can be engineered for it). note that as a special case of the above, if the peer is one hop away and you are on a link with explicit capacity allocations (including the case of a point-to-point link) then the 'engineered capacity' clause automatically applies (the node sending the signalling traffic decides inside its own networking stack how much of the link to use for signalling). This probably covers a number of the wireless scenarios. If you want a license to send un-congestion-controlled=20 signalling traffic in general topologies, take it up with the transport ADs & good luck :-) Although there are examples of RFCs which imply the sending of uncontrolled bursts of data over UDP (the DTLS spec itself, for example), we aren't allowed to get away with that in this working group. r. >=20 > Christian >=20 >=20 > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Apr 20 06:40:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeqXx-0001yO-WF; Fri, 20 Apr 2007 06:40:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeqXw-0001xp-CE for nsis@ietf.org; Fri, 20 Apr 2007 06:40:56 -0400 Received: from nz-out-0506.google.com ([64.233.162.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeqXv-0007ln-Nb for nsis@ietf.org; Fri, 20 Apr 2007 06:40:56 -0400 Received: by nz-out-0506.google.com with SMTP id z6so769299nzd for ; Fri, 20 Apr 2007 03:40:55 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:reply-to:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=VBUOSIIv5Ou5Oa9pYG5nZ4HGO/Ru4RVDcOOq6c6Xk9Of37Rx9d2DXsiyjwyUvnaanwANXbk/zXgqGfXb5MifF14d1ZESydpEZP3JZq/GV8HgS+dTXGDdCHPHR+H470Hjtv7IwC8NNcAw9C2tWYwfBWlyyQ2ePkY0P231Ddd9ceA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:reply-to:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=kvi7HioNfdTNPQEA4E4/hTFlU1ihoWo/YfBmiXkxevDurNlQGWlAnLBYf8WIkVlUnKBQTPG4Dh9bXSMom2ApOoZdGIUnxxBIcJpTzeoeoBKRfUW0rYiObELo1fRK8gzHAsd2T5ea+h56tUEnHpJTLqF49x6lV70eaXrW37tJjKE= Received: by 10.114.14.1 with SMTP id 1mr1186705wan.1177065654944; Fri, 20 Apr 2007 03:40:54 -0700 (PDT) Received: by 10.115.110.8 with HTTP; Fri, 20 Apr 2007 03:40:54 -0700 (PDT) Message-ID: <515197b00704200340q41fbff36x41934972397b84f5@mail.gmail.com> Date: Fri, 20 Apr 2007 11:40:54 +0100 From: "Vitor Bernardo" To: nsis Subject: Re: [NSIS] WGLC for draft-ietf-nsis-ntlp-13.txt In-Reply-To: <461DF40D.30403@ericsson.com> MIME-Version: 1.0 References: <00C1366D-224E-480F-9FE8-835C80B8DF8A@netlab.nec.de> <461DF40D.30403@ericsson.com> X-Google-Sender-Auth: 10bb2ebfc6a5054b X-Spam-Score: 0.0 (/) X-Scan-Signature: d2bb8c7db26f2d12109e0cd8e454db52 Cc: nsis@dei.uc.pt, =?ISO-8859-1?Q?Lu=EDs_Cordeiro?= X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: vmbern@student.dei.uc.pt List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0924691841==" Errors-To: nsis-bounces@ietf.org --===============0924691841== Content-Type: multipart/alternative; boundary="----=_Part_96171_7177758.1177065654717" ------=_Part_96171_7177758.1177065654717 Content-Type: text/plain; charset=WINDOWS-1252; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi all, You can find UoC comments to the GIST first 3 chapters. We are going to continue the review process to check any other issues that could be improved. *GIST v13 =96 UoC Review* *[Page 4]* *1.* Introduction * * Each of these different uses of signalling is referred to as a signaling application. =D8 What is a signaling application? * * GIST path-coupled signalling does not directly support multicast flows but could be extended to do so, especially in environments where the multicast replication points can be made GIST capable. =D8 After reading this statement, I think that isn't clear for reader if G= IST is multicast or not. *[Page 5]* (=85) Instead, GIST manages its own internal state and the configuration of the underlying transport and security protocols to ensure the transfer of signalling messages on behalf of signalling applications in both directions along the flow path. * * =D8 What's the objective of GIST? =D8 After reading the first paragraphs of introduction this point isn't clear=85 *[Page 9]* *3.* Design Overview *3.1.* Overall Design Approach *3rd paragraph:* =D8 Text talks about "easy" message=85 and the "difficult" message? Probab= ly "easy" it's not the best word. * * *[Page 11]* It is possible to mix these two modes along a path. This allows, for example, the use of D-mode at the edges of the network and C-mode in the core of the network. Such combinations may make operation more efficient for mobile endpoints, while allowing *multiplexing* of signalling messages across shared security associations and transport connections between core routers. The setup for these protocols imposes an initialisation cost for the use of C-mode, but in the long term this cost can be shared over all signalling sessions between peers; once the transport layer state exists, retransmission algorithms can operate much more aggressively than would be possible in a pure D-mode design. =D8 Multiplexing ??? What do you mean multiplexing? It's not clear here. * * *[Page 12]* *Predictive Routing*: Here, the intent is to signal along a path that the data flow may follow in the future. Possible cases are pre- installation of state on the backup path that would be used in the event of a link failure, and predictive installation of state on the path that will be used after a mobile node handover. *NAT Address Reservations*: This applies to the case where a node behind a NAT wishes to reserve an address at which it can be reached by a sender on the other side. This requires a message to be sent outbound from what will be the flow receiver although no reverse routing state for the flow yet exists. =D8 This is well written, but I believe that this is a concept that is too early in the document to be well understood. *[Page 14]* *3.4 *GIST Messages =D8 What is and how works the 3 way handshake? What does each GIST message type represents? MA-Hello?! What is this message? o Maybe a figure could help the understanding. Something like the curren= t Figure 4, but simpler. o Table with a small description of message types *[Page 18]* *3.10 *Example of Operation =D8 Maybe a figure of "example of operation" could help to explain it bett= er! =D8 There is a cross-reference for a figure in section 2 but it would be better to have a new one here to ease the reading. --=20 BR, Vitor Bernardo On 4/12/07, Magnus Westerlund wrote: > > I would like to raise a warning from my side regarding this WG last > call. Unless I actually see a number of persons stating that they have > read the document in this version I will refuse to process into a second > AD review. There need to be clear consensus from the WG that this is > what you want and that it doesn't contain any serious errors. > > Please remember that unless you actually get GIST published all your > work on NSLPs will be for nothing. And unless you actually help ensure > that the document really is ready this time for publication the whole WG > effort can be terminated. I need to convince a number of ADs that you > actually taken serious looking on the problems raised and are agreeing > on how to resolve them. > > Magnus Westerlund > Your AD > > ------=_Part_96171_7177758.1177065654717 Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi all,

You can find UoC comments to the GIST first 3 chapters.
=
We are going to continue the review process to check any other issues t= hat could be improved.

GIST v13 =96 UoC Review

[Page 4]

1. Introduction
 

Each of these different uses of signal=
ling is referred to as a signaling application.

 

=D8   What is a signa= ling application?

 

GIST path-coupled signalling does not directly support multicast flows but could= be extended to do so, especially in environments where the multicast replication points= can be made GIST capable.

 

=D8   After reading t= his statement, I think that isn't clear for reader if GIST is multicast or not.

[= Page 5]

(=85)

Instead, GIST manages its own internal=
 state and the configuration of the underlying transport and security proto=
cols to ensure the transfer of signalling messages on behalf of signalling =
applications in both directions along the flow path.

&= nbsp;

=D8   What's the obje= ctive of GIST?

=D8   After reading t= he first paragraphs of introduction this point isn't clear=85

[= Page 9]

3. Design Overview

3.1. Overall Design Approach

3rd paragra= ph:

 

=D8   Text talks abou= t "easy" message=85 and the "difficult" message? Probably "easy" it's not the best word.

&= nbsp;

[= Page 11]
 

  It is p=
ossible to mix these two modes along a path.  =
This allows, for example, the use of D-mode at the edges of the network and=
 C-mode in the core of the network.
  Such combinations may make operation more    efficient for mobile endpoints, whi=
le allowing multiplexing of signalling messages ac=
ross shared security associations and transport connections between core ro=
uters.
  The setup for these protocols imposes an ini=
tialisation cost for the use of C-mode, but in the long term this cost can =
be shared over all signalling sessions between peers; once the transport la=
yer state exists, retransmission algorithms can operate much more aggressiv=
ely than would be possible in a pure D-mode design.

 

=D8   Multiplexing ??= ? What do you mean multiplexing? It's not clear here.

 

[Page 12]

   <=
b style=3D"">Predictive Routing:  Here, th=
e intent is to signal along a path that the data flow may follow in the fut=
ure. =20
Possible cases are pre- installation of state on the backup path tha=
t would be used in the event of a link failure, and predictive installation=
 of state on the path that will be used after a mobile node handover.

 
   =
NAT Address Reservations:  This applies to=
 the case where a node behind a NAT wishes to reserve an address at which i=
t can be reached by a sender on the other side.
  This requires a message to be sent outbound =
from what will be the flow receiver although no reverse routing state for t=
he flow yet exists.

 

=D8   This is well wr= itten, but I believe that this is a concept that is too early in the document to be well underst= ood.

 

[Page 14]

3.4 GIS= T Messages

=D8   What is and how= works the 3 way handshake? What does each GIST message type represents? MA-Hello?! What is = this message?

o     = ;Maybe a figure could help the understanding. Something like the current Figure 4, but simpler.

o    Table with a small description of message types


[Page 18]

3.10 Ex= ample of Operation

=D8   Maybe a figure = of "example of operation" could help to explain it better!

=D8   There is a cros= s-reference for a figure in section 2 but it would be better to have a new one here to ease t= he reading.


--
BR,
Vitor Bernardo


On 4/12/07, Magnus Westerlund <magnus.westerlund@ericsson.com> wrote:
I would like to r= aise a warning from my side regarding this WG last
call. Unless I actual= ly see a number of persons stating that they have
read the document in this version I will refuse to process into a secon= d
AD review. There need to be clear consensus from the WG that this iswhat you want and that it doesn't contain any serious errors.

Please remember that unless you actually get GIST published all yourwork on NSLPs will be for nothing. And unless you actually help ensure
= that the document really is ready this time for publication the whole WG
effort can be terminated. I need to convince a number of ADs that youactually taken serious looking on the problems raised and are agreeingon how to resolve them.

Magnus Westerlund
Your AD

------=_Part_96171_7177758.1177065654717-- --===============0924691841== 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 --===============0924691841==-- From nsis-bounces@ietf.org Fri Apr 20 07:15:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Her51-0003ut-7m; Fri, 20 Apr 2007 07:15:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Her4z-0003rz-BX for nsis@ietf.org; Fri, 20 Apr 2007 07:15:05 -0400 Received: from smtp.mei.co.jp ([133.183.129.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Her4y-0001xG-Kz for nsis@ietf.org; Fri, 20 Apr 2007 07:15:05 -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/kings) with ESMTP id l3KBErZq021029; Fri, 20 Apr 2007 20:14:53 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx1) with ESMTP id l3KBEsI12328; Fri, 20 Apr 2007 20:14:54 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/redsox) with ESMTP id l3KBEss27486; Fri, 20 Apr 2007 20:14:54 +0900 (JST) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: (un)necessary features (was: RE: [NSIS] WGLC fordraft-ietf-nsis-ntlp-13.txt) Date: Fri, 20 Apr 2007 19:14:06 +0800 Message-ID: <5F09D220B62F79418461A978CA0921BD01B67C24@pslexc01.psl.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: (un)necessary features (was: RE: [NSIS] WGLC fordraft-ietf-nsis-ntlp-13.txt) Thread-index: AceCkcGBz2SteQtdTpmi+MxA9W54rQAA+iEAACf2cwA= From: "Cheng Hong" To: "Hancock, Robert" , "Lars Eggert" , "ext Jukka MJ Manner" X-Spam-Score: 0.1 (/) X-Scan-Signature: 87a3f533bb300b99e2a18357f3c1563d Cc: nsis X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Robert, Regarding the items you listed out: > - the authorisation model (mainly 4.4.2) and TLS name=20 > checking rules (5.7.3.1) The authorisation part (4.4.2) seems a bit obscure and contains too many loosing ends. Also, most part of it sounds informational and belongs to local node control. There is no requirement that all the nodes behaving the same or following the same rule. =20 Therefore, it would better if this part is moved to the Security Considerations section after the Peer Node Authentication (8.2). Anyway, it is not part of the GIST protocol, and also not a issue solved by GIST itself. =20 > - recommendations on evolvability of D-mode (3.2) This part sounds OK.=20 > - details on IP option handling (5.3.2) > - guidance on overload protection (mainly 8.4) This seems like some attempt to counter the DoS attacks. However, falling back to a non-NSIS node and bypassing the Query does not sounds correct. Wouldn't it result in the attack propagates the attack to the whole path? Shouldn't the GIST node drop the excess Query instead? > - multipath handling (7.1.4) This seems quite important. If not addressed, GIST implementation might just breakdown in such environments.=20 Regarding the scenarios described in the first paragraph (last sentence) "For example, ...., or might appear to have disappeared even though it is still attached to the network via a different route", is it possible to share a bit more on the use case you envisaged? Cheers Cheng Hong > -----Original Message----- > From: Hancock, Robert [mailto:robert.hancock@roke.co.uk]=20 > Sent: Thursday, April 19, 2007 11:32 PM > To: Lars Eggert; ext Jukka MJ Manner > Cc: nsis > Subject: (un)necessary features (was: RE: [NSIS] WGLC=20 > fordraft-ietf-nsis-ntlp-13.txt) >=20 > hi all, >=20 > > -----Original Message----- > > From: Lars Eggert [mailto:lars.eggert@nokia.com] > > Sent: 19 April 2007 15:47 > > To: ext Jukka MJ Manner > > Cc: nsis > > Subject: Re: [NSIS] WGLC for draft-ietf-nsis-ntlp-13.txt > >=20 > > On 2007-4-19, at 14:35, ext Jukka MJ Manner wrote: > > > Yet, in a separate email I have suggested the addition of=20 > "Peering=20 > > > data" > > > that could be used by NSLPs to give more details for the peering=20 > > > decision when receiving a QUERY. This is an important > > function I would > > > like to be enabled. I can provide e.g. text for a small=20 > subsection=20 > > > that identifies the issue, shows the solution and discusses its=20 > > > implications on the NSLP layer. > >=20 > > One of the points that came up during the IESG evaluation was that=20 > > GIST was already very complex, and other ADs were=20 > questioning whether=20 > > all the features were really needed or if it could even be=20 > understood=20 > > and implemented. > >=20 > > I think Magnus and me got the point across that a generic signaling=20 > > framework comes with a certain level of complexity, but if the next=20 > > revision that hits the IESG adds more features - esp. ones that=20 > > apparently aren't required for any existing NSLP - that=20 > probably would=20 > > send a very wrong message. > >=20 > > The WG needs to really think carefully about this. >=20 > there are a couple of points here. >=20 > 1. for this particular case of early peering data, I believe=20 > that the functionality necessary is already in the spec (has=20 > been since version 7) and is used by the QoS-NSLP among=20 > others. I don't believe anything extra is needed but I'll=20 > explain why in a separate mail. >=20 > 2. as a more general point, if people spot functionality or=20 > text that they feel is unecessary (for whatever reason) then=20 > that would be fine to highlight during the WGLC process. The=20 > list of things that have been added recently can be found in=20 > the change history > (E.1 and E.2), and it would be good to focus here=20 > particularly if the additions seem worthwhile. some highlights: >=20 > - the authorisation model (mainly 4.4.2) and TLS name=20 > checking rules (5.7.3.1) > - recommendations on evolvability of D-mode (3.2) > - details on IP option handling (5.3.2) > - guidance on overload protection (mainly 8.4) > - multipath handling (7.1.4) >=20 > in particular, for the last two it would be good to know if=20 > people find the text helpful or not (since it is mainly=20 > informative). Related to the multipath handling discussion is=20 > the question of whether GIST should have an explicit routing=20 > state removal functionality, which strikes me as a case of=20 > premature optimisation compared to what is already possible=20 > in the protocol, but which some people have asked for in=20 > general terms in the past. >=20 > At the moment I am unaware of any outstanding specific=20 > 'feature XXX could be removed' suggestions (there have only=20 > ever been very few) but that does not mean that some could=20 > not be made. >=20 > r. >=20 > >=20 > > Lars > >=20 > >=20 > >=20 > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > >=20 >=20 > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Apr 20 10:02: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 1Heth6-0006VV-3h; Fri, 20 Apr 2007 10:02:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Heth5-0006VM-6b for nsis@ietf.org; Fri, 20 Apr 2007 10:02:35 -0400 Received: from rotterdam.ewi.utwente.nl ([130.89.10.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Heth4-0001pu-M1 for nsis@ietf.org; Fri, 20 Apr 2007 10:02:35 -0400 Received: from webmail.cs.utwente.nl (janus.ewi.utwente.nl [130.89.10.26]) by rotterdam.ewi.utwente.nl (8.13.6/8.13.6) with SMTP id l3KE2XED020618; Fri, 20 Apr 2007 16:02:33 +0200 (MEST) Received: from 84.82.109.231 (auth. user karagian@imap2.cs.utwente.nl) by webmail.cs.utwente.nl with HTTP; Fri, 20 Apr 2007 14:02:32 +0000 To: robert.hancock@roke.co.uk Subject: RE: [NSIS] WGLC for draft-ietf-nsis-ntlp-13.txt Date: Fri, 20 Apr 2007 14:02:32 +0000 X-Mailer: IlohaMail/0.8.13 (On: webmail.cs.utwente.nl) Message-ID: From: "Georgios Karagiannis" Bounce-To: "Georgios Karagiannis" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.042 () AWL X-Scanned-By: MIMEDefang 2.52 on 130.89.10.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (rotterdam.ewi.utwente.nl [130.89.10.5]); Fri, 20 Apr 2007 16:02:34 +0200 (MEST) X-Spam-Score: 0.1 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Robert Here are some comments on v.13 of the GIST draft. In general, I agree with the information provided in this version of the GIST draft, however, I have some comments: ------------------------------ Comment_1: Section 4.3.3, second bulet from top on page 31, regarding message size specification: This bullet is very unclear. Could you please clarify this point by e.g., providing a description in a pseudo code like form? ----------------- Comment_2: Section 4.3.3, in the discussion of the situation that a message association is not required and the message is sent in D-mode, I mis the situation, which describes that if a routing state exists and the NSLP requires via the Local Policy (Message Transfer Attribute) to not use this routing state and if the MRI can be used to derive the Q-mode encapsulation then a GIST DATA or GIST QUERY message can be sent using the Q-mode encapsulation. Please change the last bullet on page 31: FROM: " * If the message is not a QUERY, and routing state exists, it is sent with normal D-mode encapsulation directly to the address from the routing state table." INTO: " * If the message is not a QUERY or DATA, and routing state exists, it is sent with normal D-mode encapsulation directly to the address from the routing state table. * If the message is a DATA, and routing state exists, and if the NSLP requires via the Local Policy (Message Transfer Attribute) to not use this routing state, and to use the MRI to derive the Q-mode encapsulation information, then this message can be sent using the Q-mode encapsulation." ------------------------------------- Comment_3: This comment is similr to Comment_2, but it relates to Section 5.3.2, page 54: Please change the text FROM: "Q-mode encapsulation MUST be used for messages where no routing state is available or where the routing state is being refreshed, in particular Query messages." INTO: "Q-mode encapsulation MUST be used for messages where no routing state is available or where the routing state is available, but it is either being refreshed or the NSLP requires via the Local Policy (Message Transfer Attribute) to not use this routing state, and to use the MRI to derive the required Q-mode encapsulation information." ---------------------------------------- Comment_4: This comment is similar to Comment_2, but it relates to Section 5.5, see table on page 60: Please change the third column of the table on the row associated with the DATA message: FROM: "If no routing state exists and the MRI can be used to derive the Q-mode encapsulation" INTO: "If no routing state exists and the MRI can be used to derive the Q-mode encapsulation. If routing state exists and the NSLP requires via the Local Policy (Message Transfer Attribute) to not use this routing state, and the MRI can be used to derive the Q-mode encapsulation." --------------------------- Comment_5 Section 5.3.3, page 58: I would like to be emphasized that if the rules given in 4.3.3 are satisfied then the D-mode can also be used for normal signaling traffic. Please add the following sentence at the bottom of page 58: "However, when the rules given in Section 4.3.3 are satisfied then the D-mode MAY also be used for normal signaling traffic." -------------------------------------- Comment_6 The explanation and the motivation of using the magic number should be described in the first sections of the draft. ---------- Comment_7: Section 5.3.2.3, page 56, editorial: Please change: FROM: "within the networ which" INTO: "within the network which" ------------------------------- Comment_8 Section 5.5, page 60, editorial: Please change: FROM: "except that that the" INTO: "except that the" Best regards, Georgios _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Apr 20 10:17: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 1HetvL-0000N0-J5; Fri, 20 Apr 2007 10:17:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HetvK-0000Mt-BQ for nsis@ietf.org; Fri, 20 Apr 2007 10:17:18 -0400 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HetvJ-0005Ni-5J for nsis@ietf.org; Fri, 20 Apr 2007 10:17:18 -0400 Received: from [10.1.1.109] (mito.netlab.nec.de [195.37.70.39]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 3CAF713CF81 for ; Fri, 20 Apr 2007 16:17:16 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v752.3) To: nsis Message-Id: References: <987892BF-91A6-4FBE-90DF-0DA38BB4B312@netlab.nec.de> From: Martin Stiemerling Date: Fri, 20 Apr 2007 16:17:14 +0200 X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9b281509fec590bb711c36d4c3ba4f74 Subject: [NSIS] Extending WGLC for draft-ietf-nsis-ntlp-13.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: , Content-Type: multipart/mixed; boundary="===============0145665870==" Errors-To: nsis-bounces@ietf.org --===============0145665870== Content-Type: multipart/alternative; boundary=Apple-Mail-8--944544264 --Apple-Mail-8--944544264 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hi all, Thanks for all getting their reviews done and/or discuss open items. The WGLC is extended for one week, as discussions have started late and to give further opportunities for reviews. Thus, the WGLC runs now until **May 2nd**! Thanks, Martin Anfang der weitergeleiteten E-Mail: > Von: Martin Stiemerling > Datum: 18. April 2007 11:37:22 MESZ > An: nsis > Betreff: [NSIS] Reminder: WGLC for draft-ietf-nsis-ntlp-13.txt > > Dear all, > > This is a friendly reminder for the currently running WGLC for GIST. > > Apparently, there have not been much reviews and/or comments on > GIST. I interpret this as *nobody* has read the document. Consider > also Magnus' email response to the original WGLC! > > In any case, I would like to encourage all WG memmbers and > especially *all* implementers and NSLP authors to review GIST and > to send their comments to the list. > > It is even good to send something along the lines "yes, I have read > the document and it is fine with me." > > Thanks and looking forward to your reviews, > > Martin > > Am 04.04.2007 um 00:31 schrieb Martin Stiemerling: > >> Dear all, >> >> We are starting an extended WGLC for GIST. The WGLC starts on >> April 4th and will run for *three* weeks. >> >> Everybody of the NSIS WG should review GIST once again, especially >> all **implementers** and **NSLP authors**. >> >> Thank you and looking forward to your reviews and comments >> >> Martin >> >> Anfang der weitergeleiteten E-Mail: >> >>> Von: >>> Datum: 3. April 2007 21:50:02 MESZ >>> An: >>> Kopie: >>> Betreff: [NSIS] I-D ACTION:draft-ietf-nsis-ntlp-13.txt >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>> This draft is a work item of the Next Steps in Signaling Working >>> Group of the IETF. >>> >>> Title : GIST: General Internet Signalling Transport >>> Author(s) : H. Schulzrinne, R. Hancock >>> Filename : draft-ietf-nsis-ntlp-13.txt >>> Pages : 177 >>> Date : 2007-4-3 >>> >>> This document specifies protocol stacks for the routing and >>> transport >>> of per-flow signalling messages along the path taken by that flow >>> through the network. The design uses existing transport and >>> security >>> protocols under a common messaging layer, the General Internet >>> Signalling Transport (GIST), which provides a common service for >>> diverse signalling applications. GIST does not handle signalling >>> application state itself, but manages its own internal state >>> and the >>> configuration of the underlying transport and security >>> protocols to >>> enable the transfer of messages in both directions along the flow >>> path. The combination of GIST and the lower layer transport and >>> security protocols provides a solution for the base protocol >>> component of the "Next Steps in Signalling" framework. >>> >>> A URL for this Internet-Draft is: >>> http://www.ietf.org/internet-drafts/draft-ietf-nsis-ntlp-13.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-ntlp-13.txt". >>> >>> A list of Internet-Drafts directories can be found in >>> http://www.ietf.org/shadow.html >>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>> >>> Internet-Drafts can also be obtained by e-mail. >>> >>> Send a message to: >>> mailserv@ietf.org. >>> In the body type: >>> "FILE /internet-drafts/draft-ietf-nsis-ntlp-13.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. >>> >>> >>> >> >> >> >> stiemerling@netlab.nec.de >> 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 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 Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 --Apple-Mail-8--944544264 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Hi all,

Thanks for all getting = their reviews done and/or discuss open items.=A0

The WGLC is extended for = one week, as discussions have started late and to give further = opportunities for reviews.=A0

Thus, the WGLC runs now = until **May 2nd**!

Thanks,

=A0 = Martin

Anfang der weitergeleiteten E-Mail:

Von: = Martin Stiemerling <stiemerling@netlab.nec.de>= ;
Datum: 18. April 2007 11:37:22 = MESZ
An: nsis <nsis@ietf.org>
Betreff: = [NSIS] Reminder: WGLC for draft-ietf-nsis-ntlp-13.txt=A0

Dear = all,

This is a friendly reminder for the currently = running WGLC for GIST.
Apparently, there have not been = much reviews and/or comments on GIST. I interpret this as *nobody* has = read the document. Consider also Magnus' email response to the original = WGLC!

In any case, I would like to encourage all WG = memmbers and especially *all* implementers and NSLP authors to review = GIST and to send their comments to the list.

It is = even good to send something along the lines "yes, I have read the = document and it is fine with me."

Thanks and looking forward to = your reviews,

=A0 = Martin

Am 04.04.2007 um 00:31 schrieb Martin = Stiemerling:

=
Dear all,

We are = starting an extended WGLC for GIST. The WGLC starts on April 4th and = will run for *three* weeks.

Everybody of the NSIS WG should = review GIST once again, especially all **implementers** and **NSLP = authors**.

Thank you and looking forward to your reviews and = comments

=A0 = Martin

Anfang der weitergeleiteten E-Mail:

Von: <Internet-Drafts@ietf.org><= /DIV>
Datum: 3. April 2007 21:50:02 MESZ
<= DIV style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; = margin-left: 0px; ">Kopie: <nsis@ietf.org>
Betreff: [NSIS] I-D = ACTION:draft-ietf-nsis-ntlp-13.txt

A New Internet-Draft is = available from the on-line Internet-Drafts
This draft is a work item of the = Next Steps in Signaling Working Group of the IETF.

= Title = = : GIST: General Internet Signalling Transport
Author(s) : H. = Schulzrinne, R. Hancock
= Filename = : draft-ietf-nsis-ntlp-13.txt
= Pages = = : 177
Date : 2007-4-3


This document = specifies protocol stacks for the routing and transport
=A0=A0 = of per-flow signalling messages along the path taken by that = flow
=A0=A0 through the network.=A0 The design uses existing = transport and security
=A0=A0 protocols under a common = messaging layer, the General Internet
=A0=A0 Signalling Transport = (GIST), which provides a common service for
=A0=A0 diverse signalling = applications.=A0 GIST does = not handle signalling
=A0=A0 application state itself, = but manages its own internal state and the
=A0=A0 configuration of the = underlying transport and security protocols to
=A0=A0 = enable the transfer of messages in both directions along the = flow
=A0=A0 path.=A0 The combination of GIST and = the lower layer transport and
=A0=A0 security protocols = provides a solution for the base protocol
=A0=A0 component of the "Next = Steps in Signalling" framework.

A URL for this Internet-Draft = is:

To = remove yourself from the I-D Announcement list, send a message = to
i-d-announce-request@ietf.or= g with the word unsubscribe in the body of
the message.
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-ntlp-13.txt".

A list of Internet-Drafts = directories can be found in
Internet-Drafts can also be = obtained by e-mail.
Send a message to:
In the body type:
"FILE = /internet-drafts/draft-ietf-nsis-ntlp-13.txt".


NOTE: The mail = server at ietf.org can return the document in
MIME-encoded form by using the = "mpack" utility.=A0 To use = this
feature, insert the command = "ENCODING mime" before the "FILE"
= command.=A0 To = decode the response(s), you will need "munpack" or
a MIME-compliant mail = reader.=A0 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
<ATT966628.TXT>
<ATT966629.txt>



stiemerling@netlab.nec.de
NEC Europe Limited |
Registered in England 2832014



nsis mailing list



stiemerling@netlab.nec.de
NEC Europe Limited |
Registered in England 2832014




nsis mailing list

stiemerling@netlab.nec.de
NEC Europe Limited |=A0Registered Office: NEC House, = 1 Victoria Road, London W3 6BL |=A0Registered in England = 2832014

=

= --Apple-Mail-8--944544264-- --===============0145665870== 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 --===============0145665870==-- From nsis-bounces@ietf.org Fri Apr 20 11:57:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HevTy-0001U9-1f; Fri, 20 Apr 2007 11:57:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HevTw-0001Tt-Jv for nsis@ietf.org; Fri, 20 Apr 2007 11:57:08 -0400 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HevTu-0000JQ-Ar for nsis@ietf.org; Fri, 20 Apr 2007 11:57:08 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l3KFuhfC025200; Fri, 20 Apr 2007 18:57:04 +0300 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 20 Apr 2007 18:56:30 +0300 Received: from daebe103.NOE.Nokia.com ([10.241.35.24]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 20 Apr 2007 10:56:27 -0500 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [NSIS] Extending WGLC for draft-ietf-nsis-ntlp-13.txt Date: Fri, 20 Apr 2007 10:55:08 -0500 Message-ID: <071568CA7B789D4AA170CEF8C9613B4F426B92@daebe103.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] Extending WGLC for draft-ietf-nsis-ntlp-13.txt Thread-Index: AceDVqMJhEMfBe/US8yxEG4mVG6jlQADaJPQ References: <987892BF-91A6-4FBE-90DF-0DA38BB4B312@netlab.nec.de> From: To: , X-OriginalArrivalTime: 20 Apr 2007 15:56:27.0154 (UTC) FILETIME=[741F8720:01C78364] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: ce2737a971e141e0457c8c1bf182367f Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0011866410==" Errors-To: nsis-bounces@ietf.org This is a multi-part message in MIME format. --===============0011866410== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C78364.73E27939" This is a multi-part message in MIME format. ------_=_NextPart_001_01C78364.73E27939 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Just to add to Martin's mail. We need people to state that they have = read the latest draft and they either agree or disagree with the current = draft. We need to have strong consensus on this before sending it back = to the IESG. If we have only a few mails, the IESG will assume there is = no interest in promoting GIST as an Internet Standard. =20 John ________________________________ From: ext Martin Stiemerling [mailto:stiemerling@netlab.nec.de] Sent: Fri 4/20/2007 5:17 PM To: nsis Subject: [NSIS] Extending WGLC for draft-ietf-nsis-ntlp-13.txt=20 Hi all,=20 Thanks for all getting their reviews done and/or discuss open items.=20 The WGLC is extended for one week, as discussions have started late and = to give further opportunities for reviews.=20 Thus, the WGLC runs now until **May 2nd**! Thanks, Martin Anfang der weitergeleiteten E-Mail: Von: Martin Stiemerling Datum: 18. April 2007 11:37:22 MESZ An: nsis Betreff: [NSIS] Reminder: WGLC for draft-ietf-nsis-ntlp-13.txt=20 Dear all, This is a friendly reminder for the currently running WGLC for GIST. Apparently, there have not been much reviews and/or comments on GIST. I = interpret this as *nobody* has read the document. Consider also Magnus' = email response to the original WGLC! In any case, I would like to encourage all WG memmbers and especially = *all* implementers and NSLP authors to review GIST and to send their = comments to the list. It is even good to send something along the lines "yes, I have read the = document and it is fine with me." Thanks and looking forward to your reviews, Martin Am 04.04.2007 um 00:31 schrieb Martin Stiemerling: Dear all, We are starting an extended WGLC for GIST. The WGLC starts on April = 4th and will run for *three* weeks. Everybody of the NSIS WG should review GIST once again, especially all = **implementers** and **NSLP authors**. Thank you and looking forward to your reviews and comments Martin Anfang der weitergeleiteten E-Mail: Von: Datum: 3. April 2007 21:50:02 MESZ An: Kopie: Betreff: [NSIS] I-D ACTION:draft-ietf-nsis-ntlp-13.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Next Steps in Signaling Working = Group of the IETF. Title : GIST: General Internet Signalling Transport Author(s) : H. Schulzrinne, R. Hancock Filename : draft-ietf-nsis-ntlp-13.txt Pages : 177 Date : 2007-4-3 =09 =09 This document specifies protocol stacks for the routing and transport of per-flow signalling messages along the path taken by that flow through the network. The design uses existing transport and = security protocols under a common messaging layer, the General Internet Signalling Transport (GIST), which provides a common service for diverse signalling applications. GIST does not handle signalling application state itself, but manages its own internal state and = the configuration of the underlying transport and security protocols = to enable the transfer of messages in both directions along the flow path. The combination of GIST and the lower layer transport and security protocols provides a solution for the base protocol component of the "Next Steps in Signalling" framework. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nsis-ntlp-13.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-ntlp-13.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-nsis-ntlp-13.txt". =09 =09 NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. stiemerling@netlab.nec.de 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 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 Europe Limited | Registered Office: NEC House, 1 Victoria Road, = London W3 6BL | Registered in England 2832014 ------_=_NextPart_001_01C78364.73E27939 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0A= =0A=
=0A=
Just to add = to Martin's =0A= mail.  We need people to state that they have read the latest draft = and =0A= they either agree or disagree with the current draft. We need to have = strong =0A= consensus on this before sending it back to the IESG.  If we have = only a =0A= few mails, the IESG will assume there is no interest in promoting GIST = as an =0A= Internet Standard.
=0A=
 
=0A=
John
=0A=

=0A=
=0A= From: ext Martin Stiemerling =0A= [mailto:stiemerling@netlab.nec.de]
Sent: Fri 4/20/2007 5:17 =0A= PM
To: nsis
Subject: [NSIS] Extending WGLC for =0A= draft-ietf-nsis-ntlp-13.txt

=0A=
Hi all, =0A=

=0A=
Thanks for all getting their reviews done and/or discuss open =0A= items. 
=0A=

=0A=
The WGLC is extended for one week, as discussions have started late = and to =0A= give further opportunities for reviews. 
=0A=

=0A=
Thus, the WGLC runs now until **May 2nd**!
=0A=

=0A=
Thanks,
=0A=

=0A=
  Martin
=0A=

=0A=
Anfang der weitergeleiteten E-Mail:

=0A=
=0A=
Von: Martin = Stiemerling <stiemerling@netlab.nec.de&g= t;
=0A=
Datum: 18. April = 2007 11:37:22 =0A= MESZ
=0A=
An: nsis <nsis@ietf.org>
=0A=
Betreff: [NSIS] = Reminder: WGLC =0A= for draft-ietf-nsis-ntlp-13.txt 
=0A=

=0A=
Dear all,
=0A=

=0A=
This is a friendly reminder for the = currently running =0A= WGLC for GIST.
=0A=

=0A=
Apparently, there have not been much = reviews and/or =0A= comments on GIST. I interpret this as *nobody* has read the document. = Consider =0A= also Magnus' email response to the original WGLC!
=0A=

=0A=
In any case, I would like to encourage all = WG =0A= memmbers and especially *all* implementers and NSLP authors to review = GIST and =0A= to send their comments to the list.
=0A=

=0A=
It is even good to send something along the = lines =0A= "yes, I have read the document and it is fine with me."
=0A=

=0A=
Thanks and looking forward to your = reviews,
=0A=

=0A=
  =0A= Martin
=0A=

=0A=
Am 04.04.2007 um 00:31 schrieb Martin =0A= Stiemerling:
=0A=

=0A=
=0A=
Dear all,
=0A=

=0A=
We are starting an extended WGLC for = GIST. The WGLC =0A= starts on April 4th and will run for *three* weeks.
=0A=

=0A=
Everybody of the NSIS WG should review = GIST once =0A= again, especially all **implementers** and **NSLP authors**.
=0A=

=0A=
Thank you and looking forward to your = reviews and =0A= comments
=0A=

=0A=
  =0A= Martin
=0A=

=0A=
Anfang der weitergeleiteten E-Mail:
=0A=

=0A=
=0A= =0A=
Datum: 3. April 2007 21:50:02 MESZ
=0A= =0A=
Kopie: <nsis@ietf.org>
=0A=
Betreff: [NSIS] I-D =0A= ACTION:draft-ietf-nsis-ntlp-13.txt
=0A=

=0A=
A New Internet-Draft is available from = the =0A= on-line Internet-Drafts
=0A=
directories.
=0A=
This draft is a work item of the Next = Steps in =0A= Signaling Working Group of the IETF.
=0A=

=0A=
Title : GIST: General Internet = Signalling =0A= Transport
=0A=
Author(s) : H. Schulzrinne, R. = Hancock
=0A=
Filename : = draft-ietf-nsis-ntlp-13.txt
=0A=
Pages : 177
=0A=
Date : 2007-4-3
=0A=


=0A=
This document specifies protocol stacks = for the =0A= routing and transport
=0A=
   =0A= of per-flow signalling messages along the path taken by = that =0A= flow
=0A=
   =0A= through the network.  =0A= The design uses existing transport and security
=0A=
   =0A= protocols under a common messaging layer, the General =0A= Internet
=0A=
   =0A= Signalling Transport (GIST), which provides a common = service =0A= for
=0A=
   =0A= diverse signalling applications.  GIST does not handle =0A= signalling
=0A=
   =0A= application state itself, but manages its own internal = state and =0A= the
=0A=
   =0A= configuration of the underlying transport and security = protocols =0A= to
=0A=
   =0A= enable the transfer of messages in both directions along = the =0A= flow
=0A=
   =0A= path.  The =0A= combination of GIST and the lower layer transport and
=0A=
   =0A= security protocols provides a solution for the base = protocol
=0A=
   =0A= component of the "Next Steps in Signalling" framework.
=0A=

=0A=
A URL for this Internet-Draft is:
=0A= =0A=

=0A=
To remove yourself from the I-D = Announcement =0A= list, send a message to
=0A=
i-d-announce-request@ietf.o= rg =0A= with the word unsubscribe in the body of
=0A=
the message.
=0A= =0A=
to change your subscription = settings.
=0A=

=0A=
Internet-Drafts are also available by = anonymous =0A= FTP. Login with the
=0A=
username "anonymous" and a password of = your =0A= e-mail address. After
=0A=
logging in, type "cd internet-drafts" = and =0A= then
=0A=
"get draft-ietf-nsis-ntlp-13.txt".
=0A=

=0A=
A list of Internet-Drafts directories = can be =0A= found in
=0A= =0A= =0A=

=0A=
Internet-Drafts can also be obtained by =0A= e-mail.
=0A=

=0A=
Send a message to:
=0A= =0A=
In the body type:
=0A=
"FILE =0A= /internet-drafts/draft-ietf-nsis-ntlp-13.txt".
=0A=


=0A=
NOTE: The mail server at ietf.org can = return =0A= the document in
=0A=
MIME-encoded form by using the = "mpack" =0A= utility.  To use = this
=0A=
feature, insert the command = "ENCODING =0A= mime" before the "FILE"
=0A=
command.  To decode the = response(s), you =0A= will need "munpack" or
=0A=
a MIME-compliant mail = reader.  Different = MIME-compliant mail =0A= readers
=0A=
exhibit different behavior, = especially =0A= when dealing with
=0A=
"multipart" MIME messages (i.e. = documents =0A= which have been split
=0A=
up into multiple messages), so = check your =0A= local documentation on
=0A=
how to manipulate these = messages.
=0A=

=0A=
Below is the data which will enable a = MIME =0A= compliant mail reader
=0A=
implementation to automatically = retrieve the =0A= ASCII version of the
=0A=
Internet-Draft.
=0A=
<ATT966628.TXT>
=0A=
<draft-ietf-nsis-ntlp-13_URL.DEFANGED-0>
=0A=
<ATT966629.txt>
=0A=

=0A=

=0A=

=0A=
stiemerling@netlab.nec.de=0A=
NEC Europe Limited |
=0A=
Registered Office: NEC House, 1 Victoria = Road, =0A= London W3 6BL |
=0A=
Registered in England 2832014
=0A=

=0A=

=0A=

=0A=
_______________________________________________
=0A=
nsis mailing list
=0A= =0A=
=0A=

=0A=

=0A=

=0A=
stiemerling@netlab.nec.de=0A=
NEC Europe Limited |
=0A=
Registered Office: NEC House, 1 Victoria = Road, London =0A= W3 6BL |
=0A=
Registered in England 2832014
=0A=

=0A=

=0A=

=0A=

=0A=
_______________________________________________
=0A=
nsis mailing list
=0A= =0A=

=0A=
=0A=
stiemerling@netlab.nec.de=0A=
NEC Europe Limited | Registered Office: = NEC House, =0A= 1 Victoria Road, London W3 6BL | Registered in England = 2832014


------_=_NextPart_001_01C78364.73E27939-- --===============0011866410== 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 --===============0011866410==-- From nsis-bounces@ietf.org Mon Apr 23 03:20:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HfsqH-0001zE-7M; Mon, 23 Apr 2007 03:20:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HfsqF-0001z4-Ju for nsis@ietf.org; Mon, 23 Apr 2007 03:20:07 -0400 Received: from an-out-0708.google.com ([209.85.132.249]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HfsqF-0008Ij-BG for nsis@ietf.org; Mon, 23 Apr 2007 03:20:07 -0400 Received: by an-out-0708.google.com with SMTP id d30so1799342and for ; Mon, 23 Apr 2007 00:20:07 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; b=fZgP5QTIlD20qiR9YBbL44Wq/jGXG7cGTEc47p4i/3BbNLS9Jy5Pac0NP1cbkjX4Bhkv1pWY93A/JB1K/o46MOtboYlIG4FMCvw/nPlS52QuwiLCINESbpbLSgjPby2mEgaoJJQSt35Yi3pVVqqX6riUMLhb1q0w4BMSx1qfHRo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type; b=Qi9g5koG6fDIQTFNYIeOt+nwasqoetE9l3nInt5pBNnfnOEb5rGLi83Z1DGEWjTMZhS0b73que+scnlLAXGpHswJsvnGlt0nT6KmwcnB/C6Xt55yroyq43FTsgxs6xWanEFu4h95aj3tH3pv6zRXL6SiIwV9HUc2t+a286r6TtI= Received: by 10.100.191.5 with SMTP id o5mr3432080anf.1177312806563; Mon, 23 Apr 2007 00:20:06 -0700 (PDT) Received: by 10.100.136.8 with HTTP; Mon, 23 Apr 2007 00:20:06 -0700 (PDT) Message-ID: <5a26be460704230020k3ad1e6a0oc02c254f068a374e@mail.gmail.com> Date: Mon, 23 Apr 2007 15:20:06 +0800 From: "=?GB2312?B?sfOx8831?=" To: nsis@ietf.org MIME-Version: 1.0 X-Spam-Score: 1.1 (+) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Subject: [NSIS] Problem statement of NSIS protocols in mobile environment (MN coudldn't send BU to CN) 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="===============1151950025==" Errors-To: nsis-bounces@ietf.org --===============1151950025== Content-Type: multipart/alternative; boundary="----=_Part_8124_17970452.1177312806499" ------=_Part_8124_17970452.1177312806499 Content-Type: text/plain; charset=GB2312; format=flowed Content-Transfer-Encoding: base64 Content-Disposition: inline SGkgQWxsLAoKCldlIGhhdmUgbWV0IGEgcHJvYmxlbSBjYXVzZWQgYnkgdGhlIGludGVyYWN0aW9u IGJldHdlZW4gTlNJUyBwcm90b2NvbCBhbmQKbW9iaWxlIElQdjYuIFRoZSBjYXNlIHdlIGNvbnNp ZGVyIGlzIHRoYXQgQ04gc2VuZHMgcGFja2V0cyB0byB0aGUgTW9iaWxlbm9kZS4KSW4gbW9iaWxl IElQdjYgcHJvdG9jb2wsIHdoZW4gbW9iaWxlIG5vZGUgbW92ZSBmcm9tIHRoZSBob21lIGxpbmsg dG8gYQpmb3JlaWduIGxpbmssIGl0IHdpbGwgc2VuZHMgQlVzIHRvIGJvdGggSEEgYW5kIENOLiBB bmQgdGhlIGNvbmRpdGlvbiB3aGVuIE1OCnNlbmRzIEJVIHRvIENOIGlzIGFzIGZvbGxvd3M6CjGh ok1OIGhhcyBhbHJlYWR5IHJlY2VpdmVkIHRoZSBmaXJzdCBwYWNrZXQgd2hpY2ggaXMgZm9yd2Fy ZGVkIGJ5IHRoZSBIQSwgaW4Kb3RoZXIgd29yZHMsIHRoZSBmaXJzdCB0cmlhbmdsZSByb3V0aW5n IHBhY2tldCAuCgogMqGiVGhlIHNvdXJjZSBhZGRyZXNzIG9mIHRoZSBpbm5lciBJUCBoZWFkZXIg b2YgdGhlIElQLWluLUlQIEVuY2Fwc3VsYXRlZApwYWNrZXQgaXMgdGhlIGFkZHJlc3Mgb2YgQ04u CgpXaGVuIE1OIHJlY2VpdmVzIHN1Y2ggYSBwYWNrZXQsIGl0IHdpbGwgcmVhbGl6ZSB0aGF0IGl0 IGhhc24ndCBhc3NvY2lhdGVkCndpdGggQ04sIHRoZW4gTU4gd2lsbCBzZW5kIGEgQlUgdG8gaW5m b3JtIENOIGFib3V0IGl0cyBuZXcgQ29BLgoKSG93ZXZlciwgaW4gTlNJUywgdGhlIGFkZHJlc3Mg b2YgdGhlIHNpZ25hbGluZyBpcyB0aGUgYWRkcmVzc2VzIG9mIGFkamFjZW50CnNpZ25hbGluZyBw ZWVycy4gSXQgaXMgaG9wIGJ5IGhvcCAoR0lTVCBIb3ApLCBhbmQgdGhlIHNvdXJjZSBhZGRyZXNz IG9mIHRoZQphYm92ZSBwYWNrZXQgKHRoZSBmaXJzdCB0cmlhbmdsZSByb3V0aW5nIHBhY2tldCkg d2lsbCBjaGFuZ2UgdG8gdGhlIHByZXZpb3VzCmhvcCwgSXQgaXMgbm8gbG9uZ2VyIHRoZSBhZGRy ZXNzIG9mIENOLiBUaGlzIHdpbGwgY2F1c2UgYSBwcm9ibGVtLCBjb3VsZG4ndAp0cmlnZ2VyIE1O IHNlbmRpbmcgQlUgdG8gQ04uIEhvdyB0byBzb2x2ZSB0aGlzIGNvbmZsaWN0PwoKQi5SLgoKQmlu YmluLiBXYW5nCjIwMDctNC0yMwoKLS0gCldhbmcuYnVwdAo= ------=_Part_8124_17970452.1177312806499 Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: base64 Content-Disposition: inline PGRpdj5IaSBBbGwsPC9kaXY+CjxkaXY+Jm5ic3A7PC9kaXY+CjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJNQVJHSU46IDBjbSAwY20gMHB0OyBURVhULUlOREVOVDogMjRwdDsgbXNvLWNoYXIt aW5kZW50LWNvdW50OiAyLjAiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iRk9OVC1TSVpFOiAx MnB0Ij48Zm9udCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPldlIGhhdmUgbWV0IGEgcHJvYmxlbSBj YXVzZWQgYnkgdGhlIGludGVyYWN0aW9uIGJldHdlZW4mbmJzcDtOU0lTIHByb3RvY29sJm5ic3A7 YW5kIG1vYmlsZSBJUHY2LiBUaGUgY2FzZSB3ZSBjb25zaWRlciBpcyB0aGF0IENOIHNlbmRzIHBh Y2tldHMgdG8gdGhlIApNb2JpbGUgbm9kZS48L2ZvbnQ+PC9zcGFuPjwvcD48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9IkZPTlQtU0laRTogMTJwdCI+PGZvbnQgZmFjZT0iVGltZXMgTmV3IFJvbWFu Ij4KPGRpdiBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iTUFSR0lOOiAwY20gMGNtIDBwdDsgVEVY VC1JTkRFTlQ6IDI0cHQ7IG1zby1jaGFyLWluZGVudC1jb3VudDogMi4wIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9IkZPTlQtU0laRTogMTJwdCI+PGZvbnQgZmFjZT0iVGltZXMgTmV3IFJvbWFu Ij5JbiBtb2JpbGUgSVB2NiBwcm90b2NvbCwgd2hlbiBtb2JpbGUgbm9kZSBtb3ZlIGZyb20gdGhl IGhvbWUgbGluayB0byBhIGZvcmVpZ24gbGluaywgaXQgd2lsbCBzZW5kcyBCVXMgdG8gYm90aCBI QSBhbmQgQ04uIEFuZCB0aGUgY29uZGl0aW9uIHdoZW4gTU4gc2VuZHMgQlUgdG8gQ04gaXMgYXMg Zm9sbG93czoKPC9mb250Pjwvc3Bhbj48L2Rpdj4KPGRpdiBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0iTUFSR0lOOiAwY20gMGNtIDBwdDsgVEVYVC1JTkRFTlQ6IDI0cHQ7IG1zby1jaGFyLWluZGVu dC1jb3VudDogMi4wIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9IkZPTlQtU0laRTogMTJwdCI+ PC9zcGFuPjwvZGl2PjwvZm9udD48L3NwYW4+PGZvbnQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9IkZPTlQtU0laRTogMTJwdDsgbXNvLWZhcmVhc3QtZm9u dC1mYW1pbHk6ICYjMzk7VGltZXMgTmV3IFJvbWFuJiMzOTsiPgo8c3BhbiBzdHlsZT0ibXNvLWxp c3Q6IElnbm9yZSI+MTxmb250IGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+oaI8L2ZvbnQ+PC9zcGFu Pjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9IkZPTlQtU0laRTogMTJwdCI+TU4gaGFz IGFscmVhZHkgcmVjZWl2ZWQgdGhlIGZpcnN0IHBhY2tldCB3aGljaCBpcyBmb3J3YXJkZWQgYnkg dGhlIEhBLCBpbiBvdGhlciB3b3JkcywgdGhlIGZpcnN0IHRyaWFuZ2xlIHJvdXRpbmcgcGFja2V0 IC4KPC9zcGFuPjwvZm9udD4KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Ik1BUkdJTjogMGNt IDBjbSAwcHQgNTQuNzVwdDsgVEVYVC1JTkRFTlQ6IC0zMy43NXB0OyBtc28tbGlzdDogbDAgbGV2 ZWwxIGxmbzE7IHRhYi1zdG9wczogbGlzdCA1NC43NXB0Ij48Zm9udCBmYWNlPSJUaW1lcyBOZXcg Um9tYW4iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iRk9OVC1TSVpFOiAxMnB0OyBtc28tZmFy ZWFzdC1mb250LWZhbWlseTogJiMzOTtUaW1lcyBOZXcgUm9tYW4mIzM5OyI+CjxzcGFuIHN0eWxl PSJtc28tbGlzdDogSWdub3JlIj4mbmJzcDsyPGZvbnQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj6h ojwvZm9udD48L3NwYW4+PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iRk9OVC1TSVpF OiAxMnB0Ij5UaGUgc291cmNlIGFkZHJlc3Mgb2YgdGhlIGlubmVyIElQIGhlYWRlciBvZiB0aGUg SVAtaW4tSVAgRW5jYXBzdWxhdGVkIHBhY2tldCBpcyB0aGUgYWRkcmVzcyBvZiBDTi4KPC9zcGFu PjwvZm9udD48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJNQVJHSU46IDBjbSAwY20g MHB0OyBURVhULUlOREVOVDogMjRwdDsgbXNvLWNoYXItaW5kZW50LWNvdW50OiAyLjAiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iRk9OVC1TSVpFOiAxMnB0Ij48Zm9udCBmYWNlPSJUaW1lcyBO ZXcgUm9tYW4iPldoZW4gTU4gcmVjZWl2ZXMgc3VjaCBhIHBhY2tldCwgaXQgd2lsbCByZWFsaXpl IHRoYXQgaXQgaGFzbid0IGFzc29jaWF0ZWQgd2l0aCBDTiwgdGhlbiBNTiB3aWxsIHNlbmQgYSBC VSB0byBpbmZvcm0gQ04gYWJvdXQgaXRzIG5ldyBDb0EuCjwvZm9udD48L3NwYW4+PC9wPgo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iTUFSR0lOOiAwY20gMGNtIDBwdDsgVEVYVC1JTkRFTlQ6 IDI0cHQ7IG1zby1jaGFyLWluZGVudC1jb3VudDogMi4wIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9IkZPTlQtU0laRTogMTJwdCI+PGZvbnQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj5Ib3dldmVy LCBpbiBOU0lTLCB0aGUgYWRkcmVzcyBvZiB0aGUgc2lnbmFsaW5nIGlzIHRoZSBhZGRyZXNzZXMg b2YgYWRqYWNlbnQgc2lnbmFsaW5nIHBlZXJzLiBJdCBpcyBob3AgYnkgaG9wIChHSVNUIEhvcCks IGFuZCB0aGUgc291cmNlIGFkZHJlc3Mgb2YgdGhlIGFib3ZlIHBhY2tldCAodGhlIGZpcnN0IHRy aWFuZ2xlIHJvdXRpbmcgcGFja2V0KSB3aWxsIGNoYW5nZSB0byB0aGUgcHJldmlvdXMgaG9wLCBJ dCBpcyBubyBsb25nZXIgdGhlIGFkZHJlc3Mgb2YgQ04uIFRoaXMgd2lsbCBjYXVzZSBhIHByb2Js ZW0sIGNvdWxkbid0IHRyaWdnZXIgTU4gc2VuZGluZyBCVSB0byBDTi4gSG93IHRvIHNvbHZlIHRo aXMgY29uZmxpY3Q/CjwvZm9udD48L3NwYW4+PC9wPgo8ZGl2PiZuYnNwOzwvZGl2Pgo8ZGl2PkIu Ui48L2Rpdj4KPGRpdj4mbmJzcDs8L2Rpdj4KPGRpdj5CaW5iaW4uIFdhbmc8L2Rpdj4KPGRpdj4y MDA3LTQtMjM8L2Rpdj4KPGRpdj48YnI+LS0gPGJyPldhbmcuYnVwdCA8L2Rpdj4K ------=_Part_8124_17970452.1177312806499-- --===============1151950025== 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 --===============1151950025==-- From nsis-bounces@ietf.org Mon Apr 23 07:03:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HfwKM-0006W8-Du; Mon, 23 Apr 2007 07:03:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HfwKK-0006Vr-Ol for nsis@ietf.org; Mon, 23 Apr 2007 07:03:24 -0400 Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HfwKJ-0000tg-Fc for nsis@ietf.org; Mon, 23 Apr 2007 07:03:24 -0400 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 1HfwKG-0001ZV-UD; Mon, 23 Apr 2007 13:03:22 +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 C83432FC012; Mon, 23 Apr 2007 13:03:20 +0200 (CEST) Received: from localhost ([127.0.0.1]) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.44) id 1HfwKG-00059M-GE; Mon, 23 Apr 2007 13:03:20 +0200 Message-ID: <462C9277.7010000@tm.uka.de> Date: Mon, 23 Apr 2007 13:03:19 +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] Extending WGLC for draft-ietf-nsis-ntlp-13.txt References: <987892BF-91A6-4FBE-90DF-0DA38BB4B312@netlab.nec.de> In-Reply-To: X-Enigmail-Version: 0.94.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Status: No X-Spam-Score: -1.4 (-) X-Spam-Report: -1.4 ALL_TRUSTED Passed through trusted hosts only via SMTP 0.0 AWL AWL: From: address is in the auto white-list X-ATIS-Checksum: v3zoCAcc32ckk X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: nsis X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Martin, Martin Stiemerling wrote: > Thanks for all getting their reviews done and/or discuss open items. > > The WGLC is extended for one week, as discussions have started late and > to give further opportunities for reviews. Ok, great. Since we are updating our implementation to draft v13 we will give feedback soon. Regards, Roland _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Apr 23 07:33:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hfwnd-0003Fo-UR; Mon, 23 Apr 2007 07:33:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hfwnc-0003Dk-B8 for nsis@ietf.org; Mon, 23 Apr 2007 07:33:40 -0400 Received: from moutng.kundenserver.de ([212.227.126.177]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hfwnb-0008V8-UL for nsis@ietf.org; Mon, 23 Apr 2007 07:33:40 -0400 Received: from [88.64.176.200] (helo=amd64.laiers.local) by mrelayeu.kundenserver.de (node=mrelayeu4) with ESMTP (Nemesis), id 0ML21M-1Hfwna48oi-0000kH; Mon, 23 Apr 2007 13:33:39 +0200 From: Max Laier Organization: =?utf-8?q?Universit=C3=A4t_Karlsruhe?= (TH) To: "=?utf-8?q?=E6=96=8C=E6=96=8C=E7=8E=8B?=" Subject: Re: [NSIS] Problem statement of NSIS protocols in mobile environment (MN coudldn't send BU to CN) Date: Mon, 23 Apr 2007 13:33:36 +0200 User-Agent: KMail/1.9.5 References: <5a26be460704230020k3ad1e6a0oc02c254f068a374e@mail.gmail.com> In-Reply-To: <5a26be460704230020k3ad1e6a0oc02c254f068a374e@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200704231333.37839.max.laier@tm.uka.de> X-Provags-ID: V01U2FsdGVkX1+jqtzP92eG3/si+VS8xvGHJ79SqmUaId6EGgq h/j/1eoC9qOTqDrrk796D39szX/hluXsnijd0AhPfHl9jyCquu P21cc2XY3pEAtnI7ReAdQ== X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org On Monday 23 April 2007 09:20, =E6=96=8C=E6=96=8C=E7=8E=8B wrote: > We have met a problem caused by the interaction between NSIS protocol > and mobile IPv6. The case we consider is that CN sends packets to the > Mobilenode. In mobile IPv6 protocol, when mobile node move from the > home link to a foreign link, it will sends BUs to both HA and CN. And > the condition when MN sends BU to CN is as follows: > 1=E3=80=81MN has already received the first packet which is forwarded by = the > HA, in other words, the first triangle routing packet . > > 2=E3=80=81The source address of the inner IP header of the IP-in-IP > Encapsulated packet is the address of CN. > > When MN receives such a packet, it will realize that it hasn't > associated with CN, then MN will send a BU to inform CN about its new > CoA. > > However, in NSIS, the address of the signaling is the addresses of > adjacent signaling peers. It is hop by hop (GIST Hop), and the source > address of the above packet (the first triangle routing packet) will > change to the previous hop, It is no longer the address of CN. This > will cause a problem, couldn't trigger MN sending BU to CN. How to > solve this conflict? This depends on the context. If you are talking about a path-coupled=20 signalling, the MN should not do route optimization for it at all. The=20 associated flow (between CN and MN) is being tunneled and so should the=20 signalling. As soon as the MN receives a packet of the actual flow, this=20 packet will have the proper CN address in the inner header and the MN=20 will perform RO for the flow. At this point a new signalling association=20 will form between CN and MN along the optimized path. Newer MIP6 drafts=20 include proactive signalling where the MN will send a BU for the flow=20 even before it has received a new packet from the CN. If you really want to break the path coupling in order to signal along the= =20 optimized path early, you should be able to retrieve the CN address from=20 the MRI. Or am I misunderstanding your problem? =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Apr 23 09: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 1HfyZN-0004Od-4g; Mon, 23 Apr 2007 09:27:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HfyZL-0004G5-2N for nsis@ietf.org; Mon, 23 Apr 2007 09:27:03 -0400 Received: from an-out-0708.google.com ([209.85.132.249]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HfyZJ-0003Jy-MC for nsis@ietf.org; Mon, 23 Apr 2007 09:27:03 -0400 Received: by an-out-0708.google.com with SMTP id d30so1909542and for ; Mon, 23 Apr 2007 06:27:01 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=t7EV0lud/T6ZpGntvQO5JBmwKL1WeGTIzY+YIsE7eGvuD/Z7KRXDmX6s9eIK7+LIeEhRZwBic7PEgHFJuY0YLXG5W6vDDblmgCAqLabEwioztPA0LlSKv7/Cf7rPNTeDj8cZ6dAXcAeJiJoS4fX0AUmQFesa0U0NsAmb9uFgRLs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=RiqNYzuCqTOFSJ6iHeTkU7i+nPDrS8fux6beuZpcTVBEivUEsBuaexXP2l4owGBj+sswqOtCeJ8U5O4l8yXLFUCrKm7Er+6onHslwxj8P1O7CRLwY87NbBJUld6BYbSpeuNReYwM0Lp8uKOED1GkelAJH1q8CiVc0sh6yxYfABY= Received: by 10.100.42.7 with SMTP id p7mr3407127anp.1177334821351; Mon, 23 Apr 2007 06:27:01 -0700 (PDT) Received: by 10.100.136.8 with HTTP; Mon, 23 Apr 2007 06:27:01 -0700 (PDT) Message-ID: <5a26be460704230627r5513ed2aqf97835ef778dd58c@mail.gmail.com> Date: Mon, 23 Apr 2007 21:27:01 +0800 From: "=?GB2312?B?sfOx8831?=" To: "Max Laier" Subject: Re: [NSIS] Problem statement of NSIS protocols in mobile environment (MN coudldn't send BU to CN) In-Reply-To: <200704231333.37839.max.laier@tm.uka.de> MIME-Version: 1.0 References: <5a26be460704230020k3ad1e6a0oc02c254f068a374e@mail.gmail.com> <200704231333.37839.max.laier@tm.uka.de> X-Spam-Score: 0.6 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0869110555==" Errors-To: nsis-bounces@ietf.org --===============0869110555== Content-Type: multipart/alternative; boundary="----=_Part_15950_17257843.1177334821251" ------=_Part_15950_17257843.1177334821251 Content-Type: text/plain; charset=GB2312; format=flowed Content-Transfer-Encoding: base64 Content-Disposition: inline IFRoYW5rIHlvdSB2ZXJ5IG11Y2guCkFzIHlvdSBkZXNjcmliZWQgYWJvdmUsIHdlIHJldHJpZXZl ZCB0aGUgQ04gYWRkcmVzcyBmcm9tIHRoZSBNUkksIGFuZApjaGFuZ2VkIHRoZSBpbm5lciBJUCBz b3VyY2UgYWRkcmVzcyB3aXRoIHRoZSBDTiBhZGRyZXNzLgoKCjIwMDcvNC8yMywgTWF4IExhaWVy IDxtYXgubGFpZXJAdG0udWthLmRlPjoKPgo+IE9uIE1vbmRheSAyMyBBcHJpbCAyMDA3IDA5OjIw LCCx87HzzfUgd3JvdGU6Cj4gPiBXZSBoYXZlIG1ldCBhIHByb2JsZW0gY2F1c2VkIGJ5IHRoZSBp bnRlcmFjdGlvbiBiZXR3ZWVuIE5TSVMgcHJvdG9jb2wKPiA+IGFuZCBtb2JpbGUgSVB2Ni4gVGhl IGNhc2Ugd2UgY29uc2lkZXIgaXMgdGhhdCBDTiBzZW5kcyBwYWNrZXRzIHRvIHRoZQo+ID4gTW9i aWxlbm9kZS4gSW4gbW9iaWxlIElQdjYgcHJvdG9jb2wsIHdoZW4gbW9iaWxlIG5vZGUgbW92ZSBm cm9tIHRoZQo+ID4gaG9tZSBsaW5rIHRvIGEgZm9yZWlnbiBsaW5rLCBpdCB3aWxsIHNlbmRzIEJV cyB0byBib3RoIEhBIGFuZCBDTi4gQW5kCj4gPiB0aGUgY29uZGl0aW9uIHdoZW4gTU4gc2VuZHMg QlUgdG8gQ04gaXMgYXMgZm9sbG93czoKPiA+IDGhok1OIGhhcyBhbHJlYWR5IHJlY2VpdmVkIHRo ZSBmaXJzdCBwYWNrZXQgd2hpY2ggaXMgZm9yd2FyZGVkIGJ5IHRoZQo+ID4gSEEsIGluIG90aGVy IHdvcmRzLCB0aGUgZmlyc3QgdHJpYW5nbGUgcm91dGluZyBwYWNrZXQgLgo+ID4KPiA+ICAyoaJU aGUgc291cmNlIGFkZHJlc3Mgb2YgdGhlIGlubmVyIElQIGhlYWRlciBvZiB0aGUgSVAtaW4tSVAK PiA+IEVuY2Fwc3VsYXRlZCBwYWNrZXQgaXMgdGhlIGFkZHJlc3Mgb2YgQ04uCj4gPgo+ID4gV2hl biBNTiByZWNlaXZlcyBzdWNoIGEgcGFja2V0LCBpdCB3aWxsIHJlYWxpemUgdGhhdCBpdCBoYXNu J3QKPiA+IGFzc29jaWF0ZWQgd2l0aCBDTiwgdGhlbiBNTiB3aWxsIHNlbmQgYSBCVSB0byBpbmZv cm0gQ04gYWJvdXQgaXRzIG5ldwo+ID4gQ29BLgo+ID4KPiA+IEhvd2V2ZXIsIGluIE5TSVMsIHRo ZSBhZGRyZXNzIG9mIHRoZSBzaWduYWxpbmcgaXMgdGhlIGFkZHJlc3NlcyBvZgo+ID4gYWRqYWNl bnQgc2lnbmFsaW5nIHBlZXJzLiBJdCBpcyBob3AgYnkgaG9wIChHSVNUIEhvcCksIGFuZCB0aGUg c291cmNlCj4gPiBhZGRyZXNzIG9mIHRoZSBhYm92ZSBwYWNrZXQgKHRoZSBmaXJzdCB0cmlhbmds ZSByb3V0aW5nIHBhY2tldCkgd2lsbAo+ID4gY2hhbmdlIHRvIHRoZSBwcmV2aW91cyBob3AsIEl0 IGlzIG5vIGxvbmdlciB0aGUgYWRkcmVzcyBvZiBDTi4gVGhpcwo+ID4gd2lsbCBjYXVzZSBhIHBy b2JsZW0sIGNvdWxkbid0IHRyaWdnZXIgTU4gc2VuZGluZyBCVSB0byBDTi4gSG93IHRvCj4gPiBz b2x2ZSB0aGlzIGNvbmZsaWN0Pwo+Cj4gVGhpcyBkZXBlbmRzIG9uIHRoZSBjb250ZXh0LiAgSWYg eW91IGFyZSB0YWxraW5nIGFib3V0IGEgcGF0aC1jb3VwbGVkCj4gc2lnbmFsbGluZywgdGhlIE1O IHNob3VsZCBub3QgZG8gcm91dGUgb3B0aW1pemF0aW9uIGZvciBpdCBhdCBhbGwuICBUaGUKPiBh c3NvY2lhdGVkIGZsb3cgKGJldHdlZW4gQ04gYW5kIE1OKSBpcyBiZWluZyB0dW5uZWxlZCBhbmQg c28gc2hvdWxkIHRoZQo+IHNpZ25hbGxpbmcuICBBcyBzb29uIGFzIHRoZSBNTiByZWNlaXZlcyBh IHBhY2tldCBvZiB0aGUgYWN0dWFsIGZsb3csIHRoaXMKPiBwYWNrZXQgd2lsbCBoYXZlIHRoZSBw cm9wZXIgQ04gYWRkcmVzcyBpbiB0aGUgaW5uZXIgaGVhZGVyIGFuZCB0aGUgTU4KPiB3aWxsIHBl cmZvcm0gUk8gZm9yIHRoZSBmbG93LiAgQXQgdGhpcyBwb2ludCBhIG5ldyBzaWduYWxsaW5nIGFz c29jaWF0aW9uCj4gd2lsbCBmb3JtIGJldHdlZW4gQ04gYW5kIE1OIGFsb25nIHRoZSBvcHRpbWl6 ZWQgcGF0aC4gIE5ld2VyIE1JUDYgZHJhZnRzCj4gaW5jbHVkZSBwcm9hY3RpdmUgc2lnbmFsbGlu ZyB3aGVyZSB0aGUgTU4gd2lsbCBzZW5kIGEgQlUgZm9yIHRoZSBmbG93Cj4gZXZlbiBiZWZvcmUg aXQgaGFzIHJlY2VpdmVkIGEgbmV3IHBhY2tldCBmcm9tIHRoZSBDTi4KPgo+IElmIHlvdSByZWFs bHkgd2FudCB0byBicmVhayB0aGUgcGF0aCBjb3VwbGluZyBpbiBvcmRlciB0byBzaWduYWwgYWxv bmcgdGhlCj4gb3B0aW1pemVkIHBhdGggZWFybHksIHlvdSBzaG91bGQgYmUgYWJsZSB0byByZXRy aWV2ZSB0aGUgQ04gYWRkcmVzcyBmcm9tCj4gdGhlIE1SSS4KPgo+IE9yIGFtIEkgbWlzdW5kZXJz dGFuZGluZyB5b3VyIHByb2JsZW0/Cj4KPiAtLQo+IC8iXCAgQmVzdCByZWdhcmRzLCAgICAgICAg ICAgICAgICAgICAgICB8IG1sYWllckBmcmVlYnNkLm9yZwo+IFwgLyAgTWF4IExhaWVyICAgICAg ICAgICAgICAgICAgICAgICAgICB8IElDUSAjNjc3NzQ2NjEKPiBYICAgaHR0cDovL3BmNGZyZWVi c2QubG92ZTJwYXJ0eS5uZXQvICB8IG1sYWllckBFRm5ldAo+IC8gXCAgQVNDSUkgUmliYm9uIENh bXBhaWduICAgICAgICAgICAgICB8IEFnYWluc3QgSFRNTCBNYWlsIGFuZCBOZXdzCj4KCgoKLS0g CldhbmcuYnVwdAo= ------=_Part_15950_17257843.1177334821251 Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: base64 Content-Disposition: inline PGRpdj4KPGRpdj5UaGFuayB5b3UgdmVyeSBtdWNoLjwvZGl2Pgo8ZGl2PkFzIHlvdSBkZXNjcmli ZWQgYWJvdmUsIHdlIHJldHJpZXZlZCB0aGUgQ04gYWRkcmVzcyBmcm9tIHRoZSBNUkksIGFuZCBj aGFuZ2VkIHRoZSBpbm5lciBJUCBzb3VyY2UgYWRkcmVzcyB3aXRoIHRoZSBDTiBhZGRyZXNzLjxi cj48YnI+Jm5ic3A7PC9kaXY+PC9kaXY+CjxkaXY+PHNwYW4gY2xhc3M9ImdtYWlsX3F1b3RlIj4y MDA3LzQvMjMsIE1heCBMYWllciAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1heC5sYWllckB0bS51a2Eu ZGUiPm1heC5sYWllckB0bS51a2EuZGU8L2E+Jmd0Ozo8L3NwYW4+CjxibG9ja3F1b3RlIGNsYXNz PSJnbWFpbF9xdW90ZSIgc3R5bGU9IlBBRERJTkctTEVGVDogMWV4OyBNQVJHSU46IDBweCAwcHgg MHB4IDAuOGV4OyBCT1JERVItTEVGVDogI2NjYyAxcHggc29saWQiPk9uIE1vbmRheSAyMyBBcHJp bCAyMDA3IDA5OjIwLCCx87HzzfUgd3JvdGU6PGJyPiZndDsgV2UgaGF2ZSBtZXQgYSBwcm9ibGVt IGNhdXNlZCBieSB0aGUgaW50ZXJhY3Rpb24gYmV0d2VlbiBOU0lTIHByb3RvY29sCjxicj4mZ3Q7 IGFuZCBtb2JpbGUgSVB2Ni4gVGhlIGNhc2Ugd2UgY29uc2lkZXIgaXMgdGhhdCBDTiBzZW5kcyBw YWNrZXRzIHRvIHRoZTxicj4mZ3Q7IE1vYmlsZW5vZGUuIEluIG1vYmlsZSBJUHY2IHByb3RvY29s LCB3aGVuIG1vYmlsZSBub2RlIG1vdmUgZnJvbSB0aGU8YnI+Jmd0OyBob21lIGxpbmsgdG8gYSBm b3JlaWduIGxpbmssIGl0IHdpbGwgc2VuZHMgQlVzIHRvIGJvdGggSEEgYW5kIENOLiBBbmQKPGJy PiZndDsgdGhlIGNvbmRpdGlvbiB3aGVuIE1OIHNlbmRzIEJVIHRvIENOIGlzIGFzIGZvbGxvd3M6 PGJyPiZndDsgMaGiTU4gaGFzIGFscmVhZHkgcmVjZWl2ZWQgdGhlIGZpcnN0IHBhY2tldCB3aGlj aCBpcyBmb3J3YXJkZWQgYnkgdGhlPGJyPiZndDsgSEEsIGluIG90aGVyIHdvcmRzLCB0aGUgZmly c3QgdHJpYW5nbGUgcm91dGluZyBwYWNrZXQgLjxicj4mZ3Q7PGJyPiZndDsmbmJzcDsmbmJzcDsy oaJUaGUgc291cmNlIGFkZHJlc3Mgb2YgdGhlIGlubmVyIElQIGhlYWRlciBvZiB0aGUgSVAtaW4t SVAKPGJyPiZndDsgRW5jYXBzdWxhdGVkIHBhY2tldCBpcyB0aGUgYWRkcmVzcyBvZiBDTi48YnI+ Jmd0Ozxicj4mZ3Q7IFdoZW4gTU4gcmVjZWl2ZXMgc3VjaCBhIHBhY2tldCwgaXQgd2lsbCByZWFs aXplIHRoYXQgaXQgaGFzbiYjMzk7dDxicj4mZ3Q7IGFzc29jaWF0ZWQgd2l0aCBDTiwgdGhlbiBN TiB3aWxsIHNlbmQgYSBCVSB0byBpbmZvcm0gQ04gYWJvdXQgaXRzIG5ldzxicj4mZ3Q7IENvQS4K PGJyPiZndDs8YnI+Jmd0OyBIb3dldmVyLCBpbiBOU0lTLCB0aGUgYWRkcmVzcyBvZiB0aGUgc2ln bmFsaW5nIGlzIHRoZSBhZGRyZXNzZXMgb2Y8YnI+Jmd0OyBhZGphY2VudCBzaWduYWxpbmcgcGVl cnMuIEl0IGlzIGhvcCBieSBob3AgKEdJU1QgSG9wKSwgYW5kIHRoZSBzb3VyY2U8YnI+Jmd0OyBh ZGRyZXNzIG9mIHRoZSBhYm92ZSBwYWNrZXQgKHRoZSBmaXJzdCB0cmlhbmdsZSByb3V0aW5nIHBh Y2tldCkgd2lsbAo8YnI+Jmd0OyBjaGFuZ2UgdG8gdGhlIHByZXZpb3VzIGhvcCwgSXQgaXMgbm8g bG9uZ2VyIHRoZSBhZGRyZXNzIG9mIENOLiBUaGlzPGJyPiZndDsgd2lsbCBjYXVzZSBhIHByb2Js ZW0sIGNvdWxkbiYjMzk7dCB0cmlnZ2VyIE1OIHNlbmRpbmcgQlUgdG8gQ04uIEhvdyB0bzxicj4m Z3Q7IHNvbHZlIHRoaXMgY29uZmxpY3Q/PGJyPjxicj5UaGlzIGRlcGVuZHMgb24gdGhlIGNvbnRl eHQuJm5ic3A7Jm5ic3A7SWYgeW91IGFyZSB0YWxraW5nIGFib3V0IGEgcGF0aC1jb3VwbGVkCjxi cj5zaWduYWxsaW5nLCB0aGUgTU4gc2hvdWxkIG5vdCBkbyByb3V0ZSBvcHRpbWl6YXRpb24gZm9y IGl0IGF0IGFsbC4mbmJzcDsmbmJzcDtUaGU8YnI+YXNzb2NpYXRlZCBmbG93IChiZXR3ZWVuIENO IGFuZCBNTikgaXMgYmVpbmcgdHVubmVsZWQgYW5kIHNvIHNob3VsZCB0aGU8YnI+c2lnbmFsbGlu Zy4mbmJzcDsmbmJzcDtBcyBzb29uIGFzIHRoZSBNTiByZWNlaXZlcyBhIHBhY2tldCBvZiB0aGUg YWN0dWFsIGZsb3csIHRoaXMKPGJyPnBhY2tldCB3aWxsIGhhdmUgdGhlIHByb3BlciBDTiBhZGRy ZXNzIGluIHRoZSBpbm5lciBoZWFkZXIgYW5kIHRoZSBNTjxicj53aWxsIHBlcmZvcm0gUk8gZm9y IHRoZSBmbG93LiZuYnNwOyZuYnNwO0F0IHRoaXMgcG9pbnQgYSBuZXcgc2lnbmFsbGluZyBhc3Nv Y2lhdGlvbjxicj53aWxsIGZvcm0gYmV0d2VlbiBDTiBhbmQgTU4gYWxvbmcgdGhlIG9wdGltaXpl ZCBwYXRoLiZuYnNwOyZuYnNwO05ld2VyIE1JUDYgZHJhZnRzCjxicj5pbmNsdWRlIHByb2FjdGl2 ZSBzaWduYWxsaW5nIHdoZXJlIHRoZSBNTiB3aWxsIHNlbmQgYSBCVSBmb3IgdGhlIGZsb3c8YnI+ ZXZlbiBiZWZvcmUgaXQgaGFzIHJlY2VpdmVkIGEgbmV3IHBhY2tldCBmcm9tIHRoZSBDTi48YnI+ PGJyPklmIHlvdSByZWFsbHkgd2FudCB0byBicmVhayB0aGUgcGF0aCBjb3VwbGluZyBpbiBvcmRl ciB0byBzaWduYWwgYWxvbmcgdGhlPGJyPm9wdGltaXplZCBwYXRoIGVhcmx5LCB5b3Ugc2hvdWxk IGJlIGFibGUgdG8gcmV0cmlldmUgdGhlIENOIGFkZHJlc3MgZnJvbQo8YnI+dGhlIE1SSS48YnI+ PGJyPk9yIGFtIEkgbWlzdW5kZXJzdGFuZGluZyB5b3VyIHByb2JsZW0/PGJyPjxicj4tLTxicj4v JnF1b3Q7XCZuYnNwOyZuYnNwO0Jlc3QgcmVnYXJkcywmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDt8IDxhIGhy ZWY9Im1haWx0bzptbGFpZXJAZnJlZWJzZC5vcmciPm1sYWllckBmcmVlYnNkLm9yZzwvYT48YnI+ XCAvJm5ic3A7Jm5ic3A7TWF4IExhaWVyJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7fCBJQ1EgIzY3Nzc0NjYxCjxicj5YJm5ic3A7Jm5ic3A7IDxhIGhyZWY9Imh0dHA6 Ly9wZjRmcmVlYnNkLmxvdmUycGFydHkubmV0LyI+aHR0cDovL3BmNGZyZWVic2QubG92ZTJwYXJ0 eS5uZXQvPC9hPiZuYnNwOyZuYnNwO3wgbWxhaWVyQEVGbmV0PGJyPi8gXCZuYnNwOyZuYnNwO0FT Q0lJIFJpYmJvbiBDYW1wYWlnbiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3wgQWdhaW5zdCBI VE1MIE1haWwgYW5kIE5ld3M8YnI+PC9ibG9ja3F1b3RlPjwvZGl2Pjxicj48YnIgY2xlYXI9ImFs bCI+PGJyPgotLSA8YnI+V2FuZy5idXB0IAo= ------=_Part_15950_17257843.1177334821251-- --===============0869110555== 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 --===============0869110555==-- From nsis-bounces@ietf.org Tue Apr 24 05:40:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgHVO-0005li-TU; Tue, 24 Apr 2007 05:40:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgHVO-0005ld-5b for nsis@ietf.org; Tue, 24 Apr 2007 05:40:14 -0400 Received: from sender-01.it.helsinki.fi ([128.214.205.139]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgHVM-0002Xy-GV for nsis@ietf.org; Tue, 24 Apr 2007 05:40:14 -0400 Received: from [128.214.177.240] (hy-ovpn2-112.vpn.helsinki.fi [128.214.177.240]) by sender-01.it.helsinki.fi (8.13.8/8.13.8) with ESMTP id l3O9eB05023200 for ; Tue, 24 Apr 2007 12:40:11 +0300 Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: nsis@ietf.org From: Nuutti Varis Date: Tue, 24 Apr 2007 12:40:08 +0300 X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Subject: [NSIS] Comments for WGLC draft-ietf-nsis-ntlp-13.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 Hello all, Having read the draft fully a couple of times (and some parts several times more), the content feel mostly well written considering how complex the protocol is. Being in early stages of implementing GIST, the draft has been very clear so far. Unfortunately I do not have any real comments to make from the more complex parts of the specification from an implementation point of view, i.e. the route state and messaging association maintenance and all that comes along with them. Below are some comments on the draft: 3.10. Example of Operation, list item 3: "GN1 therefore constructs a GIST Query carrying the NSLP payload." - Isn't this contradicting the specification, because if GIST creates a query that requests a MA to be created, you queue all NSLP data until the MA has been created and the earliest you can send your NSLP data is in the Confirm message. (4.2.2: "a queue of messages pending transmission while an MA is being established;", 4.3.3: "If no appropriate association exists, the message is queued while one is created, which will trigger the exchange of additional GIST messages.", ) 5.8 Specific Message Routing Methods s/bere/here/ 5.1 GIST Messages "Error: ... The message includes a Network-Layer-Information object for the originator of the error message, if it is being sent in D-mode;" - A.1 The GIST Common Header states about error processing that "In all cases the receiver MUST if possible return a "Common Header Parse Error" message (Appendix A.4.4.1) with the appropriate subcode, and not process the message further.". It might be a good idea to clarify the 5.1 Error message description that the NLI is indeed optional in certain cases as it is shown in the actual header representation, denoted by the square brackets. 5.3.2.3 Upper Layer Encapsulation and Overall Interception Requirements, third paragraph s/networ/network/, the whole sentence that has this typo seems a bit off, I am guessing it should be "Q-mode packets intercepted within the network ..." A.3.9 NAT Traversal Half-bit between NAT-Count and Reserved in the bitfield diagram -- BR, Nuutti _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Apr 24 09:10:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgKnJ-0001aB-VX; Tue, 24 Apr 2007 09:10:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgKnI-0001Zs-Eq for nsis@ietf.org; Tue, 24 Apr 2007 09:10:56 -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 1HgKnG-0002Tj-44 for nsis@ietf.org; Tue, 24 Apr 2007 09:10: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; Tue, 24 Apr 2007 16:05:46 +0300 id 0007BD41.462E00AA.0000255E Date: Tue, 24 Apr 2007 16:05:46 +0300 (EEST) From: Jukka MJ Manner To: "Hancock, Robert" Subject: RE: [NSIS] WGLC for draft-ietf-nsis-ntlp-13.txt In-Reply-To: Message-ID: References: <00C1366D-224E-480F-9FE8-835C80B8DF8A@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: 52e1467c2184c31006318542db5614d5 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 On Thu, 19 Apr 2007, Hancock, Robert wrote: > > - p.47: why MUST the objects be carried in the proposed > > order? It would > > put this as a SHOULD. At least the QoS NSLP says "SHOULD" for this. > > well, there are some sensible restrictions. For example, we would > probably want the NSLP-Data object at the end (to avoid having > to parse through it looking for GIST objects); the forwarding > decision in the bypass case (4.3.4) likes the MRI at the start > without having to pull apart the whole message, and the NTO has > to be at the start if it is present. Rather than try to pin > down exactly what was necessary, it seemed easier just to MUST > the specific order. Hi Rob, Thinking again about this, if I want to define a new TLV object into GIST and put it somewhere before the NSLP-Data with the AB flags set to "AB=10 (forward)", am I allowed to change the order of objects? If GIST mandates a certain order, then all future extension headers must be put after the NSLP-Data, which may be problematic. Therefore, I would still propose that GIST gives an order for the objects and uses the word "SHOULD". IMO, this is anyway enough per RFC2119: "SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course." Jukka _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Apr 24 09:15: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 1HgKrv-0007qS-Pw; Tue, 24 Apr 2007 09:15:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgKrv-0007pt-4f for nsis@ietf.org; Tue, 24 Apr 2007 09:15:43 -0400 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgKrt-0003PL-ML for nsis@ietf.org; Tue, 24 Apr 2007 09:15:43 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l3ODFFmx015415; Tue, 24 Apr 2007 16:15:38 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Apr 2007 16:15:25 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Apr 2007 16:15:25 +0300 Received: from mgw-int02.ntc.nokia.com ([172.21.143.97]) by esebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Apr 2007 16:15:24 +0300 Received: from [172.21.39.147] (esdhcp039147.research.nokia.com [172.21.39.147]) by mgw-int02.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l3ODFNl0004871; Tue, 24 Apr 2007 16:15:23 +0300 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <54C9161D-EF92-4A85-A257-6B40A6D027BB@nokia.com> From: Lars Eggert Subject: Re: [NSIS] WGLC for draft-ietf-nsis-ntlp-13.txt Date: Tue, 24 Apr 2007 16:15:23 +0300 To: ext Georgios Karagiannis X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 24 Apr 2007 13:15:24.0805 (UTC) FILETIME=[9E911350:01C78672] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: nsis@ietf.org, robert.hancock@roke.co.uk 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="===============0403130252==" Errors-To: nsis-bounces@ietf.org --===============0403130252== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-33--602655692; protocol="application/pkcs7-signature" --Apple-Mail-33--602655692 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On 2007-4-20, at 17:02, ext Georgios Karagiannis wrote: > Comment_1: > Section 4.3.3, second bulet from top on page 31, regarding message > size > specification: > > This bullet is very unclear. Could you please clarify this point by > e.g., > providing a description in a pseudo code like form? This reminds me that I forgot to send in a comment that the following text about message sizes is wrong: The message size MUST NOT exceed the least of the following three quantities: the Path MTU to the next peer (if known), the first-hop MTU, and 576 bytes. The same limit applies to IPv4 and IPv6. This text never lets you send anything over 576 bytes, because min (pmtud-to-next-peer, first-hop-mtu, 576) <= 576 bytes You probably want something similar to this text: The message size MUST NOT exceed the path MTU to the next peer. If that is unknown, the message size MUST NOT exceed the lesser of 576 bytes and the first-hop MTU. The same limit applies to IPv4 and IPv6. Lars --Apple-Mail-33--602655692 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw ggJioAMCAQICEGtxkLFHQu1g67hlmYfwPuIwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDEwNDE2MTE1NFoXDTA4MDEwNDE2MTE1 NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA26hjntVPZMiwh4d8tyuk9KiucvG92BVUGArk5zO1jhmq7tLFgU1mqcIg VGumfQqjkAzIuh83kxIiqBrB05Wvxp85apwt4sUCvzMe8mQWzZZZYp0rBzwpOj+VC5pxsMRYtYW+ BaTFBEmvFr7D7C7roZUk0lDppS5SZFs4SQbEe9ykB9aeUf1iTiw2+ikyP2+JEYto14WYCoxFWbms FbQ1uaaK+yn1WH2YHhyMfi0IOxuT0jtbsngjHJMpWIqq334zBhj+rPSUug47YBHr41FCDMHbbbjv WbyTyDYneOW3WY8LY8bGWVlAknQGB7lgduShe6e0RI/7SL/VE6X27lM9LwIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQCx3nxxTg/WowobVTRXBiXUEEZj4LBiunWbuAnR0UbJIgijvq3JbiJvZo2gUGiW9LPaHSBz 4oxT1VR/S/6O0a4e87oV5cOQm6ReB68o9rDfUzxHTwoCfv2wwMwBrXyzQMjyQK4Lt8siV41gmZpm rSXMhjTJdd9uYYNoZKQLq+VM+TCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9 fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH 2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ a3GQsUdC7WDruGWZh/A+4jAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wNzA0MjQxMzE1MjNaMCMGCSqGSIb3DQEJBDEWBBT6VxVac7gw6T9F tWVYGV8n9xYXWTCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIw DQYJKoZIhvcNAQEBBQAEggEAagNszEFLkfZYi/7nMsNB4TZ/66DDnMCNUtAjZ9eoYTwPYc2F7zZq py2kuZ/pPQzVPxV54/4S1tmKM4glWY64w6XI9INtplhkNWPV2oSbemNA/bfHgXx61Q67J3rv4FNR JsV1oLJkRO1CzpQedyvMQAy9z39Wu5ItsUb8sZMnIke7FgqdRvcZFU+HY9jijUeymSKCV4CD4mgI BxF6LhVhnVKkI1YKecGAU/E/OmiwBa6MQ6f6md8WUjuK48ARqZOll546t6LAkgSeQh601+h9U9BQ qEUm6j4IWbP1g+sVoPdLMMjyvPheldJybFhhGnNd2IkNcsdBr2MQk1xawK1YLQAAAAAAAA== --Apple-Mail-33--602655692-- --===============0403130252== 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 --===============0403130252==-- From nsis-bounces@ietf.org Tue Apr 24 09:17: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 1HgKtS-0001MO-P7; Tue, 24 Apr 2007 09:17:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgKtR-0001H1-Ae for nsis@ietf.org; Tue, 24 Apr 2007 09:17:17 -0400 Received: from rsys001x.roke.co.uk ([193.118.201.108]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgKtN-0003jD-TS for nsis@ietf.org; Tue, 24 Apr 2007 09:17:17 -0400 Received: from rsys005a.comm.ad.roke.co.uk ([193.118.193.85]) by rsys001x.roke.co.uk (8.13.1/8.13.1) with ESMTP id l3ODH8e1012933; Tue, 24 Apr 2007 14:17:08 +0100 Received: from ehlaptop ([193.118.192.66]) by rsys005a.comm.ad.roke.co.uk with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Apr 2007 14:17:08 +0100 From: "Robert Hancock" To: "'Lars Eggert'" , "'ext Georgios Karagiannis'" References: <54C9161D-EF92-4A85-A257-6B40A6D027BB@nokia.com> Subject: RE: [NSIS] WGLC for draft-ietf-nsis-ntlp-13.txt Date: Tue, 24 Apr 2007 14:17:09 +0100 Message-ID: <001301c78672$dd2435c0$0100c80a@comm.ad.roke.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AceGcrEpJT2GjJ8IRd6wd3j0dhwGgQAAB2CA In-Reply-To: <54C9161D-EF92-4A85-A257-6B40A6D027BB@nokia.com> X-OriginalArrivalTime: 24 Apr 2007 13:17:08.0063 (UTC) FILETIME=[DC1CFEF0:01C78672] 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: c1c65599517f9ac32519d043c37c5336 Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org yep. (this is the same conclusion georgios and I came to offline, fortunately.) r. > -----Original Message----- > From: Lars Eggert [mailto:lars.eggert@nokia.com] > Sent: 24 April 2007 14:15 > To: ext Georgios Karagiannis > Cc: robert.hancock@roke.co.uk; nsis@ietf.org > Subject: Re: [NSIS] WGLC for draft-ietf-nsis-ntlp-13.txt > > On 2007-4-20, at 17:02, ext Georgios Karagiannis wrote: > > Comment_1: > > Section 4.3.3, second bulet from top on page 31, regarding message > > size > > specification: > > > > This bullet is very unclear. Could you please clarify this point by > > e.g., providing a description in a pseudo code like form? > > This reminds me that I forgot to send in a comment that the > following text about message sizes is wrong: > > The message size MUST NOT exceed the > least of the following three quantities: the Path MTU > to the next > peer (if known), the first-hop MTU, and 576 bytes. > The same limit > applies to IPv4 and IPv6. > > This text never lets you send anything over 576 bytes, > because min (pmtud-to-next-peer, first-hop-mtu, 576) <= 576 bytes > > You probably want something similar to this text: > > The message size MUST NOT exceed the path MTU to the next peer. If > that is unknown, the message size MUST NOT exceed the lesser of > 576 bytes and the first-hop MTU. The same limit applies to IPv4 > and IPv6. > > Lars > > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Apr 24 09:38: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 1HgLE3-0005mi-MC; Tue, 24 Apr 2007 09:38:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgLE1-0005hl-Lj for nsis@ietf.org; Tue, 24 Apr 2007 09:38: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 1HgLDz-0000pe-57 for nsis@ietf.org; Tue, 24 Apr 2007 09:38:33 -0400 Received: from scrooge-15.cs.helsinki.fi (vallila-gw.hupnet.helsinki.fi [128.214.20.122]) (AUTH: PLAIN cs-relay, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by mail.cs.helsinki.fi with esmtp; Tue, 24 Apr 2007 16:38:30 +0300 id 0007BD59.462E0856.00003C21 Received: from localhost (localhost [127.0.0.1]) by scrooge-15.cs.helsinki.fi (Postfix) with ESMTP id 5E5FBFE388 for ; Tue, 24 Apr 2007 16:38:29 +0300 (EEST) From: Lauri J T Liuhto To: nsis@ietf.org Subject: Re: [NSIS] Extending WGLC for draft-ietf-nsis-ntlp-13.txt Date: Tue, 24 Apr 2007 16:38:28 +0300 User-Agent: KMail/1.7.2 References: <987892BF-91A6-4FBE-90DF-0DA38BB4B312@netlab.nec.de> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200704241638.28256.lliuhto@cs.helsinki.fi> X-Spam-Score: 0.1 (/) 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 Hi all. Just got through the GIST specification. I think it is mostly quite good and clear, but I also have some comments/questions about it. 1) In a recent thread on the list we have had a discussion about NSLPs sending data within queries (relating to conditional peering). I've had some problems trying to understand the peering process with all the details relating to it. I think that Section 3 or 4 should clearly state what requirements there are to include NSLP data into queries. In the second last paragraph of page 74, Section 6.2, it is said quite clearly, but I was a bit lost before found it there: (Section 6.2 p. 74): "The NSLP data MAY be carried in the Query if local policy and the transfer attributes allow it, otherwise it MUST be queued locally pending MA establishment." 2) I was (and still am, at least a bit) quite confused when trying to understand the processing of Gist hop count. For example, in Section 4.3.1 (last paragraph) it is said: "Immediately after reception, the GIST hop count is checked. Any message with a GIST hop count of zero MUST be rejected with a "Hop Limit Exceeded" error message (Appendix A.4.4.2). Otherwise, the GIST hop count MUST be decremented by one." What exactly is meant with 'reception'? Does this mean that when a GIST aware node receives a GIST message, the GIST hop count is decremented every time, even if the message is not processed at the node but just instantly forwarded? (for example; the message is a Query, and the node is not running the NSLP in the question) What if we have a following scenario: GN1 ------------------> GN2 ------------------> GN3 NSLP a Query(NSLPID:a) (no NSLP a) Forwards query NSLP a In Section 4.3.2, bullet 2, it is said: "2. The signalling application does not wish to set up state with the Querying node and become its peer. ... these diagnostics to be meaningful, any GIST node forwarding a Query MUST NOT modify it except in the NSLP payload; in particular, it MUST NOT modify any GIST payloads or their order. An implementation MAY choose to achieve this by retaining the original message, rather than reconstructing it from some parsed internal representation." Is the GIST hop count decremented? I think that Section 4.3.4 tries to clarify (also) this case, but I find the bullets 2 and 3 a bit unclear: "2. A Q-mode encapsulated message contains an RAO value which is relevant to NSIS but not to the specific node, but the IP layer is unable to recognise whether it needs to be passed to GIST for further processing or whether the packet should be forwarded just like a normal IP datagram. 3. A Q-mode encapsulated message contains an RAO value which is relevant to the node, but the specific signalling application for the NSLPID in the message is not processed there." (2) What does '[RAO value] relevant to NSIS but not to the specific node' mean? and (3) Is this the case when an NSLP refuses to peer? If it is, then the Section title ("Nodes not Hosting the NSLP") is a bit confusing. If this is meant for something else, then I think I'm lost :) 3) In Section 5.3.1. Normal Encapsulation "...The payload MUST always begin with a 32 bit magic number with value 0x4e04 bda5 in network byte order;..." -> "...The UDP payload MUST..." ? Best Regards, Lauri On Friday 20 April 2007 17:17, Martin Stiemerling wrote: > Hi all, > > Thanks for all getting their reviews done and/or discuss open items. > > The WGLC is extended for one week, as discussions have started late > and to give further opportunities for reviews. > > Thus, the WGLC runs now until **May 2nd**! > > Thanks, > > Martin _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Apr 24 12:56:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgOIt-0006Jr-QH; Tue, 24 Apr 2007 12:55:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgOIs-0006Hd-6f for nsis@ietf.org; Tue, 24 Apr 2007 12:55:46 -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 1HgOIp-0003GO-60 for nsis@ietf.org; Tue, 24 Apr 2007 12:55:46 -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 9592725F6F8; Tue, 24 Apr 2007 17:55:42 +0100 (WEST) Received: from [127.0.0.1] (dhcp-eucpii-154.ci.uc.pt [193.136.207.154]) (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 6331B25F6F4; Tue, 24 Apr 2007 17:55:42 +0100 (WEST) Message-ID: <462E368D.5050002@dei.uc.pt> Date: Tue, 24 Apr 2007 17:55:41 +0100 From: =?windows-1252?Q?Lu=EDs_Cordeiro?= User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: vmbern@student.dei.uc.pt Subject: Re: nsis: Re: [NSIS] WGLC for draft-ietf-nsis-ntlp-13.txt References: <00C1366D-224E-480F-9FE8-835C80B8DF8A@netlab.nec.de> <461DF40D.30403@ericsson.com> <515197b00704200340q41fbff36x41934972397b84f5@mail.gmail.com> In-Reply-To: <515197b00704200340q41fbff36x41934972397b84f5@mail.gmail.com> X-Spam-Score: 1.2 (+) X-Scan-Signature: a38f40f81e96f7c17c0b6f9de20b7099 Cc: nsis@dei.uc.pt, 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="===============0933250018==" Errors-To: nsis-bounces@ietf.org --===============0933250018== Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Robert and all,

Based on a review made by Michel Diaz we send you some more comments about the first 3 chapters of the draft:

[Page 4]

Int= roduction, second paragraph
=

  • The path-coupled signalling definition is not clear. It should be given an not path-coupled example.

=A0

[Pa= ge 8]

Req= uirements, message routing definition

  • Before define the Message Routing there should be explained it's difference with "normal" routing.

=A0

[Pa= ge 11]

Sec= tion 3.2, last paragraph<= br>

  • This paragraph is quite difficult to understand: in the first line, what does transport mean, and at the end: it is GIST that makes the decision, as the application gives the requirements.

[Page 15]

Sec= tion 3.6, first paragraph=

  • The probe concept is not clear in this context.

=A0

[Pa= ge 17]

Sec= tion 3.7, last paragraph<= br>

  • This paragraph is not clear.

=A0

Hope this can help.

BR,
Lu=EDs Cordeiro


Vitor Bernardo wrote:
Hi all,

You can find UoC comments to the GIST first 3 chapters.

We are going to continue the review process to check any other issues that could be improved.

GIST v= 13 =96 UoC Review

[Page 4]

1. Introduction
=A0

Each of these different uses of si=
gnalling is referred to as a signaling application.

=A0

=D8 =A0 What is a signal= ing application?

=A0

GIST path-coupled signalling does not directly support multicast flows but could be extended to do so, especially in environments where the multicast replication points can be made GIST capable.

=A0

=D8 =A0 After reading th= is statement, I think that isn't clear for reader if GIST is multicast or not.

=

[Page 5]

(=85)

Instead, GIST manages its own inte=
rnal state and the configuration of the underlying transport and security=
 protocols to ensure the transfer of signalling messages on behalf of sig=
nalling applications in both directions along the flow path.

=A0

=D8 =A0 What's the objective of GIST?

=D8 =A0 After reading th= e first paragraphs of introduction this point isn't clear=85

[Page 9]

3. = Design Overview

3.1. Overall Design Approach

3rd paragraph:

=A0

=D8 =A0 Text talks about= "easy" message=85 and the "difficult" message? Probably "easy" it's not the best word.

=A0

[Page 11] =A0

=A0 It is =
possible to mix these two modes along a path.=A0 This allows, for example, the use of D-mode at the=
 edges of the network and C-mode in the core of the network.
=A0 Such combinations may make operation more =A0=A0=A0efficient for mobile endpoints, while allowin=
g multiplexing of signalling messages across shared =
security associations and transport connections between core routers.
=A0 The setup for these protocols imposes an init=
ialisation cost for the use of C-mode, but in the long term this cost can=
 be shared over all signalling sessions between peers; once the transport=
 layer state exists, retransmission algorithms can operate much more aggr=
essively than would be possible in a pure D-mode design.

=A0

=D8 =A0 Multiplexing ???= What do you mean multiplexing? It's not clear here.

=A0

[Page 12] 

=A0=A0 Predictive Routing:=A0 Here, the intent is to signal along a path that th=
e data flow may follow in the future.=A0=20
Possible cases are pre- installation of state on the backup path t=
hat would be used in the event of a link failure, and predictive installa=
tion of state on the path that will be used after a mobile node handover.=

  
=A0
=A0=A0 NAT Address Reservations:=A0 This applies to the case where a node behind a NAT=
 wishes to reserve an address at which it can be reached by a sender on t=
he other side.
=A0 This requires a message to be sent outbound f=
rom what will be the flow receiver although no reverse routing state for =
the flow yet exists.

=A0

=D8 =A0 This is well written, but I believe that this is a concept that is too early in the document to be well understood.

=A0

[Page 14]

3.4 GIST Messages

=D8 =A0 What is and how works the 3 way handshake? What does each GIST message type represents? MA-Hello?! What is this message?

o =A0=A0 =A0= Maybe a figure could help the understanding. Something like the current Figure 4, but simpler.

o =A0=A0 Table with a small description of message types


[= Page 18]

3.10 Example of Operation

=D8 =A0 Maybe a figure o= f "example of operation" could help to explain it better!

=D8 =A0 There is a cross-reference for a figure in section 2 but it would be better to have a new one here to ease the reading.


--
BR,
Vitor Bernardo


On 4/12/07, Magnus Westerlund <= magnus.westerlund@ericsson.com> wrote:
I would like to raise a warning from my side regarding this WG last
call. Unless I actually see a number of persons stating that they have
read the document in this version I will refuse to process into a second<= br> AD review. There need to be clear consensus from the WG that this is
what you want and that it doesn't contain any serious errors.

Please remember that unless you actually get GIST published all your
work on NSLPs will be for nothing. And unless you actually help ensure that the document really is ready this time for publication the whole WG
effort can be terminated. I need to convince a number of ADs that you
= actually taken serious looking on the problems raised and are agreeing on how to resolve them.

Magnus Westerlund
Your AD

--===============0933250018== 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 --===============0933250018==-- From nsis-bounces@ietf.org Tue Apr 24 15:04:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgQJ1-0008R8-P7; Tue, 24 Apr 2007 15:04:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgQJ0-0008R3-9G for nsis@ietf.org; Tue, 24 Apr 2007 15:04:02 -0400 Received: from exchfenlb-2.cs.cornell.edu ([128.84.97.34] helo=exchfe2.cs.cornell.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgQJ0-0003mC-1Z for nsis@ietf.org; Tue, 24 Apr 2007 15:04:02 -0400 Received: from EXCHANGE2.cs.cornell.edu ([128.84.96.44]) by exchfe2.cs.cornell.edu with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Apr 2007 15:04:01 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 24 Apr 2007 15:04:02 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-irtf-eme-francis-nutss-design-00.txt Thread-Index: AceDhyStFYA0r0+LS4i+VusRKZz2FACYAjWAACzTCGAAAI2CYAABoiHg From: "Paul Francis" To: X-OriginalArrivalTime: 24 Apr 2007 19:04:01.0291 (UTC) FILETIME=[51C38DB0:01C786A3] X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: Subject: [NSIS] draft-irtf-eme-francis-nutss-design-00.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 =20 > =20 > Sorry for the multi-mailing list spam, but I just wanted to=20 > alert the "signaling community" to the recent draft in the=20 > EME (End-Middle-End) RG. The design described is sort-of a=20 > mash-up of SIP and NSIS... >=20 > https://www1.ietf.org/mailman/listinfo/eme to join the EME=20 > mailing list. >=20 > Thanks, >=20 > PF >=20 >=20 > -----Original Message----- > From: Paul Francis > Sent: Tuesday, April 24, 2007 2:10 PM > To: eme > Cc: Paul Francis > Subject: finally!: draft-irtf-eme-francis-nutss-design-00.txt >=20 >=20 > Gang, >=20 > After weeks of quiet, we have finally generated a draft=20 > design/architecture (called NUTSS) for the EME research=20 > group. Its posted at: >=20 > http://www.ietf.org/internet-drafts/draft-irtf-eme-francis-nut ss-design-00.txt >=20 >=20 > The intent here is to use this as a strawman to generate=20 > concrete discussion, with a goal of having a pretty solid=20 > proposal to bang on at an EME meeting in Chicago this July. =20 > Given the relatively short time frame, it'd be great if folks=20 > could give this a read and start commenting in the next week=20 > or so. The draft is not as long as it seems...most of it is examples. >=20 > The main feature of the NUTSS is the "dual signaling"=20 > approach, where both path-coupled and path-decoupled=20 > signaling are tightly coordinated in order to overcome the=20 > limitations of either mode alone. Some form of=20 > dual-signaling seems necessary to me, but there might be many=20 > ways to manage it. This draft suggests one way...others=20 > might have better ideas. >=20 > Thanks, >=20 > PF >=20 > =20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Apr 24 17:17:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgSNj-0002GF-F2; Tue, 24 Apr 2007 17:17:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgSNi-0002G3-2P for nsis@ietf.org; Tue, 24 Apr 2007 17:17:02 -0400 Received: from difra-computer.de ([81.169.157.103] helo=www.difra-computer.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgSNg-0008Vk-KN for nsis@ietf.org; Tue, 24 Apr 2007 17:17:02 -0400 Received: from win2003.dickmann2003.home (p548a5e50.dip.t-dialin.net [84.138.94.80]) by www.difra-computer.de (Postfix) with ESMTP id 7CFF03E4030 for ; Tue, 24 Apr 2007 23:07:33 +0200 (CEST) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Date: Tue, 24 Apr 2007 23:03:01 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WGLC comments for draft-ietf-nsis-ntlp-13.txt Thread-Index: AceGta39jhT3R6+7SCuoWtE4wzEXog== From: "Christian Dickmann" To: "nsis" X-Spam-Score: 0.1 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Subject: [NSIS] WGLC comments for draft-ietf-nsis-ntlp-13.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 last weeks I have been working on the interop test case draft[1]. In the process I looked at almost all aspects of normal GIST operation and also at some more rare ones. I have no major concerns and as an implementor I can confirm that the spec can be implemented. GIST seems to have some complexity, but being a general purpose signaling transport protocol this is acceptable to me. As an implementor I can say that the complexity is manageable.=20 Here is a number of small issues (I mailed purely editorial issues directly to Robert while they came up): - I implemented the Legacy NAT detection given in Section 7.2.1 and it works fine with a standard linux NAT.=20 - However, the spec tells me (not just in the case of NAT Traversal) to abort a 3-way handshake when I receive an Error message. The general rules for error messages tell me to send the message with NSLP ID =3D = 0. As GIST uses the triplet (MRI, SID, NSLP ID) to index the MRS-Table, I do not know how to match the error message to the flow that is currently performing the 3-way handshake. I could try all NSLP IDs, but I do not see any reason why the error message shouldn't tell me which NSLP ID it corresponds to. Or am I supposed to get that information from the original Common Header echoed in the error message? A clarification in Section 5.6 "Error Message Processing" would be nice. - Section 7.2.1. "Legacy NAT Handling" does not discuss Q-Mode encapsulated D-Mode messages. If there is no working solution here, that should be made clear. If there is one, it should be in that section. - I tried to implement the GIST-aware NAT traversal and ran into a problem. See the separate mail on that issue. - There seems to be some inconsistency regarding the setting of the S-Flag for retransmissions. On Page 55 the spec says (indicates MUST): " Note that all MRMs require S=3D1 for at least some retransmissions, so ICMP errors related to fragmentation will be seen at the Querying node." In Section 5.8.1.2 the spec says (says SHOULD):=20 " A node SHOULD use the flow source address for initial Query messages, but SHOULD transition to the signalling source address for some retransmissions or as a matter of static configuration, for example if a NAT is known to be in the path out of a certain interface." In Section 7.2.1 (indicated RECOMMEND): " note the Q-mode encapsulation rules recommend that S=3D1 is used at least for some retransmissions (see Section 5.8)." I guess "SHOULD" is correct.=20 Again, overall I agree with the current draft and would be happy to see GIST proceed through the IESG review. The specification is very well written, the technical problems have been well addressed, the complexity is manageable and the specification can be implemented. In addition, interoperable implementations exist and most features of GIST have been tested in interop events. Regards, Christian Dickmann [1] http://user.informatik.uni-goettingen.de/~cdickman/draft-dickmann-nsis-n tlp-interop-00.txt _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Apr 24 17:17: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 1HgSO8-0002Hq-Qp; Tue, 24 Apr 2007 17:17:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgSO7-0002Hj-CP for nsis@ietf.org; Tue, 24 Apr 2007 17:17:27 -0400 Received: from difra-computer.de ([81.169.157.103] helo=www.difra-computer.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgSO6-00007F-Vr for nsis@ietf.org; Tue, 24 Apr 2007 17:17:27 -0400 Received: from win2003.dickmann2003.home (p548a5e50.dip.t-dialin.net [84.138.94.80]) by www.difra-computer.de (Postfix) with ESMTP id D998E3E4030 for ; Tue, 24 Apr 2007 23:07:59 +0200 (CEST) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Date: Tue, 24 Apr 2007 23:03:28 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: GIST-aware NAT Traversal Thread-Index: AceGtb6fK+ItU5uNQz2ArNqwM14tVg== From: "Christian Dickmann" To: "nsis" X-Spam-Score: 0.1 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Subject: [NSIS] GIST-aware NAT Traversal X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi all, I tried to implement the Gist-aware NAT Traversal described in Section 7.2 of the GIST draft-v13 and ran into problems. Processing of Query and Response works fine, but I have a problem with Confirm and Data messages. The following scenario is not the most general one, but I picked it to start with the implementation: I assume that the Querying node is on the internal side of a NAT and that the Resonding side is on the external side.=20 The steps are: 1. The Querying node creates the Query with the local MRI. I denote this message as Query(MRI) 2. The GIST-aware NAT translates the MRI to MRI' and adds a NTO with the original MRI. I denote this message as Query'(MRI', NTO(MRI)). 3. The Responding node creates state for the flow described by MRI' and generates a Response with MRI' and echos the NTO with the original MRI. I denote this message as Response(MRI', NTO(MRI)). 4. The GIST-aware NAT touches neither MRI nor NTO (but NLI and SCD, but this is not relevant here). I call this message Response'(MRI', NTO(MRI)) 5. The Querying node accesses its routing table with the original MRI contained in the NTO and not with MRI'. It does not care for the MRI' at all. It generates a Confirm in the normal way with MRI. Especially there is no NTO in the Confirm. I call this message Confirm(MRI) 6. The GIST-aware NAT does not apply GIST specific processing to the Confirm, so the Confirm is unchanged. 7. The Responding node receives Confirm(MRI). It has to access its routing table with that MRI, but it created state only for MRI' (see step 3). In Step 7 I can't match the MRI contained in the Confirm to the routing state table I have. The only guidance I can find in the draft is: " In particular, the values for Message-Routing- Information are different, which is why the unmodified MRI is propagated in the NAT-Traversal object to allow subsequent C-mode messages to be interpreted correctly." (end of Section 7.2.2 Page 94) Should I add an entry to my routing table in the Responding node that corresponds to MRI instead of MRI'? Did I miss anything else? The same problem applies to subsequent Data messages and is independent from D-Mode/C-Mode. Regards, Christian Dickmann _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Apr 25 05:30:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgdpP-0002tL-M4; Wed, 25 Apr 2007 05:30:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgdpP-0002tG-8T for nsis@ietf.org; Wed, 25 Apr 2007 05:30:23 -0400 Received: from rsys001x.roke.co.uk ([193.118.201.108]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgdpK-0008Vc-KC for nsis@ietf.org; Wed, 25 Apr 2007 05:30:23 -0400 Received: from rsys005a.comm.ad.roke.co.uk ([193.118.193.85]) by rsys001x.roke.co.uk (8.13.1/8.13.1) with ESMTP id l3P9U8oW013351; Wed, 25 Apr 2007 10:30:08 +0100 Received: from [193.118.197.222] ([193.118.197.222]) by rsys005a.comm.ad.roke.co.uk with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Apr 2007 10:30:08 +0100 Message-ID: <462F1FA0.3040407@roke.co.uk> Date: Wed, 25 Apr 2007 10:30:08 +0100 From: Andrew McDonald User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Robert Hancock Subject: Re: [NSIS] WGLC for draft-ietf-nsis-ntlp-13.txt References: <54C9161D-EF92-4A85-A257-6B40A6D027BB@nokia.com> <001301c78672$dd2435c0$0100c80a@comm.ad.roke.co.uk> In-Reply-To: <001301c78672$dd2435c0$0100c80a@comm.ad.roke.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Apr 2007 09:30:08.0426 (UTC) FILETIME=[509710A0:01C7871C] 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: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: 'ext Georgios Karagiannis' , nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org On a related point, section 4.3.4 (page 33) says: > 1. The message is so large that it would be fragmented on downstream > links, for example because the downstream MTU is abnormally small > (less than 512 bytes). The error "Message Too Large" > (Appendix A.4.4.8) SHOULD be returned to the sender, which SHOULD > begin messaging association setup. I'm not clear why a value of 512 bytes is used here, rather than the 576 bytes given in 4.3.3. Possibly 512 bytes is meant to be the GIST data size (i.e. GIST message excluding IP/transport headers), since that would make a message size of 576 bytes with the 64 byte header allowance given in 4.3.3. Andrew Robert Hancock wrote: > yep. > > (this is the same conclusion georgios and I came to offline, fortunately.) > > r. > >> -----Original Message----- >> From: Lars Eggert [mailto:lars.eggert@nokia.com] >> Sent: 24 April 2007 14:15 >> To: ext Georgios Karagiannis >> Cc: robert.hancock@roke.co.uk; nsis@ietf.org >> Subject: Re: [NSIS] WGLC for draft-ietf-nsis-ntlp-13.txt >> >> On 2007-4-20, at 17:02, ext Georgios Karagiannis wrote: >>> Comment_1: >>> Section 4.3.3, second bulet from top on page 31, regarding message >>> size >>> specification: >>> >>> This bullet is very unclear. Could you please clarify this point by >>> e.g., providing a description in a pseudo code like form? >> This reminds me that I forgot to send in a comment that the >> following text about message sizes is wrong: >> >> The message size MUST NOT exceed the >> least of the following three quantities: the Path MTU >> to the next >> peer (if known), the first-hop MTU, and 576 bytes. >> The same limit >> applies to IPv4 and IPv6. >> >> This text never lets you send anything over 576 bytes, >> because min (pmtud-to-next-peer, first-hop-mtu, 576) <= 576 bytes >> >> You probably want something similar to this text: >> >> The message size MUST NOT exceed the path MTU to the next peer. If >> that is unknown, the message size MUST NOT exceed the lesser of >> 576 bytes and the first-hop MTU. The same limit applies to IPv4 >> and IPv6. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Apr 25 05: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 1Hgdv6-00078G-SE; Wed, 25 Apr 2007 05:36:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hgdv5-000782-Ll for nsis@ietf.org; Wed, 25 Apr 2007 05:36:15 -0400 Received: from rotterdam.ewi.utwente.nl ([130.89.10.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hgdv5-0003Wy-9I for nsis@ietf.org; Wed, 25 Apr 2007 05:36:15 -0400 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by rotterdam.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id l3P9a7jP000379; Wed, 25 Apr 2007 11:36:14 +0200 (MEST) From: "Georgios Karagiannis" To: "'Andrew McDonald'" , "'Robert Hancock'" References: <54C9161D-EF92-4A85-A257-6B40A6D027BB@nokia.com> <001301c78672$dd2435c0$0100c80a@comm.ad.roke.co.uk> <462F1FA0.3040407@roke.co.uk> Subject: RE: [NSIS] WGLC for draft-ietf-nsis-ntlp-13.txt Date: Wed, 25 Apr 2007 11:36:01 +0200 Message-ID: <001101c7871d$266b0e20$4c0d5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <462F1FA0.3040407@roke.co.uk> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AceHHFWz55xOKbYkT+isCzO5tl0qQgAALlXg X-Spam-Score: 0.092 () AWL X-Scanned-By: MIMEDefang 2.52 on 130.89.10.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (rotterdam.ewi.utwente.nl [130.89.10.5]); Wed, 25 Apr 2007 11:36:14 +0200 (MEST) X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Andrew I agree with your observation! Best regards, Georgios > -----Original Message----- > From: Andrew McDonald [mailto:andrew.mcdonald@roke.co.uk] > Sent: woensdag 25 april 2007 11:30 > To: Robert Hancock > Cc: 'Lars Eggert'; 'ext Georgios Karagiannis'; nsis@ietf.org > Subject: Re: [NSIS] WGLC for draft-ietf-nsis-ntlp-13.txt > > On a related point, section 4.3.4 (page 33) says: > > 1. The message is so large that it would be fragmented > on downstream > > links, for example because the downstream MTU is > abnormally small > > (less than 512 bytes). The error "Message Too Large" > > (Appendix A.4.4.8) SHOULD be returned to the sender, > which SHOULD > > begin messaging association setup. > > I'm not clear why a value of 512 bytes is used here, rather > than the 576 bytes given in 4.3.3. > > Possibly 512 bytes is meant to be the GIST data size (i.e. > GIST message excluding IP/transport headers), since that > would make a message size of > 576 bytes with the 64 byte header allowance given in 4.3.3. > > Andrew > > Robert Hancock wrote: > > yep. > > > > (this is the same conclusion georgios and I came to offline, > > fortunately.) > > > > r. > > > >> -----Original Message----- > >> From: Lars Eggert [mailto:lars.eggert@nokia.com] > >> Sent: 24 April 2007 14:15 > >> To: ext Georgios Karagiannis > >> Cc: robert.hancock@roke.co.uk; nsis@ietf.org > >> Subject: Re: [NSIS] WGLC for draft-ietf-nsis-ntlp-13.txt > >> > >> On 2007-4-20, at 17:02, ext Georgios Karagiannis wrote: > >>> Comment_1: > >>> Section 4.3.3, second bulet from top on page 31, > regarding message > >>> size > >>> specification: > >>> > >>> This bullet is very unclear. Could you please clarify > this point by > >>> e.g., providing a description in a pseudo code like form? > >> This reminds me that I forgot to send in a comment that > the following > >> text about message sizes is wrong: > >> > >> The message size MUST NOT exceed the > >> least of the following three quantities: the Path > MTU to the > >> next > >> peer (if known), the first-hop MTU, and 576 bytes. > >> The same limit > >> applies to IPv4 and IPv6. > >> > >> This text never lets you send anything over 576 bytes, because min > >> (pmtud-to-next-peer, first-hop-mtu, 576) <= 576 bytes > >> > >> You probably want something similar to this text: > >> > >> The message size MUST NOT exceed the path MTU to the > next peer. If > >> that is unknown, the message size MUST NOT exceed the lesser of > >> 576 bytes and the first-hop MTU. The same limit applies to IPv4 > >> and IPv6. > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Apr 27 11:27: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 1HhSMI-0003Sh-WE; Fri, 27 Apr 2007 11:27:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhSMH-0003SX-VO for nsis@ietf.org; Fri, 27 Apr 2007 11:27:41 -0400 Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhSMG-0003AU-IQ for nsis@ietf.org; Fri, 27 Apr 2007 11:27:41 -0400 Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5]) by iramx2.ira.uni-karlsruhe.de with esmtps id 1HhSME-000739-4B; Fri, 27 Apr 2007 17:27:39 +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 1HhSMD-0001Du-QO; Fri, 27 Apr 2007 17:27:37 +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 0E5802FC013; Fri, 27 Apr 2007 17:27:37 +0200 (CEST) Received: from localhost ([127.0.0.1]) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.44) id 1HhSMC-0002xb-If; Fri, 27 Apr 2007 17:27:36 +0200 Message-ID: <46321667.2000409@tm.uka.de> Date: Fri, 27 Apr 2007 17:27:35 +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] Extending WGLC for draft-ietf-nsis-ntlp-13.txt References: <987892BF-91A6-4FBE-90DF-0DA38BB4B312@netlab.nec.de> In-Reply-To: X-Enigmail-Version: 0.94.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Status: No X-Spam-Score: -1.4 (-) 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-ATIS-Checksum: v3zoCAcc32ckk X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: nsis X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Martin and all, Martin Stiemerling wrote: > Thanks for all getting their reviews done and/or discuss open items. > > The WGLC is extended for one week, as discussions have started late and > to give further opportunities for reviews. > > Thus, the WGLC runs now until **May 2nd**! What about input from the forthcoming Interop (from May 9th-11th)? Comments from this event should probably also be catched in the WGLC... Regards, Roland _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Apr 27 11:29: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 1HhSOB-0004nF-DF; Fri, 27 Apr 2007 11:29:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhSOB-0004nA-10 for nsis@ietf.org; Fri, 27 Apr 2007 11:29:39 -0400 Received: from rsys001x.roke.co.uk ([193.118.201.108]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhSO6-0003Tn-Ja for nsis@ietf.org; Fri, 27 Apr 2007 11:29:38 -0400 Received: from rsys005a.comm.ad.roke.co.uk ([193.118.193.85]) by rsys001x.roke.co.uk (8.13.1/8.13.1) with ESMTP id l3RFTSbl008922; Fri, 27 Apr 2007 16:29:29 +0100 Received: from ehlaptop ([193.118.192.66]) by rsys005a.comm.ad.roke.co.uk with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Apr 2007 16:29:28 +0100 From: "Robert Hancock" To: "'Roland Bless'" , "'Martin Stiemerling'" References: <987892BF-91A6-4FBE-90DF-0DA38BB4B312@netlab.nec.de> <46321667.2000409@tm.uka.de> Subject: RE: [NSIS] Extending WGLC for draft-ietf-nsis-ntlp-13.txt Date: Fri, 27 Apr 2007 16:29:32 +0100 Message-ID: <01f701c788e0$dad17380$0100c80a@comm.ad.roke.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-reply-to: <46321667.2000409@tm.uka.de> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AceI4KoH5ZLApzMjQzKEKdBlEWEJGgAAAubQ X-OriginalArrivalTime: 27 Apr 2007 15:29:28.0805 (UTC) FILETIME=[D8675150:01C788E0] 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: e1e48a527f609d1be2bc8d8a70eb76cb 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 roland, my plan has been to try to capture issues from the last call period at least in the issue tracker, but not to push to the next stage of the process until the interop is done and feedback incorporated. robert h. > -----Original Message----- > From: Roland Bless [mailto:bless@tm.uka.de] > Sent: 27 April 2007 16:28 > To: Martin Stiemerling > Cc: nsis > Subject: Re: [NSIS] Extending WGLC for draft-ietf-nsis-ntlp-13.txt > > Hi Martin and all, > > Martin Stiemerling wrote: > > Thanks for all getting their reviews done and/or discuss > open items. > > > > The WGLC is extended for one week, as discussions have started late > > and to give further opportunities for reviews. > > > > Thus, the WGLC runs now until **May 2nd**! > > What about input from the forthcoming Interop (from May 9th-11th)? > Comments from this event should probably also be catched in > the WGLC... > > 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 Fri Apr 27 11:45: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 1HhSdw-0005js-4D; Fri, 27 Apr 2007 11:45:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhSdv-0005iY-5J for nsis@ietf.org; Fri, 27 Apr 2007 11:45:55 -0400 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhSdt-00079G-MS for nsis@ietf.org; Fri, 27 Apr 2007 11:45:55 -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 l3RFjhk7002492; Fri, 27 Apr 2007 18:45:51 +0300 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Apr 2007 18:45:47 +0300 Received: from daebe103.NOE.Nokia.com ([10.241.35.24]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Apr 2007 10:45:44 -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 Subject: RE: [NSIS] Extending WGLC for draft-ietf-nsis-ntlp-13.txt Date: Fri, 27 Apr 2007 10:45:44 -0500 Message-ID: <071568CA7B789D4AA170CEF8C9613B4F7E0420@daebe103.NOE.Nokia.com> In-Reply-To: <46321667.2000409@tm.uka.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] Extending WGLC for draft-ietf-nsis-ntlp-13.txt Thread-Index: AceI4ZU5q485HG9sQmqB9jpGOVnhRwAAWfpw References: <987892BF-91A6-4FBE-90DF-0DA38BB4B312@netlab.nec.de> <46321667.2000409@tm.uka.de> From: To: , X-OriginalArrivalTime: 27 Apr 2007 15:45:44.0554 (UTC) FILETIME=[1DFECCA0:01C788E3] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Roland, We will consider input from the Interop, but the last call is for people to look at the current document, after the changes coming from the IESG review, and tell us if they are comfortable with the changes. John=20 >-----Original Message----- >From: ext Roland Bless [mailto:bless@tm.uka.de]=20 >Sent: 27 April, 2007 08:28 >To: Martin Stiemerling >Cc: nsis >Subject: Re: [NSIS] Extending WGLC for draft-ietf-nsis-ntlp-13.txt > >Hi Martin and all, > >Martin Stiemerling wrote: >> Thanks for all getting their reviews done and/or discuss open items.=20 >>=20 >> The WGLC is extended for one week, as discussions have started late=20 >> and to give further opportunities for reviews. >>=20 >> Thus, the WGLC runs now until **May 2nd**! > >What about input from the forthcoming Interop (from May 9th-11th)? >Comments from this event should probably also be catched in the WGLC... > >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 Fri Apr 27 16:30: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 1HhX5N-0004JE-3u; Fri, 27 Apr 2007 16:30:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhX5L-0004Fq-D2 for nsis@ietf.org; Fri, 27 Apr 2007 16:30:31 -0400 Received: from rsys001x.roke.co.uk ([193.118.201.108]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhX5H-0008AK-0K for nsis@ietf.org; Fri, 27 Apr 2007 16:30:31 -0400 Received: from rsys005a.comm.ad.roke.co.uk ([193.118.193.85]) by rsys001x.roke.co.uk (8.13.1/8.13.1) with ESMTP id l3RKUNOh024607; Fri, 27 Apr 2007 21:30:23 +0100 Received: from [127.0.0.1] ([193.118.192.66]) by rsys005a.comm.ad.roke.co.uk with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Apr 2007 21:30:23 +0100 Message-ID: <46325D5E.1070401@roke.co.uk> Date: Fri, 27 Apr 2007 21:30:22 +0100 From: Andrew McDonald User-Agent: IceDove 1.5.0.10 (X11/20070329) MIME-Version: 1.0 To: Christian Dickmann Subject: Re: [NSIS] GIST-aware NAT Traversal References: In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Apr 2007 20:30:23.0164 (UTC) FILETIME=[E1A3DFC0:01C7890A] 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: 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 Christian, Christian Dickmann wrote: > I tried to implement the Gist-aware NAT Traversal described in Section > 7.2 of the GIST draft-v13 and ran into problems. > Processing of Query and Response works fine, but I have a problem with > Confirm and Data messages. [snip scenario] > Should I add an entry to my routing table in the Responding node that > corresponds to MRI instead of MRI'? Did I miss anything else? > The same problem applies to subsequent Data messages and is independent > from D-Mode/C-Mode. Section 7.2.3, penultimate paragraph says: A GIST node receiving such a message MUST use the MRI from the NAT- Traversal object as the key to index its internal routing state; it MAY also store the translated MRI for additional (e.g. diagnostic) information, but this is not used in the GIST processing. The remainder of GIST processing is unchanged. Which, I think, covers your question. However, I can't see a mention of what MRI will be delivered to the NSLP. The translated one is the one you want (since you are the other side of the NAT), but storing this is only a 'MAY'. regards, Andrew _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Apr 27 16:45: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 1HhXJy-0008Aj-Fg; Fri, 27 Apr 2007 16:45:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhXJx-0008Ae-AX for nsis@ietf.org; Fri, 27 Apr 2007 16:45:37 -0400 Received: from difra-computer.de ([81.169.157.103] helo=www.difra-computer.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhXJw-0004wJ-19 for nsis@ietf.org; Fri, 27 Apr 2007 16:45:37 -0400 Received: from win2003.dickmann2003.home (p548A6E2F.dip.t-dialin.net [84.138.110.47]) by www.difra-computer.de (Postfix) with ESMTP id B67513E4030 for ; Fri, 27 Apr 2007 22:35:47 +0200 (CEST) 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] GIST-aware NAT Traversal X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Date: Fri, 27 Apr 2007 22:30:58 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] GIST-aware NAT Traversal Thread-Index: AceJCRdyquvTDrz7T3WxGBo8TUl3FAAAtBvw From: "Christian Dickmann" To: "Andrew McDonald" X-Spam-Score: 0.1 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 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 Andrew, > [snip scenario] > > Should I add an entry to my routing table in the Responding node that > > corresponds to MRI instead of MRI'? Did I miss anything else? > > The same problem applies to subsequent Data messages and is > independent > > from D-Mode/C-Mode. >=20 > Section 7.2.3, penultimate paragraph says: > A GIST node receiving such a message MUST use the MRI from the NAT- > Traversal object as the key to index its internal routing state; it > MAY also store the translated MRI for additional (e.g. diagnostic) > information, but this is not used in the GIST processing. The > remainder of GIST processing is unchanged. > Which, I think, covers your question. If I am not mistaken, the text you quote does not apply to my question. The "such a message" of the quoted text refers to "A NAT will intercept=20 D-mode messages with the normal encapsulation containing such echoed=20 NAT-Traversal objects.", i.e. Response messages. So the "receiving GIST Node" is the querying node.=20 My question however was regarding the behavior of the Responding node. =20 > However, I can't see a mention of what MRI will be delivered to the > NSLP. The translated one is the one you want (since you are the other > side of the NAT), but storing this is only a 'MAY'. Which MRI is delivered to the NSLP is of course an important aspect. But, we should talk about the NSLP once we have sorted out the GIST 3-way handshake. Regards, Christian Dickmann _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Apr 27 16:53:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhXRY-00049e-2U; Fri, 27 Apr 2007 16:53:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhXRW-00049V-7J for nsis@ietf.org; Fri, 27 Apr 2007 16:53:26 -0400 Received: from rsys002x.roke.co.uk ([193.118.201.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhXRV-0007by-Ol for nsis@ietf.org; Fri, 27 Apr 2007 16:53:26 -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 l3RKrBYj006586 for ; Fri, 27 Apr 2007 21:53:11 +0100 Received: from [127.0.0.1] ([193.118.192.66]) by rsys005a.comm.ad.roke.co.uk with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Apr 2007 21:53:11 +0100 Message-ID: <463262B7.7070803@roke.co.uk> Date: Fri, 27 Apr 2007 21:53:11 +0100 From: Andrew McDonald User-Agent: IceDove 1.5.0.10 (X11/20070329) MIME-Version: 1.0 To: NSIS Working Group Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Apr 2007 20:53:11.0883 (UTC) FILETIME=[1175D1B0:01C7890E] 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: 34d35111647d654d033d58d318c0d21a Subject: [NSIS] Responder Cookie construction X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi, In reviewing the draft and attempting to implement 'late state installation' (i.e. wait until you get a Confirm before installing routing state), I found some potential issues in the suggested (non-normative) construction for responder cookies in section 8.5. (Part of this also relates to gist-aware nat-traversal.) For reference, the construction there is: R-Cookie = liveness data + hash (locally known secret, Q-Node NLI, MRI, NSLPID, reception interface, liveness data) There are four particular cases to consider: 1) install routing state when you get the Query 2) wait until you receive the Confirm before installing routing state 3) as case (1), but where there is a NAT-Traversal object in the Query 4) as case (2), but where there is a NAT-Traversal object in the Query The current construction is sufficient for (1), although in that case an implementer may well choose just to generate random cookies and remember them in the responding node. One issue, however, I'm not clear whether the whole "Q-Node NLI" element is relevant. The key parts of the NLI for routing state are the Peer ID and Interface Address. Are there any problems if Routing State Validity Time was to change between Query and Confirm? For (2), it is necessary to store the reception interface in the cookie. The responding node can only discover this from a Q-mode encapsulated message. If not keeping routing state, then it needs to be able to recover this information from the cookie in the confirm. An version of the cookie construction to handle this would be: R-Cookie = liveness data + reception interface + hash (locally known secret, Q-Node NLI, MRI, NSLPID, reception interface, liveness data) For (3) and (4) things get slightly more complicated. Section 7.2.3 says Therefore, a Responding node that wishes to delay state installation until receiving a Confirm must somehow reconstruct the translations when the Confirm arrives. How to do this is an implementation issue; one approach is to carry the translated objects as part of the Responder cookie which is echoed in the Confirm. Indeed, for one of the cookie constructions in Section 8.5 this is automatic. However, section 8.5 does not currently appear to cover this. I'll discuss this from the point of view of case (4), case (3) is simpler since routing state data does not need to be recovered from the cookie. If there is a NAT traversal object present, I think we need to take into account both the translated and untranslated MRIs, since the responding node is expected to construct its routing state based on the untranslated MRI, but the translated MRI is needed by NSLPs. Also, the translated NLI needs to be recovered, since that is what should be used in the routing state (but only the untranslated NLI will be in the Confirm[*]). So, the cookie construction we need for case (4) probably looks like: R-Cookie = liveness data + reception interface + translated MRI + translated NLI + hash (locally known secret, translated Q-Node NLI, untranslated MRI, translated MRI, NSLPID, reception interface, liveness data) In case (3), we don't need the recoverable data outside the hash. I did also wonder whether the SID ought to be incorporated into the hashed data. The SID is part of the routing state to avoid malicious (blind, off-path) modification of the state. Are there any security issues if it was to change between Query and Confirm? If it did, then in the current state of affairs different routing state would be installed in the last state installation case to if the state had been installed when the query was received. (Also, if state had been installed when the Query was received the Confirm would be rejected as not matching that routing state.) The remaining question is, how much of this discussion (and which suggested constructions) needs to be included in 8.5? [*] I've also just noticed that 7.2.2 says that opaque versions of the NLI may be carried in the NAT-Traversal object to aid topology hiding. If the untranslated version appears in the Confirm, how does this help? regards, Andrew _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Apr 27 17:03:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhXat-0001SQ-M1; Fri, 27 Apr 2007 17:03:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhXas-0001SJ-7S for nsis@ietf.org; Fri, 27 Apr 2007 17:03:06 -0400 Received: from rsys002x.roke.co.uk ([193.118.201.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhXar-0002iU-Qu for nsis@ietf.org; Fri, 27 Apr 2007 17:03: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 l3RL2ufl008177; Fri, 27 Apr 2007 22:02:56 +0100 Received: from [127.0.0.1] ([193.118.192.66]) by rsys005a.comm.ad.roke.co.uk with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Apr 2007 22:02:55 +0100 Message-ID: <463264FF.20501@roke.co.uk> Date: Fri, 27 Apr 2007 22:02:55 +0100 From: Andrew McDonald User-Agent: IceDove 1.5.0.10 (X11/20070329) MIME-Version: 1.0 To: Christian Dickmann Subject: Re: [NSIS] GIST-aware NAT Traversal References: In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Apr 2007 21:02:56.0045 (UTC) FILETIME=[6DA5DDD0:01C7890F] 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: 21c69d3cfc2dd19218717dbe1d974352 Cc: nsis X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Christian, Christian Dickmann wrote: >>> Should I add an entry to my routing table in the Responding node > that >>> corresponds to MRI instead of MRI'? Did I miss anything else? >>> The same problem applies to subsequent Data messages and is >> independent >>> from D-Mode/C-Mode. >> Section 7.2.3, penultimate paragraph says: >> A GIST node receiving such a message MUST use the MRI from the NAT- >> Traversal object as the key to index its internal routing state; it >> MAY also store the translated MRI for additional (e.g. diagnostic) >> information, but this is not used in the GIST processing. The >> remainder of GIST processing is unchanged. >> Which, I think, covers your question. > > If I am not mistaken, the text you quote does not apply to my question. > The "such a message" of the quoted text refers to "A NAT will intercept > D-mode messages with the normal encapsulation containing such echoed > NAT-Traversal objects.", i.e. Response messages. So the "receiving GIST > Node" is the querying node. > My question however was regarding the behavior of the Responding node. Ah, yes, you're right (I've even scribbled "Response?" by the phrase "such a message" on my copy). (This means that some details in the other e-mail I've just sent are slightly confused, though the core issues remain.) So, as far as I can see the draft doesn't explicitly say which form of the MRI should form the routing state. I agree that in order to manage the matching to Confirms, the original MRI appears to be necessary. And: >> However, I can't see a mention of what MRI will be delivered to the >> NSLP. The translated one is the one you want (since you are the other >> side of the NAT), but storing this is only a 'MAY'. > > Which MRI is delivered to the NSLP is of course an important aspect. > But, > we should talk about the NSLP once we have sorted out the GIST 3-way > handshake. In order to handle this, the translated MRI appears to be necessary as well. Andrew _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Apr 27 17:58: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 1HhYSY-0007id-9U; Fri, 27 Apr 2007 17:58:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhYSW-0007iN-L5 for nsis@ietf.org; Fri, 27 Apr 2007 17:58:32 -0400 Received: from difra-computer.de ([81.169.157.103] helo=www.difra-computer.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhYSV-0007Cb-80 for nsis@ietf.org; Fri, 27 Apr 2007 17:58:32 -0400 Received: from win2003.dickmann2003.home (p548A6E2F.dip.t-dialin.net [84.138.110.47]) by www.difra-computer.de (Postfix) with ESMTP id 55DE73E4030 for ; Fri, 27 Apr 2007 23:48:42 +0200 (CEST) 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] Responder Cookie construction X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Date: Fri, 27 Apr 2007 23:43:08 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] Responder Cookie construction Thread-Index: AceJDCp8mIKV+xOcT7mQm8ALEjSwcQACjaLw From: "Christian Dickmann" To: "Andrew McDonald" , "NSIS Working Group" X-Spam-Score: 0.1 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Andrew, > There are four particular cases to consider: > 1) install routing state when you get the Query > 2) wait until you receive the Confirm before installing routing state > 3) as case (1), but where there is a NAT-Traversal object in the Query > 4) as case (2), but where there is a NAT-Traversal object in the Query >=20 > The current construction is sufficient for (1), although in that case > an > implementer may well choose just to generate random cookies and > remember > them in the responding node. >=20 > One issue, however, I'm not clear whether the whole "Q-Node NLI" > element > is relevant. The key parts of the NLI for routing state are the Peer ID > and Interface Address. Are there any problems if Routing State Validity > Time was to change between Query and Confirm? >=20 > For (2), it is necessary to store the reception interface in the > cookie. > The responding node can only discover this from a Q-mode encapsulated > message. If not keeping routing state, then it needs to be able to > recover this information from the cookie in the confirm.=20 I do not understand why you can only get the reception interface in case of a Q-Mode encapsulated message (this is what you meant, right?). Is this a theoretical argument or do you just see a problem with actual implementations of TCP/IP? >=20 > For (3) and (4) things get slightly more complicated. Section 7.2.3 > says > Therefore, a Responding node that wishes to delay state installation > until receiving a Confirm must somehow reconstruct the translations > when the Confirm arrives. How to do this is an implementation > issue; > one approach is to carry the translated objects as part of the > Responder cookie which is echoed in the Confirm. Indeed, for one of > the cookie constructions in Section 8.5 this is automatic. > However, section 8.5 does not currently appear to cover this. You seem to be right. I can't see how 8.5 covers this problem. Christian _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Apr 27 18:44:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhZBS-0003AS-LC; Fri, 27 Apr 2007 18:44:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhZBR-0003AN-6K for nsis@ietf.org; Fri, 27 Apr 2007 18:44:57 -0400 Received: from rsys001x.roke.co.uk ([193.118.201.108]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhZBN-0006jS-Uo for nsis@ietf.org; Fri, 27 Apr 2007 18:44:57 -0400 Received: from rsys005a.comm.ad.roke.co.uk ([193.118.193.85]) by rsys001x.roke.co.uk (8.13.1/8.13.1) with ESMTP id l3RMioPR030320; Fri, 27 Apr 2007 23:44:50 +0100 Received: from [127.0.0.1] ([193.118.192.66]) by rsys005a.comm.ad.roke.co.uk with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Apr 2007 23:44:50 +0100 Message-ID: <46327CE2.50407@roke.co.uk> Date: Fri, 27 Apr 2007 23:44:50 +0100 From: Andrew McDonald User-Agent: IceDove 1.5.0.10 (X11/20070329) MIME-Version: 1.0 To: Christian Dickmann Subject: Re: [NSIS] Responder Cookie construction References: In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Apr 2007 22:44:50.0095 (UTC) FILETIME=[A9E7DBF0:01C7891D] 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: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: NSIS Working Group 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 Christian, Christian Dickmann wrote: >> For (2), it is necessary to store the reception interface in the >> cookie. >> The responding node can only discover this from a Q-mode encapsulated >> message. If not keeping routing state, then it needs to be able to >> recover this information from the cookie in the confirm. > > I do not understand why you can only get the reception interface in case > of > a Q-Mode encapsulated message (this is what you meant, right?). Is this > a > theoretical argument or do you just see a problem with actual > implementations of TCP/IP? The Q-Mode encapsulation, at least in the path coupled MRM case, recommends the setting of fields in the IP header in certain ways, including: - source address set to MRI source address (S=0) - setting of DiffServ field to match MRI - setting of flow label to match MRI These /could/ cause the Q-Mode encapsulated packet to be routed differently (and so arrive over a different interface) to a Confirm. Andrew _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Sat Apr 28 04:35: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 1HhiP6-0000zJ-4S; Sat, 28 Apr 2007 04:35:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhiP5-0000xT-1j for nsis@ietf.org; Sat, 28 Apr 2007 04:35:39 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HhiP4-000163-AV for nsis@ietf.org; Sat, 28 Apr 2007 04:35:38 -0400 Received: (qmail 22589 invoked by uid 0); 28 Apr 2007 08:35:37 -0000 Received: from 195.3.113.74 by www096.gmx.net with HTTP; Sat, 28 Apr 2007 10:35:37 +0200 (CEST) Content-Type: text/plain; charset="us-ascii" Date: Sat, 28 Apr 2007 10:35:37 +0200 From: "Hannes Tschofenig" In-Reply-To: <463262B7.7070803@roke.co.uk> Message-ID: <20070428083537.70060@gmx.net> MIME-Version: 1.0 References: <463262B7.7070803@roke.co.uk> Subject: Re: [NSIS] Responder Cookie construction To: Andrew McDonald , nsis@ietf.org X-Authenticated: #29516787 X-Flags: 0001 X-Mailer: WWW-Mail 6100 (Global Message Exchange) X-Priority: 3 X-Provags-ID: V01U2FsdGVkX1/yHNZ8zLXy2PVMp0dIaDNwfSv6IDwtMNNkhXaCgc uEr6cSXEe7/g+W+vYA3OHb4uLe2UINZOWPXw== Content-Transfer-Encoding: 7bit X-GMX-UID: bjEAcjxTTXsuUIAHo2U5FstCRzdyMoMK X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org The aspect of Cookie construction in case of NAT traversal is addressed in http://tools.ietf.org/html/draft-pashalidis-nsis-gimps-nattraversal-04 -------- Original-Nachricht -------- Datum: Fri, 27 Apr 2007 21:53:11 +0100 Von: Andrew McDonald An: NSIS Working Group Betreff: [NSIS] Responder Cookie construction > Hi, > > In reviewing the draft and attempting to implement 'late state > installation' (i.e. wait until you get a Confirm before installing > routing state), I found some potential issues in the suggested > (non-normative) construction for responder cookies in section 8.5. > > (Part of this also relates to gist-aware nat-traversal.) > > For reference, the construction there is: > R-Cookie = liveness data + hash (locally known secret, > Q-Node NLI, MRI, NSLPID, > reception interface, > liveness data) > > There are four particular cases to consider: > 1) install routing state when you get the Query > 2) wait until you receive the Confirm before installing routing state > 3) as case (1), but where there is a NAT-Traversal object in the Query > 4) as case (2), but where there is a NAT-Traversal object in the Query > > The current construction is sufficient for (1), although in that case an > implementer may well choose just to generate random cookies and remember > them in the responding node. > > One issue, however, I'm not clear whether the whole "Q-Node NLI" element > is relevant. The key parts of the NLI for routing state are the Peer ID > and Interface Address. Are there any problems if Routing State Validity > Time was to change between Query and Confirm? > > For (2), it is necessary to store the reception interface in the cookie. > The responding node can only discover this from a Q-mode encapsulated > message. If not keeping routing state, then it needs to be able to > recover this information from the cookie in the confirm. An version of > the cookie construction to handle this would be: > R-Cookie = liveness data + reception interface + > hash (locally known secret, > Q-Node NLI, MRI, NSLPID, > reception interface, > liveness data) > > For (3) and (4) things get slightly more complicated. Section 7.2.3 says > Therefore, a Responding node that wishes to delay state installation > until receiving a Confirm must somehow reconstruct the translations > when the Confirm arrives. How to do this is an implementation issue; > one approach is to carry the translated objects as part of the > Responder cookie which is echoed in the Confirm. Indeed, for one of > the cookie constructions in Section 8.5 this is automatic. > However, section 8.5 does not currently appear to cover this. > > I'll discuss this from the point of view of case (4), case (3) is > simpler since routing state data does not need to be recovered from the > cookie. > > If there is a NAT traversal object present, I think we need to take into > account both the translated and untranslated MRIs, since the responding > node is expected to construct its routing state based on the > untranslated MRI, but the translated MRI is needed by NSLPs. > > Also, the translated NLI needs to be recovered, since that is what > should be used in the routing state (but only the untranslated NLI will > be in the Confirm[*]). > > So, the cookie construction we need for case (4) probably looks like: > R-Cookie = liveness data + reception interface + > translated MRI + translated NLI + > hash (locally known secret, > translated Q-Node NLI, > untranslated MRI, > translated MRI, > NSLPID, > reception interface, > liveness data) > > In case (3), we don't need the recoverable data outside the hash. > > I did also wonder whether the SID ought to be incorporated into the > hashed data. The SID is part of the routing state to avoid malicious > (blind, off-path) modification of the state. Are there any security > issues if it was to change between Query and Confirm? If it did, then in > the current state of affairs different routing state would be installed > in the last state installation case to if the state had been installed > when the query was received. (Also, if state had been installed when the > Query was received the Confirm would be rejected as not matching that > routing state.) > > The remaining question is, how much of this discussion (and which > suggested constructions) needs to be included in 8.5? > > [*] I've also just noticed that 7.2.2 says that opaque versions of the > NLI may be carried in the NAT-Traversal object to aid topology hiding. > If the untranslated version appears in the Confirm, how does this help? > > regards, > Andrew > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis