From manet-bounces@ietf.org Sun Dec 02 13:21: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 1IytRK-00069i-PT; Sun, 02 Dec 2007 13:21:14 -0500 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IytRH-0005tf-KU for manet-confirm+ok@megatron.ietf.org; Sun, 02 Dec 2007 13:21:12 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IytRH-0005tR-9Y for manet@ietf.org; Sun, 02 Dec 2007 13:21:11 -0500 Received: from ug-out-1314.google.com ([66.249.92.169]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IytRG-0002ME-Vh for manet@ietf.org; Sun, 02 Dec 2007 13:21:11 -0500 Received: by ug-out-1314.google.com with SMTP id u2so3579042uge for ; Sun, 02 Dec 2007 10:21:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; bh=Gr3N247v2p/FMPxRo+GSJH9v+La1QXiBuWBeCaMBSRA=; b=Y/8aoMjo/J5eioHKAk5itRE3z/JlG2x06/763X29NTA9+4dY1Y4FSv7uxTg3sC4HAtdCbNmPQyBN/k/iVCIRzizYLbpjgagn4qXqnLy9b15Lya0+KKeMq39qJgZxXTGuy4wjNArLlI2g5WmQGDJVYXf7Gl3PpFAFMN+BvwJT0m8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=received:message-id:date:from:to:subject:mime-version:content-type; b=fZ5yLrf2fWwDUVIHbQSWtaY67yqXiRawwRb2EStAyg9MQC9BHvoIKo8eeNIWXnWOo4nwpEvDOpytC+k1CJiSe3iDsz6lN++5wdEDIuoSWl3OZOgLHWGllVdd/oBp2UiEJWu4RC/BswXTXRhTDku0D8Q5CscjxxWT9Rlm5TvKc8Y= Received: by 10.67.103.12 with SMTP id f12mr2683061ugm.1196619670273; Sun, 02 Dec 2007 10:21:10 -0800 (PST) Received: by 10.67.10.14 with HTTP; Sun, 2 Dec 2007 10:21:10 -0800 (PST) Message-ID: <5abf39e60712021021m32513119q2ed00e592ddca56e@mail.gmail.com> Date: Sun, 2 Dec 2007 23:51:10 +0530 From: "Pushpita Chatterjee" To: manet@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Subject: [manet] establishing initial trust without using cryptography X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0697596876==" Errors-To: manet-bounces@ietf.org --===============0697596876== Content-Type: multipart/alternative; boundary="----=_Part_6732_2072098.1196619670274" ------=_Part_6732_2072098.1196619670274 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Dear All, Can anybody help me to establish initial trust between nodes of a MANET without using cryptographic primitives like key exchange etc? Regards Pushpita ------=_Part_6732_2072098.1196619670274 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Dear All,
Can anybody help me to establish initial trust between nodes of a MANET without using cryptographic primitives like key exchange etc?
Regards
Pushpita 
------=_Part_6732_2072098.1196619670274-- --===============0697596876== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet --===============0697596876==-- From manet-bounces@ietf.org Mon Dec 03 19:36: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 1IzLlJ-00008f-9y; Mon, 03 Dec 2007 19:35:45 -0500 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IzLlI-000078-HR for manet-confirm+ok@megatron.ietf.org; Mon, 03 Dec 2007 19:35:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzLlI-00006Y-79 for manet@ietf.org; Mon, 03 Dec 2007 19:35:44 -0500 Received: from an-out-0708.google.com ([209.85.132.248]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzLlH-0005OO-TF for manet@ietf.org; Mon, 03 Dec 2007 19:35:44 -0500 Received: by an-out-0708.google.com with SMTP id d11so889732and for ; Mon, 03 Dec 2007 16:35:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:mime-version:content-transfer-encoding:message-id:content-type:to:from:subject:date:x-mailer; bh=q2D9FbyJ69e7b6+dqiI7vBpXdnQiJHcXajKJ4ixZrvQ=; b=PYDXeunIQL7ZwhllL/YdLNrh1vh1/QASCjzDOhIlEccXefSi2FixSNjeuRHkJy8CvH6eGVijBpVLdzKN+aSt6nCzX8074VN3t0JhtY/HsMO2w9kFDRPMZwOFrJuhjDunLKmwT5pTTpwBlmCKZJbzkJFnbMeBhvz7V2WGzJE8Ugg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=received:mime-version:content-transfer-encoding:message-id:content-type:to:from:subject:date:x-mailer; b=InBk2pi5yfOKRForYkq1VZoS0m7gTn2U1QQYOV7C6EwtVYWPVTi9h0hBnF8b9PyP+sjMNYTf2Hl+dID8/Yl91OSbmetLH5aJZMtzEnDIK4yk7JC0kAOXEpyJFLDq/KFKQz6GGB7F9DtKNgg/+wfyuxdJ1tdDWNE8EowiRgbWQLY= Received: by 10.100.228.17 with SMTP id a17mr77984anh.1196728543613; Mon, 03 Dec 2007 16:35:43 -0800 (PST) Received: from ?130.129.69.124? ( [130.129.69.124]) by mx.google.com with ESMTPS id f55sm206825pyh.2007.12.03.16.35.41 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 03 Dec 2007 16:35:42 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: <15AFCB60-7FE0-48BC-9A09-71CB9AF37F5F@gmail.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: manet From: Ian Chakeres Date: Tue, 4 Dec 2007 06:05:34 +0530 X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Subject: [manet] Some more on MANET Identifier (ID) TLV motivation X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Chris prompted me to describe the motivation behind this Internet Draft (I-D). draft-chakeres-manet-manetid-00.txt The I-D simply defines TLV structures for carrying an identifier (ID) value. The motivation behind creating and carrying this ID is to administratively identify routing control message/information and to enable protocols to restrict dissemination/processing. Let me describe two well-known use cases that would utilize this type of feature. 1) multiple topology routing 2) administratively controlled boundaries I'm very interested in discussing this more, and I look forward to talking about it Wednesday during our meeting. Thanks. Ian _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Mon Dec 03 19:48: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 1IzLxO-0005Kk-86; Mon, 03 Dec 2007 19:48:14 -0500 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IzLxL-00055c-Oe for manet-confirm+ok@megatron.ietf.org; Mon, 03 Dec 2007 19:48:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzLxL-00052y-Cn for manet@ietf.org; Mon, 03 Dec 2007 19:48:11 -0500 Received: from an-out-0708.google.com ([209.85.132.250]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzLxJ-0006tn-9a for manet@ietf.org; Mon, 03 Dec 2007 19:48:11 -0500 Received: by an-out-0708.google.com with SMTP id d11so891190and for ; Mon, 03 Dec 2007 16:48:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:mime-version:content-type:message-id:cc:content-transfer-encoding:from:subject:date:to:x-mailer; bh=QOYMUC3jr3pz6dBVxypu7mE6Ww4Kkx+i35fHpXedpEA=; b=UhqVss8agiHShC3ZoYeDZyurtLMo55bbef6VZp08tZF4L0kV8V9ofakRHvIKy4rXCMNj5w6uQrY5EhMbPJDHYFxdYGWUtSJZGdGRZFpOOUdJoq1muup2kuS0sW2zLwIo2c7XgrnyTKVhtuhsxv7SQI4haLOcXS7JnGCqOJPCLt0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=received:mime-version:content-type:message-id:cc:content-transfer-encoding:from:subject:date:to:x-mailer; b=jWmfR4EYyBJo06dBoGTZ9ScgBczT0Oiux6/eAMYHLqviID59ltN5zc1vGDLbc9xRoX/zNYye7mEeALrE+Mtb6iHfPNKOyKdQbYJ9X2YGaDLRnC/zhB1AYs6p/m7NDgZQl4J+nAvo3aFBP6T+ftVy9ZJaGYkE3JzB+/Zsjfphh40= Received: by 10.100.253.12 with SMTP id a12mr36448ani.1196729288997; Mon, 03 Dec 2007 16:48:08 -0800 (PST) Received: from ?130.129.69.124? ( [130.129.69.124]) by mx.google.com with ESMTPS id a22sm271370pye.2007.12.03.16.48.05 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 03 Dec 2007 16:48:07 -0800 (PST) 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: Ian Chakeres Date: Tue, 4 Dec 2007 06:17:55 +0530 To: Ross Callon , Dave Ward , iesg-secretary@ietf.org, manet X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: Christopher Dearlove , Thomas Heide Clausen Subject: [manet] Request to publish draft-ietf-manet-timetlv-04.txt - writeup included X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org I would like to request that draft-ietf-manet-timvetlv-04.txt be published. I am the shepherding WG chair. ===WRITE-UP=== 1. Have the chairs personally reviewed this version of the Internet Draft (I-D), and in particular, do they believe this I-D is ready to forward to the IESG for publication? Yes the chairs have reviewed this document, and we believe that it is ready to go to the IETF for publication. 2. Has the document had adequate review from both key WG members and key non-WG members? Do you have any concerns about the depth or breadth of the reviews that have been performed? Yes the I-D has been adequately reviewed. 3. Do you have concerns that the document needs more review from a particular (broader) perspective (e.g., security, operational complexity, someone familiar with AAA, etc.)? We do not have any particular concerns regarding additional required reviews for this document. 4. Do you have any specific concerns/issues with this document that you believe the ADs and/or IESG should be aware of? For example, perhaps you are uncomfortable with certain parts of the document, or have concerns whether there really is a need for it. In any event, if your issues have been discussed in the WG and the WG has indicated it that it still wishes to advance the document, detail those concerns in the write-up. No contentious issues were raised during WG discussion on this document. 5. How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? The three main WG protocol documents contain a reference to this I-D. That is, NHDP, DYMO, and OLSRv2 all utilize the TLV format and types specified in this document. 6. Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email to the Responsible Area Director. There was no WG conflict regarding this document. 7. Have the chairs verified that the document adheres to all of the I-D Checklist items ? Yes the document adheres to the I-D checklist items. 8. Is the document split into normative and informative references? Are there normative references to I-Ds, where the I-Ds are not also ready for advancement or are otherwise in an unclear state? (note here that the RFC editor will not publish an RFC with normative references to I-Ds, it will delay publication until all such I-Ds are also ready for publication as RFCs.) Yes the references are split into normative and informative references. 9. What is the intended status of the document? (e.g., Proposed Standard, Informational?) Proposed Standard. 10. For Standards Track and BCP documents, the IESG approval announcement includes a write-up section with the following sections: * Technical Summary This document specifies the syntax of a PacketBB (publication requested) TLV for representing time. It also defines two TLV types that conform to the TimeTLV representation. * Working Group Summary This document contains information that was originally in OLSRv2. It was pulled out and generalized, since it is applicable to many MANET WG protocols. It is an integral component of NHDP, OLSRv2, and DYMO. * Protocol Quality The TimeTLV format was architected to represent a wide range of time values. The necessity and flexibility of the format is demonstrated by the two TimeTLV type instances specified in this document. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Mon Dec 03 20:49: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 1IzMuX-0001zD-Eq; Mon, 03 Dec 2007 20:49:21 -0500 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IzMuW-0001yu-59 for manet-confirm+ok@megatron.ietf.org; Mon, 03 Dec 2007 20:49:20 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzMuV-0001yl-Qd for manet@ietf.org; Mon, 03 Dec 2007 20:49:19 -0500 Received: from py-out-1112.google.com ([64.233.166.183]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IzMuV-0006uu-Cw for manet@ietf.org; Mon, 03 Dec 2007 20:49:19 -0500 Received: by py-out-1112.google.com with SMTP id d32so13360983pye for ; Mon, 03 Dec 2007 17:49:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:mime-version:content-type:message-id:cc:content-transfer-encoding:from:subject:date:to:x-mailer; bh=+flaLQamwIVx4BCBQyqddgyHDSU2nEiJdrT1yk1cK0c=; b=U4lnIYY/KdgY0StFQuRVHfvMai1goCKLC4UXfTSPnYRNVGxzczg9sd9Wa058NiKoqCbKNfUuRPbEgzWoISmpCxc22B2FuMHzmrqtaQfdXR0Hvmdodgtz9bRipJoIGLQLwe8jLgXSg5Tsqna7Oj2/jgqDSV3VFmobYmwCRAdvCKA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=received:mime-version:content-type:message-id:cc:content-transfer-encoding:from:subject:date:to:x-mailer; b=qBhmYwVA6s7EsiNGmH7WIuJTvakSD5cPwHLbuWzQ9VYfWKIbwkY7lcNgAzmhTPoxtJ5ZAWWeNfK1yCChjF0ENMGIAwhy2k4hCTNtf/FMMprg1iQnXW2takp7s6Qge6Yq5y1p1fGa9om8tzPE+qVNj1CZWg1D+MbUVlos0Gmc2co= Received: by 10.35.102.1 with SMTP id e1mr2014942pym.1196732958831; Mon, 03 Dec 2007 17:49:18 -0800 (PST) Received: from ?130.129.96.131? ( [130.129.96.131]) by mx.google.com with ESMTPS id u2sm987540pyb.2007.12.03.17.49.16 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 03 Dec 2007 17:49:17 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <9A7C8F91-1354-40DE-AFD3-55529FE41F82@gmail.com> Content-Transfer-Encoding: 7bit From: Ian Chakeres Date: Tue, 4 Dec 2007 07:19:07 +0530 To: manet X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: Subject: [manet] MANET WG Meeting Agenda for Dec 5th 2007 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Mobile Ad hoc Networks (MANET) Agenda Meeting : IETF70 Wed Dec 5th 9am Location : Salon 3 Chairs : Ian Chakeres ian.chakeres@gmail.com Joseph Macker joseph.macker@nrl.navy.mil Jabber : manet@jabber.ietf.org Audiocast: http://videolab.uoregon.edu/events/ietf/ URL : http://www.ietf.org/html.charters/manet-charter.html http://www.ianchak.com/manet http://tools.ietf.org/wg/manet/ ========================================================= AGENDA o Administriva - Mailing list: manet@ietf.org - Scribe(s) - Blue Sheets - State your name at the microphone - IPR - RFC3979 o Agenda bashing o WG Progress o SMF Discussion - draft-ietf-manet-smf-06.txt o MANET Neighborhood Discovery Protocol Discussion - draft-ietf-manet-nhdp-04.txt o DYMO Discussion - draft-ietf-manet-dymo-11.txt o OLSRv2 Discussion - draft-ietf-manet-olsrv2-04.txt o Metric(s) Discussion - draft-dean-manet-metriclv-00.txt - draft-dearlove-olsrv2-metrics-00.txt o MANET ID Discussion - draft-chakeres-manet-manetid-00.txt o Loop Detection Discussion - draft-mase-manet-loopdetect-00.txt o Open Discussion, Related Work & Announcements You can find the agenda and presentation materials at http://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=70 IPR reminder - RFC 3979 https://datatracker.ietf.org/public/ipr_disclosure.cgi If you know about IPR relevant to the technology and you are contributing, you have to speak up Audiocast http://videolab.uoregon.edu/events/ietf/ Jabber The new jabber server is located at manet@jabber.ietf.org and is currently accessible. For those who are interested, please visit the above location to join any of the available chat rooms. Sergeant-at-arms Many thanks to Ratul Mukhopadhyay for protecting the MANET mailing list from non IETF MANET WG related discussions. Please note: All traffic within the defined rooms (except "noc") is being logged and updated every 5 minutes to the ietf.org website. To view the log directories, point your browser to http://www.ietf.org/meetings/ietf-logs/. If you click on a room directory, you will see one or more files named "YYYY-MM-DD.html", e.g. 2006-03-14.html. If you click on one of those files, you will see all logged traffic for that day. Please visit the IETF Text Conferencing Web page (http://www.ietf.org/meetings/text_conf.html) for more information. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Tue Dec 04 13:49: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 1IzcpX-0007dw-Ul; Tue, 04 Dec 2007 13:49:15 -0500 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IzcpW-0007dQ-9t for manet-confirm+ok@megatron.ietf.org; Tue, 04 Dec 2007 13:49:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzcpV-0007dI-WB for manet@ietf.org; Tue, 04 Dec 2007 13:49:14 -0500 Received: from smtp.nokia.com ([192.100.122.230] helo=mgw-mx03.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzcpV-0000Je-El for manet@ietf.org; Tue, 04 Dec 2007 13:49:13 -0500 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id lB4ImdkW024866 for ; Tue, 4 Dec 2007 20:49:11 +0200 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 4 Dec 2007 20:48:15 +0200 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 4 Dec 2007 12:48:09 -0600 Received: from [10.243.4.251] ([10.243.4.251]) by daebe101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 4 Dec 2007 12:48:09 -0600 Message-ID: <4755A0E6.4010900@nokia.com> Date: Tue, 04 Dec 2007 10:48:06 -0800 From: "Charles E. Perkins" User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: manet@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Dec 2007 18:48:09.0588 (UTC) FILETIME=[37093340:01C836A6] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Subject: [manet] Editorial comment on draft-ietf-manet-packetbb-11.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Hello, From my perspective, the revised text in the packetBB document seems to be misleading. The relevant text is: > If the appropriate semantics bit (pnouniord for a packet TLV block, > mnouniord for a message TLV block or an address TLV block) is clear > ('0'), then the following constraints MUST be respected. These bits > MUST always be clear ('0') unless a protocol using this specification > defines otherwise. Protocols SHOULD only define use of these bits > when necessary, and then MUST indicate what constraints do apply if > each of the indicated bits is set ('1'); each of these constraints > SHOULD be retained unless otherwise necessary. > This indicates that using unordered TLVs is disfavored. However, given the substance of discussion during the previous several months on this point, I think it is very surprising that such a strong recommendation is made to use ordered TLVs. The arguments in favor have been reviewed and mostly found wanting, except for the occasional scenario when it is important for a receiver to be able to prematurely abort the parsing operations for incoming TLVs. I would like to see some wording inserted into this text making this clear. Here is one possible replacement for the above text: For systems in which it is important for the receiver to be able to prematurely discontinue the parsing of incoming sequences of TLV blocks, the appropriate semantics bits (pnouniord for a packet TLV block, mnouniord for a message TLV block or an address TLV block) should be cleared. In this case, when one of these semantics bits is clear ('0'), then the following constraints MUST be respected. Note that there is NO need to specify anything about what "other" constraints need to be specified by protocol documents. I also believe that the sense of the pnouniord and mnouniord semantics bits should be reversed, with appropriate renaming to be called "puniord and muniord". In fact, maybe the names should be "pord" and "mord", since I thought the ordering was monotonically increasing, not guaranteeing uniqueness. Regards, Charlie P. PS. I thought the time allowed for comments on this draft was remarkably brief. Should I forward these comments to the IESG? _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Tue Dec 04 19:00: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 1IzhgO-0004cF-QS; Tue, 04 Dec 2007 19:00:08 -0500 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IzhgJ-0004Mf-Id for manet-confirm+ok@megatron.ietf.org; Tue, 04 Dec 2007 19:00:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzhgJ-0004Lr-4c; Tue, 04 Dec 2007 19:00:03 -0500 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzhgI-0000pC-On; Tue, 04 Dec 2007 19:00:03 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 9A067327BD; Wed, 5 Dec 2007 00:00:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IzhgI-0007nL-DC; Tue, 04 Dec 2007 19:00:02 -0500 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, 04 Dec 2007 19:00:02 -0500 X-Spam-Score: -1.4 (-) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: manet@ietf.org Subject: [manet] I-D Action:draft-ietf-manet-jitter-04.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-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 Mobile Ad-hoc Networks Working Group of the IETF. Title : Jitter considerations in Mobile Ad Hoc Networks (MANETs) Author(s) : T. Clausen, et al. Filename : draft-ietf-manet-jitter-04.txt Pages : 18 Date : 2007-12-04 This document provides recommendations for jittering (randomly modifying timing) of control traffic transmissions in Mobile Ad hoc NETwork (MANET) routing protocols to reduce the probability of transmission collisions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-manet-jitter-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-manet-jitter-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-manet-jitter-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-12-04185922.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-manet-jitter-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-manet-jitter-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-12-04185922.I-D\@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet --NextPart-- From manet-bounces@ietf.org Tue Dec 04 19:00: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 1IzhgN-0004Xe-1G; Tue, 04 Dec 2007 19:00:07 -0500 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IzhgJ-0004Mg-Ic for manet-confirm+ok@megatron.ietf.org; Tue, 04 Dec 2007 19:00:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzhgI-0004KJ-Ud; Tue, 04 Dec 2007 19:00:02 -0500 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzhgI-0000p9-Ik; Tue, 04 Dec 2007 19:00:02 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 74C3C26E2A; Wed, 5 Dec 2007 00:00:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IzhgI-0007mN-BM; Tue, 04 Dec 2007 19:00:02 -0500 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, 04 Dec 2007 19:00:02 -0500 X-Spam-Score: -1.4 (-) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: manet@ietf.org Subject: [manet] I-D Action:draft-ietf-manet-jitter-04.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-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 Mobile Ad-hoc Networks Working Group of the IETF. Title : Jitter considerations in Mobile Ad Hoc Networks (MANETs) Author(s) : T. Clausen, et al. Filename : draft-ietf-manet-jitter-04.txt Pages : 18 Date : 2007-12-04 This document provides recommendations for jittering (randomly modifying timing) of control traffic transmissions in Mobile Ad hoc NETwork (MANET) routing protocols to reduce the probability of transmission collisions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-manet-jitter-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-manet-jitter-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-manet-jitter-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-12-04185833.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-manet-jitter-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-manet-jitter-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-12-04185833.I-D\@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet --NextPart-- From manet-bounces@ietf.org Thu Dec 06 03:10:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0BoG-0006yx-4b; Thu, 06 Dec 2007 03:10:16 -0500 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1J0BoD-0006yX-47 for manet-confirm+ok@megatron.ietf.org; Thu, 06 Dec 2007 03:10:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0Bo6-0006wz-SQ; Thu, 06 Dec 2007 03:10:06 -0500 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J0Bo2-0000so-6a; Thu, 06 Dec 2007 03:10:06 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 2B1D432896; Thu, 6 Dec 2007 08:10:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1J0Bo2-00037X-2k; Thu, 06 Dec 2007 03:10:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 06 Dec 2007 03:10:02 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: manet@ietf.org Subject: [manet] I-D Action:draft-ietf-manet-nhdp-05.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-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 Mobile Ad-hoc Networks Working Group of the IETF. Title : MANET Neighborhood Discovery Protocol (NHDP) Author(s) : T. Clausen, et al. Filename : draft-ietf-manet-nhdp-05.txt Pages : 63 Date : 2007-12-06 This document describes a 1-hop and symmetric 2-hop neighborhood discovery protocol (NHDP) for mobile ad hoc networks (MANETs). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-manet-nhdp-05.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-manet-nhdp-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-manet-nhdp-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-12-06030715.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-manet-nhdp-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-manet-nhdp-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-12-06030715.I-D\@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet --NextPart-- From manet-bounces@ietf.org Fri Dec 07 10:23:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0f2z-00045a-Lg; Fri, 07 Dec 2007 10:23:25 -0500 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1J0f2x-000446-SR for manet-confirm+ok@megatron.ietf.org; Fri, 07 Dec 2007 10:23:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0f2x-00043v-IV for manet@ietf.org; Fri, 07 Dec 2007 10:23:23 -0500 Received: from ovs01.rockwellcollins.com ([205.175.225.231] helo=vs01.rockwellcollins.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J0f2v-0002Or-AR for manet@ietf.org; Fri, 07 Dec 2007 10:23:23 -0500 Received: from vs01.rockwellcollins.com (localhost [127.0.0.1]) by localhost.rockwellcollins.com (Postfix) with ESMTP id 0F1C731BD3 for ; Fri, 7 Dec 2007 09:23:19 -0600 (CST) Received: from crnotes2.rockwellcollins.com (crnotes2.rockwellcollins.com [131.198.64.109]) by vs01.rockwellcollins.com (Postfix) with ESMTP id D9FE431BC2 for ; Fri, 7 Dec 2007 09:23:16 -0600 (CST) In-Reply-To: To: manet@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.2 June 01, 2004 From: jasteven@rockwellcollins.com Message-ID: Date: Fri, 7 Dec 2007 09:22:26 -0600 X-MIMETrack: Serialize by Router on CollinsCRSMTP02/CedarRapids/RockwellCollins(Release 7.0.2FP2 HF193|August 16, 2007) at 12/07/2007 09:23:16 AM, Serialize complete at 12/07/2007 09:23:16 AM X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Subject: [manet] draft-ietf-manet-nhdp-05.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1433241772==" Errors-To: manet-bounces@ietf.org This is a multipart message in MIME format. --===============1433241772== Content-Type: multipart/alternative; boundary="=_alternative 00536962862573AA_=" This is a multipart message in MIME format. --=_alternative 00536962862573AA_= Content-Type: text/plain; charset="US-ASCII" Here are comments on the Dec 6, 2007 MANET Neighborhood Discovery Protocol (NHDP), draft-ietf-manet-nhdp-05 1. Page 12, 4th major bullet. Error in sentence "Additional information may be added by a protocol using thsi protocol using the TLV mechanisms described in [1]." 2. Page 16, Section 5.1.3. What does "not updated" mean in following sentence: "If link quality is not updated, then INITIAL_QUALITY >= HYST_ACCEPT." Does it mean the same as "deployment without link quality" in section 14.1? Or can it also include any cases of deployment with link quality, e.g. the rest of section 14? 3. Page 23, Section 8.1 says "A node's Neighbor Set records all interface addresses of each 1-hop neighbor." and Page 28, Section 10.1.1 says "All addresses in a node's Local Interface Set (i.e. in any I_local_iface_addr_list) MUST be included in the address blocks in all generated HELLO messages with the following exception." What about the case of a Node that happens to be a Border Router between multiple Autonomous Systems (ASs)? I.e. this node has MANET interfaces on one AS and non-MANET interfaces to another AS? Would such a node still report its interfaces to the different AS per Section 10.1.1? 4. I noticed that the bullet character changes depending upon the level of indentation. E.g., o is used at first indentation, * is used at the second, + is used at the third, and - is used at the fourth (see page 40 for all 4 levels used on one page). Just curious, is this an IETF standard convention? Jim Stevens --=_alternative 00536962862573AA_= Content-Type: text/html; charset="US-ASCII"
Here are comments on the Dec 6, 2007 MANET Neighborhood Discovery Protocol (NHDP), draft-ietf-manet-nhdp-05
1.  Page 12, 4th major bullet.  Error in sentence "Additional information may be added by a protocol using thsi protocol using the TLV mechanisms described in [1]."

