From nobody Wed Apr 3 15:07:04 2019 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 44D3C120161 for ; Wed, 3 Apr 2019 15:07:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-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 cyx0Pv2yp3kO for ; Wed, 3 Apr 2019 15:07:01 -0700 (PDT) Received: from gproxy4-pub.mail.unifiedlayer.com (gproxy4-pub.mail.unifiedlayer.com [69.89.23.142]) (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 08261120168 for ; Wed, 3 Apr 2019 15:07:00 -0700 (PDT) Received: from cmgw14.unifiedlayer.com (unknown [10.9.0.14]) by gproxy4.mail.unifiedlayer.com (Postfix) with ESMTP id 26383175B27 for ; Wed, 3 Apr 2019 16:06:59 -0600 (MDT) Received: from box313.bluehost.com ([69.89.31.113]) by cmsmtp with ESMTP id Bo26hASgJXFO5Bo26hovtG; Wed, 03 Apr 2019 16:06:59 -0600 X-Authority-Reason: nr=8 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:References:Cc: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=EVFLSlff3169fHxVIx7BmZdbAN+X+HYRKuKOIht76G0=; b=w4hXRXVkZeAnSc7HaPU8kFhPcM TY5NDh+EUzt2RqHnMG9zEWByk/Hee7zoc9IjIKat8hdy2b2p2a2N5q2xFgz2S6txEFAZv1n50MJul GFV+Kk9rMGqx25U6sknVoP2Qp; Received: from pool-72-66-11-201.washdc.fios.verizon.net ([72.66.11.201]:47382 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from ) id 1hBo26-000ow6-On; Wed, 03 Apr 2019 16:06:58 -0600 To: Stephen Kent , secdir@ietf.org Cc: draft-ietf-manet-dlep-pause-extension.all@ietf.org, manet@ietf.org, ietf@ietf.org References: <155309526492.14741.18141095676597911076@ietfa.amsl.com> From: Lou Berger Message-ID: <6dddf23c-806a-d8ab-7f65-ac7b0855deac@labn.net> Date: Wed, 3 Apr 2019 18:06:57 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.1 MIME-Version: 1.0 In-Reply-To: <155309526492.14741.18141095676597911076@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US 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: 72.66.11.201 X-Source-L: No X-Exim-ID: 1hBo26-000ow6-On X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-72-66-11-201.washdc.fios.verizon.net ([IPv6:::1]) [72.66.11.201]:47382 X-Source-Auth: lberger@labn.net X-Email-Count: 4 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== X-Local-Domain: yes Archived-At: Subject: Re: [manet] Secdir last call review of draft-ietf-manet-dlep-pause-extension-05 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Apr 2019 22:07:03 -0000 Hi Steve, Thanks for the comments! On 3/20/2019 11:21 AM, Stephen Kent via Datatracker wrote: > Reviewer: Stephen Kent > Review result: Has Nits > > I have reviewed this document as part of the security directorate's ongoing > effort to review all IETF documents being processed by the IESG. These > comments were written with the intent of improving security requirements and > considerations in IETF drafts. Comments not addressed in last call may be > included in AD reviews during the IESG review. Document editors and WG chairs > should treat these comments just like any other last call comments. > > Review Summary: Ready with nits > > This brief document defines and extension to DLEP That enables a modem to use > DLEP to pause and resume inbound traffic from a specific peer. DLEP (RFC 8175) > cites GTSM as a security mechanism, which is rather weak, but it says that > implementations SHOULD use TLS (1.2), which is fine. > > The text states that “An example of when a modem might send this data item is > when an internal queue length exceeds a particular threshold.” However, all of > details of this data item seem to focus exclusively on queues. Thus it seems > likely that this is not just an example, but, rather, the primary motivation > for introducing the pause extension. A slight rewording of the text here seems > appropriate, or the authors could describe other (not-queue-based) examples. fair point, how about: OLD:   An example of when a modem might send   this data item is when an internal queue length exceeds a particular   threshold. NEW: The motivating use case is for this data item is when a modem's internal queue length exceeds a particular threshold.  Other use cases are possible, e.g., when there a non queue related congestion points within a modem, but such are not explicitly described in this document. > The Security Considerations section of 8175 addresses a reasonable range of > concerns. Thus it is appropriate that this document’s Security Considerations > section is very brief, as it cites the corresponding section in 8175. I suggest > a couple of minor change to the wording here: > > “The extension does not inherently introduce any additional threats … > -> > “The extension does not inherently introduce any additional vulnerabilities …” > > “ … but this is not a substantively different threat by …” > -> > “ … but this is not a substantively different attack by …” > > There are numerous examples of awkward/poor phrasing throughout the document, > which I hope the RFC Editor will correct, e.g., > > Abstract: > “…to the DLEP protocol …” -> “… to DLEP …” Hopefully these have already been corrected, if not I'm sure the editor will help us out. > page 7: > > “A modem can indicate that traffic is to be suppressed on a device wide or > destination specific basis.” > > “A modem can indicate that traffic is to be suppressed on a device- wide or > destination-specific basis.” Thanks. > “This includes that to indicate that transmission can resume to all > destinations …” > > “Thus, to indicate that transmission can resume to all destinations, …” I'm not sure thus is quite right, but will revise! Thanks again!, Lou > > From nobody Wed Apr 3 19:18:50 2019 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 9DDF31203A8 for ; Wed, 3 Apr 2019 19:08:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, 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 xlikvyJgp-P6 for ; Wed, 3 Apr 2019 19:08:37 -0700 (PDT) Received: from alt-proxy16.mail.unifiedlayer.com (alt-proxy16.mail.unifiedlayer.com [70.40.197.35]) (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 5319212039E for ; Wed, 3 Apr 2019 19:08:37 -0700 (PDT) Received: from cmgw11.unifiedlayer.com (unknown [10.9.0.11]) by gproxy9.mail.unifiedlayer.com (Postfix) with ESMTP id 426381E0729 for ; Wed, 3 Apr 2019 20:08:33 -0600 (MDT) Received: from box313.bluehost.com ([69.89.31.113]) by cmsmtp with ESMTP id BrnthnlZ2VLCbBrnthI9LV; Wed, 03 Apr 2019 20:08:33 -0600 X-Authority-Reason: nr=8 X-Authority-Analysis: $(_cmae_reason DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Subject: References:In-Reply-To:Message-ID:Date:CC:To:From: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=Pcl4g3EJTxVqFL7KV8XqfkhhTkTzMC7/ECiVwf/9Rh0=; b=qKL7oF2a7+xs14j5JHzTO4+wyx 1vXsqcooqTiMVeQq4GUt3OfAJskVTs6oBjb2XeNJ8cJdrdZXgnU1SV+Lx+5m0j2rgJ7F06f9HdyCw NgiIR8VxUA0RhmeEKW131k87r; Received: from [172.56.35.109] (port=63648 helo=[IPV6:2607:fb90:78d:1a53:0:25:1809:9b01]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from ) id 1hBrns-001vqs-La; Wed, 03 Apr 2019 20:08:32 -0600 From: Lou Berger To: Andy Smith , , Andy Smith via Datatracker CC: , , Date: Wed, 03 Apr 2019 22:08:30 -0400 Message-ID: <169e617f2b8.27ce.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> In-Reply-To: <155387449035.24968.5762515400738539072@ietfa.amsl.com> References: <155387449035.24968.5762515400738539072@ietfa.amsl.com> User-Agent: AquaMail/1.18.2-1413 (build: 101800200) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="us-ascii" Content-Transfer-Encoding: 8bit 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: 172.56.35.109 X-Source-L: No X-Exim-ID: 1hBrns-001vqs-La X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([IPV6:2607:fb90:78d:1a53:0:25:1809:9b01]) [172.56.35.109]:63648 X-Source-Auth: lberger@labn.net X-Email-Count: 2 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== X-Local-Domain: yes Archived-At: X-Mailman-Approved-At: Wed, 03 Apr 2019 19:18:48 -0700 Subject: Re: [manet] [RTG-DIR] Rtgdir last call review of draft-ietf-manet-dlep-pause-extension-05 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2019 02:08:40 -0000 Thanks for the review and will do. Lou ---------- On March 29, 2019 11:48:43 AM Andy Smith via Datatracker wrote: > Reviewer: Andy Smith > Review result: Ready > > Hello, > > I have been selected as the Routing Directorate reviewer for this draft. The > Routing Directorate seeks to review all routing or routing-related drafts as > they pass through IETF last call and IESG review. The purpose of the review is > to provide assistance to the Routing ADs. For more information about the > Routing Directorate, please see > ?http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir > > Although these comments are primarily for the use of the Routing ADs, it would > be helpful if you could consider them along with any other IETF Last Call > comments that you receive, and strive to resolve them through discussion or by > updating the draft. > > Document: draft-ietf-manet-dlep-pause-extension > Reviewer: Andy Smith > Review Date: 29 March 2019 > > Summary: > This document is well written and easy to understand. I see no reason it > cannot be published. > > Comments: > This document is well written and easy to understand. I see no reason it > cannot be published. > > Major Issues: > None > > Minor Issues: > None > > Nits: > It might be helpful to expand the acronym "TBA" in the requested Data Item Type > field. > > From nobody Wed Apr 3 19:18:57 2019 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 A62DE120392 for ; Wed, 3 Apr 2019 19:08:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 KOAF8bHgobrq for ; Wed, 3 Apr 2019 19:08:42 -0700 (PDT) Received: from gproxy8-pub.mail.unifiedlayer.com (gproxy8-pub.mail.unifiedlayer.com [67.222.33.93]) (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 662F31203A3 for ; Wed, 3 Apr 2019 19:08:38 -0700 (PDT) Received: from cmgw12.unifiedlayer.com (unknown [10.9.0.12]) by gproxy8.mail.unifiedlayer.com (Postfix) with ESMTP id 7835A1AB1DD for ; Wed, 3 Apr 2019 20:08:34 -0600 (MDT) Received: from box313.bluehost.com ([69.89.31.113]) by cmsmtp with ESMTP id BrnuhSMi8mds9Brnuh9sEE; Wed, 03 Apr 2019 20:08:34 -0600 X-Authority-Reason: nr=8 X-Authority-Analysis: $(_cmae_reason DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Subject: References:In-Reply-To:Message-ID:Date:CC:To:From: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=FmWu60jAeuQqQKKmuKEH8bGzQfAfZApS3fivv74vGz4=; b=WFiY9vBIDBvWHsVSLKCsThcf6f Oo2nBjF4lhMMJP+gQKaekYir87r8Ed6jz0bqboclD6VVnFRkso4D5rvbvjcL2p8AOIvIrUQtTnnDT N8ix5UeViHf+CtyP8TOhYIJ/1; Received: from [172.56.35.109] (port=63648 helo=[IPV6:2607:fb90:78d:1a53:0:25:1809:9b01]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from ) id 1hBrnu-001vqs-1A; Wed, 03 Apr 2019 20:08:34 -0600 From: Lou Berger To: , CC: , , Date: Wed, 03 Apr 2019 22:08:32 -0400 Message-ID: <169e61867e8.27ce.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> In-Reply-To: <011a01d4e7b9$ed743910$c85cab30$@riw.us> References: <011a01d4e7b9$ed743910$c85cab30$@riw.us> User-Agent: AquaMail/1.18.2-1413 (build: 101800200) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8" Content-Transfer-Encoding: 8bit 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: 172.56.35.109 X-Source-L: No X-Exim-ID: 1hBrnu-001vqs-1A X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([IPV6:2607:fb90:78d:1a53:0:25:1809:9b01]) [172.56.35.109]:63648 X-Source-Auth: lberger@labn.net X-Email-Count: 7 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== X-Local-Domain: yes Archived-At: X-Mailman-Approved-At: Wed, 03 Apr 2019 19:18:48 -0700 Subject: Re: [manet] RtgDir review: draft-ietf-manet-dlep-multi-hop-extension-06.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2019 02:08:45 -0000 Thanks Russ! ---------- On March 31, 2019 8:05:20 AM wrote: > Hello, > > I have been selected as the Routing Directorate reviewer for this draft. > The Routing Directorate seeks to review all routing or routing-related > drafts as they pass through IETF last call and IESG review, and sometimes > on special request. The purpose of the review is to provide assistance to > the Routing ADs. For more information about the Routing Directorate, please > see ​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir > > Although these comments are primarily for the use of the Routing ADs, it > would be helpful if you could consider them along with any other IETF Last > Call comments that you receive, and strive to resolve them through > discussion or by updating the draft. > > Document: draft-ietf-manet-dlep-multi-hop-extension-06.txt > Reviewer: Russ White > Review Date: 30 March 2019 > IETF LC End Date: 5 April 2019 > Intended Status: Standards Track > > Summary: > > No issues found. This document is ready for publication. > > Quality and Readibility: > > This draft is well written, easy to read, and easy to understand. > > Major Issues: > > None found. > > Minor Issues: > > None found. > > == > 😊 /r > > From nobody Wed Apr 3 19:38:32 2019 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 BA11B120195 for ; Wed, 3 Apr 2019 19:38:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.1 X-Spam-Level: *** X-Spam-Status: No, score=3.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, GB_SUMOF=5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 qIbmMi4ptGud for ; Wed, 3 Apr 2019 19:38:28 -0700 (PDT) Received: from gproxy8-pub.mail.unifiedlayer.com (gproxy8-pub.mail.unifiedlayer.com [67.222.33.93]) (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 4FC031200F1 for ; Wed, 3 Apr 2019 19:38:28 -0700 (PDT) Received: from cmgw11.unifiedlayer.com (unknown [10.9.0.11]) by gproxy8.mail.unifiedlayer.com (Postfix) with ESMTP id B29961AB08A for ; Wed, 3 Apr 2019 20:38:27 -0600 (MDT) Received: from box313.bluehost.com ([69.89.31.113]) by cmsmtp with ESMTP id BsGphoH4ZVLCbBsGphIeYY; Wed, 03 Apr 2019 20:38:27 -0600 X-Authority-Reason: nr=8 X-Authority-Analysis: $(_cmae_reason 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:References:Cc: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=RDLl6+3MspQuRpchTwbKib8ucRoY5kzVfGYk+val6h0=; b=ZqqcDpmTQDhhtPlaIOGM30h1C9 hAShQtsQcmPRqETz8yxNAQ8xX4ABMnU3+SsVYQp3ShuUvdVAAvsQu0yT6uKbnQqPp9ZjBBbemAey6 eJPua1Osier9B6D1Wp1xsrICu; Received: from pool-72-66-11-201.washdc.fios.verizon.net ([72.66.11.201]:53128 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from ) id 1hBsGp-0024zA-AZ; Wed, 03 Apr 2019 20:38:27 -0600 To: Dale Worley , gen-art@ietf.org Cc: draft-ietf-manet-dlep-pause-extension.all@ietf.org, manet@ietf.org, ietf@ietf.org References: <155313563193.14884.16784480436034023941@ietfa.amsl.com> From: Lou Berger Message-ID: Date: Wed, 3 Apr 2019 22:38:25 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.1 MIME-Version: 1.0 In-Reply-To: <155313563193.14884.16784480436034023941@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US 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: 72.66.11.201 X-Source-L: No X-Exim-ID: 1hBsGp-0024zA-AZ X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-72-66-11-201.washdc.fios.verizon.net ([IPv6:::1]) [72.66.11.201]:53128 X-Source-Auth: lberger@labn.net X-Email-Count: 19 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== X-Local-Domain: yes Archived-At: Subject: Re: [manet] Genart last call review of draft-ietf-manet-dlep-pause-extension-05 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2019 02:38:31 -0000 Hi, Thanks you for the comments, please see below. On 3/20/2019 10:33 PM, Dale Worley via Datatracker wrote: > Reviewer: Dale Worley > Review result: Ready with Nits > > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. > > For more information, please see the FAQ at > > . > > Document: draft-ietf-manet-dlep-pause-extension-05 > Reviewer: Dale R. Worley > Review Date: 2019-03-20 > IETF LC End Date: 2019-04-03 > IESG Telechat date: [not scheduled] > > Summary: > > This draft is basically ready for publication, but has nits > that should be fixed before publication. There are a number of > issues with technical content, but they appear to stem from > editorial issues, rather than being unsettled technical > decisions. > > * Technical issues: > > I notice that the Pause Extension cannot be used by a router to tell a > modem to not send. I assume that the WG has considered this and has a > good reason for this asymmetry. This is correct.  It was deemed unneeded complexity for the typical use case where modems have very narrow bandwidth available for transmissions in comparison to other router attached links. > > 3.1.1. Queue Parameter Sub Data Item > > There need not be a Sub Data Item for a particular queue index. Such > a queue has no declared size. OTOH, it has no DSCPs, and so no > traffic can be sent for it, either. > > Queue Parameter Sub Data Items are an unordered list composed of sub > data items with a common format. The first sub data item is assigned > a Queue Index value of 1, and subsequent data items are numbered > incrementally. The format of the Queue Parameter Sub Data Item is > > ... > > Queue Index: > > An 8-bit field indicating the queue index of the queue parameter > represented in the sub data item. > > These passages are contradictory. Either the Sub Data Items are an > ordered list and indexes are assigned to them sequentially, they are > unordered and the indexes are given in the Queue Index subfield, or > the Sub Data Items are required to be in order by their Queue Index > fields. Good catch - and you are correct.  This is text wasn't modified when we made ordering explicit. The following will be removed: The first sub data item is assigned a Queue Index value of 1, and subsequent data items are numbered incrementally. > DS Field Qn: > > The data item contains a sequence of 8 bit DS Fields. The > position in the sequence identifies the associated queue index. > The number of DS Fields present MUST equal the sum of all Num > DSCPs field values. > > This doesn't seem to match the defined format of the Sub Data Items. > The "DS Field Qn" fields contain exactly as many DS Fields as the > value of the Num DSCPs Qn field by definition. And all of them are > associated with the one Queue Index in the Sub Data Item containing > the DS Field Qn. Same issue.   Drop: The position in the sequence identifies the associated queue index. > I note that the Sub Data Items are not padded to a multiple of 4 > octets. I assume this is intended. Correct, this is consistent with rfc8175. > > 3.3. Restart > > The sending of this data item parallels the Pause Data Item, see the > previous section, and follows the same rules. This includes that to > indicate that transmission can resume to all destinations, a modem > MUST send the Restart Data Item in a Session Update Message. It also > includes that to indicate that transmission can resume to a > particular destination a modem MUST send the Pause Restart Item in a > Destination Update Message. > > Read literally, this means that there is a pause/transmit bit for each > destination/DSCP combination, and that the various messages (pause > vs. restart * Session Update vs. Destination Update * queue index > vs. 255) set some subset of the bits to "pause" or "transmit". This > is opposed to the model where (to simplify) there is an overall > pause/transmit bit for all traffic and an independent pause/transmit > bit for each destination, and traffic may be sent for a destination > only if both the overall bit and the destination bit are "transmit". > > * Editorial issues: > > 1. Introduction > > The > extension also optionally supports DSCP (differentiated services > codepoint) aware, see [RFC2475], flow control. > > The phrasing of this sentence is awkward because of the number of > interpolated phrases. I suggest something like: > > The extension also optionally supports flow control that is DSCP > (differentiated services codepoint) aware (see [RFC2475]). I'll break it into two sentences. > Also, it seems that recent RFCs have tended to capitalize the phrase > "Differentiated Services Code Point". (Probably check this point with > the Editor.) I'll defer to the RFC editor. > Note > that this mechanism only controls traffic that is to be transmitted > on the modem's attached data channel and not to DLEP control messages > themselves. > > The parallelism is not correct here, as it would read "this mechanism > ... controls ... to DLEP". Perhaps change to: "this mechanism only > applies to traffic ...". Thanks! > 2. Extension Usage and Identification > > To indicate that the Control Plane Based Pause > Extension is to be used, an implementation MUST include the Control > Plane Based Pause Extension Type Value in the Extensions Supported > Data Item. > > If I am reading RFC 8175 correctly, this is not exactly true. Sending > the Value does not compel the peer device to use the Extension. > Instead, "To indicate that the implementation accepts use of the > C.P.B.P.E., an implementation includes ...". thanks, but will s/accepts/supports. > 3. Extension Data Items > > The Queue Parameters > Data Item is used by a modem to provide information on the DSCPs it > uses in forwarding. > > Suggest s/information on/information about/. To me, "information on > the DSCPs" suggests that it will provide a listing of all the DSCPs > that it uses, whereas "information about the DSCPs" suggests that it > will provide attributes of some, but perhaps not all, of the DSCPs. > (Section 3.1 makes clear that the Queue Parameters does not need to > list all DSCPs that are used.) Done! > > 3.1. Queue Parameters > > The Queue Parameters Data Item identifies DSCPs based on groups of > logical queues, each of which is referred to via a "Queue Index". > > "groups of logical queues" isn't correct. Suggest "The Queue > Parameters Data Item groups DSCPs into logical queues, each of which > is identified by a "Queue Index"." I like it - thanks! > > An implementation that does not support DSCPs would indicate 1 queue > with 0 DSCPs, and the number of bytes that may be in its associated > link transmit queue. > > "with 0 DSCPs" is not really correct, since the Queue Parameter > doesn't specify how many DSCPs are included in queue index 0, and > traffic with all values of the DSCP field (which is unexamined by the > device) will be in queue index 0. I think this phrase should be > omitted. I think it's cleaner to remove Q0 at this point, it too is a bit vestigial and I think this highlights that having essentially two ways to cover the > Value Scale > ------------ > 0 B - Bytes (Octets) > 1 KB - Kilobytes (B/1024) > 2 MB - Megabytes (KB/1024) > 3 GB - Gigabytes (MB/1024) > > I would expect these items to be "1024 B", "1024 KB", etc. But > perhaps that's because it is ambiguous whether "scale" means the units > in which the measurement is expressed, or the factor by which the > measurement is multiplied by before it is reported. I would replace > "scale" with "unit", which does not have that ambiguity. I would also > use the IEC abbreviations: > > Value Unit > ----------- > 0 B - Bytes (Octets) > 1 KiB - Kilobytes (1024 B) > 2 MiB - Megabytes (1024 KiB) > 3 GiB - Gigabytes (1024 GiB) Sure. > [ISQ-13] International Electrotechnical Commission, "International > Standard -- Quantities and units -- Part 13: Information > science and technology", IEC 80000-13, March 2008. > > 3.2. Pause > > The special value of 255 is used to > indicate that all traffic is to be suppressed. > > This implies that a queue index of 255 cannot be used, which is also > implied by the fact that Num Queues = 255 means that only indexes 0 to > 254 are in use. It would be helpful to update 3.1 to make this more > explicit: > > Queue Indexes are numbered sequentially from zero to a maximum of > 254, where queue index zero is a special case covering DSCPs which > are not otherwise associated with Queue Index. (Value 255 is used > to indicate "all queues".) I'll add text that 255 MUST NOT be used in the Queue Index field. > > -- > > Queue Index: > > ... The special value of 255 indicates > all traffic is to be suppressed to the modem, when the data item > is carried in a Session Update Message, or a destination, when the > data item is carried in Destination Update Message. > > The parallelism is awkward here. I think you want to explicitly > parallel "traffic to the modem" and "traffic to a destination": okay, will make them parallel. > The special value of 255 indicates all traffic to the modem is > to be suppressed, when the data item is carried in a Session > Update Message, or all traffic to a destination, when the data > item is carried in Destination Update Message. > > 3.3. Restart > > Finally, the same rules apply to queue indexes. > > Probably better as "Queue indexes are interpreted in the same way as > in the Pause Data Item." Done. Look for an update to be published shortly. Thank you for the comments! Lou > [END] > > > From nobody Wed Apr 3 19:46:51 2019 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 8363712012E; Wed, 3 Apr 2019 19:46:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: manet@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.94.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: manet@ietf.org Message-ID: <155434600946.22756.15288619560553968630@ietfa.amsl.com> Date: Wed, 03 Apr 2019 19:46:49 -0700 Archived-At: Subject: [manet] I-D Action: draft-ietf-manet-dlep-pause-extension-06.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.29 List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2019 02:46:50 -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 WG 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-06.txt Pages : 12 Date : 2019-04-03 Abstract: This document defines an extension to the Dynamic Link Exchange Protocol (DLEP) that enables a modem to use DLEP messages to pause and resume data traffic coming from its peer router. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-manet-dlep-pause-extension/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-manet-dlep-pause-extension-06 https://datatracker.ietf.org/doc/html/draft-ietf-manet-dlep-pause-extension-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-manet-dlep-pause-extension-06 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 Apr 4 04:42:40 2019 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 D21AB1200B4; Thu, 4 Apr 2019 04:42:38 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Magnus Westerlund via Datatracker To: "The IESG" Cc: draft-ietf-manet-dlep-pause-extension@ietf.org, Stan Ratliff , aretana.ietf@gmail.com, manet-chairs@ietf.org, sratliff@idirect.net, manet@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.94.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Magnus Westerlund Message-ID: <155437815884.30894.8011482899811561433.idtracker@ietfa.amsl.com> Date: Thu, 04 Apr 2019 04:42:38 -0700 Archived-At: Subject: [manet] Magnus Westerlund's Discuss on draft-ietf-manet-dlep-pause-extension-06: (with DISCUSS) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.29 List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2019 11:42:39 -0000 Magnus Westerlund has entered the following ballot position for draft-ietf-manet-dlep-pause-extension-06: 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-pause-extension/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- It is unclear to me what the purpose of the pause and resume is here? Is it to enable the router to build the queue rather than the modem if there is a queue buildup in the modem? If that is the case, then pause and resume will be done frequently and on short time scales due to variability of the link. And then the router resumes transmission to the modem when the buffer has been reduced? As this is enabled to be done on a queue level what how does one ensure the per hop behavior that is intended based on the DSCP with this split. Because you will get an interaction between the two queue that are in series for the same link which makes ensuring the PHB difficult. I hope for a timely clarification to determine if this is a discuss or not and make it more actionable. From nobody Thu Apr 4 08:29:35 2019 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 BA35912024F; Thu, 4 Apr 2019 08:29:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?Mirja_K=C3=BChlewind_via_Datatracker?= To: "The IESG" Cc: draft-ietf-manet-dlep-pause-extension@ietf.org, Stan Ratliff , aretana.ietf@gmail.com, manet-chairs@ietf.org, sratliff@idirect.net, manet@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.94.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: =?utf-8?q?Mirja_K=C3=BChlewind?= Message-ID: <155439177475.30903.11264956620443512699.idtracker@ietfa.amsl.com> Date: Thu, 04 Apr 2019 08:29:34 -0700 Archived-At: Subject: [manet] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf?= =?utf-8?q?-manet-dlep-pause-extension-06=3A_=28with_DISCUSS=29?= X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.29 List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2019 15:29:35 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-manet-dlep-pause-extension-06: 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-pause-extension/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I have similar questions as Magnus does about the specific use case for this mechanism. Moreover I wonder about the assumed usage of the different DSCPs. If the router would want to assign code points to the traffic, then it would need to know what the requirements of the traffic is which is usually unknown to a router. If there is an assumption that the traffic is marked with the right DSCP by the origin than the router does not need to know about the available DS queue configuration. Can you please clarify! From nobody Thu Apr 4 08:57:01 2019 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 0FC8B120121 for ; Thu, 4 Apr 2019 08:56:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, 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 WJUeTq2J8Kia for ; Thu, 4 Apr 2019 08:56:54 -0700 (PDT) Received: from alt-proxy16.mail.unifiedlayer.com (alt-proxy16.mail.unifiedlayer.com [70.40.197.35]) (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 97E7112007A for ; Thu, 4 Apr 2019 08:56:54 -0700 (PDT) Received: from cmgw10.unifiedlayer.com (unknown [10.9.0.10]) by gproxy9.mail.unifiedlayer.com (Postfix) with ESMTP id EB4841E0BDE for ; Thu, 4 Apr 2019 09:56:53 -0600 (MDT) Received: from box313.bluehost.com ([69.89.31.113]) by cmsmtp with ESMTP id C4jThCXYLuj2oC4jTh9NxB; Thu, 04 Apr 2019 09:56:51 -0600 X-Authority-Reason: nr=8 X-Authority-Analysis: v=2.3 cv=ePE9ckh1 c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=jpOVt7BSZ2e4Z31A5e1TngXxSK0=:19 a=IkcTkHD0fZMA:10:nop_charset_1 a=xqWC_Br6kY4A:10:nop_ipv6 a=oexKYjalfGEA:10:nop_rcvd_month_year a=48vgC7mUAAAA:8 a=jB8uovYwWA93GjEbXJAA:9 a=QEXdDO2ut3YA:10:nop_charset_2 a=mYAOWqAtFUkA:10:demote_hacked_domain_1 a=1dbGxDndw2gA:10:demote_hacked_domain_7 a=w1C3t2QeGrPiZgrLijVG: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:References:Cc: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=jPxvVccER2PhNHzeE4/BagknIWTjDKFNWd041E1DEUc=; b=XY+fk/0ahl61m0KHOpub2zDyVZ rTZ0wS8E9feHKktvivh26sOukx/Fh0Ap6QNdrwxJSti1jZyHY5d7wTGWidBhu1c5V4TL6Hcz43ufu FAls91rmP3hsXO69zi9olA06n; Received: from pool-72-66-11-201.washdc.fios.verizon.net ([72.66.11.201]:46952 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from ) id 1hC4jT-001y3p-2c; Thu, 04 Apr 2019 09:56:51 -0600 To: Magnus Westerlund , The IESG Cc: draft-ietf-manet-dlep-pause-extension@ietf.org, manet@ietf.org, manet-chairs@ietf.org References: <155437815884.30894.8011482899811561433.idtracker@ietfa.amsl.com> From: Lou Berger Message-ID: Date: Thu, 4 Apr 2019 11:56:50 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.1 MIME-Version: 1.0 In-Reply-To: <155437815884.30894.8011482899811561433.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US 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: 72.66.11.201 X-Source-L: No X-Exim-ID: 1hC4jT-001y3p-2c X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-72-66-11-201.washdc.fios.verizon.net ([IPv6:::1]) [72.66.11.201]:46952 X-Source-Auth: lberger@labn.net X-Email-Count: 12 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== X-Local-Domain: yes Archived-At: Subject: Re: [manet] Magnus Westerlund's Discuss on draft-ietf-manet-dlep-pause-extension-06: (with DISCUSS) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2019 15:56:59 -0000 Hi, On 4/4/2019 7:42 AM, Magnus Westerlund via Datatracker wrote: > Magnus Westerlund has entered the following ballot position for > draft-ietf-manet-dlep-pause-extension-06: 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-pause-extension/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > It is unclear to me what the purpose of the pause and resume is here? > > Is it to enable the router to build the queue rather than the modem if there is > a queue buildup in the modem? Yes and also allow a router to implement more sophisticated queuing if it so chooses, e.g., mapping multiple DHCPs into a single modem queue. > If that is the case, then pause and resume will > be done frequently and on short time scales due to variability of the link. And > then the router resumes transmission to the modem when the buffer has been > reduced? Also correct.  Fundamentally this is the same as what was defined previously for PPPoE in RFC5578, but using a simpler on/off mechanism and DLEP.  DLEP is the replacement for using PPPoE for radio to router information. > As this is enabled to be done on a queue level what how does one > ensure the per hop behavior that is intended based on the DSCP with this split. > Because you will get an interaction between the two queue that are in series > for the same link which makes ensuring the PHB difficult. I agree that there are two queues in series, but don't see this as materially different than what RFC5578 allowed or 2 routers interconnected over a link that supports normal Ethernet pause or PFC.  In other words, I see that a modem that is DSCP aware must conform with the same requirements as a router that is DSCP aware. At least this is my option.  Others may see it differently, e.g., Stan (who co-authored RFC5578 and is the doc Shepherd) or the others in the WG who have been working radio/router interfaces for far longer than I have... Lou > I hope for a timely clarification to determine if this is a discuss or not and > make it more actionable. > > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > From nobody Thu Apr 4 09:27:06 2019 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 E82CA12060E for ; Thu, 4 Apr 2019 09:27:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 dNEKUIo8lnsG for ; Thu, 4 Apr 2019 09:27:02 -0700 (PDT) Received: from us-smtp-delivery-214.mimecast.com (us-smtp-delivery-214.mimecast.com [63.128.21.214]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 884F81205E8 for ; Thu, 4 Apr 2019 09:27:01 -0700 (PDT) Received: from webmail.idirect.net (198.180.159.2 [198.180.159.2]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-217-AAZuH6ZNOQyBZQPgqNrp1A-1; Thu, 04 Apr 2019 12:25:18 -0400 Received: from vausditchmc3.idirect.net (10.250.251.203) by vausditchmc2.idirect.net (10.250.251.202) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Thu, 4 Apr 2019 12:25:17 -0400 Received: from vausditchmc3.idirect.net ([fe80::a089:5025:3057:5d51]) by vausditchmc3.idirect.net ([fe80::a089:5025:3057:5d51%13]) with mapi id 15.01.1466.012; Thu, 4 Apr 2019 12:25:17 -0400 From: "Ratliff, Stanley" To: Lou Berger , Magnus Westerlund , The IESG CC: "draft-ietf-manet-dlep-pause-extension@ietf.org" , "manet@ietf.org" , "manet-chairs@ietf.org" Thread-Topic: [manet] Magnus Westerlund's Discuss on draft-ietf-manet-dlep-pause-extension-06: (with DISCUSS) Thread-Index: AQHU6tuDcoy41n6e4kuNlesEyZ+fpKYsa14A//+/5KA= Date: Thu, 4 Apr 2019 16:25:17 +0000 Message-ID: <8c18420b622f405eb0d4adcf844b315d@idirect.net> References: <155437815884.30894.8011482899811561433.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.250.251.20] MIME-Version: 1.0 X-MC-Unique: AAZuH6ZNOQyBZQPgqNrp1A-1 X-Mimecast-Spam-Score: 0 Content-Type: multipart/alternative; boundary="MCBoundary=_11904041225190911" Archived-At: Subject: Re: [manet] Magnus Westerlund's Discuss on draft-ietf-manet-dlep-pause-extension-06: (with DISCUSS) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2019 16:27:05 -0000 --MCBoundary=_11904041225190911 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 TWFnbnVzLCANCg0KQ29tbWVudHMgaW5saW5lLg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQo+IEZyb206IExvdSBCZXJnZXIgW21haWx0bzpsYmVyZ2VyQGxhYm4ubmV0XQ0KPiBTZW50 OiBUaHVyc2RheSwgQXByaWwgMDQsIDIwMTkgMTE6NTcgQU0NCj4gVG86IE1hZ251cyBXZXN0ZXJs dW5kIDxtYWdudXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb20+OyBUaGUgSUVTRw0KPiA8aWVzZ0Bp ZXRmLm9yZz4NCj4gQ2M6IGRyYWZ0LWlldGYtbWFuZXQtZGxlcC1wYXVzZS1leHRlbnNpb25AaWV0 Zi5vcmc7IG1hbmV0QGlldGYub3JnOw0KPiBtYW5ldC1jaGFpcnNAaWV0Zi5vcmcNCj4gU3ViamVj dDogUmU6IFttYW5ldF0gTWFnbnVzIFdlc3Rlcmx1bmQncyBEaXNjdXNzIG9uIGRyYWZ0LWlldGYt bWFuZXQtZGxlcC0NCj4gcGF1c2UtZXh0ZW5zaW9uLTA2OiAod2l0aCBESVNDVVNTKQ0KPiANCj4g KioqV0FSTklORyEgVEhJUyBFTUFJTCBPUklHSU5BVEVTIEZST00gT1VUU0lERSBWVCBJRElSRUNU LioqKg0KPiAuDQo+IA0KPiBIaSwNCj4gDQo+IA0KPiANCj4gT24gNC80LzIwMTkgNzo0MiBBTSwg TWFnbnVzIFdlc3Rlcmx1bmQgdmlhIERhdGF0cmFja2VyIHdyb3RlOg0KPiANCj4gPiBNYWdudXMg V2VzdGVybHVuZCBoYXMgZW50ZXJlZCB0aGUgZm9sbG93aW5nIGJhbGxvdCBwb3NpdGlvbiBmb3IN Cj4gDQo+ID4gZHJhZnQtaWV0Zi1tYW5ldC1kbGVwLXBhdXNlLWV4dGVuc2lvbi0wNjogRGlzY3Vz cw0KPiANCj4gPg0KPiANCj4gPiBXaGVuIHJlc3BvbmRpbmcsIHBsZWFzZSBrZWVwIHRoZSBzdWJq ZWN0IGxpbmUgaW50YWN0IGFuZCByZXBseSB0byBhbGwNCj4gDQo+ID4gZW1haWwgYWRkcmVzc2Vz IGluY2x1ZGVkIGluIHRoZSBUbyBhbmQgQ0MgbGluZXMuIChGZWVsIGZyZWUgdG8gY3V0IHRoaXMN Cj4gDQo+ID4gaW50cm9kdWN0b3J5IHBhcmFncmFwaCwgaG93ZXZlci4pDQo+IA0KPiA+DQo+IA0K PiA+DQo+IA0KPiA+IFBsZWFzZSByZWZlciB0byBodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2lu dC5jb20vdjIvdXJsP3U9aHR0cHMtDQo+IDNBX193d3cuaWV0Zi5vcmdfaWVzZ19zdGF0ZW1lbnRf ZGlzY3Vzcy0NCj4gMkRjcml0ZXJpYS5odG1sJmQ9RHdJRGFRJmM9TGxVdmlkdmxoU3RHVVN4UWww Z2lPQSZyPVF6Z0NLbEstDQo+IGVVc2JMVzVyOEtaQUw5TF95cU5PTjFkYkt0TWEtDQo+IFdieG5h OCZtPTdaOUdPTFdSd1IwWFBoNFJlRWF2akNMQ3QtDQo+IHp2aElnY1lkd1BKMFlpQmZvJnM9ZjVC N2UzdFZzVGozREtMS2syZXpzQVVfNmV1QlNPeU1pZGh1RmtobDM1RSZlDQo+ID0NCj4gDQo+ID4g Zm9yIG1vcmUgaW5mb3JtYXRpb24gYWJvdXQgSUVTRyBESVNDVVNTIGFuZCBDT01NRU5UIHBvc2l0 aW9ucy4NCj4gDQo+ID4NCj4gDQo+ID4NCj4gDQo+ID4gVGhlIGRvY3VtZW50LCBhbG9uZyB3aXRo IG90aGVyIGJhbGxvdCBwb3NpdGlvbnMsIGNhbiBiZSBmb3VuZCBoZXJlOg0KPiANCj4gPiBodHRw czovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtDQo+IDNBX19kYXRh dHJhY2tlci5pZXRmLm9yZ19kb2NfZHJhZnQtMkRpZXRmLTJEbWFuZXQtMkRkbGVwLTJEcGF1c2Ut DQo+IDJEZXh0ZW5zaW9uXyZkPUR3SURhUSZjPUxsVXZpZHZsaFN0R1VTeFFsMGdpT0Emcj1RemdD S2xLLQ0KPiBlVXNiTFc1cjhLWkFMOUxfeXFOT04xZGJLdE1hLQ0KPiBXYnhuYTgmbT03WjlHT0xX UndSMFhQaDRSZUVhdmpDTEN0LQ0KPiB6dmhJZ2NZZHdQSjBZaUJmbyZzPU9KXzFqeTJMYnkxNHlj OUxvWTE2cWg3SW54aEItQ3cxb2tKWXM3SWFoQkkmZT0NCj4gDQo+ID4NCj4gDQo+ID4NCj4gDQo+ ID4NCj4gDQo+ID4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiANCj4gPiBESVNDVVNTOg0KPiANCj4gPiAtLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tDQo+IA0KPiA+DQo+IA0KPiA+IEl0IGlzIHVuY2xlYXIgdG8gbWUgd2hhdCB0aGUg cHVycG9zZSBvZiB0aGUgcGF1c2UgYW5kIHJlc3VtZSBpcyBoZXJlPw0KPiANCj4gPg0KPiANCj4g PiBJcyBpdCB0byBlbmFibGUgdGhlIHJvdXRlciB0byBidWlsZCB0aGUgcXVldWUgcmF0aGVyIHRo YW4gdGhlIG1vZGVtIGlmIHRoZXJlDQo+IGlzDQo+IA0KPiA+IGEgcXVldWUgYnVpbGR1cCBpbiB0 aGUgbW9kZW0/DQo+IA0KPiANCj4gDQo+IFllcyBhbmQgYWxzbyBhbGxvdyBhIHJvdXRlciB0byBp bXBsZW1lbnQgbW9yZSBzb3BoaXN0aWNhdGVkIHF1ZXVpbmcgaWYNCj4gDQo+IGl0IHNvIGNob29z ZXMsIGUuZy4sIG1hcHBpbmcgbXVsdGlwbGUgREhDUHMgaW50byBhIHNpbmdsZSBtb2RlbSBxdWV1 ZS4NCj4gDQo+IA0KPiANCj4gPiAgIElmIHRoYXQgaXMgdGhlIGNhc2UsIHRoZW4gcGF1c2UgYW5k IHJlc3VtZSB3aWxsDQo+IA0KPiA+IGJlIGRvbmUgZnJlcXVlbnRseSBhbmQgb24gc2hvcnQgdGlt ZSBzY2FsZXMgZHVlIHRvIHZhcmlhYmlsaXR5IG9mIHRoZSBsaW5rLg0KPiBBbmQNCj4gDQo+ID4g dGhlbiB0aGUgcm91dGVyIHJlc3VtZXMgdHJhbnNtaXNzaW9uIHRvIHRoZSBtb2RlbSB3aGVuIHRo ZSBidWZmZXIgaGFzDQo+IGJlZW4NCj4gDQo+ID4gcmVkdWNlZD8NCj4gDQo+IA0KPiANCj4gQWxz byBjb3JyZWN0LsKgIEZ1bmRhbWVudGFsbHkgdGhpcyBpcyB0aGUgc2FtZSBhcyB3aGF0IHdhcyBk ZWZpbmVkDQo+IA0KPiBwcmV2aW91c2x5IGZvciBQUFBvRSBpbiBSRkM1NTc4LCBidXQgdXNpbmcg YSBzaW1wbGVyIG9uL29mZiBtZWNoYW5pc20NCj4gDQo+IGFuZCBETEVQLsKgIERMRVAgaXMgdGhl IHJlcGxhY2VtZW50IGZvciB1c2luZyBQUFBvRSBmb3IgcmFkaW8gdG8gcm91dGVyDQo+IA0KPiBp bmZvcm1hdGlvbi4NCj4gDQo+IA0KPiANCj4gPiBBcyB0aGlzIGlzIGVuYWJsZWQgdG8gYmUgZG9u ZSBvbiBhIHF1ZXVlIGxldmVsIHdoYXQgaG93IGRvZXMgb25lDQo+IA0KPiA+IGVuc3VyZSB0aGUg cGVyIGhvcCBiZWhhdmlvciB0aGF0IGlzIGludGVuZGVkIGJhc2VkIG9uIHRoZSBEU0NQIHdpdGgg dGhpcw0KPiBzcGxpdC4NCj4gDQo+ID4gQmVjYXVzZSB5b3Ugd2lsbCBnZXQgYW4gaW50ZXJhY3Rp b24gYmV0d2VlbiB0aGUgdHdvIHF1ZXVlIHRoYXQgYXJlIGluDQo+IHNlcmllcw0KPiANCj4gPiBm b3IgdGhlIHNhbWUgbGluayB3aGljaCBtYWtlcyBlbnN1cmluZyB0aGUgUEhCIGRpZmZpY3VsdC4N Cj4gDQoNCkknbSBub3QgZXhhY3RseSBzdXJlIHdoYXQgeW91IG1lYW4gaGVyZTsgSSdtIGFzc3Vt aW5nIGl0J3MgYWxvbmcgdGhlIGxpbmVzIG9mIHRoZSByYWRpbyBoYXZpbmcgYSBjb25nZXN0ZWQs IGhpZ2gtcHJpb3JpdHkgcXVldWUsIGFuZCBhIG5vbi1jb25nZXN0ZWQsIGxvdyBwcmlvcml0eSBx dWV1ZS4gSW4gIHRoaXMgY2FzZSwgdGhlIHJhZGlvIGNvdWxkIHRoZW9yZXRpY2FsbHkgYWxsb3cg bG93LXByaW9yaXR5IHRyYWZmaWMgaW50byBpdHMgcXVldWUsIHdoaWxlIHBhdXNpbmcgdGhlIGhp Z2gtcHJpb3JpdHkgdHJhZmZpYy4gVGhlIGNvbmNlcm4gd291bGQgYmUgYSByZS1vcmRlcmluZyBv ZiB0cmFmZmljIGNvbWluZyBvdXQgb2YgdGhlIHJhZGlvIGFuZCBvbnRvIHRoZSBSRiBkdWUgdG8g dGhpcyBjb25kaXRpb24uIA0KDQpBbG9uZyB0aGUgbGluZXMgb2Ygd2hhdCBMb3UgaGFzIGFscmVh ZHkgc2FpZCwgSSByZW1lbWJlciBzb21ldGhpbmcgRnJlZCBCYWtlciBvbmNlIHRvbGQgbWUuIFBh cmFwaHJhc2luZywgaXQgd2FzICJXZWxsLCBpZiB5b3UncmUgZ29pbmcgdG8gdHJ1c3QgdGhlIHJh ZGlvIHRvIGNhcnJ5IHRoZSB0cmFmZmljIGluIHRoZSBmaXJzdCBwbGFjZSwgeW91IHNob3VsZCBh bHNvIHRydXN0IGl0IHRvIDxmaWxsLWluLXRoZS1ibGFuaz4uIiBBcyBMb3UgcHV0IGl0LCAiYSBt b2RlbSB0aGF0IGlzIERTQ1AgYXdhcmUgbXVzdCBjb25mb3JtIHdpdGggdGhlIHNhbWUgcmVxdWly ZW1lbnRzIGFzIGEgcm91dGVyIHRoYXQgaXMgRFNDUCBhd2FyZS4iIFRoZSBleHBlY3RhdGlvbiBp biB0aGUgYWJvdmUgY2FzZSBpcyB0aGF0IHRoZSByYWRpbyB3b3VsZCBkbyB0aGUgYXBwcm9wcmlh dGUgImNsZXZlciB0aGluZ3MiIHRvIGtlZXAgdGhlIHRyYWZmaWMgcHJpb3JpdGl6YXRpb24gaW50 YWN0IHdoaWxlIHJlc29sdmluZyB0aGUgY29uZ2VzdGlvbi4NCg0KVGhlIG1haW4gaW1wZXR1cyBi ZWhpbmQgdGhlIGRvY3VtZW50IGlzIHRvIG1pbmltaXplIHRoZSBudW1iZXIgb2YgZHJvcHBlZCBw YWNrZXRzIGZvciBhbnkgZ2l2ZW4gRFNDUCBidWNrZXQsIGFzIHRoZSByb3V0ZXIgKHVzdWFsbHkp IGhhcyBtb3JlIG1lbW9yeSBhbmQgdGh1cywgbGFyZ2VyIHF1ZXVlIGRlcHRoLiANCg0KUmVnYXJk cywNClN0YW4NCg0KPiANCj4gDQo+IEkgYWdyZWUgdGhhdCB0aGVyZSBhcmUgdHdvIHF1ZXVlcyBp biBzZXJpZXMsIGJ1dCBkb24ndCBzZWUgdGhpcyBhcw0KPiANCj4gbWF0ZXJpYWxseSBkaWZmZXJl bnQgdGhhbiB3aGF0IFJGQzU1NzggYWxsb3dlZCBvciAyIHJvdXRlcnMNCj4gDQo+IGludGVyY29u bmVjdGVkIG92ZXIgYSBsaW5rIHRoYXQgc3VwcG9ydHMgbm9ybWFsIEV0aGVybmV0IHBhdXNlIG9y IFBGQy4NCj4gDQo+IEluIG90aGVyIHdvcmRzLCBJIHNlZSB0aGF0IGEgbW9kZW0gdGhhdCBpcyBE U0NQIGF3YXJlIG11c3QgY29uZm9ybSB3aXRoDQo+IA0KPiB0aGUgc2FtZSByZXF1aXJlbWVudHMg YXMgYSByb3V0ZXIgdGhhdCBpcyBEU0NQIGF3YXJlLg0KPiANCj4gDQo+IA0KPiBBdCBsZWFzdCB0 aGlzIGlzIG15IG9wdGlvbi7CoCBPdGhlcnMgbWF5IHNlZSBpdCBkaWZmZXJlbnRseSwgZS5nLiwg U3Rhbg0KPiANCj4gKHdobyBjby1hdXRob3JlZCBSRkM1NTc4IGFuZCBpcyB0aGUgZG9jIFNoZXBo ZXJkKSBvciB0aGUgb3RoZXJzIGluIHRoZQ0KPiANCj4gV0cgd2hvIGhhdmUgYmVlbiB3b3JraW5n IHJhZGlvL3JvdXRlciBpbnRlcmZhY2VzIGZvciBmYXIgbG9uZ2VyIHRoYW4gSQ0KPiANCj4gaGF2 ZS4uLg0KPiANCj4gDQo+IA0KPiBMb3UNCj4gDQo+IA0KPiANCj4gPiBJIGhvcGUgZm9yIGEgdGlt ZWx5IGNsYXJpZmljYXRpb24gdG8gZGV0ZXJtaW5lIGlmIHRoaXMgaXMgYSBkaXNjdXNzIG9yIG5v dCBhbmQNCj4gDQo+ID4gbWFrZSBpdCBtb3JlIGFjdGlvbmFibGUuDQo+IA0KPiA+DQo+IA0KPiA+ DQo+IA0KPiA+DQo+IA0KPiA+DQo+IA0KPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+IA0KPiA+IG1hbmV0IG1haWxpbmcgbGlzdA0KPiANCj4gPiBt YW5ldEBpZXRmLm9yZw0KPiANCj4gPiBodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20v djIvdXJsP3U9aHR0cHMtDQo+IDNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19tYW5l dCZkPUR3SURhUSZjPUxsVXZpZHZsaFN0R1VTDQo+IHhRbDBnaU9BJnI9UXpnQ0tsSy1lVXNiTFc1 cjhLWkFMOUxfeXFOT04xZGJLdE1hLQ0KPiBXYnhuYTgmbT03WjlHT0xXUndSMFhQaDRSZUVhdmpD TEN0LQ0KPiB6dmhJZ2NZZHdQSjBZaUJmbyZzPTNVYjZMVWdDM3BGdUEzdlMxbzNhenp4VWtlRzhi b0xVOVl0YWlmV3I2dU0NCj4gJmU9DQo+IA0KPiA+DQoNClRoaXMgZWxlY3Ryb25pYyBtZXNzYWdl IGFuZCBhbnkgZmlsZXMgdHJhbnNtaXR0ZWQgd2l0aCBpdCBjb250YWlucyBpbmZvcm1hdGlvbiBm cm9tIGlEaXJlY3QsIHdoaWNoIG1heSBiZSBwcml2aWxlZ2VkLCBwcm9wcmlldGFyeSBhbmQvb3Ig Y29uZmlkZW50aWFsLiBJdCBpcyBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGlu ZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdob20gdGhleSBhcmUgYWRkcmVzc2VkLiANCklmIHlvdSBh cmUgbm90IHRoZSBvcmlnaW5hbCByZWNpcGllbnQgb3IgdGhlIHBlcnNvbiByZXNwb25zaWJsZSBm b3IgZGVsaXZlcmluZyB0aGUgZW1haWwgdG8gdGhlIGludGVuZGVkIHJlY2lwaWVudCwgYmUgYWR2 aXNlZCB0aGF0IHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIGFuZCB0aGF0 IGFueSB1c2UsIGRpc3NlbWluYXRpb24sIGZvcndhcmRpbmcsIHByaW50aW5nLCBvciBjb3B5aW5n IG9mIA0KdGhpcyBlbWFpbCBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLiBJZiB5b3UgcmVjZWl2ZWQg dGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIGRlbGV0ZSBpdCBhbmQgaW1tZWRpYXRlbHkgbm90 aWZ5IHRoZSBzZW5kZXIuDQo= --MCBoundary=_11904041225190911 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8 Magnus,

Comments inline.

> -----Original Message-----
> From: Lou Berger [mailto:lberger@labn.net]
> Sent: Thursday, April 04, 2019 11:57 AM
> To: Magnus Westerlund <magnus.westerlund@ericsson.com>; The IESG=
> <iesg@ietf.org>
> Cc: draft-ietf-manet-dlep-pause-extension@ietf.org; manet@ietf.org; > manet-chairs@ietf.org
> Subject: Re: [manet] Magnus Westerlund's Discuss on draft-ietf-manet-d= lep-
> pause-extension-06: (with DISCUSS)
>
> ***WARNING! THIS EMAIL ORIGINATES FROM OUTSIDE VT IDIRECT.***
> .
>
> Hi,
>
>
>
> On 4/4/2019 7:42 AM, Magnus Westerlund via Datatracker wrote:
>
> > Magnus Westerlund has entered the following ballot position for >
> > draft-ietf-manet-dlep-pause-extension-06: 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 cu= t this
>
> > introductory paragraph, however.)
>
> >
>
> >
>
> > Please refer to https://urldefense.proofpoint.com/v2/url?u= =3Dhttps-
> 3A__www.ietf.org_iesg_statement_discuss-
> 2Dcriteria.html&d=3DDwIDaQ&c=3DLlUvidvlhStGUSxQl0giOA&r=3D= QzgCKlK-
> eUsbLW5r8KZAL9L_yqNON1dbKtMa-
> Wbxna8&m=3D7Z9GOLWRwR0XPh4ReEavjCLCt-
> zvhIgcYdwPJ0YiBfo&s=3Df5B7e3tVsTj3DKLKk2ezsAU_6euBSOyMidhuFkhl35E&= amp;e
> =3D
>
> > for more information about IESG DISCUSS and COMMENT positions. >
> >
>
> >
>
> > The document, along with other ballot positions, can be found her= e:
>
> > https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > 3A__datatracker.ietf.org_doc_draft-2Dietf-2Dmanet-2Ddlep-2Dpause-
> 2Dextension_&d=3DDwIDaQ&c=3DLlUvidvlhStGUSxQl0giOA&r=3DQzg= CKlK-
> eUsbLW5r8KZAL9L_yqNON1dbKtMa-
> Wbxna8&m=3D7Z9GOLWRwR0XPh4ReEavjCLCt-
> zvhIgcYdwPJ0YiBfo&s=3DOJ_1jy2Lby14yc9LoY16qh7InxhB-Cw1okJYs7IahBI&= amp;e=3D
>
> >
>
> >
>
> >
>
> > -----------------------------------------------------------------= -----
>
> > DISCUSS:
>
> > -----------------------------------------------------------------= -----
>
> >
>
> > It is unclear to me what the purpose of the pause and resume is h= ere?
>
> >
>
> > Is it to enable the router to build the queue rather than the mod= em if there
> is
>
> > a queue buildup in the modem?
>
>
>
> Yes and also allow a router to implement more sophisticated queuing if=
>
> it so chooses, e.g., mapping multiple DHCPs into a single modem queue.=
>
>
>
> > If that is the case, then pause and resume will
>
> > be done frequently and on short time scales due to variability of= the link.
> And
>
> > then the router resumes transmission to the modem when the buffer= has
> been
>
> > reduced?
>
>
>
> Also correct.  Fundamentally this is the same as what was defined=
>
> previously for PPPoE in RFC5578, but using a simpler on/off mechanism<= BR> >
> and DLEP.  DLEP is the replacement for using PPPoE for radio to r= outer
>
> information.
>
>
>
> > As this is enabled to be done on a queue level what how does one<= BR> >
> > ensure the per hop behavior that is intended based on the DSCP wi= th this
> split.
>
> > Because you will get an interaction between the two queue that ar= e in
> series
>
> > for the same link which makes ensuring the PHB difficult.
>

I'm not exactly sure what you mean here; I'm assuming it's along the lines = of the radio having a congested, high-priority queue, and a non-congested, = low priority queue. In this case, the radio could theoretically allow low-= priority traffic into its queue, while pausing the high-priority traffic. T= he concern would be a re-ordering of traffic coming out of the radio and on= to the RF due to this condition.

Along the lines of what Lou has already said, I remember something Fred Bak= er once told me. Paraphrasing, it was "Well, if you're going to trust = the radio to carry the traffic in the first place, you should also trust it= to <fill-in-the-blank>." As Lou put it, "a modem that is D= SCP aware must conform with the same requirements as a router that is DSCP = aware." The expectation in the above case is that the radio would do t= he appropriate "clever things" to keep the traffic prioritization= intact while resolving the congestion.

The main impetus behind the document is to minimize the number of dropped p= ackets for any given DSCP bucket, as the router (usually) has more memory a= nd thus, larger queue depth.

Regards,
Stan

>
>
> I agree that there are two queues in series, but don't see this as
>
> materially different than what RFC5578 allowed or 2 routers
>
> interconnected over a link that supports normal Ethernet pause or PFC.=
>
> In other words, I see that a modem that is DSCP aware must conform wit= h
>
> the same requirements as a router that is DSCP aware.
>
>
>
> At least this is my option.  Others may see it differently, e.g.,= Stan
>
> (who co-authored RFC5578 and is the doc Shepherd) or the others in the=
>
> WG who have been working radio/router interfaces for far longer than I=
>
> have...
>
>
>
> Lou
>
>
>
> > I hope for a timely clarification to determine if this is a discu= ss or not and
>
> > make it more actionable.
>
> >
>
> >
>
> >
>
> >
>
> > _______________________________________________
>
> > manet mailing list
>
> > manet@ietf.org
>
> > https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > 3A__www.ietf.org_mailman_listinfo_manet&d=3DDwIDaQ&c=3DLlUvidv= lhStGUS
> xQl0giOA&r=3DQzgCKlK-eUsbLW5r8KZAL9L_yqNON1dbKtMa-
> Wbxna8&m=3D7Z9GOLWRwR0XPh4ReEavjCLCt-
> zvhIgcYdwPJ0YiBfo&s=3D3Ub6LUgC3pFuA3vS1o3azzxUkeG8boLU9YtaifWr6uM<= BR> > &e=3D
>
> >


This electronic message and any files transmitted with it contains informat= ion 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 respons= ible for delivering the email to the intended recipient, be advised that yo= u have received this email in error, and that any use, dissemination, forwa= rding, printing, or copying of this email is strictly prohibited. If you re= ceived this email in error, please delete it and immediately notify the sen= der.

--MCBoundary=_11904041225190911-- From nobody Thu Apr 4 15:28:42 2019 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 B06C5120048 for ; Thu, 4 Apr 2019 15:28:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=verizon.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 TmUwRWqPgQnQ for ; Thu, 4 Apr 2019 15:28:32 -0700 (PDT) Received: from sonic310-15.consmr.mail.bf2.yahoo.com (sonic310-15.consmr.mail.bf2.yahoo.com [74.6.135.125]) (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 8152F120179 for ; Thu, 4 Apr 2019 15:28:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verizon.net; s=a2048; t=1554416910; bh=TmRiOX1o/uQV709xKtrGLJC88mrYETublN77xx0V6i4=; h=From:Subject:To:Cc:References:Date:In-Reply-To:From:Subject; b=dz/Jd+cioMuQYiPWPok3yJcuMNNK3N8nGHApROxeIP7WPSj2wPz7SbUjVLjT4KY+o7U4s93127+v9dkwAVbrrouW5HG7zN7KsC9tZNfE2OBk99XVMLckDT/ZHGbkMF306ElHQxBZQKYLHGFAvdy79PQUEJT9KdNALviRo45yNmS6bSqq3lK5OkpS6dk54v4WKbAAtSwMUwEBXpFh1ehA6ujxtxkLlwV5Fc+kCQklNCkLa8Diu+mj5BG70ObiFI3ysIdNC+/infqg+7rlFNH2EYXDTJh8GuAl2zPTDCcm/m6upU0VaIHOu9z0W+CcmcCXNZ9fJQL2HnIHYHaOn4/6bA== X-YMail-OSG: MBxwPmcVM1nQRhYlomroMvXNOd53BfmCv7B7FmqdDili0BzKN8.fKTI1lWqJBSQ _AmYGrd2p.izlcrzonNjziVCZi0Dqz.0yNJMh6ET55cd5iEfAy3SobvxnISbWzoBGoPkWfPU3zh_ 5wl09sfkKoxWA10rR6IvGxKrmQV0juc2Xa..Jq8OwdXs3Ik.KMHB_cbO8rK6uY7Oz.2cvWBsWQMc snJPLfl1YUiD007naU.NLreizu5dOt9XnQwFj4kKLKdHN1PemZZGBkdn8jH2SIDgi_np3hO4jl2F s7SRD.u1kd7hAorxhgQ0zfsoNKCLnrOwL_DYACcM_9IkbfV3TkyVrzj2XffP7HEc0vFgrXrERrP4 y9WH9puXJon5p7RG2kwxcqZDd685.mEiYDTZwDSFWm8N3q_au7SHsz3BOn.EXLaPqlFfA8Zojuce cIqSV5hAiED6h6Xm1RKcA.kzeydPIl2B36xo6IipHaosPRp9nGx06C4bOoz6WljIc9ZjtbJSccLU 9O_FOOlYFjNtWTVrGN0Kl9gjG.185.U4aR9WzeIlFHT0GSqPfot5yrQr9HokUUblxvCjR6jYH96h XgMu7qlwoVk8ZxMWF6Wrj9_TvVuBzoO2UdbbmXSD8qn5.NzoB8ML.vp7rbTVQlbB1NCswKlHWOBP XkiPctnFPoPqO9EJsXjeyUr79D610DVOPTkRRjdC0UN3yQ16v1jQenTD4Y3DuWesWTDiCOUkaabW Xn9hQc5hZHzGNZ9D1CCaLOAM_pQFQ9ATVicjOvCm0NSLL11tfb4cc2In6pfYuevwSBFmiekHk6UB FsCo5djXVDcVijMt_GnwC1N_zFyxyi_q.vncgVUJNCiJTwkj1Qp69ny2pifmS2IdPUpBuzB3u0_h I70XAkLtDlRcK8BzzvbvQbRzsMQIvES3cMjoKiXQjaHFnfOefbs01QWjEDVt1aaLENCtQpspvHF1 MwLJnSbKjSkL.TZ_0GPwrL_v1pxoPE6ZDFC4uvR5Qq0WuLJ_LbqAJHGCwkikYPFe0pf4oleUB7tS mrjxAKJrltip6H9as57Erj1lGVvwPvzF11muPGDuovxX_Ywbf8GVh.8AFa.u8tHTQEJ6zO_tLP7z Src1P8wuA9gGfzY5CMl_u Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.bf2.yahoo.com with HTTP; Thu, 4 Apr 2019 22:28:30 +0000 Received: from 192.40.225.130 (EHLO Steves-MacBook-Pro.local) ([192.40.225.130]) by smtp413.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID ef3da3371e5c72119df3c3879322e470; Thu, 04 Apr 2019 22:28:29 +0000 (UTC) From: Stephen Kent To: Lou Berger , Stephen Kent , secdir@ietf.org Cc: draft-ietf-manet-dlep-pause-extension.all@ietf.org, manet@ietf.org, ietf@ietf.org References: <155309526492.14741.18141095676597911076@ietfa.amsl.com> <6dddf23c-806a-d8ab-7f65-ac7b0855deac@labn.net> Message-ID: Date: Thu, 4 Apr 2019 15:28:12 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <6dddf23c-806a-d8ab-7f65-ac7b0855deac@labn.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [manet] Secdir last call review of draft-ietf-manet-dlep-pause-extension-05 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2019 22:28:35 -0000 Lou, Thanks for the quick reply. Your proposed edits look fine. Steve > Hi Steve, > > Thanks for the comments! > > On 3/20/2019 11:21 AM, Stephen Kent via Datatracker wrote: >> Reviewer: Stephen Kent >> Review result: Has Nits >> >> I have reviewed this document as part of the security directorate's >> ongoing >> effort to review all IETF documents being processed by the IESG.  These >> comments were written with the intent of improving security >> requirements and >> considerations in IETF drafts.  Comments not addressed in last call >> may be >> included in AD reviews during the IESG review.  Document editors and >> WG chairs >> should treat these comments just like any other last call comments. >> >> Review Summary: Ready with nits >> >> This brief document defines and extension to DLEP That enables a >> modem to use >> DLEP to pause and resume inbound traffic from a specific peer. DLEP >> (RFC 8175) >> cites GTSM as a security mechanism, which is rather weak, but it says >> that >> implementations SHOULD use TLS (1.2), which is fine. >> >> The text states that “An example of when a modem might send this data >> item is >> when an internal queue length exceeds a particular threshold.” >> However, all of >> details of this data item seem to focus exclusively on queues. Thus >> it seems >> likely that this is not just an example, but, rather, the primary >> motivation >> for introducing the pause extension. A slight rewording of the text >> here seems >> appropriate, or the authors could describe other (not-queue-based) >> examples. > > fair point, how about: > > OLD: > >   An example of when a modem might send >   this data item is when an internal queue length exceeds a particular >   threshold. > > NEW: > > The motivating use case is for this data item is when a modem's > internal queue length exceeds a particular threshold.  Other use cases > are possible, e.g., when there a non queue related congestion points > within a modem, but such are not explicitly described in this document. > > >> The Security Considerations section of 8175 addresses a reasonable >> range of >> concerns. Thus it is appropriate that this document’s Security >> Considerations >> section is very brief, as it cites the corresponding section in 8175. >> I suggest >> a couple of minor change to the wording here: >> >> “The extension does not inherently introduce any additional threats … >> -> >> “The extension does not inherently introduce any additional >> vulnerabilities …” >> >> “ …  but this is not a substantively different threat by …” >> -> >> “ …  but this is not a substantively different attack by …” >> >> There are numerous examples of awkward/poor phrasing throughout the >> document, >> which I hope the RFC Editor will correct, e.g., >> >> Abstract: >>          “…to the DLEP protocol …” -> “… to DLEP …” > > Hopefully these have already been corrected, if not I'm sure the > editor will help us out. > > >> page 7: >> >> “A modem can indicate that traffic is to be suppressed on a device    >> wide or >> destination specific basis.” >> >> “A modem can indicate that traffic is to be suppressed on a device-   >> wide or >> destination-specific basis.” > > Thanks. > >> “This includes that to indicate that transmission can resume to all >> destinations  …” >> >> “Thus, to indicate that transmission can resume to all destinations,  …” > > I'm not sure thus is quite right, but will revise! > > Thanks again!, > > Lou > >> >> > From nobody Thu Apr 4 16:56:33 2019 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 197701202B1; Thu, 4 Apr 2019 16:56:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Bob Briscoe via Datatracker To: Cc: draft-ietf-manet-dlep-pause-extension.all@ietf.org, manet@ietf.org, ietf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.94.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Bob Briscoe Message-ID: <155442219204.31004.18308454286183143947@ietfa.amsl.com> Date: Thu, 04 Apr 2019 16:56:32 -0700 Archived-At: Subject: [manet] Tsvart last call review of draft-ietf-manet-dlep-pause-extension-06 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.29 List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2019 23:56:32 -0000 Reviewer: Bob Briscoe Review result: On the Right Track This document has been reviewed as part of the transport area review team's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors and WG to allow them to address any issues raised and also to the IETF discussion list for information. When done at the time of IETF Last Call, the authors should consider this review as part of the last-call comments they receive. Please always CC tsv-art@ietf.org if you reply to or forward this review. ==1. Introduction== It would be useful to describe the use-case where the modem does not implement active queue management but the router does, so the modem can use flow control to push the queue back into the router, where it can be more intelligently controlled. ===Scope within Intro=== Please extend the single sentence about scope (end of 2nd para of Intro) to explain that pause control only applies to data in the router to modem direction. Please also mention that the scope of pause-based flow control is limited to one hop and to a point-to-point link between router and modem, not multipoint. The modem does not track the source of the data in its queue, so it cannot focus pause messages onto particular sending stations on a multipoint link, or onto particular ingress ports of the router. Why is the scope limited to DLEP radio links? I would have thought this protocol is generally useful between a and modem and router. ==3. Extension Data Items== Pls define the direction of the messages: s/The xxx Data Item is used by a modem to.../ /A modem sends the xxx Data Item to its peer router to.../ ===Unsafe design?=== Is it not good practice to make the data plane robust to unexpected control plane failures (e.g. key expiry, incorrect or mis-timed change of address, etc.) and vice versa? So, would it not be more robust for the router to time-out a pause if no restart appears? Also, if the last message received before shutting down or suspending was a pause, should the router restart or resume in the paused state? What if the router enters a power-saving state after it is paused and misses a restart message? ==Queue size in bytes for informational purposes?== Why? This strikes me as like one of those Government forms you have to fill in with an ill-formed question that is mandatory to answer, even though sometimes there is no answer, and you cannot proceed until you've answered, even though the answer is not needed anyway. For instance, if there is a shared physical buffer, a size cannot be straightforwardly given for each logical buffer. So, if buffer size info is not used by the protocol, do not include it in the protocol. On the other hand, how is the threshold at which the modem sends a pause configured. Is that out of scope? If so, where is it specified? Wherever this is specified, it should be possible to specify the threshold in time units (queue delay at the current service rate of the queue), not just in bytes. This is important for queues in a hierarchy where the service rate varies, e.g. dependent on traffic in another queue with priority over it. Or simply where the modem can operate at different rates. ==3.3 Restart== "A router which receives the Restart Data Item SHOULD resume transmission of the identified traffic to the modem." Why only SHOULD? Under what conditions would it not? ==4. Security Considerations== "The extension does not inherently introduce any additional vulnerabilities above those documented in [RFC8175]." Er, no... What about the ability for an off-path attacker to stop the router sending data!? The last part about TLS needs to be worded differently. Because of the above additional vulnerability, the router MUST verify that all 3 types of message are authenticated by the modem. This requires client authentication mode of TLS, which is not mentioned in RFC8175, so it needs to be mentioned here. Or is the TLS session set up by the router (so the modem is the authenticated server)? Also this raises the question of key management, if every modem has to be authenticated by its router. "but this is not a substantively different attack by such a compromised modem simply dropping all traffic destined to, or sent by a router." Er, no... The modem does not need to be compromised for a 3rd party to send spoof messages purporting to be from the modem. ==Nits== 1. Intro "DLEP peers are comprised of a modem and a router" is incorrect English for what you mean (it means that each peer consists of a modem and a router). Better to do away with this sentence completely, and alter to the previous sentence to "It provides the exchange of link related control information between a modem and its DLEP peer router." 3.1 s/with Queue Index/ /with a Queue Index/ Scale: s/An 4-bit/ /A 4-bit/ In general, I think the term "queue size" is wrongly being used where "buffer size" should be used (the queue size is the varying size of the queue within the buffer at any one time). Also, pls consistently use the term 'paused' not 'suppressed', which has the potentially ambiguous meaning of 'discarded'. Delete gratuitous 'is': "The motivating use case [is] for this data item is when a modem's internal queue length exceeds a particular threshold." CURRENT: "e.g., when there a non queue related congestion points within a modem, but such are not explicitly described in this document." SUGGESTED: "e.g., when there are non queue related congestion points within a modem. Such use-cases are not explicitly described in this document." From nobody Fri Apr 5 02:12:05 2019 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 3A40C120398; Fri, 5 Apr 2019 02:12:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 JHIzKi01F07G; Fri, 5 Apr 2019 02:12:02 -0700 (PDT) Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30041.outbound.protection.outlook.com [40.107.3.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDFB11201BE; Fri, 5 Apr 2019 02:12:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=UdFhQbRZmDj4fo3ce867gPMyTM/ldtTMMT3v3JwmPlk=; b=W2kc2K4t/dPbylwHUNQwkaEXaj4DG3LHXJ7wX3gPe+GTl3P4xu+2qk4tjwqUP/ELVnTI9N+ZcW2LydDWLQzUFrfXbq06Gzwg9SNlwhGlH1Ia2qaV7I2KjVDaIwKSIgT8NqtxWS7jZXa4HQD488N7lpB9X7e7lhYi9U70t3mD9Ns= Received: from HE1PR0701MB2522.eurprd07.prod.outlook.com (10.168.128.149) by HE1PR0701MB2457.eurprd07.prod.outlook.com (10.168.130.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1771.11; Fri, 5 Apr 2019 09:11:57 +0000 Received: from HE1PR0701MB2522.eurprd07.prod.outlook.com ([fe80::107c:5f27:2ef:8505]) by HE1PR0701MB2522.eurprd07.prod.outlook.com ([fe80::107c:5f27:2ef:8505%5]) with mapi id 15.20.1771.006; Fri, 5 Apr 2019 09:11:57 +0000 From: Magnus Westerlund To: "Ratliff, Stanley" , Lou Berger , The IESG CC: "draft-ietf-manet-dlep-pause-extension@ietf.org" , "manet@ietf.org" , "manet-chairs@ietf.org" Thread-Topic: [manet] Magnus Westerlund's Discuss on draft-ietf-manet-dlep-pause-extension-06: (with DISCUSS) Thread-Index: AQHU6tuJoEU8aqyRmUir+1XuKzIGuQ== Date: Fri, 5 Apr 2019 09:11:57 +0000 Message-ID: References: <155437815884.30894.8011482899811561433.idtracker@ietfa.amsl.com> <8c18420b622f405eb0d4adcf844b315d@idirect.net> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=magnus.westerlund@ericsson.com; x-originating-ip: [192.176.1.80] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 9d0947e8-d348-4947-ee3e-08d6b9a6c0ff x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600139)(711020)(4605104)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:HE1PR0701MB2457; x-ms-traffictypediagnostic: HE1PR0701MB2457: x-microsoft-antispam-prvs: x-forefront-prvs: 0998671D02 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(376002)(366004)(396003)(346002)(136003)(51444003)(51914003)(189003)(199004)(105586002)(9686003)(316002)(71200400001)(6246003)(14454004)(71190400001)(53936002)(486006)(102836004)(44832011)(446003)(186003)(2906002)(26005)(106356001)(76176011)(99286004)(476003)(66066001)(6436002)(86362001)(4326008)(7736002)(6506007)(7696005)(55016002)(25786009)(52536014)(256004)(305945005)(3846002)(74316002)(6116002)(33656002)(81166006)(8936002)(110136005)(54906003)(478600001)(8676002)(81156014)(5660300002)(97736004)(229853002)(68736007)(66574012); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0701MB2457; H:HE1PR0701MB2522.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: TEyVK5koScCcx83reWqri15sBHjoT3UxP82l3D2GlpCUKmaxbrBDq6txIA0IKPlbW8Ll4RuuJ1wsuu4COnPeNdQ6nyXd/uco6GSfPSYqdO3K35b7q41bykDDGHEwOSzJdGqRHTSsugY2c6me1JkjocuOoeYDip7Zxtd6auAoIsMloNrmgbDY0aRAx+XMOrtbnq+8+Tp2ZcCRQveeY9CJc60Sw70Gts7dmNUHtpB/6b78l6va2HkDaczAvZQd5poWyyKNnIthtOwlSZ8IdFz+nrx90iX4m4qwcOM/zYUknzI5jQ+krgW0xvVaD5BgzVWPaGljAtBM47YkF+eBuekiKc2NCELhU0LOgkXu6GP6ob5navuPAcRcGmm5hVNIvIYmnSYg0nXTAd31xFsyw9LLHnY62EmSIzxkCWjjZf9Llho= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 9d0947e8-d348-4947-ee3e-08d6b9a6c0ff X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Apr 2019 09:11:57.1520 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2457 Archived-At: Subject: Re: [manet] Magnus Westerlund's Discuss on draft-ietf-manet-dlep-pause-extension-06: (with DISCUSS) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Apr 2019 09:12:04 -0000 Hi,=0A= =0A= Thanks for the replies. =0A= =0A= I think the main point here is if one should treat router + modem as one=0A= common queue when it comes to meeting PHBs or treat them as two in=0A= sequence queues. If one treat them as two queues then you get the same=0A= behavior as two routers in sequence. And that is acceptable from one=0A= angle, but it also results in additional jitter and latencies.=0A= =0A= If we take the Expedited Forwarding PHB (RFC 3246) treating this as two=0A= queue results in that the error is E_a1 (router) + E_a2 (mode) rather=0A= than a E_a for the combined queue. The question is if E_a actually will=0A= be smaller than E_a1+E_a2 when one uses this type of control? In the=0A= combined case if the modem queue is so shallow that E_a2 << E_a1 as well=0A= as that time for performing the DLEP signalling is so short that the=0A= main variations ends up being in the router queue where one can apply=0A= suitable policies to control queue load to prevent violation of the=0A= targets.=0A= =0A= I think my main concern will be what happens if one attempts to=0A= implement L4S dual queues or DETNET and have DLEP in the path. Will this=0A= require additional extensions to provide more detailed flow control=0A= information so that lower latency or more deterministic behavior can be=0A= achieved?=0A= =0A= I noticed that TSVART reviewer Bob Briscoe asked for a use case=0A= description of the case when the main queue is pushed to the router. I=0A= think that appears to be a good idea. I think what I am wondering is if=0A= there need to be some applicability statement here due the limitations=0A= of the technology?=0A= =0A= Cheers=0A= =0A= Magnus=0A= =0A= =0A= -- =0A= =0A= Magnus Westerlund =0A= =0A= ----------------------------------------------------------------------=0A= Network Architecture & Protocols, Ericsson Research=0A= ----------------------------------------------------------------------=0A= Ericsson AB | Phone +46 10 7148287=0A= Torshamnsgatan 23 | Mobile +46 73 0949079=0A= SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com=0A= ----------------------------------------------------------------------=0A= =0A= From nobody Mon Apr 8 11:57:18 2019 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 E3E67120329; Mon, 8 Apr 2019 11:57:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Warren Kumari via Datatracker To: "The IESG" Cc: draft-ietf-manet-dlep-pause-extension@ietf.org, Stan Ratliff , aretana.ietf@gmail.com, manet-chairs@ietf.org, sratliff@idirect.net, manet@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.94.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Warren Kumari Message-ID: <155474982892.30185.1930382368416788523.idtracker@ietfa.amsl.com> Date: Mon, 08 Apr 2019 11:57:08 -0700 Archived-At: Subject: [manet] Warren Kumari's Discuss on draft-ietf-manet-dlep-pause-extension-06: (with DISCUSS) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.29 List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2019 18:57:09 -0000 Warren Kumari has entered the following ballot position for draft-ietf-manet-dlep-pause-extension-06: 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-pause-extension/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Please note that I'm really not a DLEP person, and so this may be completely incorrect -- in which case I'm (of course!) happy to clear my discuss. Hypothetical Scenario: My next-door neighbor keeps using up all the bandwidth, making my Internets slow! Stupid neighbor! Until now I didn't have much motivation to mess with DLEP (it didn't really gain me anything), but now I can spoof Pause Data Items to get the router to stop sending traffic to her, freeing up all the bandwidth for me. The security considerations section doesn't *really* cover this -- it says: " Note that this extension does allow a compromised or impersonating modem to suppress transmission by the router, but this is not a substantively different attack by such a compromised modem simply dropping all traffic destined to, or sent by a router." -- that only covers compromised modems, not impersonating modems. It also says: "[RFC8175] defines the use of TLS to protect against the impersonating attacker." -- yes, RFC8175 does indeed define the use of TLS, but doesn't require it. RFC8175 Security Considerations also say: " This specification does not address security of the data plane, as it (the data plane) is not affected, and standard security procedures can be employed." and "Similar issues can arise if DLEP data is used as an input to policing algorithms -- injection of malicious data via DLEP can cause those policing algorithms to make incorrect decisions, degrading network throughput." It seems that this specification is specifically allowing the dataplane to be affected by (spoofed) DLEP messages, and in a much more direct way than discussed in the RFC8175 security considerations section. I think that this is dangerous without much more direct advice (like "MUST use TLS" or similar). From nobody Tue Apr 9 04:22:21 2019 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 7E26C12078A; Tue, 9 Apr 2019 04:22:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Bob Briscoe via Datatracker To: Cc: draft-ietf-manet-dlep-multi-hop-extension.all@ietf.org, manet@ietf.org, ietf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.94.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Bob Briscoe Message-ID: <155480892243.14232.8537433440288444332@ietfa.amsl.com> Date: Tue, 09 Apr 2019 04:22:02 -0700 Archived-At: Subject: [manet] Tsvart last call review of draft-ietf-manet-dlep-multi-hop-extension-06 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.29 List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2019 11:22:04 -0000 Reviewer: Bob Briscoe Review result: Ready with Issues This document has been reviewed as part of the transport area review team's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors and WG to allow them to address any issues raised and also to the IETF discussion list for information. When done at the time of IETF Last Call, the authors should consider this review as part of the last-call comments they receive. Please always CC tsv-art@ietf.org if you reply to or forward this review. AFAICT, there's nothing technically wrong, but I believe the authors use of normative text does not convey the meaning they intended, in nearly every case. It will be seen below that there seems to be a general misunderstanding of the use of, 'SHOULD do X' when there will never be a case when X should not be done. 'SHOULD' and 'MAY' need to be used judiciously, because they make interoperability harder. ==Inappropriate Normative Text== S.2. "The use of the Multi-Hop Forwarding Extension SHOULD be configurable. " {I think you mean it SHOULD be possible to enable/disable the extension? On a modem. a router or both? In what circumstances would it not be configurable (if none, then MUST would be appropriate)? What happens if one device uses the extension and another doesn't? This last question also applies for incremental deployment.} S.3.1. "The Hop Count Data Item SHOULD be carried in the Destination Up, Destination Update, Destination Announce Response, and Link Characteristics Response messages." {I don't think the use of "SHOULD" here achieves what you intend. I think you're trying to say that this data item can only be carried in these 4 messages. But what you've said is that all these messages SHOULD contain a Hop Count data item. If any normative text is needed here, I think it would say this data item MUST NOT be carried in messages other than these 4. But maybe just substitute 'SHOULD' with 'can'?} S.3.2. The Hop Control Data Item MAY be carried in a Session Update Message sent by a router when the control applies to the whole device, or a Link Characteristics Request Message when the control applies to a particular destination. {Again, I think you're trying to say, "If used, the Hop Control Data Item MUST only be carried in" ...one of these two message types.} "A modem that receives the Hop Control Data Item in a [XXX] Message SHOULD take whatever actions are needed to make the change indicated by the data item for [YYY]." (two occurrences) {Inappropriate use of SHOULD: a) Surely a modem MUST "take whatever actions are needed." Why would it not? b) Anyway, it's meaningless to normatively require a vaguely defined action} S.3.2.3 Direction Connection "It indicates that the modem SHOULD attempt to establish a direct connection with the destination identified in the message." {I think you mean 'MUST'. Why would it not even attempt to?} "This action SHOULD only be sent for destinations for which the Hop Count is greater than 1 and has the P-Bit set in the previously received Hop Count Data Item." {I think you mean MUST. Why would it be sent otherwise?} S.3.2.4. Suppress Forwarding I suggest that you don't gratuitously switch from 'MUST' to 'SHALL' just for this section? Many implementers search the text for 'MUST'. ==Authentication== S.4. RFC8175 says 'For all "networked deployments" ..., the implementation and use of TLS are STRONGLY RECOMMENDED.' I believe it would be worth identifying which extensions would be unsafe if TLS were not used. Certainly all the Multi-Hop Extensions would be unsafe if not authenticated. ==General Nits== Inappropriate and/or inconsistent capitalization of certain phrases, like 'Data Item' or 'Action' or 'Message'. ==Specific Nits== I've provided suggested corrections in the following xml files: http://bobbriscoe.net/tmp/draft-ietf-manet-dlep-multi-hop-extension-06_BB.xml http://bobbriscoe.net/tmp/draft-ietf-manet-dlep-multi-hop-extension-06_BB.txt http://bobbriscoe.net/tmp/draft-ietf-manet-dlep-multi-hop-extension-06_BB-DIFF-06.html From nobody Wed Apr 10 12:39:53 2019 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 AB23512044E; Wed, 10 Apr 2019 12:39:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alissa Cooper via Datatracker To: "The IESG" Cc: draft-ietf-manet-dlep-pause-extension@ietf.org, Stan Ratliff , aretana.ietf@gmail.com, manet-chairs@ietf.org, sratliff@idirect.net, manet@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.95.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Alissa Cooper Message-ID: <155492518369.22601.15786320586524280536.idtracker@ietfa.amsl.com> Date: Wed, 10 Apr 2019 12:39:43 -0700 Archived-At: Subject: [manet] Alissa Cooper's Discuss on draft-ietf-manet-dlep-pause-extension-06: (with DISCUSS and COMMENT) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.29 List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2019 19:39:44 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-manet-dlep-pause-extension-06: 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-pause-extension/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- This work item does not appear to be inside the scope of the MANET charter, at least based on my reading of the charter. Am I missing something? ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I support the DISCUSS positions of Warren and Magnus. I'm unclear on why this specification is necessary, i.e. why the use of existing transport protocols and processing of DSCPs do not suffice to achieve what this specification is aiming to achieve. Is that explained in another document somewhere? = Section 1 = "Various flow control methods are possible, e.g., see [I-D.ietf-manet-dlep-da-credit-extension]." The referenced document does not specify a flow control method. Maybe draft-ietf-manet-dlep-credit-flow-control is what was intended? From nobody Wed Apr 10 12:42:08 2019 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 60553120458; Wed, 10 Apr 2019 12:42:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.301 X-Spam-Level: ** X-Spam-Status: No, score=2.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_SUMOF=5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=r0JGJHlJ; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=V/SZDoZj 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 aEc4PFVErXZa; Wed, 10 Apr 2019 12:41:56 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 341CA1205CD; Wed, 10 Apr 2019 12:41:56 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 5024521EEB; Wed, 10 Apr 2019 15:41:55 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Wed, 10 Apr 2019 15:41:55 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h= from:message-id:content-type:mime-version:subject:date :in-reply-to:cc:to:references; s=fm2; bh=wcObEG81s6E89uYlRFzMPKg y69nckH+6KC0qo+mvnyM=; b=r0JGJHlJRhLgJ2iHKrrkWSSdD00msaBRbGKU2TB aBrHDBNDFPCBbAEHTUbZl1I4iCgOVT75Px8y2IMzTv7HOfMg5afXmnA6QU8EDyS7 FWohEeoyLN/Nj39CCpdBrY/yv9YP7gbxH1s63gZHeRL6xheqyabKIzcV1TqT3Auv Zim3GzIkamdbIaahQLBUnXgWDGaE/G1wuZdkIfEgbrRvVknG1uCxI4VnMEOWXbRf SKAoZ9a/u85JK4VC6UqsLezU2I8JqZ0UOGNjG8EoHFDYQLrUr6jp/sqDYKoAYSHC zVz4DrAHHt+LbZGfErOrLPUn9nlsuQkIPpiskXnHznQ+XsA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=wcObEG 81s6E89uYlRFzMPKgy69nckH+6KC0qo+mvnyM=; b=V/SZDoZj3HLnNzWQK5Fd+D QKauXRcl1PyMHti+R/3qrbbg2Y+bCBf8poEWl2ZvwHZEsRp6Pt6kbIfU63/4aFRT Je7lKesHQ4xX2Be/dOY9iwTw5DhMIuAn5vc5wly4fGZB+NUrGGN+mNQZGHLhZ/PX 8OI74gSmeJS3p1PaGoOPlp8D2/ynhn1Hi/0UWvGUN+okfUWexSTTf7mPg2F9sj8w 3NpRiLOzy99GGCmZvpp/uXKFZxDJ/VXaafSRH2Gn43eisibJsIITrAka7YuF+awa HF446X4gJqId7v5f+gKfqnLJ3yD7HtUJP43BPNDQEPUsil0eIhZgivcqd3uNW1JQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrudejgddugedvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffktgggufffjgfvfhfosegrtdhmrehhtddvnecuhfhrohhmpeetlhhishhs rgcuvehoohhpvghruceorghlihhsshgrsegtohhophgvrhifrdhinheqnecuffhomhgrih hnpehivghtfhdrohhrghenucfkphepudejfedrfeekrdduudejrdekjeenucfrrghrrghm pehmrghilhhfrhhomheprghlihhsshgrsegtohhophgvrhifrdhinhenucevlhhushhtvg hrufhiiigvpedt X-ME-Proxy: Received: from rtp-alcoop-nitro5.cisco.com (unknown [173.38.117.87]) by mail.messagingengine.com (Postfix) with ESMTPA id B8709E4210; Wed, 10 Apr 2019 15:41:53 -0400 (EDT) From: Alissa Cooper Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_6FB8BB17-2A7D-4F19-A87D-900762A6D02A" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Wed, 10 Apr 2019 15:41:51 -0400 In-Reply-To: Cc: gen-art , draft-ietf-manet-dlep-pause-extension.all@ietf.org, manet@ietf.org, ietf discussion list To: Lou Berger , Dale Worley References: <155313563193.14884.16784480436034023941@ietfa.amsl.com> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [manet] [Gen-art] Genart last call review of draft-ietf-manet-dlep-pause-extension-05 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2019 19:42:01 -0000 --Apple-Mail=_6FB8BB17-2A7D-4F19-A87D-900762A6D02A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Dale, thank you for your review. Lou, thanks for addressing the review = comments. I entered a DISCUSS ballot on a process point not raised here. Alissa > On Apr 3, 2019, at 10:38 PM, Lou Berger wrote: >=20 > Hi, >=20 > Thanks you for the comments, please see below. >=20 > On 3/20/2019 10:33 PM, Dale Worley via Datatracker wrote: >> Reviewer: Dale Worley >> Review result: Ready with Nits >>=20 >> I am the assigned Gen-ART reviewer for this draft. The General Area >> Review Team (Gen-ART) reviews all IETF documents being processed >> by the IESG for the IETF Chair. Please treat these comments just >> like any other last call comments. >>=20 >> For more information, please see the FAQ at >>=20 >> . >>=20 >> Document: draft-ietf-manet-dlep-pause-extension-05 >> Reviewer: Dale R. Worley >> Review Date: 2019-03-20 >> IETF LC End Date: 2019-04-03 >> IESG Telechat date: [not scheduled] >>=20 >> Summary: >>=20 >> This draft is basically ready for publication, but has nits >> that should be fixed before publication. There are a number = of >> issues with technical content, but they appear to stem from >> editorial issues, rather than being unsettled technical >> decisions. >>=20 >> * Technical issues: >>=20 >> I notice that the Pause Extension cannot be used by a router to tell = a >> modem to not send. I assume that the WG has considered this and has = a >> good reason for this asymmetry. >=20 > This is correct. It was deemed unneeded complexity for the typical = use case where modems have very narrow bandwidth available for = transmissions in comparison to other router attached links. >=20 >>=20 >> 3.1.1. Queue Parameter Sub Data Item >>=20 >> There need not be a Sub Data Item for a particular queue index. Such >> a queue has no declared size. OTOH, it has no DSCPs, and so no >> traffic can be sent for it, either. >>=20 >> Queue Parameter Sub Data Items are an unordered list composed of = sub >> data items with a common format. The first sub data item is = assigned >> a Queue Index value of 1, and subsequent data items are numbered >> incrementally. The format of the Queue Parameter Sub Data Item is >>=20 >> ... >>=20 >> Queue Index: >>=20 >> An 8-bit field indicating the queue index of the queue = parameter >> represented in the sub data item. >>=20 >> These passages are contradictory. Either the Sub Data Items are an >> ordered list and indexes are assigned to them sequentially, they are >> unordered and the indexes are given in the Queue Index subfield, or >> the Sub Data Items are required to be in order by their Queue Index >> fields. >=20 > Good catch - and you are correct. This is text wasn't modified when = we made ordering explicit. >=20 > The following will be removed: >=20 > The first sub data item is assigned > a Queue Index value of 1, and subsequent data items are numbered > incrementally. >=20 >=20 >> DS Field Qn: >>=20 >> The data item contains a sequence of 8 bit DS Fields. The >> position in the sequence identifies the associated queue index. >> The number of DS Fields present MUST equal the sum of all Num >> DSCPs field values. >>=20 >> This doesn't seem to match the defined format of the Sub Data Items. >> The "DS Field Qn" fields contain exactly as many DS Fields as the >> value of the Num DSCPs Qn field by definition. And all of them are >> associated with the one Queue Index in the Sub Data Item containing >> the DS Field Qn. >=20 > Same issue. Drop: >=20 > The > position in the sequence identifies the associated queue index. > =20 >> I note that the Sub Data Items are not padded to a multiple of 4 >> octets. I assume this is intended. >=20 > Correct, this is consistent with rfc8175. >=20 >=20 >>=20 >> 3.3. Restart >>=20 >> The sending of this data item parallels the Pause Data Item, see = the >> previous section, and follows the same rules. This includes that = to >> indicate that transmission can resume to all destinations, a modem >> MUST send the Restart Data Item in a Session Update Message. It = also >> includes that to indicate that transmission can resume to a >> particular destination a modem MUST send the Pause Restart Item in = a >> Destination Update Message. >>=20 >> Read literally, this means that there is a pause/transmit bit for = each >> destination/DSCP combination, and that the various messages (pause >> vs. restart * Session Update vs. Destination Update * queue index >> vs. 255) set some subset of the bits to "pause" or "transmit". This >> is opposed to the model where (to simplify) there is an overall >> pause/transmit bit for all traffic and an independent pause/transmit >> bit for each destination, and traffic may be sent for a destination >> only if both the overall bit and the destination bit are "transmit". >>=20 >> * Editorial issues: >>=20 >> 1. Introduction >>=20 >> The >> extension also optionally supports DSCP (differentiated services >> codepoint) aware, see [RFC2475], flow control. >>=20 >> The phrasing of this sentence is awkward because of the number of >> interpolated phrases. I suggest something like: >>=20 >> The extension also optionally supports flow control that is DSCP >> (differentiated services codepoint) aware (see [RFC2475]). >=20 > I'll break it into two sentences. >=20 >=20 >> Also, it seems that recent RFCs have tended to capitalize the phrase >> "Differentiated Services Code Point". (Probably check this point = with >> the Editor.) > I'll defer to the RFC editor. >> Note >> that this mechanism only controls traffic that is to be = transmitted >> on the modem's attached data channel and not to DLEP control = messages >> themselves. >>=20 >> The parallelism is not correct here, as it would read "this mechanism >> ... controls ... to DLEP". Perhaps change to: "this mechanism only >> applies to traffic ...". >=20 > Thanks! >=20 >=20 >> 2. Extension Usage and Identification >>=20 >> To indicate that the Control Plane Based Pause >> Extension is to be used, an implementation MUST include the = Control >> Plane Based Pause Extension Type Value in the Extensions Supported >> Data Item. >>=20 >> If I am reading RFC 8175 correctly, this is not exactly true. = Sending >> the Value does not compel the peer device to use the Extension. >> Instead, "To indicate that the implementation accepts use of the >> C.P.B.P.E., an implementation includes ...". >=20 > thanks, but will s/accepts/supports. >=20 >> 3. Extension Data Items >>=20 >> The Queue Parameters >> Data Item is used by a modem to provide information on the DSCPs = it >> uses in forwarding. >>=20 >> Suggest s/information on/information about/. To me, "information on >> the DSCPs" suggests that it will provide a listing of all the DSCPs >> that it uses, whereas "information about the DSCPs" suggests that it >> will provide attributes of some, but perhaps not all, of the DSCPs. >> (Section 3.1 makes clear that the Queue Parameters does not need to >> list all DSCPs that are used.) >=20 > Done! >=20 >=20 >>=20 >> 3.1. Queue Parameters >>=20 >> The Queue Parameters Data Item identifies DSCPs based on groups of >> logical queues, each of which is referred to via a "Queue Index". >>=20 >> "groups of logical queues" isn't correct. Suggest "The Queue >> Parameters Data Item groups DSCPs into logical queues, each of which >> is identified by a "Queue Index"." > I like it - thanks! >>=20 >> An implementation that does not support DSCPs would indicate 1 = queue >> with 0 DSCPs, and the number of bytes that may be in its = associated >> link transmit queue. >>=20 >> "with 0 DSCPs" is not really correct, since the Queue Parameter >> doesn't specify how many DSCPs are included in queue index 0, and >> traffic with all values of the DSCP field (which is unexamined by the >> device) will be in queue index 0. I think this phrase should be >> omitted. >=20 > I think it's cleaner to remove Q0 at this point, it too is a bit = vestigial and I think this highlights that having essentially two ways = to cover the >=20 >=20 >> Value Scale >> ------------ >> 0 B - Bytes (Octets) >> 1 KB - Kilobytes (B/1024) >> 2 MB - Megabytes (KB/1024) >> 3 GB - Gigabytes (MB/1024) >>=20 >> I would expect these items to be "1024 B", "1024 KB", etc. But >> perhaps that's because it is ambiguous whether "scale" means the = units >> in which the measurement is expressed, or the factor by which the >> measurement is multiplied by before it is reported. I would replace >> "scale" with "unit", which does not have that ambiguity. I would = also >> use the IEC abbreviations: >>=20 >> Value Unit >> ----------- >> 0 B - Bytes (Octets) >> 1 KiB - Kilobytes (1024 B) >> 2 MiB - Megabytes (1024 KiB) >> 3 GiB - Gigabytes (1024 GiB) >=20 > Sure. >=20 >=20 >> [ISQ-13] International Electrotechnical Commission, = "International >> Standard -- Quantities and units -- Part 13: = Information >> science and technology", IEC 80000-13, March 2008. >>=20 >> 3.2. Pause >>=20 >> The special value of 255 is used to >> indicate that all traffic is to be suppressed. >>=20 >> This implies that a queue index of 255 cannot be used, which is also >> implied by the fact that Num Queues =3D 255 means that only indexes 0 = to >> 254 are in use. It would be helpful to update 3.1 to make this more >> explicit: >>=20 >> Queue Indexes are numbered sequentially from zero to a maximum of >> 254, where queue index zero is a special case covering DSCPs which >> are not otherwise associated with Queue Index. (Value 255 is used >> to indicate "all queues".) > I'll add text that 255 MUST NOT be used in the Queue Index field. >>=20 >> -- >>=20 >> Queue Index: >>=20 >> ... The special value of 255 indicates >> all traffic is to be suppressed to the modem, when the data = item >> is carried in a Session Update Message, or a destination, when = the >> data item is carried in Destination Update Message. >>=20 >> The parallelism is awkward here. I think you want to explicitly >> parallel "traffic to the modem" and "traffic to a destination": > okay, will make them parallel. >> The special value of 255 indicates all traffic to the modem is >> to be suppressed, when the data item is carried in a Session >> Update Message, or all traffic to a destination, when the data >> item is carried in Destination Update Message. >>=20 >> 3.3. Restart >>=20 >> Finally, the same rules apply to queue indexes. >>=20 >> Probably better as "Queue indexes are interpreted in the same way as >> in the Pause Data Item." >=20 > Done. >=20 > Look for an update to be published shortly. >=20 > Thank you for the comments! >=20 > Lou >=20 >> [END] >>=20 >>=20 >>=20 >=20 > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art = --Apple-Mail=_6FB8BB17-2A7D-4F19-A87D-900762A6D02A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Dale,= thank you for your review. Lou, thanks for addressing the review = comments. I entered a DISCUSS ballot on a process point not raised = here.

Alissa

On Apr 3, 2019, at 10:38 PM, Lou Berger <lberger@labn.net> = wrote:

Hi,

Thanks you for the comments, = please see below.

On 3/20/2019 10:33 PM, Dale Worley via Datatracker = wrote:
Reviewer: Dale Worley
Review result: Ready with = Nits

I am the assigned Gen-ART reviewer for = this draft. The General Area
Review Team (Gen-ART) reviews = all IETF documents being processed
by the IESG for the = IETF Chair.  Please treat these comments just
like = any other last call comments.

For more = information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: =  draft-ietf-manet-dlep-pause-extension-05
Reviewer: =  Dale R. Worley
Review Date:  2019-03-20
IETF LC End Date:  2019-04-03
IESG = Telechat date:  [not scheduled]

Summary:

       This draft is = basically ready for publication, but has nits
       that should be = fixed before publication.  There are a number of
       issues with = technical content, but they appear to stem from
       editorial issues, = rather than being unsettled technical
       decisions.

* Technical issues:

I notice that the Pause Extension cannot be used by a router = to tell a
modem to not send.  I assume that the WG = has considered this and has a
good reason for this = asymmetry.

This is correct.  It was deemed unneeded complexity for = the typical use case where modems have very narrow bandwidth available = for transmissions in comparison to other router attached = links.


3.1.1.  Queue Parameter Sub Data Item

There need not be a Sub Data Item for a particular queue = index.  Such
a queue has no declared size. =  OTOH, it has no DSCPs, and so no
traffic can be sent = for it, either.

   Queue = Parameter Sub Data Items are an unordered list composed of sub
   data items with a common format.  The = first sub data item is assigned
   a Queue = Index value of 1, and subsequent data items are numbered
   incrementally.  The format of the = Queue Parameter Sub Data Item is

   ...

   Queue Index:

      An 8-bit field indicating = the queue index of the queue parameter
      represented in the sub = data item.

These passages are = contradictory.  Either the Sub Data Items are an
ordered list and indexes are assigned to them sequentially, = they are
unordered and the indexes are given in the Queue = Index subfield, or
the Sub Data Items are required to be = in order by their Queue Index
fields.

Good catch - and you are correct.  This is text wasn't = modified when we made ordering explicit.

The following will be removed:

  The first sub data item is assigned
  a Queue Index value = of 1, and subsequent data items are numbered
  incrementally.


   DS Field Qn:

      The data = item contains a sequence of 8 bit DS Fields.  The
      position in the sequence = identifies the associated queue index.
      The number of DS Fields = present MUST equal the sum of all Num
      DSCPs field values.

This doesn't seem to match the defined format = of the Sub Data Items.
The "DS Field Qn" fields contain = exactly as many DS Fields as the
value of the Num DSCPs Qn = field by definition.  And all of them are
associated = with the one Queue Index in the Sub Data Item containing
the= DS Field Qn.

Same issue.   Drop:

     The
     position in the sequence = identifies the associated queue index.
     
I note that the Sub Data Items are = not padded to a multiple of 4
octets.  I assume this = is intended.

Correct, this is consistent with rfc8175.



3.3.  Restart

   The sending of this data item parallels the = Pause Data Item, see the
   previous = section, and follows the same rules.  This includes that to
   indicate that transmission can resume to = all destinations, a modem
   MUST send the = Restart Data Item in a Session Update Message.  It also
   includes that to indicate that transmission = can resume to a
   particular destination a = modem MUST send the Pause Restart Item in a
   Destination Update Message.
Read literally, this means that there is a pause/transmit = bit for each
destination/DSCP combination, and that the = various messages (pause
vs. restart * Session Update vs. = Destination Update * queue index
vs. 255) set some subset = of the bits to "pause" or "transmit".  This
is = opposed to the model where (to simplify) there is an overall
pause/transmit bit for all traffic and an independent = pause/transmit
bit for each destination, and traffic may = be sent for a destination
only if both the overall bit and = the destination bit are "transmit".

* = Editorial issues:

1.  Introduction

   The
   extension also optionally supports DSCP = (differentiated services
   codepoint) = aware, see [RFC2475], flow control.

The = phrasing of this sentence is awkward because of the number of
interpolated phrases.  I suggest something like:

   The extension also = optionally supports flow control that is DSCP
   (differentiated services codepoint) aware = (see [RFC2475]).

I'll break it into two sentences.


Also, = it seems that recent RFCs have tended to capitalize the phrase
"Differentiated Services Code Point".  (Probably check = this point with
the Editor.)
I'll defer to the RFC editor.
   Note
   that this mechanism only controls traffic = that is to be transmitted
   on the modem's = attached data channel and not to DLEP control messages
   themselves.

The = parallelism is not correct here, as it would read "this mechanism
... controls ... to DLEP".  Perhaps change to: =  "this mechanism only
applies to traffic ...".

Thanks!


2.  Extension Usage and = Identification

   To = indicate that the Control Plane Based Pause
   Extension is to be used, an implementation = MUST include the Control
   Plane Based = Pause Extension Type Value in the Extensions Supported
   Data Item.

If = I am reading RFC 8175 correctly, this is not exactly true. =  Sending
the Value does not compel the peer device to = use the Extension.
Instead, "To indicate that the = implementation accepts use of the
C.P.B.P.E., an = implementation includes ...".

thanks, but will = s/accepts/supports.

3.  Extension Data Items

   The Queue Parameters
   Data Item is used by a modem to provide = information on the DSCPs it
   uses in = forwarding.

Suggest s/information = on/information about/.  To me, "information on
the = DSCPs" suggests that it will provide a listing of all the DSCPs
that it uses, whereas "information about the DSCPs" suggests = that it
will provide attributes of some, but perhaps not = all, of the DSCPs.
(Section 3.1 makes clear that the Queue = Parameters does not need to
list all DSCPs that are = used.)

Done!



3.1.  Queue = Parameters

   The Queue = Parameters Data Item identifies DSCPs based on groups of
   logical queues, each of which is referred = to via a "Queue Index".

"groups of logical = queues" isn't correct.  Suggest "The Queue
Parameters = Data Item groups DSCPs into logical queues, each of which
is= identified by a "Queue Index"."
I like it - thanks!

   An implementation that does not support = DSCPs would indicate 1 queue
   with 0 = DSCPs, and the number of bytes that may be in its associated
   link transmit queue.

"with 0 DSCPs" is not really correct, since the Queue = Parameter
doesn't specify how many DSCPs are included in = queue index 0, and
traffic with all values of the DSCP = field (which is unexamined by the
device) will be in queue = index 0.  I think this phrase should be
omitted.

I think it's cleaner to remove Q0 at this point, it too is a = bit vestigial and I think this highlights that having essentially two = ways to cover the


         Value =  Scale
         ---------= ---
          &nb= sp;  0   B - Bytes =     (Octets)
          &nb= sp;  1  KB - Kilobytes (B/1024)
          &nb= sp;  2  MB - Megabytes (KB/1024)
          &nb= sp;  3  GB - Gigabytes (MB/1024)

I would expect these items to be "1024 B", "1024 KB", etc. =  But
perhaps that's because it is ambiguous whether = "scale" means the units
in which the measurement is = expressed, or the factor by which the
measurement is = multiplied by before it is reported.  I would replace
"scale" with "unit", which does not have that ambiguity. =  I would also
use the IEC abbreviations:

         Value =  Unit
         ---------= --
          &nb= sp;  0    B - Bytes =     (Octets)
          &nb= sp;  1  KiB - Kilobytes (1024 B)
          &nb= sp;  2  MiB - Megabytes (1024 KiB)
          &nb= sp;  3  GiB - Gigabytes (1024 GiB)

Sure.


   [ISQ-13] =   International Electrotechnical Commission, "International
          &nb= sp;   Standard -- Quantities and units -- Part 13: = Information
          &nb= sp;   science and technology", IEC 80000-13, March = 2008.

3.2.  Pause

   The special value of 255 is used to
   indicate that all traffic is to be = suppressed.

This implies that a queue index = of 255 cannot be used, which is also
implied by the fact = that Num Queues =3D 255 means that only indexes 0 to
254 = are in use.  It would be helpful to update 3.1 to make this more
explicit:

   Queue = Indexes are numbered sequentially from zero to a maximum of
   254, where queue index zero is a special = case covering DSCPs which
   are not = otherwise associated with Queue Index.  (Value 255 is used
   to indicate "all queues".)
I'll add text that 255 MUST NOT be used in the Queue Index = field.

--

   Queue = Index:

      ...  The special = value of 255 indicates
      all traffic is to be = suppressed to the modem, when the data item
      is carried in a Session = Update Message, or a destination, when the
      data item is carried in = Destination Update Message.

The parallelism = is awkward here.  I think you want to explicitly
parallel "traffic to the modem" and "traffic to a = destination":
okay, will make them parallel.
      The= special value of 255 indicates all traffic to the modem is
      to be suppressed, when = the data item is carried in a Session
      Update Message, or all = traffic to a destination, when the data
      item is carried in = Destination Update Message.

3.3. =  Restart

   Finally, = the same rules apply to queue indexes.

Probably better as "Queue indexes are interpreted in the same = way as
in the Pause Data Item."

Done.

Look for an update to be published shortly.

Thank you for the = comments!

Lou

[END]




_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

= --Apple-Mail=_6FB8BB17-2A7D-4F19-A87D-900762A6D02A-- From nobody Wed Apr 10 13:36:39 2019 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 1735E12031A; Wed, 10 Apr 2019 13:36:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 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, 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 faNvTAvT8foM; Wed, 10 Apr 2019 13:36:35 -0700 (PDT) Received: from mail-oi1-x236.google.com (mail-oi1-x236.google.com [IPv6:2607:f8b0:4864:20::236]) (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 85A951200C3; Wed, 10 Apr 2019 13:36:35 -0700 (PDT) Received: by mail-oi1-x236.google.com with SMTP id e5so2994997oii.0; Wed, 10 Apr 2019 13:36:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=Azp5O1zJ6ocwW9ER79zfBoi/NCHjXKdfggqdKuWq4uA=; b=oEe+c+vjHTh0Jc5Pha6BEH7YUXAhQl0yjwMjudJfSJNbft9migvMdw91KyoSBabO3l uttyyKrzUdkGwkdycH1EibEOjJiC4Op+KfUtVYpQrZm3hsnijSfqPzv3r9woWlMMjv4F 7tBPRiJJzpIGFEY8y3LXHKs6MarjcnCY+CnbRSJRo+Q5su/PDDa4MKwS7hh1oBNSwhAY enENIYJ6DsxepI7rjEvNN4MdA9wLJJr6TNxX6Q8Es/VPOpVW0uIjj54Vl2YJSQziQmtV wJyc5XDY5DQcfdnf2WLSz4H+xOiyWDsxQQ/fdXgQf1TAQYqFqWEjEqeaygqZCtdUtbWk DREQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=Azp5O1zJ6ocwW9ER79zfBoi/NCHjXKdfggqdKuWq4uA=; b=XY1aYRkAwU3FTApIDSFkX14IWrpSl9KG1DFko01NVbtAZzDfBvNupiDOhiQZJD+WNn 4TLu6ztES7VwrU0Hl0yi//bH3ucwYysZJfvpQCy4451V0Hac+KO2mdmGZMXNKG73LoCi 1QGkMTntYA3ArAuQbqacs6wnCUZFYYsUY2oZfyWe5sKbH2vO3MPRfVT5kKfpVigMjhUn FXtCD8rmbm0az9bMI9NpxQuf03ADJfFMu3Uyqhx3Vr+v3rHfgeCW8kMTY19DuKRnbWNI ZNy3jz5hRAoshstH+TWfBp96FKIMijNyAi2MpuW2qVN70KPd0GbZFuN0RsUTY/T7SOz2 +C2A== X-Gm-Message-State: APjAAAV0oynCuz+J9b0LNr6h+qw68tEdw3dkU4HfdBeC0PeJ0kqgkYmc C7qOTGfVtgsK3aOx1kukzVaCJ+sxNDnapgjs+L0= X-Google-Smtp-Source: APXvYqy4X0Ta7kLK08MEfrwGCLpOdjoSKhY+LuSLR/+BcpuDNLt6UPz7KNtPHeprwOiFuDwVyQ5WhFVUKoucubjJd78= X-Received: by 2002:aca:ecd5:: with SMTP id k204mr3943344oih.53.1554928594843; Wed, 10 Apr 2019 13:36:34 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Wed, 10 Apr 2019 13:36:34 -0700 From: Alvaro Retana In-Reply-To: <155492518369.22601.15786320586524280536.idtracker@ietfa.amsl.com> References: <155492518369.22601.15786320586524280536.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Date: Wed, 10 Apr 2019 13:36:34 -0700 Message-ID: To: Alissa Cooper , The IESG Cc: Stan Ratliff , manet-chairs@ietf.org, draft-ietf-manet-dlep-pause-extension@ietf.org, manet@ietf.org Content-Type: multipart/alternative; boundary="0000000000008bfe6c058633064a" Archived-At: Subject: Re: [manet] Alissa Cooper's Discuss on draft-ietf-manet-dlep-pause-extension-06: (with DISCUSS and COMMENT) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2019 20:36:37 -0000 --0000000000008bfe6c058633064a Content-Type: text/plain; charset="UTF-8" On April 10, 2019 at 3:39:44 PM, Alissa Cooper via Datatracker ( noreply@ietf.org) wrote: Alissa: Hi! ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- This work item does not appear to be inside the scope of the MANET charter, at least based on my reading of the charter. Am I missing something? It is not explicitly called out. However, I believe it is part of the general development of DLEP, for which the WG is responsible. Alvaro. --0000000000008bfe6c058633064a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
On April 10, 2019 at 3:39:44 PM, Alissa Cooper via Data= tracker (noreply@ietf.org) wrote:

Alissa:
=

Hi!

-= ---------------------------------------------------------------------=C2=A0
DISCUSS:=C2=A0<= br style=3D"color:rgb(0,0,0);font-variant-caps:normal;letter-spacing:normal= ;text-align:start;text-indent:0px;text-transform:none;white-space:normal;wo= rd-spacing:0px">---------------------------------------------= -------------------------=C2=A0

This work item does= not appear to be inside the scope of the MANET charter, at=C2=A0
le= ast based on my reading of the charter. Am I missing something?=C2=A0

It is not explicitly called out.=C2= =A0 However, I believe it is part of the general development of DLEP, for w= hich the WG is responsible.

Alvaro.
--0000000000008bfe6c058633064a-- From nobody Wed Apr 10 14:40:46 2019 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 4357B120420; Wed, 10 Apr 2019 14:40:39 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Roman Danyliw via Datatracker To: "The IESG" Cc: draft-ietf-manet-dlep-pause-extension@ietf.org, Stan Ratliff , aretana.ietf@gmail.com, manet-chairs@ietf.org, sratliff@idirect.net, manet@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.95.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Roman Danyliw Message-ID: <155493243926.22516.16080901486479388697.idtracker@ietfa.amsl.com> Date: Wed, 10 Apr 2019 14:40:39 -0700 Archived-At: Subject: [manet] Roman Danyliw's Discuss on draft-ietf-manet-dlep-pause-extension-06: (with DISCUSS and COMMENT) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.29 List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2019 21:40:39 -0000 Roman Danyliw has entered the following ballot position for draft-ietf-manet-dlep-pause-extension-06: 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-pause-extension/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Unauthenticated shutdown of the network seems exceedingly dangerous. An expansion of the implementation scenarios described in Section 4 of RFC8175 and the architecture laid out in Figure 1 of RFC8175 appears to be: (a) single direct connect (1x modem + 1x router) (b) single dedicated switch (1x modem + 1x switch + 1x router) (c) multiple connect (>1x modem + >=0 switches + 1x router) (d) mobile environment (>=1x modem + switch + router + other devices in the switch) (e) networked deployment (as stated in RFC8175/anything more complicated) I believe that the safest thing is that using TLS with this extension should be a MUST. If that is problematic, then I’d only soften it to (text that amounts to) “in environments and deployment scenarios (a) and (b), TLS SHOULD be used. In all other environments, TLS MUST be used.” Warren: I believe that your neighbor scenario is likely scenario (c). As the current security considerations say, using TLS in scenario (a) won’t help if the modem gets compromised. In the above recommendation, there is an assumption that the switch(s) isn’t compromised (and that should be documented). ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- (0) I support Warren and Magnus’s DISCUSS positions. (1) Section 3.1. Per the Query Parameters data item, what is the router behavior when it receives: ** Num Queues = 0 ** Num Queues <> the queues sent? (2) Section 3.1. Nit. The size of the Reserved field is not indicated in the text (like the other fields) (3) Section 3.1.1, Please provide a section reference into RFC8175 on error parsing. (4) Section 3.2 Per “Each Pause Data Item identifies the traffic to be suppressed by the Queue Index defined by Section 3.1”, am I reading it right that a Queue Parameter Data Item needs to be sent before a Pause is sent? If so, I’m not sure that is said anywhere and should be. Furthermore, how does a router behave if it does get a Pause message prior to getting a Parameter Data Item message? (5) Section 3.3 Related to comment-4, How does a router behave if it gets a Restart message prior to getting a Parameter Data Item or Pause message? From nobody Wed Apr 10 15:10:11 2019 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 4AC531201BC; Wed, 10 Apr 2019 15:10:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Adam Roach via Datatracker To: "The IESG" Cc: draft-ietf-manet-dlep-pause-extension@ietf.org, Stan Ratliff , aretana.ietf@gmail.com, manet-chairs@ietf.org, sratliff@idirect.net, manet@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.95.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Adam Roach Message-ID: <155493420330.22720.6186640431890716184.idtracker@ietfa.amsl.com> Date: Wed, 10 Apr 2019 15:10:03 -0700 Archived-At: Subject: [manet] Adam Roach's No Objection on draft-ietf-manet-dlep-pause-extension-06: (with COMMENT) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.29 List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2019 22:10:03 -0000 Adam Roach has entered the following ballot position for draft-ietf-manet-dlep-pause-extension-06: No Objection 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-pause-extension/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks to everyone who worked on this document. I share Roman and Warren's concerns about authentication of pause messages. --------------------------------------------------------------------------- §3.2: > particular threshold. Other use cases are possible, e.g., when there > a non queue related congestion points within a modem, but such are Nit: I can't quite parse the "when there a non queue" part of this. From nobody Wed Apr 10 17:42:38 2019 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 D2BFD1205CF for ; Wed, 10 Apr 2019 17:42:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.554 X-Spam-Level: X-Spam-Status: No, score=-0.554 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_BL_SPAMCOP_NET=1.347, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 fL_r5Da-omnT for ; Wed, 10 Apr 2019 17:42:29 -0700 (PDT) Received: from gproxy4-pub.mail.unifiedlayer.com (gproxy4-pub.mail.unifiedlayer.com [69.89.23.142]) (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 7A1BD12046D for ; Wed, 10 Apr 2019 17:42:27 -0700 (PDT) Received: from CMGW (unknown [10.9.0.13]) by gproxy4.mail.unifiedlayer.com (Postfix) with ESMTP id 36D08176677 for ; Wed, 10 Apr 2019 18:17:52 -0600 (MDT) Received: from box313.bluehost.com ([69.89.31.113]) by cmsmtp with ESMTP id ENPchQIEteyBxENPchtE3W; Wed, 10 Apr 2019 18:17:52 -0600 X-Authority-Reason: nr=8 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:References:Cc: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=6NAgBI4jHBO4TZQBzZIKq0sca4kh+gurfclgVzgsZV0=; b=jMIyYy30pHwaQIakDtnZMhiwry XGpbTotC42hYS5z9eb9Y8owvCBNYuNvZtzi5ot4GhgETaPb/d5pjXt7zAFkyhVIE4BIAUKtRHeeUZ NimycUYcSVjGMZXOJEyeEVfj7; Received: from pool-72-66-11-201.washdc.fios.verizon.net ([72.66.11.201]:48280 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from ) id 1hENPb-000OzO-QC; Wed, 10 Apr 2019 18:17:51 -0600 To: Bob Briscoe , tsv-art@ietf.org Cc: draft-ietf-manet-dlep-pause-extension.all@ietf.org, manet@ietf.org, ietf@ietf.org References: <155442219204.31004.18308454286183143947@ietfa.amsl.com> From: Lou Berger Message-ID: Date: Wed, 10 Apr 2019 20:17:51 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.1 MIME-Version: 1.0 In-Reply-To: <155442219204.31004.18308454286183143947@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US 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: 72.66.11.201 X-Source-L: No X-Exim-ID: 1hENPb-000OzO-QC X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-72-66-11-201.washdc.fios.verizon.net ([IPv6:::1]) [72.66.11.201]:48280 X-Source-Auth: lberger@labn.net X-Email-Count: 4 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== X-Local-Domain: yes Archived-At: Subject: Re: [manet] Tsvart last call review of draft-ietf-manet-dlep-pause-extension-06 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2019 00:42:37 -0000 Bob, Thanks for the comments - see below for responses. On 4/4/2019 7:56 PM, Bob Briscoe via Datatracker wrote: > Reviewer: Bob Briscoe > Review result: On the Right Track > > This document has been reviewed as part of the transport area review team's > ongoing effort to review key IETF documents. These comments were written > primarily for the transport area directors, but are copied to the document's > authors and WG to allow them to address any issues raised and also to the IETF > discussion list for information. > > When done at the time of IETF Last Call, the authors should consider this > review as part of the last-call comments they receive. Please always CC > tsv-art@ietf.org if you reply to or forward this review. > > ==1. Introduction== > > It would be useful to describe the use-case where the modem does not implement > active queue management but the router does, so the modem can use flow control > to push the queue back into the router, where it can be more intelligently > controlled. I guess I'll have to talk to the Shepherd on this one to see how much he/the WG would want to add on this at this point.  Perhaps giving a reference to the earlier PPPOE (rfc5578) would suffice, what do you think? > > ===Scope within Intro=== > Please extend the single sentence about scope (end of 2nd para of Intro) to > explain that pause control only applies to data in the router to modem > direction. > > Please also mention that the scope of pause-based flow control is limited to > one hop and to a point-to-point link between router and modem, not multipoint. > The modem does not track the source of the data in its queue, so it cannot > focus pause messages onto particular sending stations on a multipoint link, or > onto particular ingress ports of the router. Done. > > Why is the scope limited to DLEP radio links? I would have thought this > protocol is generally useful between a and modem and router. Because this is a DLEP extension.  Other mechanisms exist for other technologies, e.g., RFC5578 or Ethernet PAUSE/PFC. > ==3. Extension Data Items== > > Pls define the direction of the messages: > s/The xxx Data Item is used by a modem to.../ > /A modem sends the xxx Data Item to its peer router to.../ okay (paraphrase a bit) > > ===Unsafe design?=== > Is it not good practice to make the data plane robust to unexpected control > plane failures (e.g. key expiry, incorrect or mis-timed change of address, > etc.) and vice versa? So, would it not be more robust for the router to > time-out a pause if no restart appears? Also, if the last message received > before shutting down or suspending was a pause, should the router restart or > resume in the paused state? What if the router enters a power-saving state > after it is paused and misses a restart message? I generally agree that a control plane fault should not result in a data plane loss -- in some environments, I'd say this is a must.  This said, your comment goes to a design principle in DLEP RFC8175 where control plane error result in session resets and data plane impacts.  I think changing this basic behavior of DLEP is beyond the scope of this extension.  I think a general modification of base DLEP to support such would be a fine idea. > > ==Queue size in bytes for informational purposes?== > Why? This strikes me as like one of those Government forms you have to fill in > with an ill-formed question that is mandatory to answer, even though sometimes > there is no answer, and you cannot proceed until you've answered, even though > the answer is not needed anyway. For instance, if there is a shared physical > buffer, a size cannot be straightforwardly given for each logical buffer. So, > if buffer size info is not used by the protocol, do not include it in the > protocol. It is largely for reporting to a user/operator for "informational purposes".  If an implementation chooses, it can put in zero or infinity.  In most cases I understand this will be a straightforward value that can be reported to the router and its operators. > On the other hand, how is the threshold at which the modem sends a pause > configured. Is that out of scope? If so, where is it specified? Wherever this > is specified, it should be possible to specify the threshold in time units > (queue delay at the current service rate of the queue), not just in bytes. This > is important for queues in a hierarchy where the service rate varies, e.g. > dependent on traffic in another queue with priority over it. Or simply where > the modem can operate at different rates. I think a service rate / queue delay property would be very interesting - but this didn't come up in the WG, so I don't think it is appropriate to add it here.  There is also nothing preventing such information being added in a future extension. > > ==3.3 Restart== > > "A router which receives the Restart Data Item SHOULD resume > transmission of the identified traffic to the modem." > > Why only SHOULD? Under what conditions would it not? if it has no data to send. I don't object changing this to a MUST if you think important. > ==4. Security Considerations== > > "The extension does not inherently > introduce any additional vulnerabilities above those documented in > [RFC8175]." > > Er, no... What about the ability for an off-path attacker to stop the router > sending data!? the same attacker can subvert the dlep session an cause a session reset and take down all traffic.  So how is this case different? > The last part about TLS needs to be worded differently. Because of the above > additional vulnerability, the router MUST verify that all 3 types of message > are authenticated by the modem. This requires client authentication mode of > TLS, which is not mentioned in RFC8175, so it needs to be mentioned here. Or > is the TLS session set up by the router (so the modem is the authenticated > server)? Also this raises the question of key management, if every modem has to > be authenticated by its router. > > "but this is not a > substantively different attack by such a compromised modem simply > dropping all traffic destined to, or sent by a router." > > Er, no... The modem does not need to be compromised for a 3rd party to send > spoof messages purporting to be from the modem. Fair point - how about:   Note that this extension does allow a compromised or impersonating   modem to suppress transmission by the router.  Similar attacks are   generally possible base DLEP, for example an impersonating modem may   cause a session reset or a compromised modem simply can   drop all traffic destined to, or sent by a router.  defines the use of TLS to protect against the   impersonating attacker. > > ==Nits== > > 1. Intro > "DLEP peers are comprised of a modem and a router" is incorrect English for > what you mean (it means that each peer consists of a modem and a router). > Better to do away with this sentence completely, and alter to the previous > sentence to "It provides the exchange of link related control information > between a modem and its DLEP peer router." sure. > 3.1 > s/with Queue Index/ > /with a Queue Index/ okay > Scale: > s/An 4-bit/ > /A 4-bit/ okay > In general, I think the term "queue size" is wrongly being used where "buffer > size" should be used (the queue size is the varying size of the queue within > the buffer at any one time). > > Also, pls consistently use the term 'paused' not 'suppressed', which has the > potentially ambiguous meaning of 'discarded'. will clarify the intent. > Delete gratuitous 'is': > "The motivating use case [is] for this > data item is when a modem's internal queue length exceeds a > particular threshold." yes, > > CURRENT: > "e.g., when there > a non queue related congestion points within a modem, but such are > not explicitly described in this document." > SUGGESTED: > "e.g., when there > are non queue related congestion points within a modem. Such use-cases are > not explicitly described in this document." > > Done! Thank you for the comments. Lou PS the working document has been updated, if interested see https://github.com/louberger/dlep-extensions/tree/master/pause > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > From nobody Wed Apr 10 18:01:07 2019 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 EC057120125; Wed, 10 Apr 2019 18:00:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benjamin Kaduk via Datatracker To: "The IESG" Cc: draft-ietf-manet-dlep-pause-extension@ietf.org, Stan Ratliff , aretana.ietf@gmail.com, manet-chairs@ietf.org, sratliff@idirect.net, manet@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.95.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Benjamin Kaduk Message-ID: <155494445891.22757.7399588752085896470.idtracker@ietfa.amsl.com> Date: Wed, 10 Apr 2019 18:00:58 -0700 Archived-At: Subject: [manet] Benjamin Kaduk's Discuss on draft-ietf-manet-dlep-pause-extension-06: (with DISCUSS and COMMENT) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.29 List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2019 01:00:59 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-manet-dlep-pause-extension-06: 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-pause-extension/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Section 3.1 defines 'Scale' as a four-bit unsigned integer field but only the values 0-3 are assigned, leaving 4-16k usable. How will future values be assigned? In Section 3.1.1: DS Field Qn: The data item contains a sequence of 8 bit DS Fields. The number of DS Fields present MUST equal the sum of all Num DSCPs field values. Perhaps I'm misreading, but I thought the Num DSCPs Qn field was global for this queue index, so there would just be one of them and no need to take a sum. In Section 3.3: A router which receives the Restart Data Item SHOULD resume transmission of the identified traffic to the modem. Why is this only a "SHOULD"? Section 4 The extension does not inherently introduce any additional vulnerabilities above those documented in [RFC8175]. [...] As noted by others, this sentence is just not true. I will not duplicate the suggestions for additional considerations that need to be documented. In particular, I agree with Roman that the use of TLS needs to be mandatory, especially since this protocol is nominally only defined for use with radio links. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Section 3.1 Any errors or inconsistencies encountered in parsing Sub Data Items are handled in the same fashion as any other Data Item parsing error encountered in DLEP. I had a hard time finding the indicated behavior in RFC 8175 -- "error" does not appear at all (and "erroneous" only twice, for IP address processing, v4 and v6); "parse" only appears once (in the Session Initialization State); "inconsistent" apprears several times but I did not see one that seemed to be a generic catch-all case. It's probably worth putting in a section reference or changing the text to use keywords that are searchable in RFC 8175. Section 3.1.1 Queue Size Qn: A 24-bit unsigned integer representing the size, in the octet scale indicated by the Scale field, of the queue supporting traffic with the DSCPs associated with the queue index. Is there any value in including a specific sentinel value that indicates that the modem cannot or does not wish to state the size of the corresponding queue? Section 3.2 A router which receives the Pause Data Item MUST cease sending the identified traffic to the modem. This may of course translate into the router's queues exceeding their own thresholds. If a received Pause Data Item contains a Queue Index value other than 255, or a queue index established by a Session Initialization or Session Update Message, the router MUST terminate the session with a Status Data Item indicating Invalid Data. This would be a nit, but actually has serious functional consequences: remove the comma after "255". The current text says that if the router receives a queue index established by a Session Initialization message, the router MUST terminate the session, which does not seem to be the intent! Section 3.3 The Restart Data Item is used by a modem to indicate to its peer that transmission of previously suppressed traffic may be resumed. An example of when a modem might send this data item is when an internal queue length drops below a particular threshold. This seems like a fine place to suggest the application of hysteresis (i.e., that the "particular threshold" here might be lower than the one indicated in Section 3.2). Section 5.x It's not clear to me what value there is in repeating the registration policy of the registries from which codepoints are being allocated. IANA will apply the correct policy, and the reader of this document doesn't need to care what policy was applied. From nobody Wed Apr 10 19:25:27 2019 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 298AF12000F; Wed, 10 Apr 2019 19:25:19 -0700 (PDT) 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, RCVD_IN_DNSWL_NONE=-0.0001, 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 0qfDnBWL6twU; Wed, 10 Apr 2019 19:25:15 -0700 (PDT) Received: from mail-qt1-x82b.google.com (mail-qt1-x82b.google.com [IPv6:2607:f8b0:4864:20::82b]) (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 87B34120003; Wed, 10 Apr 2019 19:25:15 -0700 (PDT) Received: by mail-qt1-x82b.google.com with SMTP id v32so5350118qtc.10; Wed, 10 Apr 2019 19:25:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=X7UyIxyff5XqAUvuruLsSjfRMAQ1SEFh6xbtDIRpUzo=; b=lv4eTu/CF5780w4688xaijJumTt3MEko1F+YXwMQ4cVO+lpBuGaqf/uK+E1C243Ii8 zvuDBE3lBVF4dJzjlnEQk9In6j2nNPZ9CuUJxiFWeXOJgTlLsrwQppKp+e9BLtgZLwl4 73q/gMM4co8W3mO6dPJRSfKl0J+Qej3vGLBidtN+SgVrvkvDIFTBDqB77nS18/qNen8/ 2NxMF1K3Xk4YuMvb65iqJTTvMKP4vQyCc+7HnSS7igKioasz8a29n24DdNggdmoc8Gmj xN2S9gjKXdumKXzbJ/CPAqODa+BMTzr73ZZ3tKOtLoqTvHy7ij4dbyxR46/aLEv2DcI+ XoXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=X7UyIxyff5XqAUvuruLsSjfRMAQ1SEFh6xbtDIRpUzo=; b=WPPbYKdTDSSJGHb4p2ZA2Y/loeIaenLZo+0lI1t/3ZhjeXD0NjBhcEOY5xnRpbMQFO tRRsY3McwOeJEXtFN/JuA8BV+ECOxK53eS0YbvaMYCrK3oPpWALn2bDGJivqBHQhdOYu BO7A1Ly7TO9nSF25dEtVuGQS5ZunhgdB24hW+U3vdfw0Dr0PmQZThXFK0rX32b4TlTo4 Q7ofL+bMAxpNcfJKXyS9fK1EJyPq9BEMTjC0FjTYIhXy6KgC4iIvBe81TCAiL0VWl2Ei KZVcE9jAEW3JrWQJmt1EID5t+gvY1914gghhnkLAdID8zRp1WxknVoJxQFAgfDhBzdV9 DLIQ== X-Gm-Message-State: APjAAAXjet27SMWu9Nzmedgoy7pbV093kMtQg83wOYzNN9klEhJcJl0m MfFlfBB7eCSHeggz7dqikD5YTyMnT774Fp3gX7A= X-Google-Smtp-Source: APXvYqz8OiCM3zsq7pGMXC1MIRWt58eOHsxfNDvTJzyVF4PaSp508h38HSuhhBNNyG+zPTuLZf3R9oHlrPx2ZiL6j54= X-Received: by 2002:ac8:f3c:: with SMTP id e57mr37097253qtk.75.1554949514572; Wed, 10 Apr 2019 19:25:14 -0700 (PDT) MIME-Version: 1.0 References: <155442219204.31004.18308454286183143947@ietfa.amsl.com> In-Reply-To: From: Justin Dean Date: Wed, 10 Apr 2019 22:25:00 -0400 Message-ID: To: Lou Berger Cc: Bob Briscoe , draft-ietf-manet-dlep-pause-extension.all@ietf.org, ietf@ietf.org, manet@ietf.org, tsv-art@ietf.org Content-Type: multipart/alternative; boundary="00000000000075b6b8058637e519" Archived-At: Subject: Re: [manet] Tsvart last call review of draft-ietf-manet-dlep-pause-extension-06 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2019 02:25:19 -0000 --00000000000075b6b8058637e519 Content-Type: text/plain; charset="UTF-8" A few comments inline marked JD, Justin Dean WG chair. On Wed, Apr 10, 2019, 8:41 PM Lou Berger wrote: > Bob, > > Thanks for the comments - see below for responses. > > On 4/4/2019 7:56 PM, Bob Briscoe via Datatracker wrote: > > Reviewer: Bob Briscoe > > Review result: On the Right Track > > > > This document has been reviewed as part of the transport area review > team's > > ongoing effort to review key IETF documents. These comments were written > > primarily for the transport area directors, but are copied to the > document's > > authors and WG to allow them to address any issues raised and also to > the IETF > > discussion list for information. > > > > When done at the time of IETF Last Call, the authors should consider this > > review as part of the last-call comments they receive. Please always CC > > tsv-art@ietf.org if you reply to or forward this review. > > > > ==1. Introduction== > > > > It would be useful to describe the use-case where the modem does not > implement > > active queue management but the router does, so the modem can use flow > control > > to push the queue back into the router, where it can be more > intelligently > > controlled. > > I guess I'll have to talk to the Shepherd on this one to see how much > he/the WG would want to add on this at this point. Perhaps giving a > reference to the earlier PPPOE (rfc5578) would suffice, what do you think? > JD will talk with Lou and respond in separate email. > > > > > > ===Scope within Intro=== > > Please extend the single sentence about scope (end of 2nd para of Intro) > to > > explain that pause control only applies to data in the router to modem > > direction. > > > > Please also mention that the scope of pause-based flow control is > limited to > > one hop and to a point-to-point link between router and modem, not > multipoint. > > The modem does not track the source of the data in its queue, so it > cannot > > focus pause messages onto particular sending stations on a multipoint > link, or > > onto particular ingress ports of the router. > > Done. > > > > > Why is the scope limited to DLEP radio links? I would have thought this > > protocol is generally useful between a and modem and router. > > Because this is a DLEP extension. Other mechanisms exist for other > technologies, e.g., RFC5578 or Ethernet PAUSE/PFC. > > > > ==3. Extension Data Items== > > > > Pls define the direction of the messages: > > s/The xxx Data Item is used by a modem to.../ > > /A modem sends the xxx Data Item to its peer router to.../ > okay (paraphrase a bit) > > > > ===Unsafe design?=== > > Is it not good practice to make the data plane robust to unexpected > control > > plane failures (e.g. key expiry, incorrect or mis-timed change of > address, > > etc.) and vice versa? So, would it not be more robust for the router to > > time-out a pause if no restart appears? Also, if the last message > received > > before shutting down or suspending was a pause, should the router > restart or > > resume in the paused state? What if the router enters a power-saving > state > > after it is paused and misses a restart message? > > I generally agree that a control plane fault should not result in a data > plane loss -- in some environments, I'd say this is a must. This said, > your comment goes to a design principle in DLEP RFC8175 where control > plane error result in session resets and data plane impacts. I think > changing this basic behavior of DLEP is beyond the scope of this > extension. I think a general modification of base DLEP to support such > would be a fine idea. > JD there may be more robust and clever solutions here that don't break the base specification. Absence of an acknowledgement is not the same as an error, syntax or otherwise, which causes a reset. Allowing for a periodic restart message if data does not resume may be sufficient. > > > > > > ==Queue size in bytes for informational purposes?== > > Why? This strikes me as like one of those Government forms you have to > fill in > > with an ill-formed question that is mandatory to answer, even though > sometimes > > there is no answer, and you cannot proceed until you've answered, even > though > > the answer is not needed anyway. For instance, if there is a shared > physical > > buffer, a size cannot be straightforwardly given for each logical > buffer. So, > > if buffer size info is not used by the protocol, do not include it in the > > protocol. > It is largely for reporting to a user/operator for "informational > purposes". If an implementation chooses, it can put in zero or > infinity. In most cases I understand this will be a straightforward > value that can be reported to the router and its operators. > > On the other hand, how is the threshold at which the modem sends a pause > > configured. Is that out of scope? If so, where is it specified? Wherever > this > > is specified, it should be possible to specify the threshold in time > units > > (queue delay at the current service rate of the queue), not just in > bytes. This > > is important for queues in a hierarchy where the service rate varies, > e.g. > > dependent on traffic in another queue with priority over it. Or simply > where > > the modem can operate at different rates. > > I think a service rate / queue delay property would be very interesting > - but this didn't come up in the WG, so I don't think it is appropriate > to add it here. There is also nothing preventing such information being > added in a future extension. > > > > > > ==3.3 Restart== > > > > "A router which receives the Restart Data Item SHOULD resume > > transmission of the identified traffic to the modem." > > > > Why only SHOULD? Under what conditions would it not? > > if it has no data to send. I don't object changing this to a MUST if you > think important. > > > JD I actually think this should be a MAY but with added text explaining why data may not be sent to the modem. No data, better external links, other. > > > ==4. Security Considerations== > > > > "The extension does not inherently > > introduce any additional vulnerabilities above those documented in > > [RFC8175]." > > > > Er, no... What about the ability for an off-path attacker to stop the > router > > sending data!? > > the same attacker can subvert the dlep session an cause a session reset > and take down all traffic. So how is this case different? > > > The last part about TLS needs to be worded differently. Because of the > above > > additional vulnerability, the router MUST verify that all 3 types of > message > > are authenticated by the modem. This requires client authentication mode > of > > TLS, which is not mentioned in RFC8175, so it needs to be mentioned > here. Or > > is the TLS session set up by the router (so the modem is the > authenticated > > server)? Also this raises the question of key management, if every modem > has to > > be authenticated by its router. > > > > "but this is not a > > substantively different attack by such a compromised modem simply > > dropping all traffic destined to, or sent by a router." > > > > Er, no... The modem does not need to be compromised for a 3rd party to > send > > spoof messages purporting to be from the modem. > > Fair point - how about: > > > Note that this extension does allow a compromised or impersonating > modem to suppress transmission by the router. Similar attacks are > generally possible base DLEP, for example an impersonating modem may > cause a session reset or a compromised modem simply can > drop all traffic destined to, or sent by a router. target="RFC8175"/> defines the use of TLS to protect against the > impersonating attacker. > > > > > > ==Nits== > > > > 1. Intro > > "DLEP peers are comprised of a modem and a router" is incorrect English > for > > what you mean (it means that each peer consists of a modem and a router). > > Better to do away with this sentence completely, and alter to the > previous > > sentence to "It provides the exchange of link related control information > > between a modem and its DLEP peer router." > > sure. > > > > 3.1 > > s/with Queue Index/ > > /with a Queue Index/ > > okay > > > Scale: > > s/An 4-bit/ > > /A 4-bit/ > okay > > In general, I think the term "queue size" is wrongly being used where > "buffer > > size" should be used (the queue size is the varying size of the queue > within > > the buffer at any one time). > > > > Also, pls consistently use the term 'paused' not 'suppressed', which has > the > > potentially ambiguous meaning of 'discarded'. > > will clarify the intent. > > > > Delete gratuitous 'is': > > "The motivating use case [is] for this > > data item is when a modem's internal queue length exceeds a > > particular threshold." > yes, > > > > CURRENT: > > "e.g., when there > > a non queue related congestion points within a modem, but such are > > not explicitly described in this document." > > SUGGESTED: > > "e.g., when there > > are non queue related congestion points within a modem. Such > use-cases are > > not explicitly described in this document." > > > > > Done! > > Thank you for the comments. > > Lou > > PS the working document has been updated, if interested see > https://github.com/louberger/dlep-extensions/tree/master/pause > > > _______________________________________________ > > manet mailing list > > manet@ietf.org > > https://www.ietf.org/mailman/listinfo/manet > > > --00000000000075b6b8058637e519 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable A few comments inline marked JD, Justin Dean WG chair.
On Wed, Apr 10, 2019, 8:41 PM Lou Berger <lberger@labn.net> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">Bob,

Thanks for the comments - see below for responses.

On 4/4/2019 7:56 PM, Bob Briscoe via Datatracker wrote:
> Reviewer: Bob Briscoe
> Review result: On the Right Track
>
> This document has been reviewed as part of the transport area review t= eam's
> ongoing effort to review key IETF documents. These comments were writt= en
> primarily for the transport area directors, but are copied to the docu= ment's
> authors and WG to allow them to address any issues raised and also to = the IETF
> discussion list for information.
>
> When done at the time of IETF Last Call, the authors should consider t= his
> review as part of the last-call comments they receive. Please always C= C
> tsv-art@ietf.org= if you reply to or forward this review.
>
> =3D=3D1. Introduction=3D=3D
>
> It would be useful to describe the use-case where the modem does not i= mplement
> active queue management but the router does, so the modem can use flow= control
> to push the queue back into the router, where it can be more intellige= ntly
> controlled.

I guess I'll have to talk to the Shepherd on this one to see how much <= br> he/the WG would want to add on this at this point.=C2=A0 Perhaps giving a <= br> reference to the earlier PPPOE (rfc5578) would suffice, what do you think?<= br>
JD will talk with Lou and respond in separate em= ail.


>
> =3D=3D=3DScope within Intro=3D=3D=3D
> Please extend the single sentence about scope (end of 2nd para of Intr= o) to
> explain that pause control only applies to data in the router to modem=
> direction.
>
> Please also mention that the scope of pause-based flow control is limi= ted to
> one hop and to a point-to-point link between router and modem, not mul= tipoint.
> The modem does not track the source of the data in its queue, so it ca= nnot
> focus pause messages onto particular sending stations on a multipoint = link, or
> onto particular ingress ports of the router.

Done.

>
> Why is the scope limited to DLEP radio links? I would have thought thi= s
> protocol is generally useful between a and modem and router.

Because this is a DLEP extension.=C2=A0 Other mechanisms exist for other technologies, e.g., RFC5578 or Ethernet PAUSE/PFC.


> =3D=3D3. Extension Data Items=3D=3D
>
> Pls define the direction of the messages:
> s/The xxx Data Item is used by a modem to.../
>=C2=A0 =C2=A0/A modem sends the xxx Data Item to its peer router to.../=
okay (paraphrase a bit)
>
> =3D=3D=3DUnsafe design?=3D=3D=3D
> Is it not good practice to make the data plane robust to unexpected co= ntrol
> plane failures (e.g. key expiry, incorrect or mis-timed change of addr= ess,
> etc.) and vice versa? So, would it not be more robust for the router t= o
> time-out a pause if no restart appears? Also, if the last message rece= ived
> before shutting down or suspending was a pause, should the router rest= art or
> resume in the paused state? What if the router enters a power-saving s= tate
> after it is paused and misses a restart message?

I generally agree that a control plane fault should not result in a data plane loss -- in some environments, I'd say this is a must.=C2=A0 This = said,
your comment goes to a design principle in DLEP RFC8175 where control
plane error result in session resets and data plane impacts.=C2=A0 I think =
changing this basic behavior of DLEP is beyond the scope of this
extension.=C2=A0 I think a general modification of base DLEP to support suc= h
would be a fine idea.

JD there = may be more robust and clever solutions here that don't break the base = specification. Absence of an acknowledgement is not the same as an error, s= yntax or otherwise, which causes a reset. Allowing for a periodic restart m= essage if data does not resume may be sufficient.


>
> =3D=3DQueue size in bytes for informational purposes?=3D=3D
> Why? This strikes me as like one of those Government forms you have to= fill in
> with an ill-formed question that is mandatory to answer, even though s= ometimes
> there is no answer, and you cannot proceed until you've answered, = even though
> the answer is not needed anyway. For instance, if there is a shared ph= ysical
> buffer, a size cannot be straightforwardly given for each logical buff= er. So,
> if buffer size info is not used by the protocol, do not include it in = the
> protocol.
It is largely for reporting to a user/operator for "informational
purposes".=C2=A0 If an implementation chooses, it can put in zero or <= br> infinity.=C2=A0 In most cases I understand this will be a straightforward <= br> value that can be reported to the router and its operators.
> On the other hand, how is the threshold at which the modem sends a pau= se
> configured. Is that out of scope? If so, where is it specified? Wherev= er this
> is specified, it should be possible to specify the threshold in time u= nits
> (queue delay at the current service rate of the queue), not just in by= tes. This
> is important for queues in a hierarchy where the service rate varies, = e.g.
> dependent on traffic in another queue with priority over it. Or simply= where
> the modem can operate at different rates.

I think a service rate / queue delay property would be very interesting - but this didn't come up in the WG, so I don't think it is appropr= iate
to add it here.=C2=A0 There is also nothing preventing such information bei= ng
added in a future extension.


>
> =3D=3D3.3 Restart=3D=3D
>
>=C2=A0 =C2=A0 "A router which receives the Restart Data Item SHOUL= D resume
>=C2=A0 =C2=A0 =C2=A0transmission of the identified traffic to the modem= ."
>
> Why only SHOULD? Under what conditions would it not?

if it has no data to send. I don't object changing this to a MUST if yo= u
think important.


JD I actually think this should be a MAY bu= t with added text explaining why data may not be sent to the modem. No data= , better external links, other.

<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex"> > =3D=3D4. Security Considerations=3D=3D
>
>=C2=A0 =C2=A0 "The extension does not inherently
>=C2=A0 =C2=A0 =C2=A0introduce any additional vulnerabilities above thos= e documented in
>=C2=A0 =C2=A0 =C2=A0[RFC8175]."
>
> Er, no... What about the ability for an off-path attacker to stop the = router
> sending data!?

the same attacker can subvert the dlep session an cause a session reset and take down all traffic.=C2=A0 So how is this case different?

> The last part about TLS needs to be worded differently. Because of the= above
> additional vulnerability, the router MUST verify that all 3 types of m= essage
> are authenticated by the modem. This requires client authentication mo= de of
> TLS, which is not mentioned in RFC8175, so it needs to be mentioned he= re.=C2=A0 Or
> is the TLS session set up by the router (so the modem is the authentic= ated
> server)? Also this raises the question of key management, if every mod= em has to
> be authenticated by its router.
>
>=C2=A0 =C2=A0 =C2=A0"but this is not a
>=C2=A0 =C2=A0 =C2=A0substantively different attack by such a compromise= d modem simply
>=C2=A0 =C2=A0 =C2=A0dropping all traffic destined to, or sent by a rout= er."
>
> Er, no... The modem does not need to be compromised for a 3rd party to= send
> spoof messages purporting to be from the modem.

Fair point - how about:


=C2=A0=C2=A0 Note that this extension does allow a compromised or impersona= ting
=C2=A0=C2=A0 modem to suppress transmission by the router.=C2=A0 Similar at= tacks are
=C2=A0=C2=A0 generally possible base DLEP, for example an impersonating mod= em may
=C2=A0=C2=A0 cause a session reset or a compromised modem simply can
=C2=A0=C2=A0 drop all traffic destined to, or sent by a router.=C2=A0 <x= ref
=C2=A0=C2=A0 target=3D"RFC8175"/> defines the use of TLS to pr= otect against the
=C2=A0=C2=A0 impersonating attacker.


>
> =3D=3DNits=3D=3D
>
> 1. Intro
> "DLEP peers are comprised of a modem and a router" is incorr= ect English for
> what you mean (it means that each peer consists of a modem and a route= r).
> Better to do away with this sentence completely, and alter to the prev= ious
> sentence to "It provides the exchange of link related control inf= ormation
> between a modem and its DLEP peer router."

sure.


> 3.1
> s/with Queue Index/
>=C2=A0 =C2=A0/with a Queue Index/

okay

> Scale:
> s/An 4-bit/
>=C2=A0 =C2=A0/A 4-bit/
okay
> In general, I think the term "queue size" is wrongly being u= sed where "buffer
> size" should be used (the queue size is the varying size of the q= ueue within
> the buffer at any one time).
>
> Also, pls consistently use the term 'paused' not 'suppress= ed', which has the
> potentially ambiguous meaning of 'discarded'.

will clarify the intent.


> Delete gratuitous 'is':
>=C2=A0 =C2=A0 "The motivating use case [is] for this
>=C2=A0 =C2=A0 =C2=A0data item is when a modem's internal queue leng= th exceeds a
>=C2=A0 =C2=A0 =C2=A0particular threshold."
yes,
>
> CURRENT:
>=C2=A0 =C2=A0 "e.g., when there
>=C2=A0 =C2=A0 =C2=A0a non queue related congestion points within a mode= m, but such are
>=C2=A0 =C2=A0 =C2=A0not explicitly described in this document." > SUGGESTED:
>=C2=A0 =C2=A0 "e.g., when there
>=C2=A0 =C2=A0 =C2=A0are non queue related congestion points within a mo= dem. Such use-cases are
>=C2=A0 =C2=A0 =C2=A0not explicitly described in this document." >
>
Done!

Thank you for the comments.

Lou

PS the working document has been updated, if interested see
https://github.com/louberger/dlep-exte= nsions/tree/master/pause

> _______________________________________________
> manet mailing list
> manet@ietf.org=
> https://www.ietf.org/mailman/listinfo/manet
>
--00000000000075b6b8058637e519-- From nobody Thu Apr 11 04:47:44 2019 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 5786C120223 for ; Thu, 11 Apr 2019 04:47:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-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 DEBL7X37kIBh for ; Thu, 11 Apr 2019 04:47:34 -0700 (PDT) Received: from gproxy5-pub.mail.unifiedlayer.com (gproxy5-pub.mail.unifiedlayer.com [67.222.38.55]) (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 21FBE1201DA for ; Thu, 11 Apr 2019 04:47:34 -0700 (PDT) Received: from cmgw15.unifiedlayer.com (unknown [10.9.0.15]) by gproxy5.mail.unifiedlayer.com (Postfix) with ESMTP id 839891404EA for ; Thu, 11 Apr 2019 05:47:33 -0600 (MDT) Received: from box313.bluehost.com ([69.89.31.113]) by cmsmtp with ESMTP id EYB3hfOvRszDUEYB3hrUkg; Thu, 11 Apr 2019 05:47:33 -0600 X-Authority-Reason: nr=8 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:References:Cc: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=d2rKPnVWmKBwm0OHOjI2ka+0EWHAHx7QasZwUD2Shnw=; b=d/bJQ3V5XyhO0XHUk7Ipgeo1O6 logowe6qbWNxeha7vfutYUhIx3ySdddPvywSyHewcdyfy5QEAIAm6xXHwKnrGoavQzifpV1oe3cvE 8SIs392u7/SiwWNKwCfYgD473; Received: from pool-72-66-11-201.washdc.fios.verizon.net ([72.66.11.201]:49720 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from ) id 1hEYB3-003eKQ-7c; Thu, 11 Apr 2019 05:47:33 -0600 To: Magnus Westerlund , "Ratliff, Stanley" , The IESG Cc: "draft-ietf-manet-dlep-pause-extension@ietf.org" , "manet@ietf.org" , "manet-chairs@ietf.org" References: <155437815884.30894.8011482899811561433.idtracker@ietfa.amsl.com> <8c18420b622f405eb0d4adcf844b315d@idirect.net> From: Lou Berger Message-ID: <36cb484b-f2a5-0f13-5210-e0b67b4a4231@labn.net> Date: Thu, 11 Apr 2019 07:47:32 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US 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: 72.66.11.201 X-Source-L: No X-Exim-ID: 1hEYB3-003eKQ-7c X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-72-66-11-201.washdc.fios.verizon.net ([IPv6:::1]) [72.66.11.201]:49720 X-Source-Auth: lberger@labn.net X-Email-Count: 7 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== X-Local-Domain: yes Archived-At: Subject: Re: [manet] Magnus Westerlund's Discuss on draft-ietf-manet-dlep-pause-extension-06: (with DISCUSS) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2019 11:47:36 -0000 Magnus, On 4/5/2019 5:11 AM, Magnus Westerlund wrote: > Hi, > > Thanks for the replies. > > I think the main point here is if one should treat router + modem as one > common queue when it comes to meeting PHBs or treat them as two in > sequence queues. If one treat them as two queues then you get the same > behavior as two routers in sequence. And that is acceptable from one > angle, but it also results in additional jitter and latencies. I think Stan's response already covered the above. From my perspective, I agree with stan that a modem that reports DSCPs should be expected to honor them like any other transit IP device (router, middlebox, etc.).  I think that the following is possible in the non-diffserv modem aware case - but another approach would be to not deploy such limited modems in a network that requires DSCP support - just like you wouldn't deploy a router that doesn't support a particular PHB in network that expects to support it. > > If we take the Expedited Forwarding PHB (RFC 3246) treating this as two > queue results in that the error is E_a1 (router) + E_a2 (mode) rather > than a E_a for the combined queue. The question is if E_a actually will > be smaller than E_a1+E_a2 when one uses this type of control? In the > combined case if the modem queue is so shallow that E_a2 << E_a1 as well > as that time for performing the DLEP signalling is so short that the > main variations ends up being in the router queue where one can apply > suitable policies to control queue load to prevent violation of the > targets. > I think my main concern will be what happens if one attempts to > implement L4S dual queues or DETNET and have DLEP in the path. Will this > require additional extensions to provide more detailed flow control > information so that lower latency or more deterministic behavior can be > achieved? Quite likely -- I think this is not the flow control you'd want with DetNet (I can't speak to L4S), i'd personally use something like what's covered in ietf-manet-dlep-da-credit-extension. > I noticed that TSVART reviewer Bob Briscoe asked for a use case > description of the case when the main queue is pushed to the router. I > think that appears to be a good idea. I think what I am wondering is if > there need to be some applicability statement here due the limitations > of the technology? I certainly have no objection to such, particularly given ietf-manet-dlep-da-credit-extension.  If you have any suggested text, that would be helpful.  Otherwise, as I mentioned in response to Bob, if really needed I can work with the Shepherd/WG on some applicability text. Lou > Cheers > > Magnus > > From nobody Thu Apr 11 05:01:28 2019 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 300FE120131 for ; Thu, 11 Apr 2019 05:01:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, 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 sp5RIUuRR9Xo for ; Thu, 11 Apr 2019 05:01:24 -0700 (PDT) Received: from gproxy4-pub.mail.unifiedlayer.com (gproxy4-pub.mail.unifiedlayer.com [69.89.23.142]) (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 21A98120223 for ; Thu, 11 Apr 2019 05:01:24 -0700 (PDT) Received: from cmgw11.unifiedlayer.com (unknown [10.9.0.11]) by gproxy4.mail.unifiedlayer.com (Postfix) with ESMTP id 55E4D17670F for ; Thu, 11 Apr 2019 05:58:04 -0600 (MDT) Received: from box313.bluehost.com ([69.89.31.113]) by cmsmtp with ESMTP id EYLEhP8rjVLCbEYLEhsOTo; Thu, 11 Apr 2019 05:58:04 -0600 X-Authority-Reason: nr=8 X-Authority-Analysis: $(_cmae_reason 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:References:Cc: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=nPOhAwh8KuAueBPThEAr6ByIpb/fSW3SBSL8TjqYv80=; b=O30tALpYU9LRPvzjWvQs/KDvVS x+mMjzJeO/Svz3dQmKmJKjwUP/PirlFRexpxkvJu9oXhXPu4PZMKRoP8yGqAwuALGXmdzX1QMwmb9 fgr2Uh4BMIptuc4NHLfu7BcGY; Received: from pool-72-66-11-201.washdc.fios.verizon.net ([72.66.11.201]:49738 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from ) id 1hEYLD-003hpZ-UR; Thu, 11 Apr 2019 05:58:04 -0600 To: Warren Kumari , The IESG Cc: draft-ietf-manet-dlep-pause-extension@ietf.org, Stan Ratliff , aretana.ietf@gmail.com, manet-chairs@ietf.org, manet@ietf.org References: <155474982892.30185.1930382368416788523.idtracker@ietfa.amsl.com> From: Lou Berger Message-ID: <7465dc7c-e64b-9926-5e8d-9203e4767c7b@labn.net> Date: Thu, 11 Apr 2019 07:58:02 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.1 MIME-Version: 1.0 In-Reply-To: <155474982892.30185.1930382368416788523.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US 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: 72.66.11.201 X-Source-L: No X-Exim-ID: 1hEYLD-003hpZ-UR X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-72-66-11-201.washdc.fios.verizon.net ([IPv6:::1]) [72.66.11.201]:49738 X-Source-Auth: lberger@labn.net X-Email-Count: 15 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== X-Local-Domain: yes Archived-At: Subject: Re: [manet] Warren Kumari's Discuss on draft-ietf-manet-dlep-pause-extension-06: (with DISCUSS) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2019 12:01:26 -0000 On 4/8/2019 2:57 PM, Warren Kumari via Datatracker wrote: > Warren Kumari has entered the following ballot position for > draft-ietf-manet-dlep-pause-extension-06: 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-pause-extension/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > Please note that I'm really not a DLEP person, and so this may be completely > incorrect -- in which case I'm (of course!) happy to clear my discuss. > > Hypothetical Scenario: > My next-door neighbor keeps using up all the bandwidth, making my Internets > slow! Stupid neighbor! > > Until now I didn't have much motivation to mess with DLEP (it didn't really > gain me anything), but now I can spoof Pause Data Items to get the router to > stop sending traffic to her, freeing up all the bandwidth for me. > > The security considerations section doesn't *really* cover this -- it says: > " Note that this extension does allow a compromised or impersonating modem to > suppress transmission by the router, but this is not a substantively different > attack by such a compromised modem simply dropping all traffic destined to, or > sent by a router." -- that only covers compromised modems, not impersonating > modems. FWIW an impersonator can shut a router completely down, by constantly resetting the DLEP session.  RFC8175 defines TLS protected DLEP as the solution.  To make this clear(er) the text has been updated to read   Note that this extension does allow a compromised or impersonating   modem to suppress transmission by the router.  Similar attacks are   generally possible base DLEP, for example an impersonating modem may   cause a session reset or a compromised modem simply can   drop all traffic destined to, or sent by a router.  defines the use of TLS to protect against the   impersonating attacker. suggested improvements are most welcome! (but see below addition before drafting ;-) > It also says: > "[RFC8175] defines the use of TLS to protect against the impersonating > attacker." -- yes, RFC8175 does indeed define the use of TLS, but doesn't > require it. > > RFC8175 Security Considerations also say: > " This specification does not address security of the data plane, as it (the > data plane) is not affected, and standard security procedures can be employed." > and "Similar issues can arise if DLEP data is used as an input to policing > algorithms -- injection of malicious data via DLEP can cause those policing > algorithms to make incorrect decisions, degrading network throughput." > > It seems that this specification is specifically allowing the dataplane to be > affected by (spoofed) DLEP messages, and in a much more direct way than > discussed in the RFC8175 security considerations section. I think that this is > dangerous without much more direct advice (like "MUST use TLS" or similar). I have no objection to something.  How about, to the end of the prior paragraph:   Implementations of the extension defined in this document MUST support   configuration of TLS usage, as describe in ,   in order to protect configurations where injection attacks are   possible, i.e., when the link between a modem and router is not   otherwise protected. Lou > > > > From nobody Thu Apr 11 05:06:26 2019 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 55A131201B6 for ; Thu, 11 Apr 2019 05:06:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 WJJ8XPnWIDKo for ; Thu, 11 Apr 2019 05:06:23 -0700 (PDT) Received: from gproxy6-pub.mail.unifiedlayer.com (outbound-ss-348.hostmonster.com [74.220.202.212]) (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 361BD1201B1 for ; Thu, 11 Apr 2019 05:06:22 -0700 (PDT) Received: from cmgw11.unifiedlayer.com (unknown [10.9.0.11]) by gproxy6.mail.unifiedlayer.com (Postfix) with ESMTP id B13481E0632 for ; Thu, 11 Apr 2019 06:06:21 -0600 (MDT) Received: from box313.bluehost.com ([69.89.31.113]) by cmsmtp with ESMTP id EYTFhPL0jVLCbEYTFhsaZC; Thu, 11 Apr 2019 06:06:21 -0600 X-Authority-Reason: nr=8 X-Authority-Analysis: $(_cmae_reason 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:References:Cc: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=YT7Of+JbkycAbY0LQtkfM2uSjZ24+zFlvoUhmUpR36o=; b=aJKeMa/2nFXsMefwAtFettGdYn HluoynML1EWcd9/tWkDb6u/8RpHtSFd6P5IkRpcNLKrco7mCkBSbhOwUL9q49bEdvG5FcE8P2xuLx OCoiShfcgg0/rQ86f6zB7ZzfH; Received: from pool-72-66-11-201.washdc.fios.verizon.net ([72.66.11.201]:49754 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from ) id 1hEYTF-003lRV-8x; Thu, 11 Apr 2019 06:06:21 -0600 To: Alissa Cooper , The IESG Cc: draft-ietf-manet-dlep-pause-extension@ietf.org, Stan Ratliff , aretana.ietf@gmail.com, manet-chairs@ietf.org, manet@ietf.org References: <155492518369.22601.15786320586524280536.idtracker@ietfa.amsl.com> From: Lou Berger Message-ID: <69152b8e-2c37-53f0-0695-42e3b9341ebe@labn.net> Date: Thu, 11 Apr 2019 08:06:16 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.1 MIME-Version: 1.0 In-Reply-To: <155492518369.22601.15786320586524280536.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US 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: 72.66.11.201 X-Source-L: No X-Exim-ID: 1hEYTF-003lRV-8x X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-72-66-11-201.washdc.fios.verizon.net ([IPv6:::1]) [72.66.11.201]:49754 X-Source-Auth: lberger@labn.net X-Email-Count: 7 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== X-Local-Domain: yes Archived-At: Subject: Re: [manet] Alissa Cooper's Discuss on draft-ietf-manet-dlep-pause-extension-06: (with DISCUSS and COMMENT) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2019 12:06:25 -0000 On 4/10/2019 3:39 PM, Alissa Cooper via Datatracker wrote: > Alissa Cooper has entered the following ballot position for > draft-ietf-manet-dlep-pause-extension-06: 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-pause-extension/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > This work item does not appear to be inside the scope of the MANET charter, at > least based on my reading of the charter. Am I missing something? I presume this is for the AD (or chairs) to respond to. > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I support the DISCUSS positions of Warren and Magnus. > > I'm unclear on why this specification is necessary, i.e. why the use of > existing transport protocols and processing of DSCPs do not suffice to achieve > what this specification is aiming to achieve. Is that explained in another > document somewhere? DLEP flow control is an alternative to existing flow control mechanisms such as exists for PPPOE and ethernet (PAUSE and PFC). It has the advantage of being able to pause traffic on a per destination and/or DSCP basis. I'll add the above to the document intro. > = Section 1 = > > "Various flow control methods are possible, e.g., > see [I-D.ietf-manet-dlep-da-credit-extension]." > > The referenced document does not specify a flow control method. Maybe > draft-ietf-manet-dlep-credit-flow-control is what was intended? Added as a second reference. Thanks, Lou > > > From nobody Thu Apr 11 05:12:20 2019 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 81635120131; Thu, 11 Apr 2019 05:12:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 z7pV5KgNkCGE; Thu, 11 Apr 2019 05:12:09 -0700 (PDT) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40084.outbound.protection.outlook.com [40.107.4.84]) (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 042DD120048; Thu, 11 Apr 2019 05:12:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=HQWE+3uBPHB1QGGKVeAb9ev61qlZYUTyFyEtEe/ob6w=; b=Krwiu7zHdDjqlOtRu6crrELzkOKLyg0C8I/XXCdP9OddelP+rzkNee2qWWqYBDCwFNeStefpZISELK2L6y15Xj2k/wEwhFZZa6GhzI1hlakPnOKCMYvmV7VotaisVDGpeQbrT7XjVmDpgDJku+8/GuEVKFqyjCpqwrymF+po/Do= Received: from HE1PR0701MB2522.eurprd07.prod.outlook.com (10.168.128.149) by HE1PR0701MB2618.eurprd07.prod.outlook.com (10.168.186.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1792.10; Thu, 11 Apr 2019 12:12:05 +0000 Received: from HE1PR0701MB2522.eurprd07.prod.outlook.com ([fe80::107c:5f27:2ef:8505]) by HE1PR0701MB2522.eurprd07.prod.outlook.com ([fe80::107c:5f27:2ef:8505%5]) with mapi id 15.20.1792.009; Thu, 11 Apr 2019 12:12:05 +0000 From: Magnus Westerlund To: Lou Berger , "Ratliff, Stanley" , The IESG CC: "draft-ietf-manet-dlep-pause-extension@ietf.org" , "manet@ietf.org" , "manet-chairs@ietf.org" Thread-Topic: [manet] Magnus Westerlund's Discuss on draft-ietf-manet-dlep-pause-extension-06: (with DISCUSS) Thread-Index: AQHU6tuJoEU8aqyRmUir+1XuKzIGuQ== Date: Thu, 11 Apr 2019 12:12:05 +0000 Message-ID: References: <155437815884.30894.8011482899811561433.idtracker@ietfa.amsl.com> <8c18420b622f405eb0d4adcf844b315d@idirect.net> <36cb484b-f2a5-0f13-5210-e0b67b4a4231@labn.net> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=magnus.westerlund@ericsson.com; x-originating-ip: [192.176.1.87] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: e808fad7-649c-4b2e-be24-08d6be76e9ca x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600139)(711020)(4605104)(2017052603328)(7193020); SRVR:HE1PR0701MB2618; x-ms-traffictypediagnostic: HE1PR0701MB2618: x-microsoft-antispam-prvs: x-forefront-prvs: 00046D390F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(136003)(366004)(376002)(396003)(39860400002)(189003)(199004)(51914003)(51444003)(74316002)(6116002)(93886005)(4326008)(561944003)(5660300002)(7696005)(316002)(7736002)(33656002)(305945005)(53936002)(99286004)(26005)(54906003)(186003)(6506007)(53546011)(44832011)(2906002)(81166006)(478600001)(55016002)(6246003)(66066001)(8936002)(110136005)(8676002)(68736007)(9686003)(102836004)(52536014)(81156014)(229853002)(256004)(71200400001)(14454004)(25786009)(6436002)(106356001)(3846002)(97736004)(486006)(66574012)(105586002)(86362001)(476003)(446003)(76176011)(71190400001); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0701MB2618; H:HE1PR0701MB2522.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: Oq9NvMOJKzjFCL0e6lh9D1kV+UeCRTAQN4B6ob6mlqkl2IbGaDNq/PZ3TFmlGx6wz/2T2evAiM237qkz9F5zrW61t6i5q1nypKWdu5ENrULAs52rjNXKR3fu1qe/choaYnXrKGe1ia4TANPqqccwF5p5gW43vW1JufSp7xf3dhLDsHVa5CUsD2FDt5TEeFouAxF60W15rzjQJtz1mmYxLgne6pLx8lUnS15mdUN2tRAzP6NmXE3NDY+n1Bal7MiYuzIMy9kX4udVi7jTxtrLc4MpLYJogpZimd7AAVjIzrIdcf4IqoH1EbAqzA7BOu00UrTyhpgBOCitaWkPqDrhiNHBLhnsfPBoEwzqE6p8y6VdciAlwMQsxEtcRmLnO6JM1i2NUpseWlQBQ5GMAl0mtGxsN8B/jl0KL48VEok0j4w= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: e808fad7-649c-4b2e-be24-08d6be76e9ca X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Apr 2019 12:12:05.5799 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2618 Archived-At: Subject: Re: [manet] Magnus Westerlund's Discuss on draft-ietf-manet-dlep-pause-extension-06: (with DISCUSS) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2019 12:12:11 -0000 Hi,=0A= =0A= I don't have a text proposal. I think if you work with Bob to detail out=0A= the use case and=0A= clarifications on the limitations with the protocol that should solve my=0A= issue here.=0A= =0A= Cheers=0A= =0A= Magnus=0A= =0A= On 2019-04-11 13:47, Lou Berger wrote:=0A= > Magnus,=0A= >=0A= > On 4/5/2019 5:11 AM, Magnus Westerlund wrote:=0A= >> Hi,=0A= >>=0A= >> Thanks for the replies.=0A= >>=0A= >> I think the main point here is if one should treat router + modem as one= =0A= >> common queue when it comes to meeting PHBs or treat them as two in=0A= >> sequence queues. If one treat them as two queues then you get the same= =0A= >> behavior as two routers in sequence. And that is acceptable from one=0A= >> angle, but it also results in additional jitter and latencies.=0A= > I think Stan's response already covered the above. From my perspective, = =0A= > I agree with stan that a modem that reports DSCPs should be expected to = =0A= > honor them like any other transit IP device (router, middlebox, etc.). = =0A= > I think that the following is possible in the non-diffserv modem aware = =0A= > case - but another approach would be to not deploy such limited modems = =0A= > in a network that requires DSCP support - just like you wouldn't deploy = =0A= > a router that doesn't support a particular PHB in network that expects = =0A= > to support it.=0A= >=0A= >> If we take the Expedited Forwarding PHB (RFC 3246) treating this as two= =0A= >> queue results in that the error is E_a1 (router) + E_a2 (mode) rather=0A= >> than a E_a for the combined queue. The question is if E_a actually will= =0A= >> be smaller than E_a1+E_a2 when one uses this type of control? In the=0A= >> combined case if the modem queue is so shallow that E_a2 << E_a1 as well= =0A= >> as that time for performing the DLEP signalling is so short that the=0A= >> main variations ends up being in the router queue where one can apply=0A= >> suitable policies to control queue load to prevent violation of the=0A= >> targets.=0A= >> I think my main concern will be what happens if one attempts to=0A= >> implement L4S dual queues or DETNET and have DLEP in the path. Will this= =0A= >> require additional extensions to provide more detailed flow control=0A= >> information so that lower latency or more deterministic behavior can be= =0A= >> achieved?=0A= > Quite likely -- I think this is not the flow control you'd want with =0A= > DetNet (I can't speak to L4S), i'd personally use something like what's = =0A= > covered in ietf-manet-dlep-da-credit-extension.=0A= >=0A= >=0A= >> I noticed that TSVART reviewer Bob Briscoe asked for a use case=0A= >> description of the case when the main queue is pushed to the router. I= =0A= >> think that appears to be a good idea. I think what I am wondering is if= =0A= >> there need to be some applicability statement here due the limitations= =0A= >> of the technology?=0A= > I certainly have no objection to such, particularly given =0A= > ietf-manet-dlep-da-credit-extension. If you have any suggested text, =0A= > that would be helpful. Otherwise, as I mentioned in response to Bob, if = =0A= > really needed I can work with the Shepherd/WG on some applicability text.= =0A= >=0A= > Lou=0A= >=0A= >> Cheers=0A= >>=0A= >> Magnus=0A= >>=0A= >>=0A= =0A= -- =0A= =0A= Magnus Westerlund =0A= =0A= ----------------------------------------------------------------------=0A= Network Architecture & Protocols, Ericsson Research=0A= ----------------------------------------------------------------------=0A= Ericsson AB | Phone +46 10 7148287=0A= Torshamnsgatan 23 | Mobile +46 73 0949079=0A= SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com=0A= ----------------------------------------------------------------------=0A= =0A= From nobody Thu Apr 11 06:07:02 2019 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 99EE81200D8; Thu, 11 Apr 2019 06:06:53 -0700 (PDT) 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, HTML_MESSAGE=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=cooperw.in header.b=goR+0IDj; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=aOkYPsLU 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 S-Hxlw6OCp1D; Thu, 11 Apr 2019 06:06:51 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F38412017B; Thu, 11 Apr 2019 06:06:51 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 9B0E12789E; Thu, 11 Apr 2019 09:06:50 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Thu, 11 Apr 2019 09:06:50 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h= from:message-id:content-type:mime-version:subject:date :in-reply-to:cc:to:references; s=fm2; bh=zmIMj/USbkNEVKU/OR8pa0S zwK6JS5diFA3Bh29POPQ=; b=goR+0IDjE8rJrbhRGbyuP1vkp18DfqYzdWLcV4Q YMxWMqMnR+CnxF8PseBtgZUOrXCJh1Jacm6LikBjVyNL4DthdCMY+Ok0Pkm2j4iq leBWgS2ocVsCfvCrk9dogRDSx7BMyd4dyL6P0wedyApTtbr3mnbfqUyYlrCJxQeU 9af1tFzkNozJqaI8Zme236Zsqgl0mUwvFSeZupsh9b/AruykQ1OQdfVc78R8TuD2 KuXyPJa1ueLVXVsHVVCki8S/pdKCHgAl8YUGiwvxjAfALrsS6V91AtPAKa35uGHv Mez5hngdfz4Y54qzyUkfcCc8kgqji3LIdVeu4oMSH8v31HQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=zmIMj/ USbkNEVKU/OR8pa0SzwK6JS5diFA3Bh29POPQ=; b=aOkYPsLUWQfCzKIliU2UTd ZP6SIyY5kRpZ8kF3uZXE2aJDXF44yPDwMwDiaTLNB5FNBSMDW8vN8XEtQSF+h15A hz1H/MxKBAtvLYoNTbtNnQfS6M7N2IlKruW5VQXVZZQsfoWd+NlerUCYa9qxYjou cFMXRaaaH7qaU9MyECpI7+A24ioSHwXOSPHjXANd+p8LM6vTBYfSQwyf9jGLvGK2 TUG7aRrmeSwq+pL/4UWBtKdCgbcptyh8YS/dd6wiLnR7tKfmpUTtkA7WnQbrBSe4 rF2AD8/TxZOinudKCS8a2mwWKQJINy9lj1PPJJWtaEoM9JT6VIZR63iAbE/1PfFg == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrudelgdeiudcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhkfgtggfuffgjvfhfofesrgdtmherhhdtjeenucfhrhhomheptehlihhsshgr ucevohhophgvrhcuoegrlhhishhsrgestghoohhpvghrfidrihhnqeenucfkphepudejfe drfeekrdduudejrdekjeenucfrrghrrghmpehmrghilhhfrhhomheprghlihhsshgrsegt ohhophgvrhifrdhinhenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: from rtp-alcoop-nitro5.cisco.com (unknown [173.38.117.87]) by mail.messagingengine.com (Postfix) with ESMTPA id 99892E415C; Thu, 11 Apr 2019 09:06:49 -0400 (EDT) From: Alissa Cooper Message-Id: <6CBEC07D-A6E3-455C-87F8-6CB2DC0C1BDF@cooperw.in> Content-Type: multipart/alternative; boundary="Apple-Mail=_ADF1AF6A-1FEE-4D62-AA10-8A8CE70BE961" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Thu, 11 Apr 2019 09:06:47 -0400 In-Reply-To: Cc: IESG , Stan Ratliff , manet-chairs@ietf.org, draft-ietf-manet-dlep-pause-extension@ietf.org, manet@ietf.org To: Alvaro Retana References: <155492518369.22601.15786320586524280536.idtracker@ietfa.amsl.com> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [manet] Alissa Cooper's Discuss on draft-ietf-manet-dlep-pause-extension-06: (with DISCUSS and COMMENT) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2019 13:06:54 -0000 --Apple-Mail=_ADF1AF6A-1FEE-4D62-AA10-8A8CE70BE961 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Alvaro, > On Apr 10, 2019, at 4:36 PM, Alvaro Retana = wrote: >=20 > On April 10, 2019 at 3:39:44 PM, Alissa Cooper via Datatracker = (noreply@ietf.org ) wrote: >=20 > Alissa: >=20 > Hi! >=20 >> = ----------------------------------------------------------------------=20= >> DISCUSS:=20 >> = ----------------------------------------------------------------------=20= >>=20 >> This work item does not appear to be inside the scope of the MANET = charter, at=20 >> least based on my reading of the charter. Am I missing something?=20 >=20 > It is not explicitly called out. However, I believe it is part of the = general development of DLEP, for which the WG is responsible. Is there any scope limitation to the functionality that could = potentially be characterized as further "development of DLEP"? I ask = because from a quick read of the base specification, it doesn=E2=80=99t = look like pause/resume was contemplated, and as you note this was not = explicitly called out in the charter whereas credit windowing was. I=E2=80= =99m wondering what the boundary is around the functionality DLEP is = expected to provide as a protocol. Thanks, Alissa >=20 > Alvaro. --Apple-Mail=_ADF1AF6A-1FEE-4D62-AA10-8A8CE70BE961 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Alvaro,

On Apr 10, 2019, at 4:36 PM, Alvaro Retana = <aretana.ietf@gmail.com> wrote:

On = April 10, 2019 at 3:39:44 PM, Alissa Cooper via Datatracker (noreply@ietf.org) = wrote:

Alissa:

Hi!

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

This work = item does not appear to be inside the scope of the MANET charter, = at 
least based on my reading of the charter. Am I = missing something? 

It is not explicitly called = out.  However, I believe it is part of the general development of = DLEP, for which the WG is = responsible.

Is there any scope limitation to the functionality = that could potentially be characterized as further "development of = DLEP"? I ask because from a quick read of the base specification, it = doesn=E2=80=99t look like pause/resume was contemplated, and as you note = this was not explicitly called out in the charter whereas credit = windowing was. I=E2=80=99m wondering what the boundary is around the = functionality DLEP is expected to provide as a protocol.

Thanks,
Alissa


Alvaro.

= --Apple-Mail=_ADF1AF6A-1FEE-4D62-AA10-8A8CE70BE961-- From nobody Thu Apr 11 06:29:59 2019 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 1B5DC12021F; Thu, 11 Apr 2019 06:29:52 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Warren Kumari via Datatracker To: "The IESG" Cc: draft-ietf-manet-dlep-pause-extension@ietf.org, Stan Ratliff , aretana.ietf@gmail.com, manet-chairs@ietf.org, sratliff@idirect.net, manet@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.95.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Warren Kumari Message-ID: <155498939209.25091.12221953944223860700.idtracker@ietfa.amsl.com> Date: Thu, 11 Apr 2019 06:29:52 -0700 Archived-At: Subject: [manet] Warren Kumari's No Objection on draft-ietf-manet-dlep-pause-extension-06: (with COMMENT) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.29 List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2019 13:29:52 -0000 Warren Kumari has entered the following ballot position for draft-ietf-manet-dlep-pause-extension-06: No Objection 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-pause-extension/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- DISCUSS -> NoObj. Lou will add: Implementations of the extension defined in this document MUST support configuration of TLS usage, as describe in , in order to protect configurations where injection attacks are possible, i.e., when the link between a modem and router is not otherwise protected. to address my DISCUSS. --- Archived DISCUSS position for hysterical raisins --- Please note that I'm really not a DLEP person, and so this may be completely incorrect -- in which case I'm (of course!) happy to clear my discuss. Hypothetical Scenario: My next-door neighbor keeps using up all the bandwidth, making my Internets slow! Stupid neighbor! Until now I didn't have much motivation to mess with DLEP (it didn't really gain me anything), but now I can spoof Pause Data Items to get the router to stop sending traffic to her, freeing up all the bandwidth for me. The security considerations section doesn't *really* cover this -- it says: " Note that this extension does allow a compromised or impersonating modem to suppress transmission by the router, but this is not a substantively different attack by such a compromised modem simply dropping all traffic destined to, or sent by a router." -- that only covers compromised modems, not impersonating modems. It also says: "[RFC8175] defines the use of TLS to protect against the impersonating attacker." -- yes, RFC8175 does indeed define the use of TLS, but doesn't require it. RFC8175 Security Considerations also say: " This specification does not address security of the data plane, as it (the data plane) is not affected, and standard security procedures can be employed." and "Similar issues can arise if DLEP data is used as an input to policing algorithms -- injection of malicious data via DLEP can cause those policing algorithms to make incorrect decisions, degrading network throughput." It seems that this specification is specifically allowing the dataplane to be affected by (spoofed) DLEP messages, and in a much more direct way than discussed in the RFC8175 security considerations section. I think that this is dangerous without much more direct advice (like "MUST use TLS" or similar). ------- From nobody Thu Apr 11 06:30:52 2019 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 727CF120229 for ; Thu, 11 Apr 2019 06:30:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.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 QN0eiU0MFXjA for ; Thu, 11 Apr 2019 06:30:48 -0700 (PDT) Received: from mail-qk1-x732.google.com (mail-qk1-x732.google.com [IPv6:2607:f8b0:4864:20::732]) (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 5BC8712029F for ; Thu, 11 Apr 2019 06:30:45 -0700 (PDT) Received: by mail-qk1-x732.google.com with SMTP id g1so3425376qki.5 for ; Thu, 11 Apr 2019 06:30:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=aGfUividUIp4/hT5kwfenB4W6Edt5IlXahDaxX0oybI=; b=vZ49y1xnVJBgShJ7UZoUEIfCwmYHbVKgFZIhK5vkPN+IptTV9lp495S7sxzWuqmMRw jpH6cPAwnZeqiKOF0LzYREravTK1shcc9iK2cXUPcFj0+jBQBj48Bf8EUVQ9XR/dBhGC vQAtIv9Ev3CxhdY9yuzXMvP7fbI1iXCsiBKetalL5phN2AAinckKlbv9C83FszC2vGcz COhB80NsX0WenS3qgOkP7pTTKGFLVq2pvvk0HBtZ9DqEX1Dsybze0Q9c2NfI8Wv6fO7Y yRBmQ0cjXkG4h/XtN2wZULtcT+CeCp5ZLG0RZoLGnOCP4j7CvoBOcKwOrDiLP4BGfQ6l SIzQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=aGfUividUIp4/hT5kwfenB4W6Edt5IlXahDaxX0oybI=; b=HR5xm9/23lwZs5Co3uJ4X6a1ZonXwe/IT7e29C3DH6yIK/zlD8WHaRghYcV+iZcZvo 3HJ6cHoJkKSBVFye+PfJsOdN8iq7e1xgVhYSPH3OfpOOObAyr4myMrK2VwzgTlbM0H/L almdmBQf9OUvhok7hYFvmakM1Pr5UA25Tb30pFvtqUAc+ndvbctAj8H6jsbXiBMg1mYE nmFKgxUFALHz8L/pJE2TWRSjvHnVKgi9LT0pKPBYB2OXeZ+y3MDCMqvNXk9iY+KSY9Th EEXni3akOmlh41jl0T6BUAtPqifXKJEK1KcocImylpHEbLTMzUUhzeSFDMEpK+wP+py0 JCnw== X-Gm-Message-State: APjAAAWdMjoR/1S5yHY8J8ld/9mvIJAEqNlg53pU+a+x2RT0OWA+Gt5R 5Datw2NKwCWSNYZq5zMQaVPLpdmr6SGcMcjL+aMsdQ== X-Google-Smtp-Source: APXvYqwPMhm7bbnPZq61RKiy5DSFTkOr11knL8/w/5eu6TKgzNVd/u/juV+K8kmX6tijvMO0bK6/0/kpUrUQh0/e8Dg= X-Received: by 2002:a05:620a:1597:: with SMTP id d23mr37644298qkk.226.1554989443984; Thu, 11 Apr 2019 06:30:43 -0700 (PDT) MIME-Version: 1.0 References: <155474982892.30185.1930382368416788523.idtracker@ietfa.amsl.com> <7465dc7c-e64b-9926-5e8d-9203e4767c7b@labn.net> In-Reply-To: <7465dc7c-e64b-9926-5e8d-9203e4767c7b@labn.net> From: Warren Kumari Date: Thu, 11 Apr 2019 09:30:07 -0400 Message-ID: To: Lou Berger Cc: The IESG , draft-ietf-manet-dlep-pause-extension@ietf.org, manet@ietf.org, Mobile Ad-hoc Networks Working Group , Stan Ratliff , Alvaro Retana Content-Type: multipart/alternative; boundary="0000000000007049a5058641313d" Archived-At: Subject: Re: [manet] Warren Kumari's Discuss on draft-ietf-manet-dlep-pause-extension-06: (with DISCUSS) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2019 13:30:51 -0000 --0000000000007049a5058641313d Content-Type: text/plain; charset="UTF-8" On Thu, Apr 11, 2019 at 8:21 AM Lou Berger wrote: > > On 4/8/2019 2:57 PM, Warren Kumari via Datatracker wrote: > > Warren Kumari has entered the following ballot position for > > draft-ietf-manet-dlep-pause-extension-06: 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-pause-extension/ > > > > > > > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > > > > Please note that I'm really not a DLEP person, and so this may be > completely > > incorrect -- in which case I'm (of course!) happy to clear my discuss. > > > > Hypothetical Scenario: > > My next-door neighbor keeps using up all the bandwidth, making my > Internets > > slow! Stupid neighbor! > > > > Until now I didn't have much motivation to mess with DLEP (it didn't > really > > gain me anything), but now I can spoof Pause Data Items to get the > router to > > stop sending traffic to her, freeing up all the bandwidth for me. > > > > The security considerations section doesn't *really* cover this -- it > says: > > " Note that this extension does allow a compromised or impersonating > modem to > > suppress transmission by the router, but this is not a substantively > different > > attack by such a compromised modem simply dropping all traffic destined > to, or > > sent by a router." -- that only covers compromised modems, not > impersonating > > modems. > > FWIW an impersonator can shut a router completely down, by constantly > resetting the DLEP session. RFC8175 defines TLS protected DLEP as the > solution. To make this clear(er) the text has been updated to read > > > Note that this extension does allow a compromised or impersonating > modem to suppress transmission by the router. Similar attacks are > generally possible base DLEP, for example an impersonating modem may > cause a session reset or a compromised modem simply can > drop all traffic destined to, or sent by a router. target="RFC8175"/> defines the use of TLS to protect against the > impersonating attacker. > > suggested improvements are most welcome! (but see below addition before > drafting ;-) > > > It also says: > > "[RFC8175] defines the use of TLS to protect against the impersonating > > attacker." -- yes, RFC8175 does indeed define the use of TLS, but doesn't > > require it. > > > > RFC8175 Security Considerations also say: > > " This specification does not address security of the data plane, as it > (the > > data plane) is not affected, and standard security procedures can be > employed." > > and "Similar issues can arise if DLEP data is used as an input to > policing > > algorithms -- injection of malicious data via DLEP can cause those > policing > > algorithms to make incorrect decisions, degrading network throughput." > > > > It seems that this specification is specifically allowing the dataplane > to be > > affected by (spoofed) DLEP messages, and in a much more direct way than > > discussed in the RFC8175 security considerations section. I think that > this is > > dangerous without much more direct advice (like "MUST use TLS" or > similar). > > I have no objection to something. How about, to the end of the prior > paragraph: > > Implementations of the extension defined in this document MUST support > configuration of TLS usage, as describe in , > in order to protect configurations where injection attacks are > possible, i.e., when the link between a modem and router is not > otherwise protected. > Thank you, that works for me. I'll clear my DISCUSS, and trust y'all to include it. W > > Lou > > > > > > > > > > > -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf --0000000000007049a5058641313d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Apr 11, 2019 at 8:21 AM Lou = Berger <lberger@labn.net> wro= te:

On 4/8/2019 2:57 PM, Warren Kumari via Datatracker wrote:
> Warren Kumari has entered the following ballot position for
> draft-ietf-manet-dlep-pause-extension-06: Discuss
>
> When responding, please keep the subject line intact and reply to all<= br> > email addresses included in the To and CC lines. (Feel free to cut thi= s
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/i= esg/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-pause-extension/
>
>
>
> ----------------------------------------------------------------------=
> DISCUSS:
> ----------------------------------------------------------------------=
>
> Please note that I'm really not a DLEP person, and so this may be = completely
> incorrect -- in which case I'm (of course!) happy to clear my disc= uss.
>
> Hypothetical Scenario:
> My next-door neighbor keeps using up all the bandwidth, making my Inte= rnets
> slow! Stupid neighbor!
>
> Until now I didn't have much motivation to mess with DLEP (it didn= 't really
> gain me anything), but now I can spoof Pause Data Items to get the rou= ter to
> stop sending traffic to her, freeing up all the bandwidth for me.
>
> The security considerations section doesn't *really* cover this --= it says:
> " Note that this extension does allow a compromised or impersonat= ing modem to
> suppress transmission by the router, but this is not a substantively d= ifferent
> attack by such a compromised modem simply dropping all traffic destine= d to, or
> sent by a router." -- that only covers compromised modems, not im= personating
> modems.

FWIW an impersonator can shut a router completely down, by constantly
resetting the DLEP session.=C2=A0 RFC8175 defines TLS protected DLEP as the=
solution.=C2=A0 To make this clear(er) the text has been updated to read

=C2=A0=C2=A0 Note that this extension does allow a compromised or impersona= ting
=C2=A0=C2=A0 modem to suppress transmission by the router.=C2=A0 Similar at= tacks are
=C2=A0=C2=A0 generally possible base DLEP, for example an impersonating mod= em may
=C2=A0=C2=A0 cause a session reset or a compromised modem simply can
=C2=A0=C2=A0 drop all traffic destined to, or sent by a router.=C2=A0 <x= ref
=C2=A0=C2=A0 target=3D"RFC8175"/> defines the use of TLS to pr= otect against the
=C2=A0=C2=A0 impersonating attacker.

suggested improvements are most welcome! (but see below addition before drafting ;-)

> It also says:
> "[RFC8175] defines the use of TLS to protect against the imperson= ating
> attacker." -- yes, RFC8175 does indeed define the use of TLS, but= doesn't
> require it.
>
> RFC8175 Security Considerations also say:
> " This specification does not address security of the data plane,= as it (the
> data plane) is not affected, and standard security procedures can be e= mployed."
> and "Similar issues can arise if DLEP data is used as an input to= policing
> algorithms -- injection of malicious data via DLEP can cause those pol= icing
> algorithms to make incorrect decisions, degrading network throughput.&= quot;
>
> It seems that this specification is specifically allowing the dataplan= e to be
> affected by (spoofed) DLEP messages, and in a much more direct way tha= n
> discussed in the RFC8175 security considerations section. I think that= this is
> dangerous without much more direct advice (like "MUST use TLS&quo= t; or similar).

I have no objection to something.=C2=A0 How about, to the end of the prior =
paragraph:

=C2=A0=C2=A0 Implementations of the extension defined in this document MUST= support
=C2=A0=C2=A0 configuration of TLS usage, as describe in <xref target=3D&= quot;RFC8175"/>,
=C2=A0=C2=A0 in order to protect configurations where injection attacks are=
=C2=A0=C2=A0 possible, i.e., when the link between a modem and router is no= t
=C2=A0=C2=A0 otherwise protected.


<= /div>
= Thank you, that works for me.

I'll clear my DISCUSS, and trust y&= #39;all to include it.
W

Lou

>
>
>
>



--
I don't think the execution is relevant when= it was obviously a bad idea in the first place.
This is like putting ra= bid weasels in your pants, and later expressing regret at having chosen tho= se particular rabid weasels and that pair of pants.
=C2=A0 =C2=A0---maf<= /div>
--0000000000007049a5058641313d-- From nobody Thu Apr 11 06:49:52 2019 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 D76FD120306; Thu, 11 Apr 2019 06:49:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 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, 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 T3u-suw5nb_H; Thu, 11 Apr 2019 06:49:40 -0700 (PDT) Received: from mail-ot1-x331.google.com (mail-ot1-x331.google.com [IPv6:2607:f8b0:4864:20::331]) (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 C495B1202E2; Thu, 11 Apr 2019 06:49:40 -0700 (PDT) Received: by mail-ot1-x331.google.com with SMTP id e80so5270451ote.5; Thu, 11 Apr 2019 06:49:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=WQfdkj5uF7o7gLCLAxAapP4dXbW+sLreGEvfy2frTQ4=; b=o4mzBKFHRrNaXQW/mvd0Mxlz7gfO3MhLlF+LRacwL+1c/3EGfhYbeAn+ulaISPZXj3 J3kZ34XPojdKII7VxPLFavTxDZh58mJdAso1Se1NVWVwr3+P/Sl0mIrR6sfVU9uLRIq4 IIbSMwDI2FHCkpU0gvRdLlYHdeeUxwBu0uuqrxSucQULlty8Sno7vXbMf5fkec4q0DWm qC+ajdwap+EJY+pjSfuzJdxAzUhcdhclndooECgkvURPJZfxWWVmNx/0cfDMLzyB6dBe CG/nvFgv277uJDDk0/HRBeiI9Bj62HYi4QCLYkrMM4Qn4hOiX6x9jscYcYF3f2pMTpsx DQPw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=WQfdkj5uF7o7gLCLAxAapP4dXbW+sLreGEvfy2frTQ4=; b=p7TuW2+TU2W1Fb1RSaYgWzt+ir+kb8ooYGW0C6u857lIKix8AMpfVW0ix8jlDru2eq 02OWymLFbUNpZYOaqfLE0i9faBLGu9L11GfoEhcU32IZCGAW+8NHzda2NVgZkQGH7HjB UEz6xrVyWOjIhSHj4NSgdeFyRog5J4sQrvHLy30M9JrO1O1SKOLKWv5FmWFqhnbsohX4 ip9cVQvgyCPwaIu6U+Cy3kfnKma5BvRnshEEm9OpoVZUUCQWV/ZEFyTssSZJuNPXBKxW PcgXixQNdHbs7qWZ5HtA4yYiGwE4+ZPtIb0xYk+8INpPpwFmEM+RgHV/Tw00deRVaWe+ GyxQ== X-Gm-Message-State: APjAAAVT1JilC+YZvy4fNrPg5+8vDjj+Uh+NdteangJkAYQMw3zYYJZn V6jUoR4DxtYAg2AiRN2X2kPdqd+UHnb+JuqCj00= X-Google-Smtp-Source: APXvYqxnUME7Oe3ge2QhGV9GlnNs3I2S6UsnzcxAJQmb6UyV2NFMJAVbqWLdxLB0/I8Cy9tC2p1g5clh7G47DA8RM9g= X-Received: by 2002:a05:6830:1103:: with SMTP id w3mr33583513otq.28.1554990580012; Thu, 11 Apr 2019 06:49:40 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Thu, 11 Apr 2019 06:49:39 -0700 From: Alvaro Retana In-Reply-To: <6CBEC07D-A6E3-455C-87F8-6CB2DC0C1BDF@cooperw.in> References: <155492518369.22601.15786320586524280536.idtracker@ietfa.amsl.com> <6CBEC07D-A6E3-455C-87F8-6CB2DC0C1BDF@cooperw.in> MIME-Version: 1.0 Date: Thu, 11 Apr 2019 06:49:39 -0700 Message-ID: To: Alissa Cooper Cc: Stan Ratliff , manet-chairs@ietf.org, IESG , draft-ietf-manet-dlep-pause-extension@ietf.org, manet@ietf.org Content-Type: multipart/alternative; boundary="000000000000269aa105864175cb" Archived-At: Subject: Re: [manet] Alissa Cooper's Discuss on draft-ietf-manet-dlep-pause-extension-06: (with DISCUSS and COMMENT) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2019 13:49:43 -0000 --000000000000269aa105864175cb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On April 11, 2019 at 9:06:50 AM, Alissa Cooper (alissa@cooperw.in) wrote: Is there any scope limitation to the functionality that could potentially be characterized as further "development of DLEP"? I ask because from a quick read of the base specification, it doesn=E2=80=99t look like pause/re= sume was contemplated, and as you note this was not explicitly called out in the charter whereas credit windowing was. I=E2=80=99m wondering what the bounda= ry is around the functionality DLEP is expected to provide as a protocol. In short, I believe the boundary is simply =E2=80=9Cwhatever the users need= =E2=80=9D. When we re-chartered (a couple of years ago), the WG thought that credit windowing would be the focus (there was a document in progress, etc.), but that has changed to include this extension, and others. The community working on DLEP is a very close-knit group with related (it not significantly overlapping) users =E2=80=94 the focus of the work then follo= ws what their users require. At some point we should think about generalizing the charter. Thanks! Alvaro. --000000000000269aa105864175cb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
On April 11, 2019 at 9:06:50 AM, Alissa Cooper (alissa@cooperw.in) wrote:

Is there any scope limitation to the functionality tha= t could potentially be characterized as further "development of DLEP&q= uot;? I ask because from a quick read of the base specification, it doesn= =E2=80=99t look like pause/resume was contemplated, and as you note this wa= s not explicitly called out in the charter whereas credit windowing was. I= =E2=80=99m wondering what the boundary is around the functionality DLEP is = expected to provide as a protocol.

In short, I believe the boundary is simply = =E2=80=9Cwhatever the users need=E2=80=9D.

When we re-chartered (a couple of years ago), the WG thought that cre= dit windowing would be the focus (there was a document in progress, etc.), = but that has changed to include this extension, and others.=C2=A0 The commu= nity working on DLEP is a very close-knit group with related (it not signif= icantly overlapping) users =E2=80=94 the focus of the work then follows wha= t their users require.

At some point = we should think about generalizing the charter.

Thanks!

Alvaro.

=
--000000000000269aa105864175cb-- From nobody Thu Apr 11 15:25:21 2019 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 87D751203EB; Thu, 11 Apr 2019 15:25:18 -0700 (PDT) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=bobbriscoe.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 XJCurtlsvrBC; Thu, 11 Apr 2019 15:25:13 -0700 (PDT) Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (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 46F251201E7; Thu, 11 Apr 2019 15:25:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-Transfer-Encoding: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=k3SbrNAFTabcapWUmvFqV/UnHJ6C5xXiPDrOnLyG5qk=; b=s4r8FzMMjbezA3QEgmKMrqWoi P9JEjhoYNXRZoXtpYYAUUBvqVkVbENJuArVSYqetaa26Qjh2e6WrvVzFQNBfnfWRsTsNuF9YmYtfL lg1sw9QoYeRN2iaw5up7znpT4++1YsAr5dvLwEbzXoCZftFaXrkng7jzqVDSe2VkZ1rBVdwQd8bFI OAFbBaE1JcsOPLcvkiQizomwHAhOyU+JadNw8rF+7JCoVPxdDXzeTihbJepjUU5a8bMZUOOnn6l6E kdp54MBb58R+hE9QhSbnnFxszI2/FZSRQGFR/PXHiuhSD2LRIv/DMLNoEp//w0H8xkjOg/nXbgwAN qZ4ErPqwQ==; Received: from [31.185.128.56] (port=55832 helo=[192.168.0.7]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from ) id 1hEi86-00057P-7Y; Thu, 11 Apr 2019 23:25:10 +0100 To: Justin Dean , Lou Berger Cc: draft-ietf-manet-dlep-pause-extension.all@ietf.org, tsv-art@ietf.org, manet@ietf.org, ietf@ietf.org References: <155442219204.31004.18308454286183143947@ietfa.amsl.com> From: Bob Briscoe Message-ID: <17ac4cce-27f6-df5b-5fef-f907d146ba40@bobbriscoe.net> Date: Thu, 11 Apr 2019 23:25:09 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------FD5971CF5D2A43864D4846F6" Content-Language: en-GB X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.dnsblock1.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - bobbriscoe.net X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net Archived-At: Subject: Re: [manet] [Tsv-art] Tsvart last call review of draft-ietf-manet-dlep-pause-extension-06 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2019 22:25:19 -0000 This is a multi-part message in MIME format. --------------FD5971CF5D2A43864D4846F6 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Justin, Lou, Replying to both at once, inline... On 11/04/2019 03:25, Justin Dean wrote: > A few comments inline marked JD, Justin Dean WG chair. > On Wed, Apr 10, 2019, 8:41 PM Lou Berger > wrote: > > Bob, > > Thanks for the comments - see below for responses. > > On 4/4/2019 7:56 PM, Bob Briscoe via Datatracker wrote: > > Reviewer: Bob Briscoe > > Review result: On the Right Track > > > > This document has been reviewed as part of the transport area > review team's > > ongoing effort to review key IETF documents. These comments were > written > > primarily for the transport area directors, but are copied to > the document's > > authors and WG to allow them to address any issues raised and > also to the IETF > > discussion list for information. > > > > When done at the time of IETF Last Call, the authors should > consider this > > review as part of the last-call comments they receive. Please > always CC > > tsv-art@ietf.org if you reply to or > forward this review. > > > > ==1. Introduction== > > > > It would be useful to describe the use-case where the modem does > not implement > > active queue management but the router does, so the modem can > use flow control > > to push the queue back into the router, where it can be more > intelligently > > controlled. > > I guess I'll have to talk to the Shepherd on this one to see how much > he/the WG would want to add on this at this point.  Perhaps giving a > reference to the earlier PPPOE (rfc5578) would suffice, what do > you think? > > JD will talk with Lou and respond in separate email. [BB] What I was looking for was some indication of valid and/or invalid use cases. I couldn't find anything about what problem this extension solves. > > > > > > ===Scope within Intro=== > > Please extend the single sentence about scope (end of 2nd para > of Intro) to > > explain that pause control only applies to data in the router to > modem > > direction. > > > > Please also mention that the scope of pause-based flow control > is limited to > > one hop and to a point-to-point link between router and modem, > not multipoint. > > The modem does not track the source of the data in its queue, so > it cannot > > focus pause messages onto particular sending stations on a > multipoint link, or > > onto particular ingress ports of the router. > > Done. > > > > > Why is the scope limited to DLEP radio links? I would have > thought this > > protocol is generally useful between a and modem and router. > > Because this is a DLEP extension.  Other mechanisms exist for other > technologies, e.g., RFC5578 or Ethernet PAUSE/PFC. > [BB] OK. > > > > ==3. Extension Data Items== > > > > Pls define the direction of the messages: > > s/The xxx Data Item is used by a modem to.../ > >   /A modem sends the xxx Data Item to its peer router to.../ > okay (paraphrase a bit) > > > > ===Unsafe design?=== > > Is it not good practice to make the data plane robust to > unexpected control > > plane failures (e.g. key expiry, incorrect or mis-timed change > of address, > > etc.) and vice versa? So, would it not be more robust for the > router to > > time-out a pause if no restart appears? Also, if the last > message received > > before shutting down or suspending was a pause, should the > router restart or > > resume in the paused state? What if the router enters a > power-saving state > > after it is paused and misses a restart message? > > I generally agree that a control plane fault should not result in > a data > plane loss -- in some environments, I'd say this is a must. This > said, > your comment goes to a design principle in DLEP RFC8175 where control > plane error result in session resets and data plane impacts. I think > changing this basic behavior of DLEP is beyond the scope of this > extension.  I think a general modification of base DLEP to support > such > would be a fine idea. > > > JD there may be more robust and clever solutions here that don't break > the base specification. Absence of an acknowledgement is not the same > as an error, syntax or otherwise, which causes a reset. Allowing for a > periodic restart message if data does not resume may be sufficient. [BB] I agree that it should be possible to make pause in itself robust. My point about control plane errors doesn't have to be taken as an architectural point. I was merely saying that if restart fails for some reason, you don't want data to be paused for ever. One way to do that is simply to have a globally known constant timeout on a pause. Then, if a modem wants the router to pause longer than this timeout, it has to repeat the pause before the (globally known) timeout. This just ensures that the protocol fails safe. Design is up to you - you don't have to use my suggestion. > > > > > > ==Queue size in bytes for informational purposes?== > > Why? This strikes me as like one of those Government forms you > have to fill in > > with an ill-formed question that is mandatory to answer, even > though sometimes > > there is no answer, and you cannot proceed until you've > answered, even though > > the answer is not needed anyway. For instance, if there is a > shared physical > > buffer, a size cannot be straightforwardly given for each > logical buffer. So, > > if buffer size info is not used by the protocol, do not include > it in the > > protocol. > It is largely for reporting to a user/operator for "informational > purposes".  If an implementation chooses, it can put in zero or > infinity.  In most cases I understand this will be a straightforward > value that can be reported to the router and its operators. > [BB] I suggest then that the draft says "A value of zero means unknown or unavailable." > > On the other hand, how is the threshold at which the modem sends > a pause > > configured. Is that out of scope? If so, where is it specified? > [BB] I think this part of the question has been overlooked. > Wherever this > > is specified, it should be possible to specify the threshold in > time units > > (queue delay at the current service rate of the queue), not just > in bytes. This > > is important for queues in a hierarchy where the service rate > varies, e.g. > > dependent on traffic in another queue with priority over it. Or > simply where > > the modem can operate at different rates. > > I think a service rate / queue delay property would be very > interesting > - but this didn't come up in the WG, so I don't think it is > appropriate > to add it here.  There is also nothing preventing such information > being > added in a future extension. > [BB] "Didn't come up in the WG" is surely not a valid excuse - that's why the IETF does out-of-area reviews, isn't it? Measuring queues in time units has become common practice since about 2010, at least in transport circles, in order to better handle variable rate links. > > > > > > ==3.3 Restart== > > > >    "A router which receives the Restart Data Item SHOULD resume > >     transmission of the identified traffic to the modem.." > > > > Why only SHOULD? Under what conditions would it not? > > if it has no data to send. I don't object changing this to a MUST > if you > think important. > > > JD I actually think this should be a MAY but with added text > explaining why data may not be sent to the modem. No data, better > external links, other. [BB] All I am highlighting here is that it's best practice to accompany a 'SHOULD' with an explanation of the cases where the recommendation doesn't apply. And if there are none, then the draft ought to say 'MUST', which makes for simpler code - fewer exceptions to handle. Even if there's no data at the moment, restart surely still means resume transmission (whenever there is data). > > > ==4. Security Considerations== > > > >    "The extension does not inherently > >     introduce any additional vulnerabilities above those > documented in > >     [RFC8175]." > > > > Er, no... What about the ability for an off-path attacker to > stop the router > > sending data!? > > the same attacker can subvert the dlep session an cause a session > reset > and take down all traffic.  So how is this case different? > [BB] Subverting the dlep session is not an additional vulnerability introduced by this extension. Whereas an unauthenticated pause message is an additional vulnerability introduced by this extension. I'm just pointing out that the sentence isn't true. > > > The last part about TLS needs to be worded differently. Because > of the above > > additional vulnerability, the router MUST verify that all 3 > types of message > > are authenticated by the modem. This requires client > authentication mode of > > TLS, which is not mentioned in RFC8175, so it needs to be > mentioned here.  Or > > is the TLS session set up by the router (so the modem is the > authenticated > > server)? Also this raises the question of key management, if > every modem has to > > be authenticated by its router. > > > >     "but this is not a > >     substantively different attack by such a compromised modem > simply > >     dropping all traffic destined to, or sent by a router." > > > > Er, no... The modem does not need to be compromised for a 3rd > party to send > > spoof messages purporting to be from the modem. > > Fair point - how about: > > >    Note that this extension does allow a compromised or impersonating >    modem to suppress transmission by the router.  Similar attacks are >    generally possible base DLEP, for example an impersonating > modem may >    cause a session reset or a compromised modem simply can >    drop all traffic destined to, or sent by a router.    target="RFC8175"/> defines the use of TLS to protect against the >    impersonating attacker. > That's better. But, as I said, I didn't see anything in RFC8175 about using TLS with client authentication. That just might mean I didn't find it. > > > > > ==Nits== > > > > 1. Intro > > "DLEP peers are comprised of a modem and a router" is incorrect > English for > > what you mean (it means that each peer consists of a modem and a > router). > > Better to do away with this sentence completely, and alter to > the previous > > sentence to "It provides the exchange of link related control > information > > between a modem and its DLEP peer router." > > sure. > > > > 3.1 > > s/with Queue Index/ > >   /with a Queue Index/ > > okay > > > Scale: > > s/An 4-bit/ > >   /A 4-bit/ > okay > > In general, I think the term "queue size" is wrongly being used > where "buffer > > size" should be used (the queue size is the varying size of the > queue within > > the buffer at any one time). > > > > Also, pls consistently use the term 'paused' not 'suppressed', > which has the > > potentially ambiguous meaning of 'discarded'. > > will clarify the intent. > > > > Delete gratuitous 'is': > >    "The motivating use case [is] for this > >     data item is when a modem's internal queue length exceeds a > >     particular threshold." > yes, > > > > CURRENT: > >    "e.g., when there > >     a non queue related congestion points within a modem, but > such are > >     not explicitly described in this document." > > SUGGESTED: > >    "e.g., when there > >     are non queue related congestion points within a modem. Such > use-cases are > >     not explicitly described in this document." > > > > > Done! > > Thank you for the comments. > > Lou > > PS the working document has been updated, if interested see > https://github.com/louberger/dlep-extensions/tree/master/pause > Lou, Thx Bob > > _______________________________________________ > > manet mailing list > > manet@ietf.org > > https://www.ietf.org/mailman/listinfo/manet > > > > > _______________________________________________ > Tsv-art mailing list > Tsv-art@ietf.org > https://www.ietf.org/mailman/listinfo/tsv-art -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ --------------FD5971CF5D2A43864D4846F6 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Justin, Lou,

Replying to both at once, inline...

On 11/04/2019 03:25, Justin Dean wrote:
A few comments inline marked JD, Justin Dean WG chair.
On Wed, Apr 10, 2019, 8:41 PM Lou Berger <lberger@labn.net> wrote:
Bob,

Thanks for the comments - see below for responses.

On 4/4/2019 7:56 PM, Bob Briscoe via Datatracker wrote:
> Reviewer: Bob Briscoe
> Review result: On the Right Track
>
> This document has been reviewed as part of the transport area review team's
> ongoing effort to review key IETF documents. These comments were written
> primarily for the transport area directors, but are copied to the document's
> authors and WG to allow them to address any issues raised and also to the IETF
> discussion list for information.
>
> When done at the time of IETF Last Call, the authors should consider this
> review as part of the last-call comments they receive. Please always CC
> tsv-art@ietf.org if you reply to or forward this review.
>
> ==1. Introduction==
>
> It would be useful to describe the use-case where the modem does not implement
> active queue management but the router does, so the modem can use flow control
> to push the queue back into the router, where it can be more intelligently
> controlled.

I guess I'll have to talk to the Shepherd on this one to see how much
he/the WG would want to add on this at this point.  Perhaps giving a
reference to the earlier PPPOE (rfc5578) would suffice, what do you think?
JD will talk with Lou and respond in separate email.

[BB] What I was looking for was some indication of valid and/or invalid use cases. I couldn't find anything about what problem this extension solves.



>
> ===Scope within Intro===
> Please extend the single sentence about scope (end of 2nd para of Intro) to
> explain that pause control only applies to data in the router to modem
> direction.
>
> Please also mention that the scope of pause-based flow control is limited to
> one hop and to a point-to-point link between router and modem, not multipoint.
> The modem does not track the source of the data in its queue, so it cannot
> focus pause messages onto particular sending stations on a multipoint link, or
> onto particular ingress ports of the router.

Done.

>
> Why is the scope limited to DLEP radio links? I would have thought this
> protocol is generally useful between a and modem and router.

Because this is a DLEP extension.  Other mechanisms exist for other
technologies, e.g., RFC5578 or Ethernet PAUSE/PFC.
[BB] OK.



> ==3. Extension Data Items==
>
> Pls define the direction of the messages:
> s/The xxx Data Item is used by a modem to.../
>   /A modem sends the xxx Data Item to its peer router to.../
okay (paraphrase a bit)
>
> ===Unsafe design?===
> Is it not good practice to make the data plane robust to unexpected control
> plane failures (e.g. key expiry, incorrect or mis-timed change of address,
> etc.) and vice versa? So, would it not be more robust for the router to
> time-out a pause if no restart appears? Also, if the last message received
> before shutting down or suspending was a pause, should the router restart or
> resume in the paused state? What if the router enters a power-saving state
> after it is paused and misses a restart message?

I generally agree that a control plane fault should not result in a data
plane loss -- in some environments, I'd say this is a must.  This said,
your comment goes to a design principle in DLEP RFC8175 where control
plane error result in session resets and data plane impacts.  I think
changing this basic behavior of DLEP is beyond the scope of this
extension.  I think a general modification of base DLEP to support such
would be a fine idea.

JD there may be more robust and clever solutions here that don't break the base specification. Absence of an acknowledgement is not the same as an error, syntax or otherwise, which causes a reset. Allowing for a periodic restart message if data does not resume may be sufficient.
[BB] I agree that it should be possible to make pause in itself robust.

My point about control plane errors doesn't have to be taken as an architectural point. I was merely saying that if restart fails for some reason, you don't want data to be paused for ever.

One way to do that is simply to have a globally known constant timeout on a pause. Then, if a modem wants the router to pause longer than this timeout, it has to repeat the pause before the (globally known) timeout. This just ensures that the protocol fails safe.

Design is up to you - you don't have to use my suggestion.



>
> ==Queue size in bytes for informational purposes?==
> Why? This strikes me as like one of those Government forms you have to fill in
> with an ill-formed question that is mandatory to answer, even though sometimes
> there is no answer, and you cannot proceed until you've answered, even though
> the answer is not needed anyway. For instance, if there is a shared physical
> buffer, a size cannot be straightforwardly given for each logical buffer. So,
> if buffer size info is not used by the protocol, do not include it in the
> protocol.
It is largely for reporting to a user/operator for "informational
purposes".  If an implementation chooses, it can put in zero or
infinity.  In most cases I understand this will be a straightforward
value that can be reported to the router and its operators.
[BB] I suggest then that the draft says "A value of zero means unknown or unavailable."

> On the other hand, how is the threshold at which the modem sends a pause
> configured. Is that out of scope? If so, where is it specified?
[BB] I think this part of the question has been overlooked.

Wherever this
> is specified, it should be possible to specify the threshold in time units
> (queue delay at the current service rate of the queue), not just in bytes. This
> is important for queues in a hierarchy where the service rate varies, e.g.
> dependent on traffic in another queue with priority over it. Or simply where
> the modem can operate at different rates.

I think a service rate / queue delay property would be very interesting
- but this didn't come up in the WG, so I don't think it is appropriate
to add it here.  There is also nothing preventing such information being
added in a future extension.

[BB] "Didn't come up in the WG" is surely not a valid excuse - that's why the IETF does out-of-area reviews, isn't it? Measuring queues in time units has become common practice since about 2010, at least in transport circles, in order to better handle variable rate links.



>
> ==3.3 Restart==
>
>    "A router which receives the Restart Data Item SHOULD resume
>     transmission of the identified traffic to the modem.."
>
> Why only SHOULD? Under what conditions would it not?

if it has no data to send. I don't object changing this to a MUST if you
think important.


JD I actually think this should be a MAY but with added text explaining why data may not be sent to the modem. No data, better external links, other.
[BB] All I am highlighting here is that it's best practice to accompany a 'SHOULD' with an explanation of the cases where the recommendation doesn't apply. And if there are none, then the draft ought to say 'MUST', which makes for simpler code - fewer exceptions to handle.

Even if there's no data at the moment, restart surely still means resume transmission (whenever there is data).



> ==4. Security Considerations==
>
>    "The extension does not inherently
>     introduce any additional vulnerabilities above those documented in
>     [RFC8175]."
>
> Er, no... What about the ability for an off-path attacker to stop the router
> sending data!?

the same attacker can subvert the dlep session an cause a session reset
and take down all traffic.  So how is this case different?
[BB] Subverting the dlep session is not an additional vulnerability introduced by this extension.
Whereas an unauthenticated pause message is an additional vulnerability introduced by this extension.

I'm just pointing out that the sentence isn't true.


> The last part about TLS needs to be worded differently. Because of the above
> additional vulnerability, the router MUST verify that all 3 types of message
> are authenticated by the modem. This requires client authentication mode of
> TLS, which is not mentioned in RFC8175, so it needs to be mentioned here.  Or
> is the TLS session set up by the router (so the modem is the authenticated
> server)? Also this raises the question of key management, if every modem has to
> be authenticated by its router.
>
>     "but this is not a
>     substantively different attack by such a compromised modem simply
>     dropping all traffic destined to, or sent by a router."
>
> Er, no... The modem does not need to be compromised for a 3rd party to send
> spoof messages purporting to be from the modem.

Fair point - how about:


   Note that this extension does allow a compromised or impersonating
   modem to suppress transmission by the router.  Similar attacks are
   generally possible base DLEP, for example an impersonating modem may
   cause a session reset or a compromised modem simply can
   drop all traffic destined to, or sent by a router.  <xref
   target="RFC8175"/> defines the use of TLS to protect against the
   impersonating attacker.

That's better.

But, as I said, I didn't see anything in RFC8175 about using TLS with client authentication. That just might mean I didn't find it.



>
> ==Nits==
>
> 1. Intro
> "DLEP peers are comprised of a modem and a router" is incorrect English for
> what you mean (it means that each peer consists of a modem and a router).
> Better to do away with this sentence completely, and alter to the previous
> sentence to "It provides the exchange of link related control information
> between a modem and its DLEP peer router."

sure.


> 3.1
> s/with Queue Index/
>   /with a Queue Index/

okay

> Scale:
> s/An 4-bit/
>   /A 4-bit/
okay
> In general, I think the term "queue size" is wrongly being used where "buffer
> size" should be used (the queue size is the varying size of the queue within
> the buffer at any one time).
>
> Also, pls consistently use the term 'paused' not 'suppressed', which has the
> potentially ambiguous meaning of 'discarded'.

will clarify the intent.


> Delete gratuitous 'is':
>    "The motivating use case [is] for this
>     data item is when a modem's internal queue length exceeds a
>     particular threshold."
yes,
>
> CURRENT:
>    "e.g., when there
>     a non queue related congestion points within a modem, but such are
>     not explicitly described in this document."
> SUGGESTED:
>    "e.g., when there
>     are non queue related congestion points within a modem. Such use-cases are
>     not explicitly described in this document."
>
>
Done!

Thank you for the comments.

Lou

PS the working document has been updated, if interested see
https://github.com/louberger/dlep-extensions/tree/master/pause

Lou, Thx



Bob

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

_______________________________________________
Tsv-art mailing list
Tsv-art@ietf.org
https://www.ietf.org/mailman/listinfo/tsv-art


-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
--------------FD5971CF5D2A43864D4846F6-- From nobody Fri Apr 12 07:13:13 2019 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 AE8A1120759 for ; Fri, 12 Apr 2019 07:13:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FROM_MISSP_EH_MATCH=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 YUVdzDzhZo6I for ; Fri, 12 Apr 2019 07:13:06 -0700 (PDT) Received: from smtp.iit.cnr.it (mx3.iit.cnr.it [146.48.98.150]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CC9D120751 for ; Fri, 12 Apr 2019 07:13:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.iit.cnr.it (Postfix) with ESMTP id 17F5B6005C2 for ; Fri, 12 Apr 2019 16:13:04 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mx3.iit.cnr.it Received: from smtp.iit.cnr.it ([127.0.0.1]) by localhost (mx3.iit.cnr.it [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CJ_QQqwhTek3 for ; Fri, 12 Apr 2019 16:13:01 +0200 (CEST) X-Relay-Autenticated: yes Date: Fri, 12 Apr 2019 16:13:01 +0200 From: Elisabetta Biondi To: manet@ietf.org Message-ID: <5cb09ced./L+l1MxQ6NXTGRlO%elisabetta.biondi@iit.cnr.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: [manet] Extended deadline (May 15, 2019) - Special Issue on on Social and Human Mining with Online Social Networks and Media X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2019 14:13:12 -0000 CALL FOR PAPERS Elsevier - Online Social Networks and Media Journal http://www.journals.elsevier.com/online-social-networks-and-media/ Special Issue on Social and Human Mining with Online Social Networks and Media ****** Deadline for Submissions Extended to May 15, 2019 ****** ************************************************************************************************************************************************************************** Manuscripts can be submitted continuously until the deadline. Once a paper is submitted, the review process will start immediately. Accepted papers will be published continuously in the journal (in the first issue available as soon as the paper is accepted). All accepted papers will be listed together in an online virtual special issue published in the journal website. *************************************************************************************************************************************************************************** Online Social Networks and Media have a high scientific and economic value because the big data collected from these platforms provide a sort of social microscope to investigate and understand human behavior and interests, both in the cyber and in the physical world. The digital footprints that people leave in OSNEM provide a unique source to investigate and understand (by exploiting data mining, machine learning and complex network techniques) people's behavior (e.g., mobility patterns, opinions and interests spreading, polarization), and societal phenomena (the epidemics spreading, the terrorist networks, the diffusion of opinions, the pulse of a city, the spread of fake news, etc.) and develop innovative services. This special issue seeks high-quality scientific articles (both theoretical and experimental) and survey papers focusing on using OSNEM data for modeling and understanding the human and social behavior in the cyber and physical world. Topics include, but are not limited to: - Social media analysis and social analytics; - Measurement, analysis and modeling of social behavior through OSNEM data; - User behavior modeling with OSNEM data; - Analysis of the use of OSNEM in the urban context; - OSNEM data for Open Source Intelligence - Multidisciplinary applications of OSNEM (economics, medicine, society, politics, homeland security, etc.); - Dynamics of trends, information and opinion diffusion in OSNEM; - Recommendations and advertising in OSNEM; - Spread of news, topics, and opinions; - Modelling and characterisation of societal debates and polarization in OSNEM; - Influence analysis and social influence; - Identification of diffusion sources and influencers; - Establishment and perception of trust and reputation in OSNEM; - Detection/containment of fake news and related sources; - Modelling/analysis/countermeasures to formation of echo chambers; - Methods to modify/control/maximise information and opinion diffusion; - Data-driven approaches to study information and opinion diffusion in OSNEM; Guest Editors Marco Conti, IIT-CNR, Italy Andrea Passarella, IIT-CNR, Italy *** Instructions for submission *** Manuscripts must not have been previously published nor currently under review by other journals or conferences. Papers previously published in conference proceedings are eligible for submission if the submitted manuscript is a substantial revision and extension of the conference version. In this case, authors should indicate the previous publication(s) in the cover letter and are also required to submit their published conference article(s) and a summary document explaining the enhancements made in the journal version. The submission website for this journal is located at https://www.evise.com/profile/#/OSNEM/login. Please select "SI_Social&Human_Mining" when you reach the "Article Type" step in the submission process. To ensure that all manuscripts are correctly identified, for consideration by the special issue, the authors should indicate in the cover letter that the manuscript has been submitted for the special issue on Social and Human Mining with Online Social Networks and Media. For further information, please contact the guest editors at {m.conti,a.passarella} at iit.cnr.it From nobody Mon Apr 22 21:44:19 2019 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 E7A9112026B; Mon, 22 Apr 2019 21:44:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Barry Leiba via Datatracker To: "The IESG" Cc: draft-ietf-manet-dlep-multi-hop-extension@ietf.org, Stan Ratliff , aretana.ietf@gmail.com, manet@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.95.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Barry Leiba Message-ID: <155599465094.21034.6351688185828206651.idtracker@ietfa.amsl.com> Date: Mon, 22 Apr 2019 21:44:10 -0700 Archived-At: Subject: [manet] Barry Leiba's No Objection on draft-ietf-manet-dlep-multi-hop-extension-06: (with COMMENT) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.29 List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Apr 2019 04:44:11 -0000 Barry Leiba has entered the following ballot position for draft-ietf-manet-dlep-multi-hop-extension-06: No Objection 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-multi-hop-extension/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Section 5.3 creates a registry that includes a Specification Required policy, which has a designated expert reviewing a specification and deciding whether to approve the registration request. It would be useful to have at least brief guidance to the designated expert about what to consider when making that decision. Should the only issue be whether the specification is sufficiently clear and complete? Or are there other considerations that might warrant push-back to a registration request? From nobody Thu Apr 25 09:13:31 2019 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 61EBC12006F for ; Thu, 25 Apr 2019 09:13:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=unavailable 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 2JjBEISbOE1m for ; Thu, 25 Apr 2019 09:13:27 -0700 (PDT) Received: from gproxy5-pub.mail.unifiedlayer.com (gproxy5-pub.mail.unifiedlayer.com [67.222.38.55]) (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 A1694120048 for ; Thu, 25 Apr 2019 09:13:27 -0700 (PDT) Received: from cmgw15.unifiedlayer.com (unknown [10.9.0.15]) by gproxy5.mail.unifiedlayer.com (Postfix) with ESMTP id 33173140D6A for ; Thu, 25 Apr 2019 09:45:18 -0600 (MDT) Received: from box313.bluehost.com ([69.89.31.113]) by cmsmtp with ESMTP id JgYohEn2UszDUJgYohOtdc; Thu, 25 Apr 2019 09:45:18 -0600 X-Authority-Reason: nr=8 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:References:Cc: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=W8NP2q7utFe7mDuRGMcwjb5rwE5eEfKn8AXAeL4qMk0=; b=yiiUsLKofbYakOwajzFolzTLch Re3YgkYgzULaQHh+79qAP11W7pGKk0kwXvnVqA0gBb04F1qn/i4UsvqHmqbImVqf+DeT9jaZqAMSc 6PpplMFCgWaQL9PLYB+mDdRqD; Received: from pool-72-66-11-201.washdc.fios.verizon.net ([72.66.11.201]:52238 helo=fs2.dc.labn.net) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from ) id 1hJgYn-002hh8-Se; Thu, 25 Apr 2019 09:45:17 -0600 To: Bob Briscoe , tsv-art@ietf.org Cc: draft-ietf-manet-dlep-multi-hop-extension.all@ietf.org, manet@ietf.org, ietf@ietf.org References: <155480892243.14232.8537433440288444332@ietfa.amsl.com> From: Lou Berger Openpgp: preference=signencrypt Autocrypt: addr=lberger@labn.net; prefer-encrypt=mutual; keydata= mQENBERW5dYBCAC1Bjgr/mVovBhi1rbqkowJShVtvLitNEGOTd6RtmwO7FPebg61J9+kRFTz 1wt869yiAjtQO1EtQs26QFTH5ZDZJU/LDAOzxTi12mpBic+AWI8W0yrB1C+KOZ0gw2p7Vnfj EKc3ohwkCICHTnZ3blO8Mslb4qHGxDm7Uy3luRjvH1ZDifuZvfFHcHVw2dJyGwLg2MhXCqpo OyUqFN0tlGqz1TOCAy3/IMG6OdNK27DGF5+vJyIqek/2xkIVDOLgzVCek3dARLqPP37W1Lx2 uXJUsgcJ7t7om5AEV2LTFrafvAvJbKLT9RZ0fgF4LXeRTIVlFXKkvYJFgygW+r4JCTvHABEB AAG0HUxvdSBCZXJnZXIgPGxiZXJnZXJAbGFibi5uZXQ+iQGHBBABAgBxBQJEVuXyMBSAAAAA ACAAB3ByZWZlcnJlZC1lbWFpbC1lbmNvZGluZ0BwZ3AuY29tcGdwbWltZQcLCQgHAwIKAhkB GRhsZGFwOi8va2V5c2VydmVyLnBncC5jb20FGwMAAAADFgIBBR4BAAAABBUICQoACgkQgbLN W8HBX9eB9QgAl8/lFnNh43at51P//sRX8cDg33C/biok8st8Fff0Y/6p+6HkYKQcxiuZuOLr HHtBFxTdMGfFrlJIFob/N6m92CwVwoTRZu8QIe68DLewd+72PIEzvlSy/iTq3e91XqfGWCE7 oqw7H/weJJlB7yzPWXra/BwgPD+WkTxUiKeG2F2HzBTQfBQ6VpHiMqW6AL0jcCh/Drya93ZA aAdWfW2ywVPqIKETZIk04SBsZCw9WESB2If/NqeZu/DNwBg4FsXCrfp3WfMSTkYmfT3zcU11 MpKcv20YUpG8Jf9lyMY1DgMHHdpUHdjo/fuLz4aVSQvt8EygRSzCxGWOWb89bUosAbkBDQRE VuXXAQgApBEy7m0+xMm4SEcQtFi/UQQqjVOllc2227M1ypbcEMRa46Tq6p0P5QBM9C9pxjAl tyI2m3hzvBxBJNnjknXTp875DGyj/yDwj9VeA18Tj9q6PRsJIxAnGKBgWO0yGdZLpsp0AN5n kMamxdVFGYojzUiwkPBayST6sEUp33o4xHsx99TA2bFxZRj6k0igWgdrPVq4qeEgD1l7Cl3f pj96owzm+7wecswAts2b545gfR4/V/Vx3VUebETR/LwMDecXokP5fiDAIRHhEUi/+FXcwg6w 6jtPilFcJ64HJP6P81OUdfeMDUxvSmbeRqXaZrbRN+hF6XfWODTKepsqPaX8TQARAQABiQEi BBgBAgAMBQJEVuXXBRsMAAAAAAoJEIGyzVvBwV/XUcMH/2eB6dvsP52su9KgaDHqsgPbxF21 AQL9oDCheN+AJKD3Eouj/d/MbQdsp/M/pjgTAqB3G4/rtoyJw+BDjnvZwdUe4HQ656IPZOub e10sOgq1taJQZtQIl+mWKURMGlIihScYeuGfi/1RzMqXeCcFW63n5POVG55FzU8B7DBwQ2oJ Zy7NL0YVbT0ROXGson6WHLhzGnVP8CjHq5TN5co/FH/2BntaQIdSaOmTqN+vy38KkRsYa3cx k9eTbP99ypebZclmw6kxlOZGl9DBp4qNkTn/7LgQ7iZNVyESs9rSE7hQXnmfM+C+TCpeZo62 8AwC5SYEqa5YlkpgsP0NIEMAIoU= Message-ID: <8b06996c-a16f-cf33-2c78-8a4733522ac6@labn.net> Date: Thu, 25 Apr 2019 11:45:16 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 In-Reply-To: <155480892243.14232.8537433440288444332@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US 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: 72.66.11.201 X-Source-L: No X-Exim-ID: 1hJgYn-002hh8-Se X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-72-66-11-201.washdc.fios.verizon.net (fs2.dc.labn.net) [72.66.11.201]:52238 X-Source-Auth: lberger@labn.net X-Email-Count: 5 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== X-Local-Domain: yes Archived-At: Subject: Re: [manet] Tsvart last call review of draft-ietf-manet-dlep-multi-hop-extension-06 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Apr 2019 16:13:30 -0000 Hi Bob, Sorry for the late reply. See below for specific responses. On 4/9/19 7:22 AM, Bob Briscoe via Datatracker wrote: > Reviewer: Bob Briscoe > Review result: Ready with Issues > > This document has been reviewed as part of the transport area review team's > ongoing effort to review key IETF documents. These comments were written > primarily for the transport area directors, but are copied to the document's > authors and WG to allow them to address any issues raised and also to the IETF > discussion list for information. > > When done at the time of IETF Last Call, the authors should consider this > review as part of the last-call comments they receive. Please always CC > tsv-art@ietf.org if you reply to or forward this review. > > AFAICT, there's nothing technically wrong, but I believe the authors use of > normative text does not convey the meaning they intended, in nearly every case. > It will be seen below that there seems to be a general misunderstanding of the > use of, 'SHOULD do X' when there will never be a case when X should not be > done. 'SHOULD' and 'MAY' need to be used judiciously, because they make > interoperability harder. > > ==Inappropriate Normative Text== > > S.2. > "The use of the Multi-Hop Forwarding Extension SHOULD be configurable. " > {I think you mean it SHOULD be possible to enable/disable the extension? To me that's what this says. > On a > modem. a router or both? yes, by any node that supports the extension. > In what circumstances would it not be configurable (if > none, then MUST would be appropriate)? We generally don't stop people from building products that meet their specific market requirements as long as there's no interop issue, hence the SHOULD vs MUST.> What happens if one device uses the > extension and another doesn't? This last question also applies for incremental > deployment.} This is covered in the base DLEP RFC. > > S.3.1. > "The Hop Count Data Item SHOULD be carried in the Destination Up, Destination > Update, Destination Announce Response, and Link Characteristics Response > messages." {I don't think the use of "SHOULD" here achieves what you intend. I > think you're trying to say that this data item can only be carried in these 4 > messages. But what you've said is that all these messages SHOULD contain a Hop > Count data item. If any normative text is needed here, I think it would say > this data item MUST NOT be carried in messages other than these 4. But maybe > just substitute 'SHOULD' with 'can'?} > I'd be fine with MAY as this is more aligned with RFC8175 statement of what DIs to carry in a message. This siad, I believe the feeling was that MAY was too weak for an extension-specific DI. Unless there is strong objection with this, I'm inclined to leave it with how the WG approved it. > S.3.2. > The Hop Control Data Item MAY be carried in a Session Update Message sent by a > router when the control applies to the whole device, or a Link Characteristics > Request Message when the control applies to a particular destination. {Again, I > think you're trying to say, "If used, the Hop Control Data Item MUST only be > carried in" ...one of these two message types.} > > "A modem that receives the Hop Control Data Item in a [XXX] Message SHOULD take > whatever actions are needed to make the change indicated by the data item for > [YYY]." (two occurrences) {Inappropriate use of SHOULD: a) Surely a modem MUST > "take whatever actions are needed." Why would it not? b) Anyway, it's > meaningless to normatively require a vaguely defined action} > > S.3.2.3 Direction Connection this should be Direct Connection > > "It indicates that the modem SHOULD attempt to establish a direct connection > with the destination identified in the message." {I think you mean 'MUST'. Why > would it not even attempt to?} > local policy, or that it know that a connection is no longer possible. > "This action SHOULD only be sent for destinations for which the Hop Count is > greater than 1 and has the P-Bit set in the previously received Hop Count Data > Item." {I think you mean MUST. Why would it be sent otherwise?} A must would translate to a dlep error on the receiving side, which would translate to a session reset, which is really disruptive. > > S.3.2.4. Suppress Forwarding > I suggest that you don't gratuitously switch from 'MUST' to 'SHALL' just for > this section? Many implementers search the text for 'MUST'. > > ==Authentication== > > S.4. > RFC8175 says > 'For all "networked deployments" ..., the implementation and use of TLS are > STRONGLY RECOMMENDED.' > > I believe it would be worth identifying which extensions would be unsafe if TLS > were not used. Certainly all the Multi-Hop Extensions would be unsafe if not > authenticated. umm, I think all of DLEP would be unsafe without TLS, or some other equivalent, e.g., macsec. > > ==General Nits== > Inappropriate and/or inconsistent capitalization of certain phrases, like 'Data > Item' or 'Action' or 'Message'. > > ==Specific Nits== > I've provided suggested corrections in the following xml files: > http://bobbriscoe.net/tmp/draft-ietf-manet-dlep-multi-hop-extension-06_BB.xml > http://bobbriscoe.net/tmp/draft-ietf-manet-dlep-multi-hop-extension-06_BB.txt > http://bobbriscoe.net/tmp/draft-ietf-manet-dlep-multi-hop-extension-06_BB-DIFF-06.html Thanks! I've pushed changes to https://github.com/louberger/dlep-extensions and will coordinate an update with the AD. Lou > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > From nobody Mon Apr 29 06:38:44 2019 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 1057A1202FF; Mon, 29 Apr 2019 06:38:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?Mirja_K=C3=BChlewind_via_Datatracker?= To: "The IESG" Cc: draft-ietf-manet-dlep-multi-hop-extension@ietf.org, Stan Ratliff , aretana.ietf@gmail.com, manet-chairs@ietf.org, sratliff@idirect.net, manet@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.95.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: =?utf-8?q?Mirja_K=C3=BChlewind?= Message-ID: <155654512305.15899.6671265788242474328.idtracker@ietfa.amsl.com> Date: Mon, 29 Apr 2019 06:38:43 -0700 Archived-At: Subject: [manet] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft?= =?utf-8?q?-ietf-manet-dlep-multi-hop-extension-06=3A_=28with_COMMENT=29?= X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.29 List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Apr 2019 13:38:43 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-manet-dlep-multi-hop-extension-06: No Objection 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-multi-hop-extension/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- 1) Maybe this is a bit of a blunt question because I might not know enough about DLEP but how does a modem know the number of hops? Is there any need to say something more about how to gather this information in the document? 2) Should the security consideration section maybe also say something about the frequency of re-configurations? Maybe that should be limited, also in order to not generate a large amount of signalling messages that could congest the link. Maybe you want to at least limit the rate of messages sent such that multiple re-configuration could be covered by one message in case there is a high rate of re-configurations. Or is there already such a limit in DLEP? If yes, it would be good to state that explicitly in this document as well. nits: - There seems to be a text fragment (“example using .”) in the intro text: “This document refers to forwarding by intermediate modems as 'multi-hop forwarding'. example using . DLEP Destination messages can be used to …” - Sec 3.1: s/to indicate the number of modem/to indicate the number of modems/ -> plural: modemS From nobody Mon Apr 29 09:47:03 2019 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 66FB0120491; Mon, 29 Apr 2019 09:46:52 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Martin Vigoureux via Datatracker To: "The IESG" Cc: draft-ietf-manet-dlep-multi-hop-extension@ietf.org, Stan Ratliff , aretana.ietf@gmail.com, manet-chairs@ietf.org, sratliff@idirect.net, manet@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.95.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Martin Vigoureux Message-ID: <155655641240.15821.2941396884107276101.idtracker@ietfa.amsl.com> Date: Mon, 29 Apr 2019 09:46:52 -0700 Archived-At: Subject: [manet] Martin Vigoureux's No Objection on draft-ietf-manet-dlep-multi-hop-extension-06: (with COMMENT) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.29 List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Apr 2019 16:47:01 -0000 Martin Vigoureux has entered the following ballot position for draft-ietf-manet-dlep-multi-hop-extension-06: No Objection 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-multi-hop-extension/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Hi, thank you for this Document. I have a couple of questions regarding: The absence of the Hop Count Data Item MUST be interpreted by the router as a Hop Count value of one (1). I know it is a bit nit-picking but would it be worth explicitly saying that this applies only in the case where the Multi-Hop Forwarding capability has been successfully negotiated? regarding: Once the change is made, or fails or is rejected, the modem MUST respond with a Session Update Response Message with an appropriate Status Code. I think you should specify which status code to use depending on the situation. In sections 3.2.2 and .3 you have a requirement that says: "... MUST NOT be sent in a Session Update Message message" but in 3.2 you have some generic piece of text which says: A modem that receives the Hop Control Data Item in a Session Update Message SHOULD take whatever actions are needed to make the change indicated by the data item for all known destinations. So if a router does not respect the MUST NOT then a modem might try to take some actions based on something it should have received. Maybe it would be worth completing the "MUST NOT send" requirement with a "MUST discard/return error/log" type of requirement. By the way, I'm not sure that the should in "... SHOULD take whatever actions ..." should be in caps. The actions that to be taken are described in detail in 3.2.1 to 3.2.4 and are not all SHOULDs (MUST clear, SHOULD attempt to establish, MUST suppress). Thanks From nobody Tue Apr 30 13:55:17 2019 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 CCFD712016C; Tue, 30 Apr 2019 13:55:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?=C3=89ric_Vyncke_via_Datatracker?= To: "The IESG" Cc: draft-ietf-manet-dlep-multi-hop-extension@ietf.org, Stan Ratliff , aretana.ietf@gmail.com, manet-chairs@ietf.org, sratliff@idirect.net, manet@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.95.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: =?utf-8?q?=C3=89ric_Vyncke?= Message-ID: <155665770683.7513.15170951043940666155.idtracker@ietfa.amsl.com> Date: Tue, 30 Apr 2019 13:55:06 -0700 Archived-At: Subject: [manet] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-iet?= =?utf-8?q?f-manet-dlep-multi-hop-extension-06=3A_=28with_COMMENT=29?= X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.29 List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Apr 2019 20:55:07 -0000 Éric Vyncke has entered the following ballot position for draft-ietf-manet-dlep-multi-hop-extension-06: No Objection 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-multi-hop-extension/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Clear and easy to read. == NITS == Section 1, there is a dangling ". example using ." Section 3.2, the use of a 16-bit value for Hop Control Action suggest that there could be more than 4 values (indeed there is a IANA request for a registry for this field), suggest to mention that there could be more than 4 values in this section From nobody Tue Apr 30 23:52:51 2019 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 A332312009A; Tue, 30 Apr 2019 23:52:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Adam Roach via Datatracker To: "The IESG" Cc: draft-ietf-manet-dlep-multi-hop-extension@ietf.org, Stan Ratliff , aretana.ietf@gmail.com, manet-chairs@ietf.org, sratliff@idirect.net, manet@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.95.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Adam Roach Message-ID: <155669356166.28950.1240248164467860361.idtracker@ietfa.amsl.com> Date: Tue, 30 Apr 2019 23:52:41 -0700 Archived-At: Subject: [manet] Adam Roach's No Objection on draft-ietf-manet-dlep-multi-hop-extension-06: (with COMMENT) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.29 List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 May 2019 06:52:42 -0000 Adam Roach has entered the following ballot position for draft-ietf-manet-dlep-multi-hop-extension-06: No Objection 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-multi-hop-extension/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks to everyone who worked on this document. I have only two editorial comments. --------------------------------------------------------------------------- Please expand "DLEP" in the title and the abstract. See https://www.rfc-editor.org/materials/abbrev.expansion.txt for guidance. --------------------------------------------------------------------------- §1: > DLEP peers are comprised of a modem and a router. Nit: This should be either "DLEP peers are composed of a modem and a router." or "DLEP peers comprise a modem and a router."