From sratliff@cisco.com Sun Jan 1 11:23:18 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFBDA21F8E10; Sun, 1 Jan 2012 11:23:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kpv6Gm5ECXpn; Sun, 1 Jan 2012 11:23:18 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 0803121F8CF8; Sun, 1 Jan 2012 11:23:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sratliff@cisco.com; l=4319; q=dns/txt; s=iport; t=1325445798; x=1326655398; h=message-id:from:to:mime-version:subject:date:cc; bh=pLOI4kl5zYlCbqHmg4PKUgQLI03afsk21S1oLc8LFaE=; b=d7Fg7zbXNHcK7hw/k2pHdmHdmkG+6O5CISSUthh/6iYl+PrtjO5bc8ZY Gm9hSv+tJdE5Wu9zllEueo57XeCXScCnGYvxgCvsAKeO/OybPGl2JeO5H vIyt5WDWpMbvK6Igs4VEBUs/YHyo0AdHbJt19duEUPKO+cp8wh0dnrQvv w=; X-Files: packetbb-sec-shepherd.rtf : 3580 X-IronPort-AV: E=Sophos;i="4.71,441,1320624000"; d="rtf'212?scan'212,208,212";a="47987474" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-1.cisco.com with ESMTP; 01 Jan 2012 19:23:17 +0000 Received: from rtp-sratliff-8715.cisco.com (rtp-sratliff-8715.cisco.com [10.116.179.214]) by rcdn-core2-5.cisco.com (8.14.3/8.14.3) with ESMTP id q01JNG2o017946; Sun, 1 Jan 2012 19:23:16 GMT Message-Id: <5A1D2B8C-473B-4964-80A8-7FFCA4CE4746@cisco.com> From: Stan Ratliff To: ietf-secretary@ietf.org Content-Type: multipart/mixed; boundary=Apple-Mail-18--753743166 Mime-Version: 1.0 (Apple Message framework v936) Date: Sun, 1 Jan 2012 14:23:27 -0500 X-Mailer: Apple Mail (2.936) Cc: Joe Macker , "manet@ietf.org IETF" , Stan Ratliff Subject: [manet] Please publish draft-ietf-manet-packetbb-sec-07 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jan 2012 19:23:18 -0000 --Apple-Mail-18--753743166 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Please publish draft-ietf-manet-packetbb-sec-07 as a Standards Track RFC. The shepherd writeup is attached. Regards, Stan --Apple-Mail-18--753743166 Content-Disposition: attachment; filename=packetbb-sec-shepherd.rtf Content-Type: text/rtf; x-mac-hide-extension=yes; x-unix-mode=0644; name="packetbb-sec-shepherd.rtf" Content-Transfer-Encoding: 7bit {\rtf1\ansi\ansicpg1252\cocoartf949\cocoasubrtf540 {\fonttbl\f0\fmodern\fcharset0 Courier;} {\colortbl;\red255\green255\blue255;} \margl1440\margr1440\vieww15140\viewh14420\viewkind0 \deftab720 \pard\pardeftab720\ql\qnatural \f0\fs26 \cf0 (1.a) The document shepherd for this document is Stan Ratliff \ (sratliff@cisco.com). The shepherd has personally reviewed\ the document, and believes it is ready for forwarding to \ the IESG for publication.\ (1.b) The document has had adequate review from the working group, \ and from key non-working group members. The shepherd does not\ have any concerns about the depth or breadth of the reviews\ (1.c) The document shepherd does not have any concerns that the \ document needs more review. \ (1.d) There are no concerns that the responsible Area Directors or\ the IESG should be aware of. There were no IPR disclosures \ necessary.\ (1.e) Working group consensus behind the document is solid. There\ is strong consensus behind the core of very active members in\ the working group.\ (1.f) No appeals have been threatened; no extreme discontent has been\ indicated by anyone in the working group.\ (1.g) The document shepherd has personally verified the document satisfies\ all ID nits. The document has met all formal review criteria. \ (1.h) The document has split its references into normative and informative. \ There are no normative references to documents not ready for \ advancement. \ (1.i) The shepherd has verified that the IANA consideration section\ exists and is consistent with the body of the document. The \ reservations requested in the appropriate IANA registries. \ The IANA registries are clearly identified. The document does \ request two new IANA registries, and defines the proposed initial\ contents. It does not specifically suggest names for the new\ registries, however, the functionality is clear enough that names\ can easily be derived. The document does not outline a procedure\ for updating the registries. The document describes guidelines for\ expert review; as of this writing, the shepherd has not conferred\ with the responsible Area Director about said review. \ (1.j) The document shepherd has verified that the document has no \ sections that are written in a formal language (e.g. XML), so no\ automated checker (other than the ID nits) has been run. \ (1.k) The IESG approval announcement includes a Document \ Announcement Write-Up. Please provide such a Document \ Announcement Write-Up? Recent examples can be found in the\ "Action" announcements for approved documents. The approval \ announcement contains the following sections: \ Technical Summary \ The document defines the mechanism for including a cryptographic\ signature for the key items in an RFC 5444 formatted packet. The\ document also specifies how mutable fields in the packet should\ be handled, such that the resulting signature can be correctly \ verified by a recipient. \ Working Group Summary \ The document has been reviewed by the working group quite carefully.\ The document reflects the consensus of the working group. \ Document Quality \ The document has received careful review. The shepherd does not \ know of any existing implementations at this time. \ } --Apple-Mail-18--753743166 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit --Apple-Mail-18--753743166-- From internet-drafts@ietf.org Fri Jan 6 15:41:09 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 059361F0C6C; Fri, 6 Jan 2012 15:41:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.552 X-Spam-Level: X-Spam-Status: No, score=-102.552 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id svJk+9YWYoKk; Fri, 6 Jan 2012 15:41:08 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71FA61F0C57; Fri, 6 Jan 2012 15:41:08 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20120106234108.3705.17839.idtracker@ietfa.amsl.com> Date: Fri, 06 Jan 2012 15:41:08 -0800 Cc: manet@ietf.org Subject: [manet] I-D Action: draft-ietf-manet-nhdp-mib-11.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 23:41:09 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Mobile Ad-hoc Networks Working Group = of the IETF. Title : Definition of Managed Objects for the Neighborhood Disco= very Protocol Author(s) : Ulrich Herberg Robert G. Cole Ian D Chakeres Filename : draft-ietf-manet-nhdp-mib-11.txt Pages : 67 Date : 2012-01-06 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects for configuring parameters of the Neighborhood Discovery Protocol (NHDP) process on a router. The MIB defined in this memo, denoted NHDP-MIB, also reports state, performance information and notifications. This additional state and performance information is useful to troubleshoot problems and performance issues during neighbor discovery. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-manet-nhdp-mib-11.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-manet-nhdp-mib-11.txt From adrian@olddog.co.uk Sat Jan 7 12:12:51 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BC2E21F84DE for ; Sat, 7 Jan 2012 12:12:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id riaoN0sUk3Np for ; Sat, 7 Jan 2012 12:12:50 -0800 (PST) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) by ietfa.amsl.com (Postfix) with ESMTP id 5426821F84DD for ; Sat, 7 Jan 2012 12:12:50 -0800 (PST) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id q07KCm6s006947; Sat, 7 Jan 2012 20:12:49 GMT Received: from 950129200 (adsl-89-217-79-52.adslplus.ch [89.217.79.52]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id q07KCjdO006935 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 7 Jan 2012 20:12:48 GMT From: "Adrian Farrel" To: Date: Sat, 7 Jan 2012 20:12:37 -0000 Message-ID: <00ef01cccd78$babc3d50$3034b7f0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AczNeKDyf5ob6IhDRUWPVDWWRlUFEg== Content-Language: en-gb Cc: manet@ietf.org Subject: [manet] AD review of draft-ietf-manet-packetbb-sec X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jan 2012 20:12:51 -0000 Thanks for this draft. I have performed my AD review as usual and I=20 don't have any major issues. Before we start, one minor question to help me set my expectations... Did you have any expert security input on this work? I only ask in=20 order to try to work out what level of review we are likely to get later in the process. Otherwise I have a few nits and minor requests to polish the document. I hope they are straight forward and you can quickly spin a new=20 revision of the document which I can advance to IETF last call. Thanks, Adrian --- The text file I downloaded has a couple of interesting characters at the top. =EF=BB=BF --- Could you s/[RFC5444]/defined in RFC 5444/ =20 (A piece of pettiness, but citations cannot be made from the stand-alone Abstract) --- Section 10.1 does not include the caveat about other signatures that may already be present as found in 8.1 and 9.1. Is this intentional? --- Section 11 Don't "propose" anything! This is an I-D you plan to have converted into an RFC. You can "define" things if you feel the need for a word. --- Section 12.1.1 The rationale for separating the hash function and the cryptographic function into two octets instead of having all combinations in a single octet - possibly as TLV type extension - is twofold: First, if further hash functions or cryptographic functions are added in the future, the number space might not remain continuous. More importantly, the number space of possible combinations would be rapidly exhausted. As new or improved cryptographic mechanism are continuously being developed and introduced, this format should be able to accommodate such for the foreseeable future. I accept the reasoning for the contiguity. I don't accept the reasoning for number space exhaustion. Surely, you have the same number of bits (16) and the same amount of information (#hashfuncs * #cryptofuncs). Actually, in your method exhaustion is slightly more likely because you only have 8 bits for each category and so one of them could become exhausted independent of the other. I suggest removing the second motivation. Clarity of separation of function identifiers would serve as a second reason if you must have one. --- 12.1.1 The rationale for not including a field that lists parameters of the cryptographic signature in the TLV is, that before being able to validate a cryptographic signature, routers have to exchange or s/TLV is, that/TLV is that,/ --- Section 13 Please remove the RFC2119 language from this part of the IANA considerations section. It is typical to request IANA to perform = actions. --- Sections 13. through 13.6 The experimental ranges here are way too large unless you can give me a=20 really good reason. Understandable as MANET moves from experimental to standards track, but once you are standards track it is normal to restrict the experimental ranges to a very small (e.g. one) range of numbers. Have a look at=20 RFC 3692. Consider whether it would be enough to have just one or two code points reserved for experimentation. From valerio.arnaboldi@iit.cnr.it Mon Jan 9 00:13:10 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1272B21F862B for ; Mon, 9 Jan 2012 00:13:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.914 X-Spam-Level: ** X-Spam-Status: No, score=2.914 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, DATE_IN_PAST_24_48=1.219, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6EdoSx6Hc19A for ; Mon, 9 Jan 2012 00:13:09 -0800 (PST) Received: from redxiii.iit.cnr.it (dhcp5.iit.cnr.it [146.48.99.68]) by ietfa.amsl.com (Postfix) with ESMTP id A337721F8509 for ; Mon, 9 Jan 2012 00:13:07 -0800 (PST) Received: by redxiii.iit.cnr.it (Postfix, from userid 1000) id CDE8FE0133; Sat, 7 Jan 2012 13:00:01 +0100 (CET) Date: Sat, 07 Jan 2012 13:00:01 +0100 From: Valerio Arnaboldi To: manet@ietf.org Message-ID: <4f0833c1.O8VIjYNm+RvGX+lz%valerio.arnaboldi@iit.cnr.it> User-Agent: Heirloom mailx 12.5 6/20/10 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [manet] [ACM MobiOpp'12] Call For Demos - Deadline fast approaching X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2012 08:13:10 -0000 ============================================================================== *** Extended submission deadline --- January 10, 2012 *** ============================================================================== ------------------------------------------------------------------------------ CALL FOR DEMOS ACM MobiOpp 2012 Third International Workshop on Mobile Opportunistic Networks http://www.cl.cam.ac.uk/conference/mobiopp2012/ sponsored by ACM SIGMOBILE March 15-16, 2012 ETH Zuerich, Switzerland ------------------------------------------------------------------------------ The MobiOpp 2012 Demo session will offer high-quality demonstrations in the area of opportunistic networking and computing. MobiOpp 2012 invites demonstrations of working systems, innovative applications, groundbreaking ideas, and novel concepts related to MobiOpp. Demos from industrial researchers as well as demos from academia with a significant relevance to industry are encouraged. Topics of interest are the same as those for regular papers and include (but are not limited to): - Opportunistic and Delay-tolerant Networks - Mobile Urban Sensing and Crowdsensing - Novel Architectures, Middleware, Prototypes, and Testbeds - Routing, Dissemination, and Caching in Opportunistic Networks - Analysis of Opportunistic Protocols - Security, Trust, Privacy, and Cooperation in Opportunistic Networks - Social-aware Opportunistic Networking - Anti-censorship/surveillance opportunistic communications - Opportunistic Applications (e.g., opportunistic social networking, disaster and emergency situations, healthcare, communication in remote regions) - Mobility models for opportunistic networks The demos will be presented in a dedicated session, following a one-minute madness presentation. Demo abstracts will be included in the MobiOpp 2012 Proceedings in the form of extended abstracts and will be published in the ACM Digital Library. Submission Guidelines --------------------- Prospective contributors are expected to submit a demo proposal in the form of a short technical paper (no more than 2 pages) using the MobiOpp templates. The short paper must illustrate the research contribution of the demo, the practical setup, and the technical requirements. The evaluation criteria for the peer-review include: (1) extent and significance of the research contribution; (2) relevance to MobiOpp; (3) potential impact on the audience; (4) quality of the proposed implementation; (5) presentation quality. Only original material that has not been published or submitted for publication elsewhere may be submitted. Double submissions represent a violation of ACM policy (http://www.acm.org/pubs/rights.html) and will result in rejection from all conferences/journals involved. At least one author of each accepted demo proposal is required to register and present at the workshop. Detailed submission instructions can be found at: http://www.cl.cam.ac.uk/conference/mobiopp2012/demo.html Important Dates --------------- Submission deadline (extended): January 10, 2012 Notification of acceptance: January 13, 2012 Camera-ready due: January 20, 2012 MobiOpp 2012 Demo Co-Chairs ------------------------------ Chiara Boldrini, IIT-CNR, Italy Daniele Puccinelli, SUPSI, Switzerland ============================================== Valerio Arnaboldi - MOBIOPP2012 Publicity Chair Institute for Informatics and Telematics (IIT) Italian National Research Council (CNR) Via G. Moruzzi, 1 - 56124 Pisa, Italy phone: +39 050 315 2195 email: valerio.arnaboldi@iit.cnr.it From adrian@olddog.co.uk Mon Jan 9 09:07:13 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19B6411E807A for ; Mon, 9 Jan 2012 09:07:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k8h3-GEZ2vQm for ; Mon, 9 Jan 2012 09:07:12 -0800 (PST) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) by ietfa.amsl.com (Postfix) with ESMTP id B9E8A11E8093 for ; Mon, 9 Jan 2012 09:07:04 -0800 (PST) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id q09H72w3019882; Mon, 9 Jan 2012 17:07:03 GMT Received: from 950129200 (adsl-84-227-210-28.adslplus.ch [84.227.210.28]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id q09H70uC019844 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 9 Jan 2012 17:07:02 GMT From: "Adrian Farrel" To: References: <00ef01cccd78$babc3d50$3034b7f0$@olddog.co.uk> In-Reply-To: <00ef01cccd78$babc3d50$3034b7f0$@olddog.co.uk> Date: Mon, 9 Jan 2012 17:06:59 -0000 Message-ID: <013e01cccef1$1a7cabc0$4f760340$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQDoP3sIZs3NdoVdCSTG1ztBb1ARN5fNX54A Content-Language: en-gb Cc: manet@ietf.org Subject: Re: [manet] AD review of draft-ietf-manet-packetbb-sec X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2012 17:07:13 -0000 Please ignore the issue with spurious characters. This appears to be a = tools bug. A > -----Original Message----- > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > Sent: 07 January 2012 20:13 > To: draft-ietf-manet-packetbb-sec.all@tools.ietf.org > Cc: manet@ietf.org > Subject: AD review of draft-ietf-manet-packetbb-sec >=20 > Thanks for this draft. I have performed my AD review as usual and I > don't have any major issues. >=20 > Before we start, one minor question to help me set my expectations... >=20 > Did you have any expert security input on this work? I only ask in > order to try to work out what level of review we are likely to get > later in the process. >=20 > Otherwise I have a few nits and minor requests to polish the document. > I hope they are straight forward and you can quickly spin a new > revision of the document which I can advance to IETF last call. >=20 > Thanks, > Adrian >=20 > --- >=20 > The text file I downloaded has a couple of interesting characters at = the > top. >=20 > =EF=BB=BF >=20 > --- >=20 > Could you s/[RFC5444]/defined in RFC 5444/ >=20 > (A piece of pettiness, but citations cannot be made from the = stand-alone > Abstract) >=20 > --- >=20 > Section 10.1 does not include the caveat about other signatures that = may > already be present as found in 8.1 and 9.1. Is this intentional? >=20 > --- >=20 > Section 11 >=20 > Don't "propose" anything! This is an I-D you plan to have converted = into > an RFC. You can "define" things if you feel the need for a word. >=20 > --- >=20 > Section 12.1.1 >=20 > The rationale for separating the hash function and the = cryptographic > function into two octets instead of having all combinations in a > single octet - possibly as TLV type extension - is twofold: First, = if > further hash functions or cryptographic functions are added in the > future, the number space might not remain continuous. More > importantly, the number space of possible combinations would be > rapidly exhausted. As new or improved cryptographic mechanism are > continuously being developed and introduced, this format should be > able to accommodate such for the foreseeable future. >=20 > I accept the reasoning for the contiguity. I don't accept the = reasoning > for number space exhaustion. Surely, you have the same number of bits > (16) and the same amount of information (#hashfuncs * #cryptofuncs). >=20 > Actually, in your method exhaustion is slightly more likely because = you > only have 8 bits for each category and so one of them could become > exhausted independent of the other. >=20 > I suggest removing the second motivation. >=20 > Clarity of separation of function identifiers would serve as a second > reason if you must have one. >=20 > --- >=20 > 12.1.1 >=20 > The rationale for not including a field that lists parameters of = the > cryptographic signature in the TLV is, that before being able to > validate a cryptographic signature, routers have to exchange or >=20 > s/TLV is, that/TLV is that,/ >=20 > --- >=20 > Section 13 >=20 > Please remove the RFC2119 language from this part of the IANA > considerations section. It is typical to request IANA to perform = actions. >=20 > --- >=20 > Sections 13. through 13.6 >=20 > The experimental ranges here are way too large unless you can give me = a > really good reason. >=20 > Understandable as MANET moves from experimental to standards track, = but > once you are standards track it is normal to restrict the experimental > ranges to a very small (e.g. one) range of numbers. Have a look at > RFC 3692. Consider whether it would be enough to have just one or two > code points reserved for experimentation. From Chris.Dearlove@baesystems.com Tue Jan 10 04:34:36 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3202521F84B2 for ; Tue, 10 Jan 2012 04:34:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EbHTY6-D07JP for ; Tue, 10 Jan 2012 04:34:35 -0800 (PST) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by ietfa.amsl.com (Postfix) with ESMTP id 05B7021F84AE for ; Tue, 10 Jan 2012 04:34:34 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.71,486,1320624000"; d="scan'208";a="180819481" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 10 Jan 2012 12:34:33 +0000 Received: from glkms1102.GREENLNK.NET (glkms1102.greenlnk.net [10.108.36.193]) by baemasodc004.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id q0ACYXAS029864; Tue, 10 Jan 2012 12:34:33 GMT Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1102.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.4675); Tue, 10 Jan 2012 12:34:33 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Tue, 10 Jan 2012 12:34:32 -0000 Message-ID: In-Reply-To: <00ef01cccd78$babc3d50$3034b7f0$@olddog.co.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] AD review of draft-ietf-manet-packetbb-sec Thread-Index: AczNeKDyf5ob6IhDRUWPVDWWRlUFEgCGn0mQ References: <00ef01cccd78$babc3d50$3034b7f0$@olddog.co.uk> From: "Dearlove, Christopher (UK)" To: , X-OriginalArrivalTime: 10 Jan 2012 12:34:33.0359 (UTC) FILETIME=[34B999F0:01CCCF94] Cc: manet@ietf.org Subject: Re: [manet] AD review of draft-ietf-manet-packetbb-sec X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2012 12:34:36 -0000 With regard to the experimental code points, I think one really is too low, I can immediately see a requirement for two in something I may do, and I can imagine more. I would suggest at least four, possibly more. Would that be more palatable by making these Private as well as (or instead of?) Experimental use? --=20 Christopher Dearlove Technology Leader, Communications Group Communications and Networks Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194 Fax: +44 1245 242124 BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of A= drian Farrel Sent: 07 January 2012 20:13 To: draft-ietf-manet-packetbb-sec.all@tools.ietf.org Cc: manet@ietf.org Subject: [manet] AD review of draft-ietf-manet-packetbb-sec *** WARNING *** This message has originated outside your organisation, either from an external partner or the Global Internet.=20 Keep this in mind if you answer this message. To report a suspicious email, follow the instructions=20 on the Global Intranet at " / " =20 Thanks for this draft. I have performed my AD review as usual and I=20 don't have any major issues. Before we start, one minor question to help me set my expectations... Did you have any expert security input on this work? I only ask in=20 order to try to work out what level of review we are likely to get later in the process. Otherwise I have a few nits and minor requests to polish the document. I hope they are straight forward and you can quickly spin a new=20 revision of the document which I can advance to IETF last call. Thanks, Adrian --- The text file I downloaded has a couple of interesting characters at the top. =EF=BB=BF --- Could you s/[RFC5444]/defined in RFC 5444/ =20 (A piece of pettiness, but citations cannot be made from the stand-alone Abstract) --- Section 10.1 does not include the caveat about other signatures that may already be present as found in 8.1 and 9.1. Is this intentional? --- Section 11 Don't "propose" anything! This is an I-D you plan to have converted into an RFC. You can "define" things if you feel the need for a word. --- Section 12.1.1 The rationale for separating the hash function and the cryptographic function into two octets instead of having all combinations in a single octet - possibly as TLV type extension - is twofold: First, if further hash functions or cryptographic functions are added in the future, the number space might not remain continuous. More importantly, the number space of possible combinations would be rapidly exhausted. As new or improved cryptographic mechanism are continuously being developed and introduced, this format should be able to accommodate such for the foreseeable future. I accept the reasoning for the contiguity. I don't accept the reasoning for number space exhaustion. Surely, you have the same number of bits (16) and the same amount of information (#hashfuncs * #cryptofuncs). Actually, in your method exhaustion is slightly more likely because you only have 8 bits for each category and so one of them could become exhausted independent of the other. I suggest removing the second motivation. Clarity of separation of function identifiers would serve as a second reason if you must have one. --- 12.1.1 The rationale for not including a field that lists parameters of the cryptographic signature in the TLV is, that before being able to validate a cryptographic signature, routers have to exchange or s/TLV is, that/TLV is that,/ --- Section 13 Please remove the RFC2119 language from this part of the IANA considerations section. It is typical to request IANA to perform actions. --- Sections 13. through 13.6 The experimental ranges here are way too large unless you can give me a=20 really good reason. Understandable as MANET moves from experimental to standards track, but once you are standards track it is normal to restrict the experimental ranges to a very small (e.g. one) range of numbers. Have a look at=20 RFC 3692. Consider whether it would be enough to have just one or two code points reserved for experimentation. _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet ******************************************************************** 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. ******************************************************************** From fabio.pezzoni@iit.cnr.it Tue Jan 10 06:02:05 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1262821F8624 for ; Tue, 10 Jan 2012 06:02:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.355 X-Spam-Level: *** X-Spam-Status: No, score=3.355 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FRT_ADULT2=1.474, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b2qCcrdWtsun for ; Tue, 10 Jan 2012 06:02:04 -0800 (PST) Received: from smtp.iit.cnr.it (mx7.iit.cnr.it [146.48.98.140]) by ietfa.amsl.com (Postfix) with ESMTP id B21A321F861A for ; Tue, 10 Jan 2012 06:02:03 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.iit.cnr.it (Postfix) with ESMTP id 94A6512EE82 for ; Tue, 10 Jan 2012 15:01:57 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mx7.iit.cnr.it Received: from smtp.iit.cnr.it ([127.0.0.1]) by localhost (mx7.iit.cnr.it [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S-13xR1BU5gE for ; Tue, 10 Jan 2012 15:01:55 +0100 (CET) Received: from irina.iit.cnr.it (dhcp13.iit.cnr.it [146.48.99.76]) by smtp.iit.cnr.it (Postfix) with ESMTPA id BC23912EE81 for ; Tue, 10 Jan 2012 15:01:55 +0100 (CET) Date: Tue, 10 Jan 2012 15:00:01 +0100 From: Fabio Pezzoni To: manet@ietf.org Message-ID: <4f0c4461.Uuk1WX6FWdyt7YYw%fabio.pezzoni@iit.cnr.it> User-Agent: Heirloom mailx 12.4 7/29/08 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [manet] [IEEE AOC 2012] Call for Papers X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2012 14:02:05 -0000 -------------------------------------------------------------------------------- CALL FOR PAPERS Sixth IEEE WoWMoM Workshop on Autonomic and Opportunistic Communications (AOC 2012) June 25, 2012 - San Francisco, California, USA http://cnd.iit.cnr.it/aoc2012/ jointly supported by the SCAMPI project funded by the FP7-ICT Programme under the Future Internet Research and Experimentation (FIRE) initiative http://www.ict-scampi.eu/ and RECOGNITION project funded by the FP7-ICT Programme under the Future and Emerging Technologies (FET) initiative http://www.recognition-project.eu/ Fast Track on Computer Communication Journal http://www.elsevier.com/locate/comcom **** Submission Deadline --- February 17, 2012 **** -------------------------------------------------------------------------------- The diffusion of lightweight, powerful portable devices, also enriched with a variety of sensing capabilities, is enabling new ways for users' communication, and laying the foundation for realizing the ubiquitous networking idea. Acting either as the main communication mode or as complement to existing mobile network infrastructures, opportunistic networking can leverage the mobility of end users and enhance their communication capabilities. The opportunistic exploitation of extemporary contacts among the users of the network paves the way to a number of applications but also poses new and challenging problems to the networking research community. The AOC 2012 workshop aims at serving as a meeting point for people working in the area and a forum for exchanging ideas, discussing solutions, and sharing experiences among researchers, professionals, and application developers, both from industry and academia. As with the previous five editions of the AOC workshop series, the scope of this year's workshop will remain on general issues related to opportunistic networking and computing. Yet, AOC 2012 will have a primary interest in new directions of opportunistic communications, such as service composition techniques, scenarios of co-existence with infrastructure networks, and insights to their operation coming from other disciplines such as game theory and cognitive psychology. The workshop will solicit original papers addressing theoretical and practical aspects of autonomic and opportunistic communications but also papers describing prototype implementations and deployments. Topics of interest for AOC 2012 include, but are not limited to: * Routing, transport, and reliability issues * Techniques for data dissemination and replication * Applications and middleware support, mobile social networking applications * Mobility models and statistical analysis of mobility traces * Context and social awareness mechanisms and algorithms * Co-existence of opportunistic networks with infrastructure mobile wireless networks * Service composition in autonomic and opportunistic networks * Cognition-driven information processing and decision making * Performance modelling, scaling laws, and fundamental limits for autonomic and opportunistic communications * Game-theoretic insights to the operation of autonomic and opportunistic networks * Participatory and urban sensing in autonomic and opportunistic networks * Trust, security, and reputation * Autonomic and opportunistic communication testbeds and prototypes, measurement data from real experiments * Socio-economic models for autonomic and opportunistic communications PAPER SUBMISSION AND PUBLICATION -------------------------------- Papers should neither have been published elsewhere nor being currently under review by another conference or journal. Manuscripts are limited to 6 pages, single spacing, double column, and must strictly adhere to the template format. Guidelines on paper submission and formatting are available at http://cnd.iit.cnr.it/aoc2012/. Accepted papers will appear in the symposium proceedings published by IEEE. At least one author of each accepted paper is required to register and present his/her work at the workshop. There will be no separate registration for workshop, but one single registration will cover both conference and workshops participation. Extended versions of workshop selected papers will be considered for possible fast track publication on the Computer Communications Journal (Elsevier). IMPORTANT DATES --------------- Full papers due: February 17, 2012 Notification: April 4, 2012 Workshop: June 25, 2012 ORGANIZING COMMITTEE -------------------- WORKSHOP Chairs Merkouris Karaliopoulos, University of Athens, Greece Chiara Boldrini, IIT-CNR, Italy STEERING Committee Marco Conti, IIT-CNR, Italy Silvia Giordano, SUPSI, Switzerland Ioannis Stavrakakis, University of Athens, Greece PUBLICITY Chairs Fabio Pezzoni, IIT-CNR, Italy Pushpendra Singh, IIIT Delhi, India PROGRAM COMMITTEE (confirmed so far) ------------------------------------ Gergely Acs, BUTE, Hungary Eleonora Borgia, IIT-CNR, Italy Vania Conan, Thales, France Serge Fdida, UPMC, Paris VI, France Laura Galluccio, University of Catania, Italy Nidhi Hegde, Technicolor, France Tristan Henderson, University of St. Andrews, UK Gunnar Karlsson, KTH, Sweden Mohan Kumar, University of Texas at Arlington, USA Kyunghan Lee, North Carolina State University, USA Franck Legendre, ETH Zurich, Switzerland Daniele Miorandi, Create-net, Italy Refik Molva, Eurecom, France Valtteri Niemi, Nokia, Switzerland Katia Obraczka, University of California, Santa Cruz, USA Konstantinos Oikonomou, Ionian University, Greece Joerg Ott, HUT, Finland Elena Pagani, Universita' degli Studi di Milano, Italy Andrea Passarella, IIT-CNR, Italy Daniele Puccinelli, SUPSI, Switzerland Christian Rohner, Uppsala University, Sweden Fabrizio Sestini, EU Commission Abdullatif Shikfa, Alcatel Lucent Bell Labs, France Thrasyvoulos Spyropoulos, EURECOM, France Roger Whitaker, Cardiff University, UK Hongyi Wu, University of Louisiana at Lafayette, USA Eiko Yoneki, University of Cambridge, UK Franco Zambonelli, University of Modena-Reggio, Italy ==================================================== Fabio Pezzoni - AOC2012 Publicity Chair Institute for Informatics and Telematics (IIT) Italian National Research Council (CNR) Via G. Moruzzi, 1 - 56124 Pisa, Italy phone: +39 050 315 2195 email: fabio.pezzoni@iit.cnr.it ==================================================== From adrian@olddog.co.uk Tue Jan 10 13:29:41 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDD3521F85FD for ; Tue, 10 Jan 2012 13:29:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NajwIMedq5DD for ; Tue, 10 Jan 2012 13:29:41 -0800 (PST) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) by ietfa.amsl.com (Postfix) with ESMTP id 8CF1921F85FC for ; Tue, 10 Jan 2012 13:29:40 -0800 (PST) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id q0ALTaVl021424; Tue, 10 Jan 2012 21:29:36 GMT Received: from 950129200 (adsl-84-227-210-28.adslplus.ch [84.227.210.28]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id q0ALTUOK021390 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 10 Jan 2012 21:29:34 GMT From: "Adrian Farrel" To: "'Dearlove, Christopher \(UK\)'" , References: <00ef01cccd78$babc3d50$3034b7f0$@olddog.co.uk> In-Reply-To: Date: Tue, 10 Jan 2012 21:29:30 -0000 Message-ID: <043a01cccfde$f2f4a370$d8ddea50$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQDoP3sIZs3NdoVdCSTG1ztBb1ARNwGjth0zl8IgF9A= Content-Language: en-gb Cc: manet@ietf.org Subject: Re: [manet] AD review of draft-ietf-manet-packetbb-sec X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2012 21:29:41 -0000 Hi Chris, If it is an experiment I believe we should call it such (i.e. something = we might later bring back and standardise [or possibly put in the trash]). I = think that MANET has a proud tradition of doing experimental work and sorting the = wheat from the chaff. Few WGs come close to doing it better. We can negotiate on the number of code points. Usually it turns out that = one is enough, because everything else can be hung on subcodes. But I could = live with four. A > -----Original Message----- > From: Dearlove, Christopher (UK) = [mailto:Chris.Dearlove@baesystems.com] > Sent: 10 January 2012 12:35 > To: adrian@olddog.co.uk; = draft-ietf-manet-packetbb-sec.all@tools.ietf.org > Cc: manet@ietf.org > Subject: RE: [manet] AD review of draft-ietf-manet-packetbb-sec >=20 > With regard to the experimental code points, I think one really is too = low, > I can immediately see a requirement for two in something I may do, and > I can imagine more. I would suggest at least four, possibly more. = Would > that be more palatable by making these Private as well as (or instead = of?) > Experimental use? >=20 > -- > Christopher Dearlove > Technology Leader, Communications Group > Communications and Networks Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 Fax: +44 1245 242124 >=20 > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, > Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 >=20 > -----Original Message----- > From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf = Of > Adrian Farrel > Sent: 07 January 2012 20:13 > To: draft-ietf-manet-packetbb-sec.all@tools.ietf.org > Cc: manet@ietf.org > Subject: [manet] AD review of draft-ietf-manet-packetbb-sec >=20 >=20 > *** WARNING *** >=20 > This message has originated outside your organisation, > either from an external partner or the Global Internet. > Keep this in mind if you answer this message. > To report a suspicious email, follow the instructions > on the Global Intranet at " / " >=20 >=20 >=20 >=20 > Thanks for this draft. I have performed my AD review as usual and I > don't have any major issues. >=20 > Before we start, one minor question to help me set my expectations... >=20 > Did you have any expert security input on this work? I only ask in > order to try to work out what level of review we are likely to get > later in the process. >=20 > Otherwise I have a few nits and minor requests to polish the document. > I hope they are straight forward and you can quickly spin a new > revision of the document which I can advance to IETF last call. >=20 > Thanks, > Adrian >=20 > --- >=20 > The text file I downloaded has a couple of interesting characters at = the > top. >=20 > =EF=BB=BF >=20 > --- >=20 > Could you s/[RFC5444]/defined in RFC 5444/ >=20 > (A piece of pettiness, but citations cannot be made from the = stand-alone > Abstract) >=20 > --- >=20 > Section 10.1 does not include the caveat about other signatures that = may > already be present as found in 8.1 and 9.1. Is this intentional? >=20 > --- >=20 > Section 11 >=20 > Don't "propose" anything! This is an I-D you plan to have converted = into > an RFC. You can "define" things if you feel the need for a word. >=20 > --- >=20 > Section 12.1.1 >=20 > The rationale for separating the hash function and the = cryptographic > function into two octets instead of having all combinations in a > single octet - possibly as TLV type extension - is twofold: First, = if > further hash functions or cryptographic functions are added in the > future, the number space might not remain continuous. More > importantly, the number space of possible combinations would be > rapidly exhausted. As new or improved cryptographic mechanism are > continuously being developed and introduced, this format should be > able to accommodate such for the foreseeable future. >=20 > I accept the reasoning for the contiguity. I don't accept the = reasoning > for number space exhaustion. Surely, you have the same number of bits > (16) and the same amount of information (#hashfuncs * #cryptofuncs). >=20 > Actually, in your method exhaustion is slightly more likely because = you > only have 8 bits for each category and so one of them could become > exhausted independent of the other. >=20 > I suggest removing the second motivation. >=20 > Clarity of separation of function identifiers would serve as a second > reason if you must have one. >=20 > --- >=20 > 12.1.1 >=20 > The rationale for not including a field that lists parameters of = the > cryptographic signature in the TLV is, that before being able to > validate a cryptographic signature, routers have to exchange or >=20 > s/TLV is, that/TLV is that,/ >=20 > --- >=20 > Section 13 >=20 > Please remove the RFC2119 language from this part of the IANA > considerations section. It is typical to request IANA to perform = actions. >=20 > --- >=20 > Sections 13. through 13.6 >=20 > The experimental ranges here are way too large unless you can give me = a > really good reason. >=20 > Understandable as MANET moves from experimental to standards track, = but > once you are standards track it is normal to restrict the experimental > ranges to a very small (e.g. one) range of numbers. Have a look at > RFC 3692. Consider whether it would be enough to have just one or two > code points reserved for experimentation. >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet >=20 >=20 > ************************************************************** > ****** > 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. > ************************************************************** > ****** From adrian@olddog.co.uk Fri Jan 20 10:13:36 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB21121F867E for ; Fri, 20 Jan 2012 10:13:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.51 X-Spam-Level: X-Spam-Status: No, score=-2.51 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F6JAKtB0mfnl for ; Fri, 20 Jan 2012 10:13:36 -0800 (PST) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by ietfa.amsl.com (Postfix) with ESMTP id 3E4AA21F8677 for ; Fri, 20 Jan 2012 10:13:35 -0800 (PST) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id q0KIDUwV024811 for ; Fri, 20 Jan 2012 18:13:31 GMT Received: from 950129200 ([195.43.57.40]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id q0KIDRea024722 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 20 Jan 2012 18:13:30 GMT From: "Adrian Farrel" To: References: <20120120165739.5271A21F8646@ietfa.amsl.com> In-Reply-To: <20120120165739.5271A21F8646@ietfa.amsl.com> Date: Fri, 20 Jan 2012 18:13:28 -0000 Message-ID: <010001ccd79f$37b20fd0$a7162f70$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQE83viumCfODFj2kAngEisJzL6CC5c1eoIw Content-Language: en-gb Subject: [manet] FW: Designated Experts for MANET Registries X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2012 18:13:36 -0000 FYI > -----Original Message----- > From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf Of IESG > Secretary > Sent: 20 January 2012 16:58 > To: IANA > Cc: iesg@ietf.org > Subject: Designated Experts for MANET Registries > > IANA: > > The IESG has approved Joe Macker (joseph.macker@nrl.navy.mil) > and Stan Ratliff (sratliff@cisco.com) as the designated experts > for the MANET registries defined in RFCs 5444, 5497, and 6130. > > Best regards, > IESG Secretary From internet-drafts@ietf.org Fri Jan 27 15:56:52 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2006F21F861B; Fri, 27 Jan 2012 15:56:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.581 X-Spam-Level: X-Spam-Status: No, score=-102.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CCiZJU97vP9w; Fri, 27 Jan 2012 15:56:51 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88B9C21F85D4; Fri, 27 Jan 2012 15:56:51 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20120127235651.12256.86347.idtracker@ietfa.amsl.com> Date: Fri, 27 Jan 2012 15:56:51 -0800 Cc: manet@ietf.org Subject: [manet] I-D Action: draft-ietf-manet-smf-13.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2012 23:56:52 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Mobile Ad-hoc Networks Working Group = of the IETF. Title : Simplified Multicast Forwarding Author(s) : Joseph Macker Filename : draft-ietf-manet-smf-13.txt Pages : 53 Date : 2012-01-27 This document describes a Simplified Multicast Forwarding (SMF) mechanism that provides basic Internet Protocol (IP) multicast forwarding suitable for limited wireless mesh and mobile ad hoc network (MANET) use. It is mainly applicable in situations where efficient flooding represents an acceptable engineering design trade- off. It defines techniques for multicast duplicate packet detection (DPD), to be applied in the forwarding process, for both IPv4 and IPv6 protocol use. This document also specifies optional mechanisms for using reduced relay sets to achieve more efficient multicast data distribution within a mesh topology as compared to classic flooding. Interactions with other protocols, such as use of information provided by concurrently running unicast routing protocols, or interaction with other multicast protocols, as well as multiple deployment approaches are also described. Distributed algorithms for selecting reduced relay sets and related discussion are provided in the appendices. Basic issues relating to the operation of multicast MANET border routers are discussed, but ongoing work remains in this area, and is beyond the scope of this document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-manet-smf-13.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-manet-smf-13.txt From mech.loulou@gmail.com Sun Jan 29 03:37:02 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C052C21F8518 for ; Sun, 29 Jan 2012 03:37:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.739 X-Spam-Level: X-Spam-Status: No, score=-1.739 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dee9HZHcmx42 for ; Sun, 29 Jan 2012 03:37:02 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2AA4421F84CF for ; Sun, 29 Jan 2012 03:37:02 -0800 (PST) Received: by vbbfr13 with SMTP id fr13so2326163vbb.31 for ; Sun, 29 Jan 2012 03:37:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=JLb+Z67mVInt1+uNSRS3LdRMtm8fcnaOD8pWjHPMlSU=; b=sEp2q4EnaQYZkDJabImdX98YF95zLlY7rLVsWxKaaKrQkskTo0XcFz6LAm/bK6rTUj dDfTFo+39IQpR+RsTlHQqMO8bsGq73Db6G8OExxZAH4GD6kj5a0WF8Xe9n6N4TsbVGL8 kom7NYHaqycqNvAhhjQbnq96TNm48irLkFwms= MIME-Version: 1.0 Received: by 10.52.67.229 with SMTP id q5mr6059811vdt.14.1327837021634; Sun, 29 Jan 2012 03:37:01 -0800 (PST) Received: by 10.52.111.169 with HTTP; Sun, 29 Jan 2012 03:37:01 -0800 (PST) Date: Sun, 29 Jan 2012 12:37:01 +0100 Message-ID: From: Leila M To: manet@ietf.org Content-Type: multipart/alternative; boundary=20cf307811a0fe80bb04b7a925a3 Subject: [manet] routing protocols and attacks X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jan 2012 11:44:01 -0000 --20cf307811a0fe80bb04b7a925a3 Content-Type: text/plain; charset=ISO-8859-1 hi, what are Manet routing protocols that can be affected by a DoS or DDoS attacks thanks --20cf307811a0fe80bb04b7a925a3 Content-Type: text/html; charset=ISO-8859-1
hi,