2.  Page 16,  Section 5.1.3.  What does "not updated" mean in following sentence: "If link quality is not updated, then INITIAL_QUALITY >= HYST_ACCEPT."  Does it mean the same as "deployment without link quality" in section 14.1?  Or can it also include any cases of deployment with link quality, e.g. the rest of section 14?

3.  Page 23, Section 8.1 says "A node's Neighbor Set records all interface addresses of each 1-hop neighbor." and Page 28, Section 10.1.1 says "All addresses in a node's Local Interface Set (i.e. in any I_local_iface_addr_list) MUST be included in the address blocks in all generated HELLO messages with the following exception."   What about the case of a Node that happens to be a Border Router between multiple Autonomous Systems (ASs)?  I.e. this node has MANET interfaces on one AS and non-MANET interfaces to another AS?  Would such a node still report its interfaces to the different AS per Section 10.1.1?

4.  I noticed that the bullet character changes depending upon the level of indentation.  E.g., o is used at first indentation, * is used at the second, + is used at the third, and - is used at the fourth (see page 40 for all 4 levels used on one page).  Just curious, is this an IETF standard convention?

Jim Stevens
--=_alternative 00536962862573AA_=-- --===============1433241772== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet --===============1433241772==-- From manet-bounces@ietf.org Mon Dec 10 17:09:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1qoD-0007FP-L5; Mon, 10 Dec 2007 17:09:05 -0500 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1J1qoB-0007F3-SH for manet-confirm+ok@megatron.ietf.org; Mon, 10 Dec 2007 17:09:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1qoB-0007Ef-Ek; Mon, 10 Dec 2007 17:09:03 -0500 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J1qoB-0005e3-7a; Mon, 10 Dec 2007 17:09:03 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 0CA7B2AB68; Mon, 10 Dec 2007 22:09:03 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1J1qoA-0002B9-Uw; Mon, 10 Dec 2007 17:09:02 -0500 X-test-idtracker: no From: The IESG To: IETF-Announce Message-Id: Date: Mon, 10 Dec 2007 17:09:02 -0500 X-Spam-Score: -1.4 (-) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: manet chair , manet mailing list , Internet Architecture Board , RFC Editor Subject: [manet] Document Action: 'Jitter considerations in Mobile Ad Hoc Networks (MANETs)' to Informational RFC X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org The IESG has approved the following document: - 'Jitter considerations in Mobile Ad Hoc Networks (MANETs) ' as an Informational RFC This document is the product of the Mobile Ad-hoc Networks Working Group. The IESG contact persons are Ross Callon and David Ward. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-manet-jitter-04.txt Technical Summary This informational document provides recommendations for jittering (randomly modifying timing) of control traffic transmissions in Mobile Ad hoc NETwork (MANET) routing protocols to reduce the probability of transmission collisions. Working Group Summary No dissent reported. Strong WG agreement is reported (see PROTO writeup). Several other WG documents contain references to this ID. Protocol Quality Ross Callon has reviewed this document for the IESG. Jitter is generally used in all routing protocol implementations that I know of. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Tue Dec 11 10:35:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J278I-00086z-BX; Tue, 11 Dec 2007 10:34:54 -0500 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1J278G-00084c-LK for manet-confirm+ok@megatron.ietf.org; Tue, 11 Dec 2007 10:34:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J278G-00084S-BQ for manet@ietf.org; Tue, 11 Dec 2007 10:34:52 -0500 Received: from s2.itd.nrl.navy.mil ([132.250.83.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J278E-0002d9-75 for manet@ietf.org; Tue, 11 Dec 2007 10:34:52 -0500 Received: from smtp.itd.nrl.navy.mil (smtp.itd.nrl.navy.mil [132.250.86.3]) by s2.itd.nrl.navy.mil (8.13.8+Sun/8.12.8) with SMTP id lBBFYl7G007987; Tue, 11 Dec 2007 10:34:47 -0500 (EST) Received: (from linkwray [132.250.217.206]) by smtp.itd.nrl.navy.mil (SMSSMTP 4.1.16.48) with SMTP id M2007121110344605726 ; Tue, 11 Dec 2007 10:34:46 -0500 From: "Joe Macker" To: "'Bruce M Simpson'" , References: <474E04E9.4070506@incunabulum.net> In-Reply-To: <474E04E9.4070506@incunabulum.net> Subject: RE: [manet] Comments on draft-ietf-manet-smf-06 Date: Tue, 11 Dec 2007 10:35:22 -0800 Message-ID: <9F7D1A2D657D408E8B967F80EC999A8A@linkwray> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcgyHS2Re0yA54+RQVWHdLp2B6yq8AD3rx/w X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6000.16545 X-Spam-Score: 0.4 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: manet@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Thanks for your comments Bruce. A couple quick responses. - Present draft can deal with randomized ids, unlike previous one. ID sequencing has some security flaws that we now point out, flaws beyond fingerprinting. - I am not against another draft discussing how the approach could be adopted in an encapsulation mode, but I am presently against adding encapsulation to this draft (borrowing DPD and forwarding optimizations). I feel an EXP allows for that evolution to continue. -Joe -----Original Message----- From: Bruce M Simpson [mailto:bms@incunabulum.net] Sent: Wednesday, November 28, 2007 4:17 PM To: macker@itd.nrl.navy.mil Cc: manet@ietf.org Subject: [manet] Comments on draft-ietf-manet-smf-06 I am a bit disappointed that the current I-D for MANET SMF has no provision for the encapsulation of MANET SMF datagrams in IPv4. My points: * ip_id is only 16 bits wide, making its usefulness limited in large MANET topologies. * Both BSD and Linux may be configured to randomize the ip_id field as a defensive measure against IP host fingerprinting. * Choosing ip_id as a tag for the histogram based duplicate packet detection requires that NAT routers on the path examine ip_id, in addition to being examined by any software multicast forwarding plane implementation. * Encapsulation considerably simplifies implementation within existing software multicast forwarding planes, again, re: BSD and Linux. * The overhead of demux and rewrite of BSD mbufs or Linux skbufs is likely to be the same, i.e. O(n), for ip_id versus an encapsulation header. * For multicast flows between PIM domains and MANET domains, the overhead of prepending such encapsulation at the gateway is very likely to be within acceptable performance limits. I would therefore encourage you to consider the benefits of allowing the use of encapsulation in SMF viz the above points. Kind regards BMS _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Tue Dec 11 10:46: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 1J27Iy-0006lv-U6; Tue, 11 Dec 2007 10:45:56 -0500 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1J27Ix-0006ln-5I for manet-confirm+ok@megatron.ietf.org; Tue, 11 Dec 2007 10:45:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J27Iw-0006le-Rd for manet@ietf.org; Tue, 11 Dec 2007 10:45:54 -0500 Received: from slb-smtpout-01.boeing.com ([130.76.64.48]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J27Iw-0002xd-AY for manet@ietf.org; Tue, 11 Dec 2007 10:45:54 -0500 Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by slb-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id lBBFjaWN011620 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 11 Dec 2007 07:45:41 -0800 (PST) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id lBBFja6X009314; Tue, 11 Dec 2007 07:45:36 -0800 (PST) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by slb-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id lBBFjXDw009218; Tue, 11 Dec 2007 07:45:36 -0800 (PST) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 11 Dec 2007 07:45:34 -0800 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: [manet] Comments on draft-ietf-manet-smf-06 Date: Tue, 11 Dec 2007 07:45:13 -0800 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1029EDCE2@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <9F7D1A2D657D408E8B967F80EC999A8A@linkwray> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] Comments on draft-ietf-manet-smf-06 Thread-Index: AcgyHS2Re0yA54+RQVWHdLp2B6yq8AD3rx/wAYPn+UA= References: <474E04E9.4070506@incunabulum.net> <9F7D1A2D657D408E8B967F80EC999A8A@linkwray> From: "Templin, Fred L" To: "Joe Macker" , "Bruce M Simpson" , X-OriginalArrivalTime: 11 Dec 2007 15:45:34.0731 (UTC) FILETIME=[DE52EDB0:01C83C0C] X-Spam-Score: -4.0 (----) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: manet@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Joe,=20 > -----Original Message----- > From: Joe Macker [mailto:joseph.macker@nrl.navy.mil]=20 > Sent: Tuesday, December 11, 2007 10:35 AM > To: 'Bruce M Simpson'; macker@itd.nrl.navy.mil > Cc: manet@ietf.org > Subject: RE: [manet] Comments on draft-ietf-manet-smf-06 >=20 > Thanks for your comments Bruce. A couple quick responses. >=20 > - Present draft can deal with randomized ids, unlike previous one. ID > sequencing has some security flaws that we now point out, flaws beyond > fingerprinting. >=20 > - I am not against another draft discussing how the approach could be > adopted in an encapsulation mode, but I am presently against adding > encapsulation to this draft (borrowing DPD and forwarding optimizations). I > feel an EXP allows for that evolution to continue. I know we talked about this, but I went away and thought about it and I'm not ready to say that encapsulation shouldn't be considered for this version. It can be very difficult to back-fit new features once an initial draft goes to RFC; even as experimental. And, encapsulation does give a way for DPD to avoid or minimize hashing in IPv4 MANETs. So, I would like to see further consideration for multicast-in-multicast encapsulation now rather than wait for a future draft that may never come about and/or may be difficult to back-fit even if it does. Fred fred.l.templin@boeing.com =20 > -Joe >=20 > -----Original Message----- > From: Bruce M Simpson [mailto:bms@incunabulum.net]=20 > Sent: Wednesday, November 28, 2007 4:17 PM > To: macker@itd.nrl.navy.mil > Cc: manet@ietf.org > Subject: [manet] Comments on draft-ietf-manet-smf-06 >=20 > I am a bit disappointed that the current I-D for MANET SMF=20 > has no provision > for the encapsulation of MANET SMF datagrams in IPv4. >=20 > My points: > * ip_id is only 16 bits wide, making its usefulness limited=20 > in large MANET > topologies. > * Both BSD and Linux may be configured to randomize the=20 > ip_id field as a > defensive measure against IP host fingerprinting. > * Choosing ip_id as a tag for the histogram based duplicate packet > detection requires that NAT routers on the path examine=20 > ip_id, in addition > to being examined by any software multicast forwarding plane=20 > implementation. > * Encapsulation considerably simplifies implementation=20 > within existing > software multicast forwarding planes, again, re: BSD and Linux. > * The overhead of demux and rewrite of BSD mbufs or Linux=20 > skbufs is likely > to be the same, i.e. O(n), for ip_id versus an encapsulation header. > * For multicast flows between PIM domains and MANET domains,=20 > the overhead > of prepending such encapsulation at the gateway is very=20 > likely to be within > acceptable performance limits. >=20 > I would therefore encourage you to consider the benefits of=20 > allowing the use > of encapsulation in SMF viz the above points. >=20 > Kind regards > BMS >=20 >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet >=20 >=20 >=20 >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet >=20 _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Tue Dec 11 11:08:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J27fB-00014E-Co; Tue, 11 Dec 2007 11:08:53 -0500 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1J27f9-000148-6H for manet-confirm+ok@megatron.ietf.org; Tue, 11 Dec 2007 11:08:51 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J27f8-000140-RO for manet@ietf.org; Tue, 11 Dec 2007 11:08:50 -0500 Received: from s2.itd.nrl.navy.mil ([132.250.83.3]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J27f8-0000u7-AW for manet@ietf.org; Tue, 11 Dec 2007 11:08:50 -0500 Received: from smtp.itd.nrl.navy.mil (smtp.itd.nrl.navy.mil [132.250.86.3]) by s2.itd.nrl.navy.mil (8.13.8+Sun/8.12.8) with SMTP id lBBG4euV009894; Tue, 11 Dec 2007 11:04:40 -0500 (EST) Received: (from linkwray [132.250.217.206]) by smtp.itd.nrl.navy.mil (SMSSMTP 4.1.16.48) with SMTP id M2007121111043805960 ; Tue, 11 Dec 2007 11:04:39 -0500 From: "Joe Macker" To: "'Templin, Fred L'" , "'Bruce M Simpson'" , References: <474E04E9.4070506@incunabulum.net> <9F7D1A2D657D408E8B967F80EC999A8A@linkwray> <39C363776A4E8C4A94691D2BD9D1C9A1029EDCE2@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A1029EDCE2@XCH-NW-7V2.nw.nos.boeing.com> Subject: RE: [manet] Comments on draft-ietf-manet-smf-06 Date: Tue, 11 Dec 2007 11:05:18 -0800 Message-ID: <2C2B4C8B55BA40B786A06C33F5490B47@linkwray> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcgyHS2Re0yA54+RQVWHdLp2B6yq8AD3rx/wAYPn+UAAByCGwA== X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6000.16545 X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Cc: manet@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org IP-in-IP brings up other issues so I believe discussing the concept in a separate draft makes sense. I would like to contribute as well but want more discussion to take place. -Joe -----Original Message----- From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com] Sent: Tuesday, December 11, 2007 7:45 AM To: Joe Macker; Bruce M Simpson; macker@itd.nrl.navy.mil Cc: manet@ietf.org Subject: RE: [manet] Comments on draft-ietf-manet-smf-06 Joe, > -----Original Message----- > From: Joe Macker [mailto:joseph.macker@nrl.navy.mil] > Sent: Tuesday, December 11, 2007 10:35 AM > To: 'Bruce M Simpson'; macker@itd.nrl.navy.mil > Cc: manet@ietf.org > Subject: RE: [manet] Comments on draft-ietf-manet-smf-06 > > Thanks for your comments Bruce. A couple quick responses. > > - Present draft can deal with randomized ids, unlike previous one. ID > sequencing has some security flaws that we now point out, flaws beyond > fingerprinting. > > - I am not against another draft discussing how the approach could be > adopted in an encapsulation mode, but I am presently against adding > encapsulation to this draft (borrowing DPD and forwarding optimizations). I > feel an EXP allows for that evolution to continue. I know we talked about this, but I went away and thought about it and I'm not ready to say that encapsulation shouldn't be considered for this version. It can be very difficult to back-fit new features once an initial draft goes to RFC; even as experimental. And, encapsulation does give a way for DPD to avoid or minimize hashing in IPv4 MANETs. So, I would like to see further consideration for multicast-in-multicast encapsulation now rather than wait for a future draft that may never come about and/or may be difficult to back-fit even if it does. Fred fred.l.templin@boeing.com > -Joe > > -----Original Message----- > From: Bruce M Simpson [mailto:bms@incunabulum.net] > Sent: Wednesday, November 28, 2007 4:17 PM > To: macker@itd.nrl.navy.mil > Cc: manet@ietf.org > Subject: [manet] Comments on draft-ietf-manet-smf-06 > > I am a bit disappointed that the current I-D for MANET SMF has no > provision for the encapsulation of MANET SMF datagrams in IPv4. > > My points: > * ip_id is only 16 bits wide, making its usefulness limited in large > MANET topologies. > * Both BSD and Linux may be configured to randomize the ip_id field > as a defensive measure against IP host fingerprinting. > * Choosing ip_id as a tag for the histogram based duplicate packet > detection requires that NAT routers on the path examine ip_id, in > addition to being examined by any software multicast forwarding plane > implementation. > * Encapsulation considerably simplifies implementation within > existing software multicast forwarding planes, again, re: BSD and > Linux. > * The overhead of demux and rewrite of BSD mbufs or Linux skbufs is > likely to be the same, i.e. O(n), for ip_id versus an encapsulation > header. > * For multicast flows between PIM domains and MANET domains, the > overhead of prepending such encapsulation at the gateway is very > likely to be within acceptable performance limits. > > I would therefore encourage you to consider the benefits of allowing > the use of encapsulation in SMF viz the above points. > > Kind regards > BMS > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet > > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Tue Dec 11 11:12: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 1J27iq-00071j-SK; Tue, 11 Dec 2007 11:12:40 -0500 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1J27io-00071S-TV for manet-confirm+ok@megatron.ietf.org; Tue, 11 Dec 2007 11:12:38 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J27io-00071K-Ha for manet@ietf.org; Tue, 11 Dec 2007 11:12:38 -0500 Received: from stl-smtpout-01.boeing.com ([130.76.96.56]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J27in-00010q-Ut for manet@ietf.org; Tue, 11 Dec 2007 11:12:38 -0500 Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [192.42.227.216]) by stl-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id lBBGCUBI012596 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 11 Dec 2007 10:12:35 -0600 (CST) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id lBBGCUEG022060; Tue, 11 Dec 2007 08:12:30 -0800 (PST) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by blv-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id lBBGCTRe022002; Tue, 11 Dec 2007 08:12:29 -0800 (PST) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 11 Dec 2007 08:12:29 -0800 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: [manet] Comments on draft-ietf-manet-smf-06 Date: Tue, 11 Dec 2007 08:11:30 -0800 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1029EDCE4@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <2C2B4C8B55BA40B786A06C33F5490B47@linkwray> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] Comments on draft-ietf-manet-smf-06 Thread-Index: AcgyHS2Re0yA54+RQVWHdLp2B6yq8AD3rx/wAYPn+UAAByCGwAAF+LIw References: <474E04E9.4070506@incunabulum.net> <9F7D1A2D657D408E8B967F80EC999A8A@linkwray> <39C363776A4E8C4A94691D2BD9D1C9A1029EDCE2@XCH-NW-7V2.nw.nos.boeing.com> <2C2B4C8B55BA40B786A06C33F5490B47@linkwray> From: "Templin, Fred L" To: "Joe Macker" , "Bruce M Simpson" , X-OriginalArrivalTime: 11 Dec 2007 16:12:29.0200 (UTC) FILETIME=[A09F5900:01C83C10] X-Spam-Score: 0.0 (/) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c Cc: manet@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Joe,=20 > -----Original Message----- > From: Joe Macker [mailto:joseph.macker@nrl.navy.mil]=20 > Sent: Tuesday, December 11, 2007 11:05 AM > To: Templin, Fred L; 'Bruce M Simpson'; macker@itd.nrl.navy.mil > Cc: manet@ietf.org > Subject: RE: [manet] Comments on draft-ietf-manet-smf-06 >=20 > IP-in-IP brings up other issues so I believe discussing the concept in a > separate draft makes sense. > I would like to contribute as well but want more discussion to take place. I'm not sure what you mean about the other issues; are you talking about MTU, for example? The MTU for multicast is simply 20 bytes less than whatever the raw linkMTU is, and I don't see a problem with that. Fred fred.l.templin@boeing.com =20 > -Joe >=20 > -----Original Message----- > From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com]=20 > Sent: Tuesday, December 11, 2007 7:45 AM > To: Joe Macker; Bruce M Simpson; macker@itd.nrl.navy.mil > Cc: manet@ietf.org > Subject: RE: [manet] Comments on draft-ietf-manet-smf-06 >=20 > Joe,=20 >=20 > > -----Original Message----- > > From: Joe Macker [mailto:joseph.macker@nrl.navy.mil] > > Sent: Tuesday, December 11, 2007 10:35 AM > > To: 'Bruce M Simpson'; macker@itd.nrl.navy.mil > > Cc: manet@ietf.org > > Subject: RE: [manet] Comments on draft-ietf-manet-smf-06 > >=20 > > Thanks for your comments Bruce. A couple quick responses. > >=20 > > - Present draft can deal with randomized ids, unlike=20 > previous one. ID=20 > > sequencing has some security flaws that we now point out,=20 > flaws beyond=20 > > fingerprinting. > >=20 > > - I am not against another draft discussing how the=20 > approach could be=20 > > adopted in an encapsulation mode, but I am presently against adding=20 > > encapsulation to this draft (borrowing DPD and forwarding > optimizations). I > > feel an EXP allows for that evolution to continue. >=20 > I know we talked about this, but I went away and thought=20 > about it and I'm > not ready to say that encapsulation shouldn't be considered for this > version. It can be very difficult to back-fit new features=20 > once an initial > draft goes to RFC; even as experimental. And, encapsulation=20 > does give a way > for DPD to avoid or minimize hashing in IPv4 MANETs. So, I=20 > would like to see > further consideration for multicast-in-multicast=20 > encapsulation now rather > than wait for a future draft that may never come about and/or may be > difficult to back-fit even if it does. >=20 > Fred > fred.l.templin@boeing.com > =20 > > -Joe > >=20 > > -----Original Message----- > > From: Bruce M Simpson [mailto:bms@incunabulum.net] > > Sent: Wednesday, November 28, 2007 4:17 PM > > To: macker@itd.nrl.navy.mil > > Cc: manet@ietf.org > > Subject: [manet] Comments on draft-ietf-manet-smf-06 > >=20 > > I am a bit disappointed that the current I-D for MANET SMF has no=20 > > provision for the encapsulation of MANET SMF datagrams in IPv4. > >=20 > > My points: > > * ip_id is only 16 bits wide, making its usefulness=20 > limited in large=20 > > MANET topologies. > > * Both BSD and Linux may be configured to randomize the=20 > ip_id field=20 > > as a defensive measure against IP host fingerprinting. > > * Choosing ip_id as a tag for the histogram based duplicate packet=20 > > detection requires that NAT routers on the path examine ip_id, in=20 > > addition to being examined by any software multicast=20 > forwarding plane=20 > > implementation. > > * Encapsulation considerably simplifies implementation within=20 > > existing software multicast forwarding planes, again, re: BSD and=20 > > Linux. > > * The overhead of demux and rewrite of BSD mbufs or Linux=20 > skbufs is=20 > > likely to be the same, i.e. O(n), for ip_id versus an encapsulation=20 > > header. > > * For multicast flows between PIM domains and MANET domains, the=20 > > overhead of prepending such encapsulation at the gateway is very=20 > > likely to be within acceptable performance limits. > >=20 > > I would therefore encourage you to consider the benefits of=20 > allowing=20 > > the use of encapsulation in SMF viz the above points. > >=20 > > Kind regards > > BMS > >=20 > >=20 > > _______________________________________________ > > manet mailing list > > manet@ietf.org > > https://www1.ietf.org/mailman/listinfo/manet > >=20 > >=20 > >=20 > >=20 > > _______________________________________________ > > manet mailing list > > manet@ietf.org > > https://www1.ietf.org/mailman/listinfo/manet > >=20 >=20 >=20 >=20 _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Tue Dec 11 11:30: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 1J2802-0007uB-Ot; Tue, 11 Dec 2007 11:30:26 -0500 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1J2801-0007rs-GK for manet-confirm+ok@megatron.ietf.org; Tue, 11 Dec 2007 11:30:25 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2801-0007oD-36 for manet@ietf.org; Tue, 11 Dec 2007 11:30:25 -0500 Received: from s2.itd.nrl.navy.mil ([132.250.83.3]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J2800-0001dN-F2 for manet@ietf.org; Tue, 11 Dec 2007 11:30:24 -0500 Received: from smtp.itd.nrl.navy.mil (smtp.itd.nrl.navy.mil [132.250.86.3]) by s2.itd.nrl.navy.mil (8.13.8+Sun/8.12.8) with SMTP id lBBGTlIu011703; Tue, 11 Dec 2007 11:29:54 -0500 (EST) Received: (from linkwray [132.250.217.206]) by smtp.itd.nrl.navy.mil (SMSSMTP 4.1.16.48) with SMTP id M2007121111295306155 ; Tue, 11 Dec 2007 11:29:54 -0500 From: "Joe Macker" To: "'Templin, Fred L'" , "'Bruce M Simpson'" , References: <474E04E9.4070506@incunabulum.net> <9F7D1A2D657D408E8B967F80EC999A8A@linkwray> <39C363776A4E8C4A94691D2BD9D1C9A1029EDCE2@XCH-NW-7V2.nw.nos.boeing.com> <2C2B4C8B55BA40B786A06C33F5490B47@linkwray> <39C363776A4E8C4A94691D2BD9D1C9A1029EDCE4@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A1029EDCE4@XCH-NW-7V2.nw.nos.boeing.com> Subject: RE: [manet] Comments on draft-ietf-manet-smf-06 Date: Tue, 11 Dec 2007 11:30:31 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcgyHS2Re0yA54+RQVWHdLp2B6yq8AD3rx/wAYPn+UAAByCGwAAF+LIwAAUd0VA= X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6000.16545 X-Spam-Score: 0.4 (/) X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c Cc: manet@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Architecture considerations, iana, security, kernel implementation, etc. I don't see major problems just want it discussed in a separate document. -----Original Message----- From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com] Sent: Tuesday, December 11, 2007 8:12 AM To: Joe Macker; Bruce M Simpson; macker@itd.nrl.navy.mil Cc: manet@ietf.org Subject: RE: [manet] Comments on draft-ietf-manet-smf-06 Joe, > -----Original Message----- > From: Joe Macker [mailto:joseph.macker@nrl.navy.mil] > Sent: Tuesday, December 11, 2007 11:05 AM > To: Templin, Fred L; 'Bruce M Simpson'; macker@itd.nrl.navy.mil > Cc: manet@ietf.org > Subject: RE: [manet] Comments on draft-ietf-manet-smf-06 > > IP-in-IP brings up other issues so I believe discussing the concept in a > separate draft makes sense. > I would like to contribute as well but want more discussion to take place. I'm not sure what you mean about the other issues; are you talking about MTU, for example? The MTU for multicast is simply 20 bytes less than whatever the raw linkMTU is, and I don't see a problem with that. Fred fred.l.templin@boeing.com > -Joe > > -----Original Message----- > From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com] > Sent: Tuesday, December 11, 2007 7:45 AM > To: Joe Macker; Bruce M Simpson; macker@itd.nrl.navy.mil > Cc: manet@ietf.org > Subject: RE: [manet] Comments on draft-ietf-manet-smf-06 > > Joe, > > > -----Original Message----- > > From: Joe Macker [mailto:joseph.macker@nrl.navy.mil] > > Sent: Tuesday, December 11, 2007 10:35 AM > > To: 'Bruce M Simpson'; macker@itd.nrl.navy.mil > > Cc: manet@ietf.org > > Subject: RE: [manet] Comments on draft-ietf-manet-smf-06 > > > > Thanks for your comments Bruce. A couple quick responses. > > > > - Present draft can deal with randomized ids, unlike > previous one. ID > > sequencing has some security flaws that we now point out, > flaws beyond > > fingerprinting. > > > > - I am not against another draft discussing how the > approach could be > > adopted in an encapsulation mode, but I am presently against adding > > encapsulation to this draft (borrowing DPD and forwarding > optimizations). I > > feel an EXP allows for that evolution to continue. > > I know we talked about this, but I went away and thought about it and > I'm not ready to say that encapsulation shouldn't be considered for > this version. It can be very difficult to back-fit new features once > an initial draft goes to RFC; even as experimental. And, encapsulation > does give a way for DPD to avoid or minimize hashing in IPv4 MANETs. > So, I would like to see further consideration for > multicast-in-multicast encapsulation now rather than wait for a future > draft that may never come about and/or may be difficult to back-fit > even if it does. > > Fred > fred.l.templin@boeing.com > > > -Joe > > > > -----Original Message----- > > From: Bruce M Simpson [mailto:bms@incunabulum.net] > > Sent: Wednesday, November 28, 2007 4:17 PM > > To: macker@itd.nrl.navy.mil > > Cc: manet@ietf.org > > Subject: [manet] Comments on draft-ietf-manet-smf-06 > > > > I am a bit disappointed that the current I-D for MANET SMF has no > > provision for the encapsulation of MANET SMF datagrams in IPv4. > > > > My points: > > * ip_id is only 16 bits wide, making its usefulness > limited in large > > MANET topologies. > > * Both BSD and Linux may be configured to randomize the > ip_id field > > as a defensive measure against IP host fingerprinting. > > * Choosing ip_id as a tag for the histogram based duplicate packet > > detection requires that NAT routers on the path examine ip_id, in > > addition to being examined by any software multicast > forwarding plane > > implementation. > > * Encapsulation considerably simplifies implementation within > > existing software multicast forwarding planes, again, re: BSD and > > Linux. > > * The overhead of demux and rewrite of BSD mbufs or Linux > skbufs is > > likely to be the same, i.e. O(n), for ip_id versus an encapsulation > > header. > > * For multicast flows between PIM domains and MANET domains, the > > overhead of prepending such encapsulation at the gateway is very > > likely to be within acceptable performance limits. > > > > I would therefore encourage you to consider the benefits of > allowing > > the use of encapsulation in SMF viz the above points. > > > > Kind regards > > BMS > > > > > > _______________________________________________ > > manet mailing list > > manet@ietf.org > > https://www1.ietf.org/mailman/listinfo/manet > > > > > > > > > > _______________________________________________ > > manet mailing list > > manet@ietf.org > > https://www1.ietf.org/mailman/listinfo/manet > > > > > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Tue Dec 11 11:37:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J286M-0005Pq-5k; Tue, 11 Dec 2007 11:36:58 -0500 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1J286L-0005Pg-5D for manet-confirm+ok@megatron.ietf.org; Tue, 11 Dec 2007 11:36:57 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J286K-0005PX-PW for manet@ietf.org; Tue, 11 Dec 2007 11:36:56 -0500 Received: from stl-smtpout-01.boeing.com ([130.76.96.56]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J286K-0001ms-3U for manet@ietf.org; Tue, 11 Dec 2007 11:36:56 -0500 Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by stl-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id lBBGaiFG000249 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 11 Dec 2007 10:36:45 -0600 (CST) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id lBBGaiQK017790; Tue, 11 Dec 2007 08:36:44 -0800 (PST) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by slb-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id lBBGagKB017738; Tue, 11 Dec 2007 08:36:44 -0800 (PST) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 11 Dec 2007 08:36:43 -0800 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: [manet] Comments on draft-ietf-manet-smf-06 Date: Tue, 11 Dec 2007 08:36:01 -0800 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1029EDCE7@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] Comments on draft-ietf-manet-smf-06 Thread-Index: AcgyHS2Re0yA54+RQVWHdLp2B6yq8AD3rx/wAYPn+UAAByCGwAAF+LIwAAUd0VAAEDpFkA== References: <474E04E9.4070506@incunabulum.net> <9F7D1A2D657D408E8B967F80EC999A8A@linkwray> <39C363776A4E8C4A94691D2BD9D1C9A1029EDCE2@XCH-NW-7V2.nw.nos.boeing.com> <2C2B4C8B55BA40B786A06C33F5490B47@linkwray> <39C363776A4E8C4A94691D2BD9D1C9A1029EDCE4@XCH-NW-7V2.nw.nos.boeing.com> From: "Templin, Fred L" To: "Joe Macker" , "Bruce M Simpson" , X-OriginalArrivalTime: 11 Dec 2007 16:36:43.0106 (UTC) FILETIME=[0337CC20:01C83C14] X-Spam-Score: 0.0 (/) X-Scan-Signature: 995b2e24d23b953c94bac5288c432399 Cc: manet@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Joe,=20 > -----Original Message----- > From: Joe Macker [mailto:joseph.macker@nrl.navy.mil]=20 > Sent: Tuesday, December 11, 2007 11:31 AM > To: Templin, Fred L; 'Bruce M Simpson'; macker@itd.nrl.navy.mil > Cc: manet@ietf.org > Subject: RE: [manet] Comments on draft-ietf-manet-smf-06 >=20 > Architecture considerations, iana, security, kernel=20 > implementation, etc. Not sure what you mean be architecture and security considerations, but IANA should just fall out of whatever gets specified in this document and, with mechanisms like tuntap, I don't believe implementation is limited to kernel. =20 > I don't see major problems just want it discussed in a=20 > separate document. Again, not tackling this now is going to make it difficult if not impossible to tackle it later. Fred fred.l.templin@boeing.com > -----Original Message----- > From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com]=20 > Sent: Tuesday, December 11, 2007 8:12 AM > To: Joe Macker; Bruce M Simpson; macker@itd.nrl.navy.mil > Cc: manet@ietf.org > Subject: RE: [manet] Comments on draft-ietf-manet-smf-06 >=20 > Joe,=20 >=20 > > -----Original Message----- > > From: Joe Macker [mailto:joseph.macker@nrl.navy.mil] > > Sent: Tuesday, December 11, 2007 11:05 AM > > To: Templin, Fred L; 'Bruce M Simpson'; macker@itd.nrl.navy.mil > > Cc: manet@ietf.org > > Subject: RE: [manet] Comments on draft-ietf-manet-smf-06 > >=20 > > IP-in-IP brings up other issues so I believe discussing the=20 > concept in > a > > separate draft makes sense. > > I would like to contribute as well but want more discussion to take > place. >=20 > I'm not sure what you mean about the other issues; are you=20 > talking about > MTU, for example? The MTU for multicast is simply 20 bytes less than > whatever the raw linkMTU is, and I don't see a problem with that. >=20 > Fred > fred.l.templin@boeing.com > =20 > > -Joe > >=20 > > -----Original Message----- > > From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com] > > Sent: Tuesday, December 11, 2007 7:45 AM > > To: Joe Macker; Bruce M Simpson; macker@itd.nrl.navy.mil > > Cc: manet@ietf.org > > Subject: RE: [manet] Comments on draft-ietf-manet-smf-06 > >=20 > > Joe, > >=20 > > > -----Original Message----- > > > From: Joe Macker [mailto:joseph.macker@nrl.navy.mil] > > > Sent: Tuesday, December 11, 2007 10:35 AM > > > To: 'Bruce M Simpson'; macker@itd.nrl.navy.mil > > > Cc: manet@ietf.org > > > Subject: RE: [manet] Comments on draft-ietf-manet-smf-06 > > >=20 > > > Thanks for your comments Bruce. A couple quick responses. > > >=20 > > > - Present draft can deal with randomized ids, unlike > > previous one. ID > > > sequencing has some security flaws that we now point out, > > flaws beyond > > > fingerprinting. > > >=20 > > > - I am not against another draft discussing how the > > approach could be > > > adopted in an encapsulation mode, but I am presently=20 > against adding=20 > > > encapsulation to this draft (borrowing DPD and forwarding > > optimizations). I > > > feel an EXP allows for that evolution to continue. > >=20 > > I know we talked about this, but I went away and thought=20 > about it and=20 > > I'm not ready to say that encapsulation shouldn't be considered for=20 > > this version. It can be very difficult to back-fit new=20 > features once=20 > > an initial draft goes to RFC; even as experimental. And,=20 > encapsulation=20 > > does give a way for DPD to avoid or minimize hashing in=20 > IPv4 MANETs.=20 > > So, I would like to see further consideration for=20 > > multicast-in-multicast encapsulation now rather than wait=20 > for a future=20 > > draft that may never come about and/or may be difficult to back-fit=20 > > even if it does. > >=20 > > Fred > > fred.l.templin@boeing.com > > =20 > > > -Joe > > >=20 > > > -----Original Message----- > > > From: Bruce M Simpson [mailto:bms@incunabulum.net] > > > Sent: Wednesday, November 28, 2007 4:17 PM > > > To: macker@itd.nrl.navy.mil > > > Cc: manet@ietf.org > > > Subject: [manet] Comments on draft-ietf-manet-smf-06 > > >=20 > > > I am a bit disappointed that the current I-D for MANET SMF has no=20 > > > provision for the encapsulation of MANET SMF datagrams in IPv4. > > >=20 > > > My points: > > > * ip_id is only 16 bits wide, making its usefulness > > limited in large > > > MANET topologies. > > > * Both BSD and Linux may be configured to randomize the > > ip_id field > > > as a defensive measure against IP host fingerprinting. > > > * Choosing ip_id as a tag for the histogram based=20 > duplicate packet=20 > > > detection requires that NAT routers on the path examine ip_id, in=20 > > > addition to being examined by any software multicast > > forwarding plane > > > implementation. > > > * Encapsulation considerably simplifies implementation within=20 > > > existing software multicast forwarding planes, again, re: BSD and=20 > > > Linux. > > > * The overhead of demux and rewrite of BSD mbufs or Linux > > skbufs is > > > likely to be the same, i.e. O(n), for ip_id versus an=20 > encapsulation=20 > > > header. > > > * For multicast flows between PIM domains and MANET domains, the=20 > > > overhead of prepending such encapsulation at the gateway is very=20 > > > likely to be within acceptable performance limits. > > >=20 > > > I would therefore encourage you to consider the benefits of > > allowing > > > the use of encapsulation in SMF viz the above points. > > >=20 > > > Kind regards > > > BMS > > >=20 > > >=20 > > > _______________________________________________ > > > manet mailing list > > > manet@ietf.org > > > https://www1.ietf.org/mailman/listinfo/manet > > >=20 > > >=20 > > >=20 > > >=20 > > > _______________________________________________ > > > manet mailing list > > > manet@ietf.org > > > https://www1.ietf.org/mailman/listinfo/manet > > >=20 > >=20 > >=20 > >=20 >=20 >=20 >=20 _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Tue Dec 11 12:41: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 1J2977-0002l4-US; Tue, 11 Dec 2007 12:41:49 -0500 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1J2976-0002kz-Ad for manet-confirm+ok@megatron.ietf.org; Tue, 11 Dec 2007 12:41:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2976-0002ki-0q for manet@ietf.org; Tue, 11 Dec 2007 12:41:48 -0500 Received: from s2.itd.nrl.navy.mil ([132.250.83.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2975-0005fV-AD for manet@ietf.org; Tue, 11 Dec 2007 12:41:48 -0500 Received: from smtp.itd.nrl.navy.mil (smtp.itd.nrl.navy.mil [132.250.86.3]) by s2.itd.nrl.navy.mil (8.13.8+Sun/8.12.8) with SMTP id lBBHejsl016086; Tue, 11 Dec 2007 12:40:45 -0500 (EST) Received: (from linkwray [132.250.217.206]) by smtp.itd.nrl.navy.mil (SMSSMTP 4.1.16.48) with SMTP id M2007121112404306617 ; Tue, 11 Dec 2007 12:40:44 -0500 From: "Joe Macker" To: "'Templin, Fred L'" , "'Bruce M Simpson'" , References: <474E04E9.4070506@incunabulum.net> <9F7D1A2D657D408E8B967F80EC999A8A@linkwray> <39C363776A4E8C4A94691D2BD9D1C9A1029EDCE2@XCH-NW-7V2.nw.nos.boeing.com> <2C2B4C8B55BA40B786A06C33F5490B47@linkwray> <39C363776A4E8C4A94691D2BD9D1C9A1029EDCE4@XCH-NW-7V2.nw.nos.boeing.com> <39C363776A4E8C4A94691D2BD9D1C9A1029EDCE7@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A1029EDCE7@XCH-NW-7V2.nw.nos.boeing.com> Subject: RE: [manet] Comments on draft-ietf-manet-smf-06 Date: Tue, 11 Dec 2007 12:41:17 -0800 Message-ID: <9D58B9149A0B45F4A3521D6FCD31ED39@linkwray> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcgyHS2Re0yA54+RQVWHdLp2B6yq8AD3rx/wAYPn+UAAByCGwAAF+LIwAAUd0VAAEDpFkAAYObBQ X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6000.16545 X-Spam-Score: 0.0 (/) X-Scan-Signature: b8f3559805f7873076212d6f63ee803e Cc: manet@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Fred: At present there are experimental deployments with non-SMF receive nodes consuming SMF traffic without a required detunneling point. Understand tuntap...I meant in sense of above. I may have little time in next few days to post more (in case I am quiet).. For clarity (my thoughts): (1) would like to see a pers ID for discussion (2) could be short well-aligned with SMF CDS/DPD (3) don't think (2) is difficult (4) would be willing to help with (1) -Joe -----Original Message----- From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com] Sent: Tuesday, December 11, 2007 8:36 AM To: Joe Macker; Bruce M Simpson; macker@itd.nrl.navy.mil Cc: manet@ietf.org Subject: RE: [manet] Comments on draft-ietf-manet-smf-06 Joe, > -----Original Message----- > From: Joe Macker [mailto:joseph.macker@nrl.navy.mil] > Sent: Tuesday, December 11, 2007 11:31 AM > To: Templin, Fred L; 'Bruce M Simpson'; macker@itd.nrl.navy.mil > Cc: manet@ietf.org > Subject: RE: [manet] Comments on draft-ietf-manet-smf-06 > > Architecture considerations, iana, security, kernel implementation, > etc. Not sure what you mean be architecture and security considerations, but IANA should just fall out of whatever gets specified in this document and, with mechanisms like tuntap, I don't believe implementation is limited to kernel. > I don't see major problems just want it discussed in a separate > document. Again, not tackling this now is going to make it difficult if not impossible to tackle it later. Fred fred.l.templin@boeing.com > -----Original Message----- > From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com] > Sent: Tuesday, December 11, 2007 8:12 AM > To: Joe Macker; Bruce M Simpson; macker@itd.nrl.navy.mil > Cc: manet@ietf.org > Subject: RE: [manet] Comments on draft-ietf-manet-smf-06 > > Joe, > > > -----Original Message----- > > From: Joe Macker [mailto:joseph.macker@nrl.navy.mil] > > Sent: Tuesday, December 11, 2007 11:05 AM > > To: Templin, Fred L; 'Bruce M Simpson'; macker@itd.nrl.navy.mil > > Cc: manet@ietf.org > > Subject: RE: [manet] Comments on draft-ietf-manet-smf-06 > > > > IP-in-IP brings up other issues so I believe discussing the > concept in > a > > separate draft makes sense. > > I would like to contribute as well but want more discussion to take > place. > > I'm not sure what you mean about the other issues; are you talking > about MTU, for example? The MTU for multicast is simply 20 bytes less > than whatever the raw linkMTU is, and I don't see a problem with that. > > Fred > fred.l.templin@boeing.com > > > -Joe > > > > -----Original Message----- > > From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com] > > Sent: Tuesday, December 11, 2007 7:45 AM > > To: Joe Macker; Bruce M Simpson; macker@itd.nrl.navy.mil > > Cc: manet@ietf.org > > Subject: RE: [manet] Comments on draft-ietf-manet-smf-06 > > > > Joe, > > > > > -----Original Message----- > > > From: Joe Macker [mailto:joseph.macker@nrl.navy.mil] > > > Sent: Tuesday, December 11, 2007 10:35 AM > > > To: 'Bruce M Simpson'; macker@itd.nrl.navy.mil > > > Cc: manet@ietf.org > > > Subject: RE: [manet] Comments on draft-ietf-manet-smf-06 > > > > > > Thanks for your comments Bruce. A couple quick responses. > > > > > > - Present draft can deal with randomized ids, unlike > > previous one. ID > > > sequencing has some security flaws that we now point out, > > flaws beyond > > > fingerprinting. > > > > > > - I am not against another draft discussing how the > > approach could be > > > adopted in an encapsulation mode, but I am presently > against adding > > > encapsulation to this draft (borrowing DPD and forwarding > > optimizations). I > > > feel an EXP allows for that evolution to continue. > > > > I know we talked about this, but I went away and thought > about it and > > I'm not ready to say that encapsulation shouldn't be considered for > > this version. It can be very difficult to back-fit new > features once > > an initial draft goes to RFC; even as experimental. And, > encapsulation > > does give a way for DPD to avoid or minimize hashing in > IPv4 MANETs. > > So, I would like to see further consideration for > > multicast-in-multicast encapsulation now rather than wait > for a future > > draft that may never come about and/or may be difficult to back-fit > > even if it does. > > > > Fred > > fred.l.templin@boeing.com > > > > > -Joe > > > > > > -----Original Message----- > > > From: Bruce M Simpson [mailto:bms@incunabulum.net] > > > Sent: Wednesday, November 28, 2007 4:17 PM > > > To: macker@itd.nrl.navy.mil > > > Cc: manet@ietf.org > > > Subject: [manet] Comments on draft-ietf-manet-smf-06 > > > > > > I am a bit disappointed that the current I-D for MANET SMF has no > > > provision for the encapsulation of MANET SMF datagrams in IPv4. > > > > > > My points: > > > * ip_id is only 16 bits wide, making its usefulness > > limited in large > > > MANET topologies. > > > * Both BSD and Linux may be configured to randomize the > > ip_id field > > > as a defensive measure against IP host fingerprinting. > > > * Choosing ip_id as a tag for the histogram based > duplicate packet > > > detection requires that NAT routers on the path examine ip_id, in > > > addition to being examined by any software multicast > > forwarding plane > > > implementation. > > > * Encapsulation considerably simplifies implementation within > > > existing software multicast forwarding planes, again, re: BSD and > > > Linux. > > > * The overhead of demux and rewrite of BSD mbufs or Linux > > skbufs is > > > likely to be the same, i.e. O(n), for ip_id versus an > encapsulation > > > header. > > > * For multicast flows between PIM domains and MANET domains, the > > > overhead of prepending such encapsulation at the gateway is very > > > likely to be within acceptable performance limits. > > > > > > I would therefore encourage you to consider the benefits of > > allowing > > > the use of encapsulation in SMF viz the above points. > > > > > > Kind regards > > > BMS > > > > > > > > > _______________________________________________ > > > manet mailing list > > > manet@ietf.org > > > https://www1.ietf.org/mailman/listinfo/manet > > > > > > > > > > > > > > > _______________________________________________ > > > manet mailing list > > > manet@ietf.org > > > https://www1.ietf.org/mailman/listinfo/manet > > > > > > > > > > > > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Tue Dec 11 12:55:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J29Kh-0000qp-4U; Tue, 11 Dec 2007 12:55:51 -0500 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1J29Kf-0000qX-GB for manet-confirm+ok@megatron.ietf.org; Tue, 11 Dec 2007 12:55:49 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J29Kf-0000qN-3W for manet@ietf.org; Tue, 11 Dec 2007 12:55:49 -0500 Received: from slb-smtpout-01.boeing.com ([130.76.64.48]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J29Ke-0003YK-6K for manet@ietf.org; Tue, 11 Dec 2007 12:55:49 -0500 Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [192.42.227.216]) by slb-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id lBBHtiSR016011 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 11 Dec 2007 09:55:45 -0800 (PST) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id lBBHthPX012606; Tue, 11 Dec 2007 09:55:44 -0800 (PST) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by blv-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id lBBHthPN012560; Tue, 11 Dec 2007 09:55:43 -0800 (PST) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 11 Dec 2007 09:55:42 -0800 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: [manet] Comments on draft-ietf-manet-smf-06 Date: Tue, 11 Dec 2007 09:55:33 -0800 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1029EDCE9@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <9D58B9149A0B45F4A3521D6FCD31ED39@linkwray> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] Comments on draft-ietf-manet-smf-06 Thread-Index: AcgyHS2Re0yA54+RQVWHdLp2B6yq8AD3rx/wAYPn+UAAByCGwAAF+LIwAAUd0VAAEDpFkAAYObBQADYXWOA= References: <474E04E9.4070506@incunabulum.net> <9F7D1A2D657D408E8B967F80EC999A8A@linkwray> <39C363776A4E8C4A94691D2BD9D1C9A1029EDCE2@XCH-NW-7V2.nw.nos.boeing.com> <2C2B4C8B55BA40B786A06C33F5490B47@linkwray> <39C363776A4E8C4A94691D2BD9D1C9A1029EDCE4@XCH-NW-7V2.nw.nos.boeing.com> <39C363776A4E8C4A94691D2BD9D1C9A1029EDCE7@XCH-NW-7V2.nw.nos.boeing.com> <9D58B9149A0B45F4A3521D6FCD31ED39@linkwray> From: "Templin, Fred L" To: "Joe Macker" , "Bruce M Simpson" , X-OriginalArrivalTime: 11 Dec 2007 17:55:42.0622 (UTC) FILETIME=[0C308BE0:01C83C1F] X-Spam-Score: 0.0 (/) X-Scan-Signature: b84f8c8fba0e1389e5eb998b64078964 Cc: manet@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Joe, Your suggestion seems very pragmatic, so I tend to think we should give it serious consideration and I make be able to help with it. Let's talk further on this when time permits. Thanks - Fred fred.l.templin@boeing.com =20 > -----Original Message----- > From: Joe Macker [mailto:joseph.macker@nrl.navy.mil]=20 > Sent: Tuesday, December 11, 2007 12:41 PM > To: Templin, Fred L; 'Bruce M Simpson'; macker@itd.nrl.navy.mil > Cc: manet@ietf.org > Subject: RE: [manet] Comments on draft-ietf-manet-smf-06 >=20 > Fred: >=20 > At present there are experimental deployments with non-SMF=20 > receive nodes=20 > consuming SMF traffic without a required detunneling point.=20 > Understand tuntap...I meant in sense of above. >=20 > I may have little time in next few days to post more (in case=20 > I am quiet).. >=20 > For clarity (my thoughts): >=20 > (1) would like to see a pers ID for discussion > (2) could be short well-aligned with SMF CDS/DPD > (3) don't think (2) is difficult > (4) would be willing to help with (1) >=20 > -Joe >=20 > -----Original Message----- > From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com]=20 > Sent: Tuesday, December 11, 2007 8:36 AM > To: Joe Macker; Bruce M Simpson; macker@itd.nrl.navy.mil > Cc: manet@ietf.org > Subject: RE: [manet] Comments on draft-ietf-manet-smf-06 >=20 > Joe,=20 >=20 > > -----Original Message----- > > From: Joe Macker [mailto:joseph.macker@nrl.navy.mil] > > Sent: Tuesday, December 11, 2007 11:31 AM > > To: Templin, Fred L; 'Bruce M Simpson'; macker@itd.nrl.navy.mil > > Cc: manet@ietf.org > > Subject: RE: [manet] Comments on draft-ietf-manet-smf-06 > >=20 > > Architecture considerations, iana, security, kernel implementation,=20 > > etc. >=20 > Not sure what you mean be architecture and security=20 > considerations, but IANA > should just fall out of whatever gets specified in this=20 > document and, with > mechanisms like tuntap, I don't believe implementation is=20 > limited to kernel. > =20 > > I don't see major problems just want it discussed in a separate=20 > > document. >=20 > Again, not tackling this now is going to make it difficult if=20 > not impossible > to tackle it later. >=20 > Fred > fred.l.templin@boeing.com >=20 > > -----Original Message----- > > From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com] > > Sent: Tuesday, December 11, 2007 8:12 AM > > To: Joe Macker; Bruce M Simpson; macker@itd.nrl.navy.mil > > Cc: manet@ietf.org > > Subject: RE: [manet] Comments on draft-ietf-manet-smf-06 > >=20 > > Joe, > >=20 > > > -----Original Message----- > > > From: Joe Macker [mailto:joseph.macker@nrl.navy.mil] > > > Sent: Tuesday, December 11, 2007 11:05 AM > > > To: Templin, Fred L; 'Bruce M Simpson'; macker@itd.nrl.navy.mil > > > Cc: manet@ietf.org > > > Subject: RE: [manet] Comments on draft-ietf-manet-smf-06 > > >=20 > > > IP-in-IP brings up other issues so I believe discussing the > > concept in > > a > > > separate draft makes sense. > > > I would like to contribute as well but want more=20 > discussion to take > > place. > >=20 > > I'm not sure what you mean about the other issues; are you talking=20 > > about MTU, for example? The MTU for multicast is simply 20=20 > bytes less=20 > > than whatever the raw linkMTU is, and I don't see a problem=20 > with that. > >=20 > > Fred > > fred.l.templin@boeing.com > > =20 > > > -Joe > > >=20 > > > -----Original Message----- > > > From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com] > > > Sent: Tuesday, December 11, 2007 7:45 AM > > > To: Joe Macker; Bruce M Simpson; macker@itd.nrl.navy.mil > > > Cc: manet@ietf.org > > > Subject: RE: [manet] Comments on draft-ietf-manet-smf-06 > > >=20 > > > Joe, > > >=20 > > > > -----Original Message----- > > > > From: Joe Macker [mailto:joseph.macker@nrl.navy.mil] > > > > Sent: Tuesday, December 11, 2007 10:35 AM > > > > To: 'Bruce M Simpson'; macker@itd.nrl.navy.mil > > > > Cc: manet@ietf.org > > > > Subject: RE: [manet] Comments on draft-ietf-manet-smf-06 > > > >=20 > > > > Thanks for your comments Bruce. A couple quick responses. > > > >=20 > > > > - Present draft can deal with randomized ids, unlike > > > previous one. ID > > > > sequencing has some security flaws that we now point out, > > > flaws beyond > > > > fingerprinting. > > > >=20 > > > > - I am not against another draft discussing how the > > > approach could be > > > > adopted in an encapsulation mode, but I am presently > > against adding > > > > encapsulation to this draft (borrowing DPD and forwarding > > > optimizations). I > > > > feel an EXP allows for that evolution to continue. > > >=20 > > > I know we talked about this, but I went away and thought > > about it and > > > I'm not ready to say that encapsulation shouldn't be=20 > considered for=20 > > > this version. It can be very difficult to back-fit new > > features once > > > an initial draft goes to RFC; even as experimental. And, > > encapsulation > > > does give a way for DPD to avoid or minimize hashing in > > IPv4 MANETs.=20 > > > So, I would like to see further consideration for=20 > > > multicast-in-multicast encapsulation now rather than wait > > for a future > > > draft that may never come about and/or may be difficult=20 > to back-fit=20 > > > even if it does. > > >=20 > > > Fred > > > fred.l.templin@boeing.com > > > =20 > > > > -Joe > > > >=20 > > > > -----Original Message----- > > > > From: Bruce M Simpson [mailto:bms@incunabulum.net] > > > > Sent: Wednesday, November 28, 2007 4:17 PM > > > > To: macker@itd.nrl.navy.mil > > > > Cc: manet@ietf.org > > > > Subject: [manet] Comments on draft-ietf-manet-smf-06 > > > >=20 > > > > I am a bit disappointed that the current I-D for MANET=20 > SMF has no=20 > > > > provision for the encapsulation of MANET SMF datagrams in IPv4. > > > >=20 > > > > My points: > > > > * ip_id is only 16 bits wide, making its usefulness > > > limited in large > > > > MANET topologies. > > > > * Both BSD and Linux may be configured to randomize the > > > ip_id field > > > > as a defensive measure against IP host fingerprinting. > > > > * Choosing ip_id as a tag for the histogram based > > duplicate packet > > > > detection requires that NAT routers on the path examine=20 > ip_id, in=20 > > > > addition to being examined by any software multicast > > > forwarding plane > > > > implementation. > > > > * Encapsulation considerably simplifies implementation within=20 > > > > existing software multicast forwarding planes, again,=20 > re: BSD and=20 > > > > Linux. > > > > * The overhead of demux and rewrite of BSD mbufs or Linux > > > skbufs is > > > > likely to be the same, i.e. O(n), for ip_id versus an > > encapsulation > > > > header. > > > > * For multicast flows between PIM domains and MANET=20 > domains, the=20 > > > > overhead of prepending such encapsulation at the=20 > gateway is very=20 > > > > likely to be within acceptable performance limits. > > > >=20 > > > > I would therefore encourage you to consider the benefits of > > > allowing > > > > the use of encapsulation in SMF viz the above points. > > > >=20 > > > > Kind regards > > > > BMS > > > >=20 > > > >=20 > > > > _______________________________________________ > > > > manet mailing list > > > > manet@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/manet > > > >=20 > > > >=20 > > > >=20 > > > >=20 > > > > _______________________________________________ > > > > manet mailing list > > > > manet@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/manet > > > >=20 > > >=20 > > >=20 > > >=20 > >=20 > >=20 > >=20 >=20 >=20 >=20 _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Wed Dec 12 05:27: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 1J2Onx-0005nZ-Vq; Wed, 12 Dec 2007 05:27:05 -0500 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1J2Onw-0005nU-GE for manet-confirm+ok@megatron.ietf.org; Wed, 12 Dec 2007 05:27:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2Onw-0005nM-61 for manet@ietf.org; Wed, 12 Dec 2007 05:27:04 -0500 Received: from hpsmtp-eml17.kpnxchange.com ([213.75.38.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2Onv-0003Wy-OK for manet@ietf.org; Wed, 12 Dec 2007 05:27:04 -0500 Received: from hpsmtp-eml04.kpnxchange.com ([213.75.38.104]) by hpsmtp-eml17.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 12 Dec 2007 11:27:01 +0100 Received: from M90Teco ([86.83.9.22]) by hpsmtp-eml04.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 12 Dec 2007 11:27:01 +0100 From: "Teco Boot" To: "'Thomas Clausen'" , "'Dearlove, Christopher \(UK\)'" , "'Justin Dean'" Date: Wed, 12 Dec 2007 11:27:01 +0100 Message-ID: <001301c83ca9$888d99a0$99a8cce0$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acg8qYhZfvjgZxUsQKaAxa6g/WF0SQ== Content-Language: nl X-OriginalArrivalTime: 12 Dec 2007 10:27:01.0342 (UTC) FILETIME=[8844F7E0:01C83CA9] X-Spam-Score: -1.0 (-) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: manet@ietf.org Subject: [manet] NHDP - Link Quality measurement X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org On NHDP: === 14.4. Updating Link Quality A node MAY update link quality based on any information available to it. Particular cases that MAY be used include: o Information from the link layer, such as signal to noise ratio. o Receipt or loss of packets. If packets include a packet sequence number as defined in [1], then packets on a link SHOULD have sequential packet sequence numbers, whether or not they include HELLO messages. Link quality can be updated when a packet is received based on, for example, whether the last N out of M packets on the link were received, or a "leaky integrator" tracking packets. o Receipt or loss of HELLO messages. If the maximum interval between HELLO messages is known (such as by inclusion of a message TLV with Type == INTERVAL_TIME, as defined in [3], in HELLO messages) then the loss of HELLO messages can be determined without the need to receive a HELLO message. Note that if this case is combined with the previous case then care must be taken to avoid "double counting" a lost HELLO message in a lost packet === Are we sure we want to use packetbb packet ? I can imagine cases that this is invalid. Packets do not require a packet header or . Maybe sequence number is incremented for those packets. Or sequence number is randomized for security reasons. Or packetbb is being used for a protocol sending with another destination address or port number or lower layer protocol. By the way, the specification: If packets include a packet sequence number as defined in [1], then packets on a link SHOULD have sequential packet sequence numbers, whether or not they include HELLO messages. is not written down in packetbb. I think information from the link layer is far more important. Other available L2 information: statistics on number of retransmits and transmit failed indication for unicast traffic (sender) and the 802.11 MAC Header Retry field also for unicast traffic (receiver). This information is also used by data rate selection algorithm (if used), data rates higher than the minimum is a good indication that the link quality is OK. The NHDP link quality is for the bi-directional link, where both nodes may use the link quality mechanism. In the current text, the receiver side link quality is described. I think both nodes may use bi-directional link quality measurement. Teco. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Wed Dec 12 05:43: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 1J2P3z-0001Ay-Is; Wed, 12 Dec 2007 05:43:39 -0500 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1J2P3w-0001Ac-MU for manet-confirm+ok@megatron.ietf.org; Wed, 12 Dec 2007 05:43:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2P3w-0001AR-8D for manet@ietf.org; Wed, 12 Dec 2007 05:43:36 -0500 Received: from smtp1.bae.co.uk ([20.133.0.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2P3u-0003vC-B9 for manet@ietf.org; Wed, 12 Dec 2007 05:43:36 -0500 Received: from smtpc.greenlnk.net (smtpc.greenlnk.net [10.15.160.220]) by smtp1.bae.co.uk (Switch-3.1.10/Switch-3.1.10) with ESMTP id lBCAhSAG000448 for ; Wed, 12 Dec 2007 10:43:28 GMT Received: from glkas0002.GREENLNK.NET (glkas0002.greenlnk.net [10.15.184.52]) by smtpc.greenlnk.net (Switch-3.1.9/Switch-3.1.9) with ESMTP id lBCAhSIC022309 for ; Wed, 12 Dec 2007 10:43:28 GMT Received: from glkms1101.GREENLNK.NET ([10.15.184.109]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Wed, 12 Dec 2007 10:43:27 -0000 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1101.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.2499); Wed, 12 Dec 2007 10:43:27 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 12 Dec 2007 10:43:27 -0000 Message-ID: In-Reply-To: <001301c83ca9$888d99a0$99a8cce0$@nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: NHDP - Link Quality measurement Thread-Index: Acg8qYhZfvjgZxUsQKaAxa6g/WF0SQAACK4w References: <001301c83ca9$888d99a0$99a8cce0$@nl> From: "Dearlove, Christopher (UK)" To: "Teco Boot" , "Thomas Clausen" , "Justin Dean" X-OriginalArrivalTime: 12 Dec 2007 10:43:27.0532 (UTC) FILETIME=[D4159EC0:01C83CAB] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Cc: manet@ietf.org Subject: [manet] RE: NHDP - Link Quality measurement X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Comments below with >>>=20 -----Original Message----- From: Teco Boot [mailto:teco@inf-net.nl]=20 Sent: 12 December 2007 10:27 To: 'Thomas Clausen'; Dearlove, Christopher (UK); 'Justin Dean' Cc: manet@ietf.org Subject: NHDP - Link Quality measurement *** WARNING *** This mail has originated outside your organization, either from an external partner or the Global Internet.=20 Keep this in mind if you answer this message.=20 On NHDP: =3D=3D=3D 14.4. Updating Link Quality A node MAY update link quality based on any information available to it. Particular cases that MAY be used include: o Information from the link layer, such as signal to noise ratio. o Receipt or loss of packets. If packets include a packet sequence number as defined in [1], then packets on a link SHOULD have sequential packet sequence numbers, whether or not they include HELLO messages. Link quality can be updated when a packet is received based on, for example, whether the last N out of M packets on the link were received, or a "leaky integrator" tracking packets. o Receipt or loss of HELLO messages. If the maximum interval between HELLO messages is known (such as by inclusion of a message TLV with Type =3D=3D INTERVAL_TIME, as defined in [3], in HELLO messages) then the loss of HELLO messages can be determined without the need to receive a HELLO message. Note that if this case is combined with the previous case then care must be taken to avoid "double counting" a lost HELLO message in a lost packet =3D=3D=3D Are we sure we want to use packetbb packet ? >>> No, that's why it's a MAY. I can imagine cases that this is invalid. Packets do not require a packet header or . Maybe sequence number is incremented for those packets. Or sequence number is randomized for security reasons. Or packetbb is being used for a protocol sending with another destination address or port number or lower layer protocol. By the way, the specification:=20 If packets include a packet sequence number as defined in [1], then packets on a link SHOULD have sequential packet sequence numbers, whether or not they include HELLO messages. is not written down in packetbb. >>> That made me look back in the history. It did (although not in those >>> exact words of course) but it got removed at one point. Need to think >>> about that. But not including a packet sequence number is not in itself >>> a problem if you only increment the number when actually used. (It may >>> make the mechanism less useful, but not broken.) I think information from the link layer is far more important. >>> No disagreement here. But sometimes you just can't get what you want, >>> and an alternative is needed. Other available L2 information: statistics on number of retransmits and transmit failed indication for unicast traffic (sender) and the 802.11 MAC Header Retry field also for unicast traffic (receiver). This information is also used by data rate selection algorithm (if used), data rates higher than the minimum is a good indication that the link quality is OK. >>> NHDP isn't designed to run only over 802.11. And even when running >>> over 802.11, different drivers and OSes make different amounts of >>> information available. The NHDP link quality is for the bi-directional link, where both nodes may use the link quality mechanism. In the current text, the receiver side link quality is described. I think both nodes may use bi-directional link quality measurement. >>> To use bidirectional information you would need to transfer it. And >>> that is not what this is about. Receiver information is what NHDP >>> works on in general (do you receive HELLO messages?). Bidirectionality >>> is established by the (implicit) HELLO handshaking both agreeing that >>> the link is usable in their direction. ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Wed Dec 12 05:53:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2PD4-0001mr-E7; Wed, 12 Dec 2007 05:53:02 -0500 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1J2PD3-0001mX-5C for manet-confirm+ok@megatron.ietf.org; Wed, 12 Dec 2007 05:53:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2PD2-0001mO-RH for manet@ietf.org; Wed, 12 Dec 2007 05:53:00 -0500 Received: from ug-out-1314.google.com ([66.249.92.169]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2PD2-00048Q-E7 for manet@ietf.org; Wed, 12 Dec 2007 05:53:00 -0500 Received: by ug-out-1314.google.com with SMTP id u2so1538694uge.46 for ; Wed, 12 Dec 2007 02:52:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; bh=UzNR6LbjBFfJ1401s6j/knNNsqSqV5iPjLB6R7EHhCQ=; b=x/pGER26o745HEp0LMA2R3Y3fSOH5+JSCA5rrfHDY0aPDKM3D1y1cr5e18q4B3r1HoEJ5MjSIW3RKHxJZr4Jp05dGNctPwNi4NbeivR4qN1xPBMXIUdeQZ8YtQrKd3j+MIdfZLTY3Ml6zp5rvec+fZRkHqU0KggLHZBagHwgk58= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type; b=gs/XjU2u7GNpwvH0cQj/ecK6dMChL6771gZ/LHk54uxyuPk8qpNsh9/E/1O+t+P2ZA5hscuUBoevzYI2stsB3R33L6nRDAkkxy/lfHiRDqUgLwq2FpOC7kfqyDRnz9M9klwIaY1IZblb3xNPfPepdIcEqkpk2hWf0cPWXEcuZrA= Received: by 10.66.242.5 with SMTP id p5mr2100383ugh.4.1197456779700; Wed, 12 Dec 2007 02:52:59 -0800 (PST) Received: by 10.67.10.14 with HTTP; Wed, 12 Dec 2007 02:52:59 -0800 (PST) Message-ID: <5abf39e60712120252u506db38al79004c795504f7af@mail.gmail.com> Date: Wed, 12 Dec 2007 16:22:59 +0530 From: "Pushpita Chatterjee" To: manet@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Subject: [manet] Authenticate and configure the nodes in MANET X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0971201418==" Errors-To: manet-bounces@ietf.org --===============0971201418== Content-Type: multipart/alternative; boundary="----=_Part_844_14435946.1197456779689" ------=_Part_844_14435946.1197456779689 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Dear All, Can you suggest me how to configure the nodes of MANET? How authentication of a new naode want to join in MANET can be done without using key exchange mechanisms(non-cryptographic trust based solution)? With best regards Pushpita ------=_Part_844_14435946.1197456779689 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Dear All,
Can you suggest me how to configure the nodes of  MANET? 
How authentication of a new naode want to join in  MANET can be done without using key exchange mechanisms(non-cryptographic trust based solution)?
 
