From nobody Mon Feb 6 11:53:05 2017 Return-Path: X-Original-To: manet@ietf.org Delivered-To: manet@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 546FF1295DB; Mon, 6 Feb 2017 11:52:55 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.42.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148641077533.18879.5370240894715848406.idtracker@ietfa.amsl.com> Date: Mon, 06 Feb 2017 11:52:55 -0800 Archived-At: Cc: draft-ietf-manet-olsrv2-sec-threats@ietf.org, manet-chairs@ietf.org, manet@ietf.org, The IESG , rfc-editor@rfc-editor.org Subject: [manet] Document Action: 'Security Threats to the Optimized Link State Routing Protocol version 2 (OLSRv2)' to Informational RFC (draft-ietf-manet-olsrv2-sec-threats-04.txt) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2017 19:52:55 -0000 The IESG has approved the following document: - 'Security Threats to the Optimized Link State Routing Protocol version 2 (OLSRv2)' (draft-ietf-manet-olsrv2-sec-threats-04.txt) as Informational RFC This document is the product of the Mobile Ad-hoc Networks Working Group. The IESG contact persons are Alvaro Retana, Alia Atlas and Deborah Brungard. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2-sec-threats/ Technical Summary This document analyzes common security threats of the Optimized Link State Routing Protocol version 2 (OLSRv2) and describes their potential impacts on Mobile Ad Hoc Network (MANET) operations. It then analyzes which of these security vulnerabilities can be mitigated when using the mandatory-to-implement security mechanisms for OLSRv2, and how the vulnerabilities are mitigated. Working Group Summary There was not much discussion of this document on the WG list (typical for this type of document), but support was received, and no dissent was expressed. Document Quality The document describes the key security issues for OLSRv2. The information is presented clearly and is easy to digest. Personnel Justin Dean (bebemaster@gmail.com) is the document shepherd for this document. Alvaro Retana (aretana@cisco.com) is the responsible AD. From nobody Thu Feb 9 06:00:07 2017 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 1AA4F129DB1 for ; Thu, 9 Feb 2017 06:00:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MwLqAbMDwmnM for ; Thu, 9 Feb 2017 06:00:04 -0800 (PST) Received: from mailsrv.math.unipd.it (mailsrv.math.unipd.it [147.162.22.62]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7451129A2C for ; Thu, 9 Feb 2017 06:00:03 -0800 (PST) Received: from server0.math.unipd.it (smtpout.math.unipd.it [147.162.22.54]) by mailsrv.math.unipd.it (8.15.2/8.15.2) with ESMTPS id v19Dxu49078965 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 9 Feb 2017 13:59:56 GMT Received: from webmail.math.unipd.it (v0b1.math.unipd.it [147.162.22.157]) by server0.math.unipd.it (8.15.1/8.15.1) with ESMTPS id v19Dxh11090237 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 9 Feb 2017 13:59:43 GMT Received: from dhcp138.math.unipd.it (dhcp138.math.unipd.it [147.162.114.138]) by webmail.math.unipd.it (Horde Framework) with HTTPS; Thu, 09 Feb 2017 15:00:00 +0100 Date: Thu, 09 Feb 2017 15:00:00 +0100 Message-ID: <20170209150000.Horde.40za4cMPFC7R8raujbvFRZR@webmail.math.unipd.it> From: riccardo.lazzeretti@math.unipd.it To: manet@ietf.org User-Agent: Horde Application Framework 5 Content-Type: multipart/alternative; boundary="=_Ts5LIN-7-XYohxWdP-NMm_J" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-DCC--Metrics: server5.math.unipd.it 1481; Body=1 Fuz1=1 Fuz2=many X-IMP-Checker: SpamAssassin on webmail.math.unipd.it/imp checker X-Spam-Warning: SpamAssassin says this -probably- is not SPAM X-Scanned-By: MIMEDefang 2.78 Archived-At: Subject: [manet] [IEEE ATC 2017] Call for Workshop and Special Session Proposal Extended X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2017 14:00:06 -0000 This message is in MIME format. --=_Ts5LIN-7-XYohxWdP-NMm_J Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes Content-Description: Plaintext Message Content-Disposition: inline Content-Transfer-Encoding: 8bit Dear colleague,   Apologies for multiple postings. In conjunction with the 14th IEEE International Conference on Advanced and Trusted Computing (ATC 2017), we will organize some workshops. The workshop proposals should be submitted to ieee-atc2017@googlegroups.com Further information are provided in the ATC Call for Workshop page[1] . All accepted papers will be included in the ATC 2017 proceedings published by IEEE.   Workshop/Special Session proposals should contain following information: ·  The title of the workshop/special session, including both full name and abbreviation (for workshop) ·  The objectives, scope, and contributions to the main conference (up to 1 page) ·  The short bios of the key organizers and their related experience ·  The procedure for selecting papers, plans for dissemination (e.g., how to advertise and special issues of journals), and the expected number of participants ·  A tentative list of program committee members ·  The (tentative) website/URL of the proposed workshop/special session   Important Schedule for ATC Workshops and Special Sessions: ·  Proposal Due: extended to Feb 15, 2017 ·  Proposal Notification: extended to Feb 20, 2017 ·  Paper Submission, Notification: TBD by individual workshops ·  Final Camera-ready Paper Due: June 10, 2017   Best regards,   Riccardo Lazzeretti riccardo.lazzeretti@math.unipd.it Workshop Chair IEEE Advanced and Trusted Computing (ATC 2017) Links: ------ [1] http://cse.stfx.ca/~smartworld/2017/atc/cfw.php --=_Ts5LIN-7-XYohxWdP-NMm_J Content-Type: text/html; charset=utf-8 Content-Description: HTML Message Content-Disposition: inline

Dear colleague,

 

Apologies for multiple postings.


In conjunction with the 14th IEEE International Conference on Advanced and Trusted Computing (ATC 2017), we will organize some workshops.

The workshop proposals should be submitted to ieee-atc2017@googlegroups.com


Further information are provided in the ATC Call for Workshop page .

All accepted papers will be included in the ATC 2017 proceedings published by IEEE.

 

Workshop/Special Session proposals should contain following information:

·  The title of the workshop/special session, including both full name and abbreviation (for workshop)

·  The objectives, scope, and contributions to the main conference (up to 1 page)

·  The short bios of the key organizers and their related experience

·  The procedure for selecting papers, plans for dissemination (e.g., how to advertise and special issues of journals), and the expected number of participants

·  A tentative list of program committee members

·  The (tentative) website/URL of the proposed workshop/special session

 

Important Schedule for ATC Workshops and Special Sessions:

·  Proposal Due: extended to Feb 15, 2017

·  Proposal Notification: extended to Feb 20, 2017

·  Paper Submission, Notification: TBD by individual workshops

·  Final Camera-ready Paper Due: June 10, 2017

 

Best regards,

 

Riccardo Lazzeretti

riccardo.lazzeretti@math.unipd.it

Workshop Chair

IEEE Advanced and Trusted Computing (ATC 2017)



--=_Ts5LIN-7-XYohxWdP-NMm_J-- From nobody Thu Feb 9 12:24:09 2017 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 6AAB61295A1 for ; Thu, 9 Feb 2017 12:24:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZW3d4iQJPLTQ for ; Thu, 9 Feb 2017 12:24:06 -0800 (PST) Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 047DE129593 for ; Thu, 9 Feb 2017 12:24:05 -0800 (PST) Received: by mail-io0-x229.google.com with SMTP id l66so29944097ioi.1 for ; Thu, 09 Feb 2017 12:24:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=zj/CUi9ag0YkPg49l/uNtyAST6x2J/fFtl4LDdfFg6o=; b=UBqAQKcqCwt2EbplTUZYIBHwf39uUner93js4szYDu9JjhkUdHy7V9H8K+C8v6KZYB vySjohtwYmCHpL8nmfusbyCm1YLbePrDYJ9774mttJe9y9l/xlPZ7eeb3s1I9xyJv/zh gTEVNTaOomfMbEvGtXpNUOF4NZi7MJuqwp1Pu0S0mz9mZuO+AlDxDbeeLQSBvnU+kuQD BqJX0sQr1SBINJyalVBOYrJV+iSP6EIRGXr5le69xcZ4STFPi4QF98CPT3bQtdknvb0Y 5JfRl+5APl+xdZE8kI+Q3Yl0wi94v85c6jK2Jo0jlEE4TjYv+a1pJplFYJJdjRqwk8Fd aAiQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=zj/CUi9ag0YkPg49l/uNtyAST6x2J/fFtl4LDdfFg6o=; b=HEnPw3s8XpKVznlw6kFtn2i8yRe2YEcN0ZUVrxsjmMDJZ6JM4Kg1t1MQOlWOzj7HI1 pRyglRU/J2rNO3KC2UqMOjMw+Ihhowhr2cVstngZV5v6VkdrUvXWZc5vikggkKrZdT34 +8ATk1OXPLknn3ZmVs83ujlyP8TGNP9NN7OLdZEc2wKQKM1tlS98Jady8om7RQAU0XD0 egurJSTlRe7sQsEXaP8OPV0c6qPD28jxX1lkhECSdKVP6j5ITXQdFKby03ADfhRE3gIm 0GqlcHaZV+mzS4AArWh6FVMH0XIo3grz2mKqvz0UYKRii71zeplHw+LDwklyoS3+9kmj t/Vg== X-Gm-Message-State: AMke39mln98+DYC0BMeunpxPu8mPDBWskMpfwuHVRa0YpJ3/QPz9BS17j9FKzN3VJkL38V8pdLRkX77WmNL1Hw== X-Received: by 10.107.48.199 with SMTP id w190mr5576867iow.117.1486671844928; Thu, 09 Feb 2017 12:24:04 -0800 (PST) MIME-Version: 1.0 Received: by 10.79.158.87 with HTTP; Thu, 9 Feb 2017 12:24:04 -0800 (PST) In-Reply-To: References: From: Stan Ratliff Date: Thu, 9 Feb 2017 15:24:04 -0500 Message-ID: To: MANET IETF Content-Type: multipart/alternative; boundary=001a114451aa373afd05481ec39b Archived-At: Subject: Re: [manet] Call for acceptance as Working Group documents X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2017 20:24:07 -0000 --001a114451aa373afd05481ec39b Content-Type: text/plain; charset=UTF-8 WG Participants, The deadline of Feb 2 having expired, and not hearing any dissent, the documents above are accepted as working group documents. Regards, Stan On Thu, Jan 19, 2017 at 11:19 AM, Stan Ratliff wrote: > WG participants, > > Based on earlier complaints, we held off accepting these as WG documents. > The concerns about the "log jam" of documents appears to be resolved, so > I'm restarting this request. Please let the chairs know your thoughts on > acceptance by Feb 2. > > Regards, > Stan > > ---------- Forwarded message ---------- > From: Stan Ratliff > Date: Mon, Nov 28, 2016 at 10:26 AM > Subject: Call for acceptance as Working Group documents > To: MANET IETF > > > Hello working group participants, > > One of the items identified during the WG meeting in Seoul was to formally > request, via the list, Working Group adoption of 5 extension drafts related > to DLEP. This email is that formal request. > > The drafts are: > 1. https://tools.ietf.org/html/draft-cheng-manet-dlep-latency- > extension-00.html > 2. https://tools.ietf.org/html/draft-cheng-manet-dlep-pause-extension-00 > 3. https://tools.ietf.org/html/draft-cheng-manet-dlep-multi- > hop-extension-00 > 4. https://tools.ietf.org/html/draft-cheng-manet-dlep-da- > credit-extension-00 > > I have put all 4 extensions on this email for expediency only; please do > not assume that they must be adopted as a group. The chairs would greatly > appreciate thoughts from the WG, both positive and negative. > > For purposes of determining WG consensus, a lack of a response will be > seen as indicating support for adopting the draft (e.g. silence == > acceptance). > > Regards, > Stan > > > --001a114451aa373afd05481ec39b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
WG Participants,=C2=A0

The deadline of = Feb 2 having expired, and not hearing any dissent, the documents above are = accepted as working group documents.=C2=A0

Regards= ,
Stan


<= div class=3D"gmail_quote">On Thu, Jan 19, 2017 at 11:19 AM, Stan Ratliff <ratliffstan@gmail.com> wrote:
WG participants,

Based on earlie= r complaints, we held off accepting these as WG documents. The concerns abo= ut the "log jam" of documents appears to be resolved, so I'm = restarting this request. Please let the chairs know your thoughts on accept= ance by Feb 2.=C2=A0

Regards,
Stan
=

---------- Forwarded message ----------=
From: Stan Ratliff = <ratliffstan@= gmail.com>
Date: Mon, Nov 28, 2016 at 10:26 AM
Subject:= Call for acceptance as Working Group documents
To: MANET IETF <manet@ietf.org>

Hello working group participants,

One of the items identified during the WG meeting in Seoul was to formally= request, via the list, Working Group adoption of 5 extension drafts relate= d to DLEP. This email is that formal request.=C2=A0

The drafts are:=C2=A0

I have put all = 4 extensions on this email for expediency only; please do not assume that t= hey must be adopted as a group. The chairs would greatly appreciate thought= s from the WG, both positive and negative.

For pur= poses of determining WG consensus, a lack of a response will be seen as ind= icating support for adopting the draft (e.g. silence =3D=3D acceptance).=C2= =A0

Regards,
Stan



--001a114451aa373afd05481ec39b-- From nobody Thu Feb 9 13:36:07 2017 Return-Path: X-Original-To: manet@ietf.org Delivered-To: manet@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 43F9F12941C; Thu, 9 Feb 2017 13:36:01 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.42.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148667616127.8212.8381490802395076825.idtracker@ietfa.amsl.com> Date: Thu, 09 Feb 2017 13:36:01 -0800 Archived-At: Cc: manet@ietf.org Subject: [manet] I-D Action: draft-ietf-manet-dlep-pause-extension-00.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2017 21:36:01 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobile Ad-hoc Networks of the IETF. Title : DLEP Control Plane Based Pause Extension Authors : Bow-Nan Cheng David Wiggins Lou Berger Filename : draft-ietf-manet-dlep-pause-extension-00.txt Pages : 10 Date : 2017-02-09 Abstract: This document defines an extension to the DLEP protocol that enables a simple control plane based flow control mechanism. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-manet-dlep-pause-extension/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-manet-dlep-pause-extension-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Feb 9 13:36:26 2017 Return-Path: X-Original-To: manet@ietf.org Delivered-To: manet@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 147BF128B44; Thu, 9 Feb 2017 13:36:21 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.42.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148667618107.8146.6912872281112615678.idtracker@ietfa.amsl.com> Date: Thu, 09 Feb 2017 13:36:21 -0800 Archived-At: Cc: manet@ietf.org Subject: [manet] I-D Action: draft-ietf-manet-dlep-multi-hop-extension-00.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2017 21:36:21 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobile Ad-hoc Networks of the IETF. Title : DLEP Multi-Hop Forwarding Extension Authors : Bow-Nan Cheng Lou Berger Filename : draft-ietf-manet-dlep-multi-hop-extension-00.txt Pages : 9 Date : 2017-02-09 Abstract: This document defines an extension to the DLEP protocol that enables a the reporting and control of Multi-Hop Forwarding by DLEP capable modems. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-manet-dlep-multi-hop-extension/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-manet-dlep-multi-hop-extension-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Feb 9 13:36:50 2017 Return-Path: X-Original-To: manet@ietf.org Delivered-To: manet@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BC1B912941C; Thu, 9 Feb 2017 13:36:43 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.42.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148667620376.8118.2187640530476932203.idtracker@ietfa.amsl.com> Date: Thu, 09 Feb 2017 13:36:43 -0800 Archived-At: Cc: manet@ietf.org Subject: [manet] I-D Action: draft-ietf-manet-dlep-latency-extension-00.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2017 21:36:44 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobile Ad-hoc Networks of the IETF. Title : DLEP Lantency Range Extension Authors : Bow-Nan Cheng Lou Berger Filename : draft-ietf-manet-dlep-latency-extension-00.txt Pages : 5 Date : 2017-02-09 Abstract: This document defines an extension to the DLEP protocol to provide the range of latency that may be experienced on a link. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-manet-dlep-latency-extension/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-manet-dlep-latency-extension-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Feb 9 13:38:12 2017 Return-Path: X-Original-To: manet@ietf.org Delivered-To: manet@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 13A36129C91; Thu, 9 Feb 2017 13:38:07 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.42.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148667628707.8102.13409682946744251791.idtracker@ietfa.amsl.com> Date: Thu, 09 Feb 2017 13:38:07 -0800 Archived-At: Cc: manet@ietf.org Subject: [manet] I-D Action: draft-ietf-manet-dlep-da-credit-extension-00.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2017 21:38:07 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobile Ad-hoc Networks of the IETF. Title : DLEP DiffServ Aware Credit Windowing Extension Authors : Bow-Nan Cheng David Wiggins Lou Berger Filename : draft-ietf-manet-dlep-da-credit-extension-00.txt Pages : 15 Date : 2017-02-09 Abstract: This document defines an extension to the DLEP protocol that enables a DiffServ aware credit-windowing scheme for destination-specific flow control. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-manet-dlep-da-credit-extension/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-manet-dlep-da-credit-extension-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Feb 9 13:39:22 2017 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 51E9A129CA7; Thu, 9 Feb 2017 13:39:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=idirect.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IZKgz2fx_5xA; Thu, 9 Feb 2017 13:39:16 -0800 (PST) Received: from mx0b-00229401.pphosted.com (mx0b-00229401.pphosted.com [148.163.159.249]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B60E129C9B; Thu, 9 Feb 2017 13:39:16 -0800 (PST) Received: from pps.filterd (m0097890.ppops.net [127.0.0.1]) by mx0b-00229401.pphosted.com (8.16.0.20/8.16.0.20) with SMTP id v19LZh74003510; Thu, 9 Feb 2017 16:39:16 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=idirect.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=dk1; bh=d0wJKcDbJl1O3bSO6j4E70rPS2NC8jvHWT/+5zO2rsM=; b=JhMS18a4ije7RGWMioAcCNh0EOQjr+nCCNZuGyeJkc6hjM0QnAJ8CbiAXtUIY9Z0D9/u lvzqSOMg25r4OVVF3wFy42wVpBBz7EnVxyUkEwzzOoKjpNcyLZUiFtCsZeIDwQs8kfvM sYOm7iWnXbZ7xOuot9koQS8YOU50YXSHmzXI4G/AUylAfHSHe+xd/In2GasmRNIlATli 5TLgWD1vtF7HMWDBEMrxBp9MYKJkqKNcfLDNJEh26E3AI0E9QK2VsHL1yS5sfwemNWMc 7i4njovCzqp3eBxj3UTNiu+hisWfl9tO4znaHFtE6qjkNflkfnk8j2xl+RDNXzksA3il xA== Received: from webmail.idirect.net ([198.180.159.2]) by mx0b-00229401.pphosted.com with ESMTP id 28dc5h3wem-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 09 Feb 2017 16:39:15 -0500 Received: from VAUSDITCHM2.idirect.net (10.250.250.202) by VAUSDITCHM2.idirect.net (10.250.250.202) with Microsoft SMTP Server (TLS) id 15.0.1236.3; Thu, 9 Feb 2017 16:39:15 -0500 Received: from VAUSDITCHM2.idirect.net ([fe80::b5b6:9e50:3403:e75d]) by VAUSDITCHM2.idirect.net ([fe80::b5b6:9e50:3403:e75d%15]) with mapi id 15.00.1236.000; Thu, 9 Feb 2017 16:39:15 -0500 From: "Ratliff, Stanley" To: "internet-drafts@ietf.org" , "i-d-announce@ietf.org" Thread-Topic: [manet] I-D Action: draft-ietf-manet-dlep-da-credit-extension-00.txt Thread-Index: AQHSgxzZ5tLM5QRnPEmhoUJ4dB8J16FhM45w Date: Thu, 9 Feb 2017 21:39:15 +0000 Message-ID: References: <148667628707.8102.13409682946744251791.idtracker@ietfa.amsl.com> In-Reply-To: <148667628707.8102.13409682946744251791.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.250.250.20] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-02-09_13:, , signatures=0 X-Proofpoint-Spam-Details: rule=outboundspam_notspam policy=outboundspam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1612050000 definitions=main-1702090194 Archived-At: Cc: "manet@ietf.org" Subject: Re: [manet] I-D Action: draft-ietf-manet-dlep-da-credit-extension-00.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2017 21:39:18 -0000 WG Participants,=20 Please note that there is already agreement to merge this draft with the ex= isting credit-windowing draft.=20 Regards, Stan > -----Original Message----- > From: manet [mailto:manet-bounces@ietf.org] On Behalf Of internet- > drafts@ietf.org > Sent: Thursday, February 09, 2017 4:38 PM > To: i-d-announce@ietf.org > Cc: manet@ietf.org > Subject: [manet] I-D Action: draft-ietf-manet-dlep-da-credit-extension- > 00.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Mobile Ad-hoc Networks of the IETF. >=20 > Title : DLEP DiffServ Aware Credit Windowing Extension > Authors : Bow-Nan Cheng > David Wiggins > Lou Berger > Filename : draft-ietf-manet-dlep-da-credit-extension-00.txt > Pages : 15 > Date : 2017-02-09 >=20 > Abstract: > This document defines an extension to the DLEP protocol that enables > a DiffServ aware credit-windowing scheme for destination-specific > flow control. >=20 >=20 > The IETF datatracker status page for this draft is: > https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > 3A__datatracker.ietf.org_doc_draft-2Dietf-2Dmanet-2Ddlep-2Dda-2Dcredit- > 2Dextension_&d=3DDwICAg&c=3DLlUvidvlhStGUSxQl0giOA&r=3DQzgCKlK- > eUsbLW5r8KZAL9L_yqNON1dbKtMa- > Wbxna8&m=3D9TQb6Q5N3BVTInZ75WoGOOnfJUebZ79I48J4BqgfULw&s=3D0w3f > AQEHq-AFeAS0_0V-qYD3X2_V5ICYQYzYyc3Xs_s&e=3D >=20 > There's also a htmlized version available at: > https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > 3A__tools.ietf.org_html_draft-2Dietf-2Dmanet-2Ddlep-2Dda-2Dcredit- > 2Dextension-2D00&d=3DDwICAg&c=3DLlUvidvlhStGUSxQl0giOA&r=3DQzgCKlK- > eUsbLW5r8KZAL9L_yqNON1dbKtMa- > Wbxna8&m=3D9TQb6Q5N3BVTInZ75WoGOOnfJUebZ79I48J4BqgfULw&s=3DvS4_ > ErYmNSqmCuJN2GQIxdAhWASU-t02QmM3REGP7YA&e=3D >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > https://urldefense.proofpoint.com/v2/url?u=3Dftp-3A__ftp.ietf.org_interne= t- > 2Ddrafts_&d=3DDwICAg&c=3DLlUvidvlhStGUSxQl0giOA&r=3DQzgCKlK- > eUsbLW5r8KZAL9L_yqNON1dbKtMa- > Wbxna8&m=3D9TQb6Q5N3BVTInZ75WoGOOnfJUebZ79I48J4BqgfULw&s=3DlceM > culiCdita8xLaO2U354BvtcjwbCCS6X8FNPtgXQ&e=3D >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > 3A__www.ietf.org_mailman_listinfo_manet&d=3DDwICAg&c=3DLlUvidvlhStGUSx > Ql0giOA&r=3DQzgCKlK-eUsbLW5r8KZAL9L_yqNON1dbKtMa- > Wbxna8&m=3D9TQb6Q5N3BVTInZ75WoGOOnfJUebZ79I48J4BqgfULw&s=3DxuEj5 > CF-nwub-tZ7Ixil9PID0Bb2S7SaQcBalurdB7E&e=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D This electronic message and any files transmitted with it contains information from iDirect, which may be privileged, proprietary and/or confidential. It is intended solely for the use of the individual or entity to whom they are addressed. If you are not the original recipient or the person responsible for delivering the email to the intended recipient, be advised that you have received this email in error, and that any use, dissemination, forwarding, printing, or copying of this email is strictly prohibited. If you received this email in error, please delete it and immediately notify the sender. From nobody Thu Feb 9 14:26:04 2017 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 BD98C1294D4 for ; Thu, 9 Feb 2017 14:26:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.887 X-Spam-Level: X-Spam-Status: No, score=-3.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-1.887, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id deTdAy7ZusUs for ; Thu, 9 Feb 2017 14:26:00 -0800 (PST) Received: from gproxy3-pub.mail.unifiedlayer.com (gproxy3-pub.mail.unifiedlayer.com [69.89.30.42]) by ietfa.amsl.com (Postfix) with SMTP id DB54E1293FF for ; Thu, 9 Feb 2017 14:25:59 -0800 (PST) Received: (qmail 2674 invoked by uid 0); 9 Feb 2017 22:25:57 -0000 Received: from unknown (HELO CMOut01) (10.0.90.82) by gproxy3.mail.unifiedlayer.com with SMTP; 9 Feb 2017 22:25:57 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by CMOut01 with id imRt1u00r2SSUrH01mRwrz; Thu, 09 Feb 2017 15:25:56 -0700 X-Authority-Analysis: v=2.1 cv=U+QBU4bu c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=N659UExz7-8A:10 a=xqWC_Br6kY4A:10 a=n2v9WMKugxEA:10 a=48vgC7mUAAAA:8 a=RpNjiQI2AAAA:8 a=2mPiOllCa0SN33ktqxoA:9 a=ZBfsrXKoU43f44JF:21 a=aVPzCvDol_xkr-3M:21 a=pILNOxqGKmIA:10 a=w1C3t2QeGrPiZgrLijVG:22 a=vJuR_VyAocOa-HWBgGQO:22 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:Cc:References:To:Subject:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=Fu/zCCO4a9Qc4cvBPTaysWfGelCOcfWPlyTm0RwJt5o=; b=IDkCgFaf5kPBnIi24WgHIO1be9 HmrO8jFqqhLAk9eKOyDPyYnzY35bFZcs9lXfKpIOEvXk/VZw7yugCs7UVWzx6QDls9LNuiTLQVJwt jTs1d3kTpSYDukmyKOJlZpm9J; Received: from pool-100-15-85-191.washdc.fios.verizon.net ([100.15.85.191]:50058 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1cbxA1-0007l9-QH; Thu, 09 Feb 2017 15:25:53 -0700 To: "Ratliff, Stanley" References: <148667628707.8102.13409682946744251791.idtracker@ietfa.amsl.com> From: Lou Berger Message-ID: Date: Thu, 9 Feb 2017 17:25:49 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box313.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-BWhitelist: no X-Source-IP: 100.15.85.191 X-Exim-ID: 1cbxA1-0007l9-QH X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-100-15-85-191.washdc.fios.verizon.net ([IPv6:::1]) [100.15.85.191]:50058 X-Source-Auth: lberger@labn.net X-Email-Count: 2 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== Archived-At: Cc: "manet@ietf.org" Subject: [manet] undirectional or bidirectional (Was Re: I-D Action: draft-ietf-manet-dlep-da-credit-extension-00.txt) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2017 22:26:01 -0000 Thanks Stan. WG, So one of the basic differences in the drafts is that this document only supports flow control in one direction, i.e., for traffic sent from a router to a modem, while the other credit-window draft supports it in both directions. We'd like feedback from the WG on which approach to follow. We (authors of the DA draft) made a conscious choice to limit the DA credit based flow control to one direction out of the desire to keep the extension as simple as possible and to provide what is really expected to be used. Clearly the reason for being able to control traffic that is sent from the router to the modem/radio is pretty easily understood. Also, while bidirectional flow control existed in pre-dlep solutions, it wasn't really used -- and in one reported bug/case resulted in traffic dropped unnecessarily. That said, it at first seemed appealing to define a symmetric approach that supports flow control in either direction, but when getting into the details of DLEP message formats ( and different message types in general, based on sender type) the result was a symmetric solution that used non-symmetric messaging - which in the authors opinion was fairly complex. So, given: (a) the added complexity of document/protocol/code needed to support bidirectional credit control and (b) no one has ever used or currently expects to use credit flow control for traffic destined to a router We concluded that unidirectional definition was the right place to aim *at this time*. This of course doesn't preclude someone from defining a companion definition for modem to router traffic flow control down the road -- when there is an actual need. So the question for the WG is: Should the merged / future credit window definition support (1) bidirectional (credit) flow control, or (2) flow control for only traffic from a router to a modem? Said another way: does anyone wish to advocate the position that we need credit window flow control for traffic received over the air, and sent from modem to router, *now*? Thanks, Lou On 2/9/2017 4:39 PM, Ratliff, Stanley wrote: > WG Participants, > > Please note that there is already agreement to merge this draft with the existing credit-windowing draft. > > Regards, > Stan > > >> -----Original Message----- >> From: manet [mailto:manet-bounces@ietf.org] On Behalf Of internet- >> drafts@ietf.org >> Sent: Thursday, February 09, 2017 4:38 PM >> To: i-d-announce@ietf.org >> Cc: manet@ietf.org >> Subject: [manet] I-D Action: draft-ietf-manet-dlep-da-credit-extension- >> 00.txt >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts directories. >> This draft is a work item of the Mobile Ad-hoc Networks of the IETF. >> >> Title : DLEP DiffServ Aware Credit Windowing Extension >> Authors : Bow-Nan Cheng >> David Wiggins >> Lou Berger >> Filename : draft-ietf-manet-dlep-da-credit-extension-00.txt >> Pages : 15 >> Date : 2017-02-09 >> >> Abstract: >> This document defines an extension to the DLEP protocol that enables >> a DiffServ aware credit-windowing scheme for destination-specific >> flow control. >> >> >> The IETF datatracker status page for this draft is: >> https://urldefense.proofpoint.com/v2/url?u=https- >> 3A__datatracker.ietf.org_doc_draft-2Dietf-2Dmanet-2Ddlep-2Dda-2Dcredit- >> 2Dextension_&d=DwICAg&c=LlUvidvlhStGUSxQl0giOA&r=QzgCKlK- >> eUsbLW5r8KZAL9L_yqNON1dbKtMa- >> Wbxna8&m=9TQb6Q5N3BVTInZ75WoGOOnfJUebZ79I48J4BqgfULw&s=0w3f >> AQEHq-AFeAS0_0V-qYD3X2_V5ICYQYzYyc3Xs_s&e= >> >> There's also a htmlized version available at: >> https://urldefense.proofpoint.com/v2/url?u=https- >> 3A__tools.ietf.org_html_draft-2Dietf-2Dmanet-2Ddlep-2Dda-2Dcredit- >> 2Dextension-2D00&d=DwICAg&c=LlUvidvlhStGUSxQl0giOA&r=QzgCKlK- >> eUsbLW5r8KZAL9L_yqNON1dbKtMa- >> Wbxna8&m=9TQb6Q5N3BVTInZ75WoGOOnfJUebZ79I48J4BqgfULw&s=vS4_ >> ErYmNSqmCuJN2GQIxdAhWASU-t02QmM3REGP7YA&e= >> >> >> Please note that it may take a couple of minutes from the time of submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> Internet-Drafts are also available by anonymous FTP at: >> https://urldefense.proofpoint.com/v2/url?u=ftp-3A__ftp.ietf.org_internet- >> 2Ddrafts_&d=DwICAg&c=LlUvidvlhStGUSxQl0giOA&r=QzgCKlK- >> eUsbLW5r8KZAL9L_yqNON1dbKtMa- >> Wbxna8&m=9TQb6Q5N3BVTInZ75WoGOOnfJUebZ79I48J4BqgfULw&s=lceM >> culiCdita8xLaO2U354BvtcjwbCCS6X8FNPtgXQ&e= >> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://urldefense.proofpoint.com/v2/url?u=https- >> 3A__www.ietf.org_mailman_listinfo_manet&d=DwICAg&c=LlUvidvlhStGUSx >> Ql0giOA&r=QzgCKlK-eUsbLW5r8KZAL9L_yqNON1dbKtMa- >> Wbxna8&m=9TQb6Q5N3BVTInZ75WoGOOnfJUebZ79I48J4BqgfULw&s=xuEj5 >> CF-nwub-tZ7Ixil9PID0Bb2S7SaQcBalurdB7E&e= > ============================================================================================================================================ > This electronic message and any files transmitted with it contains > information from iDirect, which may be privileged, proprietary > and/or confidential. It is intended solely for the use of the individual > or entity to whom they are addressed. If you are not the original > recipient or the person responsible for delivering the email to the > intended recipient, be advised that you have received this email > in error, and that any use, dissemination, forwarding, printing, or > copying of this email is strictly prohibited. If you received this email > in error, please delete it and immediately notify the sender. > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > From nobody Sun Feb 12 11:23:05 2017 Return-Path: X-Original-To: manet@ietf.org Delivered-To: manet@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 01A31129AAD; Sun, 12 Feb 2017 11:22:59 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alexey Melnikov" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.43.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148692737899.6211.5674368789340482960.idtracker@ietfa.amsl.com> Date: Sun, 12 Feb 2017 11:22:58 -0800 Archived-At: Cc: manet@ietf.org, draft-ietf-manet-dlep@ietf.org, manet-chairs@ietf.org Subject: [manet] Alexey Melnikov's Discuss on draft-ietf-manet-dlep-27: (with DISCUSS and COMMENT) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Feb 2017 19:22:59 -0000 Alexey Melnikov has entered the following ballot position for draft-ietf-manet-dlep-27: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-manet-dlep/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- This is generally a well written document and I enjoyed reading it. I have one remaining question which I would like to quickly discuss before recommending approval of this document: Section 14 (Security Considerations) now says: When TLS is in use, each peer SHOULD check the validity of credentials presented by the other peer during TLS session establishment. Mobile implementations MAY need to consider use of pre-shared keys for credentials; implementations following the "networked deployment" model described in Implementation Scenarios SHOULD refer to [RFC7525] for additional details. RFC 7525 that you are referencing contains recommendations on version of TLS and ciphersuites to use. Section 6.1 of RFC 7525 talks about "Host Name Validation". I don't think this section applies to DLEP. So can you elaborate on how server identity is going to be verified using pre-shared keys and which parts of RFC 7525 do you think apply to DLEP? ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for addressing my earlier DISCUSS points. 13. DLEP Data Items Following is the list of core Data Items that MUST be recognized by a DLEP compliant implementation. As mentioned before, not all Data Items need be used during a session, but an implementation MUST correctly process these Data Items when correctly associated with a Signal or Message. Is "skip over or ignore" a valid way to "correctly process"? I think so, but this might not be obvious from the text as written. From nobody Sun Feb 12 11:26:05 2017 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 2EFCA129ABA; Sun, 12 Feb 2017 11:26:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BOXFhp2H80w6; Sun, 12 Feb 2017 11:25:58 -0800 (PST) Received: from mail-wr0-x243.google.com (mail-wr0-x243.google.com [IPv6:2a00:1450:400c:c0c::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF48312948A; Sun, 12 Feb 2017 11:25:57 -0800 (PST) Received: by mail-wr0-x243.google.com with SMTP id i10so21235776wrb.0; Sun, 12 Feb 2017 11:25:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=tVGVwlIUg4zkZZ9MzIZX2Z8Vv2g09pJdFt0gu5sewd4=; b=EpETkSA4tQjmdku7VMVNz0N2ixwCykE7OGQ7g+tGAHDA3fcIFfpgrx2hYdjE8fMCCp dHpHOTTgOsX3AaqKIu/rtMYSIEmv2CEQF321GrwnaXXBarjFTprcEfh8ySIKWbo6gLIX v2nJn0ZiU5Wr8EFugc5hW/OCkPvJr9bbt7cLuRd1DQLuFlrQetm/s+T8vonVlEXiEVoK ZyNKdOMslAWe3WhyqDLKGZqQnHuX/vkpNi54cUCg4cdS9K38JwNU6BrtSU3oIm9BqhlP opuUM/jTqnk7kCqSRjSrPolRYidqGQ30JQZvUxPYd5CIYs9wzqM2FxDpXZh9R8tU5MJl Bwig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=tVGVwlIUg4zkZZ9MzIZX2Z8Vv2g09pJdFt0gu5sewd4=; b=PsckYx+z1WBz2yK3tPGuRxYzTm+YF66BNVvndPRUGZPClHZEJGQLranPKt+MVVpFSE OrcZZLikRh83Ufqfsg8P1UDLqGWKc5Yz6Dm8JvrfYyzk2necygDYaaHT+AP07JwRx/m7 KUHxbbK8/zuvdCe2DfZFgvKl1iPW6QlKE9aqtYW8tTeMpVItPFcETXl+qvBS5ZfR6fso 6gv3gTQZNMms1BiFcjOB13+hTy/lriXkA3UkAdPP87zvxO5ngJxCV7ymv/9SH4vCSAD4 z0gzFyBJAPaWDBy5+1YMYEL190Agy5kz8bx0XpBwQDXViBADHyLWIOEAW5AjAq7ZxT4R g8Lw== X-Gm-Message-State: AMke39l0kDZi7AOcWgdz7HbpdTh4E4r9rgyaTI8ofq6ugb9rY7I3oYTQycTO5s9Lwtcj+sy6M2o7eUZw7zqbvQ== X-Received: by 10.223.130.204 with SMTP id 70mr15920293wrc.128.1486927556557; Sun, 12 Feb 2017 11:25:56 -0800 (PST) MIME-Version: 1.0 Received: by 10.80.178.101 with HTTP; Sun, 12 Feb 2017 11:25:56 -0800 (PST) In-Reply-To: <148692737899.6211.5674368789340482960.idtracker@ietfa.amsl.com> References: <148692737899.6211.5674368789340482960.idtracker@ietfa.amsl.com> From: Stan Ratliff Date: Sun, 12 Feb 2017 14:25:56 -0500 Message-ID: To: Alexey Melnikov Content-Type: multipart/alternative; boundary=001a114b4228d0c58905485a4c9d Archived-At: Cc: MANET IETF , The IESG , draft-ietf-manet-dlep@ietf.org, manet-chairs@ietf.org Subject: Re: [manet] Alexey Melnikov's Discuss on draft-ietf-manet-dlep-27: (with DISCUSS and COMMENT) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Feb 2017 19:26:00 -0000 --001a114b4228d0c58905485a4c9d Content-Type: text/plain; charset=UTF-8 On Sun, Feb 12, 2017 at 2:22 PM, Alexey Melnikov wrote: > Alexey Melnikov has entered the following ballot position for > draft-ietf-manet-dlep-27: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-manet-dlep/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > This is generally a well written document and I enjoyed reading it. > > I have one remaining question which I would like to quickly discuss > before recommending approval of this document: > > Section 14 (Security Considerations) now says: > > When TLS is in use, each peer SHOULD check the validity of > credentials presented by the other peer during TLS session > establishment. Mobile implementations MAY need to consider use of > pre-shared keys for credentials; implementations following the > "networked deployment" model described in Implementation Scenarios > SHOULD refer to [RFC7525] for additional details. > > RFC 7525 that you are referencing contains recommendations on version of > TLS and ciphersuites to use. > Section 6.1 of RFC 7525 talks about "Host Name Validation". I don't think > this section applies to DLEP. So can you elaborate on how server identity > is going to be verified using pre-shared keys and which parts of RFC 7525 > do you think apply to DLEP? > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Thank you for addressing my earlier DISCUSS points. > > 13. DLEP Data Items > > Following is the list of core Data Items that MUST be recognized by > a > DLEP compliant implementation. As mentioned before, not all Data > Items need be used during a session, but an implementation MUST > correctly process these Data Items when correctly associated with a > Signal or Message. > > Is "skip over or ignore" a valid way to "correctly process"? I think so, > but > this might not be obvious from the text as written. > Yes, "silently ignoring" a data is a valid way to "correctly process". We can make another run to tighten up this language. Regards, Stan > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > --001a114b4228d0c58905485a4c9d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sun, Feb 12, 2017 at 2:22 PM, Alexey Melnikov <= aamelnikov@fast= mail.fm> wrote:
Alexey Meln= ikov has entered the following ballot position for
draft-ietf-manet-dlep-27: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/<= wbr>statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-i= etf-manet-dlep/



-----------------------------------------------------------------= -----
DISCUSS:
-----------------------------------------------------------------= -----

This is generally a well written document and I enjoyed reading it.

I have one remaining question which I would like to quickly discuss
before recommending approval of this document:

Section 14 (Security Considerations) now says:

=C2=A0 =C2=A0When TLS is in use, each peer SHOULD check the validity of
=C2=A0 =C2=A0credentials presented by the other peer during TLS session
=C2=A0 =C2=A0establishment.=C2=A0 Mobile implementations MAY need to consid= er use of
=C2=A0 =C2=A0pre-shared keys for credentials; implementations following the=
=C2=A0 =C2=A0"networked deployment" model described in Implementa= tion Scenarios
=C2=A0 =C2=A0SHOULD refer to [RFC7525] for additional details.

RFC 7525 that you are referencing contains recommendations on version of TLS and ciphersuites to use.
Section 6.1 of RFC 7525 talks about "Host Name Validation". I don= 't think
this section applies to DLEP. So can you elaborate on how server identity is going to be verified using pre-shared keys and which parts of RFC 7525 do you think apply to DLEP?


-----------------------------------------------------------------= -----
COMMENT:
-----------------------------------------------------------------= -----

Thank you for addressing my earlier DISCUSS points.

13.=C2=A0 DLEP Data Items

=C2=A0 =C2=A0Following is the list of core Data Items that MUST be recogniz= ed by
a
=C2=A0 =C2=A0DLEP compliant implementation.=C2=A0 As mentioned before, not = all Data
=C2=A0 =C2=A0Items need be used during a session, but an implementation MUS= T
=C2=A0 =C2=A0correctly process these Data Items when correctly associated w= ith a
=C2=A0 =C2=A0Signal or Message.

Is "skip over or ignore" a valid way to "correctly process&q= uot;? I think so,
but
this might not be obvious from the text as written.
Yes, "silently ignoring" a data is a valid way to &q= uot;correctly process". We can make another run to tighten up this lan= guage.=C2=A0

Regards,
Stan
=C2=A0


_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet

--001a114b4228d0c58905485a4c9d-- From nobody Mon Feb 13 23:31:35 2017 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 D686012947A for ; Mon, 13 Feb 2017 23:31:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BWwV3Vjk0-Fz for ; Mon, 13 Feb 2017 23:31:33 -0800 (PST) Received: from mail-qt0-x22d.google.com (mail-qt0-x22d.google.com [IPv6:2607:f8b0:400d:c0d::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76A0B1204D9 for ; Mon, 13 Feb 2017 23:31:33 -0800 (PST) Received: by mail-qt0-x22d.google.com with SMTP id x49so103977678qtc.2 for ; Mon, 13 Feb 2017 23:31:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Ae3e/1DourBjPL6327nwTikIHHMLZLCgFzirHT+oxPU=; b=Z5cQciMcsWNJmimEidpU6YSAb9xAeRFIF1N5HwRuLgK0TQaTV+Hei67RNbCuDt28Xn vYuXOuamuQ98vUgJ/eBnN4XAhAjNRlsWMuGMGspLagzUevePs7n9Khy6jNg4onYL9cI9 WfpdwbY3wviM12vUy2MfEUwDeafp/yOw7EsCFg8p9CrX9rzw2+IlBPa0b43YS3tK47b1 bBu89vOszFlXW67Q/ywXIhkoFymX/NI/B2/bT0iPiSIVxX8XFLykUFFfJGbBqiLkw9eL YuSx2i4Slp2ycWBfd49bNdXkvQkX0WWmRoCynptiZahlZXD12Y0/WP4gglbx9e8EclMn qZPg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Ae3e/1DourBjPL6327nwTikIHHMLZLCgFzirHT+oxPU=; b=EmnF+hZS8vKDNTcMkSS+MoCoqdN36iOx/0YBgPnlklabH+9FbizEEisGXEBorDegvd nGDX/b2edvpk6IPYeSUPoTcqbFBvDo3rPUTwIIdHro9c3LoWx0kZ1E6qh0HJ91gxCXR9 p9U9lDAiNK3Cgeob4SSBh3D96mzx8BYCJFi6kYAUgt/N5quIKom+wScinLoXmsH3esLZ qxUrrSIeLd94cVUgd3YYXRUxAvf6ksddjqQUfYaMwhYrfeQrGeJ8L54Ta+C7qRCJKIrm ZYOy5M+o2DqrdIQukfMWyx04f67ISUhhD6ugwi98+SvZ66flbTYVfaE6oaS7p7CW3iCl /Bvw== X-Gm-Message-State: AMke39kBCV9YsyRy7OV1UuF1PGFLuMflQYXjHgzY6wOyrY5rUsybsSy9/VhgIea1JkWpw9i/OkZ993yE9BImcg== X-Received: by 10.200.48.110 with SMTP id g43mr24745275qte.277.1487057492519; Mon, 13 Feb 2017 23:31:32 -0800 (PST) MIME-Version: 1.0 Received: by 10.237.35.228 with HTTP; Mon, 13 Feb 2017 23:31:02 -0800 (PST) In-Reply-To: References: <148667628707.8102.13409682946744251791.idtracker@ietfa.amsl.com> From: Henning Rogge Date: Tue, 14 Feb 2017 08:31:02 +0100 Message-ID: To: Lou Berger Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "manet@ietf.org" Subject: Re: [manet] undirectional or bidirectional (Was Re: I-D Action: draft-ietf-manet-dlep-da-credit-extension-00.txt) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2017 07:31:35 -0000 On Thu, Feb 9, 2017 at 11:25 PM, Lou Berger wrote: > Thanks Stan. > > WG, > > So one of the basic differences in the drafts is that this document > only supports flow control in one direction, i.e., for traffic sent from > a router to a modem, while the other credit-window draft supports it in > both directions. We'd like feedback from the WG on which approach to > follow. > > We (authors of the DA draft) made a conscious choice to limit the DA > credit based flow control to one direction out of the desire to keep the > extension as simple as possible and to provide what is really expected > to be used. > > Clearly the reason for being able to control traffic that is sent from > the router to the modem/radio is pretty easily understood. Also, while > bidirectional flow control existed in pre-dlep solutions, it wasn't > really used -- and in one reported bug/case resulted in traffic dropped > unnecessarily. That said, it at first seemed appealing to define a > symmetric approach that supports flow control in either direction, but > when getting into the details of DLEP message formats ( and different > message types in general, based on sender type) the result was a > symmetric solution that used non-symmetric messaging - which in the > authors opinion was fairly complex. So, given: > (a) the added complexity of document/protocol/code needed to support > bidirectional credit control and > (b) no one has ever used or currently expects to use credit flow > control for traffic destined to a router > > We concluded that unidirectional definition was the right place to aim > *at this time*. This of course doesn't preclude someone from defining a > companion definition for modem to router traffic flow control down the > road -- when there is an actual need. > > So the question for the WG is: > > Should the merged / future credit window definition support (1) > bidirectional (credit) flow control, or (2) flow control for only > traffic from a router to a modem? > > Said another way: does anyone wish to advocate the position that we need > credit window flow control for traffic received over the air, and sent > from modem to router, *now*? Hi, in general flow control is about keeping the "bottleneck/queue" mostly on the router, where we can control it at a central point. That is an important part of the design goal of DLEP. I think flow control from the router towards the radio is THE most important part, it is practically necessary for all radios if you want to do some kind of Priorization on the router. Flow control from the radio to the router is a (in my opinion) rare cornercase for radios with a TDMA that can control incoming traffic. Because of this I think an unidirectional flow control extension is a good idea, otherwise we add a lot of complexity which will nearly never be used. Henning Rogge From nobody Tue Feb 14 01:36:12 2017 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 3FCD21294BD for ; Tue, 14 Feb 2017 01:36:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pStDoUXhxfMj for ; Tue, 14 Feb 2017 01:36:09 -0800 (PST) Received: from mailsrv.math.unipd.it (mailsrv.math.unipd.it [147.162.22.62]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91D7812009C for ; Tue, 14 Feb 2017 01:36:09 -0800 (PST) Received: from server0.math.unipd.it (smtpout.math.unipd.it [147.162.22.54]) by mailsrv.math.unipd.it (8.15.2/8.15.2) with ESMTPS id v1E9a46e026532 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 14 Feb 2017 09:36:04 GMT Received: from webmail.math.unipd.it (v0b1.math.unipd.it [147.162.22.157]) by server0.math.unipd.it (8.15.1/8.15.1) with ESMTPS id v1E9Znjp064419 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 14 Feb 2017 09:35:49 GMT Received: from host166-226-static.197-31-b.business.telecomitalia.it (host166-226-static.197-31-b.business.telecomitalia.it [31.197.226.166]) by webmail.math.unipd.it (Horde Framework) with HTTPS; Tue, 14 Feb 2017 10:36:06 +0100 Date: Tue, 14 Feb 2017 10:36:06 +0100 Message-ID: <20170214103606.Horde.cxHLFQt3IFzogiSCDz_3ujs@webmail.math.unipd.it> From: riccardo.lazzeretti@math.unipd.it To: manet@ietf.org User-Agent: Horde Application Framework 5 Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-DCC-URT-Metrics: server5.math.unipd.it 1060; Body=2 Fuz1=2 Fuz2=many X-IMP-Checker: SpamAssassin on webmail.math.unipd.it/imp checker X-Spam-Warning: SpamAssassin says this -probably- is not SPAM X-Scanned-By: MIMEDefang 2.78 Archived-At: Subject: [manet] [IEEE ATC 2017] Call for Workshop and Special Session Proposal LAST DAYS X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2017 09:36:11 -0000 Dear colleague, apologies for multiple postings. In conjunction with the 14th IEEE International Conference on Advanced and Trusted Computing (ATC 2017), we will organize some workshops. The workshop proposals should be submitted to ieee-atc2017@googlegroups.com Further information are provided in the ATC Call for Workshop page: http://cse.stfx.ca/~smartworld/2017/atc/cfw.php All accepted papers will be included in the ATC 2017 proceedings published by IEEE. Workshop/Special Session proposals should contain following information: · The title of the workshop/special session, including both full name and abbreviation (for workshop) · The objectives, scope, and contributions to the main conference (up to 1 page) · The short bios of the key organizers and their related experience · The procedure for selecting papers, plans for dissemination (e.g., how to advertise and special issues of journals), and the expected number of participants · A tentative list of program committee members · The (tentative) website/URL of the proposed workshop/special session Important Schedule for ATC Workshops and Special Sessions: · Proposal Due: extended to Feb 15, 2017 · Proposal Notification: extended to Feb 20, 2017 · Paper Submission, Notification: TBD by individual workshops a · Final Camera-ready Paper Due: June 10, 2017 Best regards, Riccardo Lazzeretti riccardo.lazzeretti@math.unipd.it Workshop Chair IEEE Advanced and Trusted Computing (ATC 2017) From nobody Tue Feb 14 15:28:22 2017 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 2E69C129956 for ; Tue, 14 Feb 2017 15:28:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YLuKUEoPTPih for ; Tue, 14 Feb 2017 15:28:19 -0800 (PST) Received: from da1vs01.rockwellcollins.com (da1vs01.rockwellcollins.com [205.175.227.27]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C1A81298C2 for ; Tue, 14 Feb 2017 15:28:19 -0800 (PST) X-RC-All-From: , 205.175.227.20, No hostname, james.a.stevens@rockwellcollins.com, "James A. (Jim) Stevens" , , X-RC-Attachments: , , X-RC-RemoteIP: 205.175.227.20 X-RC-RemoteHost: No hostname X-RC-IP-Hostname: da1ip01.rockwellcollins.com X-RC-IP-MID: 49213995 X-RC-IP-Group: GOOGLE_RELAYED X-RC-IP-Policy: $GOOGLE_RELAYED X-RC-IP-SBRS: None Received: from unknown (HELO mail-wr0-f199.google.com) ([205.175.227.20]) by da1vs01.rockwellcollins.com with ESMTP/TLS/AES128-SHA; 14 Feb 2017 17:28:18 -0600 Received: by mail-wr0-f199.google.com with SMTP id a15so49504814wrc.3 for ; Tue, 14 Feb 2017 15:28:18 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=WXKZL9/YPYuvRlF3tZCXDFl5fYLMa62RP2srOTYJBA0=; b=E5OqY6boRYTIevKa489pIY55dy87B9sJ4pgC3+uLOswr3p2L3RL+FF9EaMmQ8YHUa7 xKgUB1qdkNf319ROqFOyl+Jtdj/8YNe1j2nNJFtpCvsOMQhRezYUaQtuMWnF7Iu6o+/3 lOalr0NMV8y9/1Pig25VWySPgej6WlRsweG2UWGIq2BCv09wJNZazKmUuQl13VW+uEzF 7nO/Wih9s2LR1GmnGJZI/9lF8IHkSMsiXIgLmmThjxiXf44ydVJ3wtNVoCVfvILAYPMz OEWzPS9pWYNYZ1G7i1F81oidas4JAip7+9pc+stckyhs0pLp9FCmycjTx9t3G/lYoaX2 Vnqg== X-Gm-Message-State: AMke39lVO6ZDsEieQnOSw922FSOxcMb5L/k9mKWVnRBhABUVqPtHmbNY/8VviMEzM3W30+JBX6uSEQZS5W7GPCUvg465eWtrF6eXXmb3ZqS76v2b7HsZCJqbDefxrDzSWwzZPjh4nDF3wYEA6NAThHfHBjxs9bdNu9A= X-Received: by 10.28.209.7 with SMTP id i7mr5144221wmg.115.1487114896269; Tue, 14 Feb 2017 15:28:16 -0800 (PST) X-Received: by 10.28.209.7 with SMTP id i7mr5144211wmg.115.1487114896077; Tue, 14 Feb 2017 15:28:16 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.8.148 with HTTP; Tue, 14 Feb 2017 15:28:15 -0800 (PST) From: "James A. (Jim) Stevens" Date: Tue, 14 Feb 2017 17:28:15 -0600 Message-ID: To: "manet@ietf.org" Content-Type: multipart/alternative; boundary=94eb2c12e4c21f16c2054885eb89 Archived-At: Subject: Re: [manet] undirectional or bidirectional (Was Re: I-D Action: draft-ietf-manet-dlep-da-credit-extension-00.txt) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2017 23:28:21 -0000 --94eb2c12e4c21f16c2054885eb89 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Henning, I think I understand and agree with everything you wrote, but not absolutely sure, so want to double check. In your second paragraph, when you say that '"flow control from the router towards the radio is THE most important part, it is practically necessary for all radios if you want to do some kind of Priorization on the router =E2=80=8B" =E2=80=8B I can read the phrase "flow control from the router towards the radio" two ways. I think you mean meaning #1 below, correct? (1) radio sends unidirectional credit flow to router to perform "flow control from router towards radio" or (2) router sends unidirectional credit flow to radio to perform "flow control from router towards radio" Similarly for confusion in third paragraph on "flow control from the radio to the router". I agree if you meant meaning #1 above and disagree if you meant meaning #2 above. I strongly agree with your first and fourth paragraphs. Thanks, Jim Stevens =3D=3D Tue, 14 Feb 2017 08:31:02 +0100 email from Henning Rogge =3D=3D =3D=3D =3D=3D Hi, =3D=3D =3D=3D in general flow control is about keeping the "bottleneck/queue" most= ly =3D=3D on the router, where we can control it at a central point. That is a= n =3D=3D important part of the design goal of DLEP. =3D=3D =3D=3D I think flow control from the router towards the radio is THE most =3D=3D important part, it is practically necessary for all radios if you wa= nt =3D=3D to do some kind of Priorization on the router. =3D=3D =3D=3D Flow control from the radio to the router is a (in my opinion) rare =3D=3D cornercase for radios with a TDMA that can control incoming traffic. =3D=3D =3D=3D Because of this I think an unidirectional flow control extension is = a =3D=3D good idea, otherwise we add a lot of complexity which will nearly =3D=3D never be used. =3D=3D =3D=3D Henning Rogge =3D=3D --94eb2c12e4c21f16c2054885eb89 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hen= ning, I think I understand and agree with everything you wrote, but not abs= olutely sure, so want to double check.

In your second paragraph, when you say that '"flow control from the router towards the radio i= s THE most=C2=A0important part, it = is practically necessary for all radios if you want=C2=A0to do some kind of Priorization on the router<= div class=3D"gmail_default" style=3D"display:inline">=E2=80=8B" =E2=80= =8B

I can read the phrase "fl= ow control from the router towards the radio" two ways.

I think you mean meaning #1 below, corr= ect?

=
(1) radio sends unid= irectional credit flow to router to perform "flow control from router = towards radio"

or

(2) router sends unidirecti= onal credit flow to radio to perform "flow control from router towards= radio"
Similarly fo= r confusion in third paragraph on "flow control from the radio to the = router".
<= br>
I agree if = you meant meaning #1 above and disagree if =C2=A0you meant meaning #2 above= .

I strongly agree with y= our first and fourth paragraphs.

Thanks,
Jim Stevens
=3D= =3D=C2=A0=C2=A0Tue, 14 Feb 2017 08:= 31:02 +0100 email from Henning Rogge
=3D=3D=C2=A0
=3D= =3D=C2=A0
= =3D=3D Hi,
=3D=3D=C2=A0
=3D=3D in general flow con= trol is about keeping the "bottleneck/queue" mostly
=3D=3D on the rout= er, where we can control it at a central point. That is an
=3D=3D important par= t of the design goal of DLEP.
=3D=3D= =C2=A0
=3D= =3D I think flow control from the router towards the radio is THE most
=3D=3D im= portant part, it is practically necessary for all radios if you want=
=3D=3D to d= o some kind of Priorization on the router.
=3D=3D=C2=A0
=3D=3D Flow control from the radio to the router is a (in my opinion)= rare
=3D=3D cornercase for radios with a TDMA that can control incoming traffic= .
=3D=3D=C2=A0
=3D=3D Because of this I think an u= nidirectional flow control extension is a
=3D=3D good idea, otherwise we add a l= ot of complexity which will nearly
=3D=3D never be used.
=3D=3D=C2=A0
=3D=3D Henning Rogge
=3D=3D=C2=A0

--94eb2c12e4c21f16c2054885eb89-- From nobody Tue Feb 14 23:05:07 2017 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 461671294DA for ; Tue, 14 Feb 2017 23:05:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nt0ws2ITHtB7 for ; Tue, 14 Feb 2017 23:05:05 -0800 (PST) Received: from mail-qt0-x234.google.com (mail-qt0-x234.google.com [IPv6:2607:f8b0:400d:c0d::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9BEA1294CD for ; Tue, 14 Feb 2017 23:05:04 -0800 (PST) Received: by mail-qt0-x234.google.com with SMTP id v23so130283593qtb.0 for ; Tue, 14 Feb 2017 23:05:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=hkgfq0hdoO2F79psxyhw2loQ/STll3fiq2YszgU4oms=; b=ENcf1TxLpzCWLjARjmrpqsBcglT6B2bEeaw4tQHTjwNLFOow02CpuZkZ3d7gwPmyZz ex2nUZLD5QqUGhaIrr09FmP+ReskqUygEhGdQZ6h8Bu1G6n5AyFhI+pyU443NVJfV6fg Ag/3K/LqKnrjo/DUVczv3P1tE+WIQ1OhK1rw45q0HdnLB9K4tryGFW4g5ojTfPx5uTnO lk2pPgIemlz8sOXFrB1e7rYk1Ra9+6ILFNXW09f3K4T+waCQouYdWHjnv5vrmjUr/4VQ rY16v4U62L7uauZHp3bEU2kNHFd1JKiyTUbHzSFUd3NOaG8nJmwOA8LnY3D5UTsHhaaB wHOA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=hkgfq0hdoO2F79psxyhw2loQ/STll3fiq2YszgU4oms=; b=roy8XX59/fMb5eFrGPVJUwoRAHkFzMFxqZ5engCvNcedMooYTaQYpBvjkmH1CMwBJ2 YYSZoa81ASFzXoYZJazq3aAYmP3FSt4S0IGEA1EwIpOS+uW/3Xi4w7pcMypPIbn3UZZb HwRD97aYfzMNtE92qnFkQAepm5bKvHFIezl4mrXr7uFyG3mNA6oJggA3vgizgzotAZqX rVT6tG7gwqEyCGZkgcpyBpHJPq707i2zGL5BzWbhEZZRD37NtveTPVzPOEuDV1YASV0m IFkSB16Y8VNJxKpRYxJlk+ySmGyMR6i5N8ey16EXHV35sgHP/I4gY51RhSYxncknTlE5 i/rQ== X-Gm-Message-State: AMke39mzKaH26vefddxbuZEtmQ6pW+6Zpswobzll0630kNBa4KOt2CGGg8NWCeSO40IDpGLz2+amj/CVVHh2Sg== X-Received: by 10.237.54.1 with SMTP id e1mr29998869qtb.68.1487142303977; Tue, 14 Feb 2017 23:05:03 -0800 (PST) MIME-Version: 1.0 Received: by 10.237.35.228 with HTTP; Tue, 14 Feb 2017 23:04:33 -0800 (PST) In-Reply-To: References: From: Henning Rogge Date: Wed, 15 Feb 2017 08:04:33 +0100 Message-ID: To: "James A. (Jim) Stevens" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "manet@ietf.org" Subject: Re: [manet] undirectional or bidirectional (Was Re: I-D Action: draft-ietf-manet-dlep-da-credit-extension-00.txt) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2017 07:05:06 -0000 On Wed, Feb 15, 2017 at 12:28 AM, James A. (Jim) Stevens wrote: > Henning, I think I understand and agree with everything you wrote, but not > absolutely sure, so want to double check. *sigh* you are right, I should have been more specific. Flow control of "user data moving from router to radio" is most important to move the bottleneck from the interface specific radio to the generic router. Henning > In your second paragraph, when you say that '"flow control from the router > towards the radio is THE most important part, it is practically necessary > for all radios if you want to do some kind of Priorization on the router > " > > I can read the phrase "flow control from the router towards the radio" two > ways. > > I think you mean meaning #1 below, correct? > > (1) radio sends unidirectional credit flow to router to perform "flow > control from router towards radio" > > or > > (2) router sends unidirectional credit flow to radio to perform "flow > control from router towards radio" > > Similarly for confusion in third paragraph on "flow control from the radio > to the router". > > I agree if you meant meaning #1 above and disagree if you meant meaning #2 > above. > > I strongly agree with your first and fourth paragraphs. > > Thanks, > Jim Stevens > > == Tue, 14 Feb 2017 08:31:02 +0100 email from Henning Rogge > == > == > == Hi, > == > == in general flow control is about keeping the "bottleneck/queue" mostly > == on the router, where we can control it at a central point. That is an > == important part of the design goal of DLEP. > == > == I think flow control from the router towards the radio is THE most > == important part, it is practically necessary for all radios if you want > == to do some kind of Priorization on the router. > == > == Flow control from the radio to the router is a (in my opinion) rare > == cornercase for radios with a TDMA that can control incoming traffic. > == > == Because of this I think an unidirectional flow control extension is a > == good idea, otherwise we add a lot of complexity which will nearly > == never be used. > == > == Henning Rogge > == > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > From nobody Wed Feb 15 11:56:09 2017 Return-Path: X-Original-To: manet@ietf.org Delivered-To: manet@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E904129A80; Wed, 15 Feb 2017 11:56:07 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.43.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148718856761.31595.17672999116389427297.idtracker@ietfa.amsl.com> Date: Wed, 15 Feb 2017 11:56:07 -0800 Archived-At: Cc: manet@ietf.org, manet-chairs@ietf.org Subject: [manet] manet - New Meeting Session Request for IETF 98 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2017 19:56:07 -0000 A new meeting session request has just been submitted by Stan Ratliff, a Chair of the manet working group. --------------------------------------------------------- Working Group Name: Mobile Ad-hoc Networks Area Name: Routing Area Session Requester: Stan Ratliff Number of Sessions: 1 Length of Session(s): 1.5 Hours Number of Attendees: 50 Conflicts to Avoid: First Priority: roll rtgarea babel dtn teas Second Priority: ospf lisp People who must be present: Stan Ratliff Justin Dean Alvaro Retana Resources Requested: Special Requests: --------------------------------------------------------- From nobody Fri Feb 17 02:31:54 2017 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 5EAD9129759 for ; Fri, 17 Feb 2017 02:31:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.687 X-Spam-Level: X-Spam-Status: No, score=-2.687 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NVQZNtFQyszI for ; Fri, 17 Feb 2017 02:31:50 -0800 (PST) Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4390A1296DE for ; Fri, 17 Feb 2017 02:31:50 -0800 (PST) Received: by mail-qk0-x231.google.com with SMTP id u25so40184624qki.2 for ; Fri, 17 Feb 2017 02:31:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:from:date:message-id:subject:to; bh=CEs1wqixMguuf7ymKVe6kr8sEIIcpgwqwysipAlcNq8=; b=kHrYV+g9S0ufsoLfuoGwN+hqLB0GsvMK5e4qMPESzgkVQIAOX3BYrYwq9m05YCfeNF LL6a9YLCi80kWlAoaPsMdm40OliITPhQHLsTuG8M1/4NRkJe27wFuZrcqDz1waRMR/PE DGMT2837EWsB7HDFlrYKwaK6MuLoeDuG2ALqsgpc6PHXyTi5ArUhblVVdxhICpEJvN9J 3lggMBFF0uSKQivHodkNzhWS4m56TrTgje7WflpmAUcuoQsJ0fmVSt2UuxMbsGSz8pm4 KVfZ2S1b/qHV/oU6lBe0WfX0UxqgkR0m/T/9bb1OohvqKFn2ph0AqCBZnBnVVo+8cMay i2zA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to; bh=CEs1wqixMguuf7ymKVe6kr8sEIIcpgwqwysipAlcNq8=; b=VpW+0dUmF3nFqi5JRAER3rK9I7hlDbbl10T9Ul1Uz7Rwr+goucc8rzCo7Ke2CSFMGt K8SB2Yc5HWMKSihgO5a89jAmYMNRN+M+GnAThVjZPu7k1xf6yvwQnGUGDQRQqb/JzL4S zGgTIj8spzfu+8Fs3Oao2E3ioeP1efXEi1wdEYvdxP8IV+6+sWZ2NIL+Bww+sUxZBKfO ApHCOMbO7MY0Vwi5T4K0O/QjXo64rqCyS0xrRm2EUXa2ocvRK7OxGps4oKj+fbAVPc4s x5xq3M7kekh9hWNbqZyLhVXC4ovacHAzOsD1ZXNasXa7vZESMusSmnJyb2AANAywVv5O fpew== X-Gm-Message-State: AMke39mYFPZ0DXd2f3ID049SbH5ml6YGkyMsHwzyb7TZ3dYGsrwlVJ2TJT/pfW9MmL9YZ8p0hRx8WHNAUri5qQ== X-Received: by 10.55.6.150 with SMTP id 144mr6317560qkg.46.1487327509272; Fri, 17 Feb 2017 02:31:49 -0800 (PST) Received: from 52669349336 named unknown by gmailapi.google.com with HTTPREST; Fri, 17 Feb 2017 05:31:48 -0500 MIME-Version: 1.0 Sender: chhagan.iiita@gmail.com From: chhagan.iiita@gmail.com Date: Fri, 17 Feb 2017 05:31:48 -0500 X-Google-Sender-Auth: hhSsCBb7rGTORsqLmI67pDezlnc Message-ID: To: manet@ietf.org Content-Type: multipart/alternative; boundary=001a114d819edadf100548b76bd5 Archived-At: Subject: [manet] Deadline Approaching: Research Fellow positions in Computer Security X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2017 10:31:52 -0000 --001a114d819edadf100548b76bd5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Research Fellow positions in Computer Security University of Padua - SPRITZ Security and Privacy Research Group JOB DESCRIPTION: The SPRITZ Security and Privacy Research Group at the University of Padova is looking for four research fellows to participate in the project funded by EU H2020 titled =E2=80=9CSolutions for= access and safe use of mobile scanners devices=E2=80=9D. IoT is about connecting b= illions of objects, things, devices. The overall objective of TagItSmart! ( tagitsmart.eu) is to create a set of tools and enabling technologies integrated into a platform with open interfaces, enabling users across the value chain to fully exploit the power of condition-dependent FunCodes, to connect mass-market products with the digital world across multiple application sectors. The key requirements for the position are as follows: - Recent PhD (or significant research experience) in Computer Science, Computer Engineering, or related areas. - Hands-on experience in some of the following areas will be plus: - Internet of Things (IoT) - Application/service provisioning architectures - Android security - Security and reliability in RFID/NFC scanning - Trusted Platform Module - Software design/implementation and prototyping skills. - Algorithms design and implementation skills. - Experience in working on EU projects is desirable. - Publications in high impact journals and well known conferences. ABOUT UNIVERSITY OF PADOVA AND THE SPRITZ GROUP The University of Padua is the University of Galileo Galilei, and the first University that awarded a degree to a woman. The first ever report issued by the National Research Assessment Committee set the University of Padova as the highest ranking among leading Italian universities for the quality of its research results. Based on the number of citations of articles and publications by its researchers (source: ISI), the University of Padova ranks among the top three Italian universities for total impact index, productivity index, and presence index. SPRITZ Security and Privacy Research Group is a group of researchers very passionate in investigating security and privacy issues related to current and future technologies. The SPRITZ group was founded (in 2011) and is led by Prof. Mauro Conti (http://www.math.unipd.it/~conti/). The group is mostly based at the University of Padua, while it enjoys worldwide collaborations. For more information about our group please visit: http://spritz.math.unipd.it/ HOW TO APPLY Interested candidates are invited to contact Prof. Mauro Conti directly (conti@math.unipd.it). For more information about the position and how to apply please visit the following link: http://www.math.unipd.it/it/news/?id=3D1971 Applications must be received by March 01, 2017. --=20 Thanks, Best Regards, Chhagan Lal, PhD, Research/Postdoc Fellow, University of Padua - Department of Mathematics, *SPRITZ - Security and Privacy Research Group* *http://spritz.math.unipd.it/team.html * --001a114d819edadf100548b76bd5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= Research Fellow positions in Co= mputer Security

University of Padua - SPRITZ Security = and Privacy Research Group


JOB DESCRIPTION:

The SPRITZ Security and Priva= cy Research Group at the University of Padova is looking for four research = fellows to participate in the project funded by EU H2020 titled =E2=80=9CSo= lutions for access and safe use of mobile scanners devices=E2=80=9D. IoT is= about connecting billions of objects, things, devices. The overall objecti= ve of TagItSmart! (tagitsmart.eu) is to create a set of tools and enabling technologies integrated int= o a platform with open interfaces, enabling users across the value chain to= fully exploit the power of condition-dependent FunCodes, to connect mass-m= arket products with the digital world across multiple application sectors.<= /span>


The key requirements for the position are as follo= ws:

  • Recent PhD (or significant research experienc= e) in Computer Science, Computer Engineering, or related areas.

    <= /li>

  • Hands-on experience in some= of the following areas will be plus:

        • <= p style=3D"line-height:1.38;margin-top:0pt;margin-bottom:0pt" dir=3D"ltr"><= span style=3D"font-size:11pt;font-family:arial;color:rgb(0,0,0);background-= color:transparent;font-weight:400;font-style:normal;font-variant:normal;tex= t-decoration:none;vertical-align:baseline">Internet of Things (IoT)<= /p>

      • Application/service p= rovisioning architectures

      • Android security

      • Security and reliability in RFID/NFC scanning

      • Trusted Platform Module

  • Software = design/implementation and prototyping skills.

  • Algorithms design and implementation skills.<= /span>

  • Experience in wo= rking on EU projects is desirable.

  • Publications in high impact journals and well known con= ferences.


ABOUT = UNIVERSITY OF PADOVA AND THE SPRITZ GROUP

The University of Padua is the University of Galileo Galilei, and th= e first University that awarded a degree to a woman. The first ever report = issued by the National Research Assessment Committee set the University of = Padova as the highest ranking among leading Italian universities for the qu= ality of its research results. Based on the number of citations of articles= and publications by its researchers (source: ISI), the University of Padov= a ranks among the top three Italian universities for total impact index, pr= oductivity index, and presence index.

SPRITZ Security and Privacy Research Group is a group of researchers ver= y passionate in investigating security and privacy issues related to curren= t and future technologies. The SPRITZ group was founded (in 2011) and is le= d by Prof. Mauro Conti (= http://www.math.unipd.it/~conti/)= . The group is mostly based at the University of Padua, while it enjoys wor= ldwide collaborations. For more information about our group please visit: http://spritz.math.unipd.= it/


HOW TO APPLY

Interested candidates are invited to co= ntact Prof. Mauro Conti directly (conti@math.unipd.it). For more information about the position and how= to apply please visit the following link: http://www.math.u= nipd.it/it/news/?id=3D1971


Applications must be received by March 01, 2017.

--
Thanks,
Best Regards,
Chha= gan Lal, PhD,=C2=A0
Research/Postdoc Fellow,=C2=A0
University of Padua - Department of Mathematics,=C2=A0<= /div>
SPRITZ - Security and Privacy Research Group
--001a114d819edadf100548b76bd5-- From nobody Thu Feb 23 14:23:10 2017 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 74B041296D5; Thu, 23 Feb 2017 13:40:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lnT069xVLg0q; Thu, 23 Feb 2017 13:40:06 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 164B512940A; Thu, 23 Feb 2017 13:40:06 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 06BA2B81FCA; Thu, 23 Feb 2017 13:40:06 -0800 (PST) To: nmalykh@gmail.com, T.Clausen@computer.org, chris.dearlove@baesystems.com, philippe.jacquet@alcatel-lucent.com, ulrich@herberg.name X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Message-Id: <20170223214006.06BA2B81FCA@rfc-editor.org> Date: Thu, 23 Feb 2017 13:40:06 -0800 (PST) Archived-At: X-Mailman-Approved-At: Thu, 23 Feb 2017 14:23:08 -0800 Cc: text/plain@rfc-editor.org, manet@ietf.org, charset=UTF-8@rfc-editor.org, rfc-editor@rfc-editor.orgContent-Type, iesg@ietf.org Subject: [manet] [Errata Verified] RFC7181 (4874) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2017 21:40:07 -0000 The following errata report has been verified for RFC7181, "The Optimized Link State Routing Protocol Version 2". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=7181&eid=4874 -------------------------------------- Status: Verified Type: Technical Reported by: Nikolai Malykh Date Reported: 2016-12-01 Verified by: Alvaro Retana (IESG) Section: 17.1 Original Text ------------- If the router changes its originator address, then: 1. If there is no Originator Tuple with: * O_orig_addr = old originator address then create an Originator Tuple with: * O_orig_addr := old originator address The Originator Tuple (existing or new) with: * O_orig_addr = new originator address is then modified as follows: * O_time := current time + O_HOLD_TIME Corrected Text -------------- If the router changes its originator address, then: 1. If there is an Originator Tuple with: * O_orig_addr = old originator address then modify it as follows: * O_orig_addr := new originator address * O_time := current time + O_HOLD_TIME otherwise create an Originator Tuple with: * O_orig_addr := new originator address * O_time := current time + O_HOLD_TIME Notes ----- At the time of the modification Originator Tuple with O_orig_addr = new originator address does not yet exist. === The Corrected text reflects consultation with the WG. -------------------------------------- RFC7181 (draft-ietf-manet-olsrv2-19) -------------------------------------- Title : The Optimized Link State Routing Protocol Version 2 Publication Date : April 2014 Author(s) : T. Clausen, C. Dearlove, P. Jacquet, U. Herberg Category : PROPOSED STANDARD Source : Mobile Ad-hoc Networks Area : Routing Stream : IETF Verifying Party : IESG From nobody Thu Feb 23 16:01:26 2017 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 27013129C76 for ; Thu, 23 Feb 2017 16:01:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BkNXbojMaM-8 for ; Thu, 23 Feb 2017 16:01:23 -0800 (PST) Received: from mail-it0-x22b.google.com (mail-it0-x22b.google.com [IPv6:2607:f8b0:4001:c0b::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14BA3129C81 for ; Thu, 23 Feb 2017 16:01:23 -0800 (PST) Received: by mail-it0-x22b.google.com with SMTP id 203so4747983ith.0 for ; Thu, 23 Feb 2017 16:01:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=Bkej6+vBIPM73oaD8Q2YHFN46WJPZ1to+FqKgXYOUE4=; b=CMllwMXmDWRhTR1aXgrK83+NsGLRrLl/+6dHDhZUd//+nBmym7dpkphn+R6GG12lug swGNx/O8BbzXWc0j8B1cVDEtfA6blR9JesRO/K2t5q8I/lS0G2GqeaQmhT2uFowXxr3s S6HrMhCApByWUnQob7pCWSHj14ivbicnfJTmeydycMstvbTH1MMBovtc3oTubNOZoeZc 1oowDQvHk7GKaZoCe8BmcxVjGzY5kxZZV7TtHQI/+WYPuUlQnsBec2LHEaDR8JJJ+MoB lvAKsLPhkimgLXKjVloaRqoklzbjIK91/p6+A5WEuHmbs+w07qTnuc4qd7G/wHJmNBZ1 GSaQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=Bkej6+vBIPM73oaD8Q2YHFN46WJPZ1to+FqKgXYOUE4=; b=a1u2hdkEcE2XIfsqHz6GuSW53QTY0RCKw5NyN58YAxQofIlK1BFzbTuUuIX3AdDNQC JR04zjI97J5HREY02FY4OufYYCTtJi1Qlj2Vg3fEXxtt4ok2YtOxt2D/pV74SL/5XjG5 x/dw5qTL2q+Rp5EKvPB1lLgc5AO9Z21Mc9qA/wG6T1QcHh9usR/Wb4ZK1RIWnO1zsAZO ITbBDJz4QtqQA/H4PFsa1MbpNOFlxqK0Qr4fm2BUvSxkRSydm4I7uSa1e4FhVGh1LI+C 9OF/IXw05NvXG6FcpFUyuC98z0jI6x8zxbH2cv8nOtV8uTxGfRgq6nRos0ftho4vPgLR KF8g== X-Gm-Message-State: AMke39krlE5j47qgrbzpBpiUZjX32FyF+ZmUf780XLg1Jwpe/pQ2x7WG7a+Yfng+55IxOENXps1Ht6E/+cZFag== X-Received: by 10.36.57.10 with SMTP id l10mr226638ita.88.1487894482068; Thu, 23 Feb 2017 16:01:22 -0800 (PST) MIME-Version: 1.0 Received: by 10.79.158.87 with HTTP; Thu, 23 Feb 2017 16:01:21 -0800 (PST) From: Stan Ratliff Date: Thu, 23 Feb 2017 19:01:21 -0500 Message-ID: To: MANET IETF Content-Type: multipart/alternative; boundary=001a114aa1a0112da005493b6e68 Archived-At: Subject: [manet] Chicago IETF X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2017 00:01:24 -0000 --001a114aa1a0112da005493b6e68 Content-Type: text/plain; charset=UTF-8 Hello Working Group - We've requested a 1.5 hour slot for MANET at IETF 98. Please let the chairs know of any requests for presentation slots at that meeting. Regards, Stan --001a114aa1a0112da005493b6e68 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello Working Group -=C2=A0

We've r= equested a 1.5 hour slot for MANET at IETF 98. Please let the chairs know o= f any requests for presentation slots at that meeting.=C2=A0

=
Regards,
Stan
--001a114aa1a0112da005493b6e68--