what are Manet routing protocols that can be affected by a DoS or DDoS attacks

thanks
--20cf307811a0fe80bb04b7a925a3-- From mech.loulou@gmail.com Sun Jan 29 03:52:45 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9580C21F847A for ; Sun, 29 Jan 2012 03:52:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.058 X-Spam-Level: X-Spam-Status: No, score=-3.058 tagged_above=-999 required=5 tests=[AWL=0.540, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZoyEzjeYFlh5 for ; Sun, 29 Jan 2012 03:52:45 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 12CEF21F8472 for ; Sun, 29 Jan 2012 03:52:44 -0800 (PST) Received: by vbbfr13 with SMTP id fr13so2329632vbb.31 for ; Sun, 29 Jan 2012 03:52:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=arcNVqZdo99IabXi1RceU4pY5+PzFKPmsy7WeyYYyas=; b=fNT4uhHdVQMN92gMZjfSHAXtut01OiZD9OwtyvUrdFXR97p7G3VNq3Bg4tUWPVobb1 e7PDvonKgsYKrnxKLnpzTkj7hRq1IOR+ZfwiFVq+6Wg+XT8MboS8LzHtzI3plGeJ+itN XUJrt3kxMG0TcpHn6le1LbAXcN64zD+zsL1Cc= MIME-Version: 1.0 Received: by 10.52.91.200 with SMTP id cg8mr3722389vdb.65.1327837964668; Sun, 29 Jan 2012 03:52:44 -0800 (PST) Received: by 10.52.111.169 with HTTP; Sun, 29 Jan 2012 03:52:44 -0800 (PST) Date: Sun, 29 Jan 2012 12:52:44 +0100 Message-ID: From: Leila M To: manet@ietf.org Content-Type: multipart/alternative; boundary=bcaec50164ff3410aa04b7a95e4e Subject: [manet] routing protocols and attacks X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jan 2012 11:52:45 -0000 --bcaec50164ff3410aa04b7a95e4e Content-Type: text/plain; charset=ISO-8859-1 hi, what are Manet routing protocols that can be affected by a DoS or DDoS attacks thanks --bcaec50164ff3410aa04b7a95e4e Content-Type: text/html; charset=ISO-8859-1
hi,

what are Manet routing protocols that can be affected by a DoS or DDoS attacks

thanks
--bcaec50164ff3410aa04b7a95e4e-- From aaron@lo-res.org Sun Jan 29 05:40:58 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6E2221F8546 for ; Sun, 29 Jan 2012 05:40:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yoyo3BcNjQpO for ; Sun, 29 Jan 2012 05:40:58 -0800 (PST) Received: from mute.lo-res.org (mail.lo-res.org [IPv6:2a02:60:1:1::3]) by ietfa.amsl.com (Postfix) with ESMTP id 4FFBE21F852E for ; Sun, 29 Jan 2012 05:40:58 -0800 (PST) Received: from [192.168.101.105] (chello080108029230.5.11.vie.surfer.at [80.108.29.230]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mute.lo-res.org (Postfix) with ESMTPSA id ECE6C9BC504; Sun, 29 Jan 2012 14:40:55 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: multipart/signed; boundary="Apple-Mail=_79C998ED-CA08-4BDA-AE47-A2B72E7CE23B"; protocol="application/pgp-signature"; micalg=pgp-sha1 From: "L. Aaron Kaplan" In-Reply-To: Date: Sun, 29 Jan 2012 14:40:53 +0100 Message-Id: References: To: Leila M X-Mailer: Apple Mail (2.1251.1) Cc: manet@ietf.org Subject: Re: [manet] routing protocols and attacks X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jan 2012 13:40:58 -0000 --Apple-Mail=_79C998ED-CA08-4BDA-AE47-A2B72E7CE23B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Jan 29, 2012, at 12:52 PM, Leila M wrote: > hi, >=20 > what are Manet routing protocols that can be affected by a DoS or DDoS = attacks >=20 ???? Every MANET protocol can be affected by DDOS attacks just like any other = service on the internet. I guess you have to be more specific to get a meaningful answer on this = list. my 2 cents, Aaron Kaplan --Apple-Mail=_79C998ED-CA08-4BDA-AE47-A2B72E7CE23B Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) iEYEARECAAYFAk8lTGgACgkQxEgyMttZ8YwSXQCgrycYM3gt0sIsAJHd7prAtISW LjYAn23ktxVIuBaix+PnHvYSbdgY1P/7 =GvZ0 -----END PGP SIGNATURE----- --Apple-Mail=_79C998ED-CA08-4BDA-AE47-A2B72E7CE23B-- From fabio.pezzoni@iit.cnr.it Mon Jan 30 08:00:08 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDA6F21F8678 for ; Mon, 30 Jan 2012 08:00:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.616 X-Spam-Level: ** X-Spam-Status: No, score=2.616 tagged_above=-999 required=5 tests=[AWL=0.002, BAYES_20=-0.74, FRT_ADULT2=1.474, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yMmiGpebktIn for ; Mon, 30 Jan 2012 08:00:07 -0800 (PST) Received: from smtp.iit.cnr.it (mx8.iit.cnr.it [146.48.98.141]) by ietfa.amsl.com (Postfix) with ESMTP id 598EF21F86AA for ; Mon, 30 Jan 2012 08:00:07 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.iit.cnr.it (Postfix) with ESMTP id 07C6C12F094 for ; Mon, 30 Jan 2012 17:00:01 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mx8.iit.cnr.it Received: from smtp.iit.cnr.it ([127.0.0.1]) by localhost (mx8.iit.cnr.it [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q8H2RAdFuZxT for ; Mon, 30 Jan 2012 16:59:58 +0100 (CET) Received: from irina.iit.cnr.it (irina-lan.iit.cnr.it [146.48.96.79]) by smtp.iit.cnr.it (Postfix) with ESMTPA id C20F812F07E for ; Mon, 30 Jan 2012 16:59:58 +0100 (CET) Date: Mon, 30 Jan 2012 17:00:01 +0100 From: Fabio Pezzoni To: manet@ietf.org Message-ID: <4f26be81.brZ2bYQRRxvqV/Ef%fabio.pezzoni@iit.cnr.it> User-Agent: Heirloom mailx 12.4 7/29/08 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [manet] [IEEE AOC 2012] Call for Papers X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 16:00:08 -0000 -------------------------------------------------------------------------------- CALL FOR PAPERS Sixth IEEE WoWMoM Workshop on Autonomic and Opportunistic Communications (AOC 2012) June 25, 2012 - San Francisco, California, USA http://cnd.iit.cnr.it/aoc2012/ jointly supported by the SCAMPI project funded by the FP7-ICT Programme under the Future Internet Research and Experimentation (FIRE) initiative http://www.ict-scampi.eu/ and RECOGNITION project funded by the FP7-ICT Programme under the Future and Emerging Technologies (FET) initiative http://www.recognition-project.eu/ Fast Track on Computer Communication Journal http://www.elsevier.com/locate/comcom **** Submission Deadline --- February 17, 2012 **** -------------------------------------------------------------------------------- The diffusion of lightweight, powerful portable devices, also enriched with a variety of sensing capabilities, is enabling new ways for users' communication, and laying the foundation for realizing the ubiquitous networking idea. Acting either as the main communication mode or as complement to existing mobile network infrastructures, opportunistic networking can leverage the mobility of end users and enhance their communication capabilities. The opportunistic exploitation of extemporary contacts among the users of the network paves the way to a number of applications but also poses new and challenging problems to the networking research community. The AOC 2012 workshop aims at serving as a meeting point for people working in the area and a forum for exchanging ideas, discussing solutions, and sharing experiences among researchers, professionals, and application developers, both from industry and academia. As with the previous five editions of the AOC workshop series, the scope of this year's workshop will remain on general issues related to opportunistic networking and computing. Yet, AOC 2012 will have a primary interest in new directions of opportunistic communications, such as service composition techniques, scenarios of co-existence with infrastructure networks, and insights to their operation coming from other disciplines such as game theory and cognitive psychology. The workshop will solicit original papers addressing theoretical and practical aspects of autonomic and opportunistic communications but also papers describing prototype implementations and deployments. Topics of interest for AOC 2012 include, but are not limited to: * Routing, transport, and reliability issues * Techniques for data dissemination and replication * Applications and middleware support, mobile social networking applications * Mobility models and statistical analysis of mobility traces * Context and social awareness mechanisms and algorithms * Co-existence of opportunistic networks with infrastructure mobile wireless networks * Service composition in autonomic and opportunistic networks * Cognition-driven information processing and decision making * Performance modelling, scaling laws, and fundamental limits for autonomic and opportunistic communications * Game-theoretic insights to the operation of autonomic and opportunistic networks * Participatory and urban sensing in autonomic and opportunistic networks * Trust, security, and reputation * Autonomic and opportunistic communication testbeds and prototypes, measurement data from real experiments * Socio-economic models for autonomic and opportunistic communications PAPER SUBMISSION AND PUBLICATION -------------------------------- Papers should neither have been published elsewhere nor being currently under review by another conference or journal. Manuscripts are limited to 6 pages, single spacing, double column, and must strictly adhere to the template format. Guidelines on paper submission and formatting are available at http://cnd.iit.cnr.it/aoc2012/. Accepted papers will appear in the symposium proceedings published by IEEE. At least one author of each accepted paper is required to register and present his/her work at the workshop. There will be no separate registration for workshop, but one single registration will cover both conference and workshops participation. Extended versions of workshop selected papers will be considered for possible fast track publication on the Computer Communications Journal (Elsevier). IMPORTANT DATES --------------- Full papers due: February 17, 2012 Notification: April 4, 2012 Workshop: June 25, 2012 ORGANIZING COMMITTEE -------------------- WORKSHOP Chairs Merkouris Karaliopoulos, University of Athens, Greece Chiara Boldrini, IIT-CNR, Italy STEERING Committee Marco Conti, IIT-CNR, Italy Silvia Giordano, SUPSI, Switzerland Ioannis Stavrakakis, University of Athens, Greece PUBLICITY Chairs Fabio Pezzoni, IIT-CNR, Italy Pushpendra Singh, IIIT Delhi, India PROGRAM COMMITTEE ------------------------------------ Gergely Acs, BUTE, Hungary Eleonora Borgia, IIT-CNR, Italy Jian-Nong Cao, Hong Kong Polytechnic University, HK Vania Conan, Thales, France Serge Fdida, UPMC, Paris VI, France Laura Galluccio, University of Catania, Italy Nidhi Hegde, Technicolor, France Tristan Henderson, University of St. Andrews, UK Gunnar Karlsson, KTH, Sweden Mohan Kumar, University of Texas at Arlington, USA Kyunghan Lee, North Carolina State University, USA Franck Legendre, ETH Zurich, Switzerland Daniele Miorandi, Create-net, Italy Refik Molva, Eurecom, France Valtteri Niemi, Nokia, Switzerland Katia Obraczka, University of California, Santa Cruz, USA Konstantinos Oikonomou, Ionian University, Greece Joerg Ott, HUT, Finland Elena Pagani, Universita' degli Studi di Milano, Italy Andrea Passarella, IIT-CNR, Italy Daniele Puccinelli, SUPSI, Switzerland Christian Rohner, Uppsala University, Sweden Fabrizio Sestini, EU Commission Abdullatif Shikfa, Alcatel Lucent Bell Labs, France Thrasyvoulos Spyropoulos, EURECOM, France Roger Whitaker, Cardiff University, UK Hongyi Wu, University of Louisiana at Lafayette, USA Eiko Yoneki, University of Cambridge, UK Franco Zambonelli, University of Modena-Reggio, Italy Xiaolan Zhang, Fordham University, USA From james.huy.nguyen@gmail.com Tue Jan 31 06:02:12 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3675E21F862D for ; Tue, 31 Jan 2012 06:02:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.304 X-Spam-Level: X-Spam-Status: No, score=-3.304 tagged_above=-999 required=5 tests=[AWL=0.294, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oYtmvw6OG8+S for ; Tue, 31 Jan 2012 06:02:11 -0800 (PST) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6C08E21F8622 for ; Tue, 31 Jan 2012 06:02:11 -0800 (PST) Received: by ghbg16 with SMTP id g16so19930ghb.31 for ; Tue, 31 Jan 2012 06:02:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=pL1gqZ5ccde2G4jP5stani4TaNIV8pvfNA0gSxrLsNw=; b=pcW0pQZcp6c/NukQJOWOc0UA01LZF370a66yzaqyom7trbAEpA87Mjvrega/83e/NS Rw4k1Rit+ujE8DLAcyN4eCHkTVz2efMuh1TTUXAre/o/L2rUeJPhwSUUA3ViiYKFv3e3 L7fVPYxbLPv851LXX/BMAAL+TBTW9tzGNaCqk= MIME-Version: 1.0 Received: by 10.236.145.193 with SMTP id p41mr5589920yhj.124.1328018531042; Tue, 31 Jan 2012 06:02:11 -0800 (PST) Received: by 10.100.174.11 with HTTP; Tue, 31 Jan 2012 06:02:10 -0800 (PST) Date: Tue, 31 Jan 2012 09:02:10 -0500 Message-ID: From: James Nguyen To: manet@ietf.org Content-Type: multipart/alternative; boundary=20cf30426db8cc43e704b7d368e6 Subject: [manet] API for NHDP X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2012 14:02:12 -0000 --20cf30426db8cc43e704b7d368e6 Content-Type: text/plain; charset=UTF-8 Hi, I'm working on implementing SNMP capabilities for NHDP. I'm just wondering if there is an API that allows application to interface with NHDP. -- James Nguyen Email: james.huy.nguyen@gmail.com --20cf30426db8cc43e704b7d368e6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi,

I'm working on implementing SNMP capabilities fo= r NHDP. =C2=A0I'm just wondering if there is an API that allows applica= tion to interface with NHDP.

--
James N= guyen
Email: james.huy.nguyen@gmail= .com
--20cf30426db8cc43e704b7d368e6-- From ulrich@herberg.name Tue Jan 31 09:14:02 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 284CB21F8512 for ; Tue, 31 Jan 2012 09:14:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yv6wh4vFJ7Qp for ; Tue, 31 Jan 2012 09:14:01 -0800 (PST) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0200C21F850F for ; Tue, 31 Jan 2012 09:14:00 -0800 (PST) Received: by werm10 with SMTP id m10so247180wer.31 for ; Tue, 31 Jan 2012 09:14:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=0YNGnfwoHgG1aY03nA2lwMNKuvjlyV/YKRG9Cb6XwJI=; b=0JpnyPVyEn/uLH+D9Wc7CjQeZ4UUPJ3wEtnaDxmNybGt1jH4mbYheRJeiF+csu5OTe dFscK2LEte8EwbxXmQNEhswjS1tbpqn6bX3/XHtNJe+N9TmNNVLVtfJOeGYZUStenmoI qMOwV0PbWP45GVHlCiOU+Rc+oZfdkxwZsqTYc= MIME-Version: 1.0 Received: by 10.216.138.75 with SMTP id z53mr1335230wei.25.1328030040118; Tue, 31 Jan 2012 09:14:00 -0800 (PST) Received: by 10.216.52.65 with HTTP; Tue, 31 Jan 2012 09:14:00 -0800 (PST) In-Reply-To: References: Date: Tue, 31 Jan 2012 09:14:00 -0800 Message-ID: From: Ulrich Herberg To: James Nguyen Content-Type: multipart/alternative; boundary=0016e6d77c6bcad65d04b7d616f3 Cc: manet@ietf.org Subject: Re: [manet] API for NHDP X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2012 17:14:02 -0000 --0016e6d77c6bcad65d04b7d616f3 Content-Type: text/plain; charset=ISO-8859-1 James, as for the interface towards SNMP, you can use the MIB that is included in http://tools.ietf.org/html/draft-ietf-manet-nhdp-mib There are tools that create C++/Java/etc. code from a MIB. The back-end itself (between the MIB code and NHDP) has to be implemented manually. We are very interested in MIB implementations and experiences with it, so when you have completed the implementation, please notify us on the MANET list. Is this implementation planned to be open source? Hope that helps Ulrich On Tue, Jan 31, 2012 at 6:02 AM, James Nguyen wrote: > Hi, > > I'm working on implementing SNMP capabilities for NHDP. I'm just > wondering if there is an API that allows application to interface with NHDP. > > -- > James Nguyen > Email: james.huy.nguyen@gmail.com > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > --0016e6d77c6bcad65d04b7d616f3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable James,

as for the interface towards SNMP, you can use the MIB that i= s included in
http://tools.ietf.org/html/draft-ietf-manet-nhdp-mib

Ther= e are tools that create C++/Java/etc. code from a MIB. The back-end itself = (between the MIB code and NHDP) has to be implemented manually.

We are very interested in MIB implementations and experiences with it, = so when you have completed the implementation, please notify us on the MANE= T list. Is this implementation planned to be open source?

Hope that = helps
Ulrich


On Tue, Jan 31, 2012 at 6:02 A= M, James Nguyen <james.huy.nguyen@gmail.com> wrote:
Hi,

I'm working on implementing SNMP capabilities fo= r NHDP. =A0I'm just wondering if there is an API that allows applicatio= n to interface with NHDP.

--
James Nguyen
Email: jame= s.huy.nguyen@gmail.com

_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet


--0016e6d77c6bcad65d04b7d616f3-- From james.huy.nguyen@gmail.com Tue Jan 31 10:09:34 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F10921F8512 for ; Tue, 31 Jan 2012 10:09:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.378 X-Spam-Level: X-Spam-Status: No, score=-3.378 tagged_above=-999 required=5 tests=[AWL=0.220, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zkehCxGpokAD for ; Tue, 31 Jan 2012 10:09:34 -0800 (PST) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4344E21F8510 for ; Tue, 31 Jan 2012 10:09:29 -0800 (PST) Received: by ghbg16 with SMTP id g16so214249ghb.31 for ; Tue, 31 Jan 2012 10:09:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=G7RvLk2CBM028b1xQsMt5movUaf3jQZu1Xh0nviSfT8=; b=aeRIA3IMaP5nEPTlFLus4ca3B8NZ6SvSQR1blmvso/PiuAnBnKOWPsQXlxLRjU4sS8 EDiDFnmkMVpjw/mfnoLN16+/x9p2q9EJm+XUlA689DewGhpgFJucYVOETCtzyFGWj2Fk A0vgm8DEg4wTa5/xH9VW58ET+Kb6/eLyCdol8= MIME-Version: 1.0 Received: by 10.236.192.230 with SMTP id i66mr35869311yhn.116.1328033368884; Tue, 31 Jan 2012 10:09:28 -0800 (PST) Received: by 10.100.174.11 with HTTP; Tue, 31 Jan 2012 10:09:28 -0800 (PST) In-Reply-To: References: Date: Tue, 31 Jan 2012 13:09:28 -0500 Message-ID: From: James Nguyen To: Ulrich Herberg Content-Type: multipart/alternative; boundary=20cf3056431d33c5a704b7d6ddb4 Cc: manet@ietf.org Subject: Re: [manet] API for NHDP X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2012 18:09:34 -0000 --20cf3056431d33c5a704b7d6ddb4 Content-Type: text/plain; charset=UTF-8 Ulrich, I can see you're the co-author of NHDP. :) Do you know how many NHDP implementations there are beside Naval Research Laboratory's NHDP that was written in C++? I'm planning to have the SNMP implementation open source. James On Tue, Jan 31, 2012 at 12:14 PM, Ulrich Herberg wrote: > James, > > as for the interface towards SNMP, you can use the MIB that is included in > http://tools.ietf.org/html/draft-ietf-manet-nhdp-mib > > There are tools that create C++/Java/etc. code from a MIB. The back-end > itself (between the MIB code and NHDP) has to be implemented manually. > > We are very interested in MIB implementations and experiences with it, so > when you have completed the implementation, please notify us on the MANET > list. Is this implementation planned to be open source? > > Hope that helps > Ulrich > > > On Tue, Jan 31, 2012 at 6:02 AM, James Nguyen wrote: > >> Hi, >> >> I'm working on implementing SNMP capabilities for NHDP. I'm just >> wondering if there is an API that allows application to interface with NHDP. >> >> -- >> James Nguyen >> Email: james.huy.nguyen@gmail.com >> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >> >> > -- James Nguyen Email: james.huy.nguyen@gmail.com --20cf3056431d33c5a704b7d6ddb4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Ulrich,

I can see you're the co-author of NHDP. =C2= =A0:) =C2=A0Do you know how many NHDP implementations there are beside Nava= l Research Laboratory's NHDP that was written in C++?

I'm planning to have the SNMP implementation open source. =C2=A0
James

On Tue, Jan 31, 2012 at 12:14 PM, = Ulrich Herberg <ulrich@herberg.name> wrote:
James,

as for the interface towards S= NMP, you can use the MIB that is included in
http://tools.ietf.o= rg/html/draft-ietf-manet-nhdp-mib

There are tools that create C++/Java/etc. code from a MIB. The back-end= itself (between the MIB code and NHDP) has to be implemented manually.

We are very interested in MIB implementations and experiences with it, = so when you have completed the implementation, please notify us on the MANE= T list. Is this implementation planned to be open source?

Hope that = helps
Ulrich


On Tue,= Jan 31, 2012 at 6:02 AM, James Nguyen <james.huy.nguyen@gmail.co= m> wrote:
Hi,

I'm working on implementing SNMP capabilities fo= r NHDP. =C2=A0I'm just wondering if there is an API that allows applica= tion to interface with NHDP.

--
James Nguyen
Email: jame= s.huy.nguyen@gmail.com

_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet





--
James Nguyen=
Email: james.huy.nguyen@g= mail.com
--20cf3056431d33c5a704b7d6ddb4-- From ulrich@herberg.name Tue Jan 31 10:26:20 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 356E911E80F8 for ; Tue, 31 Jan 2012 10:26:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Weh3OfUxgTAf for ; Tue, 31 Jan 2012 10:26:19 -0800 (PST) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id C586111E80FC for ; Tue, 31 Jan 2012 10:26:18 -0800 (PST) Received: by wibhm9 with SMTP id hm9so274827wib.31 for ; Tue, 31 Jan 2012 10:26:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=GzX/lFXUc0ah48vkZHNHUot2/uIl00u9RbNDmZWUnfo=; b=E3v+F5LyiNt6AsNwNgjKu/NqruTL7YPmGKERuaSnecsLnsFe4J3wP6AGoFEP+E7I0Y zd0srWm12pqcCoHi9J4qYlsGwEb6mEwtNKhpGl5OH+blPySPS0aab9d2QO7FglhlOAXy cFYFwJ77ULyULQnjdFOEuMQau/JBB9QzJO2Ik= MIME-Version: 1.0 Received: by 10.180.100.234 with SMTP id fb10mr36276775wib.8.1328034377708; Tue, 31 Jan 2012 10:26:17 -0800 (PST) Received: by 10.216.52.65 with HTTP; Tue, 31 Jan 2012 10:26:17 -0800 (PST) In-Reply-To: References: Date: Tue, 31 Jan 2012 10:26:17 -0800 Message-ID: From: Ulrich Herberg To: James Nguyen Content-Type: multipart/alternative; boundary=f46d043748f35532db04b7d719cd Cc: manet@ietf.org Subject: Re: [manet] API for NHDP X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2012 18:26:20 -0000 --f46d043748f35532db04b7d719cd Content-Type: text/plain; charset=ISO-8859-1 James, actually, I am not a coauthor of NHDP, but of the NHDP-MIB document :-) I am not aware of how many implementations exist. I have myself implemented one in Java for my previous employer (Ecole Polytechnique), but it is not open-source. I know of a few corporate, closed-source implementations. As for open-source, there is the one from NRL (which I have tested and which works fine). There is also one from olsr.org, but I don't know the status of the implementation (but I think the basic functionality works fine, it was also tested during the interop event). Have a look at the proceedings of http://interop.thomasclausen.org During these interop events, a number of different RFC5449 and NHDP implementations have been tested. You can also find a description of the tests at http://herberg.name/downloads/pubs/thesis.pdf Will you come to the Paris IETF? There is always a slot at the end of the MANET WG session with updates about implementations. In my opinion, it would be very interesting to hear about your NHDP and in particular your NHDP-MIB implementation. Regards Ulrich On Tue, Jan 31, 2012 at 10:09 AM, James Nguyen wrote: > Ulrich, > > I can see you're the co-author of NHDP. :) Do you know how many NHDP > implementations there are beside Naval Research Laboratory's NHDP that was > written in C++? > > I'm planning to have the SNMP implementation open source. > > James > > > On Tue, Jan 31, 2012 at 12:14 PM, Ulrich Herberg wrote: > >> James, >> >> as for the interface towards SNMP, you can use the MIB that is included in >> http://tools.ietf.org/html/draft-ietf-manet-nhdp-mib >> >> There are tools that create C++/Java/etc. code from a MIB. The back-end >> itself (between the MIB code and NHDP) has to be implemented manually. >> >> We are very interested in MIB implementations and experiences with it, so >> when you have completed the implementation, please notify us on the MANET >> list. Is this implementation planned to be open source? >> >> Hope that helps >> Ulrich >> >> >> On Tue, Jan 31, 2012 at 6:02 AM, James Nguyen > > wrote: >> >>> Hi, >>> >>> I'm working on implementing SNMP capabilities for NHDP. I'm just >>> wondering if there is an API that allows application to interface with NHDP. >>> >>> -- >>> James Nguyen >>> Email: james.huy.nguyen@gmail.com >>> >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>> >>> >> > > > -- > James Nguyen > Email: james.huy.nguyen@gmail.com > --f46d043748f35532db04b7d719cd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable James,

actually, I am not a coauthor of NHDP, but of the NHDP-MIB do= cument :-) I am not aware of how many implementations exist. I have myself = implemented one in Java for my previous employer (Ecole Polytechnique), but= it is not open-source.
I know of a few corporate, closed-source implementations. As for open-sourc= e, there is the one from NRL (which I have tested and which works fine). Th= ere is also one from olsr.org, but I don= 9;t know the status of the implementation (but I think the basic functional= ity works fine, it was also tested during the interop event).

Have a look at the proceedings of http://interop.thomasclausen.org
During these interop events= , a number of different RFC5449 and NHDP implementations have been tested. = You can also find a description of the tests at http://herberg.name/downloads/pubs/thesis.pd= f

Will you come to the Paris IETF? There is always a slot at the end of t= he MANET WG session with updates about implementations. In my opinion, it w= ould be very interesting to hear about your NHDP and in particular your NHD= P-MIB implementation.


Regards
Ulrich

On Tue, Jan 31,= 2012 at 10:09 AM, James Nguyen <james.huy.nguyen@gmail.com> wrote:
Ulrich,

I can see you'= ;re the co-author of NHDP. =A0:) =A0Do you know how many NHDP implementatio= ns there are beside Naval Research Laboratory's NHDP that was written i= n C++?

I'm planning to have the SNMP implementation open source. =A0

James


On Tue, Jan 31, 2012 at 12:1= 4 PM, Ulrich Herberg <ulrich@herberg.name> wrote:
James,

as for the interface towards S= NMP, you can use the MIB that is included in
http://tools.ietf.o= rg/html/draft-ietf-manet-nhdp-mib

There are tools that create C++/Java/etc. code from a MIB. The back-end= itself (between the MIB code and NHDP) has to be implemented manually.

We are very interested in MIB implementations and experiences with it, = so when you have completed the implementation, please notify us on the MANE= T list. Is this implementation planned to be open source?

Hope that = helps
Ulrich


On Tue, Jan 31, 2012= at 6:02 AM, James Nguyen <james.huy.nguyen@gmail.com> wrote:
Hi,

I'm working on implementing SNMP capabilities fo= r NHDP. =A0I'm just wondering if there is an API that allows applicatio= n to interface with NHDP.

--
James Nguyen
Email: jame= s.huy.nguyen@gmail.com

_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet





--
James Nguyen=
Email: = james.huy.nguyen@gmail.com

--f46d043748f35532db04b7d719cd-- From ulrich@herberg.name Tue Jan 31 10:43:03 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DF8111E8111 for ; Tue, 31 Jan 2012 10:43:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V5VuV8AG9D3p for ; Tue, 31 Jan 2012 10:43:02 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id CCC0411E8080 for ; Tue, 31 Jan 2012 10:43:01 -0800 (PST) Received: by wgbdt10 with SMTP id dt10so255089wgb.13 for ; Tue, 31 Jan 2012 10:43:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=B4Ifd+WwXWr4D2NQ4dYieCSRiNmTadaCb9Si5soGwkg=; b=UOPQtomwNp/c1FG9gs57aOtyVmnVnhq3Lell21IEt39RRbmUNQeh8lm1cbHJA4NEfW XzXZaEBBdblqfojxymeL7WyU5X20BS7Jf3a0SaVA8AX3/Z+K89Rqz0clXR/efj0EYicI 5UB/+RswXInqaVZJfAmkOJU4CkECNMHTlPHAo= MIME-Version: 1.0 Received: by 10.181.12.106 with SMTP id ep10mr5754429wid.8.1328035380619; Tue, 31 Jan 2012 10:43:00 -0800 (PST) Received: by 10.216.52.65 with HTTP; Tue, 31 Jan 2012 10:43:00 -0800 (PST) In-Reply-To: References: Date: Tue, 31 Jan 2012 10:43:00 -0800 Message-ID: From: Ulrich Herberg To: James Nguyen Content-Type: multipart/alternative; boundary=f46d043c7ec01c6aad04b7d75549 Cc: manet@ietf.org Subject: Re: [manet] API for NHDP X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2012 18:43:03 -0000 --f46d043c7ec01c6aad04b7d75549 Content-Type: text/plain; charset=ISO-8859-1 P.S. I meant RFC5444, not RFC5449 in my previous email. Ulrich On Tue, Jan 31, 2012 at 10:26 AM, Ulrich Herberg wrote: > James, > > actually, I am not a coauthor of NHDP, but of the NHDP-MIB document :-) I > am not aware of how many implementations exist. I have myself implemented > one in Java for my previous employer (Ecole Polytechnique), but it is not > open-source. > I know of a few corporate, closed-source implementations. As for > open-source, there is the one from NRL (which I have tested and which works > fine). There is also one from olsr.org, but I don't know the status of > the implementation (but I think the basic functionality works fine, it was > also tested during the interop event). > > Have a look at the proceedings of http://interop.thomasclausen.org > During these interop events, a number of different RFC5449 and NHDP > implementations have been tested. You can also find a description of the > tests at http://herberg.name/downloads/pubs/thesis.pdf > > Will you come to the Paris IETF? There is always a slot at the end of the > MANET WG session with updates about implementations. In my opinion, it > would be very interesting to hear about your NHDP and in particular your > NHDP-MIB implementation. > > > Regards > Ulrich > > > On Tue, Jan 31, 2012 at 10:09 AM, James Nguyen > wrote: > >> Ulrich, >> >> I can see you're the co-author of NHDP. :) Do you know how many NHDP >> implementations there are beside Naval Research Laboratory's NHDP that was >> written in C++? >> >> I'm planning to have the SNMP implementation open source. >> >> James >> >> >> On Tue, Jan 31, 2012 at 12:14 PM, Ulrich Herberg wrote: >> >>> James, >>> >>> as for the interface towards SNMP, you can use the MIB that is included >>> in >>> http://tools.ietf.org/html/draft-ietf-manet-nhdp-mib >>> >>> There are tools that create C++/Java/etc. code from a MIB. The back-end >>> itself (between the MIB code and NHDP) has to be implemented manually. >>> >>> We are very interested in MIB implementations and experiences with it, >>> so when you have completed the implementation, please notify us on the >>> MANET list. Is this implementation planned to be open source? >>> >>> Hope that helps >>> Ulrich >>> >>> >>> On Tue, Jan 31, 2012 at 6:02 AM, James Nguyen < >>> james.huy.nguyen@gmail.com> wrote: >>> >>>> Hi, >>>> >>>> I'm working on implementing SNMP capabilities for NHDP. I'm just >>>> wondering if there is an API that allows application to interface with NHDP. >>>> >>>> -- >>>> James Nguyen >>>> Email: james.huy.nguyen@gmail.com >>>> >>>> _______________________________________________ >>>> manet mailing list >>>> manet@ietf.org >>>> https://www.ietf.org/mailman/listinfo/manet >>>> >>>> >>> >> >> >> -- >> James Nguyen >> Email: james.huy.nguyen@gmail.com >> > > --f46d043c7ec01c6aad04b7d75549 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable P.S. I meant RFC5444, not RFC5449 in my previous email.

Ulrich
On Tue, Jan 31, 2012 at 10:26 AM, Ulrich Herbe= rg <ulrich@herb= erg.name> wrote:
James,

actually, I am not a coauthor = of NHDP, but of the NHDP-MIB document :-) I am not aware of how many implem= entations exist. I have myself implemented one in Java for my previous empl= oyer (Ecole Polytechnique), but it is not open-source.
I know of a few corporate, closed-source implementations. As for open-sourc= e, there is the one from NRL (which I have tested and which works fine). Th= ere is also one from olsr.org= , but I don't know the status of the implementation (but I think th= e basic functionality works fine, it was also tested during the interop eve= nt).

Have a look at the proceedings of http://interop.thomasclausen.org
During th= ese interop events, a number of different RFC5449 and NHDP implementations = have been tested. You can also find a description of the tests at http:/= /herberg.name/downloads/pubs/thesis.pdf

Will you come to the Paris IETF? There is always a slot at the end of t= he MANET WG session with updates about implementations. In my opinion, it w= ould be very interesting to hear about your NHDP and in particular your NHD= P-MIB implementation.


Regards
Ulrich


On Tue, Jan 31, 2012 at 10:09 AM, James Nguyen <james.= huy.nguyen@gmail.com> wrote:
Ulrich,

I can see you'= ;re the co-author of NHDP. =A0:) =A0Do you know how many NHDP implementatio= ns there are beside Naval Research Laboratory's NHDP that was written i= n C++?

I'm planning to have the SNMP implementation open source. =A0

James


On Tue, Jan 31, 2012 at 12:14 PM, Ulrich Herberg <ulric= h@herberg.name> wrote:
James,

as for the interface towards S= NMP, you can use the MIB that is included in
http://tools.ietf.o= rg/html/draft-ietf-manet-nhdp-mib

There are tools that create C++/Java/etc. code from a MIB. The back-end= itself (between the MIB code and NHDP) has to be implemented manually.

We are very interested in MIB implementations and experiences with it, = so when you have completed the implementation, please notify us on the MANE= T list. Is this implementation planned to be open source?

Hope that = helps
Ulrich


On Tue, Jan 31, 2012= at 6:02 AM, James Nguyen <james.huy.nguyen@gmail.com> wrote:
Hi,

I'm working on implementing SNMP capabilities fo= r NHDP. =A0I'm just wondering if there is an API that allows applicatio= n to interface with NHDP.

--
James Nguyen
Email: jame= s.huy.nguyen@gmail.com

_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet





--
James Nguyen=
Email: = james.huy.nguyen@gmail.com


--f46d043c7ec01c6aad04b7d75549-- From internet-drafts@ietf.org Tue Jan 31 11:51:42 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2BC611E812E; Tue, 31 Jan 2012 11:51:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mrm-43V8WzAe; Tue, 31 Jan 2012 11:51:42 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E71411E809D; Tue, 31 Jan 2012 11:51:42 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20120131195142.26615.49099.idtracker@ietfa.amsl.com> Date: Tue, 31 Jan 2012 11:51:42 -0800 Cc: manet@ietf.org Subject: [manet] I-D Action: draft-ietf-manet-packetbb-sec-08.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2012 19:51:43 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Mobile Ad-hoc Networks Working Group = of the IETF. Title : MANET Cryptographical Signature TLV Definition Author(s) : Ulrich Herberg Thomas Heide Clausen Filename : draft-ietf-manet-packetbb-sec-08.txt Pages : 17 Date : 2012-01-31 This document describes general and flexible TLVs (type-length-value structure) for representing cryptographic signatures as well as timestamps, using the generalized MANET packet/message format defined in RFC 5444. It defines two Packet TLVs, two Message TLVs, and two Address Block TLVs, for affixing cryptographic signatures and timestamps to a packet, message and address, respectively. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-manet-packetbb-sec-08.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-manet-packetbb-sec-08.txt From ulrich@herberg.name Tue Jan 31 11:59:13 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05FAF21F8513 for ; Tue, 31 Jan 2012 11:59:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NI1uuH2Vqiec for ; Tue, 31 Jan 2012 11:59:12 -0800 (PST) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id EB2A221F8512 for ; Tue, 31 Jan 2012 11:59:11 -0800 (PST) Received: by werm10 with SMTP id m10so414896wer.31 for ; Tue, 31 Jan 2012 11:59:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=WGbD25ygDA7fTm6Ws61KNKXNGQhNpAbZx4pneh09Wqw=; b=00WMoHx7dh54oy0Bv9r5hZEudjBHxnoO3KE9xfLmWI2R+Wi+C9JYPtAKZQ0Zl4rrK/ c5WL4+DkXrET+gnDD7tqsTLAllDJOLLoNyiafysxR1rjhCK3USb00rGmsjXW9UMk6tEB i85ornCWrTJzCnz56UTTwWj4+NsVoDe06p7Mg= MIME-Version: 1.0 Received: by 10.216.138.75 with SMTP id z53mr1581905wei.25.1328039951080; Tue, 31 Jan 2012 11:59:11 -0800 (PST) Received: by 10.216.52.65 with HTTP; Tue, 31 Jan 2012 11:59:11 -0800 (PST) In-Reply-To: <00ef01cccd78$babc3d50$3034b7f0$@olddog.co.uk> References: <00ef01cccd78$babc3d50$3034b7f0$@olddog.co.uk> Date: Tue, 31 Jan 2012 11:59:11 -0800 Message-ID: From: Ulrich Herberg To: adrian@olddog.co.uk Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: manet@ietf.org, draft-ietf-manet-packetbb-sec.all@tools.ietf.org Subject: Re: [manet] AD review of draft-ietf-manet-packetbb-sec X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2012 19:59:13 -0000 Adrian, thank you very much for your review. My comments are inline (which are reflected in the new revision http://www.ietf.org/id/draft-ietf-manet-packetbb-sec-08.txt ) On Sat, Jan 7, 2012 at 12:12 PM, Adrian Farrel wrote: > > Thanks for this draft. I have performed my AD review as usual and I > don't have any major issues. > > Before we start, one minor question to help me set my expectations... > > Did you have any expert security input on this work? I only ask in > order to try to work out what level of review we are likely to get > later in the process. > > Otherwise I have a few nits and minor requests to polish the document. > I hope they are straight forward and you can quickly spin a new > revision of the document which I can advance to IETF last call. > > Thanks, > Adrian > > --- > > The text file I downloaded has a couple of interesting characters at the > top. > > =EF=BB=BF > > --- > > Could you s/[RFC5444]/defined in RFC 5444/ > > (A piece of pettiness, but citations cannot be made from the stand-alone > Abstract) done > > > --- > > Section 10.1 does not include the caveat about other signatures that may > already be present as found in 8.1 and 9.1. Is this intentional? No, I have added it in Section 10.1. Thanks for spotting this! > > --- > > Section 11 > > Don't "propose" anything! This is an I-D you plan to have converted into > an RFC. You can "define" things if you feel the need for a word. Done > > --- > > Section 12.1.1 > > =A0 The rationale for separating the hash function and the cryptographic > =A0 function into two octets instead of having all combinations in a > =A0 single octet - possibly as TLV type extension - is twofold: First, if > =A0 further hash functions or cryptographic functions are added in the > =A0 future, the number space might not remain continuous. =A0More > =A0 importantly, the number space of possible combinations would be > =A0 rapidly exhausted. =A0As new or improved cryptographic mechanism are > =A0 continuously being developed and introduced, this format should be > =A0 able to accommodate such for the foreseeable future. > > I accept the reasoning for the contiguity. I don't accept the reasoning > for number space exhaustion. Surely, you have the same number of bits > (16) and the same amount of information (#hashfuncs * #cryptofuncs). > > Actually, in your method exhaustion is slightly more likely because you > only have 8 bits for each category and so one of them could become > exhausted independent of the other. > > I suggest removing the second motivation. Okay, I did that. > > Clarity of separation of function identifiers would serve as a second > reason if you must have one. > > --- > > 12.1.1 > > =A0 The rationale for not including a field that lists parameters of the > =A0 cryptographic signature in the TLV is, that before being able to > =A0 validate a cryptographic signature, routers have to exchange or > > s/TLV is, that/TLV is that,/ done > > --- > > Section 13 > > Please remove the RFC2119 language from this part of the IANA > considerations section. It is typical to request IANA to perform actions. Done. Does this also apply to section 13.1? > > --- > > Sections 13. through 13.6 > > The experimental ranges here are way too large unless you can give me a > really good reason. > > Understandable as MANET moves from experimental to standards track, but > once you are standards track it is normal to restrict the experimental > ranges to a very small (e.g. one) range of numbers. Have a look at > RFC 3692. Consider whether it would be enough to have just one or two > code points reserved for experimentation. >From the follow-up discussion of this, we reduced it to a range of 4. Best regards Ulrich From internet-drafts@ietf.org Tue Jan 31 19:09:38 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF3BF21F847F; Tue, 31 Jan 2012 19:09:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4PhfCe97rXPe; Tue, 31 Jan 2012 19:09:38 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7190E21F8478; Tue, 31 Jan 2012 19:09:17 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20120201030917.18173.68833.idtracker@ietfa.amsl.com> Date: Tue, 31 Jan 2012 19:09:17 -0800 Cc: manet@ietf.org Subject: [manet] I-D Action: draft-ietf-manet-report-mib-02.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2012 03:09:39 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Mobile Ad-hoc Networks Working Group = of the IETF. Title : Definition of Managed Objects for Performance Reporting Author(s) : Robert G. Cole Joseph Macker Andy Bierman Filename : draft-ietf-manet-report-mib-02.txt Pages : 26 Date : 2012-01-31 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects for configuring autonomous report generation on any device that supports MIBs containing counter and gauge objects for performance monitoring. This allows a management station to instruct a device to build off-line reports to be collected asynchronously by the management station. Further, this REPORT-SAMPLED-MIB can be configured in a proxy configuration where the report generation is performed on a device in close network proximity to the device containing the referenced counter objects. Hence, this capability allows network operators to reduce the SNMP polling traffic burden on Mobile Ad-Hoc and Disruption Tolerant Networks which is typical of SNMP performance management applications. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-manet-report-mib-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-manet-report-mib-02.txt