With best regards
Pushpita


 
------=_Part_844_14435946.1197456779689-- --===============0971201418== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet --===============0971201418==-- From manet-bounces@ietf.org Wed Dec 12 06:07:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2PRH-0008D2-1d; Wed, 12 Dec 2007 06:07:43 -0500 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1J2PRF-0008Cw-3C for manet-confirm+ok@megatron.ietf.org; Wed, 12 Dec 2007 06:07:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2PRE-0008Co-Mc for manet@ietf.org; Wed, 12 Dec 2007 06:07:40 -0500 Received: from hpsmtp-eml13.kpnxchange.com ([213.75.38.113]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2PRC-0004XW-GK for manet@ietf.org; Wed, 12 Dec 2007 06:07:40 -0500 Received: from hpsmtp-eml09.kpnxchange.com ([213.75.38.109]) by hpsmtp-eml13.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 12 Dec 2007 12:07:37 +0100 Received: from M90Teco ([86.83.9.22]) by hpsmtp-eml09.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 12 Dec 2007 12:07:37 +0100 From: "Teco Boot" To: "'Dearlove, Christopher \(UK\)'" , "'Thomas Clausen'" , "'Justin Dean'" References: <001301c83ca9$888d99a0$99a8cce0$@nl> In-Reply-To: Date: Wed, 12 Dec 2007 12:07:37 +0100 Message-ID: <001a01c83caf$349c48e0$9dd4daa0$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acg8qYhZfvjgZxUsQKaAxa6g/WF0SQAACK4wAAEMfPA= Content-Language: nl x-cr-hashedpuzzle: EEZw EHzt HyNE IcbN KIFj OdjH PDvE Y7WN agi4 dAec hber mY9F q/cI rwkN r/wq s2Ki; 4; YwBoAHIAaQBzAC4AZABlAGEAcgBsAG8AdgBlAEAAYgBhAGUAcwB5AHMAdABlAG0AcwAuAGMAbwBtADsAagBkAGUAYQBuAEAAaQB0AGQALgBuAHIAbAAuAG4AYQB2AHkALgBtAGkAbAA7AG0AYQBuAGUAdABAAGkAZQB0AGYALgBvAHIAZwA7AHQAaABvAG0AYQBzAEAAdABoAG8AbQBhAHMAYwBsAGEAdQBzAGUAbgAuAG8AcgBnAA==; Sosha1_v1; 7; {4717A071-E4E9-4435-A286-50D2B7FD4C5E}; dABlAGMAbwBAAGkAbgBmAC0AbgBlAHQALgBuAGwA; Wed, 12 Dec 2007 11:07:14 GMT; UgBFADoAIABOAEgARABQACAALQAgAEwAaQBuAGsAIABRAHUAYQBsAGkAdAB5ACAAbQBlAGEAcwB1AHIAZQBtAGUAbgB0AA== x-cr-puzzleid: {4717A071-E4E9-4435-A286-50D2B7FD4C5E} X-OriginalArrivalTime: 12 Dec 2007 11:07:37.0476 (UTC) FILETIME=[34518440:01C83CAF] X-Spam-Score: -1.0 (-) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: manet@ietf.org Subject: [manet] RE: NHDP - Link Quality measurement X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org > > The NHDP link quality is for the bi-directional link, where both nodes > may > use the link quality mechanism. In the current text, the receiver side > link > quality is described. I think both nodes may use bi-directional link > quality > measurement. > > >>> To use bidirectional information you would need to transfer it. And > >>> that is not what this is about. Receiver information is what NHDP > >>> works on in general (do you receive HELLO messages?). > Bidirectionality > >>> is established by the (implicit) HELLO handshaking both agreeing > that > >>> the link is usable in their direction. [Teco:] Chris, I agree on your comments. But what I meant is that a node may use L2 feedback on transmissions also, when this is available. This could speed up detecting a broken link. When problems with unicast packet transfer occur, this information can be used to qualify link quality. Usage with care, of course. And there is dependency on unicast traffic. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Fri Dec 14 02:00: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 1J34W5-0000MQ-Gr; Fri, 14 Dec 2007 01:59:25 -0500 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1J34W5-0000MJ-1p for manet-confirm+ok@megatron.ietf.org; Fri, 14 Dec 2007 01:59:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J34W4-0000MB-Oa for manet@ietf.org; Fri, 14 Dec 2007 01:59:24 -0500 Received: from kuber.nabble.com ([216.139.236.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J34W2-0005P1-Qv for manet@ietf.org; Fri, 14 Dec 2007 01:59:24 -0500 Received: from isper.nabble.com ([192.168.236.156]) by kuber.nabble.com with esmtp (Exim 4.63) (envelope-from ) id 1J34W2-0004iO-IC for manet@ietf.org; Thu, 13 Dec 2007 22:59:22 -0800 Message-ID: <14330324.post@talk.nabble.com> Date: Thu, 13 Dec 2007 22:59:22 -0800 (PST) From: "Mickey@shanghai" To: manet@ietf.org Subject: Re: [manet] IEEE 802.11e code MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Nabble-From: wl19992002@yahoo.com.cn X-Spam-Score: 0.2 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org http://www.tkn.tu-berlin.de/research/802.11e_ns2/ you could download the code from this.but when i install it i meet a little error.if you could use it successufully, could you tell me how you settle it ? my email wl19992002@yahoo.com.cn muby wrote: > > Hi everybody :) > > I am planning to work on QoS enhancements for multimedia traffic on > MANET, but so far I didnt found any available code for IEEE 802.11e which > i need to work on. please anybody like to share the code or can guide me > on how to implement 802.11e new features over the IEEE 802.11 a/b/g > original standard. > > Thank You. > > Mubarak A. J. > Univeriti Putra Malaysia > > > --------------------------------- > We won't tell. Get more on shows you hate to love > (and love to hate): Yahoo! TV's Guilty Pleasures list. > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet > > -- View this message in context: http://www.nabble.com/IEEE-802.11e-code-tp9447582p14330324.html Sent from the IETF - manet mailing list archive at Nabble.com. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Tue Dec 18 09:37: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 1J4dYi-00029w-DK; Tue, 18 Dec 2007 09:36:36 -0500 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1J4dYg-00029k-Gg for manet-confirm+ok@megatron.ietf.org; Tue, 18 Dec 2007 09:36:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4dYg-00029Y-6t for manet@ietf.org; Tue, 18 Dec 2007 09:36:34 -0500 Received: from nf-out-0910.google.com ([64.233.182.186]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J4dYe-0008MD-MC for manet@ietf.org; Tue, 18 Dec 2007 09:36:34 -0500 Received: by nf-out-0910.google.com with SMTP id d21so1247091nfb.39 for ; Tue, 18 Dec 2007 06:36:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:mime-version:content-type:message-id:cc:content-transfer-encoding:from:subject:date:to:x-mailer; bh=nC4xWR2oJqq6jwkgeUWH38Qym7ClWtLFbx8JO8ZtNUQ=; b=gmsNYHu+SOQdLob2S8nbq8OHbGf0ZUwZxAL4NfrLoNSk7HxkjnQj1T4LnoXPKHAPmWu0nVKpXQ567VP3ad7WxaN3Xt2bq3+UrM9nL3eqqeah5e4YmXyYaths+glzcZfCoQvy16TAuWq1ehWMbF2yGTBYbh6MER78Frm9UP1sBqY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:content-type:message-id:cc:content-transfer-encoding:from:subject:date:to:x-mailer; b=Nep1un1mqTnidSL6Nr0QtUv0gcErlwHF1eXLcl6NV61lJ8iNt1rzc+btMU+qfXAE76hxnRjogfCpjoBs1+eoJ9JZ9OsY3i6yrCcVyp+gpXPUvIWosM4mB1xIneLnqct5i1k1Cv+qqA44YHZ4geQme0wuBn9m61Isw+fIBvRJhBY= Received: by 10.78.186.9 with SMTP id j9mr10330090huf.49.1197988590287; Tue, 18 Dec 2007 06:36:30 -0800 (PST) Received: from ?192.168.17.149? ( [122.167.181.223]) by mx.google.com with ESMTPS id e9sm3646120muf.2007.12.18.06.36.27 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 18 Dec 2007 06:36:29 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <20DB1F00-4372-4C85-9AFF-2F04714AAC02@gmail.com> Content-Transfer-Encoding: 7bit From: Ian Chakeres Date: Tue, 18 Dec 2007 20:06:16 +0530 To: manet X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: Ross Callon Subject: [manet] Vancouver MANET WG Summary/Minutes X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org I have posted the minutes from our Vancouver meeting on the proceedings website. If you have any fixes (names, content, etc.), please email them to me. In the minutes, I've also included a meeting summary. Here is the meeting summary: ====================================================== Several WG documents have moved out of the WG and onto the IETF/IESG since the meeting in Chicago, and we hope to progress several more documents before Philadelphia. Please review and provide feedback on SMF, NHDP, OLSRv2, and DYMO now. http://tools.ietf.org/wg/manet/ During the meeting the SMF presentations identified several interesting challenges, and the solutions proposed in the Internet-Draft (I-D). I encourage everyone to review the document and slides from the meeting. https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=70 There were three discussion related presentations during the meeting. The first was on temporary loops and preventive measures. There were some questions as to the reason for the looping in the scenarios presented and the implementation. Additional, discussion on both the implementation and the problem are needed before proceeding. The second was on using jitter for data forwarding in conjunction with SMF. The preliminary experimental results show that it may be helpful in reducing collisions. The experimental results also demonstrate that packet loss may reduce the ability to reliably deliver packets within a strict hop count. Additional experimental results and discussion are encouraged. Third the concept of a "MANET Identifier" was discussed. The microphone discussion demonstrated the wide variety of possible uses for a MANET Identifier. The next revision of the I-D will include a description of the behavior (for DYMO), and some simple use case scenarios will be discussed on-list. During the open microphone period at the end of the meeting, the issue of metrics for NHPD/OLSRv2 was brought up. Since the WG time was up, the discussion on this topic will need to be held on-list. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet