From nobody Wed May 3 06:54:01 2017 Return-Path: X-Original-To: lp-wan@ietf.org Delivered-To: lp-wan@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DF3C7128B88; Wed, 3 May 2017 06:53:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: lp-wan@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149381963954.21418.9914613475603000592@ietfa.amsl.com> Date: Wed, 03 May 2017 06:53:59 -0700 Archived-At: Subject: [lp-wan] IPv6 over Low Power Wide-Area Networks (lpwan) WG Virtual Meeting: 2017-05-24 X-BeenThere: lp-wan@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Low-Power Wide Area Networking \(LP-WAN\), also known as LPWA or Low-Rate WAN \(LR-WAN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2017 13:54:00 -0000 The IPv6 over Low Power Wide-Area Networks (lpwan) Working Group will hold a virtual interim meeting on 2017-05-24 from 16:00 to 17:00 Europe/Paris. Agenda: The meeting agenda will be adjusted with appropriate information before the meeting (1 week before the meeting at the latest). The general topics will include presentations and discussions on updates / reviews / implementation feedback on the WG documents. - SCHC IP/UDP draft update from previous virtual interim meeting ( draft-ietf-lpwan-ipv6-static-context-hc- ?? ) - SCHC CoAP draft update from previous virtual interim meeting ( draft-ietf-lpwan-coap-static-context-hc- ?? ) - LPWAN Overview document update from previous virtual interim meeting ( draft-ietf-lpwan-overview- ?? ) ---------------------- Information on joining the meeting: JOIN WEBEX MEETING https://cisco.webex.com/ciscosales/j.php?MTID=me7f536292c568c696a054a7ff7ef0746 Meeting number (access code): 203 453 401 Meeting password: chicalors (24422567 from phones) JOIN FROM A VIDEO SYSTEM OR APPLICATION Dial sip:203453401@cisco.webex.com >From the Cisco internal network, dial *267* and the 9-digit meeting number. If you are the host, enter your PIN when prompted. JOIN BY PHONE +1-866-432-9903 Call-in toll-free number (US/Canada) +1-408-525-6800 Call-in toll number (US/Canada) Global call-in numbers: https://cisco.webex.com/ciscosales/globalcallin.php?serviceType=MC&ED=370387747&tollFree=1 Toll-free dialing restrictions: https://www.webex.com/pdf/tollfree_restrictions.pdf Can't join the meeting? https://help.webex.com/docs/DOC-5412 Information about remote participation: https://cisco.webex.com/ciscosales/j.php?MTID=me7f536292c568c696a054a7ff7ef0746 (see Agenda for password/details how to join) From nobody Wed May 3 06:55:48 2017 Return-Path: X-Original-To: lp-wan@ietf.org Delivered-To: lp-wan@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FFC412955D; Wed, 3 May 2017 06:55:39 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: lp-wan@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149381973907.21451.11069741832302730117@ietfa.amsl.com> Date: Wed, 03 May 2017 06:55:39 -0700 Archived-At: Subject: [lp-wan] IPv6 over Low Power Wide-Area Networks (lpwan) WG Virtual Meeting: 2017-06-07 X-BeenThere: lp-wan@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Low-Power Wide Area Networking \(LP-WAN\), also known as LPWA or Low-Rate WAN \(LR-WAN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2017 13:55:39 -0000 The IPv6 over Low Power Wide-Area Networks (lpwan) Working Group will hold a virtual interim meeting on 2017-06-07 from 16:00 to 17:00 Europe/Paris. Agenda: The meeting agenda will be adjusted with appropriate information before the meeting (1 week before the meeting at the latest). The general topics will include presentations and discussions on updates / reviews / implementation feedback on the WG documents. - SCHC IP/UDP draft update from previous virtual interim meeting ( draft-ietf-lpwan-ipv6-static-context-hc- ?? ) - SCHC CoAP draft update from previous virtual interim meeting ( draft-ietf-lpwan-coap-static-context-hc- ?? ) - LPWAN Overview document update from previous virtual interim meeting ( draft-ietf-lpwan-overview- ?? ) ---------------------- Information on joining the meeting: JOIN WEBEX MEETING https://cisco.webex.com/ciscosales/j.php?MTID=me7f536292c568c696a054a7ff7ef0746 Meeting number (access code): 203 453 401 Meeting password: chicalors (24422567 from phones) JOIN FROM A VIDEO SYSTEM OR APPLICATION Dial sip:203453401@cisco.webex.com >From the Cisco internal network, dial *267* and the 9-digit meeting number. If you are the host, enter your PIN when prompted. JOIN BY PHONE +1-866-432-9903 Call-in toll-free number (US/Canada) +1-408-525-6800 Call-in toll number (US/Canada) Global call-in numbers: https://cisco.webex.com/ciscosales/globalcallin.php?serviceType=MC&ED=370387747&tollFree=1 Toll-free dialing restrictions: https://www.webex.com/pdf/tollfree_restrictions.pdf Can't join the meeting? https://help.webex.com/docs/DOC-5412 Information about remote participation: https://cisco.webex.com/ciscosales/j.php?MTID=me7f536292c568c696a054a7ff7ef0746 (see Agenda for password/details how to join) From nobody Wed May 3 07:20:11 2017 Return-Path: X-Original-To: lp-wan@ietfa.amsl.com Delivered-To: lp-wan@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B9641252BA for ; Wed, 3 May 2017 07:20:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.52 X-Spam-Level: X-Spam-Status: No, score=-1.52 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] 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 ZW7H82j8zAZW for ; Wed, 3 May 2017 07:20:06 -0700 (PDT) Received: from dash.upc.es (dash.upc.es [147.83.2.50]) (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 34D8F129789 for ; Wed, 3 May 2017 07:17:31 -0700 (PDT) Received: from entelserver.upc.edu (entelserver.upc.es [147.83.39.4]) by dash.upc.es (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id v43EHT91051546 for ; Wed, 3 May 2017 16:17:29 +0200 Received: from webmail.entel.upc.edu (webmail.entel.upc.edu [147.83.39.6]) by entelserver.upc.edu (Postfix) with ESMTP id DDF721D53C1; Wed, 3 May 2017 16:17:28 +0200 (CEST) Received: from 81.38.55.229 by webmail.entel.upc.edu with HTTP; Wed, 3 May 2017 16:17:25 +0200 Message-ID: Date: Wed, 3 May 2017 16:17:25 +0200 From: "Carles Gomez Montenegro" To: lp-wan@ietf.org User-Agent: SquirrelMail/1.4.21-1.fc14 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: clamav-milter 0.99.2 at dash X-Virus-Status: Clean X-Greylist: ACL matched, not delayed by milter-greylist-4.3.9 (dash.upc.es [147.83.2.50]); Wed, 03 May 2017 16:17:29 +0200 (CEST) Archived-At: Subject: [lp-wan] Fragmentation: retries after L2 MTU decrease X-BeenThere: lp-wan@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Low-Power Wide Area Networking \(LP-WAN\), also known as LPWA or Low-Rate WAN \(LR-WAN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2017 14:20:09 -0000 Hi everyone, In some LPWAN technologies, the L2 MTU is variable. This means that the following issue may arise for the "reliable" fragment delivery options we are designing. If a fragment needs to be retransmitted, but the L2 MTU has decreased since the original transmission of the fragment (so that the original fragment is larger than the current L2 MTU), how should the situation be handled? A few options may be: 1.- Abort the on-going transmission of the carried IPv6 datagram. 2.- Perform some form of re-fragmentation (not currently supported by the SCHC&F document, and potentially complex). 3.- Defer the decision on how to proceed to technology-specific profiles. Would the WG have any preference among these (or other) options? Thanks, Carles From nobody Wed May 3 07:46:25 2017 Return-Path: X-Original-To: lp-wan@ietfa.amsl.com Delivered-To: lp-wan@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F76E129AB5 for ; Wed, 3 May 2017 07:46:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.5 X-Spam-Level: X-Spam-Status: No, score=-1.5 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3] 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 4xmrzLIGc62w for ; Wed, 3 May 2017 07:46:22 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (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 A835912778D for ; Wed, 3 May 2017 07:43:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v43EhmHZ000409; Wed, 3 May 2017 16:43:48 +0200 (CEST) Received: from [192.168.217.113] (p5DC7F3A7.dip0.t-ipconnect.de [93.199.243.167]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3wJ1BC6dkPzDJDk; Wed, 3 May 2017 16:43:47 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Carsten Bormann X-Priority: 3 (Normal) In-Reply-To: Date: Wed, 3 May 2017 16:43:46 +0200 Cc: lp-wan@ietf.org X-Mao-Original-Outgoing-Id: 515515426.232114-f745739cc9f523a5d693973da29a5d44 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Carles Gomez Montenegro X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [lp-wan] Fragmentation: retries after L2 MTU decrease X-BeenThere: lp-wan@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Low-Power Wide Area Networking \(LP-WAN\), also known as LPWA or Low-Rate WAN \(LR-WAN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2017 14:46:24 -0000 On May 3, 2017, at 16:17, Carles Gomez Montenegro = wrote: >=20 > 2.- Perform some form of re-fragmentation (not currently supported by = the > SCHC&F document, and potentially complex). As I said in the call: =E2=80=94 retransmissions are less likely than main line transmissions =E2=80=94 any bit spent in a retransmission format is therefore less = expensive than in the main line transmission format =E2=80=94 let=E2=80=99s trade complexity for a few more (not so often = exercised) bits here. With this approach, a retransmission can break out of the mould that the = original transmission created. Gr=C3=BC=C3=9Fe, Carsten From nobody Wed May 3 08:04:44 2017 Return-Path: X-Original-To: lp-wan@ietf.org Delivered-To: lp-wan@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 00F9B12948E; Wed, 3 May 2017 08:04:35 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: lp-wan@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149382387484.21423.1265869270124179410@ietfa.amsl.com> Date: Wed, 03 May 2017 08:04:34 -0700 Archived-At: Subject: [lp-wan] IPv6 over Low Power Wide-Area Networks (lpwan) WG Virtual Meeting: 2017-06-21 X-BeenThere: lp-wan@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Low-Power Wide Area Networking \(LP-WAN\), also known as LPWA or Low-Rate WAN \(LR-WAN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2017 15:04:35 -0000 The IPv6 over Low Power Wide-Area Networks (lpwan) Working Group will hold a virtual interim meeting on 2017-06-21 from 16:00 to 17:00 Europe/Paris. Agenda: This is the last virtual interim meeting before the IETF draft submission cut-off date. The meeting agenda will be adjusted with appropriate information before the meeting (1 week before the meeting at the latest). The general topics will include presentations and discussions on updates / reviews / implementation feedback on the WG documents. - SCHC IP/UDP draft update from previous virtual interim meeting ( draft-ietf-lpwan-ipv6-static-context-hc- ?? ) - SCHC CoAP draft update from previous virtual interim meeting ( draft-ietf-lpwan-coap-static-context-hc- ?? ) - LPWAN Overview document update from previous virtual interim meeting ( draft-ietf-lpwan-overview- ?? ) ---------------------- Information on joining the meeting: JOIN WEBEX MEETING https://cisco.webex.com/ciscosales/j.php?MTID=me7f536292c568c696a054a7ff7ef0746 Meeting number (access code): 203 453 401 Meeting password: chicalors (24422567 from phones) JOIN FROM A VIDEO SYSTEM OR APPLICATION Dial sip:203453401@cisco.webex.com >From the Cisco internal network, dial *267* and the 9-digit meeting number. If you are the host, enter your PIN when prompted. JOIN BY PHONE +1-866-432-9903 Call-in toll-free number (US/Canada) +1-408-525-6800 Call-in toll number (US/Canada) Global call-in numbers: https://cisco.webex.com/ciscosales/globalcallin.php?serviceType=MC&ED=370387747&tollFree=1 Toll-free dialing restrictions: https://www.webex.com/pdf/tollfree_restrictions.pdf Can't join the meeting? https://help.webex.com/docs/DOC-5412 Information about remote participation: https://cisco.webex.com/ciscosales/j.php?MTID=me7f536292c568c696a054a7ff7ef0746 (see Agenda for password/details how to join) From nobody Wed May 3 08:21:54 2017 Return-Path: X-Original-To: lp-wan@ietfa.amsl.com Delivered-To: lp-wan@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92DE4126CD6 for ; Wed, 3 May 2017 08:21:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.702 X-Spam-Level: X-Spam-Status: No, score=-4.702 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=-2.8, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sigfoxgroup.onmicrosoft.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 29lOrVReb1tQ for ; Wed, 3 May 2017 08:21:50 -0700 (PDT) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0132.outbound.protection.outlook.com [104.47.1.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDBC412009C for ; Wed, 3 May 2017 08:19:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sigfoxgroup.onmicrosoft.com; s=selector1-sigfox-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=dNBl+IBFVNOjLAo7F4OTArq5mZXOZxInqBPSMw4WXD4=; b=S0KIhG0YWM9MG8tzRyTg2qDKlnhuLs0Ynr7M7NcNeFvpjXyr7pGIfIeymhdz00pJ2JEMaQRO+nLhUPwyHIiMVFJxd13yenCE+L/XWD6X8yjnfjFcjF52BUBPKqVq7eqqsD2ALlAqk6EHM4nCoFWmpd+yAUXqi3OxU7h9qjzwJfQ= Received: from DB6PR08MB2679.eurprd08.prod.outlook.com (10.175.235.12) by DB6PR08MB2677.eurprd08.prod.outlook.com (10.175.235.10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1061.12; Wed, 3 May 2017 15:19:04 +0000 Received: from DB6PR08MB2679.eurprd08.prod.outlook.com ([10.175.235.12]) by DB6PR08MB2679.eurprd08.prod.outlook.com ([10.175.235.12]) with mapi id 15.01.1061.019; Wed, 3 May 2017 15:19:04 +0000 From: Juan Carlos Zuniga To: Carsten Bormann , Carles Gomez Montenegro CC: "lp-wan@ietf.org" Thread-Topic: [lp-wan] Fragmentation: retries after L2 MTU decrease Thread-Index: AQHSxBhjMd9Fk9RcVkGZjNHsV21vXqHiryUAgAAJTjA= Date: Wed, 3 May 2017 15:19:04 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: tzi.org; dkim=none (message not signed) header.d=none;tzi.org; dmarc=none action=none header.from=sigfox.com; x-originating-ip: [104.163.151.155] x-microsoft-exchange-diagnostics: 1; DB6PR08MB2677; 7:cApBkR5E2FUTAPe5bSDsh1kbJIoJdGSVdG+SKKKZrkIepKid5C9XXW0b5ThFitS4rQY1Ed7MGyS4l4Ib5mmNlyBIfbMxbAaCQiD/Xy0kPDMX0jEcK78kca4iK2//OxZgEG/E3PThjgv64lXB8fhKutlkc/1pr8TdT2r38Ubk/9tE0PkW7vzkB2nng26indMBrNH6zap1vUe+Yh4dZB4f0EsgOGFpvwalqYiqNtQVGLDjAk8K3KixRHY4Glr4OjttL8qFrcBHmkGUlvdgEoZwR2IMajstpnGiUHzGg+cJfMT1u1DlsYCDKsmUT2qBQgs4lM/E8MrD8sIQpwkdPaT9kg== x-ms-office365-filtering-correlation-id: 9748e26f-b282-47e0-0bf6-08d49237bc27 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081)(201702281549075); SRVR:DB6PR08MB2677; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(93006095)(93001095)(6041248)(20161123564025)(20161123562025)(20161123560025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(6072148); SRVR:DB6PR08MB2677; BCL:0; PCL:0; RULEID:; SRVR:DB6PR08MB2677; x-forefront-prvs: 029651C7A1 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39830400002)(39450400003)(39400400002)(377454003)(24454002)(13464003)(77096006)(53936002)(38730400002)(9686003)(229853002)(6246003)(99286003)(55016002)(2171002)(74316002)(7696004)(25786009)(3280700002)(8936002)(2906002)(6436002)(54356999)(122556002)(76176999)(6506006)(2950100002)(7736002)(4326008)(305945005)(50986999)(189998001)(6306002)(66066001)(33656002)(478600001)(8676002)(3846002)(86362001)(3660700001)(5660300001)(81166006)(102836003)(6116002); DIR:OUT; SFP:1102; SCL:1; SRVR:DB6PR08MB2677; H:DB6PR08MB2679.eurprd08.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: sigfox.com X-MS-Exchange-CrossTenant-originalarrivaltime: 03 May 2017 15:19:04.2520 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: fcbc8bb1-061e-4b94-9f70-3ad917b0c8d3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR08MB2677 Archived-At: Subject: Re: [lp-wan] Fragmentation: retries after L2 MTU decrease X-BeenThere: lp-wan@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Low-Power Wide Area Networking \(LP-WAN\), also known as LPWA or Low-Rate WAN \(LR-WAN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2017 15:21:52 -0000 SSBhZ3JlZSB3aXRoIENhcnN0ZW4uIEZvciBMUFdBTiwgc2ltcGxpY2l0eSBpcyBLaW5nLg0KDQpJ ZiB0aGVyZSBpcyBhIHNtYXJ0ZXIgd2F5IHRvIGF2b2lkL3JlY3VwZXJhdGUgZnJvbSB0aGlzIHNp dHVhdGlvbiwgaXQgY291bGQgZXZlbnR1YWxseSBiZSBkZXNjcmliZWQgaW4gdGhlIHNwZWNpZmlj IHRlY2hub2xvZ3kgcHJvZmlsZS4NCg0KQ2hlZXJzLA0KDQpKdWFuIENhcmxvcyANCg0KDQo+IC0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IGxwLXdhbiBbbWFpbHRvOmxwLXdhbi1i b3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQ2Fyc3RlbiBCb3JtYW5uDQo+IFNlbnQ6IE1h eSAzLCAyMDE3IDEwOjQ0IEFNDQo+IFRvOiBDYXJsZXMgR29tZXogTW9udGVuZWdybyA8Y2FybGVz Z29AZW50ZWwudXBjLmVkdT4NCj4gQ2M6IGxwLXdhbkBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTog W2xwLXdhbl0gRnJhZ21lbnRhdGlvbjogcmV0cmllcyBhZnRlciBMMiBNVFUgZGVjcmVhc2UNCj4g DQo+IE9uIE1heSAzLCAyMDE3LCBhdCAxNjoxNywgQ2FybGVzIEdvbWV6IE1vbnRlbmVncm8NCj4g PGNhcmxlc2dvQGVudGVsLnVwYy5lZHU+IHdyb3RlOg0KPiA+DQo+ID4gMi4tIFBlcmZvcm0gc29t ZSBmb3JtIG9mIHJlLWZyYWdtZW50YXRpb24gKG5vdCBjdXJyZW50bHkgc3VwcG9ydGVkIGJ5IHRo ZQ0KPiA+ICAgIFNDSEMmRiBkb2N1bWVudCwgYW5kIHBvdGVudGlhbGx5IGNvbXBsZXgpLg0KPiAN Cj4gQXMgSSBzYWlkIGluIHRoZSBjYWxsOg0KPiANCj4g4oCUIHJldHJhbnNtaXNzaW9ucyBhcmUg bGVzcyBsaWtlbHkgdGhhbiBtYWluIGxpbmUgdHJhbnNtaXNzaW9ucyDigJQgYW55IGJpdCBzcGVu dA0KPiBpbiBhIHJldHJhbnNtaXNzaW9uIGZvcm1hdCBpcyB0aGVyZWZvcmUgbGVzcyBleHBlbnNp dmUgdGhhbiBpbiB0aGUgbWFpbiBsaW5lDQo+IHRyYW5zbWlzc2lvbiBmb3JtYXQg4oCUIGxldOKA mXMgdHJhZGUgY29tcGxleGl0eSBmb3IgYSBmZXcgbW9yZSAobm90IHNvIG9mdGVuDQo+IGV4ZXJj aXNlZCkgYml0cyBoZXJlLg0KPiANCj4gV2l0aCB0aGlzIGFwcHJvYWNoLCBhIHJldHJhbnNtaXNz aW9uIGNhbiBicmVhayBvdXQgb2YgdGhlIG1vdWxkIHRoYXQgdGhlDQo+IG9yaWdpbmFsIHRyYW5z bWlzc2lvbiBjcmVhdGVkLg0KPiANCj4gR3LDvMOfZSwgQ2Fyc3Rlbg0KPiANCj4gX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gbHAtd2FuIG1haWxpbmcg bGlzdA0KPiBscC13YW5AaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9scC13YW4NCg== From nobody Wed May 3 11:39:41 2017 Return-Path: X-Original-To: lp-wan@ietfa.amsl.com Delivered-To: lp-wan@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AD11127078 for ; Wed, 3 May 2017 11:39:39 -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_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8] 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 TiM0pGuJZXvO for ; Wed, 3 May 2017 11:39:37 -0700 (PDT) Received: from relay9-d.mail.gandi.net (relay9-d.mail.gandi.net [217.70.183.199]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66351129564 for ; Wed, 3 May 2017 11:37:22 -0700 (PDT) Received: from relay6-d.mail.gandi.net (relay6-d.mail.gandi.net [217.70.183.198]) by relay9-d.mail.gandi.net (Postfix) with ESMTPS id C3335406FB for ; Wed, 3 May 2017 20:37:20 +0200 (CEST) Received: from mfilter6-d.gandi.net (mfilter6-d.gandi.net [217.70.178.135]) by relay6-d.mail.gandi.net (Postfix) with ESMTP id A76C5FB87D for ; Wed, 3 May 2017 20:37:20 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter6-d.gandi.net Received: from relay6-d.mail.gandi.net ([IPv6:::ffff:217.70.183.198]) by mfilter6-d.gandi.net (mfilter6-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id wVQsQ2naCjEA for ; Wed, 3 May 2017 20:37:18 +0200 (CEST) X-Originating-IP: 31.38.76.100 Received: from [192.168.1.81] (mal35-h02-31-38-76-100.dsl.sta.abo.bbox.fr [31.38.76.100]) (Authenticated sender: alex@ackl.io) by relay6-d.mail.gandi.net (Postfix) with ESMTPSA id 99803FB88B for ; Wed, 3 May 2017 20:37:17 +0200 (CEST) From: Alexander Pelov Content-Type: multipart/alternative; boundary="Apple-Mail=_65825D9F-6672-42B6-97F0-F0852A55AFF9" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: <21BBB8D5-9578-4D22-9C3B-ECCA59CFB205@ackl.io> Date: Wed, 3 May 2017 20:37:18 +0200 To: lp-wan X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [lp-wan] Agenda for LPWAN WG Interim, Wed., May 10th, 2017 X-BeenThere: lp-wan@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Low-Power Wide Area Networking \(LP-WAN\), also known as LPWA or Low-Rate WAN \(LR-WAN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2017 18:39:39 -0000 --Apple-Mail=_65825D9F-6672-42B6-97F0-F0852A55AFF9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Connection details Date: May, 10th, 7-8am US Pacific, 4pm CEST: = https://www.worldtimebuddy.com/?qm=3D1&lid=3D100,12,5392171,1850147&h=3D10= 0&date=3D2017-05-10&sln=3D14-15 = Webex Link: = https://cisco.webex.com/ciscosales/j.php?MTID=3Dme7f536292c568c696a054a7ff= 7ef0746 = Meeting number (access code): 203 453 401=20 Meeting password: chicalors (24422567 from phones) Agenda [2min] Administrivia Agenda bashing Approval minutes from last meeting [5 min] LPWAN Overview - update from last meeting (Steve) WI-SUN update, others [40min] SCHC IP/UDP (Laurent, Ana, Carles) [10min] SCHC CoAP (Laurent) [3min] AOB As usual, please let the chairs (cc) know if you wish to add/modify = agenda items. =20 The chairs --Apple-Mail=_65825D9F-6672-42B6-97F0-F0852A55AFF9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

Connection details

Agenda

  • [2min] Administrivia
    • Agenda bashing
    • Approval minutes from last meeting
  • [5 = min]  LPWAN Overview - update from last meeting  (Steve)
    • WI-SUN update, = others
  • [40min] SCHC IP/UDP (Laurent, Ana, Carles)
  • [10min] SCHC CoAP = (Laurent)
  • [3min] = AOB
As usual, = please let the chairs (cc) know if you wish to add/modify agenda = items.
 
The chairs

= --Apple-Mail=_65825D9F-6672-42B6-97F0-F0852A55AFF9-- From nobody Wed May 3 14:31:07 2017 Return-Path: X-Original-To: lp-wan@ietfa.amsl.com Delivered-To: lp-wan@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72F1F129C0C for ; Wed, 3 May 2017 14:31:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.101 X-Spam-Level: X-Spam-Status: No, score=0.101 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 raaHSuSYU_6I for ; Wed, 3 May 2017 14:31:02 -0700 (PDT) Received: from relay4-d.mail.gandi.net (relay4-d.mail.gandi.net [IPv6:2001:4b98:c:538::196]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1891A129329 for ; Wed, 3 May 2017 14:29:12 -0700 (PDT) Received: from 2a01cb088947ca00e8aea64de82ce14d.ipv6.abo.wanadoo.fr (2a01cb088947ca00e8aea64de82ce14d.ipv6.abo.wanadoo.fr [IPv6:2a01:cb08:8947:ca00:e8ae:a64d:e82c:e14d]) (Authenticated sender: ana@ackl.io) by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id 718731720D9; Wed, 3 May 2017 23:29:09 +0200 (CEST) From: Ana Minaburo Content-Type: multipart/alternative; boundary="Apple-Mail=_B9C03C71-8389-4D61-B7E4-217917499A8B" Date: Wed, 3 May 2017 23:29:09 +0200 Message-Id: Cc: "Pascal Thubert (pthubert)" , Alexander Pelov To: lp-wan Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [lp-wan] Terminology for LPWAN Networks X-BeenThere: lp-wan@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Low-Power Wide Area Networking \(LP-WAN\), also known as LPWA or Low-Rate WAN \(LR-WAN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2017 21:31:05 -0000 --Apple-Mail=_B9C03C71-8389-4D61-B7E4-217917499A8B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hello, I have started doing a list for the most important terms we use on the = SCHC drafts, first I put all the names we have used to define the same = concept, second I put the name we have defined in the drafts, and last I = put one proposition, please feel free to agree or not about this = proposed terms. Thanks Ana Used on draft = draft-overview or and draft-SCHC Proposed = =20 End-System, device, Thing , Host, node Host or Thing = THING (THG)=20 LPWAN Application Server, Application Server Application Server = Application (APP) Network Gateway = Router or Network Gateway LPWAN Gateway (LGW) = =20 LPWAN C/D (LC) LC = (LPWAN Compressor) SCHC C/D = Compression/Decompression Function (CDF) CDF C/D Function = C/D Action (CDA)=20 --Apple-Mail=_B9C03C71-8389-4D61-B7E4-217917499A8B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hello,

I = have started doing a list for the most important terms we use on the = SCHC drafts, first I put all the names we have used to define the same = concept, second I put the name we have defined in the drafts, and last I = put one proposition, please feel free to agree or not about this = proposed terms.

Thanks
Ana


   Used on draft =                    =   =         draft-overview or and = draft-SCHC =    Proposed       =     
 End-System, = device, Thing , Host, node             =       Host or Thing   =        THING = (THG) 
LPWAN = Application Server,  Application  Server       =  Application Server             =                   =  Application = (APP)
Network Gateway =                     =                     =               Router or Network = Gateway                  LPWAN Gateway  (LGW) =               =  
LPWAN C/D (LC) =     LC (LPWAN Compressor) =                    SCHC C/D       =                     =      Compression/Decompression Function (CDF)   =        CDF C/D Function         =                 C/D Action = (CDA) 

= --Apple-Mail=_B9C03C71-8389-4D61-B7E4-217917499A8B-- From nobody Wed May 3 17:13:25 2017 Return-Path: X-Original-To: lp-wan@ietfa.amsl.com Delivered-To: lp-wan@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3932128D6F for ; Wed, 3 May 2017 17:13:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sigfoxgroup.onmicrosoft.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 Sb6SRTeHR-5t for ; Wed, 3 May 2017 17:13:19 -0700 (PDT) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0106.outbound.protection.outlook.com [104.47.1.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 594B0126CBF for ; Wed, 3 May 2017 17:13:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sigfoxgroup.onmicrosoft.com; s=selector1-sigfox-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=p60h3wiRiMDCfTd4+Gix5FFPw4JwzHqm7y9ooyoIw/s=; b=IKoOKTHzWy6vnOaU0yhdQ2r9LvPpdg8NzWWpkEDpQQ5wnbksvzKNI0n8EuT6EIKxfY8Jm0MoGaSeNv348lpNh+wkdeO9wL4nWrTvO203Gq9uvtKq6aI2szqVYNmvWBI8VWnyIIQW0PzrONy3Mr5Cee1qYZoC1ZofbVRLx0Kpsbg= Received: from DB6PR08MB2679.eurprd08.prod.outlook.com (10.175.235.12) by DB6PR08MB2679.eurprd08.prod.outlook.com (10.175.235.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1061.12; Thu, 4 May 2017 00:13:15 +0000 Received: from DB6PR08MB2679.eurprd08.prod.outlook.com ([10.175.235.12]) by DB6PR08MB2679.eurprd08.prod.outlook.com ([10.175.235.12]) with mapi id 15.01.1061.019; Thu, 4 May 2017 00:13:15 +0000 From: Juan Carlos Zuniga To: Ana Minaburo , lp-wan CC: "Pascal Thubert (pthubert)" , Alexander Pelov Thread-Topic: [lp-wan] Terminology for LPWAN Networks Thread-Index: AQHSxFSWerpJg/NtSUO8xRlKseoaXKHjTHPw Date: Thu, 4 May 2017 00:13:15 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ackl.io; dkim=none (message not signed) header.d=none;ackl.io; dmarc=none action=none header.from=sigfox.com; x-originating-ip: [104.163.151.155] x-microsoft-exchange-diagnostics: 1; DB6PR08MB2679; 7:jM3qbGelB9dklut8DgymBuJzqy6fkAwruSSKD6aByZeIcWjo7BdK5hmFZtxj6pwM08cl86HoMMGajwvxQKXKQjvJhRuxBKXdn9CEt2c7eD05lscTipJoX3ZEEIvS2Z8s2QYkuECjToG5xuH75Dux85pVk1hg6zyGwYQRACivAslzy4k4/JoddtTRKI8VTSQ76QWJYHBAO3DN1IJUiaLmk7iLGyyTrtf+IO3/4f2bR17W6hxxAph0KjtsMTsET/9Mn7ELd4kPoOYS1B5oaAqh1RLMP9GlQmyjrzLLdTAgjJV4SYb9btitC8Kn68LHicYcCm6qdMZ7I/OAnLt7m6ey6A== x-ms-office365-filtering-correlation-id: 884e01d9-85f1-4d63-926a-08d492825c49 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081)(201702281549075); SRVR:DB6PR08MB2679; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(95692535739014)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3002001)(6041248)(20161123562025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123555025)(20161123564025)(6072148); SRVR:DB6PR08MB2679; BCL:0; PCL:0; RULEID:; SRVR:DB6PR08MB2679; x-forefront-prvs: 02973C87BC x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39400400002)(39830400002)(39410400002)(39450400003)(377454003)(189998001)(77096006)(6116002)(54906002)(790700001)(4326008)(38730400002)(7736002)(3660700001)(50986999)(9326002)(3846002)(53936002)(102836003)(8936002)(5660300001)(33656002)(6246003)(122556002)(54356999)(9686003)(74316002)(6306002)(6436002)(229853002)(478600001)(2900100001)(76176999)(66066001)(81166006)(99286003)(54896002)(53546009)(2906002)(8676002)(6506006)(2950100002)(86362001)(3280700002)(25786009)(55016002)(7696004); DIR:OUT; SFP:1102; SCL:1; SRVR:DB6PR08MB2679; H:DB6PR08MB2679.eurprd08.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DB6PR08MB267937C672A452C983E4B1EE89EA0DB6PR08MB2679eurp_" MIME-Version: 1.0 X-OriginatorOrg: sigfox.com X-MS-Exchange-CrossTenant-originalarrivaltime: 04 May 2017 00:13:15.6060 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: fcbc8bb1-061e-4b94-9f70-3ad917b0c8d3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR08MB2679 Archived-At: Subject: Re: [lp-wan] Terminology for LPWAN Networks X-BeenThere: lp-wan@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Low-Power Wide Area Networking \(LP-WAN\), also known as LPWA or Low-Rate WAN \(LR-WAN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2017 00:13:23 -0000 --_000_DB6PR08MB267937C672A452C983E4B1EE89EA0DB6PR08MB2679eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Ana, >From the review I have started on draft-SCHC, I think the proposed terms wo= uld add a lot of clarity to the explanations. Using more intuitive acronyms= would be very helpful, especially to external readers. I support using the Proposed list of terms throughout all drafts. Best, Juan Carlos From: lp-wan [mailto:lp-wan-bounces@ietf.org] On Behalf Of Ana Minaburo Sent: May 3, 2017 5:29 PM To: lp-wan Cc: Pascal Thubert (pthubert) ; Alexander Pelov Subject: [lp-wan] Terminology for LPWAN Networks Hello, I have started doing a list for the most important terms we use on the SCHC= drafts, first I put all the names we have used to define the same concept,= second I put the name we have defined in the drafts, and last I put one pr= oposition, please feel free to agree or not about this proposed terms. Thanks Ana Used on draft = draft-overview or and draft-SCHC Proposed End-System, device, Thing , Host, node Host or Thing = THING (THG) LPWAN Application Server, Application Server Application Server = Application (APP) Network Gateway Route= r or Network Gateway LPWAN Gateway (LGW) LPWAN C/D (LC) = LC (LPWAN Compressor) SCHC C/D = Compression/Decompression Function (CDF) CD= F C/D Function C/D Action (CDA) --_000_DB6PR08MB267937C672A452C983E4B1EE89EA0DB6PR08MB2679eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Ana,

 =

From the review I have s= tarted on draft-SCHC, I think the proposed terms would add a lot of clarity= to the explanations. Using more intuitive acronyms would be very helpful, especially to external readers.

 =

I support using the Prop= osed list of terms throughout all drafts.

 =

Best,<= /p>

 =

Juan Carlos

 =

From: = lp-wan [mailto:lp-wan-bounces@ietf.org] On Behalf Of Ana Minaburo
Sent: May 3, 2017 5:29 PM
To: lp-wan <lp-wan@ietf.org>
Cc: Pascal Thubert (pthubert) <pthubert@cisco.com>; Alexander = Pelov <alexander@ackl.io>
Subject: [lp-wan] Terminology for LPWAN Networks

 

Hello,

 

I have started doing a list for the most important t= erms we use on the SCHC drafts, first I put all the names we have used to d= efine the same concept, second I put the name we have defined in the drafts= , and last I put one proposition, please feel free to agree or not about this proposed terms.

 

Thanks

Ana

 

 

   Used on d= raft                    &= nbsp;      &nb= sp;            =              &n= bsp;          draft-overview or and draft-SCHC        = ;              Proposed  &nbs= p;            &= nbsp;            

 End-System, device, Thing , Host, node   =                 Host or Thing        &n= bsp;            = ;             &= nbsp;                 THING (THG) 

LPWAN Application Server,  Application  Se= rver        Application Server       &nb= sp;                     &= nbsp;  Application (APP)

Network Gateway           &= nbsp;                    =                     &nbs= p; Router or Network Gateway             &nbs= p;    LPWAN Gateway  (LGW)  =              

LPWAN C/D (LC) &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;             =             &nb= sp;             LC (LPWAN Compressor)         &nbs= p;          SCHC C/D=                   &nbs= p;            Compression/Decompression Funct= ion (CDF)          CDF C/D Function                             = ;     C/D Action (CDA) 

 

--_000_DB6PR08MB267937C672A452C983E4B1EE89EA0DB6PR08MB2679eurp_-- From nobody Wed May 3 17:30:09 2017 Return-Path: X-Original-To: lp-wan@ietfa.amsl.com Delivered-To: lp-wan@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63A34129409 for ; Wed, 3 May 2017 17:30:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=earthlink.net; domainkeys=pass (2048-bit key) header.from=charles.perkins@earthlink.net header.d=earthlink.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 yOG_QSLT9-L9 for ; Wed, 3 May 2017 17:30:05 -0700 (PDT) Received: from elasmtp-junco.atl.sa.earthlink.net (elasmtp-junco.atl.sa.earthlink.net [209.86.89.63]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5EE2E128D6F for ; Wed, 3 May 2017 17:30:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=earthlink.net; s=dk12062016; t=1493857805; bh=y5sQHdpyFajfY8NosH3KZQxH33jR39y8qWrk knaR+0k=; h=Received:Subject:To:References:Cc:From:Message-ID:Date: User-Agent:MIME-Version:In-Reply-To:Content-Type:X-ELNK-Trace: X-Originating-IP; b=bZD9OKjbQTaLJHeWhN7rhbEcyvRo0yId2V+0zRE6ez+EaY CHj8be73k7QK4bttnTUtv0/m6PbY8rEtMyL4ltWPD6NGojonWCx9cgfUNeHFO/btrk7 8YK2GZb12xRA9PXD//uGnRqCUds8f40bl7r3Jp9c3D51yBTI+Pgli+f2uuz9x54sVdM 7OYC2za5ZItBbp7rKTBfne3xY7L+iexD71+fRaxLPnlXnJeqvM8x6NL8yVK4XFvTi/p IlH1H9LCspOnXB003X15i0o5cPRfG95MZDmDMu80ZCvOnxA2ypd/HgIoCtuRXzZaxxN tfCDaJQUZhM3QW8pETTiEWWLa/1A== DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk12062016; d=earthlink.net; b=ALkTO2Hx9cr7m3/gGf+KW8qrXOa1unh7nJTUAuNrLyc57GjyJF2iJoDYL1uk3QrVCX8jAuk0mkrpBS5IpQLRyoDGvYDh/ZHzF5KtPBP3xAHlXCUqtzBjxZAciXhIFzFatqAnU+x48yldk2JjXhDXxR8Gcrau93ZCw97mGcKrjDFDuxmEg91bczrTu82k1nsB7xqLp3jGE23eCFi6CZY7anh5xsWuJ9KyDeUjOKIWNnGJqL/hvTkWvrNu9zaER93P4xEcN0+L5PVt29J706KBhbLadlmeRvJR3pxzw7XfEeTNymte2whOQ+Z5N6UfDoctHyrQeXKGjoJD2oodCVVWDw==; h=Received:Subject:To:References:Cc:From:Message-ID:Date:User-Agent:MIME-Version:In-Reply-To:Content-Type:X-ELNK-Trace:X-Originating-IP; Received: from [99.51.72.196] (helo=[192.168.1.82]) by elasmtp-junco.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1d64eg-0005pv-AP; Wed, 03 May 2017 20:30:02 -0400 To: Ana Minaburo , lp-wan References: Cc: "Pascal Thubert (pthubert)" , Alexander Pelov From: Charlie Perkins Message-ID: Date: Wed, 3 May 2017 17:29:59 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------65F73E7F5BC57323A2047173" X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956527bd5036cbc8ac78105ad209567dd64b65641dc50d5514a350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.51.72.196 Archived-At: Subject: Re: [lp-wan] Terminology for LPWAN Networks X-BeenThere: lp-wan@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Low-Power Wide Area Networking \(LP-WAN\), also known as LPWA or Low-Rate WAN \(LR-WAN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2017 00:30:07 -0000 This is a multi-part message in MIME format. --------------65F73E7F5BC57323A2047173 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Hello Ana, I am O.K. with all of the terms except "thing". It seems to me that particular term is irretrievably ambiguous, and does not offer any helpful intuition about the intended meaning. The result would be that it would be harder to write unambiguous specifications, and suddenly other words like "anything" and "something" would become dangerous. I would be happy with any of the other terms. I have often used "device" for this meaning. Regards, Charlie P. On 5/3/2017 2:29 PM, Ana Minaburo wrote: > Hello, > > I have started doing a list for the most important terms we use on the > SCHC drafts, first I put all the names we have used to define the same > concept, second I put the name we have defined in the drafts, and last > I put one proposition, please feel free to agree or not about this > proposed terms. > > Thanks > Ana > > > Used on draft draft-overview or and draft-SCHC Proposed > End-System, device, Thing , Host, node Host or ThingTHING (THG) > LPWAN Application Server, Application Server Application Server > Application (APP) > Network Gateway Router or Network Gateway LPWAN > Gateway (LGW) > LPWAN C/D (LC) LC (LPWAN Compressor) SCHC C/D > Compression/Decompression Function (CDF) CDF C/D FunctionC/D > Action (CDA) > > > > _______________________________________________ > lp-wan mailing list > lp-wan@ietf.org > https://www.ietf.org/mailman/listinfo/lp-wan --------------65F73E7F5BC57323A2047173 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

Hello Ana,

I am O.K. with all of the terms except "thing".  It seems to me that particular term is irretrievably ambiguous, and does not offer any helpful intuition about the intended meaning.  The result would be that it would be harder to write unambiguous specifications, and suddenly other words like "anything" and "something" would become dangerous.  I would be happy with any of the other terms.  I have often used "device" for this meaning.

Regards,
Charlie P.


On 5/3/2017 2:29 PM, Ana Minaburo wrote:
Hello,

I have started doing a list for the most important terms we use on the SCHC drafts, first I put all the names we have used to define the same concept, second I put the name we have defined in the drafts, and last I put one proposition, please feel free to agree or not about this proposed terms.

Thanks
Ana


   Used on draft                              draft-overview or and draft-SCHC    Proposed           
 End-System, device, Thing , Host, node                   Host or Thing          THING (THG) 
LPWAN Application Server,  Application  Server        Application Server                                Application (APP)
Network Gateway                                                       Router or Network Gateway                  LPWAN Gateway  (LGW)                
LPWAN C/D (LC)     LC (LPWAN Compressor)                    SCHC C/D                                Compression/Decompression Function (CDF)          CDF C/D Function                         C/D Action (CDA) 



_______________________________________________
lp-wan mailing list
lp-wan@ietf.org
https://www.ietf.org/mailman/listinfo/lp-wan

--------------65F73E7F5BC57323A2047173-- From nobody Thu May 4 00:24:27 2017 Return-Path: X-Original-To: lp-wan@ietfa.amsl.com Delivered-To: lp-wan@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCDFE129BBD for ; Thu, 4 May 2017 00:24:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.5 X-Spam-Level: X-Spam-Status: No, score=-1.5 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3] 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 bj1rxB60UykT for ; Thu, 4 May 2017 00:24:23 -0700 (PDT) Received: from violet.upc.es (violet.upc.es [147.83.2.51]) (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 21C5C129BCC for ; Thu, 4 May 2017 00:24:18 -0700 (PDT) Received: from entelserver.upc.edu (entelserver.upc.es [147.83.39.4]) by violet.upc.es (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id v447OGAE051064 for ; Thu, 4 May 2017 09:24:16 +0200 Received: from webmail.entel.upc.edu (webmail.entel.upc.edu [147.83.39.6]) by entelserver.upc.edu (Postfix) with ESMTP id 90E311D53C1; Thu, 4 May 2017 09:24:16 +0200 (CEST) Received: from 81.38.55.229 by webmail.entel.upc.edu with HTTP; Thu, 4 May 2017 09:24:13 +0200 Message-ID: <436545e6e9e599f8a40dfa8b1de3fc8a.squirrel@webmail.entel.upc.edu> Date: Thu, 4 May 2017 09:24:13 +0200 From: "Carles Gomez Montenegro" To: lp-wan@ietf.org User-Agent: SquirrelMail/1.4.21-1.fc14 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: clamav-milter 0.99.2 at violet X-Virus-Status: Clean X-Greylist: Delayed for 17:06:47 by milter-greylist-4.3.9 (violet.upc.es [147.83.2.51]); Thu, 04 May 2017 09:24:16 +0200 (CEST) Archived-At: Subject: [lp-wan] Fragmentation header format for retries X-BeenThere: lp-wan@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Low-Power Wide Area Networking \(LP-WAN\), also known as LPWA or Low-Rate WAN \(LR-WAN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2017 07:24:26 -0000 Hi everyone, As discussed recently, a solution for avoiding possible ambiguity for fragment retries in Packet mode is to define a specific fragmentation header format for retries (i.e. different from the one used for first transmission attempts), possibly using more bits. Two options for fragmentation header formats for retries are the following. Option 1 ******** <------------- R ------------> <- T -> <------ A ------> +---- ... ---+- ... -+------ ... -----+ | Rule ID | DTag | AFN | +---- ... ---+- ... -+------ ... -----+ AFN stands for Absolute Fragment Number. Size A may be greater than the size of the CFN field. Note that with A = 8 bits, all fragments of a 1280-byte packet can be unambiguously numbered over all LPWAN technologies currently considered by the WG. This option has the following characteristics: - It avoids ambiguity. - It is perfectly compatible with current bitmap-based feedback from the receiver. - It does *not* support L2 MTU decrease after original fragment transmissions. Option 2 ******** <------------- R ------------> <- T -> <-------- F -------> +---- ... ---+- ... -+-------- ... ------+ | Rule ID | DTag | datagram_offset | +---- ... ---+- ... -+-------- ... ------+ datagram_offset specifies the offset, in increments of 1 octet, of the fragment from the beginning of the payload datagram. The default size of this field is 11 bit. This option has the following characteristics: - It avoids ambiguity. - It supports L2 MTU decrease after original fragment transmissions. - If L2 MTU decrease happens, it is not so nicely compatible with the current bitmap-based feedback from the receiver. The bitmap bits refer to 'original' fragments, so fine-grained feedback for 'subfragments of fragments' is not possible with the current approach. Coarse-grained feedback (i.e. 'some part of this original fragment is missing' or 'the original fragment has been completely received') is still possible, but that would mean potentially more retransmissions than strictly needed for all 'subfragments of fragments' corresponding to some original fragment. ---- With the aim of structuring a little bit this discussion: A.- Do we (as a WG) require to support L2 MTU decrease (after original fragment transmission) for retries, i.e. sending 'subfragments of fragments'? (If the answer is No, I would propose going for Option 1.) B.- If the answer is Yes, would the coarse-grained feedback for Option 2 be acceptable? (If Yes, this could be considered for Window mode as well to support L2 MTU decrease...) If L2 MTU decrease (after original fragment transmissions) is to be supported, it would be necessary to have some characterization of such events. How likely are they? How likely is it e.g. that a fragment needs to be subdivided, first in a subfragment of 50% the original size and then, after another L2 MTU decrease, the rest needs to be subdivided further as e.g. 2 subfragments of 25% original size each? (I wonder if the receiver will be able to provide feedback at the subfragment level at all...) Comments on these (or other) options are very much welcome! Thanks, Carles From patrickinney@gmail.com Thu May 4 05:44:08 2017 Return-Path: X-Original-To: lp-wan@ietfa.amsl.com Delivered-To: lp-wan@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35049127735 for ; Thu, 4 May 2017 05:44:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.233 X-Spam-Level: X-Spam-Status: No, score=-1.233 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_SOFTFAIL=0.665] 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 5lrhuXn_PnZw for ; Thu, 4 May 2017 05:44:06 -0700 (PDT) Received: from p3plsmtpa11-09.prod.phx3.secureserver.net (p3plsmtpa11-09.prod.phx3.secureserver.net [68.178.252.110]) (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 59295126E01 for ; Thu, 4 May 2017 05:44:06 -0700 (PDT) Received: from [10.0.1.5] ([24.13.37.133]) by :SMTPAUTH: with SMTP id 6G6Ydm4ZrVlT56G6Yd6UrD; Thu, 04 May 2017 05:43:35 -0700 X-Sender: pat.kinney@kinneyconsultingllc.com From: Pat Kinney Message-Id: <114B5D9F-4000-43BA-B0F7-EB071FA2A11C@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_E9EBC53B-999E-42A7-B9AE-180B8670DA74" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 4 May 2017 07:43:33 -0500 In-Reply-To: Cc: Ana Minaburo , lp-wan , Thubert Pascal , Alexander Pelov To: Charlie Perkins References: X-Mailer: Apple Mail (2.3273) X-CMAE-Envelope: MS4wfP8eV4Mj7j76Igtf4KdxLnOJdfwK14R3J/p+0OTxFsh1Yo42icCqdo7qAUVn1ciUsjldBViv47vXtwOsNBGU3hXOhQjdP+folO0s9OODWeR5q+FAoeY1 Nycn0ExerfTjZGJ8qmvUIQeSqe1Ad+XpMZz4/E6Duf5hqasMY4ShaDjf1siz4r5Oh7Wvj6RoKGWqSFKlliIUTWua+q+TDgoT+AeJ1CN0HCpnESNW9usWzyuU 9m6sakjjiJbhTPwDn6hM8kVKvB0vjbcqski8JoKi0yG9CEoXgjLPvVW3Bjmya94m Archived-At: X-Mailman-Approved-At: Thu, 04 May 2017 05:57:49 -0700 Subject: Re: [lp-wan] Terminology for LPWAN Networks X-BeenThere: lp-wan@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Low-Power Wide Area Networking \(LP-WAN\), also known as LPWA or Low-Rate WAN \(LR-WAN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2017 12:45:32 -0000 --Apple-Mail=_E9EBC53B-999E-42A7-B9AE-180B8670DA74 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I agree with Charlie, his rationale is solid. In addition to the terms = written below I have also seen Back-end used. Best Regards,=20 Pat Kinney On 3, May2017, at 19:29, Charlie Perkins = wrote: Hello Ana, I am O.K. with all of the terms except "thing". It seems to me that = particular term is irretrievably ambiguous, and does not offer any = helpful intuition about the intended meaning. The result would be that = it would be harder to write unambiguous specifications, and suddenly = other words like "anything" and "something" would become dangerous. I = would be happy with any of the other terms. I have often used "device" = for this meaning. Regards, Charlie P. On 5/3/2017 2:29 PM, Ana Minaburo wrote: > Hello, >=20 > I have started doing a list for the most important terms we use on the = SCHC drafts, first I put all the names we have used to define the same = concept, second I put the name we have defined in the drafts, and last I = put one proposition, please feel free to agree or not about this = proposed terms. >=20 > Thanks > Ana >=20 >=20 > Used on draft = draft-overview or and draft-SCHC Proposed = =20 > End-System, device, Thing , Host, node Host or = Thing THING (THG)=20 > LPWAN Application Server, Application Server Application = Server Application (APP) > Network Gateway = Router or Network Gateway LPWAN Gateway (LGW) = =20 > LPWAN C/D (LC) = LC (LPWAN Compressor) SCHC C/D = Compression/Decompression Function (CDF) CDF C/D = Function C/D Action (CDA)=20 >=20 >=20 >=20 > _______________________________________________ > lp-wan mailing list > lp-wan@ietf.org > https://www.ietf.org/mailman/listinfo/lp-wan = _______________________________________________ lp-wan mailing list lp-wan@ietf.org https://www.ietf.org/mailman/listinfo/lp-wan Pat Kinney pat.kinney@kinneyconsultingllc.com --Apple-Mail=_E9EBC53B-999E-42A7-B9AE-180B8670DA74 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii I agree with Charlie, his rationale is solid.  In addition to the terms written below I have also seen Back-end used.

Best Regards, 
Pat Kinney

On 3, May2017, at 19:29, Charlie Perkins <charles.perkins@earthlink.net> wrote:

Hello Ana,

I am O.K. with all of the terms except "thing".  It seems to me that particular term is irretrievably ambiguous, and does not offer any helpful intuition about the intended meaning.  The result would be that it would be harder to write unambiguous specifications, and suddenly other words like "anything" and "something" would become dangerous.  I would be happy with any of the other terms.  I have often used "device" for this meaning.

Regards,
Charlie P.


On 5/3/2017 2:29 PM, Ana Minaburo wrote:
Hello,

I have started doing a list for the most important terms we use on the SCHC drafts, first I put all the names we have used to define the same concept, second I put the name we have defined in the drafts, and last I put one proposition, please feel free to agree or not about this proposed terms.

Thanks
Ana


   Used on draft                              draft-overview or and draft-SCHC    Proposed           
 End-System, device, Thing , Host, node                   Host or Thing          THING (THG) 
LPWAN Application Server,  Application  Server        Application Server                                Application (APP)
Network Gateway                                                       Router or Network Gateway                  LPWAN Gateway  (LGW)                
LPWAN C/D (LC)     LC (LPWAN Compressor)                    SCHC C/D                                Compression/Decompression Function (CDF)          CDF C/D Function                         C/D Action (CDA) 



_______________________________________________
lp-wan mailing list
lp-wan@ietf.org
https://www.ietf.org/mailman/listinfo/lp-wan

_______________________________________________
lp-wan mailing list
lp-wan@ietf.org
https://www.ietf.org/mailman/listinfo/lp-wan


--Apple-Mail=_E9EBC53B-999E-42A7-B9AE-180B8670DA74-- From nobody Thu May 4 06:03:12 2017 Return-Path: X-Original-To: lp-wan@ietfa.amsl.com Delivered-To: lp-wan@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42AF0129536 for ; Thu, 4 May 2017 06:03:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.512 X-Spam-Level: X-Spam-Status: No, score=-14.512 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 fHkbs_zo1z5A for ; Thu, 4 May 2017 06:03:08 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A988127B52 for ; Thu, 4 May 2017 06:02:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13646; q=dns/txt; s=iport; t=1493902976; x=1495112576; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=W/KZtlk5Mj0OdIKaPOdbC2Afvpqf0T/MiLimtT0pSHc=; b=SkAKovqtHV9Bv02aVZdvefamiIezEPnoykUaCY+S+SpAI69Gyr2WGQD/ tNM7zx36W+ckKfsaN9ruZUaj9hPq82wuwiHh10uhBicARNNDjQVprKKwK xgabBnQ3wfcsadmz28Wp+yx2v31c1+anMDOfw0DVattsoyiaEiSyDxEy0 w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AeAQAPJgtZ/5RdJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm5nYoEMB415kVWQN4U4gg8hAQqFeAKEST8YAQIBAQEBAQEBayi?= =?us-ascii?q?FFQEBAQEDAQErQQsQAgEIDgMEAQEoBycLFAkIAgQBDQUIigADFQ6ydyuKPQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBARgFhl+BXoMbglSBeUyFLwWJSYZPjU0BkwuCDYF?= =?us-ascii?q?hg1iKKpQ0AR84gQpvFUaGcnaHdIENAQEB?= X-IronPort-AV: E=Sophos;i="5.38,287,1491264000"; d="scan'208,217";a="241178902" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 May 2017 13:02:35 +0000 Received: from XCH-ALN-003.cisco.com (xch-aln-003.cisco.com [173.36.7.13]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id v44D2ZPI019744 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 4 May 2017 13:02:35 GMT Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-ALN-003.cisco.com (173.36.7.13) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 4 May 2017 08:02:35 -0500 Received: from xch-rcd-001.cisco.com ([173.37.102.11]) by XCH-RCD-001.cisco.com ([173.37.102.11]) with mapi id 15.00.1210.000; Thu, 4 May 2017 08:02:34 -0500 From: "Pascal Thubert (pthubert)" To: Charlie Perkins , Ana Minaburo , lp-wan CC: Alexander Pelov Thread-Topic: [lp-wan] Terminology for LPWAN Networks Thread-Index: AQHSxFRetrGDBzuiCkiZnr1DdpREaKHjpkiAgAB9W0A= Date: Thu, 4 May 2017 13:02:28 +0000 Deferred-Delivery: Thu, 4 May 2017 13:01:48 +0000 Message-ID: <63720c5b4ed34971952039304eec1ffa@XCH-RCD-001.cisco.com> References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.55.22.4] Content-Type: multipart/alternative; boundary="_000_63720c5b4ed34971952039304eec1ffaXCHRCD001ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [lp-wan] Terminology for LPWAN Networks X-BeenThere: lp-wan@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Low-Power Wide Area Networking \(LP-WAN\), also known as LPWA or Low-Rate WAN \(LR-WAN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2017 13:03:10 -0000 --_000_63720c5b4ed34971952039304eec1ffaXCHRCD001ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Same as Charlie, I agree but for 'thing'. I klike the idea to change it to = device, which is how it's called in a number of venues I participate(d) to. Take care, Pascal From: Charlie Perkins [mailto:charles.perkins@earthlink.net] Sent: jeudi 4 mai 2017 02:30 To: Ana Minaburo ; lp-wan Cc: Pascal Thubert (pthubert) ; Alexander Pelov Subject: Re: [lp-wan] Terminology for LPWAN Networks Hello Ana, I am O.K. with all of the terms except "thing". It seems to me that partic= ular term is irretrievably ambiguous, and does not offer any helpful intuit= ion about the intended meaning. The result would be that it would be harde= r to write unambiguous specifications, and suddenly other words like "anyth= ing" and "something" would become dangerous. I would be happy with any of = the other terms. I have often used "device" for this meaning. Regards, Charlie P. On 5/3/2017 2:29 PM, Ana Minaburo wrote: Hello, I have started doing a list for the most important terms we use on the SCHC= drafts, first I put all the names we have used to define the same concept,= second I put the name we have defined in the drafts, and last I put one pr= oposition, please feel free to agree or not about this proposed terms. Thanks Ana Used on draft = draft-overview or and draft-SCHC Proposed End-System, device, Thing , Host, node Host or Thing = THING (THG) LPWAN Application Server, Application Server Application Server = Application (APP) Network Gateway Route= r or Network Gateway LPWAN Gateway (LGW) LPWAN C/D (LC) = LC (LPWAN Compressor) SCHC C/D = Compression/Decompression Function (CDF) = CDF C/D Function C/D Action (CDA) _______________________________________________ lp-wan mailing list lp-wan@ietf.org https://www.ietf.org/mailman/listinfo/lp-wan --_000_63720c5b4ed34971952039304eec1ffaXCHRCD001ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Same as Charlie, I agree but for R= 16;thing’. I klike the idea to change it to device, which is how it&#= 8217;s called in a number of venues I participate(d) to.<= /p>

 

Take care,

 

Pascal

 

Fr= om: Charlie Perkins [mailto:charles.perkins@ea= rthlink.net]
Sent: jeudi 4 mai 2017 02:30
To: Ana Minaburo <ana@ackl.io>; lp-wan <lp-wan@ietf.org>=
Cc: Pascal Thubert (pthubert) <pthubert@cisco.com>; Alexander = Pelov <alexander@ackl.io>
Subject: Re: [lp-wan] Terminology for LPWAN Networks

 

Hello Ana,

I am O.K. with all of the terms except &quo= t;thing".  It seems to me that particular term is irretrievably a= mbiguous, and does not offer any helpful intuition about the intended meani= ng.  The result would be that it would be harder to write unambiguous specifications, and suddenly other words like "a= nything" and "something" would become dangerous.  I wou= ld be happy with any of the other terms.  I have often used "devi= ce" for this meaning.

Regards,
Charlie P.

 

On 5/3/2017 2:29 PM, An= a Minaburo wrote:

Hello,

 

I have started doing a = list for the most important terms we use on the SCHC drafts, first I put al= l the names we have used to define the same concept, second I put the name = we have defined in the drafts, and last I put one proposition, please feel free to agree or not about this propose= d terms.

 

Thanks

Ana

 

 

   Used on draft            =          &nbs= p;             =             &nb= sp;             = ;          draft-overview or and draft-SCHC        = ;         Proposed  &nbs= p;            &= nbsp;             =     

 End-System, devic= e, Thing , Host, node               &nbs= p;   Host or Thing   &nb= sp;            =              &n= bsp;                 THING (THG) 

LPWAN Application Serve= r,  Application  Server        Application Se= rver                     =            Appl= ication (APP)

Network Gateway   =                      = ;                     &nb= sp;         Router or Network Gateway     &nb= sp;            LPWAN Gateway  (LGW)  =              

LPWAN C/D (LC)         &nbs= p;            &= nbsp;           &nbs= p;             =             &nb= sp;             = ;       LC (LPWAN Compressor)         &nbs= p;          SCHC C/D=                   &nbs= p;            Compression/Decompression Funct= ion (CDF)          CDF C/D Function          = ;                     = ;     C/D Action (CDA) 

 




_________________________________________=
______
lp-wan mailing list
lp-wan=
@ietf.org
https://www.ietf.org/mailman/listinfo/lp-wan=

 

--_000_63720c5b4ed34971952039304eec1ffaXCHRCD001ciscocom_-- From nobody Thu May 4 07:41:49 2017 Return-Path: X-Original-To: lp-wan@ietfa.amsl.com Delivered-To: lp-wan@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6692612E85E for ; Thu, 4 May 2017 07:41:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.109 X-Spam-Level: X-Spam-Status: No, score=-2.109 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, T_KAM_HTML_FONT_INVALID=0.01] 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 gS6vbEf6fRFb for ; Thu, 4 May 2017 07:41:43 -0700 (PDT) Received: from relay4-d.mail.gandi.net (relay4-d.mail.gandi.net [217.70.183.196]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE977129494 for ; Thu, 4 May 2017 07:41:42 -0700 (PDT) Received: from [IPv6:2001:660:7301:3728:11c6:a6e8:a33e:a0ab] (unknown [IPv6:2001:660:7301:3728:11c6:a6e8:a33e:a0ab]) (Authenticated sender: alex@ackl.io) by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id BD7981720E2; Thu, 4 May 2017 16:41:40 +0200 (CEST) From: Alexander Pelov Message-Id: <5CD953CA-CEBD-4483-9839-3BF26C6C3A02@ackl.io> Content-Type: multipart/alternative; boundary="Apple-Mail=_AAAB52FF-CFC4-4161-BFAD-63C8738EE0B1" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 4 May 2017 16:41:39 +0200 In-Reply-To: <63720c5b4ed34971952039304eec1ffa@XCH-RCD-001.cisco.com> Cc: Charlie Perkins , Ana Minaburo , lp-wan To: "Pascal Thubert (pthubert)" References: <63720c5b4ed34971952039304eec1ffa@XCH-RCD-001.cisco.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [lp-wan] Terminology for LPWAN Networks X-BeenThere: lp-wan@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Low-Power Wide Area Networking \(LP-WAN\), also known as LPWA or Low-Rate WAN \(LR-WAN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2017 14:41:47 -0000 --Apple-Mail=_AAAB52FF-CFC4-4161-BFAD-63C8738EE0B1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 +1.=20 I still find it difficult to use "Thing" on daily basis, and generally = tend to fall back to host, end-device or simply device. So, I=E2=80=99d go with what Charlie and Pascal said. Device is OK for = me. Alex > Le 4 mai 2017 =C3=A0 15:02, Pascal Thubert (pthubert) = a =C3=A9crit : >=20 > Same as Charlie, I agree but for =E2=80=98thing=E2=80=99. I klike the = idea to change it to device, which is how it=E2=80=99s called in a = number of venues I participate(d) to. > =20 > Take care, > =20 > Pascal > =20 > From: Charlie Perkins [mailto:charles.perkins@earthlink.net = ]=20 > Sent: jeudi 4 mai 2017 02:30 > To: Ana Minaburo >; lp-wan = > > Cc: Pascal Thubert (pthubert) >; Alexander Pelov > > Subject: Re: [lp-wan] Terminology for LPWAN Networks > =20 > Hello Ana, >=20 > I am O.K. with all of the terms except "thing". It seems to me that = particular term is irretrievably ambiguous, and does not offer any = helpful intuition about the intended meaning. The result would be that = it would be harder to write unambiguous specifications, and suddenly = other words like "anything" and "something" would become dangerous. I = would be happy with any of the other terms. I have often used "device" = for this meaning. >=20 > Regards, > Charlie P. >=20 > =20 > On 5/3/2017 2:29 PM, Ana Minaburo wrote: > Hello,=20 > =20 > I have started doing a list for the most important terms we use on the = SCHC drafts, first I put all the names we have used to define the same = concept, second I put the name we have defined in the drafts, and last I = put one proposition, please feel free to agree or not about this = proposed terms. > =20 > Thanks > Ana > =20 > =20 > Used on draft = draft-overview or and draft-SCHC = Proposed =20 > End-System, device, Thing , Host, node Host or = Thing THING (THG)=20 > LPWAN Application Server, Application Server Application = Server Application (APP) > Network Gateway = Router or Network Gateway LPWAN Gateway (LGW) = =20 > LPWAN C/D (LC) = LC (LPWAN Compressor) SCHC = C/D Compression/Decompression Function = (CDF) CDF C/D Function C/D = Action (CDA)=20 > =20 >=20 >=20 >=20 > _______________________________________________ > lp-wan mailing list > lp-wan@ietf.org > https://www.ietf.org/mailman/listinfo/lp-wan = > =20 > _______________________________________________ > lp-wan mailing list > lp-wan@ietf.org > https://www.ietf.org/mailman/listinfo/lp-wan = --Apple-Mail=_AAAB52FF-CFC4-4161-BFAD-63C8738EE0B1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
+1. 

I still find it difficult to use = "Thing" on daily basis, and generally tend to fall back to host, = end-device or simply device.

So, I=E2=80=99d go with what Charlie = and Pascal said. Device is OK for me.

Alex



Le = 4 mai 2017 =C3=A0 15:02, Pascal Thubert (pthubert) <pthubert@cisco.com> = a =C3=A9crit :

Same as Charlie, I = agree but for =E2=80=98thing=E2=80=99. I klike the idea to change it to = device, which is how it=E2=80=99s called in a number of venues I = participate(d) to.
 
Take care,
 
Pascal
 
From: Charlie Perkins [mailto:charles.perkins@earthlink.net] 
Sent: jeudi 4 mai 2017 02:30
To: Ana Minaburo <ana@ackl.io>; lp-wan <lp-wan@ietf.org>
Cc: Pascal Thubert (pthubert) = <pthubert@cisco.com>; = Alexander Pelov <alexander@ackl.io>
Subject: Re: [lp-wan] Terminology = for LPWAN Networks
 
Hello Ana,

I am = O.K. with all of the terms except "thing".  It seems to me that = particular term is irretrievably ambiguous, and does not offer any = helpful intuition about the intended meaning.  The result would be = that it would be harder to write unambiguous specifications, and = suddenly other words like "anything" and "something" would become = dangerous.  I would be happy with any of the other terms.  I = have often used "device" for this meaning.

Regards,
Charlie P.

 
On 5/3/2017 2:29 PM, Ana Minaburo = wrote:
Hello, 
 
I have started doing a list for = the most important terms we use on the SCHC drafts, first I put all the = names we have used to define the same concept, second I put the name we = have defined in the drafts, and last I put one proposition, please feel = free to agree or not about this proposed terms.
 
Thanks
Ana
 
 
   Used on draft     =                        =             &n= bsp;           =                   =   draft-overview or and draft-SCHC        &= nbsp;       =  Proposed        &= nbsp;           &nb= sp;         =     
 End-System, = device, Thing , Host, node             =       Host or Thing        &= nbsp;           &nb= sp;     =                   =    THING (THG) 
LPWAN = Application Server,  Application  Server       =  Application Server             =                   =  Application = (APP)
Network Gateway =                     =                     =               Router or Network = Gateway                  LPWAN Gateway  (LGW) =     =            
LPWAN C/D (LC)     =             &n= bsp;           &nbs= p;           =             &n= bsp;           =                 LC = (LPWAN Compressor)               =      SCHC = C/D   =                     =          Compression/Decompression Function = (CDF)          CDF C/D Function        &= nbsp;         =                 =   C/D = Action (CDA) 
 



_______________________________________________
lp-wan mailing =
list
lp-wan@ietf.org
https://www.ietf.org/mailman/listinfo/lp-wan
 
_______________________________________________
lp-wan mailing list
lp-wan@ietf.org
https://www.ietf.org/mailman/listinfo/lp-wan

= --Apple-Mail=_AAAB52FF-CFC4-4161-BFAD-63C8738EE0B1-- From nobody Thu May 4 07:55:34 2017 Return-Path: X-Original-To: lp-wan@ietfa.amsl.com Delivered-To: lp-wan@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6B53126B71 for ; Thu, 4 May 2017 07:55:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.589 X-Spam-Level: X-Spam-Status: No, score=-2.589 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mail-udp-cl.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 iekIuPkzrIMh for ; Thu, 4 May 2017 07:55:29 -0700 (PDT) Received: from mail-yw0-x229.google.com (mail-yw0-x229.google.com [IPv6:2607:f8b0:4002:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B591812EA93 for ; Thu, 4 May 2017 07:55:13 -0700 (PDT) Received: by mail-yw0-x229.google.com with SMTP id l18so7756991ywh.3 for ; Thu, 04 May 2017 07:55:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mail-udp-cl.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=GCq9e8DXjbIdzvnQCGXF6YPK1tWL3ZUfbVXPw0aYLY0=; b=oCtaq1K8skj7TCrcmbwfPDjdaQO6tgKevS8Dvo8C2BA+oMv19V0TZ42yJGY8Yo7o9c 55dL3YjjIBOTosmsfzn8fDu5NXHoGZdvgkIEITlxDgW0kiKn3SIpNzRd3bS+hXIFgqe/ Pe6wZ1hPqh/tfTc/9VbayqGtlPIHL+RluY7kr4EtdlwxmDboBX/vrOOxNWhkaZXNDY6H gky9WWt1bl0GQnaSB3wPeehpciD4BFXMDaacC3JpPBNPymaoTiQEDlQ3Re6JLeKxcWvQ zEDecR0D8JzosBv9CivQctaadjHoNis9EE1rak7wUdQ3yPSAeapFBrvyCUnv1FCtJPX2 Xjeg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=GCq9e8DXjbIdzvnQCGXF6YPK1tWL3ZUfbVXPw0aYLY0=; b=uCrm1pw7qLWbrJVJpy0D82IUx4mIAFHtywLxiyV2VDa5I58cBLxJuW0r2zxKs/NWXR 62scywec62G8B+4frwgKnbWCo8cRZQEIXUl3UOujzgOt2ucKF11knCKiC11CkiZnwfxh Omn9+D3a7KehJVX905Wjv8jUlj63sMeYOY5NTVB+o+j+WW27UB2WfD+dSqrDm+2OyaMv Z/32JQuh0aNJplZOW0+pdFOkBQKNAU1+T6RCQpwk+lhyHe1LWKAxikfxnj9LBEnoZwzC IWkpL9nafRVYJ2vKcCVWT/DgVc/axayd1IdlCDzHKUVX4bLyC1Z/mG2LE//4Ouuzpfj+ F2GQ== X-Gm-Message-State: AN3rC/7K8fUz/IjG89v69+xMisaU7afk2XEcJtbQKxynaYg6ye9LXXzZ Q8d6xBGYi2YpTLqDJKqkEJYR1Fl87A== X-Received: by 10.129.107.138 with SMTP id g132mr10446103ywc.117.1493909712809; Thu, 04 May 2017 07:55:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.136.134 with HTTP; Thu, 4 May 2017 07:54:51 -0700 (PDT) In-Reply-To: <5CD953CA-CEBD-4483-9839-3BF26C6C3A02@ackl.io> References: <63720c5b4ed34971952039304eec1ffa@XCH-RCD-001.cisco.com> <5CD953CA-CEBD-4483-9839-3BF26C6C3A02@ackl.io> From: "Prof. Diego Dujovne" Date: Thu, 4 May 2017 11:54:51 -0300 Message-ID: To: Alexander Pelov Cc: "Pascal Thubert (pthubert)" , Charlie Perkins , lp-wan , Ana Minaburo Content-Type: multipart/alternative; boundary=001a114739a4c29341054eb3f5f7 Archived-At: Subject: Re: [lp-wan] Terminology for LPWAN Networks X-BeenThere: lp-wan@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Low-Power Wide Area Networking \(LP-WAN\), also known as LPWA or Low-Rate WAN \(LR-WAN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2017 14:55:32 -0000 --001a114739a4c29341054eb3f5f7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable +1 on Device. Regards, Diego 2017-05-04 11:41 GMT-03:00 Alexander Pelov : > +1. > > I still find it difficult to use "Thing" on daily basis, and generally > tend to fall back to host, end-device or simply device. > > So, I=E2=80=99d go with what Charlie and Pascal said. Device is OK for me= . > > Alex > > > > Le 4 mai 2017 =C3=A0 15:02, Pascal Thubert (pthubert) a > =C3=A9crit : > > Same as Charlie, I agree but for =E2=80=98thing=E2=80=99. I klike the ide= a to change it to > device, which is how it=E2=80=99s called in a number of venues I particip= ate(d) to. > > Take care, > > Pascal > > *From:* Charlie Perkins [mailto:charles.perkins@earthlink.net > ] > *Sent:* jeudi 4 mai 2017 02:30 > *To:* Ana Minaburo ; lp-wan > *Cc:* Pascal Thubert (pthubert) ; Alexander Pelov < > alexander@ackl.io> > *Subject:* Re: [lp-wan] Terminology for LPWAN Networks > > > Hello Ana, > > I am O.K. with all of the terms except "thing". It seems to me that > particular term is irretrievably ambiguous, and does not offer any helpfu= l > intuition about the intended meaning. The result would be that it would = be > harder to write unambiguous specifications, and suddenly other words like > "anything" and "something" would become dangerous. I would be happy with > any of the other terms. I have often used "device" for this meaning. > > Regards, > Charlie P. > > On 5/3/2017 2:29 PM, Ana Minaburo wrote: > > Hello, > > I have started doing a list for the most important terms we use on the > SCHC drafts, first I put all the names we have used to define the same > concept, second I put the name we have defined in the drafts, and last I > put one proposition, please feel free to agree or not about this proposed > terms. > > Thanks > Ana > > > Used on draft > draft-overview or and draft-SCHC > Proposed > End-System, device, Thing , Host, node Host or Thing > THING (THG) > LPWAN Application Server, Application Server Application Server > Application (APP) > Network Gateway > Router or Network Gateway LPWAN Gateway (LGW) > > LPWAN C/D (LC) > LC (LPWAN Compressor) > SCHC C/D Compression/Decompression > Function (CDF) CDF C/D Function > C/D Action (CDA) > > > > > _______________________________________________ > > lp-wan mailing list > > lp-wan@ietf.org > > https://www.ietf.org/mailman/listinfo/lp-wan > > > _______________________________________________ > lp-wan mailing list > lp-wan@ietf.org > https://www.ietf.org/mailman/listinfo/lp-wan > > > > _______________________________________________ > lp-wan mailing list > lp-wan@ietf.org > https://www.ietf.org/mailman/listinfo/lp-wan > > --=20 DIEGO DUJOVNE Profesor Asociado Escuela de Inform=C3=A1tica y Telecomunicaciones Facultad de Ingenier=C3=ADa - Universidad Diego Portales - Chile www.ingenieria.udp.cl (56 2) 676 8125 --001a114739a4c29341054eb3f5f7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
+1 on Device.
Regards,

=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Diego=

2017-= 05-04 11:41 GMT-03:00 Alexander Pelov <a@ackl.io>:
+1.=C2=A0

I still find it difficult to use "Thing" on dai= ly basis, and generally tend to fall back to host, end-device or simply dev= ice.

So, I=E2=80=99d go with what Charlie and Pasc= al said. Device is OK for me.

Alex



Le 4 mai 2017 =C3=A0 15:02, Pascal Thubert (pthubert) <pthubert@cisco.com>= a =C3=A9crit :

Same as Charlie, I agree bu= t for =E2=80=98thing=E2=80=99. I klike the idea to change it to device, whi= ch is how it=E2=80=99s called in a number of venues I participate(d) to.=
=C2=A0=
Take care,=
=C2=A0
Pascal
=C2=A0
From:=C2=A0= Charlie Perkins [mailto:charles.pe= rkins@earthlink.net]=C2=A0
Sent:=C2=A0jeudi 4 mai 2017 02:30
To:=C2=A0= Ana Minaburo <ana@ackl.io>; lp-wan <lp-wan@ietf.org>
Cc:=C2=A0Pascal Thubert (= pthubert) <pthubert@cisco.com>; Ale= xander Pelov <alexander@ackl.io>
= Subject:= =C2=A0Re: [lp-wan] Terminology for LPWAN Networks
=C2=A0
<= p style=3D"margin-right:0cm;margin-left:36pt;font-size:12pt;font-family:= 9;Times New Roman',serif">Hello Ana,

I am O.K. with all of the terms except "thing".=C2= =A0 It seems to me that particular term is irretrievably ambiguous, and doe= s not offer any helpful intuition about the intended meaning.=C2=A0 The res= ult would be that it would be harder to write unambiguous specifications, a= nd suddenly other words like "anything" and "something"= would become dangerous.=C2=A0 I would be happy with any of the other terms= .=C2=A0 I have often used "device" for this meaning.

Regards,
Charlie P.

=C2=A0
On 5/3/2017 2:29 PM, Ana Minaburo wrote:
Hello,=C2=A0
=C2=A0
I have started d= oing a list for the most important terms we use on the SCHC drafts, first I= put all the names we have used to define the same concept, second I put th= e name we have defined in the drafts, and last I put one proposition, pleas= e feel free to agree or not about this proposed terms.
<= /div>
=C2=A0
=
Thanks
Ana
=C2=A0
=C2=A0
=C2=A0 =C2=A0Used on draft =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2= =A0=C2=A0draft-overview or and draft-SCHC=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0Proposed=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=
=C2=A0End-System= , device, Thing , Host, node =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Host or Thing=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0THING (THG)=C2=A0
LPWAN Application Server, =C2=A0Application =C2=A0Se= rver =C2=A0 =C2=A0 =C2=A0 =C2=A0Application Server =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0Application (APP)=
Netwo= rk Gateway =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Router or Network Gate= way =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0LPWAN Gateway =C2=A0(LGW) =C2=A0=C2=A0=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
=
LPWAN C/D (LC)=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 LC (LPWAN Compressor) =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0SCHC C/D=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Compre= ssion/Decompression Function (CDF) =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0CDF C/= D Function=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0= C/D Action (CDA)=C2=A0<= u>
= =C2=A0


______________________________=
_________________
lp-wan mailing list<=
u>
lp-wan@ietf=
.org
https://www.ietf.org/mailman/listinfo/lp-wan
=C2=A0=
_______________________________________________
lp-wan mailing list
lp-wan@ietf.org<= br style=3D"font-family:Helvetica;font-size:12px;font-style:normal;font-var= iant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;= text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;bac= kground-color:rgb(255,255,255)">https://www.ietf.org/mailman/listinfo/lp-wan<= /a>


_______________________________________________
lp-wan mailing list
lp-wan@ietf.org
https://www.ietf.org/mailman/listinfo/lp-wan



--
=
DIEGO DUJOVNE
Profesor Asociado
Escuela de= Inform=C3=A1tica y Telecomunicaciones
Facultad de Ingenier=C3=ADa - Uni= versidad Diego Portales - Chile
www.ingenieria.udp.cl
(56 2) 676 8125
--001a114739a4c29341054eb3f5f7-- From nobody Fri May 5 03:12:25 2017 Return-Path: X-Original-To: lp-wan@ietfa.amsl.com Delivered-To: lp-wan@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B04FF1294C9 for ; Fri, 5 May 2017 03:12:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.81 X-Spam-Level: X-Spam-Status: No, score=-1.81 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_NEUTRAL=0.779, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=digiusto-com.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 RWHbItg5HIax for ; Fri, 5 May 2017 03:12:22 -0700 (PDT) Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001:c06::22a]) (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 A8BBD129418 for ; Fri, 5 May 2017 03:12:20 -0700 (PDT) Received: by mail-io0-x22a.google.com with SMTP id k91so2131590ioi.1 for ; Fri, 05 May 2017 03:12:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=digiusto-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=+m7vPxyMdp520egGneQt5hCxlgZtxsqwxowlyOuqNNY=; b=kcwf303gN+3zYpsKjfSR7mtaRdzCZk9HNS8YNhwwPnvXoEaVoHhbgav/pq7M+OqECB lfoT3J0rtoXGuEUTqwcGQC4YmCEqeLlC6LZLaVj5gfRFfA3mjq6saqOprJIyGPuCJg/J 92UyoV4Q/s5jmzSIxmufPYfdkP8Ri/vzyW4meBt7JQkEO4Z2ntZZn3ueTqUuHIRqmLuP mHX8vMY8XkG7oGbkVte59DWP3tPJ3rn0sD5Fu7+1Z6egBvFsfG3s6mYq3GxiirQmFnU5 rXPKrpVTE9EagRkSUA/woj3juBk2Y6kkJRKxwyIdaYcgCyirFjRnq0FTxdNSEv06+jMT zGOA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=+m7vPxyMdp520egGneQt5hCxlgZtxsqwxowlyOuqNNY=; b=UD9TSYdpVPV132DOjAX3lsBNcMNgxCKqjOgT2+9isEBWzn5RDpE7PZvFXjFU8wyxZG 87K/ji92mHuaNcskwVf6fEYJ5aBNS1V2JlkIrmWqMsDUGNPDXr5OwShGLdlVD48fPfyA UspvdLmJrrJ3PGFAgKRU22Bu/VmkD6emGP2o5CSV4VH8qi9Spa1IKe8HkA5RLca1IXnG ZpvPgumNI9G2pEOFymIpsygnHxrYSDg2PSULUa1sI7vTxuz3fbL0UavdLuJIXPaPMTlc 19+uctqovvPjsX9A1WURmevA+6TYyGsKZrxR2oZ2PrMw285z/lBZYJdWj7yXjuzFV5h4 aWIw== X-Gm-Message-State: AN3rC/6Xt6SB1+fxgj92qZ0waxpicj3FjcaxTYVTkr4lVfu75u+2FN6l j0MvFkODs+aiYRTE X-Received: by 10.107.18.203 with SMTP id 72mr13405995ios.149.1493979139678; Fri, 05 May 2017 03:12:19 -0700 (PDT) Received: from mail-io0-f171.google.com (mail-io0-f171.google.com. [209.85.223.171]) by smtp.gmail.com with ESMTPSA id w191sm878012iof.11.2017.05.05.03.12.17 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 05 May 2017 03:12:18 -0700 (PDT) Received: by mail-io0-f171.google.com with SMTP id k91so2130428ioi.1 for ; Fri, 05 May 2017 03:12:17 -0700 (PDT) X-Received: by 10.107.141.2 with SMTP id p2mr43388118iod.161.1493979137537; Fri, 05 May 2017 03:12:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.3.74 with HTTP; Fri, 5 May 2017 03:11:57 -0700 (PDT) In-Reply-To: References: <63720c5b4ed34971952039304eec1ffa@XCH-RCD-001.cisco.com> <5CD953CA-CEBD-4483-9839-3BF26C6C3A02@ackl.io> From: Ivan Di Giusto Date: Fri, 5 May 2017 20:11:57 +1000 X-Gmail-Original-Message-ID: Message-ID: To: "Prof. Diego Dujovne" Cc: Alexander Pelov , Charlie Perkins , lp-wan , "Pascal Thubert (pthubert)" , Ana Minaburo Content-Type: multipart/alternative; boundary=94eb2c05ab72cb824e054ec41f2a Archived-At: Subject: Re: [lp-wan] Terminology for LPWAN Networks X-BeenThere: lp-wan@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Low-Power Wide Area Networking \(LP-WAN\), also known as LPWA or Low-Rate WAN \(LR-WAN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 May 2017 10:12:25 -0000 --94eb2c05ab72cb824e054ec41f2a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi All, Couple of comments: - I support the choice of DEVICE - I would recommend using APPLICATION SERVER instead of APPLICATION. APPLICATION is what runs on the DEVICE, while APPLICATION SERVER is what receives data from the DEVICE through the network. - I see discussion of the LPWAN Gateway when talking about the network. In most LPWAN implementations, Gateway is a dumb radio and the smarts ar= e in the Network Server. It is really the Network Server that is the network. I am not sure if it helps or hinders to introduce the concept = of the Network Server in this document. Regards, Ivan On 5 May 2017 at 00:54, Prof. Diego Dujovne wrote: > +1 on Device. > Regards, > > Diego > > 2017-05-04 11:41 GMT-03:00 Alexander Pelov : > >> +1. >> >> I still find it difficult to use "Thing" on daily basis, and generally >> tend to fall back to host, end-device or simply device. >> >> So, I=E2=80=99d go with what Charlie and Pascal said. Device is OK for m= e. >> >> Alex >> >> >> >> Le 4 mai 2017 =C3=A0 15:02, Pascal Thubert (pthubert) a >> =C3=A9crit : >> >> Same as Charlie, I agree but for =E2=80=98thing=E2=80=99. I klike the id= ea to change it >> to device, which is how it=E2=80=99s called in a number of venues I part= icipate(d) >> to. >> >> Take care, >> >> Pascal >> >> *From:* Charlie Perkins [mailto:charles.perkins@earthlink.net >> ] >> *Sent:* jeudi 4 mai 2017 02:30 >> *To:* Ana Minaburo ; lp-wan >> *Cc:* Pascal Thubert (pthubert) ; Alexander Pelov < >> alexander@ackl.io> >> *Subject:* Re: [lp-wan] Terminology for LPWAN Networks >> >> >> Hello Ana, >> >> I am O.K. with all of the terms except "thing". It seems to me that >> particular term is irretrievably ambiguous, and does not offer any helpf= ul >> intuition about the intended meaning. The result would be that it would= be >> harder to write unambiguous specifications, and suddenly other words lik= e >> "anything" and "something" would become dangerous. I would be happy wit= h >> any of the other terms. I have often used "device" for this meaning. >> >> Regards, >> Charlie P. >> >> On 5/3/2017 2:29 PM, Ana Minaburo wrote: >> >> Hello, >> >> I have started doing a list for the most important terms we use on the >> SCHC drafts, first I put all the names we have used to define the same >> concept, second I put the name we have defined in the drafts, and last I >> put one proposition, please feel free to agree or not about this propose= d >> terms. >> >> Thanks >> Ana >> >> >> Used on draft >> draft-overview or and draft-SCHC >> Proposed >> End-System, device, Thing , Host, node Host or Thing >> THING (THG) >> LPWAN Application Server, Application Server Application Server >> Application (APP) >> Network Gateway >> Router or Network Gateway LPWAN Gateway (LGW) >> >> LPWAN C/D (LC) >> LC (LPWAN Compressor) >> SCHC C/D >> Compression/Decompression Function (CDF) CDF C/D Function >> C/D Action (CDA) >> >> >> >> >> _______________________________________________ >> >> lp-wan mailing list >> >> lp-wan@ietf.org >> >> https://www.ietf.org/mailman/listinfo/lp-wan >> >> >> _______________________________________________ >> lp-wan mailing list >> lp-wan@ietf.org >> https://www.ietf.org/mailman/listinfo/lp-wan >> >> >> >> _______________________________________________ >> lp-wan mailing list >> lp-wan@ietf.org >> https://www.ietf.org/mailman/listinfo/lp-wan >> >> > > > -- > DIEGO DUJOVNE > Profesor Asociado > Escuela de Inform=C3=A1tica y Telecomunicaciones > Facultad de Ingenier=C3=ADa - Universidad Diego Portales - Chile > www.ingenieria.udp.cl > (56 2) 676 8125 > > _______________________________________________ > lp-wan mailing list > lp-wan@ietf.org > https://www.ietf.org/mailman/listinfo/lp-wan > > --94eb2c05ab72cb824e054ec41f2a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi All,=C2=A0

Couple of comments:
  • I support the choice of DEVICE
  • I would recommend u= sing APPLICATION SERVER instead of APPLICATION.=C2=A0 APPLICATION is what r= uns on the DEVICE, while APPLICATION SERVER is what receives data from the = DEVICE through the network.
  • I see discussion of the LPWAN Gateway w= hen talking about the network.=C2=A0 In most LPWAN implementations, Gateway= is a dumb radio and the smarts are in the Network Server.=C2=A0 It is real= ly the Network Server that is the network.=C2=A0 I am not sure if it helps = or hinders to introduce the concept of the Network Server in this document.=
Regards,
Ivan

On 5 May 2017 at 00:54, Prof. Diego = Dujovne <diego.dujovne@mail.udp.cl> wrote:
+1 on Device.
Regards,
<= div>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0Diego

2017-05-04 11:41 GMT-03:00 Alexa= nder Pelov <a@ackl.io>:
+1.=C2=A0

I still= find it difficult to use "Thing" on daily basis, and generally t= end to fall back to host, end-device or simply device.

=
So, I=E2=80=99d go with what Charlie and Pascal said. Device is OK for= me.

Alex



<= div>Le 4 mai 2017 =C3=A0 15:02, Pascal Thubert (pthubert) <pthubert@cisco.com> a =C3= =A9crit :

Same as Charlie, I agree but for =E2=80=98thing=E2=80=99. I klike = the idea to change it to device, which is how it=E2=80=99s called in a numb= er of venues I participate(d) to.
=C2=A0
Take care,
=C2=A0
Pascal=
=C2=A0
From:=C2=A0Charlie Perkins [<= a href=3D"mailto:charles.perkins@earthlink.net" style=3D"color:purple;text-= decoration:underline" target=3D"_blank">mailto:charles.perkins@earthli= nk.net]=C2=A0
Sent:=C2=A0jeudi 4 ma= i 2017 02:30
To:=C2=A0Ana Minaburo <ana@ackl.io>; lp-wan <lp-w= an@ietf.org>
Cc:=C2=A0Pascal Thubert (pthuber= t) <pthubert@cisco.com>; Alexander = Pelov <alexander@ackl.io>
Subj= ect:=C2=A0Re: [lp-wan] Terminology for LPWAN Networks
=C2=A0=

Hello Ana,

I am O.K. with all of the terms except "th= ing".=C2=A0 It seems to me that particular term is irretrievably ambig= uous, and does not offer any helpful intuition about the intended meaning.= =C2=A0 The result would be that it would be harder to write unambiguous spe= cifications, and suddenly other words like "anything" and "s= omething" would become dangerous.=C2=A0 I would be happy with any of t= he other terms.=C2=A0 I have often used "device" for this meaning= .

Regards,
Charlie P.=

=C2=A0
<= div style=3D"margin:0cm 0cm 0.0001pt 36pt;font-size:12pt;font-family:'T= imes New Roman',serif">On 5/3/2017 2:29 PM, Ana Minaburo wrote:<= u>
Hello,=C2=A0
=C2=A0
I have started doing a list for the most important terms= we use on the SCHC drafts, first I put all the names we have used to defin= e the same concept, second I put the name we have defined in the drafts, an= d last I put one proposition, please feel free to agree or not about this p= roposed terms.
=C2=A0
Thanks
Ana
=C2=A0
=C2=A0
=C2=A0 =C2=A0Used o= n draft =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2= =A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 =C2= =A0 =C2=A0=C2=A0draft-overview or and draft-SCHC=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0Proposed=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0=C2=A0
= =C2=A0End-System, device, Thing , Host, node =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Host or Thing=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0THING= (THG)=C2=A0
LPWAN Application Server, =C2=A0Application =C2=A0Server =C2=A0 =C2= =A0 =C2=A0 =C2=A0Application Server =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Application (APP)<= /div>
Network Gateway =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Router or Network Gateway =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0LPWAN Gateway =C2=A0(LGW) =C2=A0=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<= /u>
LPWAN C/D (LC)=C2= =A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 LC (LPWAN Compressor) =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0SCHC C/D=C2=A0=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Compression/Decompression Function (CDF) = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0CDF C/D Function=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0=C2=A0C/D Action (CDA)=C2=A0
=C2=A0


___________________________=
____________________
lp-wan maili=
ng list
lp-=
wan@ietf.org
https://www.ietf.org/mailman/listinfo/lp-w=
an
= =C2=A0
_______________________________________________
lp-wan mailing list
lp-wan@ietf= .org
https://www.ietf.org/mailman/listinf= o/lp-wan

<= /div>

_______________________________________________ lp-wan mailing list
lp-wan@ietf.org https://www.ietf.org/mailman/listinfo/lp-wan



--
DIEGO DUJOVNE
Profesor Asociado
Escue= la de Inform=C3=A1tica y Telecomunicaciones
Facultad de Ingenier=C3=ADa = - Universidad Diego Portales - Chile
www.ingenieria.udp.cl
(56 2) 676 8125

_______________________________________________
lp-wan mailing list
lp-wan@ietf.org
https://www.ietf.org/mailman/listinfo/lp-wan

--94eb2c05ab72cb824e054ec41f2a-- From nobody Fri May 5 09:13:48 2017 Return-Path: X-Original-To: lp-wan@ietfa.amsl.com Delivered-To: lp-wan@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 753361296C6 for ; Fri, 5 May 2017 09:13:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iK3XqbO6BCul for ; Fri, 5 May 2017 09:13:42 -0700 (PDT) Received: from ot-mail-smtp-2.pulsation.fr (ot-mail-smtp-4.pulsation.fr [80.74.64.133]) (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 351BC129AB3 for ; Fri, 5 May 2017 09:13:41 -0700 (PDT) Received: from [192.168.5.247] (unknown [37.157.230.10]) (Authenticated sender: j.catalano@kerlink.fr) by smtp.oceamail.net (Postfix) with ESMTPA id 3B9F31006D65; Fri, 5 May 2017 18:13:39 +0200 (CEST) To: Alexander Pelov , "Pascal Thubert (pthubert)" References: <63720c5b4ed34971952039304eec1ffa@XCH-RCD-001.cisco.com> <5CD953CA-CEBD-4483-9839-3BF26C6C3A02@ackl.io> Cc: Charlie Perkins , lp-wan , Ana Minaburo From: Julien Catalano Message-ID: <0d2efe85-16f9-904c-aafd-f32ac1ce43ea@kerlink.fr> Date: Fri, 5 May 2017 18:13:38 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <5CD953CA-CEBD-4483-9839-3BF26C6C3A02@ackl.io> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Vvdr0x8N74TM4wOJpljcfcWSJQII0qJRb" Archived-At: Subject: Re: [lp-wan] Terminology for LPWAN Networks X-BeenThere: lp-wan@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Low-Power Wide Area Networking \(LP-WAN\), also known as LPWA or Low-Rate WAN \(LR-WAN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 May 2017 16:13:46 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Vvdr0x8N74TM4wOJpljcfcWSJQII0qJRb Content-Type: multipart/mixed; boundary="cI5vixJAJrTGpErUjwNRtx3ek8hheUujb"; protected-headers="v1" From: Julien Catalano To: Alexander Pelov , "Pascal Thubert (pthubert)" Cc: Charlie Perkins , lp-wan , Ana Minaburo Message-ID: <0d2efe85-16f9-904c-aafd-f32ac1ce43ea@kerlink.fr> Subject: Re: [lp-wan] Terminology for LPWAN Networks References: <63720c5b4ed34971952039304eec1ffa@XCH-RCD-001.cisco.com> <5CD953CA-CEBD-4483-9839-3BF26C6C3A02@ackl.io> In-Reply-To: <5CD953CA-CEBD-4483-9839-3BF26C6C3A02@ackl.io> --cI5vixJAJrTGpErUjwNRtx3ek8hheUujb Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hello all, I tend to prefer using "END-DEVICE" or "ENDPOINT" instead of DEVICE, which looks too generic and ambiguous to me. A gateway or a router can also be called "devices" (as in "electronic devices" or "network devices"). My (first!) 2 cents. Julien On 04/05/2017 16:41, Alexander Pelov wrote: > +1.=20 > > I still find it difficult to use "Thing" on daily basis, and generally > tend to fall back to host, end-device or simply device. > > So, I=92d go with what Charlie and Pascal said. Device is OK for me. > > Alex > > > >> Le 4 mai 2017 =E0 15:02, Pascal Thubert (pthubert) > > a =E9crit : >> >> Same as Charlie, I agree but for =91thing=92. I klike the idea to chan= ge >> it to device, which is how it=92s called in a number of venues I >> participate(d) to. >> =20 >> Take care, >> =20 >> Pascal >> =20 >> *From:* Charlie Perkins [mailto:charles.perkins@earthlink.net]=20 >> *Sent:* jeudi 4 mai 2017 02:30 >> *To:* Ana Minaburo >; lp-wan >> > >> *Cc:* Pascal Thubert (pthubert) > >; Alexander Pelov > > >> *Subject:* Re: [lp-wan] Terminology for LPWAN Networks >> =20 >> >> Hello Ana, >> >> I am O.K. with all of the terms except "thing". It seems to me that >> particular term is irretrievably ambiguous, and does not offer any >> helpful intuition about the intended meaning. The result would be >> that it would be harder to write unambiguous specifications, and >> suddenly other words like "anything" and "something" would become >> dangerous. I would be happy with any of the other terms. I have >> often used "device" for this meaning. >> >> Regards, >> Charlie P. >> >> =20 >> On 5/3/2017 2:29 PM, Ana Minaburo wrote: >> >> Hello,=20 >> =20 >> I have started doing a list for the most important terms we use >> on the SCHC drafts, first I put all the names we have used to >> define the same concept, second I put the name we have defined in >> the drafts, and last I put one proposition, please feel free to >> agree or not about this proposed terms. >> =20 >> Thanks >> Ana >> =20 >> =20 >> Used on draft =20 >> draft-overview or and >> draft-SCHC Proposed = =20 >> End-System, device, Thing , Host, node Host or >> Thing THING (THG)=20 >> LPWAN Application Server, Application Server Application >> Server Application (APP) >> Network Gateway =20 >> Router or Network Gateway LPWAN Gateway >> (LGW) =20 >> LPWAN C/D (LC) =20 >> LC (LPWAN Compressor) =20 >> SCHC C/D =20 >> Compression/Decompression Function (CDF) CDF C/D >> Function C/D Action (CDA)=20 >> =20 >> >> >> >> _______________________________________________ >> >> lp-wan mailing list >> >> lp-wan@ietf.org >> >> https://www.ietf.org/mailman/listinfo/lp-wan >> >> =20 >> _______________________________________________ >> lp-wan mailing list >> lp-wan@ietf.org >> https://www.ietf.org/mailman/listinfo/lp-wan > > > > _______________________________________________ > lp-wan mailing list > lp-wan@ietf.org > https://www.ietf.org/mailman/listinfo/lp-wan --cI5vixJAJrTGpErUjwNRtx3ek8hheUujb-- --Vvdr0x8N74TM4wOJpljcfcWSJQII0qJRb Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJZDKSzAAoJEMBXUxqHqWRCXG0QAL39KSEv+WeXq19zruNQJaLz m9oM8Q8F1xcfDIJWszT+pLuN+KVA73ioLPzlmsTuF6ZWjSIn5XlOnnvd5AjLURLT mPpvmAxqd1oNURs2kIObTYJ2HT3zhJq0ao/SnbyjUGOmDaOqElTX2KNHrR0RuMQZ oqO38f3qRCLw4MluE5Otz88aWlR4c5O1iEFeWlT2umSQdPvuvy6gMaUIcVNlAbVj I8YoT33RDM6CDjchvs0+TUvv9Ku9lQTuq9e5D5u8vNAdr7w4EgspxNMqv8T/Gl+v T5d60uLJ0z6Ut4iRKrT5Kf7CzUa4QHVxhwNjsltp2BmiIAiJGoStTUVXFllmvgDs XHWjH+VNRwtYKlRE2Rm5AI0pF5MAM1Q/dGYRnFmltEWi7lXZ26xwH9sk/gSqIAAZ b66Z834tYyphKrpiHDMufWenPA/Kw/KJDQNPHaGiCPQBghsdm/fGpaVZK25vYbaZ tv3mFKVRLS7s23aBL1vfoyGMgenHCD4Qm2UOb9UKVYgrNbqWfz/FZ9Q1a2tQ0iby jbJXSzW9Ow2KIeNyuj0Lw5UVaPi22/N5Mnhwi+Qxk/ZLHqj0zK0/RmZy99IEDsMA AF1Z+5Fq0NZ/amPW4Ey1fVwmFt1dJ5HXzGkXvBbNoy08J+ZHk9wRZK1LF1G6sA4Z XORW755VAICYl3zq09Ls =x+// -----END PGP SIGNATURE----- --Vvdr0x8N74TM4wOJpljcfcWSJQII0qJRb-- From nobody Fri May 5 11:01:07 2017 Return-Path: X-Original-To: lp-wan@ietf.org Delivered-To: lp-wan@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DA6A11286CA; Fri, 5 May 2017 11:01:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: lp-wan@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149400726585.8434.8654374640287295976@ietfa.amsl.com> Date: Fri, 05 May 2017 11:01:05 -0700 Archived-At: Subject: [lp-wan] I-D Action: draft-ietf-lpwan-ipv6-static-context-hc-03.txt X-BeenThere: lp-wan@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Low-Power Wide Area Networking \(LP-WAN\), also known as LPWA or Low-Rate WAN \(LR-WAN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 May 2017 18:01:06 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 over Low Power Wide-Area Networks of the IETF. Title : LPWAN Static Context Header Compression (SCHC) and fragmentation for IPv6 and UDP Authors : Ana Minaburo Laurent Toutain Carles Gomez Filename : draft-ietf-lpwan-ipv6-static-context-hc-03.txt Pages : 36 Date : 2017-05-05 Abstract: This document describes a header compression scheme and fragmentation functionality for IPv6/UDP protocols. These techniques are especially tailored for LPWAN (Low Power Wide Area Network) networks and could be extended to other protocol stacks. The Static Context Header Compression (SCHC) offers a great level of flexibility when processing the header fields. Static context means that information stored in the context which, describes field values, does not change during the packet transmission, avoiding complex resynchronization mechanisms, incompatible with LPWAN characteristics. In most of the cases, IPv6/UDP headers are reduced to a small identifier. This document describes the generic compression/decompression process and applies it to IPv6/UDP headers. Similar mechanisms for other protocols such as CoAP will be described in a separate document. Moreover, this document specifies fragmentation and reassembly mechanims for SCHC compressed packets exceeding the L2 pdu size and for the case where the SCHC compression is not possible then the IPv6/UDP packet is sent. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lpwan-ipv6-static-context-hc/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-lpwan-ipv6-static-context-hc-03 https://datatracker.ietf.org/doc/html/draft-ietf-lpwan-ipv6-static-context-hc-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lpwan-ipv6-static-context-hc-03 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 Sat May 6 01:42:10 2017 Return-Path: X-Original-To: lp-wan@ietfa.amsl.com Delivered-To: lp-wan@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3578129445 for ; Sat, 6 May 2017 01:42:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.4 X-Spam-Level: X-Spam-Status: No, score=-5.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 L65rLc8U3p0k for ; Sat, 6 May 2017 01:42:06 -0700 (PDT) Received: from relais-inet.orange.com (mta241.mail.business.static.orange.com [80.12.66.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33057129441 for ; Sat, 6 May 2017 01:42:06 -0700 (PDT) Received: from opfedar03.francetelecom.fr (unknown [xx.xx.xx.5]) by opfedar26.francetelecom.fr (ESMTP service) with ESMTP id A6AA71C02B4; Sat, 6 May 2017 10:42:04 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.24]) by opfedar03.francetelecom.fr (ESMTP service) with ESMTP id 7F82E180071; Sat, 6 May 2017 10:42:04 +0200 (CEST) Received: from OPEXCLILM22.corporate.adroot.infra.ftgroup ([fe80::8c90:f4e9:be28:2a1]) by OPEXCLILM7D.corporate.adroot.infra.ftgroup ([fe80::9044:c5ee:4dd2:4f16%19]) with mapi id 14.03.0339.000; Sat, 6 May 2017 10:42:04 +0200 From: To: Julien Catalano , Alexander Pelov , "Pascal Thubert (pthubert)" CC: Charlie Perkins , lp-wan , Ana Minaburo Thread-Topic: [lp-wan] Terminology for LPWAN Networks Thread-Index: AQHSxFSV+U6NdVj8vEqrAKlM7ckZF6HjMO+AgADSPgCAABu2gIABrAgAgAE1roA= Date: Sat, 6 May 2017 08:42:02 +0000 Message-ID: <32134_1494060124_590D8C5C_32134_9931_1_D5335854.4328E%dominique.barthel@orange.com> References: <63720c5b4ed34971952039304eec1ffa@XCH-RCD-001.cisco.com> <5CD953CA-CEBD-4483-9839-3BF26C6C3A02@ackl.io> <0d2efe85-16f9-904c-aafd-f32ac1ce43ea@kerlink.fr> In-Reply-To: <0d2efe85-16f9-904c-aafd-f32ac1ce43ea@kerlink.fr> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.3.170325 x-originating-ip: [10.168.234.5] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [lp-wan] Terminology for LPWAN Networks X-BeenThere: lp-wan@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Low-Power Wide Area Networking \(LP-WAN\), also known as LPWA or Low-Rate WAN \(LR-WAN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 May 2017 08:42:09 -0000 Hello all, END-DEVICE sounds good to me. It also resonates with ES (End System) that is sometime used to designate the thing/host/device. Dominique Le 05/05/17 18:13, =AB lp-wan on behalf of Julien Catalano =BB a =E9crit : >Hello all, > >I tend to prefer using "END-DEVICE" or "ENDPOINT" instead of DEVICE, >which looks too generic and ambiguous to me. >A gateway or a router can also be called "devices" (as in "electronic >devices" or "network devices"). > >My (first!) 2 cents. >Julien > >On 04/05/2017 16:41, Alexander Pelov wrote: >> +1.=20 >> >> I still find it difficult to use "Thing" on daily basis, and generally >> tend to fall back to host, end-device or simply device. >> >> So, I=B9d go with what Charlie and Pascal said. Device is OK for me. >> >> Alex >> >> >> >>> Le 4 mai 2017 =E0 15:02, Pascal Thubert (pthubert) >> > a =E9crit : >>> >>> Same as Charlie, I agree but for =8Cthing=B9. I klike the idea to change >>> it to device, which is how it=B9s called in a number of venues I >>> participate(d) to. >>>=20=20 >>> Take care, >>>=20=20 >>> Pascal >>>=20=20 >>> *From:* Charlie Perkins [mailto:charles.perkins@earthlink.net] >>> *Sent:* jeudi 4 mai 2017 02:30 >>> *To:* Ana Minaburo >; lp-wan >>> > >>> *Cc:* Pascal Thubert (pthubert) >> >; Alexander Pelov >> > >>> *Subject:* Re: [lp-wan] Terminology for LPWAN Networks >>>=20=20 >>> >>> Hello Ana, >>> >>> I am O.K. with all of the terms except "thing". It seems to me that >>> particular term is irretrievably ambiguous, and does not offer any >>> helpful intuition about the intended meaning. The result would be >>> that it would be harder to write unambiguous specifications, and >>> suddenly other words like "anything" and "something" would become >>> dangerous. I would be happy with any of the other terms. I have >>> often used "device" for this meaning. >>> >>> Regards, >>> Charlie P. >>> >>>=20=20 >>> On 5/3/2017 2:29 PM, Ana Minaburo wrote: >>> >>> Hello,=20 >>>=20=20=20=20=20=20 >>> I have started doing a list for the most important terms we use >>> on the SCHC drafts, first I put all the names we have used to >>> define the same concept, second I put the name we have defined in >>> the drafts, and last I put one proposition, please feel free to >>> agree or not about this proposed terms. >>>=20=20=20=20=20=20 >>> Thanks >>> Ana >>>=20=20=20=20=20=20 >>>=20=20=20=20=20=20 >>> Used on draft >>> draft-overview or and >>> draft-SCHC Proposed >>>=20=20 >>> End-System, device, Thing , Host, node Host or >>> Thing THING (THG) >>> LPWAN Application Server, Application Server Application >>> Server Application (APP) >>> Network Gateway >>> Router or Network Gateway LPWAN Gateway >>> (LGW)=20=20=20=20=20 >>> LPWAN C/D (LC) >>> LC (LPWAN Compressor) >>> SCHC C/D >>> Compression/Decompression Function (CDF) CDF C/D >>> Function C/D Action (CDA) >>>=20=20=20=20=20=20 >>> >>> >>> >>> _______________________________________________ >>> >>> lp-wan mailing list >>> >>> lp-wan@ietf.org >>> >>> https://www.ietf.org/mailman/listinfo/lp-wan >>> >>>=20=20 >>> _______________________________________________ >>> lp-wan mailing list >>> lp-wan@ietf.org >>> https://www.ietf.org/mailman/listinfo/lp-wan >> >> >> >> _______________________________________________ >> lp-wan mailing list >> lp-wan@ietf.org >> https://www.ietf.org/mailman/listinfo/lp-wan > > ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Sat May 6 03:19:48 2017 Return-Path: X-Original-To: lp-wan@ietfa.amsl.com Delivered-To: lp-wan@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 947FF120727 for ; Sat, 6 May 2017 03:19:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.8 X-Spam-Level: X-Spam-Status: No, score=-2.8 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_MED=-2.3] 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 XG0GMMHY_PDd for ; Sat, 6 May 2017 03:19:45 -0700 (PDT) Received: from violet.upc.es (violet.upc.es [147.83.2.51]) (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 52BBE127058 for ; Sat, 6 May 2017 03:19:45 -0700 (PDT) Received: from entelserver.upc.edu (entelserver.upc.es [147.83.39.4]) by violet.upc.es (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id v46AJXva044276; Sat, 6 May 2017 12:19:33 +0200 Received: from webmail.entel.upc.edu (webmail.entel.upc.edu [147.83.39.6]) by entelserver.upc.edu (Postfix) with ESMTP id E50141D53C1; Sat, 6 May 2017 12:19:32 +0200 (CEST) Received: from 81.38.55.229 by webmail.entel.upc.edu with HTTP; Sat, 6 May 2017 12:19:28 +0200 Message-ID: <579c69d6abf7e8ede0863c8a82772a4a.squirrel@webmail.entel.upc.edu> In-Reply-To: <32134_1494060124_590D8C5C_32134_9931_1_D5335854.4328E%dominique.barthel@orange.com> References: <63720c5b4ed34971952039304eec1ffa@XCH-RCD-001.cisco.com> <5CD953CA-CEBD-4483-9839-3BF26C6C3A02@ackl.io> <0d2efe85-16f9-904c-aafd-f32ac1ce43ea@kerlink.fr> <32134_1494060124_590D8C5C_32134_9931_1_D5335854.4328E%dominique.barthel@orange.com> Date: Sat, 6 May 2017 12:19:28 +0200 From: "Carles Gomez Montenegro" To: dominique.barthel@orange.com Cc: "Julien Catalano" , "Alexander Pelov" , "Pascal Thubert (pthubert)" , "Charlie Perkins" , "lp-wan" , "Ana Minaburo" User-Agent: SquirrelMail/1.4.21-1.fc14 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: clamav-milter 0.99.2 at violet X-Virus-Status: Clean X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.3.9 (violet.upc.es [147.83.2.51]); Sat, 06 May 2017 12:19:34 +0200 (CEST) Archived-At: Subject: Re: [lp-wan] Terminology for LPWAN Networks X-BeenThere: lp-wan@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Low-Power Wide Area Networking \(LP-WAN\), also known as LPWA or Low-Rate WAN \(LR-WAN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 May 2017 10:19:48 -0000 +1 'End device' is more specific than 'device'. Cheers, Carles > Hello all, > > END-DEVICE sounds good to me. > It also resonates with ES (End System) that is sometime used to designate > the thing/host/device. > > Dominique > > Le 05/05/17 18:13, « lp-wan on behalf of Julien Catalano » > a écrit : > >>Hello all, >> >>I tend to prefer using "END-DEVICE" or "ENDPOINT" instead of DEVICE, >>which looks too generic and ambiguous to me. >>A gateway or a router can also be called "devices" (as in "electronic >>devices" or "network devices"). >> >>My (first!) 2 cents. >>Julien From nobody Wed May 10 08:22:28 2017 Return-Path: X-Original-To: lp-wan@ietfa.amsl.com Delivered-To: lp-wan@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E30C127B60; Wed, 10 May 2017 08:22:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 64GQkatw5fUN; Wed, 10 May 2017 08:22:24 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A89F129BD1; Wed, 10 May 2017 08:22:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11980; q=dns/txt; s=iport; t=1494429744; x=1495639344; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=G6T3YA1/qjkx5mZJ4Oapc9IEOdsWhHadb63clhEF6Ok=; b=a1RbgF0BihvVZ/+kzJGIj2q4Y0WKcoHJoyjDlotnFX4+lHg7GY/QLLv/ 9PeCV1Xr8LWqUk+Qp6/OaAJg4dAWA9jU+bbnGCZ/UIG+f+LPosSw09KBt 1V8WSKg69M9GC/m6OtvmIEAChYmXI0A0T/0ZXgnBKp2rioLofwHlTlF4c k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DKAAD+LhNZ/5JdJa1DEAoBGQEBAQECA?= =?us-ascii?q?QEBAQgBAQEBg1VigQwHjXqSSpUAgg8uhXaFAj8YAQIBAQEBAQEBayiFOQpHCxI?= =?us-ascii?q?BHBwMPCYBBA4NE4oGDjG0KjqDVYceAQEBAQEBAQEBAQEBAQEBAQEBIIZfgV6CZ?= =?us-ascii?q?4FwgWWBEwcLAQZkghmCbRoFiUSHIY0lAYcbi3aCDYU7iiyUQgEfOH8LcBVGhHM?= =?us-ascii?q?DHIFiAXYBhmqBIYENAQEB?= X-IronPort-AV: E=Sophos;i="5.38,320,1491264000"; d="scan'208";a="419489372" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 May 2017 15:22:23 +0000 Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id v4AFMNo1009665 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 10 May 2017 15:22:23 GMT Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-ALN-004.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 10 May 2017 10:22:22 -0500 Received: from xch-rcd-001.cisco.com ([173.37.102.11]) by XCH-RCD-001.cisco.com ([173.37.102.11]) with mapi id 15.00.1210.000; Wed, 10 May 2017 10:22:22 -0500 From: "Pascal Thubert (pthubert)" To: lp-wan CC: "lpwan-chairs@ietf.org" Thread-Topic: Meeting Minutes, LPWAN Interim Wednesday May-10-2017 Thread-Index: AdLJoLyeWTd7y8o0SYOOXBRa0mBlhA== Date: Wed, 10 May 2017 15:21:53 +0000 Deferred-Delivery: Wed, 10 May 2017 15:21:33 +0000 Message-ID: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.55.22.5] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [lp-wan] Meeting Minutes, LPWAN Interim Wednesday May-10-2017 X-BeenThere: lp-wan@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Low-Power Wide Area Networking \(LP-WAN\), also known as LPWA or Low-Rate WAN \(LR-WAN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 May 2017 15:22:27 -0000 Dear all The minutes and proceedings are uploaded on the IETF site, https://datatrac= ker.ietf.org/meeting/interim-2017-lpwan-02/session/lpwan =20 As they stand at this time, they are as below. Please let us know if we ne= ed to change anything: Connection details ------------ *=A0 =A0 Date: 7-8am US Pacific, 4pm CEST: http ://www.worldtimebuddy.com/?qm=3D1&lid=3D100,12,5392171,1850147&h=3D100&dat e=3D2017-05-10&sln=3D14-15=20 *=A0 =A0 Webex Link: https://cisco.webex.com/ciscosales/j.php?MTID=3Dme7f536292c568c696a054a7ff7= ef0746 *=A0 =A0 Meeting number (access code): 203 453 401=20 *=A0 =A0 Meeting password: chicalors (24422567 from phones) Agenda ------------ *=A0 =A0 [7:00]Administrivia=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 [ 2min]=20 =A0 =A0 o=A0 =A0 Note-Well, Blue Sheets, Scribes, Agenda Bashing=A0=20 =A0 =A0 o=A0 =A0 Approval minutes from last meeting *=A0 =A0 [7:02] LPWAN Overview=A0 (Steve)=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 [ 5min] *=A0 =A0 [7:07] SCHC IP/UDP Compression (Laurent, Ana, Carles)=A0 =A0 =A0 = =A0 =A0 [40min]=20 *=A0 =A0 [7:47] SCHC CoAP (Laurent)=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 [10min] *=A0 =A0 [7:47] AOB=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 [ 3min] Action Items ------------ * Alex:=20 Minute takers =A0 =A0 ------------- *=A0 =A0 Ana minaburo *=A0 =A0 Pascal Thubert *=A0 =A0 Carsten Bormann *=A0 =A0 Juan-Carlos Zuniga Attendees --------- *=A0 =A0 Alex Pelov [x] *=A0 =A0 Ana minaburo *=A0 =A0 Arunprabhu Kandasamy *=A0 =A0 Carles Gomez *=A0 =A0 Carsten Bormann=20 *=A0 =A0 Juan-Carlos Zuniga *=A0 =A0 Laurent Toutain=20 *=A0 =A0 Pascal Thubert *=A0 =A0 Samian Kaur=20 *=A0 =A0 Uday Davuluru Minutes ------- *=A0 =A0 [7:00]Administrivia=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 [ 2min] o=A0 =A0 Note-Well, Blue Sheets, Scribes, Agenda Bashing=A0 =3D> Agenda app= roved o=A0 =A0 Approval minutes from last meeting =3D> Minutes approved =A0 =A0 o=A0 =A0 Alex introdcuces the documents =A0 =A0=20 =A0 =A0=20 =A0 =A0 * No changes for agenda =A0 =A0 * Last minutes are approved =A0 =A0 * Remmind the charter actions and milestones =A0 =A0 * Action items from last meeting: =A0 =A0 Review IP/UDP draft from JC and DD =A0 =A0 - First Review from JC to Ana, most about confusing terms,=20 =A0 =A0 - Missed Fragmentation, he has already done SCHC compression part =A0 =A0 inputs from JCZ is already incorporated version 3 =A0 =A0 - JCZ will send out New comments for version 3 including the fragmentation part =A0 =A0 - draft CoAP: CB and MV =A0 =A0 - not yet done =A0 =A0 - AP: meeting in person at Prague may be 2hrs =A0 =A0 - LT: we will need 2hrs if we want to discuss the CoAP part Action Items from last meeting ------------------------------ *=A0 =A0 [7:02] LPWAN Overview=A0 (Steve)=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 [ 5min] =A0 =A0 o=A0 =A0 AP: Stephen cannot attend, Alex presenting =A0 =A0 o=A0 =A0 Stephen will send revision by Friday, then WG to do review till May 24th, LC ready version by May 30th=20 =A0 =A0 o Review by working group next week; friday; =A0 =A0 o Ana: next step to confirm the consensus on the vocabulary; *=A0 =A0 [7:07] SCHC IP/UDP Compression (Laurent, Ana, Carles)=A0 =A0 =A0 = =A0 =A0 [40min] o Presentor:Ana =A0 =A0 o changes in schc version3: modifications from JCZ incorporated =A0 =A0 This modifications seems to bring clearty to the draft =A0 =A0 o waiting for consensus on end device vs device =A0 =A0 - Consensus is called it Dev to match acronym =A0 =A0 o Application sever is now App because there is not necessarily a server, to be confirmed =A0 =A0 -Consensus is called it App=20 =A0 =A0 o Added W in NG -> NGW =A0 =A0 o Comment from JCZ was that the names could be confusion, Function vs. Action. Changing CDF to CDA. =A0 =A0 o JCZ: I asked people for feedback from external view about readability, thus suggested the chang= es, in particular for acronyms =A0 =A0 o JCZ: recommend using the term device, abbrev as Dev. Is that a good idea? =A0 =A0 o PT: +1; calling for consensus on that =A0 =A0 o CB: agreement.=20 =A0 =A0 o AP: agrees with Dev; onem2m calls DA:=20 =A0 =A0 o PT: Come with proposal and disucss in mailing list =A0 =A0 o LT: App is fine APP not as ??much since people may think it is an acronym as opposed to an Abbreviation; =A0 =A0 o PT: Agree; App, NGW, Dev. =A0 =A0 o AP: We need to advance on fragmentation, we have 25mn. =A0 =A0 o Carles now talks about fragmentation =A0 =A0 o CG: All changes were added in 03, thanks to everyone for the feedback =A0 =A0 o CG: for windoow mode, one bit is added (W bit) to avoid ambiguity, as a window flip flop. =A0 =A0 o Window is complemented to recognize which window is in used =A0 =A0 o Exmples for the ise of W:=20 =A0 =A0 =A0 =A0 The retries will use the same W is used, with the same valu= e o CB: repeating hi =A0 =A0 o PT do you want no window at all or do you want=20 =A0 =A0 o CB: Not window at all, the struct of transmission of the single packet is modify,=20 =A0 =A0 o PT: the window is to avoid ambiguity, the fragment counter is small in size of bits, so there is not enough to number all the fragments, o CB: confusion with the SN=20 =A0 =A0 o PT:=A0 If not trucking this is right but when trucking there is a sequence and we need to avoid ambiguity =A0 =A0 o CB: It is very expensive to do this =A0 =A0 o PT: The problem is the number of bits to number, so there is not enough so need a window, nd we need to eliminate the ambiguity o CB: More regular transmission than retransmission, it is more impotant to optimize regular ttransmission than retransmissions =A0 =A0 o PT: So we need more bits to renumber all this framents =A0 =A0 o AP: So the MTU is 11 bytes, so we need more than 200 to numebr this fragments=20 =A0 =A0 o CB: It is not necessary need a window =A0 =A0 o LT/ Well this is a mechanisms, what the ML think? it is a good solution about the reduction of bits, and it is reliable. What people want = to implement and use? =A0 =A0 o AP: We need to see avout this question, CG find a solution about the previous question about drapping out, so this is solved =A0 =A0 o CB: RFC 3819, section 8 =A0 =A0 o CG: Next slides; identify as pending in the lo ast meetings but now is on =A0 =A0 o CG: Possible solution, with an ambiguity that can arrise, with twoo format for transmission and retransmission=20 =A0 =A0 Replace the CFN with an absolute, AFN fragment number, with a size bigger than the CFN,= but need to be defined for different technologies =A0 =A0 o LT: When you send pckts for the 1st transmission and when retransmission the AFN is bigger so data is n= ot the same size, how you manage the modification in size of the data? =A0 =A0 o CG: There are different approaches, AFN is not defined yet, one possibility is = that data does not fit all the capacity iin teh tranmission and then is can fit completely the packet in the retranmisssion, it is not optimize but it can = allow us to resend the fragment =A0 =A0 LT =A0 =A0 PT: Trouble if we cannot detect then we cannot drop the packet =A0 =A0 LT: Detect can be done using the MIC in the end but do not waranty the fragment transmission, so we take the risk to loose the packet =A0 =A0 o CG: first attempt could send les than max so taht the AFN can fit in retry, =3D> loss of capacity but I dio not see anither way =A0 =A0 o AP: I feel that AFN > CFN leads to trouble. Need to bo written down =A0 =A0 o CG: If AFN is expected to be as CFN then we cannot said N=3DA so A not equal to any numbe= r, for the 1s transmiision we need an extra space,=20 =A0 =A0 oAP: If we reserve some space so A=3DN and we use A all the time=20 =A0 =A0 o CG: for the 1st attemp we use a FN and not an absolute number =A0 =A0 o AP: If we have a full window of losses, we drop the packet =A0 =A0 o CG: The probability is low, and we can check with MIC, it cannot say which fragment is mising but the error is detected =A0 =A0 o AP: There could be an event that there is a very big lost, so the MIC needs to detec thte transmissione rror.=A0 So we need to write down, and see that the technolog= y needs to detect and use the MIC=20 =A0 =A0 o CB: Any MIC has a chance to fail. You can also put a received length as an assurance. There are 2 directions one is more expensive than the other, so both need to be solved =A0 =A0 o CB the size can be in the all ones frame, or in the ack, depending on where the cost is =A0 =A0 o LT: we are fragmenting the uplink not the downlink =A0 =A0 o CB: Optimize for what is really expensive =A0 =A0 o PT: If the this frame is expensive then we can Ack=20 =A0 =A0 o LT: We need an uplink msg to send a downlink =A0 =A0 o PT: where it is expensive ? Sending ir more expensive than receiving by number of bytes, that present i= in the ACK, bitmap if self cab give the number of bytes =A0 =A0 o CB: If the ACK bitmap gets too big for the max frag size (and ACK is on the expensive direction), maybe use a fountain code and an ACK that just indicates the number of frag= ments missing.=A0 This also removes the need for an AFN, as the fountain code wou= ld simply continue the CFN sequence. =A0 =A0 o AP: If your CFN is 3 bits the window is 8, even if the SN is big you still sending 3 bits in CFN to have enough spa= ce for all technologies.=20 =A0 =A0 o PT: We need to study CB input, and also we send 100 fragments and we lose 10, the FN can express the bytes as the bitmap, if lo= ses are less then we indicate the list of the few instead of the bitmap than ca= n take a big place =A0 =A0 o PT: Do we really have this case?=20 =A0 =A0 o LT/AP: It is a possibility to have this, this mode makes sense, when deploying we need to consider the number of consecutive fragment lost, to built the packet. You = use this packet and verify with MIC =A0 =A0 o AP: This is a good things to explore, do we have the 2 modes to solve thes kind of problems? =A0 =A0 o LT: What we have to defin is the format and not the behavior, and when you solve this the draft= goes faster=20 =A0 =A0 o AP: agree with Laurent. settle on the format. Inclide this behavior makes sense =A0 =A0 o CG: Other updates made on the draft, =A0 =A0 o PT: We need to discusses more ACK, but sending back the langs , we got them all, f= ull bitmap maps once, to get all frames but I need to check the langs =A0 =A0 o AP: bitmap for the windows, to avoid ambiguity =A0 =A0 o LT: Ambuguity: loosing all the packet and receivng an ACK? =A0 =A0 o PT: That there is not 2 windows when it is waiting for an ACK =A0 =A0 o AP: the proposal the CG gives looks right, but not sure if the optimization would work. =A0 =A0 o LT: AFN is a particular number of CFN o PT: The choices will be done by technology. The event of retransmission i= s supposed to be rare. However, more than depending on the technology, it see= ms like it would need to be based on the deployment, which is much more compli= cated o LT: depends also on the application.=20 =A0 =A0 o CG: How each technology will manage the specific issue =A0 =A0 o AP: Continue further on the mailing list. CG: send an email when you can integerate these discussion. Diego and JCZ shall review the changes. *=A0 =A0 [7:47] SCHC CoAP (Laurent)=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 [10min] =A0 =A0 o Not covered =A0 =A0=20 *=A0 =A0 [7:47] AOB=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 [ 3min] =A0 =A0 o From nobody Thu May 11 00:32:46 2017 Return-Path: X-Original-To: lp-wan@ietfa.amsl.com Delivered-To: lp-wan@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 879051205F0 for ; Thu, 11 May 2017 00:32:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.399 X-Spam-Level: X-Spam-Status: No, score=-5.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 zc5fy2jiLFhp for ; Thu, 11 May 2017 00:32:43 -0700 (PDT) Received: from relais-inet.orange.com (mta241.mail.business.static.orange.com [80.12.66.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8700A127BA3 for ; Thu, 11 May 2017 00:32:42 -0700 (PDT) Received: from opfedar07.francetelecom.fr (unknown [xx.xx.xx.9]) by opfedar26.francetelecom.fr (ESMTP service) with ESMTP id D634A1C066D for ; Thu, 11 May 2017 09:32:40 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.63]) by opfedar07.francetelecom.fr (ESMTP service) with ESMTP id B9D52C0063 for ; Thu, 11 May 2017 09:32:40 +0200 (CEST) Received: from OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06]) by OPEXCLILM6E.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0339.000; Thu, 11 May 2017 09:32:40 +0200 From: To: "lp-wan@ietf.org" Thread-Topic: Terminology for LPWAN Networks Thread-Index: AdLIrUmZY0qQIkUUQ8O4AzKPwdT5agBe2flg Date: Thu, 11 May 2017 07:32:39 +0000 Message-ID: <7288_1494487960_59141398_7288_553_1_BC397CDFFDB82545B5E3571A77AB72043CC2353D@OPEXCLILM21.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: multipart/alternative; boundary="_000_BC397CDFFDB82545B5E3571A77AB72043CC2353DOPEXCLILM21corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [lp-wan] Terminology for LPWAN Networks X-BeenThere: lp-wan@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Low-Power Wide Area Networking \(LP-WAN\), also known as LPWA or Low-Rate WAN \(LR-WAN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 May 2017 07:32:45 -0000 --_000_BC397CDFFDB82545B5E3571A77AB72043CC2353DOPEXCLILM21corp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, Regarding terminology, it is not clear what is the difference between Radio= Gateway (RG) and Network Gateway (NGW). Adding definitions in section 2 (Vocabulary) would help. Thanks Philippe CHRISTIN ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_BC397CDFFDB82545B5E3571A77AB72043CC2353DOPEXCLILM21corp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

 

Regarding terminology, it = is not clear what is the difference between Radio Gateway (RG) and Network = Gateway (NGW).

Adding definitions in sect= ion 2 (Vocabulary) would help.

 

Thanks

 

Philippe CHR= ISTIN

 

______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_BC397CDFFDB82545B5E3571A77AB72043CC2353DOPEXCLILM21corp_-- From nobody Fri May 12 20:45:15 2017 Return-Path: X-Original-To: lp-wan@ietfa.amsl.com Delivered-To: lp-wan@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A5D3129AF1 for ; Fri, 12 May 2017 20:45:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.237 X-Spam-Level: * X-Spam-Status: No, score=1.237 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] autolearn=no 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 yRj3wP2tbkue for ; Fri, 12 May 2017 20:45:12 -0700 (PDT) Received: from mx1.bupt.edu.cn (mx1.bupt.edu.cn [211.68.68.2]) by ietfa.amsl.com (Postfix) with ESMTP id 86AA9127977 for ; Fri, 12 May 2017 20:42:43 -0700 (PDT) Received: from WeiGengyuPC (unknown [114.254.89.114]) by mx1.bupt.edu.cn (AnyMacro(G7)) with ESMTPA id 41D5419F388 for ; Sat, 13 May 2017 11:42:42 +0800 (HKT) Message-ID: From: "weigengyu" To: References: <149400726585.8434.8654374640287295976@ietfa.amsl.com> In-Reply-To: <149400726585.8434.8654374640287295976@ietfa.amsl.com> Date: Sat, 13 May 2017 11:42:40 +0800 Organization: BUPT MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3528.331 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331 Archived-At: Subject: Re: [lp-wan] I-D Action: draft-ietf-lpwan-ipv6-static-context-hc-03.txt X-BeenThere: lp-wan@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Low-Power Wide Area Networking \(LP-WAN\), also known as LPWA or Low-Rate WAN \(LR-WAN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 May 2017 03:45:14 -0000 Hi all, There is a question, maybe a silly question. Does the end-device in Lora, Sigfox, or the like networks need the facilities of UDP protocol? It is heard that it generally is simple one function device, the port multiplexing is required or not? Regards, Gengyu WEI Network Technology Center School of Computer Beijing University of Posts and Telecommunications -----原始邮件----- From: internet-drafts@ietf.org Sent: Saturday, May 06, 2017 2:01 AM To: i-d-announce@ietf.org Cc: lp-wan@ietf.org Subject: [lp-wan] I-D Action: draft-ietf-lpwan-ipv6-static-context-hc-03.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 over Low Power Wide-Area Networks of the IETF. Title : LPWAN Static Context Header Compression (SCHC) and fragmentation for IPv6 and UDP Authors : Ana Minaburo Laurent Toutain Carles Gomez Filename : draft-ietf-lpwan-ipv6-static-context-hc-03.txt Pages : 36 Date : 2017-05-05 Abstract: This document describes a header compression scheme and fragmentation functionality for IPv6/UDP protocols. These techniques are especially tailored for LPWAN (Low Power Wide Area Network) networks and could be extended to other protocol stacks. The Static Context Header Compression (SCHC) offers a great level of flexibility when processing the header fields. Static context means that information stored in the context which, describes field values, does not change during the packet transmission, avoiding complex resynchronization mechanisms, incompatible with LPWAN characteristics. In most of the cases, IPv6/UDP headers are reduced to a small identifier. This document describes the generic compression/decompression process and applies it to IPv6/UDP headers. Similar mechanisms for other protocols such as CoAP will be described in a separate document. Moreover, this document specifies fragmentation and reassembly mechanims for SCHC compressed packets exceeding the L2 pdu size and for the case where the SCHC compression is not possible then the IPv6/UDP packet is sent. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lpwan-ipv6-static-context-hc/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-lpwan-ipv6-static-context-hc-03 https://datatracker.ietf.org/doc/html/draft-ietf-lpwan-ipv6-static-context-hc-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lpwan-ipv6-static-context-hc-03 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/ _______________________________________________ lp-wan mailing list lp-wan@ietf.org https://www.ietf.org/mailman/listinfo/lp-wan From nobody Fri May 12 23:00:35 2017 Return-Path: X-Original-To: lp-wan@ietfa.amsl.com Delivered-To: lp-wan@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60392129B0F for ; Fri, 12 May 2017 23:00:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.798 X-Spam-Level: X-Spam-Status: No, score=0.798 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6cDp5I0Y83YH for ; Fri, 12 May 2017 23:00:31 -0700 (PDT) Received: from mx1.bupt.edu.cn (mx1.bupt.edu.cn [211.68.68.2]) by ietfa.amsl.com (Postfix) with ESMTP id 86B23129549 for ; Fri, 12 May 2017 22:57:59 -0700 (PDT) Received: from WeiGengyuPC (unknown [114.254.89.114]) by mx1.bupt.edu.cn (AnyMacro(G7)) with ESMTPA id 9DAA619F374 for ; Sat, 13 May 2017 13:57:58 +0800 (HKT) Message-ID: From: "weigengyu" To: References: <149400726585.8434.8654374640287295976@ietfa.amsl.com> In-Reply-To: Date: Sat, 13 May 2017 13:57:56 +0800 Organization: BUPT MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=response Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3528.331 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331 Archived-At: Subject: Re: [lp-wan] I-D Action: draft-ietf-lpwan-ipv6-static-context-hc-03.txt X-BeenThere: lp-wan@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Low-Power Wide Area Networking \(LP-WAN\), also known as LPWA or Low-Rate WAN \(LR-WAN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 May 2017 06:00:34 -0000 HI, In draft-ietf-lpwan-ipv6-static-context-hc-03, 3. Static Context Header Compression Figure 1 based on [I-D.ietf-lpwan-overview] terminology represents the architecture for compression/decompression. In draft-farrell-lpwan-overview-04, 2.1. LoRaWAN [[Ed: Text here is from [I-D.farrell-lpwan-lora-overview]]] In draft-farrell-lpwan-lora-overview-01, 2. Terminology o End-device: a LoRa client device, sometimes called a mote. Communicates with gateways. o Classes A, B and C define different device capabilities and modes of operation for end-devices. End-devices can transmit uplink messages at any time in any mode of operation (so long as e.g., ISM band restrictions are honoured). An end-device in Class A can only receive downlink messages at predetermined timeslots after each uplink message transmission. Class B allows the end-device to receive downlink messages at periodically scheduled timeslots. Class C allows receipt of downlink messages at anytime. Class selection is based on the end-devices’ application use case and its power supply. (While Classes B and C are not further described here, readers may have seen those terms elsewhere so we include them for clarity.) Based on the descriptions above, it is not clear for me to see whether the end-device requires the UDP facilities. Regards, Gengyu WEI Network Technology Center School of Computer Beijing University of Posts and Telecommunications -----原始邮件----- From: weigengyu Sent: Saturday, May 13, 2017 11:42 AM To: lp-wan@ietf.org Subject: Re: [lp-wan] I-D Action: draft-ietf-lpwan-ipv6-static-context-hc-03.txt Hi all, There is a question, maybe a silly question. Does the end-device in Lora, Sigfox, or the like networks need the facilities of UDP protocol? It is heard that it generally is simple one function device, the port multiplexing is required or not? Regards, Gengyu WEI Network Technology Center School of Computer Beijing University of Posts and Telecommunications -----原始邮件----- From: internet-drafts@ietf.org Sent: Saturday, May 06, 2017 2:01 AM To: i-d-announce@ietf.org Cc: lp-wan@ietf.org Subject: [lp-wan] I-D Action: draft-ietf-lpwan-ipv6-static-context-hc-03.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 over Low Power Wide-Area Networks of the IETF. Title : LPWAN Static Context Header Compression (SCHC) and fragmentation for IPv6 and UDP Authors : Ana Minaburo Laurent Toutain Carles Gomez Filename : draft-ietf-lpwan-ipv6-static-context-hc-03.txt Pages : 36 Date : 2017-05-05 Abstract: This document describes a header compression scheme and fragmentation functionality for IPv6/UDP protocols. These techniques are especially tailored for LPWAN (Low Power Wide Area Network) networks and could be extended to other protocol stacks. The Static Context Header Compression (SCHC) offers a great level of flexibility when processing the header fields. Static context means that information stored in the context which, describes field values, does not change during the packet transmission, avoiding complex resynchronization mechanisms, incompatible with LPWAN characteristics. In most of the cases, IPv6/UDP headers are reduced to a small identifier. This document describes the generic compression/decompression process and applies it to IPv6/UDP headers. Similar mechanisms for other protocols such as CoAP will be described in a separate document. Moreover, this document specifies fragmentation and reassembly mechanims for SCHC compressed packets exceeding the L2 pdu size and for the case where the SCHC compression is not possible then the IPv6/UDP packet is sent. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lpwan-ipv6-static-context-hc/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-lpwan-ipv6-static-context-hc-03 https://datatracker.ietf.org/doc/html/draft-ietf-lpwan-ipv6-static-context-hc-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lpwan-ipv6-static-context-hc-03 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/ _______________________________________________ lp-wan mailing list lp-wan@ietf.org https://www.ietf.org/mailman/listinfo/lp-wan _______________________________________________ lp-wan mailing list lp-wan@ietf.org https://www.ietf.org/mailman/listinfo/lp-wan From nobody Sat May 13 06:29:06 2017 Return-Path: X-Original-To: lp-wan@ietfa.amsl.com Delivered-To: lp-wan@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 633F0129B52 for ; Sat, 13 May 2017 06:28:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.702 X-Spam-Level: X-Spam-Status: No, score=-4.702 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=-2.8, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sigfoxgroup.onmicrosoft.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 cFrkDDB_nY1t for ; Sat, 13 May 2017 06:28:46 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0130.outbound.protection.outlook.com [104.47.0.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B1BF129B40 for ; Sat, 13 May 2017 06:26:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sigfoxgroup.onmicrosoft.com; s=selector1-sigfox-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=UTCwGk80GBtF7DTTyyWp0xAQd5pGK7PEOaZrbNcfz5I=; b=AKJjFEDk6/lWJTdTwrw6ocqo3ma0EbZHt/kjdmgy/awTftUv4l3zLv4eEBGeeJcGPzNCjp+y4ZnDDqZNBy3t8CQzCtRweCAWqygsqHCRw4vX/rGVr53tyVH3XYUpPsVHHglnn47LbIKmx916udHBAyo/oIQqjW/Wk+3ZT8uviFk= Received: from DB6PR08MB2679.eurprd08.prod.outlook.com (10.175.235.12) by DB6PR08MB2679.eurprd08.prod.outlook.com (10.175.235.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1084.16; Sat, 13 May 2017 13:26:44 +0000 Received: from DB6PR08MB2679.eurprd08.prod.outlook.com ([fe80::3c08:54b8:1c7c:498a]) by DB6PR08MB2679.eurprd08.prod.outlook.com ([fe80::3c08:54b8:1c7c:498a%13]) with mapi id 15.01.1084.020; Sat, 13 May 2017 13:26:44 +0000 From: Juan Carlos Zuniga To: weigengyu , "lp-wan@ietf.org" Thread-Topic: [lp-wan] I-D Action: draft-ietf-lpwan-ipv6-static-context-hc-03.txt Thread-Index: AQHSxcmWE6nZkl3R706y6Booc4wueKHxql0AgACgpbA= Date: Sat, 13 May 2017 13:26:44 +0000 Message-ID: References: <149400726585.8434.8654374640287295976@ietfa.amsl.com> In-Reply-To: Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: bupt.edu.cn; dkim=none (message not signed) header.d=none;bupt.edu.cn; dmarc=none action=none header.from=sigfox.com; x-originating-ip: [96.127.243.254] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DB6PR08MB2679; 7:B7MyILB8EG5K8uzkSvV+8WmcF49jQFd8PtbEafKibccHbAdE2wXQNKzHfJysMxR/aP2RVJ34AdXaX8DfCsmNmOj4/iV1hlvEKaZjV+rbGFdPl5Ya909MO09MBhAbJRm1QbCBZLppQpgzt+ye8BDuCIyw1ckxOV0ckb1Qj8Bce/3BiQqqvXwEXvU7CbM8JUFwhNU9ML1R7AK5gwOhipFHPPcbWCVJ0x8yu3ePjY+8v4fIDcjBcd4KrmC2hgpWUFUbj5MMGCnM+zkVEK83Sqd1TufZR1Ot5iJH4WdbNm8BQhiJeEl+4/sUIAAk7309HMquXiKDYx9j/JteRdqMpBFDwA== x-ms-office365-filtering-correlation-id: 571a14cb-f88f-4d4f-6ba2-08d49a03b301 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:DB6PR08MB2679; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(93006095)(93001095)(6041248)(20161123555025)(20161123560025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123558100)(6072148); SRVR:DB6PR08MB2679; BCL:0; PCL:0; RULEID:; SRVR:DB6PR08MB2679; x-forefront-prvs: 0306EE2ED4 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39410400002)(39400400002)(39450400003)(39830400002)(377424004)(377454003)(53754006)(13464003)(6436002)(6306002)(66066001)(76176999)(478600001)(3846002)(50986999)(102836003)(6506006)(6116002)(55016002)(38730400002)(7736002)(99286003)(86362001)(229853002)(9686003)(2906002)(5250100002)(54356999)(2950100002)(5660300001)(74316002)(7696004)(8676002)(189998001)(2900100001)(53546009)(25786009)(33656002)(3660700001)(81166006)(3280700002)(6246003)(53936002)(2171002)(230783001)(8936002)(305945005)(2501003); DIR:OUT; SFP:1102; SCL:1; SRVR:DB6PR08MB2679; H:DB6PR08MB2679.eurprd08.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: sigfox.com X-MS-Exchange-CrossTenant-originalarrivaltime: 13 May 2017 13:26:44.2244 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: fcbc8bb1-061e-4b94-9f70-3ad917b0c8d3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR08MB2679 Archived-At: Subject: Re: [lp-wan] I-D Action: draft-ietf-lpwan-ipv6-static-context-hc-03.txt X-BeenThere: lp-wan@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Low-Power Wide Area Networking \(LP-WAN\), also known as LPWA or Low-Rate WAN \(LR-WAN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 May 2017 13:28:49 -0000 SGksDQoNCk5vdCBhbGwgZGV2aWNlcyBuZWVkIHRvIGltcGxlbWVudCB0aGUgSVAgc3RhY2suIA0K DQpJbiBDaGljYWdvIHdlIGRlbW9uc3RyYXRlZCBob3cgdHdvIHR5cGUgb2YgZGV2aWNlcywgb25l IFJhc3BiZXJyeSBQaSAod2l0aCBmdWxsIElQIHN0YWNrKSBhbmQgb25lIHNpbXBsZSBzZW5zb3Ig d2l0aCBhIG1pY3JvY29udHJvbGxlciAod2l0aCBubyBJUCBzdGFjaywgVURQLCBldGMuKSwgd2Vy ZSBhYmxlIHRvIGNvbW11bmljYXRlIHdpdGggYSBDb0FQL1VEUC9JUHY2IEludGVybmV0IGFwcGxp Y2F0aW9uIGJ5IHVzaW5nIFNDSEMgcnVsZXMuDQoNCkJlc3QsDQoNCkp1YW4gQ2FybG9zIA0KDQo+ IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IGxwLXdhbiBbbWFpbHRvOmxwLXdh bi1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2Ygd2VpZ2VuZ3l1DQo+IFNlbnQ6IE1heSAx MiwgMjAxNyAxMTo0MyBQTQ0KPiBUbzogbHAtd2FuQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBb bHAtd2FuXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLWxwd2FuLWlwdjYtc3RhdGljLWNvbnRleHQt aGMtMDMudHh0DQo+IA0KPiBIaSBhbGwsDQo+IA0KPiBUaGVyZSBpcyBhIHF1ZXN0aW9uLCBtYXli ZSBhIHNpbGx5IHF1ZXN0aW9uLg0KPiANCj4gRG9lcyB0aGUgZW5kLWRldmljZSBpbiBMb3JhLCBT aWdmb3gsIG9yIHRoZSBsaWtlIG5ldHdvcmtzIG5lZWQgdGhlIGZhY2lsaXRpZXMgb2YNCj4gVURQ IHByb3RvY29sPw0KPiBJdCBpcyBoZWFyZCB0aGF0IGl0IGdlbmVyYWxseSBpcyBzaW1wbGUgb25l IGZ1bmN0aW9uIGRldmljZSwgdGhlIHBvcnQgbXVsdGlwbGV4aW5nDQo+IGlzIHJlcXVpcmVkIG9y IG5vdD8NCj4gDQo+IFJlZ2FyZHMsDQo+IA0KPiBHZW5neXUgV0VJDQo+IE5ldHdvcmsgVGVjaG5v bG9neSBDZW50ZXINCj4gU2Nob29sIG9mIENvbXB1dGVyDQo+IEJlaWppbmcgVW5pdmVyc2l0eSBv ZiBQb3N0cyBhbmQgVGVsZWNvbW11bmljYXRpb25zDQo+IC0tLS0t5Y6f5aeL6YKu5Lu2LS0tLS0N Cj4gRnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnDQo+IFNlbnQ6IFNhdHVyZGF5LCBNYXkg MDYsIDIwMTcgMjowMSBBTQ0KPiBUbzogaS1kLWFubm91bmNlQGlldGYub3JnDQo+IENjOiBscC13 YW5AaWV0Zi5vcmcNCj4gU3ViamVjdDogW2xwLXdhbl0gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1s cHdhbi1pcHY2LXN0YXRpYy1jb250ZXh0LWhjLTAzLnR4dA0KPiANCj4gDQo+IEEgTmV3IEludGVy bmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0cw0K PiBkaXJlY3Rvcmllcy4NCj4gVGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUgSVB2NiBv dmVyIExvdyBQb3dlciBXaWRlLUFyZWEgTmV0d29ya3Mgb2YNCj4gdGhlIElFVEYuDQo+IA0KPiAg ICAgICAgIFRpdGxlICAgICAgICAgICA6IExQV0FOIFN0YXRpYyBDb250ZXh0IEhlYWRlciBDb21w cmVzc2lvbiAoU0NIQykgYW5kDQo+IGZyYWdtZW50YXRpb24gZm9yIElQdjYgYW5kIFVEUA0KPiAg ICAgICAgIEF1dGhvcnMgICAgICAgICA6IEFuYSBNaW5hYnVybw0KPiAgICAgICAgICAgICAgICAg ICAgICAgICAgIExhdXJlbnQgVG91dGFpbg0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgIENh cmxlcyBHb21leg0KPiBGaWxlbmFtZSAgICAgICAgOiBkcmFmdC1pZXRmLWxwd2FuLWlwdjYtc3Rh dGljLWNvbnRleHQtaGMtMDMudHh0DQo+IFBhZ2VzICAgICAgICAgICA6IDM2DQo+IERhdGUgICAg ICAgICAgICA6IDIwMTctMDUtMDUNCj4gDQo+IEFic3RyYWN0Og0KPiAgICBUaGlzIGRvY3VtZW50 IGRlc2NyaWJlcyBhIGhlYWRlciBjb21wcmVzc2lvbiBzY2hlbWUgYW5kIGZyYWdtZW50YXRpb24N Cj4gICAgZnVuY3Rpb25hbGl0eSBmb3IgSVB2Ni9VRFAgcHJvdG9jb2xzLiAgVGhlc2UgdGVjaG5p cXVlcyBhcmUNCj4gICAgZXNwZWNpYWxseSB0YWlsb3JlZCBmb3IgTFBXQU4gKExvdyBQb3dlciBX aWRlIEFyZWEgTmV0d29yaykgbmV0d29ya3MNCj4gICAgYW5kIGNvdWxkIGJlIGV4dGVuZGVkIHRv IG90aGVyIHByb3RvY29sIHN0YWNrcy4NCj4gDQo+ICAgIFRoZSBTdGF0aWMgQ29udGV4dCBIZWFk ZXIgQ29tcHJlc3Npb24gKFNDSEMpIG9mZmVycyBhIGdyZWF0IGxldmVsIG9mDQo+ICAgIGZsZXhp YmlsaXR5IHdoZW4gcHJvY2Vzc2luZyB0aGUgaGVhZGVyIGZpZWxkcy4gIFN0YXRpYyBjb250ZXh0 IG1lYW5zDQo+ICAgIHRoYXQgaW5mb3JtYXRpb24gc3RvcmVkIGluIHRoZSBjb250ZXh0IHdoaWNo LCBkZXNjcmliZXMgZmllbGQgdmFsdWVzLA0KPiAgICBkb2VzIG5vdCBjaGFuZ2UgZHVyaW5nIHRo ZSBwYWNrZXQgdHJhbnNtaXNzaW9uLCBhdm9pZGluZyBjb21wbGV4DQo+ICAgIHJlc3luY2hyb25p emF0aW9uIG1lY2hhbmlzbXMsIGluY29tcGF0aWJsZSB3aXRoIExQV0FODQo+ICAgIGNoYXJhY3Rl cmlzdGljcy4gIEluIG1vc3Qgb2YgdGhlIGNhc2VzLCBJUHY2L1VEUCBoZWFkZXJzIGFyZSByZWR1 Y2VkDQo+ICAgIHRvIGEgc21hbGwgaWRlbnRpZmllci4NCj4gDQo+ICAgIFRoaXMgZG9jdW1lbnQg ZGVzY3JpYmVzIHRoZSBnZW5lcmljIGNvbXByZXNzaW9uL2RlY29tcHJlc3Npb24gcHJvY2Vzcw0K PiAgICBhbmQgYXBwbGllcyBpdCB0byBJUHY2L1VEUCBoZWFkZXJzLiAgU2ltaWxhciBtZWNoYW5p c21zIGZvciBvdGhlcg0KPiAgICBwcm90b2NvbHMgc3VjaCBhcyBDb0FQIHdpbGwgYmUgZGVzY3Jp YmVkIGluIGEgc2VwYXJhdGUgZG9jdW1lbnQuDQo+ICAgIE1vcmVvdmVyLCB0aGlzIGRvY3VtZW50 IHNwZWNpZmllcyBmcmFnbWVudGF0aW9uIGFuZCByZWFzc2VtYmx5DQo+ICAgIG1lY2hhbmltcyBm b3IgU0NIQyBjb21wcmVzc2VkIHBhY2tldHMgZXhjZWVkaW5nIHRoZSBMMiBwZHUgc2l6ZSBhbmQN Cj4gICAgZm9yIHRoZSBjYXNlIHdoZXJlIHRoZSBTQ0hDIGNvbXByZXNzaW9uIGlzIG5vdCBwb3Nz aWJsZSB0aGVuIHRoZQ0KPiAgICBJUHY2L1VEUCBwYWNrZXQgaXMgc2VudC4NCj4gDQo+IA0KPiBU aGUgSUVURiBkYXRhdHJhY2tlciBzdGF0dXMgcGFnZSBmb3IgdGhpcyBkcmFmdCBpczoNCj4gaHR0 cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1scHdhbi1pcHY2LXN0YXRp Yy1jb250ZXh0LWhjLw0KPiANCj4gVGhlcmUgYXJlIGFsc28gaHRtbGl6ZWQgdmVyc2lvbnMgYXZh aWxhYmxlIGF0Og0KPiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1scHdh bi1pcHY2LXN0YXRpYy1jb250ZXh0LWhjLTAzDQo+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvZG9jL2h0bWwvZHJhZnQtaWV0Zi1scHdhbi1pcHY2LXN0YXRpYy1jb250ZXh0LWhjLQ0KPiAw Mw0KPiANCj4gQSBkaWZmIGZyb20gdGhlIHByZXZpb3VzIHZlcnNpb24gaXMgYXZhaWxhYmxlIGF0 Og0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1scHdhbi1p cHY2LXN0YXRpYy1jb250ZXh0LWhjLTAzDQo+IA0KPiANCj4gUGxlYXNlIG5vdGUgdGhhdCBpdCBt YXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbg0K PiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRv b2xzLmlldGYub3JnLg0KPiANCj4gSW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBi eSBhbm9ueW1vdXMgRlRQIGF0Og0KPiBmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRz Lw0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cj4gbHAtd2FuIG1haWxpbmcgbGlzdA0KPiBscC13YW5AaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9scC13YW4NCj4gDQo+IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IGxwLXdhbiBtYWlsaW5nIGxpc3QNCj4g bHAtd2FuQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v bHAtd2FuDQo= From nobody Sat May 13 08:41:58 2017 Return-Path: X-Original-To: lp-wan@ietfa.amsl.com Delivered-To: lp-wan@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBF53129B05 for ; Sat, 13 May 2017 08:41:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.463 X-Spam-Level: X-Spam-Status: No, score=-1.463 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] autolearn=no 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 T08QaLZSJCtx for ; Sat, 13 May 2017 08:41:54 -0700 (PDT) Received: from mx1.bupt.edu.cn (mx1.bupt.edu.cn [211.68.68.2]) by ietfa.amsl.com (Postfix) with ESMTP id 138EC129601 for ; Sat, 13 May 2017 08:40:04 -0700 (PDT) Received: from WeiGengyuPC (unknown [114.254.89.114]) by mx1.bupt.edu.cn (AnyMacro(G7)) with ESMTPA id 4C01D19F374; Sat, 13 May 2017 23:40:02 +0800 (HKT) Message-ID: <8C6EB16391684A7DB1E8C9040F48C612@WeiGengyuPC> From: "weigengyu" To: "Juan Carlos Zuniga" , References: <149400726585.8434.8654374640287295976@ietfa.amsl.com> In-Reply-To: Date: Sat, 13 May 2017 23:39:59 +0800 Organization: BUPT MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3528.331 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331 Archived-At: Subject: Re: [lp-wan] I-D Action: draft-ietf-lpwan-ipv6-static-context-hc-03.txt X-BeenThere: lp-wan@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Low-Power Wide Area Networking \(LP-WAN\), also known as LPWA or Low-Rate WAN \(LR-WAN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 May 2017 15:41:57 -0000 Hi Juan， 〉were able to communicate with a CoAP/UDP/IPv6 Internet application by using SCHC rules. One node being able to communicate with another one means two nodes should share some contexts. What are they, the IPv6 context, or UDP/IPv6 contexts, or CoAP/UDP/IPv6 contexts. Regards, Gengyu WEI Network Technology Center School of Computer Beijing University of Posts and Telecommunications -----原始邮件----- From: Juan Carlos Zuniga Sent: Saturday, May 13, 2017 9:26 PM To: weigengyu ; lp-wan@ietf.org Subject: Re: [lp-wan] I-D Action: draft-ietf-lpwan-ipv6-static-context-hc-03.txt Hi, Not all devices need to implement the IP stack. In Chicago we demonstrated how two type of devices, one Raspberry Pi (with full IP stack) and one simple sensor with a microcontroller (with no IP stack, UDP, etc.), were able to communicate with a CoAP/UDP/IPv6 Internet application by using SCHC rules. Best, Juan Carlos > -----Original Message----- > From: lp-wan [mailto:lp-wan-bounces@ietf.org] On Behalf Of weigengyu > Sent: May 12, 2017 11:43 PM > To: lp-wan@ietf.org > Subject: Re: [lp-wan] I-D Action: > draft-ietf-lpwan-ipv6-static-context-hc-03.txt > > Hi all, > > There is a question, maybe a silly question. > > Does the end-device in Lora, Sigfox, or the like networks need the > facilities of > UDP protocol? > It is heard that it generally is simple one function device, the port > multiplexing > is required or not? > > Regards, > > Gengyu WEI > Network Technology Center > School of Computer > Beijing University of Posts and Telecommunications > -----原始邮件----- > From: internet-drafts@ietf.org > Sent: Saturday, May 06, 2017 2:01 AM > To: i-d-announce@ietf.org > Cc: lp-wan@ietf.org > Subject: [lp-wan] I-D Action: > draft-ietf-lpwan-ipv6-static-context-hc-03.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the IPv6 over Low Power Wide-Area Networks of > the IETF. > > Title : LPWAN Static Context Header Compression (SCHC) > and > fragmentation for IPv6 and UDP > Authors : Ana Minaburo > Laurent Toutain > Carles Gomez > Filename : draft-ietf-lpwan-ipv6-static-context-hc-03.txt > Pages : 36 > Date : 2017-05-05 > > Abstract: > This document describes a header compression scheme and fragmentation > functionality for IPv6/UDP protocols. These techniques are > especially tailored for LPWAN (Low Power Wide Area Network) networks > and could be extended to other protocol stacks. > > The Static Context Header Compression (SCHC) offers a great level of > flexibility when processing the header fields. Static context means > that information stored in the context which, describes field values, > does not change during the packet transmission, avoiding complex > resynchronization mechanisms, incompatible with LPWAN > characteristics. In most of the cases, IPv6/UDP headers are reduced > to a small identifier. > > This document describes the generic compression/decompression process > and applies it to IPv6/UDP headers. Similar mechanisms for other > protocols such as CoAP will be described in a separate document. > Moreover, this document specifies fragmentation and reassembly > mechanims for SCHC compressed packets exceeding the L2 pdu size and > for the case where the SCHC compression is not possible then the > IPv6/UDP packet is sent. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-lpwan-ipv6-static-context-hc/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-lpwan-ipv6-static-context-hc-03 > https://datatracker.ietf.org/doc/html/draft-ietf-lpwan-ipv6-static-context-hc- > 03 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-lpwan-ipv6-static-context-hc-03 > > > 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/ > > _______________________________________________ > lp-wan mailing list > lp-wan@ietf.org > https://www.ietf.org/mailman/listinfo/lp-wan > > _______________________________________________ > lp-wan mailing list > lp-wan@ietf.org > https://www.ietf.org/mailman/listinfo/lp-wan _______________________________________________ lp-wan mailing list lp-wan@ietf.org https://www.ietf.org/mailman/listinfo/lp-wan From nobody Sat May 13 15:09:05 2017 Return-Path: X-Original-To: lp-wan@ietfa.amsl.com Delivered-To: lp-wan@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD7D212947E for ; Sat, 13 May 2017 15:09:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 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_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sigfoxgroup.onmicrosoft.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 hruaVqZR6t-i for ; Sat, 13 May 2017 15:08:59 -0700 (PDT) Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30106.outbound.protection.outlook.com [40.107.3.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E58E512E034 for ; Sat, 13 May 2017 15:06:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sigfoxgroup.onmicrosoft.com; s=selector1-sigfox-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=ExvqY/hT6G1qV2vl7GMm4Rpui81FWD7a+xuQ9a0QNLA=; b=CI976L3nqvPOFl/ofUGFpvIWVzfvhEWfUrWuleHhFaO1m6pD/YuZhAGRpUKb11uESxHVObSPaZyVwaGW/E+weyHwW2G1G9l8Jeyo8UJHXZC5jpjMB/qTQ1t43oMC0eRJWKvnSpSxNO3DRiYdP82TUr9SmUj7ZBy8ldb4RPH8mTY= Received: from DB6PR08MB2679.eurprd08.prod.outlook.com (10.175.235.12) by DB6PR08MB2678.eurprd08.prod.outlook.com (10.175.235.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1084.16; Sat, 13 May 2017 22:06:45 +0000 Received: from DB6PR08MB2679.eurprd08.prod.outlook.com ([fe80::3c08:54b8:1c7c:498a]) by DB6PR08MB2679.eurprd08.prod.outlook.com ([fe80::3c08:54b8:1c7c:498a%13]) with mapi id 15.01.1084.020; Sat, 13 May 2017 22:06:45 +0000 From: Juan Carlos Zuniga To: weigengyu , "lp-wan@ietf.org" Thread-Topic: [lp-wan] I-D Action: draft-ietf-lpwan-ipv6-static-context-hc-03.txt Thread-Index: AQHSxcmWE6nZkl3R706y6Booc4wueKHxql0AgACgpbCAACfGgIAAarLA Date: Sat, 13 May 2017 22:06:45 +0000 Message-ID: References: <149400726585.8434.8654374640287295976@ietfa.amsl.com> <8C6EB16391684A7DB1E8C9040F48C612@WeiGengyuPC> In-Reply-To: <8C6EB16391684A7DB1E8C9040F48C612@WeiGengyuPC> Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: bupt.edu.cn; dkim=none (message not signed) header.d=none;bupt.edu.cn; dmarc=none action=none header.from=sigfox.com; x-originating-ip: [96.127.243.254] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DB6PR08MB2678; 7:zE1R4arUnzYm2oZBHYybSOh5ZQNoshHGE7aM1glQExMK4eUm1akozR0KJDd3GjQj1fC4bRvsiT/JqpyaP2NKXIJZTIlqWEKCs6rSQB4HA0sRDeVhHsIFzDvQNVEzp6psjARRIzmR1VFRd1AL6HmamxONTBchd8q+gFpvX5T3UuhjWxjMM6u171QeJ340+8dDzNCP86AtRu/Sz227YubwrqezuCfNsoJmjT9tDmrzn1y57u6y32/oHRA1j1+JqDllLZnECyrT6TiWK9cSi/+3TWJoTtNWn+K8sN5k4lXAHcOQqSNU6IOvemTjRF/pHrmYTz9fIxubre/JEXqN5YfDgw== x-ms-office365-filtering-correlation-id: 71b9e9ed-5b74-45fc-1573-08d49a4c584b x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081)(201702281549075); SRVR:DB6PR08MB2678; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(3002001)(6041248)(20161123564025)(20161123562025)(20161123558100)(20161123555025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148); SRVR:DB6PR08MB2678; BCL:0; PCL:0; RULEID:; SRVR:DB6PR08MB2678; x-forefront-prvs: 0306EE2ED4 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39410400002)(39400400002)(39830400002)(39450400003)(53754006)(13464003)(377424004)(377454003)(2171002)(86362001)(93886004)(99286003)(6246003)(6306002)(76176999)(53936002)(9686003)(5250100002)(3280700002)(6436002)(8936002)(50986999)(55016002)(6116002)(3846002)(38730400002)(74316002)(102836003)(5660300001)(478600001)(66066001)(33656002)(25786009)(229853002)(7736002)(6506006)(230783001)(2501003)(8676002)(54356999)(305945005)(189998001)(2906002)(3660700001)(81166006)(2950100002)(53546009)(7696004)(2900100001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB6PR08MB2678; H:DB6PR08MB2679.eurprd08.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: sigfox.com X-MS-Exchange-CrossTenant-originalarrivaltime: 13 May 2017 22:06:45.4139 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: fcbc8bb1-061e-4b94-9f70-3ad917b0c8d3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR08MB2678 Archived-At: Subject: Re: [lp-wan] I-D Action: draft-ietf-lpwan-ipv6-static-context-hc-03.txt X-BeenThere: lp-wan@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Low-Power Wide Area Networking \(LP-WAN\), also known as LPWA or Low-Rate WAN \(LR-WAN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 May 2017 22:09:04 -0000 SGkgR2VuZ3l1LA0KDQpUaGV5IHdlcmUgc2hhcmluZyB0aGUgc2FtZSBDb0FQL1VEUC9JUHY2IGNv bnRleHQuIA0KT25lIGRldmljZSB3YXMgY29tcHJlc3NpbmcvZGVjb21wcmVzc2luZywgYW5kIHRo ZSBvdGhlciBvbmUgd2FzbuKAmXQuICANCg0KQmVzdCwNCg0KSnVhbiBDYXJsb3MgDQoNCj4gLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogd2VpZ2VuZ3l1IFttYWlsdG86d2VpZ2Vu Z3l1QGJ1cHQuZWR1LmNuXQ0KPiBTZW50OiBNYXkgMTMsIDIwMTcgMTE6NDAgQU0NCj4gVG86IEp1 YW4gQ2FybG9zIFp1bmlnYSA8anVhbmNhcmxvcy56dW5pZ2FAc2lnZm94LmNvbT47IGxwLXdhbkBp ZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW2xwLXdhbl0gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1s cHdhbi1pcHY2LXN0YXRpYy1jb250ZXh0LWhjLTAzLnR4dA0KPiANCj4gSGkgSnVhbu+8jA0KPiAN Cj4g44CJd2VyZSBhYmxlIHRvIGNvbW11bmljYXRlIHdpdGggYSBDb0FQL1VEUC9JUHY2IEludGVy bmV0IGFwcGxpY2F0aW9uIGJ5DQo+IHVzaW5nIFNDSEMgcnVsZXMuDQo+IA0KPiBPbmUgbm9kZSBi ZWluZyBhYmxlIHRvIGNvbW11bmljYXRlIHdpdGggYW5vdGhlciBvbmUgbWVhbnMgdHdvIG5vZGVz DQo+IHNob3VsZCBzaGFyZSBzb21lIGNvbnRleHRzLg0KPiBXaGF0IGFyZSB0aGV5LCB0aGUgSVB2 NiBjb250ZXh0LCBvciBVRFAvSVB2NiBjb250ZXh0cywgb3IgQ29BUC9VRFAvSVB2Ng0KPiBjb250 ZXh0cy4NCj4gDQo+IFJlZ2FyZHMsDQo+IA0KPiBHZW5neXUgV0VJDQo+IE5ldHdvcmsgVGVjaG5v bG9neSBDZW50ZXINCj4gU2Nob29sIG9mIENvbXB1dGVyDQo+IEJlaWppbmcgVW5pdmVyc2l0eSBv ZiBQb3N0cyBhbmQgVGVsZWNvbW11bmljYXRpb25zDQo+IC0tLS0t5Y6f5aeL6YKu5Lu2LS0tLS0N Cj4gRnJvbTogSnVhbiBDYXJsb3MgWnVuaWdhDQo+IFNlbnQ6IFNhdHVyZGF5LCBNYXkgMTMsIDIw MTcgOToyNiBQTQ0KPiBUbzogd2VpZ2VuZ3l1IDsgbHAtd2FuQGlldGYub3JnDQo+IFN1YmplY3Q6 IFJlOiBbbHAtd2FuXSBJLUQgQWN0aW9uOg0KPiBkcmFmdC1pZXRmLWxwd2FuLWlwdjYtc3RhdGlj LWNvbnRleHQtaGMtMDMudHh0DQo+IA0KPiBIaSwNCj4gDQo+IE5vdCBhbGwgZGV2aWNlcyBuZWVk IHRvIGltcGxlbWVudCB0aGUgSVAgc3RhY2suDQo+IA0KPiBJbiBDaGljYWdvIHdlIGRlbW9uc3Ry YXRlZCBob3cgdHdvIHR5cGUgb2YgZGV2aWNlcywgb25lIFJhc3BiZXJyeSBQaSAod2l0aA0KPiBm dWxsIElQIHN0YWNrKSBhbmQgb25lIHNpbXBsZSBzZW5zb3Igd2l0aCBhIG1pY3JvY29udHJvbGxl ciAod2l0aCBubyBJUCBzdGFjaywNCj4gVURQLCBldGMuKSwgd2VyZSBhYmxlIHRvIGNvbW11bmlj YXRlIHdpdGggYSBDb0FQL1VEUC9JUHY2IEludGVybmV0DQo+IGFwcGxpY2F0aW9uIGJ5IHVzaW5n IFNDSEMgcnVsZXMuDQo+IA0KPiBCZXN0LA0KPiANCj4gSnVhbiBDYXJsb3MNCj4gDQo+ID4gLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiBGcm9tOiBscC13YW4gW21haWx0bzpscC13YW4t Ym91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIHdlaWdlbmd5dQ0KPiA+IFNlbnQ6IE1heSAx MiwgMjAxNyAxMTo0MyBQTQ0KPiA+IFRvOiBscC13YW5AaWV0Zi5vcmcNCj4gPiBTdWJqZWN0OiBS ZTogW2xwLXdhbl0gSS1EIEFjdGlvbjoNCj4gPiBkcmFmdC1pZXRmLWxwd2FuLWlwdjYtc3RhdGlj LWNvbnRleHQtaGMtMDMudHh0DQo+ID4NCj4gPiBIaSBhbGwsDQo+ID4NCj4gPiBUaGVyZSBpcyBh IHF1ZXN0aW9uLCBtYXliZSBhIHNpbGx5IHF1ZXN0aW9uLg0KPiA+DQo+ID4gRG9lcyB0aGUgZW5k LWRldmljZSBpbiBMb3JhLCBTaWdmb3gsIG9yIHRoZSBsaWtlIG5ldHdvcmtzIG5lZWQgdGhlDQo+ ID4gZmFjaWxpdGllcyBvZiBVRFAgcHJvdG9jb2w/DQo+ID4gSXQgaXMgaGVhcmQgdGhhdCBpdCBn ZW5lcmFsbHkgaXMgc2ltcGxlIG9uZSBmdW5jdGlvbiBkZXZpY2UsIHRoZSBwb3J0DQo+ID4gbXVs dGlwbGV4aW5nIGlzIHJlcXVpcmVkIG9yIG5vdD8NCj4gPg0KPiA+IFJlZ2FyZHMsDQo+ID4NCj4g PiBHZW5neXUgV0VJDQo+ID4gTmV0d29yayBUZWNobm9sb2d5IENlbnRlcg0KPiA+IFNjaG9vbCBv ZiBDb21wdXRlcg0KPiA+IEJlaWppbmcgVW5pdmVyc2l0eSBvZiBQb3N0cyBhbmQgVGVsZWNvbW11 bmljYXRpb25zDQo+ID4gLS0tLS3ljp/lp4vpgq7ku7YtLS0tLQ0KPiA+IEZyb206IGludGVybmV0 LWRyYWZ0c0BpZXRmLm9yZw0KPiA+IFNlbnQ6IFNhdHVyZGF5LCBNYXkgMDYsIDIwMTcgMjowMSBB TQ0KPiA+IFRvOiBpLWQtYW5ub3VuY2VAaWV0Zi5vcmcNCj4gPiBDYzogbHAtd2FuQGlldGYub3Jn DQo+ID4gU3ViamVjdDogW2xwLXdhbl0gSS1EIEFjdGlvbjoNCj4gPiBkcmFmdC1pZXRmLWxwd2Fu LWlwdjYtc3RhdGljLWNvbnRleHQtaGMtMDMudHh0DQo+ID4NCj4gPg0KPiA+IEEgTmV3IEludGVy bmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0cw0K PiA+IGRpcmVjdG9yaWVzLg0KPiA+IFRoaXMgZHJhZnQgaXMgYSB3b3JrIGl0ZW0gb2YgdGhlIElQ djYgb3ZlciBMb3cgUG93ZXIgV2lkZS1BcmVhDQo+ID4gTmV0d29ya3Mgb2YgdGhlIElFVEYuDQo+ ID4NCj4gPiAgICAgICAgIFRpdGxlICAgICAgICAgICA6IExQV0FOIFN0YXRpYyBDb250ZXh0IEhl YWRlciBDb21wcmVzc2lvbiAoU0NIQykNCj4gPiBhbmQNCj4gPiBmcmFnbWVudGF0aW9uIGZvciBJ UHY2IGFuZCBVRFANCj4gPiAgICAgICAgIEF1dGhvcnMgICAgICAgICA6IEFuYSBNaW5hYnVybw0K PiA+ICAgICAgICAgICAgICAgICAgICAgICAgICAgTGF1cmVudCBUb3V0YWluDQo+ID4gICAgICAg ICAgICAgICAgICAgICAgICAgICBDYXJsZXMgR29tZXoNCj4gPiBGaWxlbmFtZSAgICAgICAgOiBk cmFmdC1pZXRmLWxwd2FuLWlwdjYtc3RhdGljLWNvbnRleHQtaGMtMDMudHh0DQo+ID4gUGFnZXMg ICAgICAgICAgIDogMzYNCj4gPiBEYXRlICAgICAgICAgICAgOiAyMDE3LTA1LTA1DQo+ID4NCj4g PiBBYnN0cmFjdDoNCj4gPiAgICBUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyBhIGhlYWRlciBjb21w cmVzc2lvbiBzY2hlbWUgYW5kIGZyYWdtZW50YXRpb24NCj4gPiAgICBmdW5jdGlvbmFsaXR5IGZv ciBJUHY2L1VEUCBwcm90b2NvbHMuICBUaGVzZSB0ZWNobmlxdWVzIGFyZQ0KPiA+ICAgIGVzcGVj aWFsbHkgdGFpbG9yZWQgZm9yIExQV0FOIChMb3cgUG93ZXIgV2lkZSBBcmVhIE5ldHdvcmspIG5l dHdvcmtzDQo+ID4gICAgYW5kIGNvdWxkIGJlIGV4dGVuZGVkIHRvIG90aGVyIHByb3RvY29sIHN0 YWNrcy4NCj4gPg0KPiA+ICAgIFRoZSBTdGF0aWMgQ29udGV4dCBIZWFkZXIgQ29tcHJlc3Npb24g KFNDSEMpIG9mZmVycyBhIGdyZWF0IGxldmVsIG9mDQo+ID4gICAgZmxleGliaWxpdHkgd2hlbiBw cm9jZXNzaW5nIHRoZSBoZWFkZXIgZmllbGRzLiAgU3RhdGljIGNvbnRleHQgbWVhbnMNCj4gPiAg ICB0aGF0IGluZm9ybWF0aW9uIHN0b3JlZCBpbiB0aGUgY29udGV4dCB3aGljaCwgZGVzY3JpYmVz IGZpZWxkIHZhbHVlcywNCj4gPiAgICBkb2VzIG5vdCBjaGFuZ2UgZHVyaW5nIHRoZSBwYWNrZXQg dHJhbnNtaXNzaW9uLCBhdm9pZGluZyBjb21wbGV4DQo+ID4gICAgcmVzeW5jaHJvbml6YXRpb24g bWVjaGFuaXNtcywgaW5jb21wYXRpYmxlIHdpdGggTFBXQU4NCj4gPiAgICBjaGFyYWN0ZXJpc3Rp Y3MuICBJbiBtb3N0IG9mIHRoZSBjYXNlcywgSVB2Ni9VRFAgaGVhZGVycyBhcmUgcmVkdWNlZA0K PiA+ICAgIHRvIGEgc21hbGwgaWRlbnRpZmllci4NCj4gPg0KPiA+ICAgIFRoaXMgZG9jdW1lbnQg ZGVzY3JpYmVzIHRoZSBnZW5lcmljIGNvbXByZXNzaW9uL2RlY29tcHJlc3Npb24gcHJvY2Vzcw0K PiA+ICAgIGFuZCBhcHBsaWVzIGl0IHRvIElQdjYvVURQIGhlYWRlcnMuICBTaW1pbGFyIG1lY2hh bmlzbXMgZm9yIG90aGVyDQo+ID4gICAgcHJvdG9jb2xzIHN1Y2ggYXMgQ29BUCB3aWxsIGJlIGRl c2NyaWJlZCBpbiBhIHNlcGFyYXRlIGRvY3VtZW50Lg0KPiA+ICAgIE1vcmVvdmVyLCB0aGlzIGRv Y3VtZW50IHNwZWNpZmllcyBmcmFnbWVudGF0aW9uIGFuZCByZWFzc2VtYmx5DQo+ID4gICAgbWVj aGFuaW1zIGZvciBTQ0hDIGNvbXByZXNzZWQgcGFja2V0cyBleGNlZWRpbmcgdGhlIEwyIHBkdSBz aXplIGFuZA0KPiA+ICAgIGZvciB0aGUgY2FzZSB3aGVyZSB0aGUgU0NIQyBjb21wcmVzc2lvbiBp cyBub3QgcG9zc2libGUgdGhlbiB0aGUNCj4gPiAgICBJUHY2L1VEUCBwYWNrZXQgaXMgc2VudC4N Cj4gPg0KPiA+DQo+ID4gVGhlIElFVEYgZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2UgZm9yIHRoaXMg ZHJhZnQgaXM6DQo+ID4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0 Zi1scHdhbi1pcHY2LXN0YXRpYy1jb250ZXh0LQ0KPiA+IGhjLw0KPiA+DQo+ID4gVGhlcmUgYXJl IGFsc28gaHRtbGl6ZWQgdmVyc2lvbnMgYXZhaWxhYmxlIGF0Og0KPiA+IGh0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWxwd2FuLWlwdjYtc3RhdGljLWNvbnRleHQtaGMtMDMN Cj4gPiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWlldGYtbHB3 YW4taXB2Ni1zdGF0aWMtY29uDQo+ID4gdGV4dC1oYy0NCj4gPiAwMw0KPiA+DQo+ID4gQSBkaWZm IGZyb20gdGhlIHByZXZpb3VzIHZlcnNpb24gaXMgYXZhaWxhYmxlIGF0Og0KPiA+IGh0dHBzOi8v d3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLWxwd2FuLWlwdjYtc3RhdGljLWNv bnRleHQNCj4gPiAtaGMtMDMNCj4gPg0KPiA+DQo+ID4gUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkg dGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2YNCj4gPiBzdWJtaXNzaW9u IHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQNCj4g PiB0b29scy5pZXRmLm9yZy4NCj4gPg0KPiA+IEludGVybmV0LURyYWZ0cyBhcmUgYWxzbyBhdmFp bGFibGUgYnkgYW5vbnltb3VzIEZUUCBhdDoNCj4gPiBmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJu ZXQtZHJhZnRzLw0KPiA+DQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj4gPiBscC13YW4gbWFpbGluZyBsaXN0DQo+ID4gbHAtd2FuQGlldGYub3Jn DQo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9scC13YW4NCj4gPg0K PiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4g bHAtd2FuIG1haWxpbmcgbGlzdA0KPiA+IGxwLXdhbkBpZXRmLm9yZw0KPiA+IGh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbHAtd2FuDQo+IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IGxwLXdhbiBtYWlsaW5nIGxpc3QNCj4gbHAt d2FuQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbHAt d2FuDQoNCg== From nobody Sun May 14 02:30:11 2017 Return-Path: X-Original-To: lp-wan@ietf.org Delivered-To: lp-wan@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A25C4129329; Sun, 14 May 2017 02:30:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: lp-wan@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149475420158.2867.2858210762450072982@ietfa.amsl.com> Date: Sun, 14 May 2017 02:30:01 -0700 Archived-At: Subject: [lp-wan] I-D Action: draft-ietf-lpwan-overview-02.txt X-BeenThere: lp-wan@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Low-Power Wide Area Networking \(LP-WAN\), also known as LPWA or Low-Rate WAN \(LR-WAN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 May 2017 09:30:02 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 over Low Power Wide-Area Networks of the IETF. Title : LPWAN Overview Author : Stephen Farrell Filename : draft-ietf-lpwan-overview-02.txt Pages : 39 Date : 2017-05-14 Abstract: Low Power Wide Area Networks (LPWAN) are wireless technologies with characteristics such as large coverage areas, low bandwidth, possibly very small packet and application layer data sizes and long battery life operation. This memo is an informational overview of the set of LPWAN technologies being considered in the IETF and of the gaps that exist between the needs of those technologies and the goal of running IP in LPWANs. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lpwan-overview/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-lpwan-overview-02 https://datatracker.ietf.org/doc/html/draft-ietf-lpwan-overview-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lpwan-overview-02 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 Sun May 14 02:34:32 2017 Return-Path: X-Original-To: lp-wan@ietfa.amsl.com Delivered-To: lp-wan@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F10B1292CE for ; Sun, 14 May 2017 02:34:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 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_MED=-2.3, RP_MATCHES_RCVD=-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=cs.tcd.ie 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 5vhNKf3KRz1o for ; Sun, 14 May 2017 02:34:28 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1032B1286D6 for ; Sun, 14 May 2017 02:33:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 9DAC9BE3E for ; Sun, 14 May 2017 10:33:01 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SZUWBujD4LuL for ; Sun, 14 May 2017 10:33:00 +0100 (IST) Received: from [10.244.2.100] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id A9D07BDD0 for ; Sun, 14 May 2017 10:32:59 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1494754380; bh=eOPeDWg+EZN3swcqAAYrXSYCzZQfP9Ir0rdJS0N7IPQ=; h=Subject:References:To:From:Date:In-Reply-To:From; b=NHGGXXKIj+fifN81wY/WXzXZhRcl0SrQofpqMd06jE2epumsWJlLDb7yq0/SL1l60 /4d3Nxo0BDViBhbU71VViRpMmMk5U3B3nHe4fkVW+Fb8FKr4Y5mxstdRowCpvr6Byj YRYUgdzkXWmb+FGVLDLMfup9MXMh6+cWHNNj2Jgk= References: <149475420158.2867.2858210762450072982@ietfa.amsl.com> To: lp-wan@ietf.org From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <4921d239-dbab-9ea1-3dbd-66e044bf22ec@cs.tcd.ie> Date: Sun, 14 May 2017 10:32:58 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <149475420158.2867.2858210762450072982@ietfa.amsl.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="6bSGg98itPw0EOvx8GJaMRaOTbOLfmUtd" Archived-At: Subject: Re: [lp-wan] I-D Action: draft-ietf-lpwan-overview-02.txt X-BeenThere: lp-wan@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Low-Power Wide Area Networking \(LP-WAN\), also known as LPWA or Low-Rate WAN \(LR-WAN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 May 2017 09:34:31 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --6bSGg98itPw0EOvx8GJaMRaOTbOLfmUtd Content-Type: multipart/mixed; boundary="sNQv3TRkfEdFubA5CBCILQhETEf1Dvo8j"; protected-headers="v1" From: Stephen Farrell To: lp-wan@ietf.org Message-ID: <4921d239-dbab-9ea1-3dbd-66e044bf22ec@cs.tcd.ie> Subject: Re: [lp-wan] I-D Action: draft-ietf-lpwan-overview-02.txt References: <149475420158.2867.2858210762450072982@ietfa.amsl.com> In-Reply-To: <149475420158.2867.2858210762450072982@ietfa.amsl.com> --sNQv3TRkfEdFubA5CBCILQhETEf1Dvo8j Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi all, I've updated the overview document as planned (well, a week or two later than planned:-). I still have two open issues that I'd like to resolve before I'd claim that this is ready for WGLC so I'll send separate mails on those. Other than that, it might be pretty close to ready, though your comments are welcome of course. (Either on the list or as a PR to the git repo.) Cheers, S. On 14/05/17 10:30, internet-drafts@ietf.org wrote: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts dire= ctories. > This draft is a work item of the IPv6 over Low Power Wide-Area Networks= of the IETF. >=20 > Title : LPWAN Overview > Author : Stephen Farrell > Filename : draft-ietf-lpwan-overview-02.txt > Pages : 39 > Date : 2017-05-14 >=20 > Abstract: > Low Power Wide Area Networks (LPWAN) are wireless technologies with > characteristics such as large coverage areas, low bandwidth, possibl= y > very small packet and application layer data sizes and long battery > life operation. This memo is an informational overview of the set o= f > LPWAN technologies being considered in the IETF and of the gaps that= > exist between the needs of those technologies and the goal of runnin= g > IP in LPWANs. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-lpwan-overview/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-lpwan-overview-02 > https://datatracker.ietf.org/doc/html/draft-ietf-lpwan-overview-02 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-lpwan-overview-02 >=20 >=20 > Please note that it may take a couple of minutes from the time of submi= ssion > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > lp-wan mailing list > lp-wan@ietf.org > https://www.ietf.org/mailman/listinfo/lp-wan >=20 --sNQv3TRkfEdFubA5CBCILQhETEf1Dvo8j-- --6bSGg98itPw0EOvx8GJaMRaOTbOLfmUtd Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZGCRKAAoJEC88hzaAX42iCYcH/A/f4+nY/Mo+Rf4jlmD37g5p wHCgrbWdaphEqrhiiio++MB+/pyZiUmKrIVniaKUMKrjNIoeALCXGD5ca7LXszdb w7AUGb0GyIFvYxG9drhOqN69BwEqac2ghX8bA6Z+ucJaK7/2BRBysPbIY0ZrxJfW j6/5Y1gSP/qgRsgntsoWOnjq1O/+atYdVfhP2DVLTB1QlvVWr7EXjZyruMZqtQ1T 8Ay3volpH8UaKXGCibI76VIQ3bKgSA9GJX9vPqio7ptrLXQvJZTbbzLcqf3jrLa6 /8t/8W9Yb9hHgw8swWp8XRtGWDjMpeAzDBY9VfGyoljVUf0MJsfYwJQtl8prRi4= =r/2L -----END PGP SIGNATURE----- --6bSGg98itPw0EOvx8GJaMRaOTbOLfmUtd-- From nobody Sun May 14 02:39:00 2017 Return-Path: X-Original-To: lp-wan@ietfa.amsl.com Delivered-To: lp-wan@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A211126D74 for ; Sun, 14 May 2017 02:38:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.402 X-Spam-Level: X-Spam-Status: No, score=-2.402 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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=cs.tcd.ie 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 E0eX1Pp0S6EP for ; Sun, 14 May 2017 02:38:57 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9A621296B3 for ; Sun, 14 May 2017 02:37:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 5D9BEBE3E for ; Sun, 14 May 2017 10:37:09 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C6jVCd4Sj6tR for ; Sun, 14 May 2017 10:37:08 +0100 (IST) Received: from [10.244.2.100] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id AE5EBBDD0 for ; Sun, 14 May 2017 10:37:07 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1494754628; bh=/Jkng3SKfEyAm5QWbwgiBxmzvE5c9iw2LF87x6+/I/w=; h=To:From:Subject:Date:From; b=yPc9YgZaDR0sxRQ+vacHYqojRPbQswc46E0zFeLe53WNLKF2V5rRiewSN7t0f2qrm 6YP/+MBHqtFdo5qqG7s9jOVkZzjBE7JHWSC6IhcaLTQg/itqaF64fhF9Wts2rkNA48 YJyd9tYe4RkL6YXYOgSKigaREc8uV3NFOM/EPDjE= To: lp-wan From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: Date: Sun, 14 May 2017 10:37:07 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="PW2INLEwMmTXmmDBh6RwJC2dxaEuqTSqc" Archived-At: Subject: [lp-wan] overview issue#1: worst case MTU... X-BeenThere: lp-wan@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Low-Power Wide Area Networking \(LP-WAN\), also known as LPWA or Low-Rate WAN \(LR-WAN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 May 2017 09:39:00 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --PW2INLEwMmTXmmDBh6RwJC2dxaEuqTSqc Content-Type: multipart/mixed; boundary="8iOE0gVfQh3b7rQtfi1jECK9e9lO8BUgR"; protected-headers="v1" From: Stephen Farrell To: lp-wan Message-ID: Subject: overview issue#1: worst case MTU... --8iOE0gVfQh3b7rQtfi1jECK9e9lO8BUgR Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, In [1], I note that I don't know what's the worst case MTU that might apply in NB-IoT. Does anyone know? To be clear, I'm asking what MTU would apply in the worst-case network conditions where some LPWAN traffic can get through. (Though there's probably a better way to ask the question:-) Do the WG think that it'd be useful to have that for each of the technologies covered? (I think it would, fwiw.) Cheers, S. [1] https://tools.ietf.org/html/draft-ietf-lpwan-overview-02#section-2.2.= 2 --8iOE0gVfQh3b7rQtfi1jECK9e9lO8BUgR-- --PW2INLEwMmTXmmDBh6RwJC2dxaEuqTSqc Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZGCVDAAoJEC88hzaAX42i094H/iIiou0RzXxC3DyOqSA3nwaP Uv6bUujxqiTDjwRa2FHvQK8eW/Gc/BlXmJgDTZoV3b3Ec7BvE6t35oQGHQCUHd/T tPHVkL7R2FvNWiLnQBD/A52GEyCcqFS57oRkcdInHa+UvtnnPbbldFB3Q7bQyLyk blQ0w0zMzl0oDV87ZW79SO4zTC6a+JK8v87eFs/Ow0RMPvzNhjw/oD1ImHZD2bgG Hr2WKdGMGEAYeGCG4oLApBpUBwPaaoi5YXDwr9Zw/ok/PoH/fxYjAaH1Oh+doEQc Rj3e1UONSU3SWg8MJKT/r47T82/QdfzVP6e9SXfiSlPO8OCLzfmLxasfBzP24fQ= =S368 -----END PGP SIGNATURE----- --PW2INLEwMmTXmmDBh6RwJC2dxaEuqTSqc-- From nobody Sun May 14 02:45:10 2017 Return-Path: X-Original-To: lp-wan@ietfa.amsl.com Delivered-To: lp-wan@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA4741294D4 for ; Sun, 14 May 2017 02:45:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.402 X-Spam-Level: X-Spam-Status: No, score=-2.402 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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=cs.tcd.ie 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 DhhFkcmPqz49 for ; Sun, 14 May 2017 02:45:06 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E03CC12949B for ; Sun, 14 May 2017 02:43:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 7BE14BE3E for ; Sun, 14 May 2017 10:43:13 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h-WkcUrkvmKn for ; Sun, 14 May 2017 10:43:12 +0100 (IST) Received: from [10.244.2.100] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id A2725BDD8 for ; Sun, 14 May 2017 10:43:11 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1494754992; bh=4gUm7jfcrXgTjbtYRREUOfI/BOP0V53q8G6LVPpUe5A=; h=To:From:Subject:Date:From; b=PYVdze1Kqof/73zx62Crc0cunoXhfO07AC+PKVPMJyWaZAhnp6mSydDMGcC0YgJYV 8LGCt6Zm90JNxesBa+uyXPPRaGAB85YFSymDWHiw5KB5FjU8pbyuGqIjPI9aCf2Fxe U/6Kym8uvq+ww5Ppdtg33cnHt1DNipCdKHC60nzk= To: lp-wan From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: Date: Sun, 14 May 2017 10:43:11 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="33jCGV7NG0riRE8TNwGSjnnEEn08X79DP" Archived-At: Subject: [lp-wan] overview issue#1: AAA server term... X-BeenThere: lp-wan@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Low-Power Wide Area Networking \(LP-WAN\), also known as LPWA or Low-Rate WAN \(LR-WAN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 May 2017 09:45:09 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --33jCGV7NG0riRE8TNwGSjnnEEn08X79DP Content-Type: multipart/mixed; boundary="tL731OM59UCVPxBHAhmmI02UwcEDlPPwQ"; protected-headers="v1" From: Stephen Farrell To: lp-wan Message-ID: Subject: overview issue#1: AAA server term... --tL731OM59UCVPxBHAhmmI02UwcEDlPPwQ Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, In [1] we define the term "AAA server." I don't think that's a good term to use, as it may be read to assume that we'll end up with a RADIUS or Diameter based solution and a typical AAA server like that is just not the same as a LoRaWAN NS/JS. (There might be a RADIUS or Diameter server behind such a beast, but it's not the same thing.) I think (less sure though) that the "AAA server" is also not so good for the other technologies too. What'd the WG like to do here? Cheers, S. [1] https://tools.ietf.org/html/draft-ietf-lpwan-overview-02#section-3 --tL731OM59UCVPxBHAhmmI02UwcEDlPPwQ-- --33jCGV7NG0riRE8TNwGSjnnEEn08X79DP Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZGCavAAoJEC88hzaAX42i9TwIAJ0Rtv74lWZizV4xr64W/B7k nxl74Hr8XzC3WOo6aHkVP4hoW3H0fYSMUlUsies9yAv1dDXhRE2tYpGc+/AXOCxd PB+4s4S7XV8M5klzvdDJvxr1XPCgTKTKxd7MJYVYNAdBNGQ+LUd0Zy1mWw5aHK+B Cp/b1euIXA7jEKEVpZmXaMjQAF/eII/YxVC1nIxRhdAKpKsd9BohYcjeboTo/WC2 VxROE2d0NguOrI+TarnLUZFp9fTguqipE889hw9Nty21F8DwRRAB4QGD0xeM/Irt AU8XYDstrgSOfnwsB2iQDAJEpJBHnoRJg+lQ+DxT7UmbQwBV2S2ZoPKubBdZLZs= =18up -----END PGP SIGNATURE----- --33jCGV7NG0riRE8TNwGSjnnEEn08X79DP-- From nobody Mon May 15 00:12:00 2017 Return-Path: X-Original-To: lp-wan@ietfa.amsl.com Delivered-To: lp-wan@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1084B129AE8 for ; Mon, 15 May 2017 00:11:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.5 X-Spam-Level: X-Spam-Status: No, score=-1.5 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3] 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 a6v5V154f7xu for ; Mon, 15 May 2017 00:11:57 -0700 (PDT) Received: from violet.upc.es (violet.upc.es [147.83.2.51]) (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 E585E129423 for ; Mon, 15 May 2017 00:07:44 -0700 (PDT) Received: from entelserver.upc.edu (entelserver.upc.es [147.83.39.4]) by violet.upc.es (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id v4F77eOo020541; Mon, 15 May 2017 09:07:40 +0200 Received: from webmail.entel.upc.edu (webmail.entel.upc.edu [147.83.39.6]) by entelserver.upc.edu (Postfix) with ESMTP id 5A5B71D53C1; Mon, 15 May 2017 09:07:39 +0200 (CEST) Received: from 83.53.20.192 by webmail.entel.upc.edu with HTTP; Mon, 15 May 2017 09:07:33 +0200 Message-ID: <581ff36a40953beacb6af19a50190928.squirrel@webmail.entel.upc.edu> In-Reply-To: References: Date: Mon, 15 May 2017 09:07:33 +0200 From: "Carles Gomez Montenegro" To: "Stephen Farrell" Cc: "lp-wan" User-Agent: SquirrelMail/1.4.21-1.fc14 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: clamav-milter 0.99.2 at violet X-Virus-Status: Clean X-Greylist: Delayed for 00:28:15 by milter-greylist-4.3.9 (violet.upc.es [147.83.2.51]); Mon, 15 May 2017 09:07:40 +0200 (CEST) Archived-At: Subject: Re: [lp-wan] overview issue#1: worst case MTU... X-BeenThere: lp-wan@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Low-Power Wide Area Networking \(LP-WAN\), also known as LPWA or Low-Rate WAN \(LR-WAN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 May 2017 07:11:59 -0000 Hi Stephen, > Do the WG think that it'd be useful to have that for each > of the technologies covered? (I think it would, fwiw.) It is really useful (and actually required for IPv6 over LPWAN) to have such information for each covered technology. I think such information is already included in the document for LoRaWAN and SIGFOX. So whether 1600 bytes is the worst-case MTU in NB-IoT should be confirmed, and the worst-case MTU for Wi-SUN should also (ideally) be explicitly stated. It would also be very useful to have information on uplink and downlink message rate (i.e. message per time unit) constraints beyond those naturally due to the physical layer bit rate, for all technologies covered. Cheers, Carles From nobody Mon May 15 02:17:16 2017 Return-Path: X-Original-To: lp-wan@ietfa.amsl.com Delivered-To: lp-wan@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE13C129AEE for ; Mon, 15 May 2017 02:17:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.5 X-Spam-Level: X-Spam-Status: No, score=-3.5 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 j_aYlOdKzkSF for ; Mon, 15 May 2017 02:17:13 -0700 (PDT) Received: from relais-inet.orange.com (mta241.mail.business.static.orange.com [80.12.66.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D317129C25 for ; Mon, 15 May 2017 02:13:19 -0700 (PDT) Received: from opfedar04.francetelecom.fr (unknown [xx.xx.xx.6]) by opfedar24.francetelecom.fr (ESMTP service) with ESMTP id B24CFC14AC for ; Mon, 15 May 2017 11:13:17 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.69]) by opfedar04.francetelecom.fr (ESMTP service) with ESMTP id 935DB40073 for ; Mon, 15 May 2017 11:13:17 +0200 (CEST) Received: from OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06]) by OPEXCLILMA2.corporate.adroot.infra.ftgroup ([fe80::bc1c:ad2f:eda3:8c3d%18]) with mapi id 14.03.0339.000; Mon, 15 May 2017 11:13:17 +0200 From: To: "lp-wan@ietf.org" Thread-Topic: Question on LoRaWAN and SCHC decompression architecture (Figure 1) Thread-Index: AdLNT6lpBSXcjkPyS9eRNGz+Etc8Aw== Date: Mon, 15 May 2017 09:13:16 +0000 Message-ID: <21798_1494839597_5919712D_21798_82_1_BC397CDFFDB82545B5E3571A77AB72043CC24ED4@OPEXCLILM21.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: multipart/alternative; boundary="_000_BC397CDFFDB82545B5E3571A77AB72043CC24ED4OPEXCLILM21corp_" MIME-Version: 1.0 Archived-At: Subject: [lp-wan] Question on LoRaWAN and SCHC decompression architecture (Figure 1) X-BeenThere: lp-wan@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Low-Power Wide Area Networking \(LP-WAN\), also known as LPWA or Low-Rate WAN \(LR-WAN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 May 2017 09:17:15 -0000 --_000_BC397CDFFDB82545B5E3571A77AB72043CC24ED4OPEXCLILM21corp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, The LoRaWAN protocol is designed to encrypt LoRaWAN MAC payload between the= Device and the Application Server (End to End confidentiality). And the NGW and the Application Server are connected through HTTPS link . How do you see for LoRaWAN a SCHC Decompression function running in between= of NGW and Application Server ? It should not be possible, except to host this function in the Application = Server. Thanks Philippe ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_BC397CDFFDB82545B5E3571A77AB72043CC24ED4OPEXCLILM21corp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,=

 

The LoRaWAN pr= otocol is designed to encrypt LoRaWAN MAC payload between the Device and th= e Application Server (End to End confidentiality).

And the NGW an= d the Application Server are connected through HTTPS link .

 

How do you see= for LoRaWAN a SCHC Decompression function running in between of NGW and Ap= plication Server ?

It should not = be possible, except to host this function in the Application Server.

 

Thanks

 

Philippe<= /o:p>

 

______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_BC397CDFFDB82545B5E3571A77AB72043CC24ED4OPEXCLILM21corp_-- From nobody Mon May 15 05:23:18 2017 Return-Path: X-Original-To: lp-wan@ietfa.amsl.com Delivered-To: lp-wan@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74FA412E3AE for ; Mon, 15 May 2017 05:23:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MuAUnDz7Yq8K for ; Mon, 15 May 2017 05:23:15 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (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 D17F2128BB6 for ; Mon, 15 May 2017 05:19:05 -0700 (PDT) X-AuditID: c1b4fb25-466159a000006049-66-59199cb7e043 Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.183.84]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id B4.4E.24649.7BC99195; Mon, 15 May 2017 14:19:04 +0200 (CEST) Received: from ESESSMB101.ericsson.se ([169.254.1.161]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.03.0339.000; Mon, 15 May 2017 14:19:01 +0200 From: Antti Ratilainen To: Carles Gomez Montenegro , Stephen Farrell CC: lp-wan Thread-Topic: [lp-wan] overview issue#1: worst case MTU... Thread-Index: AQHSzJXsNZDi7hpjxEm1UIPnYJm+sqH02SWAgAB3wwA= Date: Mon, 15 May 2017 12:19:00 +0000 Message-ID: References: <581ff36a40953beacb6af19a50190928.squirrel@webmail.entel.upc.edu> In-Reply-To: <581ff36a40953beacb6af19a50190928.squirrel@webmail.entel.upc.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.147] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpmkeLIzCtJLcpLzFFi42KZGbE9RHfHHMlIg92bmCwObvvOavFmlr3F 9L3X2B2YPdZ2X2XzuH/wAbPHkiU/mQKYo7hsUlJzMstSi/TtErgyPp59xliwi7fi7dGnrA2M P7i6GDk5JARMJK48nsLYxcjFISRwhFHi4K4P7BDOEkaJz1MusnQxcnCwCZhJPHin1cXIziEi kCzx3A2klVlARuJg4xR2EFtYwFLiy60vYLaIgJXExpnbWGHsy9ffMYLYLAKqEp/PL2YCsXkF fCVm/b3EArGpgVHi8sIdYAlOAT+JzU8WgTUwCohJfD+1hglimbjErSfzmSBuFpBYsuc8M4Qt KvHy8T9WkCslBJQkpm1NgyjXkViw+xMbhK0tsWzha2aIvYISJ2c+YZnAKDoLydRZSFpmIWmZ haRlASPLKkbR4tTipNx0I2O91KLM5OLi/Dy9vNSSTYzAqDm45bfqDsbLbxwPMQpwMCrx8LJP k4wUYk0sK67MPcQowcGsJMK7qQcoxJuSWFmVWpQfX1Sak1p8iFGag0VJnNdx34UIIYH0xJLU 7NTUgtQimCwTB6dUA2O21Z8NDXeu1z1Yl/6tNPHDR0U2/Y9C/VlSsYe6dt7uPjvt2eNXJ50v ezDv+PHK1K1g0aY71xO7ngrmSuUnnjysfn5CRY2N/+NVv+x7niy+G73kWu2F/av2mHpZMSkV l6i+y45p3ce57O3WfIF43shs7fcRCQ87dN4UR04KLd0XrfNyk1+P9xclluKMREMt5qLiRABC svUClgIAAA== Archived-At: Subject: Re: [lp-wan] overview issue#1: worst case MTU... X-BeenThere: lp-wan@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Low-Power Wide Area Networking \(LP-WAN\), also known as LPWA or Low-Rate WAN \(LR-WAN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 May 2017 12:23:17 -0000 Dear all, I'm not quite sure what is meant by worst case MTU. But in the case of NB-I= oT, any size packet up to the said MTU size (1600 bytes) can be passed to N= B-IoT from higher layers, segmentation of the packet is performed in the RL= C layer, which can segment the data to transmission blocks with size as sma= ll as 16 bits. Hope this clarifies this issue for NB-IoT. I have also informed Stephen with this answer along with some other updates= regarding NB-IoT section of the overview document. Best regards, Antti -----Original Message----- From: lp-wan [mailto:lp-wan-bounces@ietf.org] On Behalf Of Carles Gomez Mon= tenegro Sent: 15. toukokuuta 2017 10:08 To: Stephen Farrell Cc: lp-wan Subject: Re: [lp-wan] overview issue#1: worst case MTU... Hi Stephen, > Do the WG think that it'd be useful to have that for each of the=20 > technologies covered? (I think it would, fwiw.) It is really useful (and actually required for IPv6 over LPWAN) to have suc= h information for each covered technology. I think such information is already included in the document for LoRaWAN an= d SIGFOX. So whether 1600 bytes is the worst-case MTU in NB-IoT should be c= onfirmed, and the worst-case MTU for Wi-SUN should also (ideally) be explic= itly stated. It would also be very useful to have information on uplink and downlink mes= sage rate (i.e. message per time unit) constraints beyond those naturally d= ue to the physical layer bit rate, for all technologies covered. Cheers, Carles _______________________________________________ lp-wan mailing list lp-wan@ietf.org https://www.ietf.org/mailman/listinfo/lp-wan From nobody Mon May 15 05:26:40 2017 Return-Path: X-Original-To: lp-wan@ietfa.amsl.com Delivered-To: lp-wan@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE3DE12947E for ; Mon, 15 May 2017 05:26:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 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_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 ZcjibXInJd1h for ; Mon, 15 May 2017 05:26:36 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 405FB126BF3 for ; Mon, 15 May 2017 05:22:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id D381DBDD8; Mon, 15 May 2017 13:22:24 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EHhFBBQUiFXz; Mon, 15 May 2017 13:22:24 +0100 (IST) Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 2F5E6BDD0; Mon, 15 May 2017 13:22:24 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1494850944; bh=W1sf8rI4VQ3Km2N2wPwwTAbgTo4CmszMIfmGA5rUaAc=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=W88dnzGXsa2eisg14+xoWbpWILy4WkaaJzijhIjR+VIYA5PaiNOwTD2SjdcqtK3pR fujq+VSngcOS2xa0M8R6y6C6gnVA3Tn/3MH/u37d/cyJRRgsycMD7kaUo3b/bttv6q BfsUxdrCQGBRhqcr8o9g68uYt6z8hxwFcGEEUzL4= To: Antti Ratilainen , Carles Gomez Montenegro References: <581ff36a40953beacb6af19a50190928.squirrel@webmail.entel.upc.edu> Cc: lp-wan From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <374fe358-365d-87d4-4779-b2ba0483a70e@cs.tcd.ie> Date: Mon, 15 May 2017 13:22:23 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Foc69mPmJHMiaJweRSiFGSHawJCUntt82" Archived-At: Subject: Re: [lp-wan] overview issue#1: worst case MTU... X-BeenThere: lp-wan@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Low-Power Wide Area Networking \(LP-WAN\), also known as LPWA or Low-Rate WAN \(LR-WAN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 May 2017 12:26:39 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Foc69mPmJHMiaJweRSiFGSHawJCUntt82 Content-Type: multipart/mixed; boundary="le67P6iPbqTNsvckSUOBEujSik6B8NgS9"; protected-headers="v1" From: Stephen Farrell To: Antti Ratilainen , Carles Gomez Montenegro Cc: lp-wan Message-ID: <374fe358-365d-87d4-4779-b2ba0483a70e@cs.tcd.ie> Subject: Re: [lp-wan] overview issue#1: worst case MTU... References: <581ff36a40953beacb6af19a50190928.squirrel@webmail.entel.upc.edu> In-Reply-To: --le67P6iPbqTNsvckSUOBEujSik6B8NgS9 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 15/05/17 13:19, Antti Ratilainen wrote: > Dear all, >=20 > I'm not quite sure what is meant by worst case MTU. But in the case > of NB-IoT, any size packet up to the said MTU size (1600 bytes) can > be passed to NB-IoT from higher layers, segmentation of the packet is > performed in the RLC layer, which can segment the data to > transmission blocks with size as small as 16 bits. Hope this > clarifies this issue for NB-IoT. Ah, ok, so 1600 is always ok for an IP layer on top of NB-IoT then, even if it'd not perform as well maybe in lossy conditions - is that right? >=20 > I have also informed Stephen with this answer along with some other > updates regarding NB-IoT section of the overview document. Please do check that I've gotten those into the latest version. If not, (first: sorry:-) and just send me a pointer to the mail and I'll shoot out a -03 if stuff still needs fixing Cheers, S. >=20 > Best regards, Antti >=20 > -----Original Message----- From: lp-wan > [mailto:lp-wan-bounces@ietf.org] On Behalf Of Carles Gomez > Montenegro Sent: 15. toukokuuta 2017 10:08 To: Stephen Farrell > Cc: lp-wan Subject: Re: > [lp-wan] overview issue#1: worst case MTU... >=20 > Hi Stephen, >=20 >> Do the WG think that it'd be useful to have that for each of the=20 >> technologies covered? (I think it would, fwiw.) >=20 > It is really useful (and actually required for IPv6 over LPWAN) to > have such information for each covered technology. >=20 > I think such information is already included in the document for > LoRaWAN and SIGFOX. So whether 1600 bytes is the worst-case MTU in > NB-IoT should be confirmed, and the worst-case MTU for Wi-SUN should > also (ideally) be explicitly stated. >=20 > It would also be very useful to have information on uplink and > downlink message rate (i.e. message per time unit) constraints beyond > those naturally due to the physical layer bit rate, for all > technologies covered. >=20 > Cheers, >=20 > Carles >=20 > _______________________________________________ lp-wan mailing list=20 > lp-wan@ietf.org https://www.ietf.org/mailman/listinfo/lp-wan >=20 --le67P6iPbqTNsvckSUOBEujSik6B8NgS9-- --Foc69mPmJHMiaJweRSiFGSHawJCUntt82 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZGZ1/AAoJEC88hzaAX42ixVkH/jE6GA//RregTmBHgKc8nYTL YrczGjacCK6Yg0tybXhMB+9j88vWEfpvAGO0N2ci60L4yGrOYLZT8RJYCbk+gCJy tPf7ivsKQdr66ttJursrfFbVhs+RMC4f4T2cKe17LGy7j7j6kw6v0F37HveAbuYn MV1yLyfiu6qsfaCWgkbP4qcis2+Mors4CuqHLlGqNw9x8B/0ljY98XBpXAct3IhW A1P8c4mkd4K20f0xQQHrTd6MD4/vj+0XhKa/xgO1VyL7nn7H9+4235soyn/d2/os x3fVB0/xOlfwZyjjkmHDAGVC5oR8E1Hh4zuxVx4vlvl5FeP9vJql0FwyKzMjYL8= =aEOX -----END PGP SIGNATURE----- --Foc69mPmJHMiaJweRSiFGSHawJCUntt82-- From nobody Mon May 15 05:47:39 2017 Return-Path: X-Original-To: lp-wan@ietfa.amsl.com Delivered-To: lp-wan@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A90F126C0F for ; Mon, 15 May 2017 05:47:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nd9JL-h3FToZ for ; Mon, 15 May 2017 05:47:35 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 3ED0C126BF0 for ; Mon, 15 May 2017 05:43:50 -0700 (PDT) X-AuditID: c1b4fb2d-b25ff7000000196b-35-5919a283634f Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.183.60]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id DF.D0.06507.382A9195; Mon, 15 May 2017 14:43:48 +0200 (CEST) Received: from ESESSMB101.ericsson.se ([169.254.1.161]) by ESESSHC014.ericsson.se ([153.88.183.60]) with mapi id 14.03.0339.000; Mon, 15 May 2017 14:43:47 +0200 From: Antti Ratilainen To: Stephen Farrell , Carles Gomez Montenegro CC: lp-wan Thread-Topic: [lp-wan] overview issue#1: worst case MTU... Thread-Index: AQHSzJXsNZDi7hpjxEm1UIPnYJm+sqH02SWAgAB3wwD//+A0gIAAJJuw Date: Mon, 15 May 2017 12:43:46 +0000 Message-ID: References: <581ff36a40953beacb6af19a50190928.squirrel@webmail.entel.upc.edu> <374fe358-365d-87d4-4779-b2ba0483a70e@cs.tcd.ie> In-Reply-To: <374fe358-365d-87d4-4779-b2ba0483a70e@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.147] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpikeLIzCtJLcpLzFFi42KZGbHdRrdlkWSkwbdXChYHt31ntXgzy95i +t5r7A7MHmu7r7J53D/4gNljyZKfTAHMUVw2Kak5mWWpRfp2CVwZax7fYi64olhx9XEjewPj E4UuRk4OCQETiXtzVjN3MXJxCAkcYZTo6rjNDpIQEljCKDF1mV8XIwcHm4CZxIN3WiBhEYFk iWX//rKB2MwCMhIHG6eAlQsLWEp8ufWFHaLGSmLjzG2sELabxKvPF8DiLAKqEttuHQHr5RXw lZh28QkbxN7vjBIHJ60Ha+AUsJW4uWM5I4jNKCAm8f3UGiaIZeISt57MZ4I4WkBiyZ7zzBC2 qMTLx/9YQe6UEFCSmLY1DcRkFtCUWL9LH6JTUWJK90N2iLWCEidnPmGZwCg6C8nQWQgds5B0 zELSsYCRZRWjaHFqcXFuupGxXmpRZnJxcX6eXl5qySZGYMwc3PJbdwfj6teOhxgFOBiVeHhZ p0lGCrEmlhVX5h5ilOBgVhLh3dQDFOJNSaysSi3Kjy8qzUktPsQozcGiJM7rsO9ChJBAemJJ anZqakFqEUyWiYNTqoFx1qcFLBXsnjsO6p6pnmijk2fx9P3P6L3ahmsPPXjqKKl6Py83W7Bu j9exyPXtEerpPx8cjyi/NJ3hYcryk+8bUs8JnpKTPXPqXePzdY8erczh8n/DUHl6o3rUnNLk tf+KSxbn3pTPfLmF2a7oEquNyZVZrmzvN5+actXRqu1JnH1VNjP/nbO5SizFGYmGWsxFxYkA +WigS5UCAAA= Archived-At: Subject: Re: [lp-wan] overview issue#1: worst case MTU... X-BeenThere: lp-wan@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Low-Power Wide Area Networking \(LP-WAN\), also known as LPWA or Low-Rate WAN \(LR-WAN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 May 2017 12:47:37 -0000 DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogU3RlcGhlbiBGYXJyZWxsIFttYWls dG86c3RlcGhlbi5mYXJyZWxsQGNzLnRjZC5pZV0gDQpTZW50OiAxNS4gdG91a29rdXV0YSAyMDE3 IDE1OjIyDQpUbzogQW50dGkgUmF0aWxhaW5lbiA8YW50dGkucmF0aWxhaW5lbkBlcmljc3Nvbi5j b20+OyBDYXJsZXMgR29tZXogTW9udGVuZWdybyA8Y2FybGVzZ29AZW50ZWwudXBjLmVkdT4NCkNj OiBscC13YW4gPGxwLXdhbkBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbbHAtd2FuXSBvdmVydmll dyBpc3N1ZSMxOiB3b3JzdCBjYXNlIE1UVS4uLg0KDQoNCg0KT24gMTUvMDUvMTcgMTM6MTksIEFu dHRpIFJhdGlsYWluZW4gd3JvdGU6DQo+IERlYXIgYWxsLA0KPiANCj4gSSdtIG5vdCBxdWl0ZSBz dXJlIHdoYXQgaXMgbWVhbnQgYnkgd29yc3QgY2FzZSBNVFUuIEJ1dCBpbiB0aGUgY2FzZSBvZiAN Cj4gTkItSW9ULCBhbnkgc2l6ZSBwYWNrZXQgdXAgdG8gdGhlIHNhaWQgTVRVIHNpemUgKDE2MDAg Ynl0ZXMpIGNhbiBiZSANCj4gcGFzc2VkIHRvIE5CLUlvVCBmcm9tIGhpZ2hlciBsYXllcnMsIHNl Z21lbnRhdGlvbiBvZiB0aGUgcGFja2V0IGlzIA0KPiBwZXJmb3JtZWQgaW4gdGhlIFJMQyBsYXll ciwgd2hpY2ggY2FuIHNlZ21lbnQgdGhlIGRhdGEgdG8gdHJhbnNtaXNzaW9uIA0KPiBibG9ja3Mg d2l0aCBzaXplIGFzIHNtYWxsIGFzIDE2IGJpdHMuIEhvcGUgdGhpcyBjbGFyaWZpZXMgdGhpcyBp c3N1ZSANCj4gZm9yIE5CLUlvVC4NCg0KQWgsIG9rLCBzbyAxNjAwIGlzIGFsd2F5cyBvayBmb3Ig YW4gSVAgbGF5ZXIgb24gdG9wIG9mIE5CLUlvVCB0aGVuLCBldmVuIGlmIGl0J2Qgbm90IHBlcmZv cm0gYXMgd2VsbCBtYXliZSBpbiBsb3NzeSBjb25kaXRpb25zIC0gaXMgdGhhdCByaWdodD8NCg0K W0FudHRpXSBUbyBjbGFyaWZ5LCB0aGUgMTYwMCBCIE1UVSBpcyBiYXNlZCBvbiAxNTAwIEIgSVAg bGF5ZXIgcGFja2V0ICsgc29tZSBvdmVyaGVhZC4gVGhlIHBhY2tldCBwcm92aWRlZCBmcm9tIGhp Z2hlciBsYXllciBkb2VzIG5vdCBoYXZlIHRvIGJlIHRoYXQgbGFyZ2UsIGl0IGNhbiBiZSBzbWFs bGVyIGFzIHdlbGwuDQpBbmQgeWVzLCBSTEMgbGF5ZXIgbWF5IHRha2UgdGhlIHJhZGlvIGNvbmRp dGlvbnMgb2YgdGhlIGNoYW5uZWwgaW50byBhY2NvdW50IHdoZW4gcGVyZm9ybWluZyB0aGUgc2Vn bWVudGF0aW9uIG9mIHRoZSBJUCBsYXllciBwYWNrZXQsIHVzaW5nIGxvd2VyIHNpemUgdHJhbnNt aXNzaW9uIGJsb2NrcyBhbmQgYmV0dGVyIE1DUyB0byBjb3VudGVyIHRoZSBiYWQgcmFkaW8gY29u bmVjdGlvbi4gT2YgY291cnNlIHdpdGggMTYwMCBCICBwYWNrZXQgc2VnbWVudGVkIGludG8gc3Vj aCBzbWFsbCB0cmFuc21pc3Npb24gYmxvY2tzIGluIGJhZCByYWRpbyBjb25kaXRpb25zLCBpdCB3 aWxsIHRha2UgcmVsYXRpdmVseSBsb25nIHRpbWUgdG8gdHJhbnNtaXQgdGhlIHdob2xlIHBhY2tl dC4NCg0KPiANCj4gSSBoYXZlIGFsc28gaW5mb3JtZWQgU3RlcGhlbiB3aXRoIHRoaXMgYW5zd2Vy IGFsb25nIHdpdGggc29tZSBvdGhlciANCj4gdXBkYXRlcyByZWdhcmRpbmcgTkItSW9UIHNlY3Rp b24gb2YgdGhlIG92ZXJ2aWV3IGRvY3VtZW50Lg0KDQpQbGVhc2UgZG8gY2hlY2sgdGhhdCBJJ3Zl IGdvdHRlbiB0aG9zZSBpbnRvIHRoZSBsYXRlc3QgdmVyc2lvbi4gSWYgbm90LCAoZmlyc3Q6IHNv cnJ5Oi0pIGFuZCBqdXN0IHNlbmQgbWUgYSBwb2ludGVyIHRvIHRoZSBtYWlsIGFuZCBJJ2xsIHNo b290IG91dCBhIC0wMyBpZiBzdHVmZiBzdGlsbCBuZWVkcyBmaXhpbmcNCg0KW0FudHRpXSBJIHdp bGwgc2VuZCB1cGRhdGVzIGFzIHBlciB5b3VyIHJlcXVlc3QuDQoNCkNoZWVycywNClMuDQoNCj4g DQo+IEJlc3QgcmVnYXJkcywgQW50dGkNCj4gDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t IEZyb206IGxwLXdhbiANCj4gW21haWx0bzpscC13YW4tYm91bmNlc0BpZXRmLm9yZ10gT24gQmVo YWxmIE9mIENhcmxlcyBHb21leiBNb250ZW5lZ3JvIA0KPiBTZW50OiAxNS4gdG91a29rdXV0YSAy MDE3IDEwOjA4IFRvOiBTdGVwaGVuIEZhcnJlbGwgDQo+IDxzdGVwaGVuLmZhcnJlbGxAY3MudGNk LmllPiBDYzogbHAtd2FuIDxscC13YW5AaWV0Zi5vcmc+IFN1YmplY3Q6IFJlOg0KPiBbbHAtd2Fu XSBvdmVydmlldyBpc3N1ZSMxOiB3b3JzdCBjYXNlIE1UVS4uLg0KPiANCj4gSGkgU3RlcGhlbiwN Cj4gDQo+PiBEbyB0aGUgV0cgdGhpbmsgdGhhdCBpdCdkIGJlIHVzZWZ1bCB0byBoYXZlIHRoYXQg Zm9yIGVhY2ggb2YgdGhlIA0KPj4gdGVjaG5vbG9naWVzIGNvdmVyZWQ/IChJIHRoaW5rIGl0IHdv dWxkLCBmd2l3LikNCj4gDQo+IEl0IGlzIHJlYWxseSB1c2VmdWwgKGFuZCBhY3R1YWxseSByZXF1 aXJlZCBmb3IgSVB2NiBvdmVyIExQV0FOKSB0byANCj4gaGF2ZSBzdWNoIGluZm9ybWF0aW9uIGZv ciBlYWNoIGNvdmVyZWQgdGVjaG5vbG9neS4NCj4gDQo+IEkgdGhpbmsgc3VjaCBpbmZvcm1hdGlv biBpcyBhbHJlYWR5IGluY2x1ZGVkIGluIHRoZSBkb2N1bWVudCBmb3IgDQo+IExvUmFXQU4gYW5k IFNJR0ZPWC4gU28gd2hldGhlciAxNjAwIGJ5dGVzIGlzIHRoZSB3b3JzdC1jYXNlIE1UVSBpbiAN Cj4gTkItSW9UIHNob3VsZCBiZSBjb25maXJtZWQsIGFuZCB0aGUgd29yc3QtY2FzZSBNVFUgZm9y IFdpLVNVTiBzaG91bGQgDQo+IGFsc28gKGlkZWFsbHkpIGJlIGV4cGxpY2l0bHkgc3RhdGVkLg0K PiANCj4gSXQgd291bGQgYWxzbyBiZSB2ZXJ5IHVzZWZ1bCB0byBoYXZlIGluZm9ybWF0aW9uIG9u IHVwbGluayBhbmQgDQo+IGRvd25saW5rIG1lc3NhZ2UgcmF0ZSAoaS5lLiBtZXNzYWdlIHBlciB0 aW1lIHVuaXQpIGNvbnN0cmFpbnRzIGJleW9uZCANCj4gdGhvc2UgbmF0dXJhbGx5IGR1ZSB0byB0 aGUgcGh5c2ljYWwgbGF5ZXIgYml0IHJhdGUsIGZvciBhbGwgDQo+IHRlY2hub2xvZ2llcyBjb3Zl cmVkLg0KPiANCj4gQ2hlZXJzLA0KPiANCj4gQ2FybGVzDQo+IA0KPiBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXyBscC13YW4gbWFpbGluZyBsaXN0IA0KPiBs cC13YW5AaWV0Zi5vcmcgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9scC13 YW4NCj4gDQoNCg== From nobody Mon May 15 05:49:12 2017 Return-Path: X-Original-To: lp-wan@ietfa.amsl.com Delivered-To: lp-wan@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86A8A127A91 for ; Mon, 15 May 2017 05:49:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.702 X-Spam-Level: X-Spam-Status: No, score=-4.702 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=-2.8, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sigfoxgroup.onmicrosoft.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 A1x9m03c3Cp2 for ; Mon, 15 May 2017 05:49:08 -0700 (PDT) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-eopbgr20130.outbound.protection.outlook.com [40.107.2.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9494312E858 for ; Mon, 15 May 2017 05:45:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sigfoxgroup.onmicrosoft.com; s=selector1-sigfox-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=36+Z9tMrB+KESu3NGaFXviiRqD91NtUJ7xyiC3y/tsk=; b=eR5WXAosyUSg+ywcRDehSO4NLmNjqv9hIQzhBTA4vcSAJvDNSVRqNJkNcD0zeqlVG3DV+9cb3+91IRZjdX6P3Zn+ugs6nTTfyivFwWzCPYl7iCzVun2VYFSnNemt5MUcF8aJBFi9tn4dSdhkBcCA8GSCMmfg7Xh38mCnMhegju8= Received: from DB6PR08MB2679.eurprd08.prod.outlook.com (10.175.235.12) by DB6PR08MB2680.eurprd08.prod.outlook.com (10.175.235.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1084.16; Mon, 15 May 2017 12:45:06 +0000 Received: from DB6PR08MB2679.eurprd08.prod.outlook.com ([fe80::3c08:54b8:1c7c:498a]) by DB6PR08MB2679.eurprd08.prod.outlook.com ([fe80::3c08:54b8:1c7c:498a%13]) with mapi id 15.01.1084.027; Mon, 15 May 2017 12:45:06 +0000 From: Juan Carlos Zuniga To: Antti Ratilainen , Carles Gomez Montenegro , Stephen Farrell CC: lp-wan Thread-Topic: [lp-wan] overview issue#1: worst case MTU... Thread-Index: AQHSzJXvw8aqlwAoMk+ZKcgPfqJsdaH0+qyAgABXBQCAAAV+YA== Date: Mon, 15 May 2017 12:45:06 +0000 Message-ID: References: <581ff36a40953beacb6af19a50190928.squirrel@webmail.entel.upc.edu> In-Reply-To: Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ericsson.com; dkim=none (message not signed) header.d=none;ericsson.com; dmarc=none action=none header.from=sigfox.com; x-originating-ip: [104.163.143.41] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DB6PR08MB2680; 7:bdjSK/xfWGhIbnMo3kkCGryxczmTrSaqPzLqVIv3UUTC0bRppggA97xp7khAbfTUd9vxv/DgtpMeK3bF/qu9echz0LPQtOYFdvBZUPKvlozJJtjSU2CoveaRcOlzWIpMXD0Y1pggDQSRhbHaWgitX2/KOYVHorZNZdi6k6glNrbiZn2r9elW2bDqLNgTPpZUQibnqS5eaWzkLxuAA6Js1hP5WZZkdE38n0LPcZJuncbtoRVnYTjUd2Nb1Uo+95Jjn5N1T4T4wb/OnB9HJVptHWs3mU8Adxx1Hl6drzL3Ow1929lEmvwlxQ8k3WZ5ZTllKJ7anL2BFoax89fdc0FcjQ== x-ms-office365-filtering-correlation-id: 7e19ae26-e549-4b09-a894-08d49b903724 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081)(201702281549075); SRVR:DB6PR08MB2680; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(93006095)(93001095)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123564025)(20161123560025)(20161123562025)(20161123555025)(6072148); SRVR:DB6PR08MB2680; BCL:0; PCL:0; RULEID:; SRVR:DB6PR08MB2680; x-forefront-prvs: 0308EE423E x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39450400003)(39400400002)(39410400002)(39830400002)(9686003)(55016002)(6436002)(38730400002)(99286003)(66066001)(6246003)(53936002)(8936002)(478600001)(102836003)(6116002)(2171002)(3846002)(2906002)(54356999)(76176999)(189998001)(50986999)(3660700001)(3280700002)(4326008)(25786009)(7736002)(6506006)(74316002)(5660300001)(305945005)(2900100001)(33656002)(2950100002)(81166006)(86362001)(7696004)(5250100002)(229853002)(8676002)(17413003); DIR:OUT; SFP:1102; SCL:1; SRVR:DB6PR08MB2680; H:DB6PR08MB2679.eurprd08.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: sigfox.com X-MS-Exchange-CrossTenant-originalarrivaltime: 15 May 2017 12:45:06.7747 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: fcbc8bb1-061e-4b94-9f70-3ad917b0c8d3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR08MB2680 Archived-At: Subject: Re: [lp-wan] overview issue#1: worst case MTU... X-BeenThere: lp-wan@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Low-Power Wide Area Networking \(LP-WAN\), also known as LPWA or Low-Rate WAN \(LR-WAN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 May 2017 12:49:11 -0000 Hi Antti, >=20 > I'm not quite sure what is meant by worst case MTU. But in the case of NB= -IoT, > any size packet up to the said MTU size (1600 bytes) can be passed to NB-= IoT > from higher layers, segmentation of the packet is performed in the RLC la= yer, > which can segment the data to transmission blocks with size as small as 1= 6 bits. > Hope this clarifies this issue for NB-IoT. Is this true for both IP data mode as well as non-IP data over NAS (using t= he SCEF)? Best, Juan Carlos=20 From nobody Mon May 15 06:06:00 2017 Return-Path: X-Original-To: lp-wan@ietfa.amsl.com Delivered-To: lp-wan@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93ACF12941C for ; Mon, 15 May 2017 06:05:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.8 X-Spam-Level: X-Spam-Status: No, score=-3.8 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_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=imt-atlantique.fr 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 dyxPuPXZ19CN for ; Mon, 15 May 2017 06:05:49 -0700 (PDT) Received: from zproxy220.enst-bretagne.fr (zproxy220.enst-bretagne.fr [192.108.117.9]) by ietfa.amsl.com (Postfix) with ESMTP id 9AB9912956C for ; Mon, 15 May 2017 05:59:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zproxy220.enst-bretagne.fr (Postfix) with ESMTP id 402683025E for ; Mon, 15 May 2017 14:59:15 +0200 (CEST) Received: from zproxy220.enst-bretagne.fr ([127.0.0.1]) by localhost (zproxy220.enst-bretagne.fr [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id F34nNs0JDv_u for ; Mon, 15 May 2017 14:59:14 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by zproxy220.enst-bretagne.fr (Postfix) with ESMTP id B28D130230 for ; Mon, 15 May 2017 14:59:14 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.9.2 zproxy220.enst-bretagne.fr B28D130230 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=imt-atlantique.fr; s=50EA75E8-DE22-11E6-A6DE-0662BA474D24; t=1494853154; bh=PnMr9GEOLgKfiSvXUUIVAJMsu3owOIXzTVKBH/GgS6g=; h=MIME-Version:From:Date:Message-ID:Subject:To:Content-Type; b=QZ82a4Ug1i28abiwjDSxqbeQbsu0E7NFM1o8dWSIpIbIHjfPSXkWNEK0lzT4rX+Rc QiaUDzHl+TI69sFzJFGg6DL0i4j1P+ASDTe4e8mT9bwj5rf+qaHZ807HhDlHaQJWuR G/xeMXJawUYmD+PL8Iur9af3n3F6QAI3eYpdcDpY= X-Virus-Scanned: amavisd-new at zproxy220.enst-bretagne.fr Received: from zproxy220.enst-bretagne.fr ([127.0.0.1]) by localhost (zproxy220.enst-bretagne.fr [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id euSW5l3GN-ib for ; Mon, 15 May 2017 14:59:14 +0200 (CEST) Received: from mail-qt0-f182.google.com (mail-qt0-f182.google.com [209.85.216.182]) by zproxy220.enst-bretagne.fr (Postfix) with ESMTPSA id 4C64230252 for ; Mon, 15 May 2017 14:59:14 +0200 (CEST) Received: by mail-qt0-f182.google.com with SMTP id v27so73300887qtg.2 for ; Mon, 15 May 2017 05:59:14 -0700 (PDT) X-Gm-Message-State: AODbwcD7cJv1IF7qepUafln+zHY1PFGgsC/7ZVYyBWDdLJv8netg2qYn icDg3KVm69Id92DzjEvJKjPq9+Xqnw== X-Received: by 10.237.42.102 with SMTP id k35mr5802389qtf.58.1494853153056; Mon, 15 May 2017 05:59:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.132.99 with HTTP; Mon, 15 May 2017 05:58:32 -0700 (PDT) In-Reply-To: <21798_1494839597_5919712D_21798_82_1_BC397CDFFDB82545B5E3571A77AB72043CC24ED4@OPEXCLILM21.corporate.adroot.infra.ftgroup> References: <21798_1494839597_5919712D_21798_82_1_BC397CDFFDB82545B5E3571A77AB72043CC24ED4@OPEXCLILM21.corporate.adroot.infra.ftgroup> From: Laurent Toutain Date: Mon, 15 May 2017 14:58:32 +0200 X-Gmail-Original-Message-ID: Message-ID: To: philippe.christin@orange.com Cc: "lp-wan@ietf.org" Content-Type: multipart/alternative; boundary="001a1146e2a62df394054f8f9f8d" Archived-At: Subject: Re: [lp-wan] Question on LoRaWAN and SCHC decompression architecture (Figure 1) X-BeenThere: lp-wan@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Low-Power Wide Area Networking \(LP-WAN\), also known as LPWA or Low-Rate WAN \(LR-WAN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 May 2017 13:05:58 -0000 --001a1146e2a62df394054f8f9f8d Content-Type: text/plain; charset="UTF-8" Hi Philippe, The location of the SCHC Compressor/Decompressor is not imposed by the draft, it can be either in a Network Gateway (if the key is known) or in the Application Server. IPv6/UDP/CoAP can be compressed within a single rule or a rule for IPv6/UDP can be set and another one for CoAP. In that case, IPv6/UDP headers can be compressed between the Device and the Network Gateway and the CoAP between the Device and the Application. Laurent On Mon, May 15, 2017 at 11:13 AM, wrote: > Hi, > > > > The LoRaWAN protocol is designed to encrypt LoRaWAN MAC payload between > the Device and the Application Server (End to End confidentiality). > > And the NGW and the Application Server are connected through HTTPS link . > > > > How do you see for LoRaWAN a SCHC Decompression function running in > between of NGW and Application Server ? > > It should not be possible, except to host this function in the Application > Server. > > > > Thanks > > > > Philippe > > > > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. > > This message and its attachments may contain confidential or privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. > Thank you. > > > _______________________________________________ > lp-wan mailing list > lp-wan@ietf.org > https://www.ietf.org/mailman/listinfo/lp-wan > > --001a1146e2a62df394054f8f9f8d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Philippe,

The location of the SC= HC Compressor/Decompressor is not imposed by the draft, it can be either in= a Network Gateway (if the key is known) or in the Application Server. IPv6= /UDP/CoAP can be compressed within a single rule or a rule for IPv6/UDP can= be set and another one for CoAP. In that case, IPv6/UDP headers can be com= pressed between the Device and the Network Gateway and the CoAP between the= Device and the Application.

Laurent




On Mon, M= ay 15, 2017 at 11:13 AM, <philippe.christin@orange.com>= wrote:

Hi,<= /u>

=C2=A0<= u>

The LoRaWAN pr= otocol is designed to encrypt LoRaWAN MAC payload between the Device and th= e Application Server (End to End confidentiality).

And the NGW an= d the Application Server are connected through HTTPS link .

=C2=A0<= u>

How do you see= for LoRaWAN a SCHC Decompression function running in between of NGW and Ap= plication Server ?

It should not = be possible, except to host this function in the Application Server.

=C2=A0<= u>

Thanks<= u>

=C2=A0<= u>

Philippe

=C2=A0<= u>

____________________________________________________________=
_____________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les message=
s electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.

_______________________________________________
lp-wan mailing list
lp-wan@ietf.org
https://www.ietf.org/mailman/listinfo/lp-wan

--001a1146e2a62df394054f8f9f8d-- From nobody Mon May 15 23:16:45 2017 Return-Path: X-Original-To: lp-wan@ietfa.amsl.com Delivered-To: lp-wan@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D8AD128CDB for ; Mon, 15 May 2017 23:16:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 8CkgeS4rht7g for ; Mon, 15 May 2017 23:16:42 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (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 AF0DB1272E1 for ; Mon, 15 May 2017 23:14:03 -0700 (PDT) X-AuditID: c1b4fb30-663149a00000015f-26-591a98a9741d Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.183.69]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 57.45.00351.9A89A195; Tue, 16 May 2017 08:14:01 +0200 (CEST) Received: from ESESSMB101.ericsson.se ([169.254.1.161]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.03.0339.000; Tue, 16 May 2017 08:13:55 +0200 From: Antti Ratilainen To: Juan Carlos Zuniga , Carles Gomez Montenegro , Stephen Farrell CC: lp-wan Thread-Topic: [lp-wan] overview issue#1: worst case MTU... Thread-Index: AQHSzJXsNZDi7hpjxEm1UIPnYJm+sqH02SWAgAB3wwD//+aNAIABRjPw Date: Tue, 16 May 2017 06:13:54 +0000 Message-ID: References: <581ff36a40953beacb6af19a50190928.squirrel@webmail.entel.upc.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.16] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupnkeLIzCtJLcpLzFFi42KZGbHdVXflDKlIg5udRhYHt31ntei9PYvR 4s0se4vpe6+xO7B4rO2+yuZx/+ADZo8lS34yeTz9kBnAEsVlk5Kak1mWWqRvl8CVsf1+RsFp 9oqHPz8yNzBOZOti5OSQEDCRaJ10mKWLkYtDSOAIo8SDRzfYIZwljBKf56xi6mLk4GATMJN4 8E4LJC4iMI1RYsKfXawg3cwCMhIHG6ewg9jCApYSX259AbNFBKwkNs7cxgphu0nc2LuQGcRm EVCVOPakBWwzr4CvxMeVCxkhlk1nkujr28cCkuAUiJXYMmk+WBGjgJjE91NrmCCWiUvcejKf CeJsAYkle84zQ9iiEi8f/2OFsBUldp5tZ4ao15FYsPsTG4StLbFs4WtmiMWCEidnPmGZwCg6 C8nYWUhaZiFpmYWkZQEjyypG0eLU4qTcdCMjvdSizOTi4vw8vbzUkk2MwGg6uOW3wQ7Gl88d DzEKcDAq8fCGTJSKFGJNLCuuzD3EKMHBrCTCW2cCFOJNSaysSi3Kjy8qzUktPsQozcGiJM7r uO9ChJBAemJJanZqakFqEUyWiYNTqoGR6c+kNPbshZOUO7UYrp/yXDOvV0p7S0nB7m9Hgzjc on1+WScFR5/ivD33/L7PWt+YgwJVdvxtEJ+38LrZmQuSj2/Gb45bGn32w/845qWB88u+/Ip1 uVo55c+kjz25/2UStyXbcm4oZwqUXeXfxJ4snndvfrnujdfaXc/sFtUY+00yz1U5/oNViaU4 I9FQi7moOBEAFryjNaICAAA= Archived-At: Subject: Re: [lp-wan] overview issue#1: worst case MTU... X-BeenThere: lp-wan@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Low-Power Wide Area Networking \(LP-WAN\), also known as LPWA or Low-Rate WAN \(LR-WAN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 May 2017 06:16:44 -0000 Hi Juan Carlos, Yes, it is true for both cases. Best regards, Antti -----Original Message----- From: Juan Carlos Zuniga [mailto:juancarlos.zuniga@sigfox.com]=20 Sent: 15. toukokuuta 2017 15:45 To: Antti Ratilainen ; Carles Gomez Monteneg= ro ; Stephen Farrell Cc: lp-wan Subject: RE: [lp-wan] overview issue#1: worst case MTU... Hi Antti, >=20 > I'm not quite sure what is meant by worst case MTU. But in the case of=20 > NB-IoT, any size packet up to the said MTU size (1600 bytes) can be=20 > passed to NB-IoT from higher layers, segmentation of the packet is=20 > performed in the RLC layer, which can segment the data to transmission bl= ocks with size as small as 16 bits. > Hope this clarifies this issue for NB-IoT. Is this true for both IP data mode as well as non-IP data over NAS (using t= he SCEF)? Best, Juan Carlos=20 From nobody Wed May 17 01:04:05 2017 Return-Path: X-Original-To: lp-wan@ietfa.amsl.com Delivered-To: lp-wan@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3FD41286B2 for ; Wed, 17 May 2017 01:04:02 -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_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8] 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 iBfJnFXCncvO for ; Wed, 17 May 2017 01:04:00 -0700 (PDT) Received: from relay7-d.mail.gandi.net (relay7-d.mail.gandi.net [217.70.183.200]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E07E12778E for ; Wed, 17 May 2017 00:59:44 -0700 (PDT) Received: from relay3-d.mail.gandi.net (relay3-d.mail.gandi.net [217.70.183.195]) by relay7-d.mail.gandi.net (Postfix) with ESMTPS id BD5253855; Wed, 17 May 2017 09:59:41 +0200 (CEST) Received: from [IPv6:2001:660:7301:3728:590b:9880:e0cb:24a6] (unknown [IPv6:2001:660:7301:3728:590b:9880:e0cb:24a6]) (Authenticated sender: ana@ackl.io) by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id 31408A810A; Wed, 17 May 2017 09:59:40 +0200 (CEST) From: Ana Minaburo Content-Type: multipart/alternative; boundary="Apple-Mail=_6EEF5739-DC35-42C3-B1EB-3282E6B65702" Date: Wed, 17 May 2017 09:59:42 +0200 Message-Id: Cc: "Pascal Thubert (pthubert)" , Alexander Pelov To: lp-wan Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [lp-wan] ACK in packet mode X-BeenThere: lp-wan@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Low-Power Wide Area Networking \(LP-WAN\), also known as LPWA or Low-Rate WAN \(LR-WAN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 May 2017 08:04:03 -0000 --Apple-Mail=_6EEF5739-DC35-42C3-B1EB-3282E6B65702 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hello, After analysing the discussion during the last meeting, We need to fix = the problem regarding acknowledgement on packet mode When we send ack at the end of all fragments transmission, we got the = problem of the bitmap size in the downlink. I will take an average size = of 10 bytes (LoraWan, SF0) it is less for some technologies but it could = be useful for explanation. We got 128 fragments so we need 128 bits in a = packet of 10 bytes, so we need two downlink packets to ack all the = fragments. So I think Pascal added, we can only send the number of the = corrupted fragments, why not, but until how many corrupted fragments = this solution is better than the bitmap?=20 Taking 10 bytes less Rule-ID size 3bits, To represent 128 fragments I = need 7 bits per fragment, so I put Rule-ID in 3 bits to get 11 fragment = in one ack, if not it is 10 lost fragments I can have. So in the best case I can only have 11 lost fragments in this solution, = so if there are more than 11 lost fragments then we use bitmap and then = we need to 2 ack. Well, We need to define something else that can cover = all the fragments in one downlink packet Ana --Apple-Mail=_6EEF5739-DC35-42C3-B1EB-3282E6B65702 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hello,


After analysing the discussion during the last = meeting, We need = to fix the problem regarding acknowledgement on packet mode

When = we send ack at the end of all fragments transmission, we got the problem = of the bitmap size in the downlink. I will take an average size of = 10 bytes (LoraWan, SF0) it is less for some technologies but it = could be useful for explanation. We got 128 fragments so we need = 128 bits in a packet of 10 bytes, so we need two downlink packets = to ack all the fragments. So I think Pascal added, we can only send = the number of the corrupted fragments, why not, but until how many = corrupted fragments this solution is better than the bitmap? 
Taking 10 bytes less Rule-ID size 3bits,  To represent = 128 fragments I need 7 bits per fragment, so I put Rule-ID in 3 = bits to get 11 fragment in one ack, if not it is 10 lost  fragments = I can have.
So in the best case I can only have 11 = lost fragments in this solution, so if there are more than 11 lost = fragments then we use bitmap and then we need to 2 ack. Well, We need to = define something else that can cover all the fragments in one = downlink packet

Ana


= --Apple-Mail=_6EEF5739-DC35-42C3-B1EB-3282E6B65702-- From nobody Wed May 17 01:27:33 2017 Return-Path: X-Original-To: lp-wan@ietfa.amsl.com Delivered-To: lp-wan@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD0511271DF for ; Wed, 17 May 2017 01:27:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.5 X-Spam-Level: X-Spam-Status: No, score=-1.5 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3] 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 srwiSMnR_a8I for ; Wed, 17 May 2017 01:27:28 -0700 (PDT) Received: from violet.upc.es (violet.upc.es [147.83.2.51]) (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 0AD5F129488 for ; Wed, 17 May 2017 01:23:31 -0700 (PDT) Received: from entelserver.upc.edu (entelserver.upc.es [147.83.39.4]) by violet.upc.es (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id v4H8NOX3037076; Wed, 17 May 2017 10:23:24 +0200 Received: from webmail.entel.upc.edu (webmail.entel.upc.edu [147.83.39.6]) by entelserver.upc.edu (Postfix) with ESMTP id E1F571D53C1; Wed, 17 May 2017 10:23:23 +0200 (CEST) Received: from 83.53.20.192 by webmail.entel.upc.edu with HTTP; Wed, 17 May 2017 10:23:13 +0200 Message-ID: In-Reply-To: References: Date: Wed, 17 May 2017 10:23:13 +0200 From: "Carles Gomez Montenegro" To: "Ana Minaburo" Cc: "lp-wan" , "Pascal Thubert \(pthubert\)" , "Alexander Pelov" User-Agent: SquirrelMail/1.4.21-1.fc14 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: clamav-milter 0.99.2 at violet X-Virus-Status: Clean X-Greylist: Delayed for 49:15:45 by milter-greylist-4.3.9 (violet.upc.es [147.83.2.51]); Wed, 17 May 2017 10:23:25 +0200 (CEST) Archived-At: Subject: Re: [lp-wan] ACK in packet mode X-BeenThere: lp-wan@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Low-Power Wide Area Networking \(LP-WAN\), also known as LPWA or Low-Rate WAN \(LR-WAN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 May 2017 08:27:31 -0000 Hi Ana, I have been preparing some emails I'll sent right now, and one of them is exactly on this same topic. Thanks for bringing this up, and please see my comments there. Cheers, Carles > Hello, > > > After analysing the discussion during the last meeting, We need to fix the > problem regarding acknowledgement on packet mode > > When we send ack at the end of all fragments transmission, we got the > problem of the bitmap size in the downlink. I will take an average size of > 10 bytes (LoraWan, SF0) it is less for some technologies but it could be > useful for explanation. We got 128 fragments so we need 128 bits in a > packet of 10 bytes, so we need two downlink packets to ack all the > fragments. So I think Pascal added, we can only send the number of the > corrupted fragments, why not, but until how many corrupted fragments this > solution is better than the bitmap? > Taking 10 bytes less Rule-ID size 3bits, To represent 128 fragments I > need 7 bits per fragment, so I put Rule-ID in 3 bits to get 11 fragment in > one ack, if not it is 10 lost fragments I can have. > So in the best case I can only have 11 lost fragments in this solution, so > if there are more than 11 lost fragments then we use bitmap and then we > need to 2 ack. Well, We need to define something else that can cover all > the fragments in one downlink packet > > Ana > > > > _______________________________________________ > lp-wan mailing list > lp-wan@ietf.org > https://www.ietf.org/mailman/listinfo/lp-wan > From nobody Wed May 17 01:29:49 2017 Return-Path: X-Original-To: lp-wan@ietfa.amsl.com Delivered-To: lp-wan@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BF17129418 for ; Wed, 17 May 2017 01:29:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.52 X-Spam-Level: X-Spam-Status: No, score=-1.52 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] 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 tKwOk3UWGS5R for ; Wed, 17 May 2017 01:29:46 -0700 (PDT) Received: from dash.upc.es (dash.upc.es [147.83.2.50]) (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 C0F5E129AEA for ; Wed, 17 May 2017 01:25:44 -0700 (PDT) Received: from entelserver.upc.edu (entelserver.upc.es [147.83.39.4]) by dash.upc.es (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id v4H8Pgse022818 for ; Wed, 17 May 2017 10:25:42 +0200 Received: from webmail.entel.upc.edu (webmail.entel.upc.edu [147.83.39.6]) by entelserver.upc.edu (Postfix) with ESMTP id 8CF211D53C1; Wed, 17 May 2017 10:25:42 +0200 (CEST) Received: from 83.53.20.192 by webmail.entel.upc.edu with HTTP; Wed, 17 May 2017 10:25:31 +0200 Message-ID: <78f38a990ee9b96d62aa43114188d636.squirrel@webmail.entel.upc.edu> Date: Wed, 17 May 2017 10:25:31 +0200 From: "Carles Gomez Montenegro" To: lp-wan@ietf.org User-Agent: SquirrelMail/1.4.21-1.fc14 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: clamav-milter 0.99.2 at dash X-Virus-Status: Clean X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.3.9 (dash.upc.es [147.83.2.50]); Wed, 17 May 2017 10:25:42 +0200 (CEST) Archived-At: Subject: [lp-wan] Supporting "bitmap" and "list" ACK types X-BeenThere: lp-wan@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Low-Power Wide Area Networking \(LP-WAN\), also known as LPWA or Low-Rate WAN \(LR-WAN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 May 2017 08:29:48 -0000 Hi everyone, In the last interim WG meeting, the problem of a large bitmap was discussed. One proposal was considering that if the number of fragment losses (for a given fragmented IPv6 packet) is low, sending the list of the absolute numbers of lost fragments might be a more lightweight approach than sending the whole bitmap (see Example 1 below). In other situations, the bitmap will be more efficient (Example 2). Therefore, it would be good for a receiver to support both types of feedback, and use the most efficient one for each specific situation. Whether a bitmap or a list (of lost fragments) is used would be indicated in the Rule ID for the ACK. Any objections to / comments on this? Cheers, Carles ----------------------- Example 1 ********* - Number of fragments carrying the IPv6 packet: 90 - Number of lost fragments: 1 (out of 90) - Size of each absolute fragment number: 8 bits The sizes for the "bitmap" and "list" would be: - Bitmap size: 12 bytes - List size: 1 byte (Note: an additional byte could be used to indicate the total number of fragments received as additional information just in case the MIC fails) Example 2 ********* - Number of fragments carrying the IPv6 packet: 6 - Number of lost fragments: 4 (out of 6) - Size of each absolute fragment number: 8 bits - Bitmap size: 1 byte - List size: 4 bytes (possibly, plus a further "number of frags" byte) From nobody Wed May 17 01:32:15 2017 Return-Path: X-Original-To: lp-wan@ietfa.amsl.com Delivered-To: lp-wan@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25DE312E048 for ; Wed, 17 May 2017 01:32:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.52 X-Spam-Level: X-Spam-Status: No, score=-1.52 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] 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 M00w8gb1uyiC for ; Wed, 17 May 2017 01:32:11 -0700 (PDT) Received: from dash.upc.es (dash.upc.es [147.83.2.50]) (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 A1BCA129442 for ; Wed, 17 May 2017 01:28:22 -0700 (PDT) Received: from entelserver.upc.edu (entelserver.upc.es [147.83.39.4]) by dash.upc.es (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id v4H8SKj9023460 for ; Wed, 17 May 2017 10:28:20 +0200 Received: from webmail.entel.upc.edu (webmail.entel.upc.edu [147.83.39.6]) by entelserver.upc.edu (Postfix) with ESMTP id BC7891D53C1; Wed, 17 May 2017 10:28:20 +0200 (CEST) Received: from 83.53.20.192 by webmail.entel.upc.edu with HTTP; Wed, 17 May 2017 10:28:09 +0200 Message-ID: Date: Wed, 17 May 2017 10:28:09 +0200 From: "Carles Gomez Montenegro" To: lp-wan@ietf.org User-Agent: SquirrelMail/1.4.21-1.fc14 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: clamav-milter 0.99.2 at dash X-Virus-Status: Clean X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.3.9 (dash.upc.es [147.83.2.50]); Wed, 17 May 2017 10:28:20 +0200 (CEST) Archived-At: Subject: [lp-wan] ACK size exceeding the L2 MTU X-BeenThere: lp-wan@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Low-Power Wide Area Networking \(LP-WAN\), also known as LPWA or Low-Rate WAN \(LR-WAN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 May 2017 08:32:13 -0000 Hi again, Even if a fragment receiver may support both the "bitmap" and "list" ACK types, there may be scenarios where none of these ACK types can fit a single L2 MTU. (Another approach might avoid this problem, but it follows a different scheme for error correction and it is not considered here, see my next email.) The above problem will only happen under the following three conditions: i) the IPv6 packet is very large (in the sense of an LPWAN context), ii) a relatively high number of fragment losses per packet occurs, and iii) the L2 MTU has a size in the order of ~10 bytes. The three conditions being met simultaneously might be a relatively rare event, but still might happen. How should we handle this? A simple solution is to define a "multi-PDU" ACK, which can be carried over more than one L2 PDU. In practice, a maximum of two/three PDUs would be needed to carry the ACK for a 1280-byte IPv6 packet in the worst case. Assuming R = 8 bits: - In LoRaWAN, a bitmap ACK fits the L2 MTU, except for DR0 in the US (where two L2 PDUs will be needed to carry the bitmap for a 1280-byte IPv6 packet). - In SIGFOX, three L2 PDUs will be needed to carry the bitmap for a 1280-byte IPv6 packet. A bit from the Rule ID could signal whether a PDU is the last one carrying a multi-PDU ACK. Comments? Thanks, Carles From nobody Wed May 17 01:34:02 2017 Return-Path: X-Original-To: lp-wan@ietfa.amsl.com Delivered-To: lp-wan@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB480126C26 for ; Wed, 17 May 2017 01:34:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.52 X-Spam-Level: X-Spam-Status: No, score=-1.52 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] 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 PcC28fjyQYR4 for ; Wed, 17 May 2017 01:33:58 -0700 (PDT) Received: from dash.upc.es (dash.upc.es [147.83.2.50]) (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 BAE50128CD5 for ; Wed, 17 May 2017 01:30:05 -0700 (PDT) Received: from entelserver.upc.edu (entelserver.upc.es [147.83.39.4]) by dash.upc.es (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id v4H8U3tp024113 for ; Wed, 17 May 2017 10:30:03 +0200 Received: from webmail.entel.upc.edu (webmail.entel.upc.edu [147.83.39.6]) by entelserver.upc.edu (Postfix) with ESMTP id AB9D41D53C1; Wed, 17 May 2017 10:30:03 +0200 (CEST) Received: from 83.53.20.192 by webmail.entel.upc.edu with HTTP; Wed, 17 May 2017 10:29:52 +0200 Message-ID: <48d27dc1bb6776c6e318175d2e882a8f.squirrel@webmail.entel.upc.edu> Date: Wed, 17 May 2017 10:29:52 +0200 From: "Carles Gomez Montenegro" To: lp-wan@ietf.org User-Agent: SquirrelMail/1.4.21-1.fc14 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: clamav-milter 0.99.2 at dash X-Virus-Status: Clean X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.3.9 (dash.upc.es [147.83.2.50]); Wed, 17 May 2017 10:30:03 +0200 (CEST) Archived-At: Subject: [lp-wan] Ambiguity problem in Packet mode: possible solutions X-BeenThere: lp-wan@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Low-Power Wide Area Networking \(LP-WAN\), also known as LPWA or Low-Rate WAN \(LR-WAN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 May 2017 08:34:01 -0000 Hi LPWANners, Yet another item for discussion: ambiguity in Packet mode and possible solutions. The problem *********** Use of a CFN in Packet mode involves a possible issue when some fragments are lost and need to be resent. In the example below, three fragments are lost and are resent. However, the fact that two different fragments with the same CFN are resent may lead to ambiguity. Sender Receiver |-------CFN=6-------->| |-------CFN=5-------->| |-------CFN=4---X---->| |-------CFN=3-------->| |-------CFN=2---X---->| |-------CFN=1-------->| |-------CFN=0-------->| |-------CFN=6-------->| |-------CFN=5-------->| |-------CFN=4---X---->| |-------CFN=7-------->|MIC checked |<-------ACK----------|bitmap:1101011110100001 retry A |-------CFN=4-------->| retry B |-------CFN=2-------->| retry C |-------CFN=4-------->|MIC checked => |<-------ACK----------|no bitmap (End) - If retries B and C are unsuccessful, the receiver will only get one fragment with CFN=4 (retry A). - If retries A and B are unsuccessful, the receiver will only get one fragment with CFN=4 (retry C). Then: how can the receiver tell in any of the two situations above which one of the two fragments with CFN=4 has been received? Solutions ********* 1.- AFN for retries ******************* One attempt to solve this is in -03: there is a format for first transmission attempts (which uses the CFN) and a format for retransmissions (which uses the Absolute Fragment Number, AFN). This would avoid ambiguity, but in the interim some concerns were expressed. Since the fragmentation header for retries will be larger than the one for first attempts, data in the first transmission attempt cannot fill the whole L2 MTU, so that data in a retry still fits the L2 MTU. In addition, in some technologies, the whole MTU needs to be filled. 2.- AFN always ************** A solution is to use the AFN for both first transmission attempts and retries (or, equivalently, a CFN field with a large enough size). This would avoid ambiguity. However, the fragmentation header size will be larger than with the usually short CFN (e.g. adding 1 byte to the header). When the underlying LPWAN technology supports ~10 bytes of L2 MTU, this approach may increase the number of fragments needed to carry a large IPv6 packet by ~10%. 3.- Fragment renumbering ************************ This mechanism renumbers the CFN of lost fragments (and thus avoids increasing fragmentation header size) by numbering retransmitted fragments as if they were a new sequence of fragments, e.g.: Sender Receiver |-------CFN=6-------->| |-------CFN=5-------->| |-------CFN=4---X---->| |-------CFN=3-------->| |-------CFN=2---X---->| |-------CFN=1-------->| |-------CFN=0-------->| |-------CFN=6-------->| |-------CFN=5-------->| |-------CFN=4---X---->| |-------CFN=7-------->|MIC checked |<-------ACK----------|bitmap:1101011110100001 retry A |-------CFN=6-------->| retry B |-------CFN=5-------->| retry C |-------CFN=4-------->|MIC checked => |<-------ACK----------|no bitmap (End) There is still some non-zero probability of ambiguity with this approach. However, such probability would be low. Ambiguity will happen if at least 2^N-1 consecutive retransmitted fragments are lost. This can also happen for first transmission attempts, and N should be set to a large enough value. (Note that in this case, the receiver can still tell after the MIC check that the packet has not been correctly received, even if it cannot tell what has been lost.) We currently recommend N >= 3 for Packet (and Window) mode. We may "steal" one more bit from the Rule ID space (now N=4) and ambiguity may only happen if the packet sent requires at least 16 fragments to be carried, there are at least 15 lost fragments (for the first round of transmissions) and then at least 15 consecutive losses from retransmitted fragments. Furthermore, typical error burstiness in wireless links may be less severe in LPWAN, considering that time between two consecutive transmissions may be large (due to message rate limitations), thus long fragment loss bursts should be less likely here. 4. Fountain code **************** Another solution suggested in the interim was using a fountain code and a short-sized ACK that just tells how many fragments have been missed. The CFN would be used (no need for an AFN). However, the sender may need to send an excess of E encoded "fragments" (in addition to the actual number of fragments) to allow the receiver recover the complete packet with high probability [1]. The exact amount of overhead may depend on the specific fountain code used and could also be configurable. How would the overhead of this solution compare with that of the other solutions above? ----- What does the WG think about these 4 possible options? Any preference? Anything in particular to avoid? (I would like to have WG feedback before addressing this in -04...) Thanks! Carles [1] https://docs.switzernet.com/people/emin-gabrielyan/060112-capillary-references/ref/MacKay05.pdf From nobody Wed May 17 08:53:42 2017 Return-Path: X-Original-To: lp-wan@ietfa.amsl.com Delivered-To: lp-wan@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEAD812EC4B for ; Wed, 17 May 2017 08:53:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.501 X-Spam-Level: X-Spam-Status: No, score=-3.501 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8] 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 OIngDpGiPlNZ for ; Wed, 17 May 2017 08:53:38 -0700 (PDT) Received: from relay7-d.mail.gandi.net (relay7-d.mail.gandi.net [217.70.183.200]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC81312EB68 for ; Wed, 17 May 2017 08:47:19 -0700 (PDT) Received: from relay3-d.mail.gandi.net (relay3-d.mail.gandi.net [217.70.183.195]) by relay7-d.mail.gandi.net (Postfix) with ESMTPS id 3568E380C; Wed, 17 May 2017 17:47:18 +0200 (CEST) Received: from mfilter14-d.gandi.net (mfilter14-d.gandi.net [217.70.178.142]) by relay3-d.mail.gandi.net (Postfix) with ESMTP id 208C2A810C; Wed, 17 May 2017 17:47:18 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter14-d.gandi.net Received: from relay3-d.mail.gandi.net ([IPv6:::ffff:217.70.183.195]) by mfilter14-d.gandi.net (mfilter14-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id Dg2f6a30ddnR; Wed, 17 May 2017 17:47:15 +0200 (CEST) X-Originating-IP: 192.44.77.204 Received: from el-meco.rennes.enst-bretagne.fr (nat-asr-incub-b204.rennes.enst-bretagne.fr [192.44.77.204]) (Authenticated sender: ana@ackl.io) by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id 938C3A80C1; Wed, 17 May 2017 17:47:15 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: text/plain; charset=utf-8 From: Ana Minaburo X-Priority: 3 (Normal) In-Reply-To: <78f38a990ee9b96d62aa43114188d636.squirrel@webmail.entel.upc.edu> Date: Wed, 17 May 2017 17:47:15 +0200 Cc: lp-wan@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <4D032E13-286D-40F2-93A6-B30BD643CB72@ackl.io> References: <78f38a990ee9b96d62aa43114188d636.squirrel@webmail.entel.upc.edu> To: Carles Gomez Montenegro X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [lp-wan] Supporting "bitmap" and "list" ACK types X-BeenThere: lp-wan@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Low-Power Wide Area Networking \(LP-WAN\), also known as LPWA or Low-Rate WAN \(LR-WAN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 May 2017 15:53:42 -0000 Hello Carles,=20 The support for both types of feedback needs to be mandatory, and I = agree about using the Rule ID to identify whether I=E2=80=99m sending a = bitmap or the list of absolute numbers. But the decision about which is better is more difficult to take, I = think it does not depend on the rate lost/total number of fragments but = on the number of bytes I need to represent all this information vs the = ACK size. One possibility to define the use of both types of feedback could be: = When the number of lost packet is less than the max size of the ACK - 1 = bytes (for Rule ID + Total fragments) the list may be used, and when = there are more packets than the ACK size - 1 byte the bitmap may be = used. At least we have a clear decision where to use each choice. Ana > On 17 May 2017, at 10:25, Carles Gomez Montenegro = wrote: >=20 > Hi everyone, >=20 > In the last interim WG meeting, the problem of a large bitmap was > discussed. >=20 > One proposal was considering that if the number of fragment losses = (for a > given fragmented IPv6 packet) is low, sending the list of the absolute > numbers of lost fragments might be a more lightweight approach than > sending the whole bitmap (see Example 1 below). In other situations, = the > bitmap will be more efficient (Example 2). >=20 > Therefore, it would be good for a receiver to support both types of > feedback, and use the most efficient one for each specific situation. > Whether a bitmap or a list (of lost fragments) is used would be = indicated > in the Rule ID for the ACK. >=20 > Any objections to / comments on this? >=20 > Cheers, >=20 > Carles >=20 >=20 > ----------------------- >=20 > Example 1 > ********* >=20 > - Number of fragments carrying the IPv6 packet: 90 > - Number of lost fragments: 1 (out of 90) > - Size of each absolute fragment number: 8 bits >=20 > The sizes for the "bitmap" and "list" would be: >=20 > - Bitmap size: 12 bytes > - List size: 1 byte (Note: an additional byte could be used to = indicate the > total number of fragments received as additional information just in = case > the MIC fails) >=20 >=20 > Example 2 > ********* >=20 > - Number of fragments carrying the IPv6 packet: 6 > - Number of lost fragments: 4 (out of 6) > - Size of each absolute fragment number: 8 bits >=20 > - Bitmap size: 1 byte > - List size: 4 bytes (possibly, plus a further "number of frags" byte) >=20 > _______________________________________________ > lp-wan mailing list > lp-wan@ietf.org > https://www.ietf.org/mailman/listinfo/lp-wan From nobody Wed May 17 09:02:51 2017 Return-Path: X-Original-To: lp-wan@ietfa.amsl.com Delivered-To: lp-wan@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D325212ECA3 for ; Wed, 17 May 2017 09:02:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.4 X-Spam-Level: X-Spam-Status: No, score=-5.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8] 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 Rz2b4NLWjEBY for ; Wed, 17 May 2017 09:02:48 -0700 (PDT) Received: from relay7-d.mail.gandi.net (relay7-d.mail.gandi.net [217.70.183.200]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDED812EC80 for ; Wed, 17 May 2017 08:56:21 -0700 (PDT) Received: from relay3-d.mail.gandi.net (relay3-d.mail.gandi.net [217.70.183.195]) by relay7-d.mail.gandi.net (Postfix) with ESMTPS id 77A2A383D; Wed, 17 May 2017 17:56:20 +0200 (CEST) Received: from mfilter24-d.gandi.net (mfilter24-d.gandi.net [217.70.178.152]) by relay3-d.mail.gandi.net (Postfix) with ESMTP id 5EE66A8112; Wed, 17 May 2017 17:56:20 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter24-d.gandi.net Received: from relay3-d.mail.gandi.net ([IPv6:::ffff:217.70.183.195]) by mfilter24-d.gandi.net (mfilter24-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id A3KSCa49OBRC; Wed, 17 May 2017 17:56:18 +0200 (CEST) X-Originating-IP: 192.44.77.204 Received: from el-meco.rennes.enst-bretagne.fr (nat-asr-incub-b204.rennes.enst-bretagne.fr [192.44.77.204]) (Authenticated sender: ana@ackl.io) by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id B5CC2A80F1; Wed, 17 May 2017 17:56:18 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: text/plain; charset=us-ascii From: Ana Minaburo X-Priority: 3 (Normal) In-Reply-To: Date: Wed, 17 May 2017 17:56:18 +0200 Cc: lp-wan@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <381888E7-BD7F-47CA-A5C0-12187B58E29E@ackl.io> References: To: Carles Gomez Montenegro X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [lp-wan] ACK size exceeding the L2 MTU X-BeenThere: lp-wan@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Low-Power Wide Area Networking \(LP-WAN\), also known as LPWA or Low-Rate WAN \(LR-WAN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 May 2017 16:02:50 -0000 Hello, In the case where the ACK size exceeds the L2 MTU, you use window mode To go forward with your thoughts, which will be more expensive retrying = a very corrupted packet or drop it and send it again?=20 What could be a relatively high number of fragment losses? 20%, 30% ?=20 Ana > On 17 May 2017, at 10:28, Carles Gomez Montenegro = wrote: >=20 > Hi again, >=20 > Even if a fragment receiver may support both the "bitmap" and "list" = ACK > types, there may be scenarios where none of these ACK types can fit a > single L2 MTU. (Another approach might avoid this problem, but it = follows > a different scheme for error correction and it is not considered here, = see > my next email.) >=20 > The above problem will only happen under the following three = conditions: >=20 > i) the IPv6 packet is very large (in the sense of an LPWAN context), > ii) a relatively high number of fragment losses per packet occurs, and > iii) the L2 MTU has a size in the order of ~10 bytes. >=20 > The three conditions being met simultaneously might be a relatively = rare > event, but still might happen. How should we handle this? >=20 > A simple solution is to define a "multi-PDU" ACK, which can be carried > over more than one L2 PDU. In practice, a maximum of two/three PDUs = would > be needed to carry the ACK for a 1280-byte IPv6 packet in the worst = case. >=20 > Assuming R =3D 8 bits: >=20 > - In LoRaWAN, a bitmap ACK fits the L2 MTU, except for DR0 in the US > (where two L2 PDUs will be needed to carry the bitmap for a 1280-byte = IPv6 > packet). >=20 > - In SIGFOX, three L2 PDUs will be needed to carry the bitmap for a > 1280-byte IPv6 packet. >=20 > A bit from the Rule ID could signal whether a PDU is the last one = carrying > a multi-PDU ACK. >=20 > Comments? >=20 > Thanks, >=20 > Carles >=20 > _______________________________________________ > lp-wan mailing list > lp-wan@ietf.org > https://www.ietf.org/mailman/listinfo/lp-wan From nobody Wed May 17 23:42:08 2017 Return-Path: X-Original-To: lp-wan@ietfa.amsl.com Delivered-To: lp-wan@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D734E12EA94 for ; Wed, 17 May 2017 23:42:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.499 X-Spam-Level: X-Spam-Status: No, score=-1.499 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, 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 LLvKCqBxhuJG for ; Wed, 17 May 2017 23:42:03 -0700 (PDT) Received: from violet.upc.es (violet.upc.es [147.83.2.51]) (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 F2617129562 for ; Wed, 17 May 2017 23:36:42 -0700 (PDT) Received: from entelserver.upc.edu (entelserver.upc.es [147.83.39.4]) by violet.upc.es (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id v4I6ad2q035072; Thu, 18 May 2017 08:36:39 +0200 Received: from webmail.entel.upc.edu (webmail.entel.upc.edu [147.83.39.6]) by entelserver.upc.edu (Postfix) with ESMTP id AE9C21D53C1; Thu, 18 May 2017 08:36:38 +0200 (CEST) Received: from 83.53.20.192 by webmail.entel.upc.edu with HTTP; Thu, 18 May 2017 08:36:22 +0200 Message-ID: In-Reply-To: <4D032E13-286D-40F2-93A6-B30BD643CB72@ackl.io> References: <78f38a990ee9b96d62aa43114188d636.squirrel@webmail.entel.upc.edu> <4D032E13-286D-40F2-93A6-B30BD643CB72@ackl.io> Date: Thu, 18 May 2017 08:36:22 +0200 From: "Carles Gomez Montenegro" To: "Ana Minaburo" Cc: lp-wan@ietf.org User-Agent: SquirrelMail/1.4.21-1.fc14 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: clamav-milter 0.99.2 at violet X-Virus-Status: Clean X-Greylist: Delayed for 22:13:15 by milter-greylist-4.3.9 (violet.upc.es [147.83.2.51]); Thu, 18 May 2017 08:36:39 +0200 (CEST) Archived-At: Subject: Re: [lp-wan] Supporting "bitmap" and "list" ACK types X-BeenThere: lp-wan@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Low-Power Wide Area Networking \(LP-WAN\), also known as LPWA or Low-Rate WAN \(LR-WAN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 May 2017 06:42:06 -0000 Hi Ana, Thanks for your comments! Please see some inline responses below: > The support for both types of feedback needs to be mandatory, and I agree > about using the Rule ID to identify whether I’m sending a bitmap or the > list of absolute numbers. OK! > But the decision about which is better is more difficult to take, I think > it does not depend on the rate lost/total number of fragments but on the > number of bytes I need to represent all this information vs the ACK size. Yes, it does not depend on the percentage of lost fragments, but on i) how many lost fragments there have been for an IPv6 packet, and also on ii) the total number of fragments (since the most efficient type of ACK can be chosen based on these two parameters). One detail here (mentioned in your previous email) is that in some cases (i.e. technologies and the direction in terms of uplink/downlink), a 7-bit field would suffice to encode the absolute fragment number for the "list", assuming we intend to support a maximum IPv6 packet size of 1280 bytes. In other cases, an 8-bit field would be needed. > One possibility to define the use of both types of feedback could be: When > the number of lost packet is less than the max size of the ACK - 1 bytes > (for Rule ID + Total fragments) the list may be used, and when there are > more packets than the ACK size - 1 byte the bitmap may be used. At least > we have a clear decision where to use each choice. That is one option, although in some cases it would not lead to using the shortest possible ACK (see e.g. Example 2 below). I think a receiver can have freedom to create the most convenient type of ACK for each received fragmented IPv6 packet, based on the total number of fragments and on the amount of lost fragments for that packet... Cheers, Carles > Ana > > >> On 17 May 2017, at 10:25, Carles Gomez Montenegro >> wrote: >> >> Hi everyone, >> >> In the last interim WG meeting, the problem of a large bitmap was >> discussed. >> >> One proposal was considering that if the number of fragment losses (for >> a >> given fragmented IPv6 packet) is low, sending the list of the absolute >> numbers of lost fragments might be a more lightweight approach than >> sending the whole bitmap (see Example 1 below). In other situations, the >> bitmap will be more efficient (Example 2). >> >> Therefore, it would be good for a receiver to support both types of >> feedback, and use the most efficient one for each specific situation. >> Whether a bitmap or a list (of lost fragments) is used would be >> indicated >> in the Rule ID for the ACK. >> >> Any objections to / comments on this? >> >> Cheers, >> >> Carles >> >> >> ----------------------- >> >> Example 1 >> ********* >> >> - Number of fragments carrying the IPv6 packet: 90 >> - Number of lost fragments: 1 (out of 90) >> - Size of each absolute fragment number: 8 bits >> >> The sizes for the "bitmap" and "list" would be: >> >> - Bitmap size: 12 bytes >> - List size: 1 byte (Note: an additional byte could be used to indicate >> the >> total number of fragments received as additional information just in >> case >> the MIC fails) >> >> >> Example 2 >> ********* >> >> - Number of fragments carrying the IPv6 packet: 6 >> - Number of lost fragments: 4 (out of 6) >> - Size of each absolute fragment number: 8 bits >> >> - Bitmap size: 1 byte >> - List size: 4 bytes (possibly, plus a further "number of frags" byte) >> >> _______________________________________________ >> lp-wan mailing list >> lp-wan@ietf.org >> https://www.ietf.org/mailman/listinfo/lp-wan > > _______________________________________________ > lp-wan mailing list > lp-wan@ietf.org > https://www.ietf.org/mailman/listinfo/lp-wan > From nobody Thu May 18 00:32:53 2017 Return-Path: X-Original-To: lp-wan@ietfa.amsl.com Delivered-To: lp-wan@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40B6512EC21 for ; Thu, 18 May 2017 00:32:52 -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, RCVD_IN_DNSWL_MED=-2.3, 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 3c6uNXj405A8 for ; Thu, 18 May 2017 00:32:50 -0700 (PDT) Received: from violet.upc.es (violet.upc.es [147.83.2.51]) (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 8594712EB51 for ; Thu, 18 May 2017 00:27:25 -0700 (PDT) Received: from entelserver.upc.edu (entelserver.upc.es [147.83.39.4]) by violet.upc.es (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id v4I7RLCP050223; Thu, 18 May 2017 09:27:21 +0200 Received: from webmail.entel.upc.edu (webmail.entel.upc.edu [147.83.39.6]) by entelserver.upc.edu (Postfix) with ESMTP id 005E11D53C1; Thu, 18 May 2017 09:27:21 +0200 (CEST) Received: from 83.53.20.192 by webmail.entel.upc.edu with HTTP; Thu, 18 May 2017 09:27:04 +0200 Message-ID: <9d56d693a40f81869ceff0e17732793e.squirrel@webmail.entel.upc.edu> In-Reply-To: <381888E7-BD7F-47CA-A5C0-12187B58E29E@ackl.io> References: <381888E7-BD7F-47CA-A5C0-12187B58E29E@ackl.io> Date: Thu, 18 May 2017 09:27:04 +0200 From: "Carles Gomez Montenegro" To: "Ana Minaburo" Cc: lp-wan@ietf.org User-Agent: SquirrelMail/1.4.21-1.fc14 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: clamav-milter 0.99.2 at violet X-Virus-Status: Clean X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.3.9 (violet.upc.es [147.83.2.51]); Thu, 18 May 2017 09:27:22 +0200 (CEST) Archived-At: Subject: Re: [lp-wan] ACK size exceeding the L2 MTU X-BeenThere: lp-wan@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Low-Power Wide Area Networking \(LP-WAN\), also known as LPWA or Low-Rate WAN \(LR-WAN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 May 2017 07:32:52 -0000 Hi Ana, Thanks again! Please see inline: > In the case where the ACK size exceeds the L2 MTU, you use window mode That is an option. However, while ACK size would potentially be shorter than in Packet mode (with multi-PDU ACK), the number of ACK data units in Window mode would be equal to or greater than the one with Packet mode (with multi-PDU ACK). For example, assume an IPv6 packet needs 100 fragments to be carried, and 10 of those fragments are lost. If the LPWAN technology has an 8-byte MTU in the "feedback channel" (i.e. from the fragment receiver to the fragment sender), a 2-PDU ACK will be needed in Packet mode (with either bitmap or list type ACK). However, in Window mode: - N=6 (window size: 63 frags), then 2 windows are used, 2 ACKs needed. - N=5 (window size: 31 frags), then 4 windows are used, 4 ACKs needed. - ... (The ACKs that would be needed after retries if losses can be recovered are not included in the count, but should also be considered.) If the ACKs are being sent in the expensive direction, one might want to reduce the number of data units required to carry ACKs. However, there may be other considerations for the Window or Packet mode choice (section 8.3 of the SCHC document), and the original question was about handling the situation in Packet mode (if possible). > To go forward with your thoughts, which will be more expensive retrying a > very corrupted packet or drop it and send it again? I think this is a very good and also difficult question. One might think that it is better to try to amortize the fragments that did arrive in a quite bad fragmented IPv6 packet transmission. On the other hand, a link may be suffering a "bad quality interval", but conditions might vary after a while and the channel quality may become good afterwards. So persisting when a channel is bad could be more expensive than resending after a while in this case. A sender could decide to abort an on-going transmission, and if some upper layer determines that the packet needs to be resent, there would be a retransmission later. > What could be a relatively high number of fragment losses? 20%, 30% ? Yes, something in that order, assuming that the IPv6 packet we are considering here is large (e.g. ~100 fragments). To be clearer, a "relatively high number of fragment losses" would be a number of losses that would lead to a "list" ACK to exceed the L2 MTU. Cheers, Carles > > Ana > > >> On 17 May 2017, at 10:28, Carles Gomez Montenegro >> wrote: >> >> Hi again, >> >> Even if a fragment receiver may support both the "bitmap" and "list" ACK >> types, there may be scenarios where none of these ACK types can fit a >> single L2 MTU. (Another approach might avoid this problem, but it >> follows >> a different scheme for error correction and it is not considered here, >> see >> my next email.) >> >> The above problem will only happen under the following three conditions: >> >> i) the IPv6 packet is very large (in the sense of an LPWAN context), >> ii) a relatively high number of fragment losses per packet occurs, and >> iii) the L2 MTU has a size in the order of ~10 bytes. >> >> The three conditions being met simultaneously might be a relatively rare >> event, but still might happen. How should we handle this? >> >> A simple solution is to define a "multi-PDU" ACK, which can be carried >> over more than one L2 PDU. In practice, a maximum of two/three PDUs >> would >> be needed to carry the ACK for a 1280-byte IPv6 packet in the worst >> case. >> >> Assuming R = 8 bits: >> >> - In LoRaWAN, a bitmap ACK fits the L2 MTU, except for DR0 in the US >> (where two L2 PDUs will be needed to carry the bitmap for a 1280-byte >> IPv6 >> packet). >> >> - In SIGFOX, three L2 PDUs will be needed to carry the bitmap for a >> 1280-byte IPv6 packet. >> >> A bit from the Rule ID could signal whether a PDU is the last one >> carrying >> a multi-PDU ACK. >> >> Comments? >> >> Thanks, >> >> Carles >> >> _______________________________________________ >> lp-wan mailing list >> lp-wan@ietf.org >> https://www.ietf.org/mailman/listinfo/lp-wan > > _______________________________________________ > lp-wan mailing list > lp-wan@ietf.org > https://www.ietf.org/mailman/listinfo/lp-wan > From nobody Thu May 18 00:47:25 2017 Return-Path: X-Original-To: lp-wan@ietfa.amsl.com Delivered-To: lp-wan@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECADF12E048 for ; Thu, 18 May 2017 00:47:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.601 X-Spam-Level: X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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=cs.tcd.ie 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 T-PuquDBmZx6 for ; Thu, 18 May 2017 00:47:21 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8223012E858 for ; Thu, 18 May 2017 00:41:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 034DDBE39 for ; Thu, 18 May 2017 08:41:38 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N3oQdW4fAi3e for ; Thu, 18 May 2017 08:41:36 +0100 (IST) Received: from [10.244.2.100] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 9C7A2BE38 for ; Thu, 18 May 2017 08:41:35 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1495093296; bh=U+ahrSiDvWIKIXoDrO/d65XwMO6wUSluS6PZzbmQwqQ=; h=From:Subject:To:Date:From; b=QVjNa/xA1CSeEwXC/y1A5tO5znK8reC/VQj+8s99+9TSKc1+BgUHQ1Vu7eg0s7cdE DuJ4tQNfrHTQzq1r8f80p8zhCHRgc5yEOWVbwQ8c02eIZw/JEWbKtK7Ev0ypoYKy/M g+XLRkzmXTYsn5/AkWQupLKnCk3T3THtRQvi0HDM= From: Stephen Farrell To: lp-wan Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <6a4c386b-4b23-569f-c32a-09d546e7e681@cs.tcd.ie> Date: Thu, 18 May 2017 08:41:34 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="4IrphvigAeSEoVAJ0cCSCdMHtlOsG0ROh" Archived-At: Subject: [lp-wan] overview issue#2: AAA server term... X-BeenThere: lp-wan@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Low-Power Wide Area Networking \(LP-WAN\), also known as LPWA or Low-Rate WAN \(LR-WAN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 May 2017 07:47:24 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --4IrphvigAeSEoVAJ0cCSCdMHtlOsG0ROh Content-Type: multipart/mixed; boundary="GXnmrFKEa6ORvLjbVB4k8AGuS7hX8SiSB"; protected-headers="v1" From: Stephen Farrell To: lp-wan Message-ID: <6a4c386b-4b23-569f-c32a-09d546e7e681@cs.tcd.ie> Subject: overview issue#2: AAA server term... --GXnmrFKEa6ORvLjbVB4k8AGuS7hX8SiSB Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable Hiya, (Crap: I mucked up the subject line by also calling this "issue#1" when I first sent this, maybe that's why nobody responded - so trying now with a correct subject line and with a suggested resolution in case nobody else cares... :-) In [1] we define the term "AAA server." I don't think that's a good term to use, as it may be read to assume that we'll end up with a RADIUS or Diameter based solution and a typical AAA server like that is just not the same as a LoRaWAN NS/JS. (There might be a RADIUS or Diameter server behind such a beast, but it's not the same thing.) I think (less sure though) that the "AAA server" is also not so good for the other technologies too. What'd the WG like to do here? If nobody answers, in the next revision I'll use the term "LPWAN back-end server" ("LBES") instead of "AAA server." That's also not great but at least doesn't have the potential to create new confusion. Cheers, S. [1] https://tools.ietf.org/html/draft-ietf-lpwan-overview-02#section-3 --GXnmrFKEa6ORvLjbVB4k8AGuS7hX8SiSB-- --4IrphvigAeSEoVAJ0cCSCdMHtlOsG0ROh Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZHVAuAAoJEC88hzaAX42iJ5QIALKfOdc4fBrV/1oeTvqTKUoO 1Y63GWcyBH4xBOgYDCWlGhrwH0Qd1mYuWT0gxKlV/dZc8T22JYPzP9Qp084K4ui/ 3iZA7UKfyF50m+OwuewDxI097LugG0FdcVX/ez0D7y4NCOwWeUroN9lr6bdMw0CE P+rC3fL9xA8q1Tu4DVVEgRlzN9Mn6WCsju2oGXjttb5SgL0FJBkxOgyoBxhevpdk sHaH8bAkRRlFCOAoJno2YKtTcvsH4zph1G81EogperGnjvUE5pI66/j83euHZKv5 iK+cN2nDr2+onafpyK9K/NCk6OSzC1191aivO9sW2d7KCLfyvJblqszu/xcqqTo= =muT+ -----END PGP SIGNATURE----- --4IrphvigAeSEoVAJ0cCSCdMHtlOsG0ROh-- From nobody Thu May 18 02:48:24 2017 Return-Path: X-Original-To: lp-wan@ietfa.amsl.com Delivered-To: lp-wan@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2EAD12EB6F for ; Thu, 18 May 2017 02:48:22 -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, RCVD_IN_DNSWL_MED=-2.3, 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 BGKrw0xw_z8J for ; Thu, 18 May 2017 02:48:20 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (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 3A42112EB9C for ; Thu, 18 May 2017 02:43:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v4I9h3dW010123; Thu, 18 May 2017 11:43:03 +0200 (CEST) Received: from [192.168.217.124] (p5DC7F3A7.dip0.t-ipconnect.de [93.199.243.167]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3wT5pH3h9wzDJ77; Thu, 18 May 2017 11:43:03 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Carsten Bormann X-Priority: 3 (Normal) In-Reply-To: <78f38a990ee9b96d62aa43114188d636.squirrel@webmail.entel.upc.edu> Date: Thu, 18 May 2017 11:43:02 +0200 Cc: lp-wan@ietf.org X-Mao-Original-Outgoing-Id: 516793382.424463-94bd5c781c2297ebdff6ef9847ce7a8e Content-Transfer-Encoding: quoted-printable Message-Id: <27B835A1-D133-45DD-97BF-807E1EAF376C@tzi.org> References: <78f38a990ee9b96d62aa43114188d636.squirrel@webmail.entel.upc.edu> To: Carles Gomez Montenegro X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [lp-wan] Supporting "bitmap" and "list" ACK types X-BeenThere: lp-wan@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Low-Power Wide Area Networking \(LP-WAN\), also known as LPWA or Low-Rate WAN \(LR-WAN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 May 2017 09:48:23 -0000 Use delta coding, with 0 as end of list (so no length is needed). Code each delta as a base-8 SDNV (RFC 6256 defines base-128 SDNVs), put = into nibbles. Optionally, spend a number of the SDNV code points for run lengths = and/or embedded bitmaps. (Use figure 3 of RFC 2687 as an inspiration, if needed.) This NACK format can easily be designed so it is much smaller than = either bitmaps or byte-wise sequence numbers for all realistic cases and = insignificantly larger than a bitmap for the most pathological case; no = need to waste rule space. Gr=C3=BC=C3=9Fe, Carsten > On May 17, 2017, at 10:25, Carles Gomez Montenegro = wrote: >=20 > Hi everyone, >=20 > In the last interim WG meeting, the problem of a large bitmap was > discussed. >=20 > One proposal was considering that if the number of fragment losses = (for a > given fragmented IPv6 packet) is low, sending the list of the absolute > numbers of lost fragments might be a more lightweight approach than > sending the whole bitmap (see Example 1 below). In other situations, = the > bitmap will be more efficient (Example 2). >=20 > Therefore, it would be good for a receiver to support both types of > feedback, and use the most efficient one for each specific situation. > Whether a bitmap or a list (of lost fragments) is used would be = indicated > in the Rule ID for the ACK. >=20 > Any objections to / comments on this? >=20 > Cheers, >=20 > Carles >=20 >=20 > ----------------------- >=20 > Example 1 > ********* >=20 > - Number of fragments carrying the IPv6 packet: 90 > - Number of lost fragments: 1 (out of 90) > - Size of each absolute fragment number: 8 bits >=20 > The sizes for the "bitmap" and "list" would be: >=20 > - Bitmap size: 12 bytes > - List size: 1 byte (Note: an additional byte could be used to = indicate the > total number of fragments received as additional information just in = case > the MIC fails) >=20 >=20 > Example 2 > ********* >=20 > - Number of fragments carrying the IPv6 packet: 6 > - Number of lost fragments: 4 (out of 6) > - Size of each absolute fragment number: 8 bits >=20 > - Bitmap size: 1 byte > - List size: 4 bytes (possibly, plus a further "number of frags" byte) >=20 > _______________________________________________ > lp-wan mailing list > lp-wan@ietf.org > https://www.ietf.org/mailman/listinfo/lp-wan >=20 From nobody Thu May 18 08:29:49 2017 Return-Path: X-Original-To: lp-wan@ietfa.amsl.com Delivered-To: lp-wan@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61F93129B4D for ; Thu, 18 May 2017 08:29:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.802 X-Spam-Level: X-Spam-Status: No, score=0.802 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=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 MvZuiMKxeuKk for ; Thu, 18 May 2017 08:29:45 -0700 (PDT) Received: from relay9-d.mail.gandi.net (relay9-d.mail.gandi.net [IPv6:2001:4b98:c:538::199]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39147128B4E for ; Thu, 18 May 2017 08:24:18 -0700 (PDT) Received: from relay6-d.mail.gandi.net (relay6-d.mail.gandi.net [217.70.183.198]) by relay9-d.mail.gandi.net (Postfix) with ESMTPS id 60D124074A for ; Thu, 18 May 2017 17:24:16 +0200 (CEST) Received: from mfilter17-d.gandi.net (mfilter17-d.gandi.net [217.70.178.145]) by relay6-d.mail.gandi.net (Postfix) with ESMTP id DEDA2FB8FB for ; Thu, 18 May 2017 17:24:16 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter17-d.gandi.net Received: from relay6-d.mail.gandi.net ([IPv6:::ffff:217.70.183.198]) by mfilter17-d.gandi.net (mfilter17-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id U63bi75ngg5N for ; Thu, 18 May 2017 17:24:15 +0200 (CEST) X-Originating-IP: 192.44.77.204 Received: from [192.168.1.157] (nat-asr-incub-b204.rennes.enst-bretagne.fr [192.44.77.204]) (Authenticated sender: arun@acklio.com) by relay6-d.mail.gandi.net (Postfix) with ESMTPSA id 30289FB8CE for ; Thu, 18 May 2017 17:24:14 +0200 (CEST) To: lp-wan@ietf.org References: <6a4c386b-4b23-569f-c32a-09d546e7e681@cs.tcd.ie> From: Arun Message-ID: <1fec4a42-3477-d8c1-ce6d-d2d8cd4b568c@acklio.com> Date: Thu, 18 May 2017 17:23:57 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <6a4c386b-4b23-569f-c32a-09d546e7e681@cs.tcd.ie> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="e1QQ1R6ExOOoTdItm4WAO2rHPGV62AnWU" Archived-At: Subject: Re: [lp-wan] overview issue#2: AAA server term... X-BeenThere: lp-wan@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Low-Power Wide Area Networking \(LP-WAN\), also known as LPWA or Low-Rate WAN \(LR-WAN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 May 2017 15:29:47 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --e1QQ1R6ExOOoTdItm4WAO2rHPGV62AnWU Content-Type: multipart/mixed; boundary="o4L4k0HJN3OxdhO9d348StSpNP5UQTLb9"; protected-headers="v1" From: Arun To: lp-wan@ietf.org Message-ID: <1fec4a42-3477-d8c1-ce6d-d2d8cd4b568c@acklio.com> Subject: Re: [lp-wan] overview issue#2: AAA server term... References: <6a4c386b-4b23-569f-c32a-09d546e7e681@cs.tcd.ie> In-Reply-To: <6a4c386b-4b23-569f-c32a-09d546e7e681@cs.tcd.ie> --o4L4k0HJN3OxdhO9d348StSpNP5UQTLb9 Content-Type: multipart/alternative; boundary="------------B40FF0144CB4A7ED3E1A21D0" This is a multi-part message in MIME format. --------------B40FF0144CB4A7ED3E1A21D0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Stephen, There is a draft, draft-garcia-radext-radius-lorawan, that explains the use of AAA server in lpwa technologies like lora. The idea is to use standardized solutions like AAA for authenticating end devices in such technologies. IMHO, AAA term in a way is good to push for the use of standard entities in the architecture. regards, Arun On 18/05/2017 09:41, Stephen Farrell wrote: > Hiya, > > (Crap: I mucked up the subject line by also calling this "issue#1" > when I first sent this, maybe that's why nobody responded - so > trying now with a correct subject line and with a suggested > resolution in case nobody else cares... :-) > > In [1] we define the term "AAA server." I don't think that's a good > term to use, as it may be read to assume that we'll end up with a > RADIUS or Diameter based solution and a typical AAA server like that > is just not the same as a LoRaWAN NS/JS. (There might be a RADIUS or > Diameter server behind such a beast, but it's not the same thing.) > I think (less sure though) that the "AAA server" is also not so good > for the other technologies too. > > What'd the WG like to do here? > > If nobody answers, in the next revision I'll use the term "LPWAN > back-end server" ("LBES") instead of "AAA server." That's also not > great but at least doesn't have the potential to create new confusion. > > Cheers, > S. > > [1] https://tools.ietf.org/html/draft-ietf-lpwan-overview-02#section-3 > > > > > > _______________________________________________ > lp-wan mailing list > lp-wan@ietf.org > https://www.ietf.org/mailman/listinfo/lp-wan --------------B40FF0144CB4A7ED3E1A21D0 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Stephen,
There is a draft, draft-garcia-radext-radius-lorawan, that explains the use of AAA server in lpwa technologies like lora.
The idea is to use standardized solutions like AAA for authenticating end devices in such technologies.
IMHO, AAA term in a way is good to push for the use of standard entities in the architecture.

regards,
Arun

On 18/05/2017 09:41, Stephen Farrell wrote:
Hiya,

(Crap: I mucked up the subject line by also calling this "issue#1"
when I first sent this, maybe that's why nobody responded - so
trying now with a correct subject line and with a suggested
resolution in case nobody else cares... :-)

In [1] we define the term "AAA server." I don't think that's a good
term to use, as it may be read to assume that we'll end up with a
RADIUS or Diameter based solution and a typical AAA server like that
is just not the same as a LoRaWAN NS/JS. (There might be a RADIUS or
Diameter server behind such a beast, but it's not the same thing.)
I think (less sure though) that the "AAA server" is also not so good
for the other technologies too.

What'd the WG like to do here?

If nobody answers, in the next revision I'll use the term "LPWAN
back-end server" ("LBES") instead of "AAA server." That's also not
great but at least doesn't have the potential to create new confusion.

Cheers,
S.

[1] https://tools.ietf.org/html/dra=
ft-ietf-lpwan-overview-02#section-3






_______________________________________________
lp-wan mailing list
lp-=
wan@ietf.org
https://www.ietf.org/mailman/listinfo/lp-wan

--------------B40FF0144CB4A7ED3E1A21D0-- --o4L4k0HJN3OxdhO9d348StSpNP5UQTLb9-- --e1QQ1R6ExOOoTdItm4WAO2rHPGV62AnWU Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJZHbyNAAoJENe8HNMjzJQRMGYP/RgFK/DlY6F5wAuY8duiOrph jTMCzNA/CIMjCJmt7q/ApbSrn/uKe+nQ+ZNXVsn45J+mBc7jKIXiygp0CXnkPUb5 zkRk/QEoGJHfwpnqOrnSBVYiPzSnSHR6WK5Q5y3/BiDSpNwCYB7Ar8vIM4q7R0zN npMPIbYXhW3+jE6vLgeqi3Sc49sHCQ4IQ9wAT5ayqjYROXL3clpWteYRWhwyjVW7 iHV3z/rLKwbQhmBjCl+JuxLii57DNodll2bITNUsm0W/CUIvWXo/zX+BOaCuEewX cj+Ae5iDCPp3KqzYWof7z6OFcJrEc0/HbsYeWHBjuC80NGyB4cVLKYfstoAHdIQb knaDneTw+LAUDpdHtVdlb8Z6S8fmVA6uTdA4P1VZ/T71ibJIg8suni4h4ccG5yE8 M91ctpdWmQT3jbGRce1cGxHTPH3wj4IF7nYrq2chHT1M85GRkF6+pCUASccjModz /+dw2nxyaC+AvAWXCxf+CZFkn1q3VzoOEJHfGUlqSmuiJXh7Sy92iARIjcxQeJEc VMUTF5Q5awChbj+WLQygzax3E8qS/HOmHAP+rCouI0LL/YC5xQK55NiB6Nn5XVsI 1h4SrtpEKyhb6ATRVyiHYta1lBQvd3WVca/5IS/EYis8lCBkObo5gQoYmEPJwfiF msdwvIbeMysO0otZAvKz =ZLVw -----END PGP SIGNATURE----- --e1QQ1R6ExOOoTdItm4WAO2rHPGV62AnWU-- From nobody Thu May 18 09:06:33 2017 Return-Path: X-Original-To: lp-wan@ietfa.amsl.com Delivered-To: lp-wan@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06F431294AB for ; Thu, 18 May 2017 09:06:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.69 X-Spam-Level: X-Spam-Status: No, score=-4.69 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sigfoxgroup.onmicrosoft.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 s_oAe1-fuSe8 for ; Thu, 18 May 2017 09:06:30 -0700 (PDT) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10126.outbound.protection.outlook.com [40.107.1.126]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36668129548 for ; Thu, 18 May 2017 09:01:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sigfoxgroup.onmicrosoft.com; s=selector1-sigfox-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=nBeJ5JbdJfKuLOLoXP28gnuEIcQY1YLBdxhKB0zvwEU=; b=WWyczxi1DQGRvOoZ8vu7RfNW/P2kxxodr9Ys/kiao0PU4euynIO4uCiCd5dEIhueTkYmB8VcrlTvPZUUTvNVi6jZy6ctwDMWP2KQGpalbSPy/ieByggRrePKYgn9mMovpEUX+mfYn7c1XTZei+8+Kw8eIneehOkxzsVBoAm2N0Q= Received: from DB6PR08MB2679.eurprd08.prod.outlook.com (10.175.235.12) by DB6PR08MB2680.eurprd08.prod.outlook.com (10.175.235.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1101.14; Thu, 18 May 2017 16:01:20 +0000 Received: from DB6PR08MB2679.eurprd08.prod.outlook.com ([fe80::3c08:54b8:1c7c:498a]) by DB6PR08MB2679.eurprd08.prod.outlook.com ([fe80::3c08:54b8:1c7c:498a%13]) with mapi id 15.01.1101.011; Thu, 18 May 2017 16:01:20 +0000 From: Juan Carlos Zuniga To: Arun , "lp-wan@ietf.org" Thread-Topic: [lp-wan] overview issue#2: AAA server term... Thread-Index: AQHSz6sAUOs+OLzI+0ux6AoVKl9EYKH6NjKAgAAH/eA= Date: Thu, 18 May 2017 16:01:20 +0000 Message-ID: References: <6a4c386b-4b23-569f-c32a-09d546e7e681@cs.tcd.ie> <1fec4a42-3477-d8c1-ce6d-d2d8cd4b568c@acklio.com> In-Reply-To: <1fec4a42-3477-d8c1-ce6d-d2d8cd4b568c@acklio.com> Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: acklio.com; dkim=none (message not signed) header.d=none;acklio.com; dmarc=none action=none header.from=sigfox.com; x-originating-ip: [104.163.146.252] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DB6PR08MB2680; 7:309oaLAMaSPE+3j6zn2r0MuJNYYZApTIlfsQwCSYlpUzT75TWVWwN9ykYTP9hgkdTY74XJ5nRC4S8lPoS3eg1tupLvmAKXYNxTA+1JSdACvpcRTQxAjqMxQfFcLu+fzPbNBrukZav7HnEXORQ/h+p2rTQhDtA3RAtQjTeOI80BBpMRuBZoj2oM9EMcODMF7WnOVzzzK5IzARH71u8znCu1GexNgEvAS6MhXBGNbVSiyT5pIGkS+bsSHK/aEuj9bAWdLNUZ3KNiHt2UhGA6GSOoYoC8UZoIqEYKCdZKBGrpKqYSkAq8e1G3YR9TgiPC1YLDoSaR6d97maXIW9ABP3WQ== x-ms-traffictypediagnostic: DB6PR08MB2680: x-ms-office365-filtering-correlation-id: 529bd57b-d211-4533-65a9-08d49e07200d x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:DB6PR08MB2680; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3002001)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123564025)(20161123558100)(20161123555025)(20161123560025)(6072148); SRVR:DB6PR08MB2680; BCL:0; PCL:0; RULEID:; SRVR:DB6PR08MB2680; x-forefront-prvs: 0311124FA9 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39830400002)(39450400003)(39410400002)(39400400002)(377454003)(24454002)(7696004)(2906002)(561944003)(7736002)(3280700002)(7906003)(74316002)(50986999)(38730400002)(54356999)(2501003)(5250100002)(189998001)(478600001)(966005)(2900100001)(66066001)(99286003)(9686003)(8676002)(55016002)(54896002)(6306002)(33656002)(9326002)(8936002)(236005)(25786009)(53546009)(6506006)(606005)(5660300001)(6246003)(86362001)(53936002)(6436002)(3846002)(3660700001)(6116002)(102836003)(81166006)(2950100002)(76176999)(790700001)(229853002); DIR:OUT; SFP:1102; SCL:1; SRVR:DB6PR08MB2680; H:DB6PR08MB2679.eurprd08.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DB6PR08MB26799EC47E945CF45AFCDBE689E40DB6PR08MB2679eurp_" MIME-Version: 1.0 X-OriginatorOrg: sigfox.com X-MS-Exchange-CrossTenant-originalarrivaltime: 18 May 2017 16:01:20.3139 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: fcbc8bb1-061e-4b94-9f70-3ad917b0c8d3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR08MB2680 Archived-At: Subject: Re: [lp-wan] overview issue#2: AAA server term... X-BeenThere: lp-wan@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Low-Power Wide Area Networking \(LP-WAN\), also known as LPWA or Low-Rate WAN \(LR-WAN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 May 2017 16:06:32 -0000 --_000_DB6PR08MB26799EC47E945CF45AFCDBE689E40DB6PR08MB2679eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I tend to agree with Stephen in that assuming a RADIUS or Diameter server i= s not generic enough. Even though a solution like the one proposed in draft= -garcia-radext-radius-lorawan might be suitable for certain technologies li= ke LoRaWAN, there are other protocols like Sigfox which don't have a joinin= g procedure or an authentication message exchange (i.e. every message is in= dividually authenticated). Therefore, Stephen's proposal to use LBES instea= d of AAA sounds like a good generic solution. Best, Juan Carlos From: lp-wan [mailto:lp-wan-bounces@ietf.org] On Behalf Of Arun Sent: May 18, 2017 11:24 AM To: lp-wan@ietf.org Subject: Re: [lp-wan] overview issue#2: AAA server term... Hi Stephen, There is a draft, draft-garcia-radext-radius-lorawan, that explains the use= of AAA server in lpwa technologies like lora. The idea is to use standardized solutions like AAA for authenticating end d= evices in such technologies. IMHO, AAA term in a way is good to push for the use of standard entities in= the architecture. regards, Arun On 18/05/2017 09:41, Stephen Farrell wrote: Hiya, (Crap: I mucked up the subject line by also calling this "issue#1" when I first sent this, maybe that's why nobody responded - so trying now with a correct subject line and with a suggested resolution in case nobody else cares... :-) In [1] we define the term "AAA server." I don't think that's a good term to use, as it may be read to assume that we'll end up with a RADIUS or Diameter based solution and a typical AAA server like that is just not the same as a LoRaWAN NS/JS. (There might be a RADIUS or Diameter server behind such a beast, but it's not the same thing.) I think (less sure though) that the "AAA server" is also not so good for the other technologies too. What'd the WG like to do here? If nobody answers, in the next revision I'll use the term "LPWAN back-end server" ("LBES") instead of "AAA server." That's also not great but at least doesn't have the potential to create new confusion. Cheers, S. [1] https://tools.ietf.org/html/draft-ietf-lpwan-overview-02#section-3 _______________________________________________ lp-wan mailing list lp-wan@ietf.org https://www.ietf.org/mailman/listinfo/lp-wan --_000_DB6PR08MB26799EC47E945CF45AFCDBE689E40DB6PR08MB2679eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

&n= bsp;

I tend = to agree with Stephen in that assuming a RADIUS or Diameter server is not g= eneric enough. Even though a solution like the one proposed in draft-garcia-radext-radius-lorawan might be suitable for c= ertain technologies like LoRaWAN, there are other protocols like Sigfox whi= ch don’t have a joining procedure or an authentication message exchan= ge (i.e. every message is individually authenticated). Therefore, Stephen’s proposal to use LBES instead of= AAA sounds like a good generic solution.

&n= bsp;

Best,

&n= bsp;

Juan Ca= rlos

&n= bsp;

&n= bsp;

From:= lp-wan [mailto:lp-wan-bounces@ietf.org] On Behalf Of Arun
Sent: May 18, 2017 11:24 AM
To: lp-wan@ietf.org
Subject: Re: [lp-wan] overview issue#2: AAA server term...

 

Hi Stephen,
There is a draft, draft-garcia-radext-radius-lorawan, that explains the= use of AAA server in lpwa technologies like lora.
The idea is to use standardized solutions like AAA for authenticating e= nd devices in such technologies.
IMHO, AAA term in a way is good to push for the use of standard entitie= s in the architecture.

regards,
Arun

On 18/05/2017 09:41, Stephen Farrell wrote:

 
Hiya,
 
(Crap: I mucked up the subject line by also calling this "issue#1=
"
when I first sent this, maybe that's why nobody responded - so
trying now with a correct subject line and with a suggested=

resolution in case nobody else cares... :-)
 
In [1] we define the term "AAA server." I don't think that's=
 a good
term to use, as it may be read to assume that we'll end up with a=

RADIUS or Diameter based solution and a typical AAA server like that
is just not the same as a LoRaWAN NS/JS. (There might be a RADIUS or
Diameter server behind such a beast, but it's not the same thing.)
I think (less sure though) that the "AAA server" is also not=
 so good
for the other technologies too.
 
What'd the WG like to do here?
 
If nobody answers, in the next revision I'll use the term "LPWAN<=
o:p>
back-end server" ("LBES") instead of "AAA server.&=
quot; That's also not
great but at least doesn't have the potential to create new confusion.=

 
Cheers,
S.
 
[1] https://tools.ietf.org/html/draft-ietf-lpwan-overview-02#secti=
on-3
 
 
 




_______________________________________________
lp-wan mailing list
lp-wan@ietf.org

https://www.i=
etf.org/mailman/listinfo/lp-wan

 

--_000_DB6PR08MB26799EC47E945CF45AFCDBE689E40DB6PR08MB2679eurp_-- From nobody Thu May 18 10:08:18 2017 Return-Path: X-Original-To: lp-wan@ietfa.amsl.com Delivered-To: lp-wan@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2D4212EB48 for ; Thu, 18 May 2017 10:08:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.19 X-Spam-Level: X-Spam-Status: No, score=-4.19 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, 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 pfXeCQTEQwhz for ; Thu, 18 May 2017 10:08:12 -0700 (PDT) Received: from xenon44.um.es (xenon44.um.es [155.54.212.171]) by ietfa.amsl.com (Postfix) with ESMTP id 6C1EB12EB6D for ; Thu, 18 May 2017 10:02:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon44.um.es (Postfix) with ESMTP id 5DB4A206CD; Thu, 18 May 2017 19:02:32 +0200 (CEST) X-Virus-Scanned: by antispam in UMU at xenon44.um.es Received: from xenon44.um.es ([127.0.0.1]) by localhost (xenon44.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Lxz5fi23z7Z2; Thu, 18 May 2017 19:02:32 +0200 (CEST) Received: from inf-205-172.inf.um.es (inf-205-172.inf.um.es [155.54.205.172]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: dan.garcia@um.es) by xenon44.um.es (Postfix) with ESMTPSA id 8A50E206C6; Thu, 18 May 2017 19:02:31 +0200 (CEST) Content-Type: multipart/alternative; boundary="Apple-Mail=_E7976E12-506A-4680-AD7C-ED13FAF54143" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: =?utf-8?Q?Dan_Garc=C3=ADa_Carrillo?= In-Reply-To: Date: Thu, 18 May 2017 19:02:31 +0200 Cc: =?utf-8?Q?Dan_Garc=C3=ADa_Carrillo?= , Arun , "lp-wan@ietf.org" Message-Id: References: <6a4c386b-4b23-569f-c32a-09d546e7e681@cs.tcd.ie> <1fec4a42-3477-d8c1-ce6d-d2d8cd4b568c@acklio.com> To: Juan Carlos Zuniga X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [lp-wan] overview issue#2: AAA server term... X-BeenThere: lp-wan@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Low-Power Wide Area Networking \(LP-WAN\), also known as LPWA or Low-Rate WAN \(LR-WAN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 May 2017 17:08:16 -0000 --Apple-Mail=_E7976E12-506A-4680-AD7C-ED13FAF54143 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, I agree that the solution presented in = draft-garcia-radext-radius-lorawan is specific to LoRaWAN. Not = applicable to other radio technologies (i.e. Sigfox as mentioned).=20 Although, the idea of having AAA and its advanced characteristics (e.g., = Identity federation) is the general idea that can be extrapolated to = LPWAN (That was also the idea behind the draft)=20 I understand, at the end, that is the goal. Using AAA or LBES from what = I understand is only nomenclature. Am I wright, or are there other = reasons? If RADIUS or Diameter are not suitable for the task would be an = interesting discussion, as well as analyzing the possible gap in case = there are reasons to change the name, or the concept, beyond = nomenclature.=20 What do you think? Thank you.=20 Best Regards, Dan.=20 > El 18 may 2017, a las 18:01, Juan Carlos Zuniga = escribi=C3=B3: >=20 > Hi, > =20 > I tend to agree with Stephen in that assuming a RADIUS or Diameter = server is not generic enough. Even though a solution like the one = proposed in draft-garcia-radext-radius-lorawan might be suitable for = certain technologies like LoRaWAN, there are other protocols like Sigfox = which don=E2=80=99t have a joining procedure or an authentication = message exchange (i.e. every message is individually authenticated). = Therefore, Stephen=E2=80=99s proposal to use LBES instead of AAA sounds = like a good generic solution. > =20 > Best, > =20 > Juan Carlos > =20 > =20 > From: lp-wan [mailto:lp-wan-bounces@ietf.org] On Behalf Of Arun > Sent: May 18, 2017 11:24 AM > To: lp-wan@ietf.org > Subject: Re: [lp-wan] overview issue#2: AAA server term... > =20 > Hi Stephen,=20 > There is a draft, draft-garcia-radext-radius-lorawan, that explains = the use of AAA server in lpwa technologies like lora.=20 > The idea is to use standardized solutions like AAA for authenticating = end devices in such technologies. > IMHO, AAA term in a way is good to push for the use of standard = entities in the architecture.=20 >=20 > regards, > Arun >=20 > On 18/05/2017 09:41, Stephen Farrell wrote: > =20 > Hiya, > =20 > (Crap: I mucked up the subject line by also calling this "issue#1" > when I first sent this, maybe that's why nobody responded - so > trying now with a correct subject line and with a suggested > resolution in case nobody else cares... :-) > =20 > In [1] we define the term "AAA server." I don't think that's a good > term to use, as it may be read to assume that we'll end up with a > RADIUS or Diameter based solution and a typical AAA server like that > is just not the same as a LoRaWAN NS/JS. (There might be a RADIUS or > Diameter server behind such a beast, but it's not the same thing.) > I think (less sure though) that the "AAA server" is also not so good > for the other technologies too. > =20 > What'd the WG like to do here? > =20 > If nobody answers, in the next revision I'll use the term "LPWAN > back-end server" ("LBES") instead of "AAA server." That's also not > great but at least doesn't have the potential to create new confusion. > =20 > Cheers, > S. > =20 > [1] https://tools.ietf.org/html/draft-ietf-lpwan-overview-02#section-3 = > =20 > =20 > =20 >=20 >=20 >=20 > _______________________________________________ > lp-wan mailing list > lp-wan@ietf.org > https://www.ietf.org/mailman/listinfo/lp-wan = > =20 > _______________________________________________ > lp-wan mailing list > lp-wan@ietf.org > https://www.ietf.org/mailman/listinfo/lp-wan --Apple-Mail=_E7976E12-506A-4680-AD7C-ED13FAF54143 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi,

I agree that the solution presented in = draft-garcia-radext-radius-lorawan is specific to LoRaWAN. Not = applicable to other radio technologies (i.e. Sigfox as = mentioned). 

Although, the idea of having AAA and its advanced = characteristics (e.g., Identity federation) is the general idea that can = be extrapolated to LPWAN (That was also the idea behind the = draft) 

I = understand, at the end, that is the goal. Using AAA or LBES from what I = understand is only nomenclature. Am I wright, or are there other = reasons? If RADIUS or Diameter are not suitable for the task would be an = interesting discussion, as well as analyzing the possible gap in case = there are reasons to change the name, or the concept, beyond = nomenclature. 

What do you think?

Thank you. 
Best Regards,
Dan. 


El 18 may 2017, a las 18:01, Juan Carlos Zuniga <juancarlos.zuniga@sigfox.com> escribi=C3=B3:

Hi,
 
I tend = to agree with Stephen in that assuming a RADIUS or Diameter server is = not generic enough. Even though a solution like the one proposed in = draft-garcia-radext-radius-lorawan might be suitable for certain = technologies like LoRaWAN, there are other protocols like Sigfox which = don=E2=80=99t have a joining procedure or an authentication message = exchange (i.e. every message is individually authenticated). Therefore, = Stephen=E2=80=99s proposal to use LBES instead of AAA sounds like a good = generic solution.
 
Best,
 
Juan = Carlos
 
 
From: lp-wan [mailto:lp-wan-bounces@ietf.org] On Behalf = Of Arun
Sent: May 18, 2017 11:24 AM
To: lp-wan@ietf.org
Subject: Re: [lp-wan] overview = issue#2: AAA server term...
 

Hi Stephen, 
There is = a draft, draft-garcia-radext-radius-lorawan, that explains the use of = AAA server in lpwa technologies like lora. 
The idea is to use = standardized solutions like AAA for authenticating end devices in such = technologies.
IMHO, AAA term in a way is good to push for the use of = standard entities in the architecture. 

regards,
Arun

On 18/05/2017 09:41, = Stephen Farrell wrote:
 
Hiya,
 
(Crap: I mucked up the subject line by also =
calling this "issue#1"
when I first sent this, maybe that's why nobody responded - =
so
trying now with =
a correct subject line and with a suggested
resolution in =
case nobody else cares... :-)
 
In [1] we define the term "AAA server." I =
don't think that's a good
term to use, as it may be read to assume that we'll end up =
with a
RADIUS =
or Diameter based solution and a typical AAA server like that
is just not the =
same as a LoRaWAN NS/JS. (There might be a RADIUS or
Diameter server =
behind such a beast, but it's not the same thing.)
I think (less =
sure though) that the "AAA server" is also not so good
for the other =
technologies too.
 
What'd the WG like to do here?
 
If nobody answers, in the next revision I'll =
use the term "LPWAN
back-end server" ("LBES") instead of "AAA server." That's =
also not
great =
but at least doesn't have the potential to create new confusion.
 
Cheers,
S.
 
[1] https://tools.ietf.org/html/draft-ietf-lpwan-overview-02#sectio=
n-3
 
 
 



_______________________________________________
lp-wan mailing =
list
lp-wan@ietf.org
https://www.ietf.org/mailman/listinfo/lp-wan
 
_______________________________________________
lp-wan mailing list
lp-wan@ietf.org
https://www.ietf.org/mailman/listinfo/lp-wan

= --Apple-Mail=_E7976E12-506A-4680-AD7C-ED13FAF54143-- From nobody Fri May 19 01:49:16 2017 Return-Path: X-Original-To: lp-wan@ietfa.amsl.com Delivered-To: lp-wan@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D756E12EB1A for ; Fri, 19 May 2017 01:49:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 lZJlbX9NoFsm for ; Fri, 19 May 2017 01:49:12 -0700 (PDT) Received: from relay4-d.mail.gandi.net (relay4-d.mail.gandi.net [IPv6:2001:4b98:c:538::196]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63970129C4B for ; Fri, 19 May 2017 01:43:18 -0700 (PDT) Received: from mfilter44-d.gandi.net (mfilter44-d.gandi.net [217.70.178.175]) by relay4-d.mail.gandi.net (Postfix) with ESMTP id AB2FC172144; Fri, 19 May 2017 10:43:16 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter44-d.gandi.net Received: from relay4-d.mail.gandi.net ([IPv6:::ffff:217.70.183.196]) by mfilter44-d.gandi.net (mfilter44-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id 8S8dwSmyWah4; Fri, 19 May 2017 10:43:14 +0200 (CEST) X-Originating-IP: 192.44.77.204 Received: from el-meco.rennes.enst-bretagne.fr (nat-asr-incub-b204.rennes.enst-bretagne.fr [192.44.77.204]) (Authenticated sender: ana@ackl.io) by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id 9291E172178; Fri, 19 May 2017 10:43:13 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Ana Minaburo In-Reply-To: <4921d239-dbab-9ea1-3dbd-66e044bf22ec@cs.tcd.ie> Date: Fri, 19 May 2017 10:43:13 +0200 Cc: lp-wan@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <54E3DA78-D7D4-46BE-B0F6-602304440D4D@ackl.io> References: <149475420158.2867.2858210762450072982@ietfa.amsl.com> <4921d239-dbab-9ea1-3dbd-66e044bf22ec@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [lp-wan] I-D Action: draft-ietf-lpwan-overview-02.txt X-BeenThere: lp-wan@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Low-Power Wide Area Networking \(LP-WAN\), also known as LPWA or Low-Rate WAN \(LR-WAN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 May 2017 08:49:15 -0000 Hello, Do you think you can add the consensus we got in last meeting about for = the section 3 terminology? thanks Ana > On 14 May 2017, at 11:32, Stephen Farrell = wrote: >=20 >=20 >=20 > Hi all, >=20 > I've updated the overview document as planned (well, a week or > two later than planned:-). I still have two open issues that I'd > like to resolve before I'd claim that this is ready for WGLC so > I'll send separate mails on those. >=20 > Other than that, it might be pretty close to ready, though your > comments are welcome of course. (Either on the list or as a PR > to the git repo.) >=20 > Cheers, > S. >=20 > On 14/05/17 10:30, internet-drafts@ietf.org wrote: >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >> This draft is a work item of the IPv6 over Low Power Wide-Area = Networks of the IETF. >>=20 >> Title : LPWAN Overview >> Author : Stephen Farrell >> Filename : draft-ietf-lpwan-overview-02.txt >> Pages : 39 >> Date : 2017-05-14 >>=20 >> Abstract: >> Low Power Wide Area Networks (LPWAN) are wireless technologies with >> characteristics such as large coverage areas, low bandwidth, = possibly >> very small packet and application layer data sizes and long battery >> life operation. This memo is an informational overview of the set = of >> LPWAN technologies being considered in the IETF and of the gaps = that >> exist between the needs of those technologies and the goal of = running >> IP in LPWANs. >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-lpwan-overview/ >>=20 >> There are also htmlized versions available at: >> https://tools.ietf.org/html/draft-ietf-lpwan-overview-02 >> https://datatracker.ietf.org/doc/html/draft-ietf-lpwan-overview-02 >>=20 >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-lpwan-overview-02 >>=20 >>=20 >> 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. >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> _______________________________________________ >> lp-wan mailing list >> lp-wan@ietf.org >> https://www.ietf.org/mailman/listinfo/lp-wan >>=20 >=20 > _______________________________________________ > lp-wan mailing list > lp-wan@ietf.org > https://www.ietf.org/mailman/listinfo/lp-wan From nobody Fri May 19 02:08:15 2017 Return-Path: X-Original-To: lp-wan@ietfa.amsl.com Delivered-To: lp-wan@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55E25129469 for ; Fri, 19 May 2017 02:08:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 kJZ_Y-mXoUVC for ; Fri, 19 May 2017 02:08:12 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58DBD129BB3 for ; Fri, 19 May 2017 02:01:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12828; q=dns/txt; s=iport; t=1495184499; x=1496394099; h=from:to:cc:subject:date:message-id:mime-version; bh=IB84HUbX79khp0YIjCYJOmfAmMjxKh7MXkB/YXd9B2s=; b=QBLn7bcWKGRBvi5vYvofg/lJxps/g/4zJbRfy5blMZGW4fj2cRpRlDQ3 Jr7/0+gRO64BqcgUpI6A7sSCSwn5eLHacm7FqzgBi67pjLVMBrD4FpPGu AjQTiwo2lXRwIRPmwXrPtlel95LIHQiqGexCFZhhc7a+ZfsOfBKIYg5Nl s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ChAACosx5Z/4YNJK1CGgEYAQEBAQEBA?= =?us-ascii?q?QEBAQEHAQEBAQGCbmdigQwHjX+iLoU4gg8uhXaFdj8YAQIBAQEBAQEBayiFTEw?= =?us-ascii?q?SARwcDDwmAQQODYocDjGxD4NVh0gBAQEBAQEBAQEBAQEBAQEBAQEBAQEYBYZfg?= =?us-ascii?q?V6EV4FlgWIugh2CbRoFnhUBhxyLdoINhTyKLokBi0QBHziBCnAVhT0cgWN2AYg?= =?us-ascii?q?OgQ0BAQE?= X-IronPort-AV: E=Sophos;i="5.38,363,1491264000"; d="scan'208,217";a="250347228" Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 19 May 2017 09:01:38 +0000 Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id v4J91cQr013635 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 19 May 2017 09:01:38 GMT Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 19 May 2017 04:01:37 -0500 Received: from xch-rcd-001.cisco.com ([173.37.102.11]) by XCH-RCD-001.cisco.com ([173.37.102.11]) with mapi id 15.00.1210.000; Fri, 19 May 2017 04:01:37 -0500 From: "Pascal Thubert (pthubert)" To: lp-wan CC: Stephen Farrell , Ana Minaburo , Alexander Pelov , Laurent Toutain , Carles Gomez Montenegro Thread-Topic: Agenda, LPWAN Interim meeting, May 24th, 2017 Thread-Index: AdLQfQ7rr1cfSDTzQXWvzwb7vfJseQ== Date: Fri, 19 May 2017 09:01:14 +0000 Deferred-Delivery: Fri, 19 May 2017 09:01:11 +0000 Message-ID: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.228.216.11] Content-Type: multipart/alternative; boundary="_000_aa772ec8ec5a40439e1d2e35c6c6dea1XCHRCD001ciscocom_" MIME-Version: 1.0 Archived-At: Subject: [lp-wan] Agenda, LPWAN Interim meeting, May 24th, 2017 X-BeenThere: lp-wan@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Low-Power Wide Area Networking \(LP-WAN\), also known as LPWA or Low-Rate WAN \(LR-WAN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 May 2017 09:08:14 -0000 --_000_aa772ec8ec5a40439e1d2e35c6c6dea1XCHRCD001ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all: Please find the proposed agenda for next Wednesday; if you have any suggest= ion for a change/addition please let us know in advance: Connection details * IETF link: https://datatracker.ietf.org/meeting/interim-2017-lpwan= -03/session/lpwan * Date: May, 24th, 7-8am US Pacific, 4pm CEST: https://www.worldtime= buddy.com/?qm=3D1&lid=3D100,12,5392171,1850147&h=3D100&date=3D2017-05-24&sl= n=3D14-15 * Webex Link: https://cisco.webex.com/ciscosales/j.php?MTID=3Dme7f53= 6292c568c696a054a7ff7ef0746 * Meeting number (access code): 203 453 401 * Meeting password: chicalors (24422567 from phones) Agenda * [7min] Administrivia o Agenda bashing o Approval minutes from last meeting o Review last interim todos o Terminology * [5 min] LPWAN Overview - update from last meeting (Steve) o Status on Steve's issues on ML o Publication? * [10min] SCHC IP/UDP (Laurent, Ana) * [15min] SCHC CoAP (Laurent) * [15min] Fragmentation (Carles) * [3min] AOB The chairs --_000_aa772ec8ec5a40439e1d2e35c6c6dea1XCHRCD001ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear all:

 

Please find the proposed agenda for next Wednesday; = if you have any suggestion for a change/addition please let us know in adva= nce:

Connection details

·       =  IETF link: https://datatracker.ietf.org/meeting/interim-2017-lpwan-03/session/lpwan

·        Date: May, 24th, 7-8am US Pacific, 4pm CEST:=  https://ww= w.worldtimebuddy.com/?qm=3D1&lid=3D100,12,5392171,1850147&h=3D100&a= mp;date=3D2017-05-24&sln=3D14-15

·       =  Webex Link: = https://cisco.webex.com/ciscosales/j.php?MTID=3Dme7f536292c568c696a0= 54a7ff7ef0746

·       =  Meeting number (a= ccess code): 203 453 401 

·       =  Meeting password:= chicalors (24422567 from phones)

Agenda

·       =  [7min] Administri= via
o   Agenda bashing

o<= span style=3D"font-size:7.0pt">   Approval minutes from last meeting

o&= nbsp; Review last interim todos

o&= nbsp; Terminology

 

·       =  [5 min]  LPW= AN Overview - update from last meeting  (Steve)
o   Status on Steve’s issues on ML
o   Publication?

 

·       =  [10min] SCHC IP/U= DP (Laurent, Ana)

·     =    [15min] SCHC CoAP (Laurent)

·     =    [15min] Fragmentation (Carles)

 

·     =    [3min] AOB

 

The chairs

--_000_aa772ec8ec5a40439e1d2e35c6c6dea1XCHRCD001ciscocom_-- From nobody Fri May 19 02:26:23 2017 Return-Path: X-Original-To: lp-wan@ietfa.amsl.com Delivered-To: lp-wan@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF35512778E for ; Fri, 19 May 2017 02:26:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 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_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 4vp5c5yKWsh5 for ; Fri, 19 May 2017 02:26:16 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BBCC12700F for ; Fri, 19 May 2017 02:20:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id D0B7EBE73; Fri, 19 May 2017 10:20:08 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WJ-BPHF7ei3n; Fri, 19 May 2017 10:20:05 +0100 (IST) Received: from [10.244.2.100] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 1E68DBE55; Fri, 19 May 2017 10:20:05 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1495185605; bh=2VoozGmup5Ki8X8EUZs87utdHFiJsdk6a5tf69ABIlY=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=wr4zQblFy5ewIZwaxUD+MKQ98Vqw0vK8OKT0KIsXH/JP4rBMpl6yWBgd3YB8B3CYq /mUSZ3Td2AGbKqoMRaENHMLP0yr+bM+fDYZwP4zEDopvdVi/QqnxWPyOdeiug9+ks3 MvNmc6dQQBnmzgvnRytU8vkZ3fhgibJCbpwNgo34= To: Ana Minaburo Cc: lp-wan@ietf.org References: <149475420158.2867.2858210762450072982@ietfa.amsl.com> <4921d239-dbab-9ea1-3dbd-66e044bf22ec@cs.tcd.ie> <54E3DA78-D7D4-46BE-B0F6-602304440D4D@ackl.io> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <5918eb97-45f1-b544-7873-8d9899c18586@cs.tcd.ie> Date: Fri, 19 May 2017 10:20:03 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <54E3DA78-D7D4-46BE-B0F6-602304440D4D@ackl.io> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Et7wIfC5UxbnmACDSLCw4FUaA4N2HfgNe" Archived-At: Subject: Re: [lp-wan] I-D Action: draft-ietf-lpwan-overview-02.txt X-BeenThere: lp-wan@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Low-Power Wide Area Networking \(LP-WAN\), also known as LPWA or Low-Rate WAN \(LR-WAN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 May 2017 09:26:20 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Et7wIfC5UxbnmACDSLCw4FUaA4N2HfgNe Content-Type: multipart/mixed; boundary="8707wmNpd5IjgcdQLKTNLqjQDisA5lmJI"; protected-headers="v1" From: Stephen Farrell To: Ana Minaburo Cc: lp-wan@ietf.org Message-ID: <5918eb97-45f1-b544-7873-8d9899c18586@cs.tcd.ie> Subject: Re: [lp-wan] I-D Action: draft-ietf-lpwan-overview-02.txt References: <149475420158.2867.2858210762450072982@ietfa.amsl.com> <4921d239-dbab-9ea1-3dbd-66e044bf22ec@cs.tcd.ie> <54E3DA78-D7D4-46BE-B0F6-602304440D4D@ackl.io> In-Reply-To: <54E3DA78-D7D4-46BE-B0F6-602304440D4D@ackl.io> --8707wmNpd5IjgcdQLKTNLqjQDisA5lmJI Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable Hiya, On 19/05/17 09:43, Ana Minaburo wrote: > Hello, >=20 > Do you think you can add the consensus we got in last meeting about for= the section 3 terminology? >=20 Sure. What text would you like? (*) Cheers, S. (*) Ideally, via a PR for [1] but however you prefer is fine. [1] https://github.com/sftcd/lpwan-ov > thanks > Ana >=20 >> On 14 May 2017, at 11:32, Stephen Farrell = wrote: >> >> >> >> Hi all, >> >> I've updated the overview document as planned (well, a week or >> two later than planned:-). I still have two open issues that I'd >> like to resolve before I'd claim that this is ready for WGLC so >> I'll send separate mails on those. >> >> Other than that, it might be pretty close to ready, though your >> comments are welcome of course. (Either on the list or as a PR >> to the git repo.) >> >> Cheers, >> S. >> >> On 14/05/17 10:30, internet-drafts@ietf.org wrote: >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts di= rectories. >>> This draft is a work item of the IPv6 over Low Power Wide-Area Networ= ks of the IETF. >>> >>> Title : LPWAN Overview >>> Author : Stephen Farrell >>> Filename : draft-ietf-lpwan-overview-02.txt >>> Pages : 39 >>> Date : 2017-05-14 >>> >>> Abstract: >>> Low Power Wide Area Networks (LPWAN) are wireless technologies with= >>> characteristics such as large coverage areas, low bandwidth, possib= ly >>> very small packet and application layer data sizes and long battery= >>> life operation. This memo is an informational overview of the set = of >>> LPWAN technologies being considered in the IETF and of the gaps tha= t >>> exist between the needs of those technologies and the goal of runni= ng >>> IP in LPWANs. >>> >>> >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-lpwan-overview/ >>> >>> There are also htmlized versions available at: >>> https://tools.ietf.org/html/draft-ietf-lpwan-overview-02 >>> https://datatracker.ietf.org/doc/html/draft-ietf-lpwan-overview-02 >>> >>> A diff from the previous version is available at: >>> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-lpwan-overview-02 >>> >>> >>> Please note that it may take a couple of minutes from the time of sub= mission >>> 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/ >>> >>> _______________________________________________ >>> lp-wan mailing list >>> lp-wan@ietf.org >>> https://www.ietf.org/mailman/listinfo/lp-wan >>> >> >> _______________________________________________ >> lp-wan mailing list >> lp-wan@ietf.org >> https://www.ietf.org/mailman/listinfo/lp-wan >=20 > _______________________________________________ > lp-wan mailing list > lp-wan@ietf.org > https://www.ietf.org/mailman/listinfo/lp-wan >=20 --8707wmNpd5IjgcdQLKTNLqjQDisA5lmJI-- --Et7wIfC5UxbnmACDSLCw4FUaA4N2HfgNe Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZHrjEAAoJEC88hzaAX42iZMcIAJdzbQhA9s0taH7WFvsNMK/k JG/hIoddahNWr5zIPXGr6+BnvtolH6YdexfFQXpKbe4IY5xannST+jWxqqAd6nKX 9z5mlcPSUlspdBVSHqsbxExIo11dnlzNvGs1AkEOmR4o3c+KK4dd0UCprKzAkgnV tL1ErKLZUV0cV24z81xbXSQAv0EBshMiWb4DOMN92AhsSu5oZzxgE8pUUhXgPP+4 hpD19vLXhvwtIVbCumnYqaLJ6Eskx6BpHootqGFtAJ2yCKhILvhK7gpDIZT01NBj K+ErajPNlTK9O4fsM2hkfQ9gD3d9pPSDo1oXPoGFO2o0dn/BF63Xfl5x0QypQkM= =KRe5 -----END PGP SIGNATURE----- --Et7wIfC5UxbnmACDSLCw4FUaA4N2HfgNe-- From nobody Fri May 19 02:42:20 2017 Return-Path: X-Original-To: lp-wan@ietfa.amsl.com Delivered-To: lp-wan@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B37E912EB6E for ; Fri, 19 May 2017 02:42:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 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_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 Le5Pw8XN6Y8u for ; Fri, 19 May 2017 02:42:15 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D403D12EB83 for ; Fri, 19 May 2017 02:35:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 60911BE5C; Fri, 19 May 2017 10:35:17 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CCQSjyeU6wMq; Fri, 19 May 2017 10:35:15 +0100 (IST) Received: from [10.244.2.100] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 282EABE5B; Fri, 19 May 2017 10:35:15 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1495186515; bh=0PeNzX2uBDP2jyDGXLU1raGVF9DRHT4lxYeTaMyXJWY=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=HiJwTPRqnsl8ILY/M4LAxTVc2GqSseJzNJhwjff7S3uB7OW4FDcDRuF0y8rCtLrzq oxSIWS78wXd8y0W71a4Qq8L0Yv2VfJ8YrZ/iYIAb+y7jCGPhnznvCMruKbeg2oO7gr ItnAO4BNE/x0zgbCLhY7nPhoEZF6WaPUTkOPjgDE= To: =?UTF-8?Q?Dan_Garc=c3=ada_Carrillo?= , Juan Carlos Zuniga Cc: "lp-wan@ietf.org" , Arun References: <6a4c386b-4b23-569f-c32a-09d546e7e681@cs.tcd.ie> <1fec4a42-3477-d8c1-ce6d-d2d8cd4b568c@acklio.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: Date: Fri, 19 May 2017 10:35:14 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="OOQJTcd8VOb0xAHvv1xuQbqPIKnWqDG0R" Archived-At: Subject: Re: [lp-wan] overview issue#2: AAA server term... X-BeenThere: lp-wan@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Low-Power Wide Area Networking \(LP-WAN\), also known as LPWA or Low-Rate WAN \(LR-WAN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 May 2017 09:42:19 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --OOQJTcd8VOb0xAHvv1xuQbqPIKnWqDG0R Content-Type: multipart/mixed; boundary="mVgGwgkbdK9f0xlaPajnB6WLStcLNjIHA"; protected-headers="v1" From: Stephen Farrell To: =?UTF-8?Q?Dan_Garc=c3=ada_Carrillo?= , Juan Carlos Zuniga Cc: "lp-wan@ietf.org" , Arun Message-ID: Subject: Re: [lp-wan] overview issue#2: AAA server term... References: <6a4c386b-4b23-569f-c32a-09d546e7e681@cs.tcd.ie> <1fec4a42-3477-d8c1-ce6d-d2d8cd4b568c@acklio.com> In-Reply-To: --mVgGwgkbdK9f0xlaPajnB6WLStcLNjIHA Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable Hiya, On 18/05/17 18:02, Dan Garc=C3=ADa Carrillo wrote: > Hi, >=20 > I agree that the solution presented in > draft-garcia-radext-radius-lorawan is specific to LoRaWAN. Not > applicable to other radio technologies (i.e. Sigfox as mentioned). >=20 > Although, the idea of having AAA and its advanced characteristics > (e.g., Identity federation) is the general idea that can be > extrapolated to LPWAN (That was also the idea behind the draft) >=20 Well, in terms of RFC2904 (not that that should be considered that authoratitive), the thing about which we're talking is just called the "service equipment." And that's about right, a LoRaWAN NS/JS is not (architecturally) a AAA server in my mind, a AAA server is a more generic entity that is not specific to the radio technology in use. In saying that it's also true that the LoRaWAN NS/JS interaction is very similar to one part of what we do with RADIUS/Diameter, so the ideas in draft-garcia-radext-radius-lorawan are not crazy at all. > I understand, at the end, that is the goal. Using AAA or LBES from > what I understand is only nomenclature.=20 Yep. This isn't a hill on which anyone ought want to die:-) > Am I wright, or are there > other reasons? If RADIUS or Diameter are not suitable for the task > would be an interesting discussion, as well as analyzing the possible > gap in case there are reasons to change the name, or the concept, > beyond nomenclature. IMO Diameter or RADIUS are fine protocols one might well use talk to a AAA server from an "LBES" (or whatever we end up calling it). Cheers, S. >=20 > What do you think? >=20 > Thank you. Best Regards, Dan. >=20 >=20 >> El 18 may 2017, a las 18:01, Juan Carlos Zuniga >> escribi=C3=B3: >>=20 >> Hi, >>=20 >> I tend to agree with Stephen in that assuming a RADIUS or Diameter >> server is not generic enough. Even though a solution like the one >> proposed in draft-garcia-radext-radius-lorawan might be suitable >> for certain technologies like LoRaWAN, there are other protocols >> like Sigfox which don=E2=80=99t have a joining procedure or an >> authentication message exchange (i.e. every message is individually >> authenticated). Therefore, Stephen=E2=80=99s proposal to use LBES inst= ead >> of AAA sounds like a good generic solution. >>=20 >> Best, >>=20 >> Juan Carlos >>=20 >>=20 >> From: lp-wan [mailto:lp-wan-bounces@ietf.org] On Behalf Of Arun=20 >> Sent: May 18, 2017 11:24 AM To: lp-wan@ietf.org Subject: Re: >> [lp-wan] overview issue#2: AAA server term... >>=20 >> Hi Stephen, There is a draft, draft-garcia-radext-radius-lorawan, >> that explains the use of AAA server in lpwa technologies like lora. >> The idea is to use standardized solutions like AAA for >> authenticating end devices in such technologies. IMHO, AAA term in >> a way is good to push for the use of standard entities in the >> architecture. >>=20 >> regards, Arun >>=20 >> On 18/05/2017 09:41, Stephen Farrell wrote: >>=20 >> Hiya, >>=20 >> (Crap: I mucked up the subject line by also calling this "issue#1"=20 >> when I first sent this, maybe that's why nobody responded - so=20 >> trying now with a correct subject line and with a suggested=20 >> resolution in case nobody else cares... :-) >>=20 >> In [1] we define the term "AAA server." I don't think that's a >> good term to use, as it may be read to assume that we'll end up >> with a RADIUS or Diameter based solution and a typical AAA server >> like that is just not the same as a LoRaWAN NS/JS. (There might be >> a RADIUS or Diameter server behind such a beast, but it's not the >> same thing.) I think (less sure though) that the "AAA server" is >> also not so good for the other technologies too. >>=20 >> What'd the WG like to do here? >>=20 >> If nobody answers, in the next revision I'll use the term "LPWAN=20 >> back-end server" ("LBES") instead of "AAA server." That's also not=20 >> great but at least doesn't have the potential to create new >> confusion. >>=20 >> Cheers, S. >>=20 >> [1] >> https://tools.ietf.org/html/draft-ietf-lpwan-overview-02#section-3 >> >> >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ lp-wan mailing >> list lp-wan@ietf.org =20 >> https://www.ietf.org/mailman/listinfo/lp-wan >> >>=20 >> _______________________________________________ lp-wan mailing >> list lp-wan@ietf.org https://www.ietf.org/mailman/listinfo/lp-wan >=20 >=20 >=20 >=20 > _______________________________________________ lp-wan mailing list=20 > lp-wan@ietf.org https://www.ietf.org/mailman/listinfo/lp-wan >=20 --mVgGwgkbdK9f0xlaPajnB6WLStcLNjIHA-- --OOQJTcd8VOb0xAHvv1xuQbqPIKnWqDG0R Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZHrxSAAoJEC88hzaAX42iuzcIAKYdrtKCi5heZ83PrTFuMsch tC+1FJSfnvw5QllxjPRh6l7Jhru7IW4NtvtVXs+/Tj6Wrob4clQEjJfU0JP6l95p gJC34Jnu+Isrt8ro9jbxicRV9F+TOpEKclxh8abwit5DBIGT/nGublYx037E7qrw OjhD8FLUXyyvuC8E/wZC6/VXijc530ERhAD75ikWix+GQTQBN1WClqW1E9cLjcUP L9vqN/NBxnrs/xCOVTQ9ZRIS9FBkE1/2MLOReREw5ANkKIYKb+KVIPQZwxf23fGN dGFHup6RrEuY7NSRS4M7dzF2UaWH1CvYHDh+rlEeb2zDvB5WTUlcC/aF2CZtlqM= =sBGQ -----END PGP SIGNATURE----- --OOQJTcd8VOb0xAHvv1xuQbqPIKnWqDG0R-- From nobody Fri May 19 05:58:49 2017 Return-Path: X-Original-To: lp-wan@ietfa.amsl.com Delivered-To: lp-wan@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40CD6126D05 for ; Fri, 19 May 2017 05:58:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.602 X-Spam-Level: X-Spam-Status: No, score=-1.602 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 GPAZ2Blds4lm for ; Fri, 19 May 2017 05:58:45 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 315A212ECBD for ; Fri, 19 May 2017 05:52:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id C3C91BEBB for ; Fri, 19 May 2017 13:52:07 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s-2eFiUTwdRi for ; Fri, 19 May 2017 13:52:06 +0100 (IST) Received: from [10.244.2.100] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 1272BBEB3 for ; Fri, 19 May 2017 13:52:05 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1495198326; bh=Y8Cz223GNEX755a/lv3IuEUqbyZyOVpPqr0xUQ3SYhs=; h=To:From:Subject:Date:From; b=D7fMPOSu0PGqR87GXcKCZVSwzTJtKgLwdaRGSd5O720zNvV+LTFfa/cgyP9BBrCtI X4/OxNL0715xhV0OddexpiZD4AfbSu8pgb6+gwsi9QL+UNDNiKTlHJR/88/g6PkMY7 402pqxAy0tFJin4gJB5eEnXMVjtd5TP+TOwl378s= To: lp-wan From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <9c35cc58-b438-1697-85f3-1e6980d5d30e@cs.tcd.ie> Date: Fri, 19 May 2017 13:52:05 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="v92Alfjil6S8wDicQlHXmp8Ll32uAMCPL" Archived-At: Subject: [lp-wan] overview doc - edits about nbiot merged... X-BeenThere: lp-wan@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Low-Power Wide Area Networking \(LP-WAN\), also known as LPWA or Low-Rate WAN \(LR-WAN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 May 2017 12:58:48 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --v92Alfjil6S8wDicQlHXmp8Ll32uAMCPL Content-Type: multipart/mixed; boundary="32JL3BM6SCkcL0IS0gPHDSwH0w2NimC6f"; protected-headers="v1" From: Stephen Farrell To: lp-wan Message-ID: <9c35cc58-b438-1697-85f3-1e6980d5d30e@cs.tcd.ie> Subject: overview doc - edits about nbiot merged... --32JL3BM6SCkcL0IS0gPHDSwH0w2NimC6f Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable Hiya, Just for the record: Antti created a PR [1] with a bunch of nbiot changes that I've merged. I gave 'em a quick check and didn't see anything that'd need WG consensus but do let me know if I missed anything. (Thanks Antti for making the editor's life easier by doing that via a PR:-) For anyone not already used to github: these changes will be in the next revision of the draft, assuming nobody has a problem with 'em. You can always check out the editor's latest version at [2]. Cheers, S. [1] https://github.com/sftcd/lpwan-ov/pull/4 [2] https://github.com/sftcd/lpwan-ov/blob/master/draft-ietf-lpwan-overview.t= xt --32JL3BM6SCkcL0IS0gPHDSwH0w2NimC6f-- --v92Alfjil6S8wDicQlHXmp8Ll32uAMCPL Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZHup1AAoJEC88hzaAX42iXpgH/232OyxTVtgeM8cAXCFCMzd/ PTqdZf+/P4r3LS6g5r1ezSzZDGrKsM5DVwC6ChKkeZBlZOjBCBn9rbbatv4DnRPQ aOyOnOiOG/Pb5JJbco4es58c/59r1aSe/43s4U9XI1b1Zgv2b9L8FTzsNzPZvfKP HBuei6lHqvDg/KqKThDN4nLC5v9L4HgZEez/Mw4tWmaj71ggr2F//M0b6ZPiaCpJ HMOINP6XsEfKs/NVcfK3WMi7KkkYb4PYHpnCNYlPsFC0Nd68NmRp+YApJcxsghN3 /rVxMH283Li/YTb/4YNR0LECRVgXLUMOfcePwAEdfj0ic1gEBbA0KbTK4P9n3PY= =k+4I -----END PGP SIGNATURE----- --v92Alfjil6S8wDicQlHXmp8Ll32uAMCPL-- From nobody Sun May 21 19:35:33 2017 Return-Path: X-Original-To: lp-wan@ietfa.amsl.com Delivered-To: lp-wan@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 824EE129AE7 for ; Sun, 21 May 2017 19:35:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.588 X-Spam-Level: X-Spam-Status: No, score=-2.588 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mail-udp-cl.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 847_K2TG_wjU for ; Sun, 21 May 2017 19:35:29 -0700 (PDT) Received: from mail-yw0-x22d.google.com (mail-yw0-x22d.google.com [IPv6:2607:f8b0:4002:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E797A129404 for ; Sun, 21 May 2017 19:35:28 -0700 (PDT) Received: by mail-yw0-x22d.google.com with SMTP id b68so53899406ywe.3 for ; Sun, 21 May 2017 19:35:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mail-udp-cl.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=6HTbuoygk7a/sN5GIER5s3YK+U7tQNF0MFoflop2TyQ=; b=hdJlwRH0r6BztVrwaZQ5PYZIF7DYk7MwbQOglRsUYg9fIGwVT0Wnnbk1KzZjquxRpH yYGknTEFrkjJJEKhKP7IY1L/mX6q2Qr1JK+ubXp5xi/Xtr0YSwicniGl0DTxNnkxUnEr fYZFTvbImGEXLJa/Rq9OVilbBmP9Ot81iLeF0sI680hplLcCAMz0IrhcIPdTgo+xL5fp MkAQFwunqbuNShRFYTdas/ET9nveDLkWDQ1Va9wDr94xYFAhebWoeWWbh6vGYvIJ+0Wg Uv3C0O/GUgAbZnMdKIKsc4ri/OMaUCb2JJdFO25EHIFo7i6i5lggt4ITQusBvizNWY93 1FrQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=6HTbuoygk7a/sN5GIER5s3YK+U7tQNF0MFoflop2TyQ=; b=ddVL8Z4B3pmYEMbQ2ytoXwIC9RwWYyt+lJDpcJHjR2RnMhFj5M/IM9HLfiesirlWp/ yycEnJfbMp3G8yeV3EedEnyZ+b4rZFBcBOvowQikNBZsN2J5RgsTQiSRp2++TreJxsON L/Zg2Cb6sGJQ7FbyEhHlIjLwq4u9RLDp1PH1mSfuOlLE8e+Ktm1McX7kxcieN5u7UUBV QVkUvJdeyZJrrV6w6X25vux20LteD3QNilFUit+exgtkkQkl8GOqZQEWF+jCTPaKNRpW Scd9VeVaCy9rrqyfDjGUCTh+IfuuKLH+pn245er4DhZz7de7lb86Ytfo4iP21clWehjX BIOg== X-Gm-Message-State: AODbwcArQi3M79vvLCbV21qPSLFcivExKJx/isrlux8wxWYRCYOb8XAM GTO9HmaN4jvjjTPbwaKvTJISSobggzrD7nQ= X-Received: by 10.13.215.148 with SMTP id z142mr18569512ywd.170.1495420527457; Sun, 21 May 2017 19:35:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.233.135 with HTTP; Sun, 21 May 2017 19:35:06 -0700 (PDT) From: "Prof. Diego Dujovne" Date: Sun, 21 May 2017 22:35:06 -0400 Message-ID: To: lp-wan Content-Type: multipart/alternative; boundary="94eb2c075a60546106055013b906" Archived-At: Subject: [lp-wan] Review of draft-ietf-lpwan-ipv6-static-context-hc-03 X-BeenThere: lp-wan@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Low-Power Wide Area Networking \(LP-WAN\), also known as LPWA or Low-Rate WAN \(LR-WAN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 May 2017 02:35:33 -0000 --94eb2c075a60546106055013b906 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear all, I post here the review of draft-ietf-lpwan-ipv6-static-context-hc-03 from the beginning until Section 7 (included). I will go on with the remaining part of the draft in the following days. Regards, Diego Abstract - "Static context means that information stored in the context which, describes field values," I would take out the first comma. - "does not change during the packet transmission" I would remove "the" - " Similar mechanisms for other protocols such as CoAP will be described in a separate document." I would put "separate documents" since you are talking about other protocols, no only CoAP. - "the L2 pdu size" I would put PDU with capital letters. Introduction - "Topology is star oriented, therefore all the packets follow the same path." First, I would add a hyphen: star-oriented. Second, there is no specific discussion if stars of stars will ever be supported, or if this draft only applies to a star topology. In this case, star-oriented can be both star of stars and star. - "SCHC uses a context where header information is kept in order." Is there any other scheme where the header information is not kept in order= ? - "(the values on the header fields do not change during time)" I would suggest "do not change over time" The introduction does not introduce fragmentation as the abstract does. - "The SCHC header compression is indedependent" Typo: independent. - "On the other hand," Is it needed the "On the one hand" statement previously to use this expression? - "not support layer two fragmentation" This is not coherent with the notation on the abstract -> change to L2. Just for the sake of clarity, from the introduction, I can deduce this draft only concentrates on a protocol and a mechanism. The protocol is SCHC and the mechanism is Fragmentation. The protocol usage is justified by two properties of LPWANs and the mechanism is justified by the lack of support on part of the LPWAN technologies. Vocabulary -"Vocabulary" Isn't this "Terminology"? - "DEV: Device. Node connected to the LPWAN. A DEV may implement SCHC." I can conclude that devices with and without SCHC can coexist. This should be mentioned on the Introduction. - "An application sending/consuming IPv6" AFAIK, the term "consumer" comes from the Content-Centric Networking environment; I think this should be changed to "receiving", or, the other way round, "sending/consuming" should be changed to "producing/consuming", just to keep coherence. - "flow. Rule ID is sent on the LPWAN." "The Rule ID is"... - "MO: Matching Operator. An operator used to compare a value contained in a header field with a value contained in a rule." - "TV: Target value. A value contained in the rule that will be matched with the value of a header field." Does the matching operator compare the Target Value (TV) with the value of the header field? I think it would be better to use the terminology already on MO. Do you use "match" and "compare" as synonyms? Static Context Header Compression - "compression mechanisms such as RoHC." This is the first time RoHC appears on the text. Can you put a reference to the corresponding RFC? - "provisionning protocol" provisioning - From figure 1, The Radio Gateway was not defined on the local Terminology, while the rest of the used blocks is defined there. - "applications which produce IPv6" Here the term producer is used as I mentioned before. Maybe the idea to "produce" is better than to "send" flows. - "the headers size" I would keep here "header size" as a generic expression. - "shares the same rules with the DEV" Then, on Figure 1 it should say "DEV" instead of "DEVICE" - " or in another places" I would write "or in another place" or in "or in another intermediate place= " - "if a tunnel is established between the NGW and the SCHC C/D" I would write "as long as a tunnel is" I think it shows better the need to put a tunnel because of the placement of the SCHC C/D far away from the NGW. The "if" statement makes me understand that the tunnel was before the SCHC C/D location and not as a consequence of this action. - "This architecture forms a star topology." This architecture is applicable only to a star topology. Is the star topology a consequence of SCHC? - "After decompression, the packet can be sent on the Internet to one or several LPWAN Application Servers (APP)." On this stage, the packet is rebuilt according to the IPv6 structure. The draft does not mention any multicast capability or if the resulting packets will be unicast only. If one or many application servers can be reached, this should be specified. - "The principle is exactly the same in the other direction." This means that unicast or multicast are possible towards the node side. - "field identifier (FID), a field position (FP), a direction indicator (DI)" Although it is defined just after, this should be on the terminology too, as the other terms used on the draft. - " Figure 2: Compression Decompression Context" To be coherent to the rest of the text, this should be "Compression/Decompression" - "the description of the header field must be done in the same order they appear in the packet." "must be executed in the same order that appears on the packet" I think that it must be said somewhere that both the SCHC Compressor / Decompressor MUST share the same set of rules. - "On the other hand, the rule describes the compressed header which are transmitted regarding their position in the rule which is used for data serialization on the compressor side and data deserialization on the decompressor side." "describes the compressed header which is" - "Regarding their" Who are they? I do not understand what can be in a different order than the order established by the packet header. Being the SCHC C/D, I will not understand what to decompress and how if the order is changed. - "The main idea of the compression scheme is to send the rule id to the other end instead of known field values. When a value is known by both ends, it is not necessary to send it on the LPWAN network." I think this is the key to this draft. This should be on the introduction/abstract too. - "A Field Position (FP) indicating if several instances of the field exist in the headers which one is targeted." This expression is not clear. I imagine that this is an index to reference each of the instances of the field. - "A Target Value (TV) is the value used to make the comparison with the packet header field. The Target Value can be of any type (integer, strings,...). It can be a single value or a more complex structure (array, list,...). It can be considered as a CBOR structure." Here I have a conflict on the idea of header field and value. I can interpret that the intention is that a field has a value and the target value is compared against the field value, and not the name of the field. But it needs to be rewritten. When is it going to be represented as a CBOR structure and when not? Is there a bit for each field on each rule saying so? If not, it is not clear when to interpret it as a CBOR structure and when not. This applies to all the cases when the text says CBOR can be used. Another general question is why it is specified that the TV, MO and CDA may require some parameters which can be CBOR: Are these parameters specified on this draft or in any other draft? If they are, they should be referenced. On the end of section 4 there are a number of parameters specified, but none of them are defined if they are CBOR or n= ot. - "The size of the rule ID is not specified in this document and can vary regarding the LPWAN technology, the number of flows,..." This text must state that the rule ID value is implementation-specific. If there are no more items to add at the end, it is better to replace the "..." with "among others". - "Some values in the rule ID space may be reserved for goals other than header compression, for example fragmentation." Fragmentation was added to this draft recently. It can be specified here if there are any Rule IDs reserved for fragmentation and remove the example. Packet processing - "(excluding unappropriate direction or position)" The text before this expression says that the matching is done using direction and position, and this excludes this from the comparison (saying even unapproriate direction or position will match). If this is not the correct interpretation, it is misleading. - "In the downstrean direction, the rule is also used to find the device ID." Better to add "as explained on section 5.5 - "sent in the first byte of the L2 payload." This is the first limitation: It must be said here that, if there are compressed values to include in the payload, they MUST use, at most 1 byte. Is it the correct way to interpret this limitation? - "associates these values to header fields" Which values? It may better to write: "associates the values to header fiel= ds" Matching operators - "This document describes basic matching operators" "This section describes"... - "SCHC C/D, endpoints" Eliminate the comma. - "equal: a field value in a packet matches with a field value in a rule if they are equal" Is any of those values a TV? - "MSB(length): a field value of a size equal to "length" bits in a packet matches with a field value in a rule if the most significant "length" bits are equal." Can this be rewritten to: "TV where the MSBs match the MSBs of the field value on a rule" ? Am I missing something? - "match-mapping: The goal of mapping-sent is to reduce" mapping-sent is defined after as an action. It may be better to write "The goal of match-mapping is"... Furthermore, it must be said that the field values MUST be unique, or that the it matches the first occurrence, in order to avoid ambiguities. - "Matching Operators and match-mapping needs" match-mapping is a matching operator: "Matching operators need" - "Figure 4: Compression and Decompression Functions" Are tables used or only figures? This should be a Table. - "may be sent with the compressed header." How to add the field size on the compressed header? - "for that field on which compression is applied." "for the field"... - "number of bit sent" number of bits sent - "Compute-*" Is not on the table. (Figure 4) - "These functions are used by the decompressor" I think it may be better to rewrite it as: "This class of functions is used by the decompressor"... - "during the compression and reconstructed during the decompression." Remove "the" on both instances. - "compute a checksum from the information already received by the SCHC C/D= " "compute the checksum". "a checksum" is too generic. Also "the information" is too generic. Is it the packet? Application to IPv6 and UDP headers -"CDA must be "not-sent." Double quote is missing. - "the first one there is without compression and the original value is sent, or the sencond where the values can be computed by sending only the LSB bits:" "the first one is not to use compression, thus the original"... change "sencond" for "second" - "TV is not set" Does this mean it is empty? - "The SCHC C/D recompute the original" "recomputes" - "If the payload is small" It is not clear what is small: there may be gain even with a 15-bit payload length, however, the packet becomes too long and will need fragmentation. - "since there is no IP forwarding between the DEV and the SCHC C/D" However, the Hop limit can be set by the DEV to forward a packet towards beyond the SCHC C/D to any value. - "For privacy reasons or if the DEV address is changing over time, it maybe better to use a static value." This means that there is an internal mapping function that matches the static value to each of the addresses the DEV acquires over time. - "the list of possible IID" "IIDs" - "CDF is set to LSB" I think it is "CDA" instead of "CDF". - "If both ends knows the port number" "know" - "(such as in the LPWAN fragmentation process (see XXXX))" Now that fragmentation is included on the draft, XXXX can be changed to "Section 8" Examples - "when such technologie are used" "technologies" - "the three rules Figure 6" "the three rules depicted on Figure 6" -- DIEGO DUJOVNE Profesor Asociado Escuela de Inform=C3=A1tica y Telecomunicaciones Facultad de Ingenier=C3=ADa - Universidad Diego Portales - Chile www.ingenieria.udp.cl (56 2) 676 8125 --94eb2c075a60546106055013b906 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear all,=
=C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0I post here the review of=C2=A0draft-iet= f-lpwan-ipv6-static-context-hc-03
from the beginning until Section 7 (included). I will g= o on with the remaining part of
the draft in the following days.
Regards,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Diego



Abstract

- "<= span style=3D"color:rgb(0,0,0);white-space:pre-wrap">Static context means that informatio= n stored in the context which, describes field values," =

I would take out the first comma.

- "does not change during the packet transmission"

I would remove "the"

- " Similar mechanisms for other protocols such as CoAP will be described i= n a separate document."

I would put "sepa= rate documents" since you are talking about other protocols, no only C= oAP.

- "the L2 pdu size"

I woul= d put PDU with capital letters.


<= /div>

Introduction
= - "Topology is star oriented, = therefore all the packets follow the same path."

First, I w= ould add a hyphen: star-oriented.
Second, there is no specific discussion if stars of stars will ever= be supported, or if this draft only applies to a star topology. In this ca= se, star-oriented can be both star of stars and star.

- "SCHC uses a context where header information is kept in<= span style=3D"color:rgb(0,0,0);white-space:pre-wrap"> order." <= /font>

Is there any other scheme where the h= eader information is not kept in order?

- =C2=A0"(the values on the header fields do not change during time)"

I would suggest "do not change over time"<= /font>

The introduction does n= ot introduce fragmentation as the abstract does.

- "The SCHC header compression is indedependent"

Typo: independent.

- "On the ot= her hand,"

<= /span>
Is it needed the "On the one = hand" statement previously to use this expression?
=

- "not support layer two fragmentation"
=

This is not coherent with the notation on the abstract -> change t= o L2.

Just for the sake of clarity, from the intro= duction, I can deduce this draft only concentrates on a protocol and a mech= anism. The protocol is SCHC and the mechanism is Fragmentation. The protocol usage is jus= tified by two properties of LPWANs and the mechanism is justified by the la= ck of support on part of the LPWAN technologies.

Vocabular= y
-"=
;Vocabulary"
Is=
n't this "Terminology"?
- "DEV: Device.  Node connected to the LPWAN.  A DEV=
 may implement SCHC."
I can conclude that devices with and without SCHC can coexist. This =
should be mentioned on the Introduction.
- "An application sending/consuming IPv6"
AFAIK, the term "=
consumer" comes from the Content-Centric Networking environment; I thi=
nk this should be changed to "receiving", or, the other way round=
, "sending/consuming" should be changed to "producing/consum=
ing", just to keep coherence. 
- "flow.  Rule ID is sent on the LPWAN."
"The Rule ID is"..=
.
- "MO: Matchi=
ng Operator.  An operator used to compare a value contained in a header fie=
ld with a value contained in a rule." 
- "TV: Target value.  A value contained in the=
 rule that will be      matched with the value of a header field."
Does the matching opera=
tor compare the Target Value (TV) with the value of the header field? I thi=
nk it would be better to use the terminology already on MO. Do you use &quo=
t;match" and "compare" as synonyms?

Static Context Header Compression

- "compression mechanisms such as RoHC." 

This is the first time RoHC appears on th=
e text. Can you put a reference to the corresponding RFC?
=

- "provisionning protocol"

provisioning

= - From figure 1,

The Radio Gateway = was not defined on the local Terminology, while the rest of the used blocks= is defined there.

- "applicati= ons which produce IPv6"

Here = the term producer is used as I mentioned before. Maybe the idea to "pr= oduce" is better than to "send" flows.

=
- "the headers size"

I would keep here "header size" as a generic express= ion.

= - "shares the same rules w= ith the DEV"

Then, on Figure 1 = it should say "DEV" instead of "DEVICE"
- " or in another places"
I would write "or in another place" or in= "or in another intermediate place"

<= /div>
- "if a tunnel is established between the NGW and the SCHC C= /D"

I would write "as long= as a tunnel is" I think it shows better the need to put a tunnel beca= use of the placement of the SCHC C/D far away from the NGW. The "if&qu= ot; statement makes me understand that the tunnel was before the SCHC C/D = location and not as a consequence of this action.

=
- "This architecture forms a star topology."

This architecture is applicable only t= o a star topology. Is the star topology a consequence of SCHC?
=

- "After decompression, the packet can be s= ent on the Internet to one or several LPWAN Application Servers (APP)."= ;

On this stage, the packet is rebui= lt according to the IPv6 structure. The draft does not mention any multicas= t capability or if the resulting packets will be unicast only. If one or ma= ny application servers can be reached, this should be specified.

- "The principle is exactly the same in t= he other direction."
<= font face=3D"arial, helvetica, sans-serif">
This means= that unicast or multicast are possible towards the node side.
=

- "field identifier (FID), a field position= (FP), a direction indicator (DI)"

=
Although it is defined just after, this should be on the terminology t= oo, as the other terms used on the draft.

- " Figure 2: Compression Decompression Context" <= /div>

To be coherent to the rest of the text, t= his should be "Compression/Decompression"

<= /font>
- "the description of the header field must be done i= n the same order they appear in the packet."

"must be executed in the same order that appears on the = packet"

I think that it must be= said somewhere that both the SCHC Compressor / Decompressor MUST share the= same set of rules.

- "On the other hand, the rule describes the comp= ressed header which are
   the decompressor s=
ide."

"describes th= e compressed header which is"

-= "Regarding their"

Who a= re they?

I do not understand what ca= n be in a different order than the order established by the packet header. = Being the SCHC C/D, I will not understand what to decompress and how if th= e order is changed.

- "The main idea of the compression scheme is to = send the rule id to the

I think this is the key to this draft. This should =
be on the 
introduction/abstr=
act too.

- "A Field Position (F=
P) indicating if several instances of the field
      exist in the headers which one is targeted."
<= div style=3D"white-space:pre-wrap">
This expression is not clear. I imagine t=
hat this is an index to
<=
font face=3D"arial, helvetica, sans-serif">reference each of the instances =
of the field.

- "A Target =
Value (TV) is the value used to make the comparison with
      the packet header field.  The Target Value can be of any type
      (integer, strings,...).  It can be a single value or a more
      complex structure (array, list,...).  It can be considered as a
      CBOR structure."

Her=
e I have a conflict on the idea of header field and value. I can 
interpret that the intention is that a field has a value and 
the target value is compared against the field value, and n=
ot the
name of the field. But it needs to be rewritten.<=
/font>
When is it going to be represented as a CBOR structure a=
nd when not?
Is there a bit for each field on each rul=
e saying so? If not, it is
not clear when to interpret=
 it as a CBOR structure and when not. This
applies to al=
l the cases when the text says CBOR can be used.
Another=
 general question is why it is specified that the TV, MO and
CDA may require some parameters which can be CBOR: Are these parameter=
s specified on this draft or in any other draft? If they are, they should b=
e referenced. On the end of section 4 there are a number
of parameters specified, but none of them are defined if they are CBOR or =
not.

- "The size of the rul=
e ID is not specified in this document and can
   vary r=
egarding the LPWAN technology, the number of flows,..."


=
This text must state that the r=
ule ID value is implementation-specific.
If there are no=
 more items to add at the end, it is better to replace 
=
the "..." with "among others".
- "Some values in the rule ID space may be reserv=
ed for goals other than
<=
font face=3D"arial, helvetica, sans-serif">   header compression, for examp=
le fragmentation."


=
Fragmentation was added to this=
 draft recently. It can be specified here
if there are a=
ny Rule IDs reserved for fragmentation and remove the
ex=
ample.


P=
acket processing

- "(exclud=
ing unappropriate direction or position)"

The text before this expression says that the matching is do=
ne
using direction and position, and this excludes this =
from the
comparison (saying even unapproriate direction =
or position will
match). If this is not the correct inte=
rpretation, it is misleading.

- =
"In the downstrean direction, the rule is also used to find the=

      device ID."

Better to add "as explained on section 5.5
 
- "sent in the first byte of the L2 payload.&quo=
t; 

This is the first limita=
tion: It must be said here that, if there
are compressed values to include in the payloa=
d, they MUST use, at most 1 byte. Is it
the correct way to interpret this limitation?

-  "associa=
tes these values to header fields"

Which values? It may better to write: "associates the values t=
o header fields"

Matc=
hing operators

- "
This document describes basic match=
ing operators" 

"This section describes"...

=

- "SCHC C=
/D, endpoints"

Eliminate the comma.

<=
font face=3D"arial, helvetica, sans-serif">- "equal: a field value in =
a packet matches with a field value in a
      rule if they are equal"
=
Is any of those values a TV?

- "MSB(length): a field value of a size =
equal to "length" bits in a
      packet matches with a field value=
 in a rule if the most
      significant "length" bits are equal."

<= pre class=3D"gmail-newpage" style=3D"font-size:13.3333px;margin-top:0px;mar= gin-bottom:0px">Can this be rew= ritten to: "TV where the <length> MSBs match 
the <length> M=
SBs of the field value on a rule" ? 
Am I missing something?   

- "=
;match-mapping: The goal of mapping-sent is to reduce"

= 
mapping-sent i=
s defined after as an action. It may be better to write 
"The goal of ma=
tch-mapping is"...
Furthermore, it must be said that the field values MU=
ST be unique, or 
that the it matches the first occurrence, in order to avoid=
 ambiguities.

- "Matching Operators and match-mapping needs"

<=
/font>
ma=
tch-mapping is a matching operator: "Matching operators need"

- "Figure 4: Compressi=
on and Decompression Functions"

Are tables used or only figures? This should be a Table.<= pre class=3D"gmail-newpage" style=3D"white-space:pre-wrap;font-size:13.3333= px;margin-top:0px;margin-bottom:0px">
- "may be sent with the compressed heade=
r."

How to add the fiel= d size on the compressed header?

- &= quot;for that field on which compression is applied."

"for the field"...

- "number of bit sent"

number of bits sent

- "Compute-*"

Is not on the table. (Figure 4)=
- "These functions a= re used by the decompressor"

I think it may be better to rewrite it as: "This class of functions is used by the decompress= or"...
- "during the compression and reconstruc= ted during the decompression.&qu= ot;

=
Remove "the"= ; on both instances.

- &q= uot;compute a checksum from the = information already received by = the SCHC C/D"
<= span style=3D"font-size:13.3333px">
"= compute the checksum". "a checksum" is too generic. Also &qu= ot;the information" is too generic. Is
it the packet? 


Ap=
plication to IPv6 and UDP headers


<= /div>

-"CDA must be "not-sent."

Double quote is missing.

- "the first one there is
   without compression and the original value=
 is sent, or the sencond
   where the values can be computed by sending only the LSB bits:"

<=
/font>
&q=
uot;the first one is not to use compression, thus the original"... 
chan=
ge "sencond" for "second"
=

- "TV is not set"<=
/font>
Does this mean it is empty?

- "The SCHC C/D recompute the original&q=
uot;

"recomputes"

-  "If the paylo=
ad is small"

It is not clear what is small: there may be gain even wi=
th a 15-bit
payload length, however, the packet becomes too long and will nee=
d
=
fragmentation.

- "since there is no IP forwarding between = the DEV and the
   SCHC C/D"

However, the Hop limit can be set by the =
DEV to forward
a packet towards beyond the SCHC C/D to any value.

- "Fo=
r privacy reasons or if the DEV address is changing over time, it
   maybe be=
tter to use a static value."

This means that there is an internal m=
apping function that
matches the static value to each of the addresses the DE=
V acquires
over time.

- "the list of possible IID"

=

"IIDs&quo=
t;

- "CDF is set to LSB"

I think it is "CDA" instead =
of "CDF".

- "If both ends knows the port number"

&quo=
t;know"

- "(such as in the LPWAN fragmentation process (see XXXX=
))"

Now that fragmentation is included on the draft, XXXX can =

be chang=
ed to "Section 8"


Examples

=
- "when such technologie a=
re used"

"technologies"

- "the three rules Figure 6&q=
uot;

"the three rules depicted on Figure 6"


  
-- 
DIEGO DUJOVNE
Profesor Asociado
Escuela de Inform=C3=
=A1tica y Telecomunicaciones
Facultad de Ingenier=C3=ADa - Universidad D=
iego Portales - Chile
www.ingenieria.udp.cl
(56 2) 676 8125
=





--94eb2c075a60546106055013b906--


From nobody Wed May 24 01:14:52 2017
Return-Path: 
X-Original-To: lp-wan@ietfa.amsl.com
Delivered-To: lp-wan@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 953AE12706D for ; Wed, 24 May 2017 01:14:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 8h3w5fbpvpgB for ; Wed, 24 May 2017 01:14:47 -0700 (PDT)
Received: from relay5-d.mail.gandi.net (relay5-d.mail.gandi.net [217.70.183.197]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 967351201FA for ; Wed, 24 May 2017 01:14:47 -0700 (PDT)
Received: from mfilter27-d.gandi.net (mfilter27-d.gandi.net [217.70.178.155]) by relay5-d.mail.gandi.net (Postfix) with ESMTP id A2F0D41C0A5; Wed, 24 May 2017 10:14:45 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at mfilter27-d.gandi.net
Received: from relay5-d.mail.gandi.net ([IPv6:::ffff:217.70.183.197]) by mfilter27-d.gandi.net (mfilter27-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id WOKCnSpNeixe; Wed, 24 May 2017 10:14:44 +0200 (CEST)
X-Originating-IP: 192.44.77.204
Received: from el-meco.rennes.enst-bretagne.fr (nat-asr-incub-b204.rennes.enst-bretagne.fr [192.44.77.204]) (Authenticated sender: ana@ackl.io) by relay5-d.mail.gandi.net (Postfix) with ESMTPSA id 062EF41C0A0; Wed, 24 May 2017 10:14:42 +0200 (CEST)
Content-Type: multipart/alternative; boundary="Apple-Mail=_BEF50CD9-5CD2-4B56-9DA2-591801E8B5CA"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Ana Minaburo 
In-Reply-To: <5918eb97-45f1-b544-7873-8d9899c18586@cs.tcd.ie>
Date: Wed, 24 May 2017 10:14:41 +0200
Cc: lp-wan@ietf.org
Message-Id: <1ECF807C-229E-40E9-91E1-AC9C5567A02E@ackl.io>
References: <149475420158.2867.2858210762450072982@ietfa.amsl.com> <4921d239-dbab-9ea1-3dbd-66e044bf22ec@cs.tcd.ie> <54E3DA78-D7D4-46BE-B0F6-602304440D4D@ackl.io> <5918eb97-45f1-b544-7873-8d9899c18586@cs.tcd.ie>
To: Stephen Farrell 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Subject: Re: [lp-wan] I-D Action: draft-ietf-lpwan-overview-02.txt
X-BeenThere: lp-wan@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Low-Power Wide Area Networking \(LP-WAN\), also known as LPWA or Low-Rate WAN \(LR-WAN\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 May 2017 08:14:50 -0000

--Apple-Mail=_BEF50CD9-5CD2-4B56-9DA2-591801E8B5CA
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Hello,

I=E2=80=99ve create a PR with the modifications, based on meeting =
consensus.

Ana

> On 19 May 2017, at 11:20, Stephen Farrell  =
wrote:
>=20
>=20
> Hiya,
>=20
> On 19/05/17 09:43, Ana Minaburo wrote:
>> Hello,
>>=20
>> Do you think you can add the consensus we got in last meeting about =
for the section 3 terminology?
>>=20
>=20
> Sure. What text would you like? (*)
>=20
> Cheers,
> S.
>=20
> (*) Ideally, via a PR for [1] but however you prefer is fine.
>=20
> [1] https://github.com/sftcd/lpwan-ov =

>=20
>> thanks
>> Ana
>>=20
>>> On 14 May 2017, at 11:32, Stephen Farrell =
 wrote:
>>>=20
>>>=20
>>>=20
>>> Hi all,
>>>=20
>>> I've updated the overview document as planned (well, a week or
>>> two later than planned:-). I still have two open issues that I'd
>>> like to resolve before I'd claim that this is ready for WGLC so
>>> I'll send separate mails on those.
>>>=20
>>> Other than that, it might be pretty close to ready, though your
>>> comments are welcome of course. (Either on the list or as a PR
>>> to the git repo.)
>>>=20
>>> Cheers,
>>> S.
>>>=20
>>> On 14/05/17 10:30, internet-drafts@ietf.org wrote:
>>>>=20
>>>> A New Internet-Draft is available from the on-line Internet-Drafts =
directories.
>>>> This draft is a work item of the IPv6 over Low Power Wide-Area =
Networks of the IETF.
>>>>=20
>>>>       Title           : LPWAN Overview
>>>>       Author          : Stephen Farrell
>>>> 	Filename        : draft-ietf-lpwan-overview-02.txt
>>>> 	Pages           : 39
>>>> 	Date            : 2017-05-14
>>>>=20
>>>> Abstract:
>>>>  Low Power Wide Area Networks (LPWAN) are wireless technologies =
with
>>>>  characteristics such as large coverage areas, low bandwidth, =
possibly
>>>>  very small packet and application layer data sizes and long =
battery
>>>>  life operation.  This memo is an informational overview of the set =
of
>>>>  LPWAN technologies being considered in the IETF and of the gaps =
that
>>>>  exist between the needs of those technologies and the goal of =
running
>>>>  IP in LPWANs.
>>>>=20
>>>>=20
>>>> The IETF datatracker status page for this draft is:
>>>> https://datatracker.ietf.org/doc/draft-ietf-lpwan-overview/
>>>>=20
>>>> There are also htmlized versions available at:
>>>> https://tools.ietf.org/html/draft-ietf-lpwan-overview-02
>>>> https://datatracker.ietf.org/doc/html/draft-ietf-lpwan-overview-02
>>>>=20
>>>> A diff from the previous version is available at:
>>>> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-lpwan-overview-02
>>>>=20
>>>>=20
>>>> 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.
>>>>=20
>>>> Internet-Drafts are also available by anonymous FTP at:
>>>> ftp://ftp.ietf.org/internet-drafts/
>>>>=20
>>>> _______________________________________________
>>>> lp-wan mailing list
>>>> lp-wan@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/lp-wan
>>>>=20
>>>=20
>>> _______________________________________________
>>> lp-wan mailing list
>>> lp-wan@ietf.org
>>> https://www.ietf.org/mailman/listinfo/lp-wan
>>=20
>> _______________________________________________
>> lp-wan mailing list
>> lp-wan@ietf.org 
>> https://www.ietf.org/mailman/listinfo/lp-wan =

>>=20
>=20
> _______________________________________________
> lp-wan mailing list
> lp-wan@ietf.org 
> https://www.ietf.org/mailman/listinfo/lp-wan =


--Apple-Mail=_BEF50CD9-5CD2-4B56-9DA2-591801E8B5CA
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

Hello,

I=E2=80=99ve create a PR with the modifications, based on =
meeting consensus.

Ana

On 19 May 2017, at 11:20, =
Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:


Hiya,

On 19/05/17 09:43, Ana Minaburo wrote:
Hello,

Do you think you can add the consensus we got in last meeting =
about for the section 3 terminology?


Sure. What text would you like? =
(*)

Cheers,
S.

(*) Ideally, via a PR for [1] but however you =
prefer is fine.

[1] https://github.com/sftcd/lpwan-ov

thanks
Ana

On 14 May 2017, at =
11:32, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:



Hi all,

I've updated the overview document as planned (well, a week =
or
two later than planned:-). I still have two open issues =
that I'd
like to resolve before I'd claim that this is =
ready for WGLC so
I'll send separate mails on those.

Other than that, it might be pretty close to =
ready, though your
comments are welcome of course. (Either =
on the list or as a PR
to the git repo.)

Cheers,
S.

On =
14/05/17 10:30, internet-drafts@ietf.org wrote:

A New Internet-Draft is =
available from the on-line Internet-Drafts directories.
This=
 draft is a work item of the IPv6 over Low Power Wide-Area Networks of =
the IETF.

      Title =
          : LPWAN =
Overview
      Author =
         : Stephen =
Farrell
	Filename        : =
draft-ietf-lpwan-overview-02.txt
	Pages =
          : 39
	=
Date =
           : =
2017-05-14

Abstract:
 Low =
Power Wide Area Networks (LPWAN) are wireless technologies with
 characteristics such as large coverage areas, low =
bandwidth, possibly
 very small packet and =
application layer data sizes and long battery
 life =
operation.  This memo is an informational overview of the set of
 LPWAN technologies being considered in the IETF and of =
the gaps that
 exist between the needs of those =
technologies and the goal of running
 IP in =
LPWANs.


The IETF datatracker =
status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-lpwan-overview/=


There are also htmlized versions available =
at:
https://tools.ietf.org/html/draft-ietf-lpwan-overview-02
https://datatracker.ietf.org/doc/html/draft-ietf-lpwan-overview=
-02

A diff from the previous version is =
available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-lpwan-overview-0=
2


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/

_______________________________________________
lp-wan mailing list
lp-wan@ietf.org
https://www.ietf.org/mailman/listinfo/lp-wan


_______________________________________________
lp-wan mailing list
lp-wan@ietf.org
https://www.ietf.org/mailman/listinfo/lp-wan

_______________________________________________
lp-wan mailing list
lp-wan@ietf.org
https://www.ietf.org/mailman/listinfo/lp-wan


_______________________________________________
lp-wan mailing list
lp-wan@ietf.org
https://www.ietf.org/mailman/listinfo/lp-wan

=

--Apple-Mail=_BEF50CD9-5CD2-4B56-9DA2-591801E8B5CA--


From nobody Wed May 24 01:51:54 2017
Return-Path: 
X-Original-To: lp-wan@ietfa.amsl.com
Delivered-To: lp-wan@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DAE01293E1 for ; Wed, 24 May 2017 01:51:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.588
X-Spam-Level: 
X-Spam-Status: No, score=-2.588 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, T_KAM_HTML_FONT_INVALID=0.01, 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 BqLRLJZpbooA for ; Wed, 24 May 2017 01:51:48 -0700 (PDT)
Received: from relay3-d.mail.gandi.net (relay3-d.mail.gandi.net [IPv6:2001:4b98:c:538::195]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42CE7127909 for ; Wed, 24 May 2017 01:51:48 -0700 (PDT)
Received: from mfilter2-d.gandi.net (mfilter2-d.gandi.net [217.70.178.140]) by relay3-d.mail.gandi.net (Postfix) with ESMTP id B0EC3A811B; Wed, 24 May 2017 10:51:46 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at mfilter2-d.gandi.net
Received: from relay3-d.mail.gandi.net ([IPv6:::ffff:217.70.183.195]) by mfilter2-d.gandi.net (mfilter2-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id AYZOrCzUfo-P; Wed, 24 May 2017 10:51:43 +0200 (CEST)
X-Originating-IP: 192.44.77.204
Received: from el-meco.rennes.enst-bretagne.fr (nat-asr-incub-b204.rennes.enst-bretagne.fr [192.44.77.204]) (Authenticated sender: ana@ackl.io) by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id D179EA80F2; Wed, 24 May 2017 10:51:42 +0200 (CEST)
Content-Type: multipart/alternative; boundary="Apple-Mail=_4E1FBFA3-9925-42AC-97CD-AC283F3C0A42"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Ana Minaburo 
In-Reply-To: 
Date: Wed, 24 May 2017 10:51:41 +0200
Cc: lp-wan 
Message-Id: <75992E1B-55CD-4794-9C32-11D0F4454487@ackl.io>
References: 
To: "Prof. Diego Dujovne" 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Subject: Re: [lp-wan] Review of draft-ietf-lpwan-ipv6-static-context-hc-03
X-BeenThere: lp-wan@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Low-Power Wide Area Networking \(LP-WAN\), also known as LPWA or Low-Rate WAN \(LR-WAN\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 May 2017 08:51:53 -0000

--Apple-Mail=_4E1FBFA3-9925-42AC-97CD-AC283F3C0A42
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Hello Diego,=20

thanks for the comments, perhaps some clarifications


> On 22 May 2017, at 04:35, Prof. Diego Dujovne =
 wrote:
>=20
> Dear all,
>              I post here the review of =
draft-ietf-lpwan-ipv6-static-context-hc-03
> from the beginning until Section 7 (included). I will go on with the =
remaining part of
> the draft in the following days.
> Regards,
>=20
>                                                Diego
>=20
>=20
>=20
> Abstract
>=20
> - "Static context means that information stored in the context which, =
describes field values,"=20
>=20
> I would take out the first comma.
>=20
> - "does not change during the packet transmission"
>=20
> I would remove "the"
>=20
> - " Similar mechanisms for other protocols such as CoAP will be =
described in a separate document."
>=20
> I would put "separate documents" since you are talking about other =
protocols, no only CoAP.
>=20
> - "the L2 pdu size"
>=20
> I would put PDU with capital letters.
>=20
>=20
>=20
> Introduction
>=20
> - "Topology is star oriented, therefore all the packets follow the =
same path."
>=20
> First, I would add a hyphen: star-oriented.=20
> Second, there is no specific discussion if stars of stars will ever be =
supported, or if this draft only applies to a star topology. In this =
case, star-oriented can be both star of stars and star.
>=20
> - "SCHC uses a context where header information is kept in order."=20
>=20
> Is there any other scheme where the header information is not kept in =
order?

The idea was to be clear about how to put information on the context, =
there is no other scheme, but the information can be put in any order if =
it is not specified, so we believe that to be clear we need to said at =
least once that the information is kept in the format order of the =
original protocol.
>=20
> -  "(the values on the header fields do not change during time)"
>=20
> I would suggest "do not change over time"
>=20
> The introduction does not introduce fragmentation as the abstract =
does.
>=20
> - "The SCHC header compression is indedependent"
>=20
> Typo: independent.
>=20
> - "On the other hand,"
>=20
> Is it needed the "On the one hand" statement previously to use this =
expression?
>=20
> - "not support layer two fragmentation"
>=20
> This is not coherent with the notation on the abstract -> change to =
L2.
>=20
> Just for the sake of clarity, from the introduction, I can deduce this =
draft only concentrates on a protocol and a mechanism. The protocol is =
SCHC and the mechanism is Fragmentation. The protocol usage is justified =
by two properties of LPWANs and the mechanism is justified by the lack =
of support on part of the LPWAN technologies.   =20

I=E2=80=99m not sure I have understand you. But the SCHC header =
compression must be used always, and only if needed the fragmentation =
part will be applied. Both may be considered as protocols, or =
mechanisms, both parts are together in the same place and you will use =
one or both as needed.=20
Perhaps we need to modify the introduction to be clear
>=20
> Vocabulary
> -"Vocabulary"
> Isn't this "Terminology"?
> - "DEV: Device.  Node connected to the LPWAN.  A DEV may implement =
SCHC."
> I can conclude that devices with and without SCHC can coexist. This =
should be mentioned on the Introduction.
> - "An application sending/consuming IPv6"
> AFAIK, the term "consumer" comes from the Content-Centric Networking =
environment; I think this should be changed to "receiving", or, the =
other way round, "sending/consuming" should be changed to =
"producing/consuming", just to keep coherence.=20
> - "flow.  Rule ID is sent on the LPWAN."
> "The Rule ID is"...
> - "MO: Matching Operator.  An operator used to compare a value =
contained in a header field with a value contained in a rule."=20
> - "TV: Target value.  A value contained in the rule that will be      =
matched with the value of a header field."
> Does the matching operator compare the Target Value (TV) with the =
value of the header field? I think it would be better to use the =
terminology already on MO. Do you use "match" and "compare" as synonyms?
>=20
> Static Context Header Compression
> - "compression mechanisms such as RoHC."=20
>=20
> This is the first time RoHC appears on the text. Can you put a =
reference to the corresponding RFC?
>=20
> - "provisionning protocol"
>=20
> provisioning
>=20
> - =46rom figure 1,=20
>=20
> The Radio Gateway was not defined on the local Terminology, while the =
rest of the used blocks is defined there.
>=20
> - "applications which produce IPv6"
>=20
> Here the term producer is used as I mentioned before. Maybe the idea =
to "produce" is better than to "send" flows.
>=20
> - "the headers size"
>=20
> I would keep here "header size" as a generic expression.
>=20
> - "shares the same rules with the DEV"
>=20
> Then, on Figure 1 it should say "DEV" instead of "DEVICE"
>=20
> - " or in another places"
>=20
> I would write "or in another place" or in "or in another intermediate =
place"
>=20
> - "if a tunnel is established between the NGW and the SCHC C/D"
>=20
> I would write "as long as a tunnel is" I think it shows better the =
need to put a tunnel because of the placement of the SCHC C/D far away =
from the NGW. The "if" statement makes  me understand that the tunnel =
was before the SCHC C/D location and not as a consequence of this =
action.
>=20
> - "This architecture forms a star topology."
>=20
> This architecture is applicable only to a star topology. Is the star =
topology a consequence of SCHC?
>=20
> - "After decompression, the packet can be sent on the Internet to one =
or several LPWAN Application Servers (APP)."
>=20
> On this stage, the packet is rebuilt according to the IPv6 structure. =
The draft does not mention any multicast capability or if the resulting =
packets will be unicast only. If one or many application servers can be =
reached, this should be specified.
>=20
> - "The principle is exactly the same in the other direction."
>=20
> This means that unicast or multicast are possible towards the node =
side.
>=20
> - "field identifier (FID), a field position (FP), a direction =
indicator (DI)"=20
>=20
> Although it is defined just after, this should be on the terminology =
too, as the other terms used on the draft. =20
>=20
> - " Figure 2: Compression Decompression Context"=20
>=20
> To be coherent to the rest of the text, this should be =
"Compression/Decompression"
>=20
> - "the description of the header field must be done in the same order =
they appear in the packet."
>=20
> "must be executed in the same order that appears on the packet"
>=20
> I think that it must be said somewhere that both the SCHC Compressor / =
Decompressor MUST share the same set of rules.=20
>=20
> - "On the other hand, the rule describes the compressed header which =
are
>    transmitted regarding their position in the rule which is used for
>    data serialization on the compressor side and data deserialization =
on
>    the decompressor side."
>=20
> "describes the compressed header which is"
>=20
> - "Regarding their"=20
>=20
> Who are they?
>=20
> I do not understand what can be in a different order than the order =
established by the packet header.  Being the SCHC C/D, I will not =
understand what to decompress and how if the order is changed.=20

We want to block the order you put information in the context, so =
that=E2=80=99s why we talk about order, if the ML think it is not =
important to leave this clear, we can delete this part, but I believe =
that if it is not define you can create your context as you want.
>=20
> - "The main idea of the compression scheme is to send the rule id to =
the
>    other end instead of known field values.  When a value is known by
>    both ends, it is not necessary to send it on the LPWAN network."
>=20
> I think this is the key to this draft. This should be on the=20
> introduction/abstract too.
>=20
> - "A Field Position (FP) indicating if several instances of the field
>       exist in the headers which one is targeted."
>=20
> This expression is not clear. I imagine that this is an index to
> reference each of the instances of the field.

In some protocols the value of a field may be divided in different parts =
of the header, so you need too specify to which part you are referring.=20=


In this part we are trying to develop the complete tools for the SCHC =
compression of any protocol
>=20
> - "A Target Value (TV) is the value used to make the comparison with
>       the packet header field.  The Target Value can be of any type
>       (integer, strings,...).  It can be a single value or a more
>       complex structure (array, list,...).  It can be considered as a
>       CBOR structure."
>=20
> Here I have a conflict on the idea of header field and value. I can=20
> interpret that the intention is that a field has a value and=20
> the target value is compared against the field value, and not the
> name of the field. But it needs to be rewritten.
One thing is the field name and other thing is its value.
The TV is the value that is in the Context, this value has been given to =
this context before transmission as a configuration and it is not the =
value in the packet header.=20
> When is it going to be represented as a CBOR structure and when not?
When you want
> Is there a bit for each field on each rule saying so? If not, it is
No, the Rule-ID will give this difference
> not clear when to interpret it as a CBOR structure and when not. This
> applies to all the cases when the text says CBOR can be used.
> Another general question is why it is specified that the TV, MO and
> CDA may require some parameters which can be CBOR: Are these =
parameters specified on this draft or in any other draft? If they are, =
they should be referenced. On the end of section 4 there are a number
> of parameters specified, but none of them are defined if they are CBOR =
or not.
>=20
> - "The size of the rule ID is not specified in this document and can
>    vary regarding the LPWAN technology, the number of flows,=E2=80=A6"
>=20
> This text must state that the rule ID value is =
implementation-specific.
> If there are no more items to add at the end, it is better to replace=20=

> the "..." with "among others".
>=20
> - "Some values in the rule ID space may be reserved for goals other =
than
>    header compression, for example fragmentation."
>=20
> Fragmentation was added to this draft recently. It can be specified =
here
> if there are any Rule IDs reserved for fragmentation and remove the
> example.
>=20
>=20
> Packet processing
>=20
> - "(excluding unappropriate direction or position)"
>=20
> The text before this expression says that the matching is done
> using direction and position, and this excludes this from the
> comparison (saying even unapproriate direction or position will
> match). If this is not the correct interpretation, it is misleading.
>=20
> - "In the downstrean direction, the rule is also used to find the
>       device ID."
>=20
> Better to add "as explained on section 5.5
> =20
> - "sent in the first byte of the L2 payload."=20
>=20
> This is the first limitation: It must be said here that, if there
> are compressed values to include in the payload, they MUST use, at =
most 1 byte. Is it
> the correct way to interpret this limitation?
>=20
> -  "associates these values to header fields"
>=20
> Which values? It may better to write: "associates the values to header =
fields"
>=20
> Matching operators
>=20
> - "This document describes basic matching operators"=20
>=20
> "This section describes"...
>=20
> - "SCHC C/D, endpoints"
>=20
> Eliminate the comma.
>=20
> - "equal: a field value in a packet matches with a field value in a
>       rule if they are equal"
>=20
> Is any of those values a TV?
No, The SCHC C/D are actions in order to decide which information will =
be sent
>=20
> - "MSB(length): a field value of a size equal to "length" bits in a
>       packet matches with a field value in a rule if the most
>       significant "length" bits are equal."
>=20
> Can this be rewritten to: "TV where the  MSBs match=20
> the  MSBs of the field value on a rule" ?=20
> Am I missing something?  =20
>=20
> - "match-mapping: The goal of mapping-sent is to reduce"
>=20
> mapping-sent is defined after as an action. It may be better to write=20=

> "The goal of match-mapping is"...
> Furthermore, it must be said that the field values MUST be unique, or=20=

> that the it matches the first occurrence, in order to avoid =
ambiguities.
>=20
> - "Matching Operators and match-mapping needs"
>=20
> match-mapping is a matching operator: "Matching operators need"
>=20
> - "Figure 4: Compression and Decompression Functions"
>=20
> Are tables used or only figures? This should be a Table.
>=20
> - "may be sent with the compressed header."
>=20
> How to add the field size on the compressed header?
>=20
> - "for that field on which compression is applied."
>=20
> "for the field"...
>=20
> - "number of bit sent"
>=20
> number of bits sent
>=20
> - "Compute-*"
>=20
> Is not on the table. (Figure 4)
>=20
> - "These functions are used by the decompressor"
>=20
> I think it may be better to rewrite it as: "This class of functions is =
used by the decompressor"...
>=20
> - "during the compression and reconstructed during the decompression."
>=20
> Remove "the" on both instances.
>=20
> - "compute a checksum from the information already received by the =
SCHC C/D"
>=20
> "compute the checksum". "a checksum" is too generic. Also "the =
information" is too generic. Is
> it the packet?=20
>=20
>=20
> Application to IPv6 and UDP headers
>=20
>=20
> -"CDA must be "not-sent."
>=20
> Double quote is missing.
>=20
> - "the first one there is
>    without compression and the original value is sent, or the sencond
>    where the values can be computed by sending only the LSB bits:"
>=20
> "the first one is not to use compression, thus the original"...=20
> change "sencond" for "second"
>=20
> - "TV is not set"
>=20
> Does this mean it is empty?
>=20
> - "The SCHC C/D recompute the original"
>=20
> "recomputes"
>=20
> -  "If the payload is small"
>=20
> It is not clear what is small: there may be gain even with a 15-bit
> payload length, however, the packet becomes too long and will need
> fragmentation.
>=20
> - "since there is no IP forwarding between the DEV and the
>    SCHC C/D"
>=20
> However, the Hop limit can be set by the DEV to forward
> a packet towards beyond the SCHC C/D to any value.
>=20
> - "For privacy reasons or if the DEV address is changing over time, it
>    maybe better to use a static value."
>=20
> This means that there is an internal mapping function that
> matches the static value to each of the addresses the DEV acquires
> over time.
>=20
> - "the list of possible IID"
>=20
> "IIDs"
>=20
> - "CDF is set to LSB"
>=20
> I think it is "CDA" instead of "CDF".
>=20
> - "If both ends knows the port number"
>=20
> "know"
>=20
> - "(such as in the LPWAN fragmentation process (see XXXX))"
>=20
> Now that fragmentation is included on the draft, XXXX can=20
> be changed to "Section 8"
>=20
>=20
> Examples
>=20
> - "when such technologie are used"
>=20
> "technologies"
>=20
> - "the three rules Figure 6"
>=20
> "the three rules depicted on Figure 6"
>=20
>=20
>  =20
> --=20
> DIEGO DUJOVNE
> Profesor Asociado
> Escuela de Inform=C3=A1tica y Telecomunicaciones
> Facultad de Ingenier=C3=ADa - Universidad Diego Portales - Chile
> www.ingenieria.udp.cl 
> (56 2) 676 8125
> _______________________________________________
> lp-wan mailing list
> lp-wan@ietf.org
> https://www.ietf.org/mailman/listinfo/lp-wan

Ana=

--Apple-Mail=_4E1FBFA3-9925-42AC-97CD-AC283F3C0A42
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

Hello Diego, 

thanks for the comments, perhaps some =
clarifications


On 22 May 2017, at 04:35, Prof. Diego Dujovne <diego.dujovne@mail.udp.cl> wrote:

Dear all,
          =
   I post here the review =
of draft-ietf-lpwan-ipv6-static-context-hc-03
from =
the beginning until Section 7 (included). I will go on with the =
remaining part of
the draft in the following =
days.
Regards,

              =
                    =
             Diego



Abstract

- "Static =
context means =
that information stored in the context which, describes field values," =

I would take out the first comma.

- "does not change during the =
packet transmission"

I would remove =
"the"

- " Similar mechanisms for =
other protocols =
such as CoAP will be described in a separate =
document."

I would put "separate documents" since =
you are talking about other protocols, no only =
CoAP.

- "the L2 pdu =
size"

I would put PDU with capital =
letters.



Introduction

- "Topology is star oriented, therefore all the packets follow =
the same =
path."

First, I would add a hyphen: =
star-oriented. 
Second, there is no specific discussion if stars of stars =
will ever be supported, or if this draft only applies to a star =
topology. In this case, star-oriented can be both star of stars and =
star.
- "SCHC uses a context where =
header information is kept in order." 

Is =
there any other scheme where the header information is not kept in =
order?

The idea was to be clear about how to put information =
on the context, there is no other scheme, but the information can be put =
in any order if it is not specified, so we believe that to be clear we =
need to said at least once that the information is kept in the format =
order of the original protocol.

-  "(the values on the header =
fields do not =
change during time)"

I would suggest "do not change over =
time"

The introduction does =
not introduce fragmentation as the abstract =
does.

- "The SCHC header compression =
is indedependent"

Typo: =
independent.

- "On the other =
hand,"

Is it needed the "On the one =
hand" statement previously to use this =
expression?

- "not support layer two =
fragmentation"

This is not coherent with the =
notation on the abstract -> change to L2.

Just for the sake of clarity, from the introduction, I can =
deduce this draft only concentrates on a protocol and a mechanism. The =
protocol is SCHC and the mechanism is Fragmentation. The protocol usage is =
justified by two properties of LPWANs and the mechanism is justified by =
the lack of support on part of the LPWAN technologies.    =


I=E2=80=99m not sure I have understand you. But the =
SCHC header compression must be used always, and only if needed the =
fragmentation part will be applied. Both may be considered as protocols, =
or mechanisms, both parts are together in the same place and you will =
use one or both as needed. 
Perhaps we need to modify the =
introduction to be clear

Vocabulary
-"Vocabulary"
Isn't this =
"Terminology"?
- "DEV: Device.  Node connected to the LPWAN.  A =
DEV may implement SCHC."
I can conclude that devices with and =
without SCHC can coexist. This should be mentioned on the =
Introduction.
- "An application sending/consuming =
IPv6"
AFAIK, the term "consumer" comes from the Content-Centric =
Networking environment; I think this should be changed to "receiving", =
or, the other way round, "sending/consuming" should be changed to =
"producing/consuming", just to keep coherence. 
- "flow.  Rule ID is =
sent on the LPWAN."
"The Rule ID is"...
- "MO: Matching =
Operator.  An operator used to compare a value contained in a header =
field with a value contained in a rule." 
- "TV: Target value.  A =
value contained in the rule that will be      matched with the value of =
a header field."
Does the matching operator compare the Target =
Value (TV) with the value of the header field? I think it would be =
better to use the terminology already on MO. Do you use "match" and =
"compare" as synonyms?

Static Context Header =
Compression

- "compression =
mechanisms such as RoHC." 

This =
is the first time RoHC appears on the text. Can you put a reference to =
the corresponding RFC?

- =
"provisionning protocol"

provisioning

- =46rom=
 figure 1, 

The =
Radio Gateway was not defined on the local Terminology, while the rest =
of the used blocks is defined there.

- "applications which produce =
IPv6"

Here =
the term producer is used as I mentioned before. Maybe the idea to =
"produce" is better than to "send" flows.

- "the headers size"

I would keep here "header size" as a =
generic expression.

- =
"shares the same rules with the DEV"

Then, on Figure 1 it should say "DEV" =
instead of "DEVICE"

- " or =
in another places"

I =
would write "or in another place" or in "or in another intermediate =
place"

- "if =
a tunnel is established between the NGW and the SCHC =
C/D"

I =
would write "as long as a tunnel is" I think it shows better the need to =
put a tunnel because of the placement of the SCHC C/D far away from the =
NGW. The "if" statement makes  me understand that the tunnel was before =
the SCHC C/D location and not as a consequence of this action.

- =
"This architecture forms a star topology."

This architecture is applicable only =
to a star topology. Is the star topology a consequence of =
SCHC?

- =
"After decompression, the packet can be sent on the Internet to one or =
several LPWAN Application Servers (APP)."

On this stage, the packet is rebuilt =
according to the IPv6 structure. The draft does not mention any =
multicast capability or if the resulting packets will be unicast only. =
If one or many application servers can be reached, this should be =
specified.

- "The =
principle is exactly the same in the other direction."

This means that unicast or multicast =
are possible towards the node side.

- "field identifier (FID), a field =
position (FP), a direction indicator (DI)" 

Although it is defined just after, =
this should be on the terminology too, as the other terms used on the =
draft.  

- " =
Figure 2: Compression Decompression Context" 

To be coherent to the rest of the =
text, this should be "Compression/Decompression"

- "the description of the header field =
must be done in the same order they appear in the =
packet."

"must =
be executed in the same order that appears on the =
packet"

I =
think that it must be said somewhere that both the SCHC Compressor / =
Decompressor MUST share the same set of rules. 

- "On the other hand, the rule describes the compressed header =
which are
   =
transmitted regarding their position in the rule which is used for
   data serialization on the compressor side and data deserialization on

   the decompressor =
side."

"describes the compressed header which is"

- "Regarding their" 

Who are they?

I do not understand what can be in a =
different order than the order established by the packet header.  Being =
the SCHC C/D, I will not understand what to decompress and how if the =
order is changed. =


We want to block the order you put information in the =
context, so that=E2=80=99s why we talk about order, if the ML think it =
is not important to leave this clear, we can delete this part, but I =
believe that if it is not define you can create your context as you =
want.

- "The main idea of the compression scheme is to send the rule =
id to the
   =
other end instead of known field values.  When a value is known by
   both ends, it is not necessary to send it on the LPWAN network."


I think =
this is the key to this draft. This should be on the 
introduction/abstract =
too.

- "A Field Position =
(FP) indicating if several instances of the field
      exist in the headers which one is =
targeted."

This =
expression is not clear. I imagine that this is an index =
to
reference=
 each of the instances of the =
field.
<=
br class=3D"">
In some protocols the value of a field may be =
divided in different parts of the header, so you need too specify to =
which part you are referring. 

In=
 this part we are trying to develop the complete tools for the SCHC =
compression of any protocol

- "A =
Target Value (TV) is the value used to make the comparison =
with
      =
the packet header field.  The Target Value can be of any type
      (integer, strings,...).  It can be a single value or a more
      complex structure (array, list,...).  It can be considered as a
      CBOR structure."

Here I =
have a conflict on the idea of header field and value. I can =

interpret=
 that the intention is that a field has a value and 
the =
target value is compared against the field value, and not =
the
name of =
the field. But it needs to be =
rewritten.
One thing is the field name and other thing is its value.
The TV =
is the value that is in the Context, this value has been given to this =
context before transmission as a configuration and it is not the value =
in the packet header. 
When is =
it going to be represented as a CBOR structure and when =
not?
When =
you want
Is =
there a bit for each field on each rule saying so? If not, it =
is
No, the =
Rule-ID will give this difference
not =
clear when to interpret it as a CBOR structure and when not. =
This
applies =
to all the cases when the text says CBOR can be used.
Another =
general question is why it is specified that the TV, MO =
and
CDA may =
require some parameters which can be CBOR: Are these parameters =
specified on this draft or in any other draft? If they are, they should =
be referenced. On the end of section 4 there are a =
number
of =
parameters specified, but none of them are defined if they are CBOR or =
not.

- "The =
size of the rule ID is not specified in this document and =
can
   vary =
regarding the LPWAN technology, the number of =
flows,=E2=80=A6"

This =
text must state that the rule ID value is =
implementation-specific.
If =
there are no more items to add at the end, it is better to replace =

the =
"..." with "among others".

- "Some =
values in the rule ID space may be reserved for goals other =
than
   =
header compression, for example fragmentation."


Fragmentation was added to this draft recently. It can be =
specified here
if =
there are any Rule IDs reserved for fragmentation and remove =
the
example.


Packet =
processing

- =
"(excluding unappropriate direction or position)"

The =
text before this expression says that the matching is =
done
using =
direction and position, and this excludes this from the
comparison (saying even unapproriate direction or position =
will
match). =
If this is not the correct interpretation, it is =
misleading.

- "In =
the downstrean direction, the rule is also used to find =
the
      =
device ID."

Better =
to add "as explained on section 5.5
 
- "sent =
in the first byte of the L2 payload." 

This is the first =
limitation: It must be said here that, if there
are compressed values =
to include in the payload, they MUST use, at most 1 byte. Is =
it
the correct way to =
interpret this limitation?

-  "associates these =
values to header fields"

Which =
values? It may better to write: "associates the values to header =
fields"

Matching =
operators

- =
"
This document describes basic matching operators" =


"This section =
describes"...

- "SCHC C/D, =
endpoints"

Eliminate the =
comma.

- "equal: a field value =
in a packet matches with a field value in a
      rule if they are =
equal"

Is any of those values =
a =
TV?
No,=
 The SCHC C/D are actions in order to decide which information will be =
sent

- "MSB(length): a field =
value of a size equal to "length" bits in a
      packet matches =
with a field value in a rule if the most
      significant "length" bits are equal."

Can this be rewritten =
to: "TV where the <length> MSBs match 
the <length> MSBs =
of the field value on a rule" ? 
Am I missing something? =
  

- "match-mapping: The =
goal of mapping-sent is to reduce"

mapping-sent is defined =
after as an action. It may be better to write 
"The goal of =
match-mapping is"...
Furthermore, it must be =
said that the field values MUST be unique, or 
that the it matches the =
first occurrence, in order to avoid ambiguities.

- "Matching Operators =
and match-mapping needs"

match-mapping is a =
matching operator: "Matching operators need"

- =
"Figure 4: Compression and Decompression Functions"

Are =
tables used or only figures? This should be a Table.

- "may =
be sent with the compressed header."

How to add the field size on the =
compressed header?

- =
"for that field on which =
compression is applied."

"for the field"...

- "number=
 of bit sent"

number of bits =
sent

- "Compute-*"

Is not =
on the table. (Figure 4)

- =
"These functions =
are used by the decompressor"

I think it may be better to rewrite it as: "This class of functions is used =
by the decompressor"...

- "during=
 the compression and reconstructed during the =
decompression."

Remove "the" on both =
instances.

- "compute a checksum from the =
information already =
received by the SCHC C/D"

"compute the checksum". "a checksum" is too =
generic. Also "the information" is too generic. =
Is
it the packet? =



Application to IPv6 and UDP headers




-"CDA =
must be "not-sent."

Double quote is =
missing.

- "the first one there =
is
   without compression =
and the original value is sent, or the sencond
   where the values can be computed by sending only the LSB =
bits:"

"the first one is not =
to use compression, thus the original"... 
change "sencond" for =
"second"

- "TV is not =
set"

Does this mean it is =
empty?

- "The SCHC C/D =
recompute the original"

"recomputes"

-  "If the payload is =
small"

It is not clear what is =
small: there may be gain even with a 15-bit
payload length, =
however, the packet becomes too long and will need
fragmentation.

- "since there is no IP =
forwarding between the DEV and the
   SCHC =
C/D"

However, the Hop limit =
can be set by the DEV to forward
a packet towards beyond =
the SCHC C/D to any value.

- "For privacy reasons =
or if the DEV address is changing over time, it
   maybe better to use =
a static value."

This means that there =
is an internal mapping function that
matches the static =
value to each of the addresses the DEV acquires
over =
time.

- "the list of possible =
IID"

"IIDs"

- "CDF is set to =
LSB"

I think it is "CDA" =
instead of "CDF".

- "If both ends knows =
the port number"

"know"

- "(such as in the =
LPWAN fragmentation process (see XXXX))"

Now that fragmentation =
is included on the draft, XXXX can 
be changed to "Section =
8"


Examples

- "when such =
technologie are used"

"technologies"

- "the three rules =
Figure 6"

"the three rules =
depicted on Figure 6"


  =

-- 
DIEGO DUJOVNE
Profesor =
Asociado
Escuela de Inform=C3=A1tica y =
Telecomunicaciones
Facultad de Ingenier=C3=ADa - =
Universidad Diego Portales - Chile
www.ingenieria.udp.cl
(56 2) 676 8125



_______________________________________________
lp-wan =
mailing list
lp-wan@ietf.org
https://www.ietf.org/mailman/listinfo/lp-wan

Ana
=

--Apple-Mail=_4E1FBFA3-9925-42AC-97CD-AC283F3C0A42--



From nobody Wed May 24 02:07:40 2017
Return-Path: 
X-Original-To: lp-wan@ietfa.amsl.com
Delivered-To: lp-wan@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E47BC12942F for ; Wed, 24 May 2017 02:07:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Level: 
X-Spam-Status: No, score=-4.301 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_MED=-2.3, RP_MATCHES_RCVD=-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=cs.tcd.ie
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 MNj4B1Zv0Xdl for ; Wed, 24 May 2017 02:07:36 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0EDCE129404 for ; Wed, 24 May 2017 02:07:35 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 87AD6BE49; Wed, 24 May 2017 10:07:33 +0100 (IST)
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aaYsqbZGfASk; Wed, 24 May 2017 10:07:33 +0100 (IST)
Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 3551EBE53; Wed, 24 May 2017 10:06:34 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1495616794; bh=dUXAD1E+94E9hWhQXduHMqB67Dtv62ApMpDbzL84ohA=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=qrwbKQn24103H2edv+XLaYXgE6m0iLqkS9GT2Vm9eQwmTzA568cVx0GU7lIyVURjm VJaGPAZUFwJ9GK3bc+BmqVK73QV3vT30DBErkXbXsAKv/P2K+Z/TF7Y+9MtwPaqWqA bAzOPCuspMEYmCbWlKuX1r0tkzzx2UOCtUsXAZTE=
To: Ana Minaburo 
Cc: lp-wan@ietf.org
References: <149475420158.2867.2858210762450072982@ietfa.amsl.com> <4921d239-dbab-9ea1-3dbd-66e044bf22ec@cs.tcd.ie> <54E3DA78-D7D4-46BE-B0F6-602304440D4D@ackl.io> <5918eb97-45f1-b544-7873-8d9899c18586@cs.tcd.ie> <1ECF807C-229E-40E9-91E1-AC9C5567A02E@ackl.io>
From: Stephen Farrell 
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <6b268a87-7f0d-104c-7fc5-5577e34e333c@cs.tcd.ie>
Date: Wed, 24 May 2017 10:06:33 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1
MIME-Version: 1.0
In-Reply-To: <1ECF807C-229E-40E9-91E1-AC9C5567A02E@ackl.io>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Uw7DFhld12GlG0Sts73JaCHPQUkML7gDM"
Archived-At: 
Subject: Re: [lp-wan] I-D Action: draft-ietf-lpwan-overview-02.txt
X-BeenThere: lp-wan@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Low-Power Wide Area Networking \(LP-WAN\), also known as LPWA or Low-Rate WAN \(LR-WAN\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 May 2017 09:07:39 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--Uw7DFhld12GlG0Sts73JaCHPQUkML7gDM
Content-Type: multipart/mixed; boundary="6aJXca1Iu031pVFmPpuBq6obUxJx5gEvg";
 protected-headers="v1"
From: Stephen Farrell 
To: Ana Minaburo 
Cc: lp-wan@ietf.org
Message-ID: <6b268a87-7f0d-104c-7fc5-5577e34e333c@cs.tcd.ie>
Subject: Re: [lp-wan] I-D Action: draft-ietf-lpwan-overview-02.txt
References: <149475420158.2867.2858210762450072982@ietfa.amsl.com>
 <4921d239-dbab-9ea1-3dbd-66e044bf22ec@cs.tcd.ie>
 <54E3DA78-D7D4-46BE-B0F6-602304440D4D@ackl.io>
 <5918eb97-45f1-b544-7873-8d9899c18586@cs.tcd.ie>
 <1ECF807C-229E-40E9-91E1-AC9C5567A02E@ackl.io>
In-Reply-To: <1ECF807C-229E-40E9-91E1-AC9C5567A02E@ackl.io>

--6aJXca1Iu031pVFmPpuBq6obUxJx5gEvg
Content-Type: text/plain; charset=utf-8
Content-Language: en-GB
Content-Transfer-Encoding: quoted-printable



On 24/05/17 09:14, Ana Minaburo wrote:
> Hello,
>=20
> I=E2=80=99ve create a PR with the modifications, based on meeting conse=
nsus.

Thanks, I've merged that one and also PR#6 that expanded an
acronym.

The result is at [1], do yell if I got anything wrong.

Cheers,
S.

[1]
https://github.com/sftcd/lpwan-ov/blob/master/draft-ietf-lpwan-overview.t=
xt

>=20
> Ana
>=20
>> On 19 May 2017, at 11:20, Stephen Farrell  =
wrote:
>>
>>
>> Hiya,
>>
>> On 19/05/17 09:43, Ana Minaburo wrote:
>>> Hello,
>>>
>>> Do you think you can add the consensus we got in last meeting about f=
or the section 3 terminology?
>>>
>>
>> Sure. What text would you like? (*)
>>
>> Cheers,
>> S.
>>
>> (*) Ideally, via a PR for [1] but however you prefer is fine.
>>
>> [1] https://github.com/sftcd/lpwan-ov 
>>
>>> thanks
>>> Ana
>>>
>>>> On 14 May 2017, at 11:32, Stephen Farrell  wrote:
>>>>
>>>>
>>>>
>>>> Hi all,
>>>>
>>>> I've updated the overview document as planned (well, a week or
>>>> two later than planned:-). I still have two open issues that I'd
>>>> like to resolve before I'd claim that this is ready for WGLC so
>>>> I'll send separate mails on those.
>>>>
>>>> Other than that, it might be pretty close to ready, though your
>>>> comments are welcome of course. (Either on the list or as a PR
>>>> to the git repo.)
>>>>
>>>> Cheers,
>>>> S.
>>>>
>>>> On 14/05/17 10:30, internet-drafts@ietf.org wrote:
>>>>>
>>>>> A New Internet-Draft is available from the on-line Internet-Drafts =
directories.
>>>>> This draft is a work item of the IPv6 over Low Power Wide-Area Netw=
orks of the IETF.
>>>>>
>>>>>       Title           : LPWAN Overview
>>>>>       Author          : Stephen Farrell
>>>>> 	Filename        : draft-ietf-lpwan-overview-02.txt
>>>>> 	Pages           : 39
>>>>> 	Date            : 2017-05-14
>>>>>
>>>>> Abstract:
>>>>>  Low Power Wide Area Networks (LPWAN) are wireless technologies wit=
h
>>>>>  characteristics such as large coverage areas, low bandwidth, possi=
bly
>>>>>  very small packet and application layer data sizes and long batter=
y
>>>>>  life operation.  This memo is an informational overview of the set=
 of
>>>>>  LPWAN technologies being considered in the IETF and of the gaps th=
at
>>>>>  exist between the needs of those technologies and the goal of runn=
ing
>>>>>  IP in LPWANs.
>>>>>
>>>>>
>>>>> The IETF datatracker status page for this draft is:
>>>>> https://datatracker.ietf.org/doc/draft-ietf-lpwan-overview/
>>>>>
>>>>> There are also htmlized versions available at:
>>>>> https://tools.ietf.org/html/draft-ietf-lpwan-overview-02
>>>>> https://datatracker.ietf.org/doc/html/draft-ietf-lpwan-overview-02
>>>>>
>>>>> A diff from the previous version is available at:
>>>>> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-lpwan-overview-02
>>>>>
>>>>>
>>>>> Please note that it may take a couple of minutes from the time of s=
ubmission
>>>>> until the htmlized version and diff are available at tools.ietf.org=
=2E
>>>>>
>>>>> Internet-Drafts are also available by anonymous FTP at:
>>>>> ftp://ftp.ietf.org/internet-drafts/
>>>>>
>>>>> _______________________________________________
>>>>> lp-wan mailing list
>>>>> lp-wan@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/lp-wan
>>>>>
>>>>
>>>> _______________________________________________
>>>> lp-wan mailing list
>>>> lp-wan@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/lp-wan
>>>
>>> _______________________________________________
>>> lp-wan mailing list
>>> lp-wan@ietf.org 
>>> https://www.ietf.org/mailman/listinfo/lp-wan 
>>>
>>
>> _______________________________________________
>> lp-wan mailing list
>> lp-wan@ietf.org 
>> https://www.ietf.org/mailman/listinfo/lp-wan 
>=20


--6aJXca1Iu031pVFmPpuBq6obUxJx5gEvg--

--Uw7DFhld12GlG0Sts73JaCHPQUkML7gDM
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEcBAEBCAAGBQJZJU0ZAAoJEC88hzaAX42iFmEH+QENMrCTZnPLyDGg7d7+ujjZ
7igJfZzokmP8GR1UNio32HA1pSeAkvSYEXZhqaZCOP6qpVo6o7M8tskjyKHta4Ry
H64+feBCY4btKt7T/07olp932icVDC0CyVztZt4w578//2rD7rivWby4mmWEfw+Q
leOO7Mr3UL1t+Acq9VQGnBnzkAXD6bC/1BiqnhejlqD6ciSjc81QS/ZG3iBGJq3v
oxNbotpBxlD47Vio4CRrlLb77zGjbc7jlqbpjThwicelS7V3GCldKyo7TC+Y1OmP
2E27ZZqYN3RbPRbayoiSAciwInDvnwDGBgPRoqCm5Q9gVIeKhNay5O8WNuwjXRs=
=tNzi
-----END PGP SIGNATURE-----

--Uw7DFhld12GlG0Sts73JaCHPQUkML7gDM--


From nobody Wed May 24 03:35:11 2017
Return-Path: 
X-Original-To: lp-wan@ietfa.amsl.com
Delivered-To: lp-wan@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37302129492 for ; Wed, 24 May 2017 03:35:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mail-udp-cl.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 NqGKGG0MnPIz for ; Wed, 24 May 2017 03:35:07 -0700 (PDT)
Received: from mail-yw0-x234.google.com (mail-yw0-x234.google.com [IPv6:2607:f8b0:4002:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64212127286 for ; Wed, 24 May 2017 03:35:07 -0700 (PDT)
Received: by mail-yw0-x234.google.com with SMTP id l74so87081235ywe.2 for ; Wed, 24 May 2017 03:35:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mail-udp-cl.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=M0ow3/iExWGzr1xaTnZTEB8yenp647lbiWGYp1h510c=; b=kaWD0qpr5moiteR7/ECYbQeydzW8/MXFRu+b5BifMTVrENZLGlUqL6h/7ENKuuQgHX Z8UACnBSfTuuNvz4CAnQ6tWlsV+C5QLUatFEQ2vZLY97TvyQTwaisUOkO6oE1zxUg9gD A5w59DMzSdNOY8ceJIzuwEPeF+lTYII054EvDsAM1n3oWUlkBzNArKB30v6EHjGp3Wj6 nrKo2garmqVqNufLLEVpTDd8K5xjVvp39lVV7r+Q621mCbUYXkI0MncWMnU1YPlhNa9N vc9jXVYZ4hryvT4UmJt9i4KArQVk+sLv2/vhItXSD4pj7kgf314uyM9/tRk9IXDZWLlY oGEQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=M0ow3/iExWGzr1xaTnZTEB8yenp647lbiWGYp1h510c=; b=Tau871jVqoaW3vvz3df+dRBsAcm4lQNHNeHc3xWIw5xG+4DKuatJzbIHMxDk2PhWJE bLjuXYD+iKRltqLRpXR33tGZlOLZ12xS5czEnXR/JVi3CF8DGe/4JDvE0jW/spqWdLIs hVj6njQhYIdSFug7f0dUEhuE1KATqUNc+la1AuM6UVAwW2FPpxWQF3jgjXOy+VSNUkvZ POKTw91Bof/R1S4wLsWGxWB16nBE+/z5PFVImt3ND+9JP/Q6YInBpQJ/Ho6Y1+cqPgRc HnYeJdraA79BUcqXnlCF2uocfrClUHd7axTDGpdjdC5Thy3KnHIXZS7JDLh0HgbLoi/D JkXw==
X-Gm-Message-State: AODbwcD1qrlckeJ997hlhicLOpz/R296hfYgEEiFasnGcD/NCkbj749g QZd8CwnPDPIyOVSj9aZq0HHcITy5plDV4rg=
X-Received: by 10.129.183.7 with SMTP id v7mr29146680ywh.15.1495622106021; Wed, 24 May 2017 03:35:06 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.13.208.196 with HTTP; Wed, 24 May 2017 03:34:45 -0700 (PDT)
From: "Prof. Diego Dujovne" 
Date: Wed, 24 May 2017 06:34:45 -0400
Message-ID: 
To: lp-wan 
Content-Type: multipart/alternative; boundary="94eb2c1cbcba591a2a055042a812"
Archived-At: 
Subject: [lp-wan] review draft-ietf-lpwan-ipv6-static-context-hc-03 (part II)
X-BeenThere: lp-wan@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Low-Power Wide Area Networking \(LP-WAN\), also known as LPWA or Low-Rate WAN \(LR-WAN\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 May 2017 10:35:10 -0000

--94eb2c1cbcba591a2a055042a812
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

I post the review from section 8 until the end.

Fragmentation

- "If the datagram does not fit within a single L2 data unit, it SHALL

   be broken into fragments."


And if not broken into fragments, the alternative is to

drop the packet?


- "Things (End Systems)"


There was recently a discussion on using or not the term

"Things" for devices. This shall follow the results of this

discussion.


- "topology, and therefore"


remove comma.


Reliability options: discussion


- "Figure Figure 7 summarizes"


remove one "Figure"


- "provides flow control"


I don't know if this is exactly flow control in the terms

of what it is known in TCP. For TCP, one lost packet signals

that the bandwidth limit for the flow is full (probably due

to congestion), and there is no congestion at the lpwan level.

What is true is that this mechanism stops


- Figure 7


Do we differentiate Figures and Tables?


Fragmentation header formats



I am worried about the "SHALL" term. The header MUST be

as described, if not, there will be no interoperability.


I suggest to describe the fields of the fragmentation

header before the types of header. One has to wait to the

last one to understand them.

I can understand you have to create a rule for each

fragmentation reliability option used. Am I right?


-  "options,

  N equal to or "


remove CR/LF


-"The ACK

          provides"


remove CR/LF


-"sender

   renumbers the CFNs


remove CR/LF


Aborting a fragmented IPv6 datagram transmission


*As it is defined in this section by *TBD_ABORT_RX*, it would be
practical to have a list *

*of rule identifiers required to implement fragmentation.*


*- "* on- going,"


remove space.


Security considerations for fragmentation


- "{HHWH}"


what is this?






--=20
DIEGO DUJOVNE
Profesor Asociado
Escuela de Inform=C3=A1tica y Telecomunicaciones
Facultad de Ingenier=C3=ADa - Universidad Diego Portales - Chile
www.ingenieria.udp.cl
(56 2) 676 8125

--94eb2c1cbcba591a2a055042a812
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


I post the review from section 8 until the end.

Fragmentation

- "If the datagram does not fit within a sin=
gle L2 data unit, it SHALL
   be br=
oken into fragments."

And if not broken into fragments, the al=
ternative is to
drop the packet?

- "Things (End Systems)"

There was recently a discus=
sion on using or not the term
"=
Things" for devices. This shall follow the results of this
discussion.

- "topology, and there=
fore"

remove comma.
Reliability options: discussion

- "
Figure Figure 7 summa=
rizes"

remove one &qu=
ot;Figure"

- "provides flow control"

I don't know i=
f this is exactly flow control in the terms
of what it is known in TCP. For TCP, one lost packet signals
<=
pre class=3D"gmail-newpage" style=3D"font-size:13.3333px;margin-top:0px;mar=
gin-bottom:0px;color:rgb(0,0,0)">that the bandwidth limit for the flow is f=
ull (probably due
to congestion), an=
d there is no congestion at the lpwan level.
What is true is that this mechanism stops  

- Figure 7

Do we differentiate Figures and Tables?

Fragmentation header formats




I am worried about the &quo=
t;SHALL" term. The header MUST be
as described, if not, there will be no interoperability.

I sugge=
st to describe the fields of the fragmentation
header before the types of header. One has to wait to the
<=
pre class=3D"gmail-newpage" style=3D"font-size:13.3333px;margin-top:0px;mar=
gin-bottom:0px;color:rgb(0,0,0)">last one to understand them. 
I can understand you have to create a rule for e=
ach 
fragmentation reliability optio=
n used. Am I right?

- =C2=A0"options,
  N equal to or "

remove CR/LF

-"=
;The ACK
          provides"

remove CR/LF

-"sender
   renumbers the CFNs 
<=
pre class=3D"gmail-newpage" style=3D"font-size:13.3333px;margin-top:0px;mar=
gin-bottom:0px">
remove CR/LF

Aborting a fragmented =
IPv6 datagram transmission

As it is defined in this section by T=
BD_ABORT_RX, =
it would be practical to have a list 
of rule =
identifiers required to implement fragmentation.
=

- " on- going,"

remove space.

Security considerations=
 for fragmentation
=


=

- "
{HHWH}"

what is this?




-- 
DIEGO DUJOVNE
Profesor Asociado=

Escuela de Inform=C3=A1tica y Telecomunicaciones
Facultad de Ingenie=
r=C3=ADa - Universidad Diego Portales - Chile
www.ingenieria.udp.cl
(56 2) 676 81=
25




--94eb2c1cbcba591a2a055042a812--


From nobody Wed May 24 08:07:22 2017
Return-Path: 
X-Original-To: lp-wan@ietfa.amsl.com
Delivered-To: lp-wan@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 317ED129B5C for ; Wed, 24 May 2017 08:07:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.08
X-Spam-Level: 
X-Spam-Status: No, score=0.08 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] 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 RQX5wgehDATa for ; Wed, 24 May 2017 08:07:17 -0700 (PDT)
Received: from relay4-d.mail.gandi.net (relay4-d.mail.gandi.net [217.70.183.196]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61F7B129B2B for ; Wed, 24 May 2017 08:07:17 -0700 (PDT)
Received: from mfilter29-d.gandi.net (mfilter29-d.gandi.net [217.70.178.160]) by relay4-d.mail.gandi.net (Postfix) with ESMTP id 030951720A3 for ; Wed, 24 May 2017 17:07:16 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at mfilter29-d.gandi.net
Received: from relay4-d.mail.gandi.net ([IPv6:::ffff:217.70.183.196]) by mfilter29-d.gandi.net (mfilter29-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id K-i3wQV7-Kn2 for ; Wed, 24 May 2017 17:07:14 +0200 (CEST)
X-Originating-IP: 192.44.77.207
Received: from [192.168.207.230] (nat-asr-incub-v207-1x.rennes.enst-bretagne.fr [192.44.77.207]) (Authenticated sender: arun@acklio.com) by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id 815D31720CE for ; Wed, 24 May 2017 17:07:14 +0200 (CEST)
From: Arun 
To: lp-wan 
Message-ID: <43d320a7-aed7-9bde-3208-ce0c6f90b91a@acklio.com>
Date: Wed, 24 May 2017 17:07:06 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="RmNSueKpMTkHuKseKwT6IauRrfLgLEWnv"
Archived-At: 
Subject: [lp-wan]  interop for schc @ prague
X-BeenThere: lp-wan@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Low-Power Wide Area Networking \(LP-WAN\), also known as LPWA or Low-Rate WAN \(LR-WAN\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 May 2017 15:07:19 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--RmNSueKpMTkHuKseKwT6IauRrfLgLEWnv
Content-Type: multipart/mixed; boundary="WIArxqRVn6noTUk7dispG0Crw870FFQC3";
 protected-headers="v1"
From: Arun 
To: lp-wan 
Message-ID: <43d320a7-aed7-9bde-3208-ce0c6f90b91a@acklio.com>
Subject: [lp-wan] interop for schc @ prague

--WIArxqRVn6noTUk7dispG0Crw870FFQC3
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hello All,=20

Since the drafts about the ip/udp/coap has been around for a while and
nearing stability, many would have come up their implementations already.=

Do you think an inter-op for schc at the next ietf99, Prague would be
possible to have?


thanks,
Arun



--WIArxqRVn6noTUk7dispG0Crw870FFQC3--

--RmNSueKpMTkHuKseKwT6IauRrfLgLEWnv
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJZJaGbAAoJENe8HNMjzJQReXcP/it9bBpKxNZDDCy9wKxUTA7r
lDrAiMtXyG6u0PVHhmHILxCZuKOEDBIrJGAadMOwvZJf6A5Y/er4/mpr9lM6Qiad
D61cpVh7vpgKv43Of+uabsfzNdb9U0+MJ7rLmDb8urstb+q6d+oOqNELxHdPkZl6
OqM5kntQ6DAeNT5IxHmA7d/eR0vcikdIa29gjASCS4GwEBvwxOWocKHFIvqDBJCf
prasTZk2Ld+WwpUub6AencqSTDGy5GTcKAaKi1UI+xW/aIPQpK6uhY2a5NEBpmdy
0re3RXOcmnViTfClqQ8UVYy3lk/0l48MEadfqEMl7KCDloA3T3sIhOoDYMBWxDd8
fx8GY5EIz2URYbGjla4EQx/uYPA8NSkYdVXvgmEGzhylRlrMBIFy4ChXTCsTdi1W
2nQz5Uk8t5kQovCqOp5klysZVa+lnToU3Nfavoi+RgGvAJDl3cltblC8dYBnSmhx
KaWW2anXsPwHmiYt2MwVEKEApmREGsPpIK4ZkylfN6qa2wPnpjyF/Zox7ER4Abu7
hamW3uBlNm/Y2ZkyX7blsjCOhz8sTqNSHp0kYuIC5a3q2PSi/iIRjyx6IH0X6quo
/7J4uA3wHYmmMFYCdEGXblqWsRLqI/T2ryhxWE1JDQDra8VWgkE9eYkRc/D+I63T
8N5T4jBoS9X9uXTvH0cc
=jYXF
-----END PGP SIGNATURE-----

--RmNSueKpMTkHuKseKwT6IauRrfLgLEWnv--


From nobody Wed May 24 08:24:18 2017
Return-Path: 
X-Original-To: lp-wan@ietfa.amsl.com
Delivered-To: lp-wan@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB044127369 for ; Wed, 24 May 2017 08:24:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.72
X-Spam-Level: 
X-Spam-Status: No, score=-0.72 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] 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 V6rcF1jyHLUS for ; Wed, 24 May 2017 08:24:15 -0700 (PDT)
Received: from relay3-d.mail.gandi.net (relay3-d.mail.gandi.net [217.70.183.195]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC12C128ACA for ; Wed, 24 May 2017 08:24:14 -0700 (PDT)
Received: from mfilter38-d.gandi.net (mfilter38-d.gandi.net [217.70.178.169]) by relay3-d.mail.gandi.net (Postfix) with ESMTP id 30A8EA80C6 for ; Wed, 24 May 2017 17:24:13 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at mfilter38-d.gandi.net
Received: from relay3-d.mail.gandi.net ([IPv6:::ffff:217.70.183.195]) by mfilter38-d.gandi.net (mfilter38-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id tJ6zhNuBl0Gi for ; Wed, 24 May 2017 17:24:11 +0200 (CEST)
X-Originating-IP: 192.44.77.204
Received: from el-meco.rennes.enst-bretagne.fr (nat-asr-incub-b204.rennes.enst-bretagne.fr [192.44.77.204]) (Authenticated sender: ana@ackl.io) by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id 61975A80D9 for ; Wed, 24 May 2017 17:24:11 +0200 (CEST)
From: Ana Minaburo 
Content-Type: multipart/alternative; boundary="Apple-Mail=_C41696B6-E3A4-4DB4-A002-60FD85075823"
Message-Id: <337D2F1B-1751-4A49-8773-082A8C5BBE11@ackl.io>
Date: Wed, 24 May 2017 17:24:09 +0200
To: lp-wan 
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Subject: [lp-wan] Next steps on LPWAN WG
X-BeenThere: lp-wan@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Low-Power Wide Area Networking \(LP-WAN\), also known as LPWA or Low-Rate WAN \(LR-WAN\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 May 2017 15:24:18 -0000

--Apple-Mail=_C41696B6-E3A4-4DB4-A002-60FD85075823
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Hello LPWANers,

What I would like to talk about you during the meeting is about the =
future of the WG. As soon as the work is going on, and the Milestone are =
done we need to start thinking about what are the next steps we need to =
do and which are the most urgent.=20

I start a possible list of some of them, but I would like to know what =
do you think and what will be the priorities to the ML. The list is not =
in any order neither in priority so this is only some ideas, and if you =
want to add something the list is open.

Thanks

Ana


Next Steps on LPWAN WG:

- YANG data modelling for SCHC=20
- Profile Technologies. Develop the different document for each =
technology in order to define the different parameters.
- Security, all the security solution for the LPWAN
- Rules-ID=E2=80=99s management
	+ Use to identify some specific cases:
		* Fragmentation
                * Format Values
                * Rule-IDs dedicated for some specific cases as CBOR =
structure representation, fragmentation, etc
		* The way to use the Rule-Id and their configuration     =
  =09
- ICMP Compression



--Apple-Mail=_C41696B6-E3A4-4DB4-A002-60FD85075823
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

Hello LPWANers,

What I would like to talk about =
you during the meeting is about the future of the WG. As soon as the work is going on, and the Milestone are =
done we need to start thinking about what are the next steps we need to =
do and which are the most urgent. 

I start a possible list of some of them, but =
I would like to know what do you think and what will be the priorities =
to the ML. The list is not in any order neither in priority so this is =
only some ideas, and if you want to add something the list is =
open.

Thanks

Ana


Next =
Steps on LPWAN WG:

- YANG =
data modelling for SCHC 
- Profile Technologies. Develop the different =
document for each technology in order to define the different =
parameters.
- Security, all the security solution for the LPWAN
- Rules-ID=E2=80=99s =
management
	+ Use =
to identify some specific cases:
		* =
Fragmentation
                * =
Format Values
      =
          * Rule-IDs dedicated for some =
specific cases as CBOR structure representation, fragmentation, =
etc
		* The way to use the =
Rule-Id and their configuration       	=

- ICMP =
Compression


=

--Apple-Mail=_C41696B6-E3A4-4DB4-A002-60FD85075823--


From nobody Wed May 24 08:26:52 2017
Return-Path: 
X-Original-To: lp-wan@ietfa.amsl.com
Delivered-To: lp-wan@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6C0D127369 for ; Wed, 24 May 2017 08:26:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level: 
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=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=mail-udp-cl.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 Bq66zHLdkMHQ for ; Wed, 24 May 2017 08:26:47 -0700 (PDT)
Received: from mail-yw0-x229.google.com (mail-yw0-x229.google.com [IPv6:2607:f8b0:4002:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41788129AFC for ; Wed, 24 May 2017 08:26:47 -0700 (PDT)
Received: by mail-yw0-x229.google.com with SMTP id b68so90883464ywe.3 for ; Wed, 24 May 2017 08:26:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mail-udp-cl.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=qHa9rKMDukYERN4rhYNbvBF7tYe+FKr04RA7EmMjPJ0=; b=Cryip+6yA0MM/tOcDCNQguCvI6bzGPnq+vHzpriB/VKOWyI55nt8fo9f4uOA0VEAxV DDgYie7LwjyGz01QVS/4RLDBeO5oN+KPyyYgLoFYLZsLbJknJFF+JoJX/rEhuN5MN25A WPPgJtB5hmmnSP9o1TNFkO9kel5JN8jPgaM1ZxYURfF3ehoGxpoNxuCna/EvnIqgRXPC WcnxnUxuUPWTXvRnJp8Xn9YkGD0p8CKoa+MwUKCKqUIQzrHIChkppxxjR8cv1ieMM7kI vfq5N8LfxBFEsTFHfUwAKBBmoguMtmO09jwn+DAwpFpaR+WdMnHfMf5TzVJZl7DGwta/ Xqow==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=qHa9rKMDukYERN4rhYNbvBF7tYe+FKr04RA7EmMjPJ0=; b=OnW8ac2YsBwFpf6+L+jJMZ9mXNIAc1hmrCw+s+So6jJ6Q3wAg9Kd61kO5v4Wf+HlNc 3wEx3ddeHmxT2c5jgHfYd0XIQcFhYEJ/Fjs21E2fOY40vEUVCHr2o9VSr0fKag8pvXFE CsbbNB5V+5VZs4FXwetKA/DSzUVOb2gOgJm9mMI47lmfEcWA8eSSJi8lpO2v47sS0eHm QJTZW7tLbKfuPA+i5FKJYJzS9PleIFOwQWtHrGxOyxYjbAUk612vNoNRDOK8QP2PL11B E6KnPoHPBAHgY2J05hw2S2xleFOe8x0D7SVYfkC56b09jbuKa7EoTKczjGAAjL0ciRWg iRKA==
X-Gm-Message-State: AODbwcAGA69ewco3xxgrdz6oZfgZb/duV0Mv6d89UWiRpcFCTYe8XOvu WokkoD7esD8k1wLoGdt2HpdGZHYgx4VX
X-Received: by 10.13.215.148 with SMTP id z142mr30202128ywd.170.1495639606174;  Wed, 24 May 2017 08:26:46 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.13.208.196 with HTTP; Wed, 24 May 2017 08:26:25 -0700 (PDT)
In-Reply-To: <337D2F1B-1751-4A49-8773-082A8C5BBE11@ackl.io>
References: <337D2F1B-1751-4A49-8773-082A8C5BBE11@ackl.io>
From: "Prof. Diego Dujovne" 
Date: Wed, 24 May 2017 11:26:25 -0400
Message-ID: 
To: lp-wan 
Content-Type: multipart/alternative; boundary="94eb2c075a607035bc055046bb1c"
Archived-At: 
Subject: Re: [lp-wan] Next steps on LPWAN WG
X-BeenThere: lp-wan@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Low-Power Wide Area Networking \(LP-WAN\), also known as LPWA or Low-Rate WAN \(LR-WAN\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 May 2017 15:26:51 -0000

--94eb2c075a607035bc055046bb1c
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Ana,
       We are writing a draft for ICMP compression,
we hope to have it finished in a couple of weeks.
Regards,

                                     Diego Dujovne

2017-05-24 11:24 GMT-04:00 Ana Minaburo :

> Hello LPWANers,
>
> What I would like to talk about you during the meeting is about the futur=
e
> of the WG. As soon as the work is going on, and the Milestone are done we
> need to start thinking about what are the next steps we need to do and
> which are the most urgent.
>
> I start a possible list of some of them, but I would like to know what do
> you think and what will be the priorities to the ML. The list is not in a=
ny
> order neither in priority so this is only some ideas, and if you want to
> add something the list is open.
>
> Thanks
>
> Ana
>
>
> Next Steps on LPWAN WG:
>
> - YANG data modelling for SCHC
> - Profile Technologies. Develop the different document for each technolog=
y
> in order to define the different parameters.
> - Security, all the security solution for the LPWAN
> - Rules-ID=E2=80=99s management
> + Use to identify some specific cases:
> * Fragmentation
>                 * Format Values
>                 * Rule-IDs dedicated for some specific cases as CBOR
> structure representation, fragmentation, etc
> * The way to use the Rule-Id and their configuration
> - ICMP Compression
>
>
>
> _______________________________________________
> lp-wan mailing list
> lp-wan@ietf.org
> https://www.ietf.org/mailman/listinfo/lp-wan
>
>


--=20
DIEGO DUJOVNE
Profesor Asociado
Escuela de Inform=C3=A1tica y Telecomunicaciones
Facultad de Ingenier=C3=ADa - Universidad Diego Portales - Chile
www.ingenieria.udp.cl
(56 2) 676 8125

--94eb2c075a607035bc055046bb1c
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Ana,
=C2=A0 =C2=A0 =C2=A0 =C2=A0We are writing a draft=
 for ICMP compression,
we hope to have it finished in a couple of=
 weeks.
Regards,

=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Diego Dujovne

2017-05-24 11:24 GMT-04:00 =
Ana Minaburo <ana@ackl.io>:
Hello LPWANers,
What I would like to talk=
 about you during the meeting is about the future of the WG.=C2=A0As soon as the wo=
rk is going on, and the=C2=A0Milestone are done we need to start thinking a=
bout what are the next steps we need to do and which are the most urgent.=
=C2=A0

I start a possible list of some of them, but I would like to know wh=
at do you think and what will be the priorities to the ML. The list is not =
in any order neither in priority so this is only some ideas, and if you wan=
t to add something the list is open.

Thanks

Ana


Next Ste=
ps on LPWAN WG:

- YANG data modelling for SCHC=C2=A0
-=
 Profile Technologies. Develop the different document for each technology i=
n order to define the different parameters.
- S=
ecurity, all the security solution for the LPWAN
- Rules-ID=E2=80=99s management
	+ Use to identify some specif=
ic cases:
		* Fragmentation
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 * Format Values
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 * Rule-IDs dedicated for some specific cases as CB=
OR structure representation, fragmentation, etc
		* The way t=
o use the Rule-Id and their configuration=C2=A0 =C2=A0 =C2=A0 =C2=A0	
=

- ICMP Compre=
ssion



__________________________________=
_____________

lp-wan mailing list

lp-wan@ietf.org

https://www.ietf.org/mailman/listinfo/lp-wan




-- 
=

DIEGO DUJOVNE
Profesor Asociado
Escuela de=
 Inform=C3=A1tica y Telecomunicaciones
Facultad de Ingenier=C3=ADa - Uni=
versidad Diego Portales - Chile
www.ingenieria.udp.cl
(56 2) 676 8125




--94eb2c075a607035bc055046bb1c--


From nobody Wed May 24 08:27:26 2017
Return-Path: 
X-Original-To: lp-wan@ietfa.amsl.com
Delivered-To: lp-wan@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABB44127369 for ; Wed, 24 May 2017 08:27:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.699
X-Spam-Level: 
X-Spam-Status: No, score=-0.699 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 cWp154SYnhOJ for ; Wed, 24 May 2017 08:27:18 -0700 (PDT)
Received: from relay2-d.mail.gandi.net (relay2-d.mail.gandi.net [IPv6:2001:4b98:c:538::194]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1160B129B53 for ; Wed, 24 May 2017 08:27:18 -0700 (PDT)
Received: from mfilter2-d.gandi.net (mfilter2-d.gandi.net [217.70.178.140]) by relay2-d.mail.gandi.net (Postfix) with ESMTP id 30610C5A4E for ; Wed, 24 May 2017 17:27:16 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at mfilter2-d.gandi.net
Received: from relay2-d.mail.gandi.net ([IPv6:::ffff:217.70.183.194]) by mfilter2-d.gandi.net (mfilter2-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id Y_gu3iKOtth5 for ; Wed, 24 May 2017 17:27:14 +0200 (CEST)
X-Originating-IP: 192.44.77.207
Received: from [192.168.207.230] (nat-asr-incub-v207-1x.rennes.enst-bretagne.fr [192.44.77.207]) (Authenticated sender: arun@acklio.com) by relay2-d.mail.gandi.net (Postfix) with ESMTPSA id 3735AC5A87 for ; Wed, 24 May 2017 17:27:13 +0200 (CEST)
To: lp-wan@ietf.org
References: <337D2F1B-1751-4A49-8773-082A8C5BBE11@ackl.io>
From: Arun 
Message-ID: <34fcea3f-bcb9-e616-106b-6a388e09b73e@acklio.com>
Date: Wed, 24 May 2017 17:27:07 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <337D2F1B-1751-4A49-8773-082A8C5BBE11@ackl.io>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="BF1JVacmMV1w7LGC2jE3e9VJbSFOExJOb"
Archived-At: 
Subject: Re: [lp-wan] Next steps on LPWAN WG
X-BeenThere: lp-wan@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Low-Power Wide Area Networking \(LP-WAN\), also known as LPWA or Low-Rate WAN \(LR-WAN\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 May 2017 15:27:23 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--BF1JVacmMV1w7LGC2jE3e9VJbSFOExJOb
Content-Type: multipart/mixed; boundary="jH8iFu55futMBwEpa4WnaMsJvSJOgDbBj";
 protected-headers="v1"
From: Arun 
To: lp-wan@ietf.org
Message-ID: <34fcea3f-bcb9-e616-106b-6a388e09b73e@acklio.com>
Subject: Re: [lp-wan] Next steps on LPWAN WG
References: <337D2F1B-1751-4A49-8773-082A8C5BBE11@ackl.io>
In-Reply-To: <337D2F1B-1751-4A49-8773-082A8C5BBE11@ackl.io>

--jH8iFu55futMBwEpa4WnaMsJvSJOgDbBj
Content-Type: multipart/alternative;
 boundary="------------0470082E410753CB9E9300EE"

This is a multi-part message in MIME format.
--------------0470082E410753CB9E9300EE
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

+1, ICMP compression.


On 24/05/2017 17:24, Ana Minaburo wrote:
> Hello LPWANers,
>
> What I would like to talk about you during the meeting is about the
> future of the WG. As soon as the work is going on, and the Milestone
> are done we need to start thinking about what are the next steps we
> need to do and which are the most urgent.=20
>
> I start a possible list of some of them, but I would like to know what
> do you think and what will be the priorities to the ML. The list is
> not in any order neither in priority so this is only some ideas, and
> if you want to add something the list is open.
>
> Thanks
>
> Ana
>
>
> Next Steps on LPWAN WG:
>
> - YANG data modelling for SCHC=20
> - Profile Technologies. Develop the different document for each
> technology in order to define the different parameters.
> - Security, all the security solution for the LPWAN
> - Rules-ID=92s management
> + Use to identify some specific cases:
> * Fragmentation
>                 * Format Values
>                 * Rule-IDs dedicated for some specific cases as CBOR
> structure representation, fragmentation, etc
> * The way to use the Rule-Id and their configuration      =20
> - ICMP Compression
>
>
>
>
> _______________________________________________
> lp-wan mailing list
> lp-wan@ietf.org
> https://www.ietf.org/mailman/listinfo/lp-wan


--------------0470082E410753CB9E9300EE
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable


  
    
  
  
    
+1, ICMP compression.

    

    

    
On 24/05/2017 17:24, Ana Minaburo
      wrote:

    

    

      
      Hello LPWANers,
      


        

      
What I =
would
          like to talk about you during the meeting is about the future
          of the WG.=A0As soon as the work is
            going on, and the=A0Milestone are done we need to start
            thinking about what are the next steps we need to do and
            which are the most urgent.=A0

        

        I start a possible list of some of them, but I would=

          like to know what do you think and what will be the priorities
          to the ML. The list is not in any order neither in priority so
          this is only some ideas, and if you want to add something the
          list is open.

        

        Thanks

        

        Ana

        

        

        Next Steps on LPWAN WG:

        

        - YANG data modelling for SCHC=A0

        - Profile Technologies. Develop the different
          document for each technology in order to define the different
          parameters.

        - Security, all the security solution for the LPWAN<=
/span>

        - Rules-ID=92s management

        	+
          Use to identify some specific cases:

        		*
          Fragmentation

        =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 * Format Values

      
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 * Ru=
le-IDs dedicated
          for some specific cases as CBOR structure representation,
          fragmentation, etc

      
		*
          The way to use the Rule-Id and their configuration=A0 =A0 =A0 =A0=
	

      
- ICMP Compression

      


        

      


        

      

      

      

      
_______________________________________________
lp-wan mailing list
lp-=
wan@ietf.org
https://www.ietf.org/mailman/listinfo/lp-wan


    

    

  


--------------0470082E410753CB9E9300EE--

--jH8iFu55futMBwEpa4WnaMsJvSJOgDbBj--

--BF1JVacmMV1w7LGC2jE3e9VJbSFOExJOb
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJZJaZLAAoJENe8HNMjzJQRtqQQAJMz7xhnqdWdwLBO0quV7V5K
dMZ2MJvA677+DaeCTvrhZFzTgPoxqUe1mHN9loxCFPjoQJdVGH4aVM33FvKcgGw8
iYpk03SDeuhV7Udb6CsI8ltn+1xEABYf6NYgVlgHeyKkVnon8Zj8j++BMw2UlEeZ
dKphKMzwKUd+Imm6wKod0y7OvVaPXitLdMY5Qi6Yb2JKvb6+KimNT4cGbpFdIq8x
ZobTz93G1ll8a262PcJmWQT383kvQ+iybNeAmysnDuj6g62c5tfG23tLFNREwgc2
+fgCRY3rScxXpokU/TJcL8tL1gf44M4k3vAvJHDBqnAiYXRoCQfmNukMVbX+tkvM
F0GUygpGRC2hgBZbnR+M7fB2E6FPIQ5OhRr8KHIOTt+cyuVLa4SOh1kywxpRbQ19
/bzQ7xCuQJpM4fp+9DRnc/kK49UBpQmeE5S8uM4LX/0QFUbHeP4sGdhZB926YmR+
giS3bw5zJe4uGu9iwjDDhb71vV0Lxi7jRyVy1WLoIsQY8KCjI5wljB4u3BEuv6j8
JC+SezPW10j8UI2q2kb6nUfOZYjUh8AhBAZiaaHjYSd7RuCoSELo0hEqyq3NpjhS
wJmqKbjxr0pLMHyXh7XUb1155/jl+/FP6VR2gZiIbh76w5d/xOSgHG1mxG4wb5tZ
Cjze3iQbI3MidARgro9M
=A24M
-----END PGP SIGNATURE-----

--BF1JVacmMV1w7LGC2jE3e9VJbSFOExJOb--


From nobody Thu May 25 07:11:50 2017
Return-Path: 
X-Original-To: lp-wan@ietfa.amsl.com
Delivered-To: lp-wan@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFF17129AAA for ; Thu, 25 May 2017 07:11:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.199
X-Spam-Level: 
X-Spam-Status: No, score=-1.199 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=patavinatech-com.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 tgZNZ1kxw2lw for ; Thu, 25 May 2017 07:11:47 -0700 (PDT)
Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::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 C4AA7129530 for ; Thu, 25 May 2017 07:11:47 -0700 (PDT)
Received: by mail-wm0-x236.google.com with SMTP id e127so106977768wmg.1 for ; Thu, 25 May 2017 07:11:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=patavinatech-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=i9lXriGS7R3XFhQ2esHA2+SlG2/ljGsMeHcHgS+IBFE=; b=WZmqTVfuOiKCJx46UmbTdhEMNapd/enTa8aXMBd5VkuSVA0cYin7DOYZoCzp2zLgqQ ZwcJlgUAqCt9sq2ymEdQ8sC2ChEQfJinizFwJXS9TwnHSYrqI5gwYt0IqxChwxBaWpry 8d5vMLh1PzNICS8HhqGHB1XjP8ZtbOEgZUjXhMMx17/grreou8O/+yq/UgWvr6/DFMuF FDe+3fGF35sgaazL0nnbIJpClvo7QfdUV2RPlkcP2kmuAK90cmRbdqxgME1PvtjshTAT PmDeDg+f2ESXfz0ni4WsbCPxgk9k87DCIFmLzXwIrxgVLPUPkjffGiAgdXN+zrSDSr7j J7nQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=i9lXriGS7R3XFhQ2esHA2+SlG2/ljGsMeHcHgS+IBFE=; b=uU7GXd9Sq7tCc1T4PTVf1wbLXtXurYsIzt8ZNFfoAxP4GbChYAHuWEzeiSwGV5nVPZ mme0OD2mZXXOowKyRwv+0fgEFK+WO+7kXoNhtLzE6kxwIcQ+GGz4ulhbVWiOvmf53GK8 ToFB9dYmujREjLoIlwogZFOVmZ4CG+s7c0qwOB+1fzx0fogtUcDrSNu0dgB/buL1OIY0 0Eocxb4A1S/r2myeneqcnLMgu4r8ghhebigniDrnlC3LoT64jk0T4IO5bv/lO+UDH01d XvMuMMIOe2Mj2uePxscdQo20+8X2WG23bw1tiDydR8O8/i+NN1vYT8W+Fpd0w3bfx8Dy yMfA==
X-Gm-Message-State: AODbwcB13NX0go+TlnEe+lBVZzUN0wLQ4m/Ek8JppkjknlgcW2v9i5QZ L/Gwtx0Hsc/AjwSVfVwBHg==
X-Received: by 10.28.23.131 with SMTP id 125mr9713247wmx.42.1495721506221; Thu, 25 May 2017 07:11:46 -0700 (PDT)
Received: from [10.8.8.21] ([185.183.104.139]) by smtp.gmail.com with ESMTPSA id l1sm9204054wrl.15.2017.05.25.07.11.45 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 25 May 2017 07:11:45 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_0144A094-7C51-4E17-9691-90CA481A7749"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Lorenzo Vangelista 
X-Mailbutler-Link-Tracking-Uuid: 
In-Reply-To: <337D2F1B-1751-4A49-8773-082A8C5BBE11@ackl.io>
Date: Thu, 25 May 2017 16:11:31 +0200
Cc: lp-wan 
Message-Id: <74DB7381-5C61-4067-B5CF-C5AB77A1C8B9@patavinatech.com>
References: <337D2F1B-1751-4A49-8773-082A8C5BBE11@ackl.io>
To: Ana Minaburo 
X-Mailer: Apple Mail (2.3273)
Archived-At: 
Subject: Re: [lp-wan] Next steps on LPWAN WG
X-BeenThere: lp-wan@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Low-Power Wide Area Networking \(LP-WAN\), also known as LPWA or Low-Rate WAN \(LR-WAN\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 25 May 2017 14:11:50 -0000

--Apple-Mail=_0144A094-7C51-4E17-9691-90CA481A7749
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

+1 ICMP

Lorenzo=20
> On 24 May 2017, at 17:24, Ana Minaburo  wrote:
>=20
> Hello LPWANers,
>=20
> What I would like to talk about you during the meeting is about the =
future of the WG. As soon as the work is going on, and the Milestone are =
done we need to start thinking about what are the next steps we need to =
do and which are the most urgent.=20
>=20
> I start a possible list of some of them, but I would like to know what =
do you think and what will be the priorities to the ML. The list is not =
in any order neither in priority so this is only some ideas, and if you =
want to add something the list is open.
>=20
> Thanks
>=20
> Ana
>=20
>=20
> Next Steps on LPWAN WG:
>=20
> - YANG data modelling for SCHC=20
> - Profile Technologies. Develop the different document for each =
technology in order to define the different parameters.
> - Security, all the security solution for the LPWAN
> - Rules-ID=E2=80=99s management
> 	+ Use to identify some specific cases:
> 		* Fragmentation
>                 * Format Values
>                 * Rule-IDs dedicated for some specific cases as CBOR =
structure representation, fragmentation, etc
> 		* The way to use the Rule-Id and their configuration     =
  =09
> - ICMP Compression
>=20
>=20
> _______________________________________________
> lp-wan mailing list
> lp-wan@ietf.org
> https://www.ietf.org/mailman/listinfo/lp-wan


--Apple-Mail=_0144A094-7C51-4E17-9691-90CA481A7749
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

+1 ICMP

Lorenzo 
On 24 May 2017, at 17:24, Ana Minaburo <ana@ackl.io> =
wrote:

Hello =
LPWANers,

What I would like to talk about =
you during the meeting is about the future of the WG. As soon as the work is going on, and the Milestone are =
done we need to start thinking about what are the next steps we need to =
do and which are the most urgent. 

I start a possible list of some of them, but =
I would like to know what do you think and what will be the priorities =
to the ML. The list is not in any order neither in priority so this is =
only some ideas, and if you want to add something the list is =
open.

Thanks

Ana


Next =
Steps on LPWAN WG:

- YANG =
data modelling for SCHC 
- Profile Technologies. Develop the different =
document for each technology in order to define the different =
parameters.
- Security, all the security solution for the LPWAN
- Rules-ID=E2=80=99s =
management
	+ Use =
to identify some specific cases:
		* =
Fragmentation
                * =
Format Values
      =
          * Rule-IDs dedicated for some =
specific cases as CBOR structure representation, fragmentation, =
etc
		* The way to use the =
Rule-Id and their configuration       	=

- ICMP =
Compression


____________________________________________=
___
lp-wan mailing list
lp-wan@ietf.org
https://www.ietf.org/mailman/listinfo/lp-wan

=

--Apple-Mail=_0144A094-7C51-4E17-9691-90CA481A7749--


From nobody Thu May 25 07:49:02 2017
Return-Path: 
X-Original-To: lp-wan@ietf.org
Delivered-To: lp-wan@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CE4D11200FC; Thu, 25 May 2017 07:48:53 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
Cc: lp-wan@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.51.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <149572373378.8620.79871453718961896@ietfa.amsl.com>
Date: Thu, 25 May 2017 07:48:53 -0700
Archived-At: 
Subject: [lp-wan] I-D Action: draft-ietf-lpwan-overview-03.txt
X-BeenThere: lp-wan@ietf.org
X-Mailman-Version: 2.1.22
List-Id: "Low-Power Wide Area Networking \(LP-WAN\), also known as LPWA or Low-Rate WAN \(LR-WAN\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 25 May 2017 14:48:54 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IPv6 over Low Power Wide-Area Networks of the IETF.

        Title           : LPWAN Overview
        Author          : Stephen Farrell
	Filename        : draft-ietf-lpwan-overview-03.txt
	Pages           : 41
	Date            : 2017-05-25

Abstract:
   Low Power Wide Area Networks (LPWAN) are wireless technologies with
   characteristics such as large coverage areas, low bandwidth, possibly
   very small packet and application layer data sizes and long battery
   life operation.  This memo is an informational overview of the set of
   LPWAN technologies being considered in the IETF and of the gaps that
   exist between the needs of those technologies and the goal of running
   IP in LPWANs.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-lpwan-overview/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-lpwan-overview-03
https://datatracker.ietf.org/doc/html/draft-ietf-lpwan-overview-03

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-lpwan-overview-03


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 May 25 07:52:35 2017
Return-Path: 
X-Original-To: lp-wan@ietfa.amsl.com
Delivered-To: lp-wan@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C60EC129AE3 for ; Thu, 25 May 2017 07:52:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.302
X-Spam-Level: 
X-Spam-Status: No, score=-4.302 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_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie
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 E_HKgAjaFk68 for ; Thu, 25 May 2017 07:52:30 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F2131200FC for ; Thu, 25 May 2017 07:52:30 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 35B3ABE64; Thu, 25 May 2017 15:52:28 +0100 (IST)
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YqnNDBHCDHIG; Thu, 25 May 2017 15:52:28 +0100 (IST)
Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 77D8ABE58; Thu, 25 May 2017 15:52:27 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1495723948; bh=HEt3OrOAueiQchOqMjh1P4HJJXE6PS/AX7GTsWld5Sw=; h=Subject:References:To:Cc:From:Date:In-Reply-To:From; b=rv87m1Dh3hcg5XeroTGHy10Qn4SLRzQ+C44xqFkegJamQlke0KyyWEz1zMfPgr+mE 5JGcxUy+pHNpDLLlcoy7zGD30p+gPIF6gQH1KCEjqCftt0ITcHbrrIcQdZJNu9tkhb 2XQT+7sON/OP4VMXLG30HZYY/yxWVhhLPpQvi/UA=
References: <149572373378.8620.79871453718961896@ietfa.amsl.com>
To: "lpwan-chairs@tools.ietf.org" 
Cc: lp-wan 
From: Stephen Farrell 
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
X-Forwarded-Message-Id: <149572373378.8620.79871453718961896@ietfa.amsl.com>
Message-ID: <222c950f-77f8-601b-afcf-075ba566b0df@cs.tcd.ie>
Date: Thu, 25 May 2017 15:52:21 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1
MIME-Version: 1.0
In-Reply-To: <149572373378.8620.79871453718961896@ietfa.amsl.com>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="98t1kCwPAT5h2aMjettb5fg80SoquGR4U"
Archived-At: 
Subject: [lp-wan] Fwd:  I-D Action: draft-ietf-lpwan-overview-03.txt
X-BeenThere: lp-wan@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Low-Power Wide Area Networking \(LP-WAN\), also known as LPWA or Low-Rate WAN \(LR-WAN\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 25 May 2017 14:52:33 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--98t1kCwPAT5h2aMjettb5fg80SoquGR4U
Content-Type: multipart/mixed; boundary="fHQu6JsQueEeFgKvqjIik2fJfw3sEEj7i";
 protected-headers="v1"
From: Stephen Farrell 
To: "lpwan-chairs@tools.ietf.org" 
Cc: lp-wan 
Message-ID: <222c950f-77f8-601b-afcf-075ba566b0df@cs.tcd.ie>
Subject: Fwd: [lp-wan] I-D Action: draft-ietf-lpwan-overview-03.txt
References: <149572373378.8620.79871453718961896@ietfa.amsl.com>
In-Reply-To: <149572373378.8620.79871453718961896@ietfa.amsl.com>

--fHQu6JsQueEeFgKvqjIik2fJfw3sEEj7i
Content-Type: text/plain; charset=utf-8
Content-Language: en-GB
Content-Transfer-Encoding: quoted-printable


Hi Alexander, Pascal,

While nothing is ever perfect, I think this is ready
for you to consider doing a WGLC or whatever you think
is the right next step, if you're happy enough with it.

Comments as always are welcome though, and as usual
ideally as a PR for the XML file in [1].

Cheers,
S.

[1] https://github.com/sftcd/lpwan-ov

-------- Forwarded Message --------
Subject: [lp-wan] I-D Action: draft-ietf-lpwan-overview-03.txt
Date: Thu, 25 May 2017 07:48:53 -0700
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
CC: lp-wan@ietf.org


A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the IPv6 over Low Power Wide-Area Networks
of the IETF.

        Title           : LPWAN Overview
        Author          : Stephen Farrell
	Filename        : draft-ietf-lpwan-overview-03.txt
	Pages           : 41
	Date            : 2017-05-25

Abstract:
   Low Power Wide Area Networks (LPWAN) are wireless technologies with
   characteristics such as large coverage areas, low bandwidth, possibly
   very small packet and application layer data sizes and long battery
   life operation.  This memo is an informational overview of the set of
   LPWAN technologies being considered in the IETF and of the gaps that
   exist between the needs of those technologies and the goal of running
   IP in LPWANs.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-lpwan-overview/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-lpwan-overview-03
https://datatracker.ietf.org/doc/html/draft-ietf-lpwan-overview-03

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-lpwan-overview-03


Please note that it may take a couple of minutes from the time of submiss=
ion
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
lp-wan mailing list
lp-wan@ietf.org
https://www.ietf.org/mailman/listinfo/lp-wan



--fHQu6JsQueEeFgKvqjIik2fJfw3sEEj7i--

--98t1kCwPAT5h2aMjettb5fg80SoquGR4U
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEcBAEBCAAGBQJZJu+nAAoJEC88hzaAX42iaMgIAJvMc7eTXuNJXPFDzWDihsa9
M74VJxCZOcHzu4OmDpxX0Q6ShrN7PTll4YX1HsDQPvqPGoB/yNc4VnpMVPatrIUm
TP4yDJJzDC9s7mECIBxh5tO8vi2NKVVZakz+CWBHzSOCNq1fyoFe/xQ3gVtspbEC
hDa0Mc+0K3gldyx7aWkqhdG7ptLVKj2g7nQAc6Ixb1XAHXgw+53XcEI/y2ZKGqCi
q2ATQ/QRyByxyYY2X6T/pwcrF5IJ3iCY65fDN8QXalsCtSKmkmINCACEmPj/xVbi
NVC8LI9xBa4eet/ujrGRY7fr1pWY+uvYBUTccXA0POaj+GWTnRxEc7KWfCc49pA=
=2ZJJ
-----END PGP SIGNATURE-----

--98t1kCwPAT5h2aMjettb5fg80SoquGR4U--


From nobody Mon May 29 09:33:43 2017
Return-Path: 
X-Original-To: lp-wan@ietfa.amsl.com
Delivered-To: lp-wan@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 250ED126C26 for ; Mon, 29 May 2017 09:33:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.08
X-Spam-Level: 
X-Spam-Status: No, score=0.08 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] 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 gOwt0uZEXAER for ; Mon, 29 May 2017 09:33:40 -0700 (PDT)
Received: from relay4-d.mail.gandi.net (relay4-d.mail.gandi.net [217.70.183.196]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 580C31201FA for ; Mon, 29 May 2017 09:33:40 -0700 (PDT)
Received: from [IPv6:2001:660:7301:3728:143:65e6:ae18:a847] (unknown [IPv6:2001:660:7301:3728:143:65e6:ae18:a847]) (Authenticated sender: alex@ackl.io) by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id 89E371720BF for ; Mon, 29 May 2017 18:33:35 +0200 (CEST)
From: Alexander Pelov 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Message-Id: 
Date: Mon, 29 May 2017 18:33:35 +0200
To: lp-wan 
X-Mailer: Apple Mail (2.3273)
Archived-At: 
Subject: [lp-wan] Window mode as default fragmentation in SCHC + Minutes from Interim on 24/05
X-BeenThere: lp-wan@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Low-Power Wide Area Networking \(LP-WAN\), also known as LPWA or Low-Rate WAN \(LR-WAN\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 29 May 2017 16:33:42 -0000

Dear all,

The minutes from the last interim meeting have been uploaded and can be =
found at the following address: =
https://www.ietf.org/proceedings/interim-2017-lpwan-03/minutes/minutes-int=
erim-2017-lpwan-03-201705241600-00

One of the main topics that were discussed was the advancement of the =
fragmentation part of the IP/UDP SCHC document ( =
https://tools.ietf.org/html/draft-ietf-lpwan-ipv6-static-context-hc-03 =
).=20

During the call we have reached a rough consensus that the Window mode =
covers all use-cases, is simple (from implementation and protocol point =
of view), is well understood, and can be included as a default mode for =
fragmentation in the RFC.=20

We have also indicated that there are other ways of doing the =
fragmentation (most notably the Packet mode), but some corner cases =
still need to be covered (e.g. bitmap sizes bigger than available =
payload limiting the MTU to less than 1280), and some advanced ways of =
actually solving this (Bloom filters were mentioned I think). These are =
all interesting ideas and they merit a longer discussion to find the =
right balance. These are to be kept in a separate document, which can =
continue its life independently, and if the WG decides can be included =
as a future WG item. If a future devices implement these other =
fragmentation mechanisms, they will be perfectly compatible with the =
default Window mode (the Rule ID can indicate which fragmentation mode =
is used).

We would like to confirm that you approve the Window mode as the default =
mode for fragmentation to be included in the SCHC IP/UDP document.=20

Best,
The chairs


From nobody Mon May 29 11:01:01 2017
Return-Path: 
X-Original-To: lp-wan@ietfa.amsl.com
Delivered-To: lp-wan@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A958129AFC for ; Mon, 29 May 2017 11:01:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.912
X-Spam-Level: 
X-Spam-Status: No, score=-2.912 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_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sigfoxgroup.onmicrosoft.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 mVw8_BqbF0ed for ; Mon, 29 May 2017 11:00:57 -0700 (PDT)
Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00123.outbound.protection.outlook.com [40.107.0.123]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E09C129AF4 for ; Mon, 29 May 2017 11:00:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sigfoxgroup.onmicrosoft.com; s=selector1-sigfox-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=ASYx6kVsCB+u/mRQkHNhaM/QRBV59tx54+5VHEz6Y2k=; b=PRjkWTtyo7UsAxRXatgJQKa9Z21NvmW4ihZd5sC88/SM4bLaGzuwvzjqQGJsaqlNs57oCoMr/mJg2CAV4m0DaJi6zQ+UdZXjWm/cHW3gcw5LZQcqTEty1ygyrphm3654oUs35YizD9X1HCDgx87tmpsc2dZrQZbwJnvpWBa9biY=
Received: from DB6PR08MB2679.eurprd08.prod.outlook.com (10.175.235.12) by DB6PR08MB2679.eurprd08.prod.outlook.com (10.175.235.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1124.9; Mon, 29 May 2017 18:00:53 +0000
Received: from DB6PR08MB2679.eurprd08.prod.outlook.com ([fe80::3c08:54b8:1c7c:498a]) by DB6PR08MB2679.eurprd08.prod.outlook.com ([fe80::3c08:54b8:1c7c:498a%13]) with mapi id 15.01.1124.009; Mon, 29 May 2017 18:00:53 +0000
From: Juan Carlos Zuniga 
To: Alexander Pelov , lp-wan 
Thread-Topic: [lp-wan] Window mode as default fragmentation in SCHC + Minutes from Interim on 24/05
Thread-Index: AQHS2JlZVZYBIug+0UOzL245ZsvsG6ILmJLg
Date: Mon, 29 May 2017 18:00:53 +0000
Message-ID: 
References: 
In-Reply-To: 
Accept-Language: en-CA, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: ackl.io; dkim=none (message not signed) header.d=none;ackl.io; dmarc=none action=none header.from=sigfox.com;
x-originating-ip: [104.163.152.104]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DB6PR08MB2679; 7:mpf+SJL222T/0Ncl2ISFqL+mueFnCgNDaG+eTvzHq2kgprHC+LVF/hVz9QVOrRiEz+NIsiUFF/2bcz5/4I1LrzLBmNcYvrImwEjCZ9OTgNAUmpTU3+TKIjDJLuJUnDtiE5Wb7KiaO5Lrm/DduF6vbX9WFlVkmoF2sOnnGJPw+2MfgHDA7rkTmtwoPn5CJBtfpftR1UvQyI9Uo6g7U8kI3HJbAkOVykCYFfSrxbdho4uYPa7yqj4FJk7h4h1KbtSSfhbfxj0KJhe1C4xjuWlu4lw1EE+pAazwD7RNf6u/1AYC7PJt0Q4VabOl2qx54HUXTf5PT/n8bLz8UX7TerAf7Q==
x-ms-traffictypediagnostic: DB6PR08MB2679:
x-ms-office365-filtering-correlation-id: dde2f7ca-e739-4dbd-16a2-08d4a6bca61b
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081)(201702281549075); SRVR:DB6PR08MB2679; 
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(100405760836317);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(93006095)(93001095)(6041248)(20161123558100)(20161123564025)(20161123560025)(20161123562025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148); SRVR:DB6PR08MB2679; BCL:0; PCL:0; RULEID:; SRVR:DB6PR08MB2679; 
x-forefront-prvs: 0322B4EDE1
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39450400003)(39400400002)(39410400002)(39830400002)(13464003)(377454003)(25786009)(3846002)(2900100001)(966005)(7696004)(189998001)(6436002)(76176999)(38730400002)(14454004)(50986999)(99286003)(6306002)(9686003)(6506006)(6116002)(53546009)(6246003)(7736002)(102836003)(53936002)(478600001)(66066001)(86362001)(2906002)(8936002)(305945005)(5660300001)(81166006)(5250100002)(55016002)(8676002)(33656002)(3660700001)(3280700002)(74316002)(54356999)(27393003)(781001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB6PR08MB2679; H:DB6PR08MB2679.eurprd08.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: sigfox.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 29 May 2017 18:00:53.4281 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: fcbc8bb1-061e-4b94-9f70-3ad917b0c8d3
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR08MB2679
Archived-At: 
Subject: Re: [lp-wan] Window mode as default fragmentation in SCHC + Minutes from Interim on 24/05
X-BeenThere: lp-wan@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Low-Power Wide Area Networking \(LP-WAN\), also known as LPWA or Low-Rate WAN \(LR-WAN\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 29 May 2017 18:01:00 -0000

Hi Alex,

I agree that the window mode provides enough support and flexibility for th=
e basic use cases. The more advanced fragmentation mechanisms to be defined=
 later on can be easily supported and communicated with Rule IDs, as you me=
ntion.

+1       for Window as default fragmentation mode.

Best,

Juan Carlos=20

> -----Original Message-----
> From: lp-wan [mailto:lp-wan-bounces@ietf.org] On Behalf Of Alexander Pelo=
v
> Sent: May 29, 2017 12:34 PM
> To: lp-wan 
> Subject: [lp-wan] Window mode as default fragmentation in SCHC + Minutes
> from Interim on 24/05
>=20
> Dear all,
>=20
> The minutes from the last interim meeting have been uploaded and can be
> found at the following address: https://www.ietf.org/proceedings/interim-
> 2017-lpwan-03/minutes/minutes-interim-2017-lpwan-03-201705241600-00
>=20
> One of the main topics that were discussed was the advancement of the
> fragmentation part of the IP/UDP SCHC document (
> https://tools.ietf.org/html/draft-ietf-lpwan-ipv6-static-context-hc-03 ).
>=20
> During the call we have reached a rough consensus that the Window mode
> covers all use-cases, is simple (from implementation and protocol point o=
f
> view), is well understood, and can be included as a default mode for
> fragmentation in the RFC.
>=20
> We have also indicated that there are other ways of doing the fragmentati=
on
> (most notably the Packet mode), but some corner cases still need to be co=
vered
> (e.g. bitmap sizes bigger than available payload limiting the MTU to less=
 than
> 1280), and some advanced ways of actually solving this (Bloom filters wer=
e
> mentioned I think). These are all interesting ideas and they merit a long=
er
> discussion to find the right balance. These are to be kept in a separate
> document, which can continue its life independently, and if the WG decide=
s can
> be included as a future WG item. If a future devices implement these othe=
r
> fragmentation mechanisms, they will be perfectly compatible with the defa=
ult
> Window mode (the Rule ID can indicate which fragmentation mode is used).
>=20
> We would like to confirm that you approve the Window mode as the default
> mode for fragmentation to be included in the SCHC IP/UDP document.
>=20
> Best,
> The chairs
>=20
> _______________________________________________
> lp-wan mailing list
> lp-wan@ietf.org
> https://www.ietf.org/mailman/listinfo/lp-wan


From nobody Mon May 29 14:36:42 2017
Return-Path: 
X-Original-To: lp-wan@ietfa.amsl.com
Delivered-To: lp-wan@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 130C012947D for ; Mon, 29 May 2017 14:36:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.22
X-Spam-Level: 
X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] 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 HfzYZwwN6i7d for ; Mon, 29 May 2017 14:36:38 -0700 (PDT)
Received: from dash.upc.es (dash.upc.es [147.83.2.50]) (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 B0D8112947C for ; Mon, 29 May 2017 14:36:37 -0700 (PDT)
Received: from entelserver.upc.edu (entelserver.upc.es [147.83.39.4]) by dash.upc.es (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id v4TLaWMd049058;  Mon, 29 May 2017 23:36:32 +0200
Received: from webmail.entel.upc.edu (webmail.entel.upc.edu [147.83.39.6]) by entelserver.upc.edu (Postfix) with ESMTP id 9217B1D53C1; Mon, 29 May 2017 23:36:31 +0200 (CEST)
Received: from 83.53.20.192 by webmail.entel.upc.edu with HTTP; Mon, 29 May 2017 23:36:14 +0200
Message-ID: <3c5e78783f5ab589b74f3a5556df434e.squirrel@webmail.entel.upc.edu>
In-Reply-To: 
References:  
Date: Mon, 29 May 2017 23:36:14 +0200
From: "Carles Gomez Montenegro" 
To: "Juan Carlos Zuniga" 
Cc: "Alexander Pelov" , "lp-wan" 
User-Agent: SquirrelMail/1.4.21-1.fc14
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
X-Virus-Scanned: clamav-milter 0.99.2 at dash
X-Virus-Status: Clean
X-Greylist: Delayed for 06:35:51 by milter-greylist-4.3.9 (dash.upc.es [147.83.2.50]); Mon, 29 May 2017 23:36:33 +0200 (CEST)
Archived-At: 
Subject: Re: [lp-wan] Window mode as default fragmentation in SCHC + Minutes from Interim on 24/05
X-BeenThere: lp-wan@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Low-Power Wide Area Networking \(LP-WAN\), also known as LPWA or Low-Rate WAN \(LR-WAN\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 29 May 2017 21:36:41 -0000

Hi,

I also agree.

After looking carefully at evaluation results [1], an overall conclusion
is that it is possible to configure the window size to have low ACK
overhead at a reasonably low cost in terms of fragmentation header size
(and number of fragments for a given IPv6 packet size).

Supporting more than one window size (e.g. advertised by means of a
corresponding Rule ID), when possible, is a further interesting feature
for performance improvement.

On the other hand, I think we need more time to better analyze the
different proposals for Packet mode, so working on it in a different
document will allow for a longer term effort.

Cheers,

Carles

[1] I will soon share some slides on this...






> Hi Alex,
>
> I agree that the window mode provides enough support and flexibility for
> the basic use cases. The more advanced fragmentation mechanisms to be
> defined later on can be easily supported and communicated with Rule IDs,
> as you mention.
>
> +1       for Window as default fragmentation mode.
>
> Best,
>
> Juan Carlos
>
>> -----Original Message-----
>> From: lp-wan [mailto:lp-wan-bounces@ietf.org] On Behalf Of Alexander
>> Pelov
>> Sent: May 29, 2017 12:34 PM
>> To: lp-wan 
>> Subject: [lp-wan] Window mode as default fragmentation in SCHC + Minutes
>> from Interim on 24/05
>>
>> Dear all,
>>
>> The minutes from the last interim meeting have been uploaded and can be
>> found at the following address:
>> https://www.ietf.org/proceedings/interim-
>> 2017-lpwan-03/minutes/minutes-interim-2017-lpwan-03-201705241600-00
>>
>> One of the main topics that were discussed was the advancement of the
>> fragmentation part of the IP/UDP SCHC document (
>> https://tools.ietf.org/html/draft-ietf-lpwan-ipv6-static-context-hc-03
>> ).
>>
>> During the call we have reached a rough consensus that the Window mode
>> covers all use-cases, is simple (from implementation and protocol point
>> of
>> view), is well understood, and can be included as a default mode for
>> fragmentation in the RFC.
>>
>> We have also indicated that there are other ways of doing the
>> fragmentation
>> (most notably the Packet mode), but some corner cases still need to be
>> covered
>> (e.g. bitmap sizes bigger than available payload limiting the MTU to
>> less than
>> 1280), and some advanced ways of actually solving this (Bloom filters
>> were
>> mentioned I think). These are all interesting ideas and they merit a
>> longer
>> discussion to find the right balance. These are to be kept in a separate
>> document, which can continue its life independently, and if the WG
>> decides can
>> be included as a future WG item. If a future devices implement these
>> other
>> fragmentation mechanisms, they will be perfectly compatible with the
>> default
>> Window mode (the Rule ID can indicate which fragmentation mode is used).
>>
>> We would like to confirm that you approve the Window mode as the default
>> mode for fragmentation to be included in the SCHC IP/UDP document.
>>
>> Best,
>> The chairs
>>
>> _______________________________________________
>> lp-wan mailing list
>> lp-wan@ietf.org
>> https://www.ietf.org/mailman/listinfo/lp-wan
>
> _______________________________________________
> lp-wan mailing list
> lp-wan@ietf.org
> https://www.ietf.org/mailman/listinfo/lp-wan
>



From nobody Tue May 30 00:51:18 2017
Return-Path: 
X-Original-To: lp-wan@ietfa.amsl.com
Delivered-To: lp-wan@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF36C129B7D for ; Tue, 30 May 2017 00:51:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.799
X-Spam-Level: 
X-Spam-Status: No, score=-3.799 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_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5, 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=imt-atlantique.fr
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 Rzl1RqoDVz0t for ; Tue, 30 May 2017 00:51:12 -0700 (PDT)
Received: from zproxy210.enst-bretagne.fr (zproxy210.enst-bretagne.fr [192.108.117.8]) by ietfa.amsl.com (Postfix) with ESMTP id 0B518129B79 for ; Tue, 30 May 2017 00:51:12 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by zproxy210.enst-bretagne.fr (Postfix) with ESMTP id 99300232080 for ; Tue, 30 May 2017 09:51:10 +0200 (CEST)
Received: from zproxy210.enst-bretagne.fr ([127.0.0.1]) by localhost (zproxy210.enst-bretagne.fr [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id 8X-mDt8eJH9n for ; Tue, 30 May 2017 09:51:09 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1]) by zproxy210.enst-bretagne.fr (Postfix) with ESMTP id 831FA232082 for ; Tue, 30 May 2017 09:51:09 +0200 (CEST)
DKIM-Filter: OpenDKIM Filter v2.9.2 zproxy210.enst-bretagne.fr 831FA232082
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=imt-atlantique.fr; s=50EA75E8-DE22-11E6-A6DE-0662BA474D24; t=1496130669; bh=DE9FWTrawxU3Z+SGreht8IcS1RKG1pLTCb5OmZn/280=; h=MIME-Version:From:Date:Message-ID:Subject:To:Content-Type; b=BX4p1drCqedDt+rqdW1EB8heCcMBkIzqPjSB8bBKcZU49BA3B1zPCZ55W00Ng4+Zy CvvFvLe0Y+G6HO1KgLpMass/Kd7FFYCkU6A/CJeYedSjTFPT+aHuDyB5rn45du44cd o0mGT3MRiquCRzFa9eRzbeUwqrnsYRMRpFvuN8Ys=
X-Virus-Scanned: amavisd-new at zproxy210.enst-bretagne.fr
Received: from zproxy210.enst-bretagne.fr ([127.0.0.1]) by localhost (zproxy210.enst-bretagne.fr [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 9Y4ZRqNh4rFc for ; Tue, 30 May 2017 09:51:09 +0200 (CEST)
Received: from mail-qk0-f173.google.com (mail-qk0-f173.google.com [209.85.220.173]) by zproxy210.enst-bretagne.fr (Postfix) with ESMTPSA id 22BE0232046 for ; Tue, 30 May 2017 09:51:09 +0200 (CEST)
Received: by mail-qk0-f173.google.com with SMTP id u75so62342697qka.3 for ; Tue, 30 May 2017 00:51:09 -0700 (PDT)
X-Gm-Message-State: AODbwcAXbLZK/Cr+ULzMejXcJVwmeqXjNLT+VDUA9J/wO7MSp89yA2so ncyH0XJ0MlcMqdjV7ZlXsnIA7K4zxQ==
X-Received: by 10.55.217.70 with SMTP id u67mr21006980qki.17.1496130667895; Tue, 30 May 2017 00:51:07 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.12.132.4 with HTTP; Tue, 30 May 2017 00:50:27 -0700 (PDT)
In-Reply-To: <3c5e78783f5ab589b74f3a5556df434e.squirrel@webmail.entel.upc.edu>
References:   <3c5e78783f5ab589b74f3a5556df434e.squirrel@webmail.entel.upc.edu>
From: Laurent Toutain 
Date: Tue, 30 May 2017 09:50:27 +0200
X-Gmail-Original-Message-ID: 
Message-ID: 
To: Carles Gomez Montenegro 
Cc: Juan Carlos Zuniga , lp-wan , Alexander Pelov 
Content-Type: multipart/alternative; boundary="001a1149a908ff61a80550b9102a"
Archived-At: 
Subject: Re: [lp-wan] Window mode as default fragmentation in SCHC + Minutes from Interim on 24/05
X-BeenThere: lp-wan@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Low-Power Wide Area Networking \(LP-WAN\), also known as LPWA or Low-Rate WAN \(LR-WAN\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 30 May 2017 07:51:16 -0000

--001a1149a908ff61a80550b9102a
Content-Type: text/plain; charset="UTF-8"

Hi,

+1,

I'm in favor of a universal solution in the main document. Optimizations
can occur after, but we need a better feed back from the field to see if
they are realistic. My only concern is the unidirectional mode where there
is not ACK, but a MIC at the end. It should remains since it is a expected
behavior, we have to derive it from window mode and we have also to define
a default MIC which detect efficiently fragment losses.

Laurent

On Mon, May 29, 2017 at 11:36 PM, Carles Gomez Montenegro <
carlesgo@entel.upc.edu> wrote:

> Hi,
>
> I also agree.
>
> After looking carefully at evaluation results [1], an overall conclusion
> is that it is possible to configure the window size to have low ACK
> overhead at a reasonably low cost in terms of fragmentation header size
> (and number of fragments for a given IPv6 packet size).
>
> Supporting more than one window size (e.g. advertised by means of a
> corresponding Rule ID), when possible, is a further interesting feature
> for performance improvement.
>
> On the other hand, I think we need more time to better analyze the
> different proposals for Packet mode, so working on it in a different
> document will allow for a longer term effort.
>
> Cheers,
>
> Carles
>
> [1] I will soon share some slides on this...
>
>
>
>
>
>
> > Hi Alex,
> >
> > I agree that the window mode provides enough support and flexibility for
> > the basic use cases. The more advanced fragmentation mechanisms to be
> > defined later on can be easily supported and communicated with Rule IDs,
> > as you mention.
> >
> > +1       for Window as default fragmentation mode.
> >
> > Best,
> >
> > Juan Carlos
> >
> >> -----Original Message-----
> >> From: lp-wan [mailto:lp-wan-bounces@ietf.org] On Behalf Of Alexander
> >> Pelov
> >> Sent: May 29, 2017 12:34 PM
> >> To: lp-wan 
> >> Subject: [lp-wan] Window mode as default fragmentation in SCHC + Minutes
> >> from Interim on 24/05
> >>
> >> Dear all,
> >>
> >> The minutes from the last interim meeting have been uploaded and can be
> >> found at the following address:
> >> https://www.ietf.org/proceedings/interim-
> >> 2017-lpwan-03/minutes/minutes-interim-2017-lpwan-03-201705241600-00
> >>
> >> One of the main topics that were discussed was the advancement of the
> >> fragmentation part of the IP/UDP SCHC document (
> >> https://tools.ietf.org/html/draft-ietf-lpwan-ipv6-static-context-hc-03
> >> ).
> >>
> >> During the call we have reached a rough consensus that the Window mode
> >> covers all use-cases, is simple (from implementation and protocol point
> >> of
> >> view), is well understood, and can be included as a default mode for
> >> fragmentation in the RFC.
> >>
> >> We have also indicated that there are other ways of doing the
> >> fragmentation
> >> (most notably the Packet mode), but some corner cases still need to be
> >> covered
> >> (e.g. bitmap sizes bigger than available payload limiting the MTU to
> >> less than
> >> 1280), and some advanced ways of actually solving this (Bloom filters
> >> were
> >> mentioned I think). These are all interesting ideas and they merit a
> >> longer
> >> discussion to find the right balance. These are to be kept in a separate
> >> document, which can continue its life independently, and if the WG
> >> decides can
> >> be included as a future WG item. If a future devices implement these
> >> other
> >> fragmentation mechanisms, they will be perfectly compatible with the
> >> default
> >> Window mode (the Rule ID can indicate which fragmentation mode is used).
> >>
> >> We would like to confirm that you approve the Window mode as the default
> >> mode for fragmentation to be included in the SCHC IP/UDP document.
> >>
> >> Best,
> >> The chairs
> >>
> >> _______________________________________________
> >> lp-wan mailing list
> >> lp-wan@ietf.org
> >> https://www.ietf.org/mailman/listinfo/lp-wan
> >
> > _______________________________________________
> > lp-wan mailing list
> > lp-wan@ietf.org
> > https://www.ietf.org/mailman/listinfo/lp-wan
> >
>
>
> _______________________________________________
> lp-wan mailing list
> lp-wan@ietf.org
> https://www.ietf.org/mailman/listinfo/lp-wan
>

--001a1149a908ff61a80550b9102a
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi,

+1, 

I'm in favor of a universa=
l solution in the main document. Optimizations can occur after, but we need=
 a better feed back from the field to see if they are realistic. My only co=
ncern is the unidirectional mode where there is not ACK, but a MIC at the e=
nd. It should remains since it is a expected behavior, we have to derive it=
 from window mode and we have also to define a default MIC which detect eff=
iciently fragment losses.=C2=A0 

Laurent
<=
div class=3D"gmail_extra">
On Mon, May 29, 20=
17 at 11:36 PM, Carles Gomez Montenegro <carlesgo@entel.upc.edu&g=
t; wrote:
Hi,



I also agree.



After looking carefully at evaluation results [1], an overall conclusion
is that it is possible to configure the window size to have low ACK

overhead at a reasonably low cost in terms of fragmentation header size

(and number of fragments for a given IPv6 packet size).



Supporting more than one window size (e.g. advertised by means of a

corresponding Rule ID), when possible, is a further interesting feature

for performance improvement.



On the other hand, I think we need more time to better analyze the

different proposals for Packet mode, so working on it in a different

document will allow for a longer term effort.



Cheers,



Carles



[1] I will soon share some slides on this...














> Hi Alex,

>

> I agree that the window mode provides enough support and flexibility f=
or

> the basic use cases. The more advanced fragmentation mechanisms to be<=
br>
> defined later on can be easily supported and communicated with Rule ID=
s,

> as you mention.

>

> +1=C2=A0 =C2=A0 =C2=A0 =C2=A0for Window as default fragmentation mode.=


>

> Best,

>

> Juan Carlos

>

>> -----Original Message-----

>> From: lp-wan [mailto:lp=
-wan-bounces@ietf.org] On Behalf Of Alexander

>> Pelov

>> Sent: May 29, 2017 12:34 PM

>> To: lp-wan <lp-wan@ietf.org<=
/a>>

>> Subject: [lp-wan] Window mode as default fragmentation in SCHC + M=
inutes

>> from Interim on 24/05

>>

>> Dear all,

>>

>> The minutes from the last interim meeting have been uploaded and c=
an be

>> found at the following address:

>> https://www.ietf.org/proceedings/interim-=


>> 2017-lpwan-03/minutes/minutes-interim-2017-lpwan-03-2017=
05241600-00

>>

>> One of the main topics that were discussed was the advancement of =
the

>> fragmentation part of the IP/UDP SCHC document (

>> https://tools.ietf.or=
g/html/draft-ietf-lpwan-ipv6-static-context-hc-03

>> ).

>>

>> During the call we have reached a rough consensus that the Window =
mode

>> covers all use-cases, is simple (from implementation and protocol =
point

>> of

>> view), is well understood, and can be included as a default mode f=
or

>> fragmentation in the RFC.

>>

>> We have also indicated that there are other ways of doing the

>> fragmentation

>> (most notably the Packet mode), but some corner cases still need t=
o be

>> covered

>> (e.g. bitmap sizes bigger than available payload limiting the MTU =
to

>> less than

>> 1280), and some advanced ways of actually solving this (Bloom filt=
ers

>> were

>> mentioned I think). These are all interesting ideas and they merit=
 a

>> longer

>> discussion to find the right balance. These are to be kept in a se=
parate

>> document, which can continue its life independently, and if the WG=


>> decides can

>> be included as a future WG item. If a future devices implement the=
se

>> other

>> fragmentation mechanisms, they will be perfectly compatible with t=
he

>> default

>> Window mode (the Rule ID can indicate which fragmentation mode is =
used).

>>

>> We would like to confirm that you approve the Window mode as the d=
efault

>> mode for fragmentation to be included in the SCHC IP/UDP document.=


>>

>> Best,

>> The chairs

>>

>> _______________________________________________

>> lp-wan mailing list

>> lp-wan@ietf.org

>> https://www.ietf.org/mailman/listinfo/lp-w=
an

>

> _______________________________________________

> lp-wan mailing list

> lp-wan@ietf.org

> https://www.ietf.org/mailman/listinfo/lp-wan

>





_______________________________________________

lp-wan mailing list

lp-wan@ietf.org

https://www.ietf.org/mailman/listinfo/lp-wan




--001a1149a908ff61a80550b9102a--


From nobody Tue May 30 13:25:29 2017
Return-Path: 
X-Original-To: lp-wan@ietfa.amsl.com
Delivered-To: lp-wan@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 547AC12943F for ; Tue, 30 May 2017 13:25:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.701
X-Spam-Level: 
X-Spam-Status: No, score=-4.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sigfoxgroup.onmicrosoft.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 sKlBEfKz3Zyz for ; Tue, 30 May 2017 13:25:22 -0700 (PDT)
Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0090.outbound.protection.outlook.com [104.47.1.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9541312943E for ; Tue, 30 May 2017 13:25:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sigfoxgroup.onmicrosoft.com; s=selector1-sigfox-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Jk8O+ZrHg2rrqVjI0jg9RbiDRVRJ6Tyed6wWX9i3+ZE=; b=L1af3XA0l4CHtwVrbKQMd9gnXc0hnRH1q1mcUjPkQRieQ/ww0TtqRV6OP647UoTroDN2kEnZ8LpCsjtnQeGvmsn9+iffx7pRmCqCX8tTACaMJnVWJ5vjVDy5cnBIT5sXr3yNs6llt0r9p6mjNrYmpKCLuZ8f1qDS7lrTuJ/now0=
Received: from DB6PR08MB2679.eurprd08.prod.outlook.com (10.175.235.12) by DB6PR08MB2678.eurprd08.prod.outlook.com (10.175.235.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1124.9; Tue, 30 May 2017 20:25:18 +0000
Received: from DB6PR08MB2679.eurprd08.prod.outlook.com ([fe80::3c08:54b8:1c7c:498a]) by DB6PR08MB2679.eurprd08.prod.outlook.com ([fe80::3c08:54b8:1c7c:498a%13]) with mapi id 15.01.1124.009; Tue, 30 May 2017 20:25:18 +0000
From: Juan Carlos Zuniga 
To: lp-wan 
Thread-Topic: Review of draft-ietf-lpwan-ipv6-static-context-hc-03
Thread-Index: AdLYtD5WSRWdUxCvTV+W5HdcWDFNlw==
Date: Tue, 30 May 2017 20:25:18 +0000
Message-ID: 
Accept-Language: en-CA, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=sigfox.com;
x-originating-ip: [104.163.152.104]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DB6PR08MB2678; 7:PPzT4Y1/eqs1OnUafZMTKDSDNhvbEMdYn7HCU4VAlMNwAOQ79dPvNZc67WqVkcfbtZOJ+enPUTEVO4IvTXj9+vLxo3UxDdqeO76Oq5DJIvs9UTFRjHTRmlpaMVuUBnWVEemZVFMV0BORJC46GZ0BpOTJMzfXy/8CmWLQltcA3zA0k+AwUKVxSuHHgn1PfsUq9E9WrHR+wR/jkyQq+gBur0jL672ZXRWvDCclnD4i+86YsHi0EaFzpT59lLfJw9B0/nsbcwo2mOqJZjI0hj+Qa/LzoLTPoI7a36pI3kkZDaHnSmwS3RqNohZTPXfOv5kjGzsYJyIZj/BW/8j/JmgDWQ==
x-ms-traffictypediagnostic: DB6PR08MB2678:
x-ms-office365-filtering-correlation-id: a87f02a8-06c6-4ff6-9d8e-08d4a799fd69
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081)(201702281549075); SRVR:DB6PR08MB2678; 
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(21748063052155);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(93006095)(93001095)(6041248)(20161123558100)(20161123555025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123560025)(6072148); SRVR:DB6PR08MB2678; BCL:0; PCL:0; RULEID:; SRVR:DB6PR08MB2678; 
x-forefront-prvs: 032334F434
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39410400002)(39450400003)(39830400002)(39400400002)(9326002)(8936002)(8676002)(86362001)(81166006)(6436002)(230783001)(99286003)(53946003)(110136004)(189998001)(6306002)(7736002)(5250100002)(14454004)(3846002)(55016002)(66066001)(6116002)(790700001)(74316002)(6506006)(53936002)(54896002)(9686003)(5660300001)(102836003)(50986999)(2906002)(478600001)(25786009)(33656002)(2900100001)(6916009)(3660700001)(7696004)(3280700002)(54356999)(38730400002)(557034004); DIR:OUT; SFP:1102; SCL:1; SRVR:DB6PR08MB2678; H:DB6PR08MB2679.eurprd08.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_DB6PR08MB2679AF369D523A04B708E65C89F00DB6PR08MB2679eurp_"
MIME-Version: 1.0
X-OriginatorOrg: sigfox.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 30 May 2017 20:25:18.8693 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: fcbc8bb1-061e-4b94-9f70-3ad917b0c8d3
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR08MB2678
Archived-At: 
Subject: [lp-wan] Review of draft-ietf-lpwan-ipv6-static-context-hc-03
X-BeenThere: lp-wan@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Low-Power Wide Area Networking \(LP-WAN\), also known as LPWA or Low-Rate WAN \(LR-WAN\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 30 May 2017 20:25:27 -0000

--_000_DB6PR08MB2679AF369D523A04B708E65C89F00DB6PR08MB2679eurp_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hello,

Below are my comments on draft-ietf-lpwan-ipv6-static-context-hc-03:

General:


-          Throughout the document it is mentioned that this is a "header" =
compression mechanism. However, in some cases the baseline principles can a=
lso be applied to packet payloads. For that reason, I suggest removing "hea=
der" from all instances in sentences that are not specific to the header it=
self, like the abstract and the introduction, e.g. "This document describes=
 a header compression scheme and fragmentation functionality for IPv6/UDP p=
rotocols."

Editorial/Technical:


-          Section 2:

o   Rule ID: An identifier for a rule, SCHC C/D and DEV share the same rule=
 ID for a specific flow.

?  Remove: Rule ID is sent on the LPWAN.

o   Add Field Identifier (FID) definition

o   Add IID, DEV ID, and APP ID definitions (for these two latter, please s=
ee comments on sections 6 and 7 below)

-          Section 3:

o   ROHC: Add reference to RFC 5795

o   "The context must be stored in both ends. It can also be learned by usi=
ng a provisionning protocol that is out of the scope of this draft."

?  Change to >> The context must be stored in both ends, and it can either =
be leaned by a provisioning protocol, by out of band means, it can be pre-p=
rovisioned, etc. The way the context is learned on both sides is out of sco=
pe of this document.

o   The principle is the same in the other direction.

?  Change to >> The SCHC process is bidirectional, so the same principles c=
an be applied in the other direction

o   Add a new subsection header (e.g. 3.1) called "SCHC Rules" before the f=
ollowing paragraph:

?  "The context contains a list of rules..."

o   Move the following paragraph to the beginning of the proposed new subse=
ction 3.1:

?  "The main idea of the compression scheme..."

-          Current section 3.2 Packet processing:

o   "compression rule selection: the goal is to identify which rule(s)will =
be used to compress the headers. Each field is associated to a matching ope=
rator for compression. Each header field's value is compared to the corresp=
onding target value stored in the rule for that field using the matching op=
erator. If all the fields in the packet's header satisfied all the matching=
 operators of a rule, the packet is processed using Compression Decompressi=
on Function associated with the fields. Otherwise the next rule is tested. =
If no eligible rule is found, then the packet is sent without compression, =
which may require using the fragmentation procedure."

?  Change to >> "compression rule selection: the goal is to identify which =
rule(s) will be used to compress the packet. Fields are first identified ac=
cording to their field identifier (FID), field position (FP) and direction =
indicator (DI). Each field's value is then compared to the corresponding ta=
rget value (TV) stored in the rule for that specific field using the matchi=
ng operator (MO). If all the fields in the packet satisfy all the matching =
operators (MOs) of a rule (i.e. all results are True), the fields of the pa=
cket are then processed according to the Compression Decompression Actions =
(CDAs) and a compressed packet is obtained. Otherwise the next rule is test=
ed. If no eligible rule is found, then the packet must be sent without comp=
ression, in which case the fragmentation process may be required."

o   Not sure why the following sentence was added from rev 02 to rev 03: "I=
n the downstrean direction, the rule is also used to find the device ID. "

?  Should probably remove the sentence, as it looks out of place.

?  Also, isn't it that in DL first the DEV ID is used to know the rule, as =
the same rule ID can be used to identify different rules for different devi=
ces?

o   "sending: The rule ID is sent to the other end followed by information =
resulting from the compression of header fields.  This information is sent =
in the order expressed in the rule for the matching fields.  The way the ru=
le ID is sent depends on the layer two technology and will be specified in =
a specific document.  For example, it can either be included in a Layer 2 h=
eader or sent in the first byte of the L2 payload. (cf.  Figure 3)

?  Change to >> "sending: The rule ID is sent to the other end followed by =
information resulting from the compression of the packet's fields.  This in=
formation is sent in the order expressed in the rule for the matching field=
s.  The way the rule ID is sent depends on the specific LPWAN technology an=
d will be specified in a specific document.  For example, it can either be =
included in a Layer 2 header or sent in the first byte of the L2 payload. (=
cf.  Figure 3)

o   "decompression: The receiver identifies the sender through its device-i=
d (e.g.  MAC address) and selects the appropriate rule through the rule ID.=
 This rule gives the compressed header format and associates these values t=
o header fields.  It applies the CDA action to reconstruct the original hea=
der fields.  The CDA order can be different of the order given by the rule.=
  For instance Compute-* may be applied after the other CDAs.

?  Change to >> "decompression: In the upstream direction, the receiver fir=
st identifies the sender through its device identifier (DID) and selects th=
e appropriate rule through the rule ID. This rule gives the compressed head=
er format and associates these values to header fields.  It applies the CDA=
 action to reconstruct the original header fields.  The CDA order can be di=
fferent of the order given by the rule.  For instance Compute-* may be appl=
ied after the other CDAs."

-          Section 4

o   "This document describes basic matching operators (MO)s which must be k=
nown by both SCHC C/D, endpoints involved in the header compression/decompr=
ession.  They are not typed and can be applied indifferently to integer, st=
ring or any other type.  The MOs and their definitions are provided next:"

?  Change to >> "Matching operators (MOs) are functions used by both SCHC C=
/D endpoints involved in the header compression/decompression.  They are no=
t typed and can be applied indifferently to integer, string or any other da=
ta type.  The result of the operation can either be True or False. MOs are =
defined as follows:"

o   "equal: a field value in a packet matches with a field value in a rule =
if they are equal."

?  Change to>> "equal: a field value in a packet matches with a TV in a rul=
e if they are equal."

o   "MSB(length): a field value of a size equal to "length" bits in a packe=
t matches with a field value in a rule if the most significant "length" bit=
s are equal."

?  Change to>> "MSB (length): a matching is obtained if the most significan=
t bits of the length field value of the packet are equal to the TV in the r=
ule."

-          Section 5

o   In figure 4 (should probably be called table instead of figure), change=
 the following Action:

?  LSB(length)|send LSB|ctxt value OR rcvd value  >>  LSB(length)|send LSB|=
TV (OR) received value

o   In 5.4: "LSB action is used to send a fixed part of the packet field he=
ader to the other end."

?  Change to>> "LSB action is used to avoid sending the fixed part of the p=
acket field to the other end."

o   5.5.  DEViid-DID, APPiid-DID CDA:

?  "These functions are used to process respectively the Device and the App=
lication Device Identifier (DID).  APPiid-DID CDA is less common, since cur=
rent LPWAN technologies frames contain a single address.

?  The IID value is computed from the Device ID present in the Layer 2 head=
er.  The computation depends on the technology and the Device ID size.

?  In the downstream direction, these CDA are used to determine the L2 addr=
esses used by the LPWAN."

?  Change to>> DEV ID, APP ID CDAs:

?  "These functions are used to process the DEV and the APP Identifiers.  T=
he value can be computed from the Device ID present in the Layer 2 header. =
 The computation is specific for each LPWAN technology and depends on the D=
evice ID size.

o   In 5.6 - Add new subsections (5.6.1 and 5.6.2) to the compute-length an=
d compute-checksum function paragraph descriptions, respectively

-          Section 6

o   6.2: wellknown >> well-known

o   6.3: dpending >> depending

o   6.7.2 IPv6 source and destination IID: "If the DEV or APP IID are based=
 on an LPWAN address, then the IID can be reconstructed with information co=
ming from the LPWAN header.  In that case, the TV is not set, the MO is set=
 to "ignore" and the CDA is set to "DEViid-DID" or "APPiid-DID".  Note that=
 the LPWAN technology is generally carrying a single device identifier corr=
esponding to the DEV."

o   Change to>> "If the DEV or APP IID are based on an LPWAN address, then =
the IID can be reconstructed with information coming from the LPWAN header.=
  In that case, the TV is not set, the MO is set to "ignore" and the CDA is=
 set to "DEV IID" or "APP IID".  Note that the LPWAN technology is generall=
y carrying a single device identifier corresponding to the DEV."

o   The following paragraph is contradictory:

?  For privacy reasons or if the DEV address is changing over time, it mayb=
e better to use a static value.  In that case, the TV contains the value, t=
he MO operator is set to "equal" and the CDA is set to "not-sent".

?  If we are adding privacy features, the use of long-lasting identifiers s=
hould be avoided. It is not clear if in this case it is the source or the d=
estination (compressor or decompressor) that is in charge of changing the i=
dentity, and what effect does this have on the CDA.

-          Section 7

o   Figure 6: Context rules (and rest of section 7)

?  Change all instances of "DEViid-DID" >> "DEV IID"

o   Remove the following sentence: "The DEViid-DID value is found in the L2=
 header."





For comments on Section 8 onwards, I will wait for a new revision of the dr=
aft incorporating the potential changes to come after the latest discussion=
s about the fragmentation modes.



Best,



Juan Carlos




--_000_DB6PR08MB2679AF369D523A04B708E65C89F00DB6PR08MB2679eurp_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Hello,


 


Below are my comments on draft-ietf-lpwan-ipv6-stati=
c-context-hc-03:


 


General:


 



-       =
;  
Throughout the document it is mentioned that this i=
s a “header” compression mechanism. However, in some cases the =
baseline principles can also be applied to packet payloads. For that reason=
, I suggest removing “header” from all instances
 in sentences that are not specific to the header itself, like the abstract=
 and the introduction, e.g. “This document describes a
header compression scheme and fragmentation functionality for IPv6/U=
DP protocols.”


 


Editorial/Technical:


 



-       =
;  
Section 2:  



o  
Rule ID: An identifier for a rule, SCHC C/D and DEV share the same=
 rule ID for a specific flow.



§Remove:
Rule ID is sent on the LPWAN.



o  
Add Field Identifier (FID) definition



o  
Add IID, DEV ID, and APP ID definitions (for=
 these two latter, please see comments on sections 6 and 7 below)


-     &=
nbsp;   
Section 3: 



o  
ROHC: Add reference to RFC 5795


o &n=
bsp;
“The =
context must be stored in both ends. It can also be learned by using a prov=
isionning protocol that is out of the scope of this
 draft.”



§ 
Change to=

>> The context must be store=
d in both ends,
 and it can either be leaned by a provisioning protocol, by out of band mea=
ns, it can be pre-provisioned, etc. The way the context is learned on both =
sides is out of scope of this document.



o  
The principle is the same in the other direction.<=
o:p>



§ 
Change to=

>> 
The SCHC process is bidirectional, so the same principles can be applied in=
 the other direction



o  
Add a new subsec=
tion header (e.g. 3.1) called “SCHC Rules” before the following=
 paragraph:


=
§  “The context contains a list of rules...”



o  
Move the following paragraph to the beginnin=
g of the proposed new subsection 3.1:


=
§  “The main idea of the compression scheme...”


-    &=
nbsp;     C=
urrent section 3.2 Packet processing:



o  
“compression rule selection: the goal is to identify which r=
ule(s)will be used to compress the headers. Each field is associated to a m=
atching operator for compression. Each header
 field’s value is compared to the corresponding target value stored i=
n the rule for that field using the matching operator. If all the fields in=
 the packet’s header satisfied all the matching operators of a rule, =
the packet is processed using Compression Decompression
 Function associated with the fields. Otherwise the next rule is tested. If=
 no eligible rule is found, then the packet is sent without compression, wh=
ich may require using the fragmentation procedure.”



§ 
Change to=

>> “=
;compression rule selection: the goal is to identify which rule(s) will be =
used to compress the packet. Fields are first identified according to their=
 field identifier (FID), field position (FP) and
 direction indicator (DI). Each field’s value is then compared to the=
 corresponding target value (TV) stored in the rule for that specific field=
 using the matching operator (MO). If all the fields in the packet satisfy =
all the matching operators (MOs) of a
 rule (i.e. all results are True), the fields of the packet are then proces=
sed according to the Compression Decompression Actions (CDAs) and a compres=
sed packet is obtained. Otherwise the next rule is tested. If no eligible r=
ule is found, then the packet must
 be sent without compression, in which case the fragmentation process may b=
e required.”


o &nbs=
p; Not sure why the following s=
entence was added from rev 02 to rev 03:=
 “In the downstrean direction, the rule is also used to find the devi=
ce ID. ”


=
§  Should probably remove the sentence, as it looks out of place. 


=
§  Also, isn’t it that in DL first the DEV ID is used to know t=
he rule, as the same rule ID can be used to identify different rules for di=
fferent devices?


o &nbs=
p; “sendin=
g: The rule ID is sent to the other end followed by information resulting f=
rom the compression of header fields.  This information is sent in the=
 order expressed in the rule for the matching fields.  The way the rul=
e ID is sent depends on the layer two technology and will be specified in a=
 specific document.  For example, it can either be included in a Layer=
 2 header or sent in the first byte of the L2 payload. (cf.  Figure 3)=



=
§  Change=
 to >> “sending: The rule ID=
 is sent to the other end followed by information resulting from the compre=
ssion of the packet’s fields.  This information is sent in the o=
rder expressed in the rule for the matching fields.  The way the rule =
ID is sent depends on the specific LPWAN technology and will be specified i=
n a specific document.  For example, it can either be included in a La=
yer 2 header or sent in the first byte of the L2 payload. (cf.  Figure=
 3)


o &nbs=
p; “decomp=
ression: The receiver identifies the sender through its device-id (e.g.&nbs=
p; MAC address) and selects the appropriate rule through the rule ID. This =
rule gives the compressed header format and associates these values to head=
er fields.  It applies the CDA action to reconstruct the original head=
er fields.  The CDA order can be different of the order given by the r=
ule.  For instance Compute-* may be applied after the other CDAs.=



=
§  Change=
 to >> “decompression: In th=
e upstream direction, the receiver first identifies the sender through its =
device identifier (DID) and selects the appropriate rule through the rule I=
D. This rule gives the compressed header format and associates these values=
 to header fields.  It applies the CDA action to reconstruct the origi=
nal header fields.  The CDA order can be different of the order given =
by the rule.  For instance Compute-* may be applied after the other CD=
As.”


-    &=
nbsp;     S=
ection 4


o &nbs=
p; “This d=
ocument describes basic matching operators (MO)s which must be known by bot=
h SCHC C/D, endpoints involved in the header compression/decompression.&nbs=
p; They are not typed and can be applied indifferently to integer, string o=
r any other type.  The MOs and their definitions are provided next:=
221;


=
§  Change=
 to >> “Matching operators (=
MOs) are functions used by both SCHC C/D endpoints involved in the header c=
ompression/decompression.  They are not typed and can be applied indif=
ferently to integer, string or any other data type.  The result of the=
 operation can either be True or False. MOs are defined as follows:”<=
o:p>


o &nbs=
p; “equal:=
 a field value in a packet matches with a field value in a rule if they are=
 equal.”


=
§  Change=
 to>> “equal: a field value =
in a packet matches with a TV in a rule if they are equal.”


o &nbs=
p; “MSB(le=
ngth): a field value of a size equal to "length" bits in a packet=
 matches with a field value in a rule if the most significant "length&=
quot; bits are equal.”


=
§  Change=
 to>> “MSB (length): a match=
ing is obtained if the most significant bits of the length field value of t=
he packet are equal to the TV in the rule.”


-    &=
nbsp;     S=
ection 5


o &nbs=
p; In figure 4 (=
should probably be called table instead of figure), change the following Ac=
tion:


=
§  LSB(length)|send LSB|ctxt value OR rcvd value  >> =
 LSB(length)|send LSB|TV (OR) received value


o &nbs=
p; In 5.4: ̶=
0;LSB action is used to send a fixed part of the packet field header to the=
 other end.”


=
§  Change=
 to>> “LSB action is used to=
 avoid sending the fixed part of the packet field to the other end.”<=
o:p>


o &nbs=
p; 5.5.  DE=
Viid-DID, APPiid-DID CDA: 


=
§  “These functions are used to process respectively the Device=
 and the Application Device Identifier (DID).  APPiid-DID CDA is less =
common, since current LPWAN technologies frames contain a single address.


=
§  The IID value is computed from the Device ID present in the Layer =
2 header.  The computation depends on the technology and the Device ID=
 size.


=
§  In the downstream direction, these CDA are used to determine the L=
2 addresses used by the LPWAN.”


=
§  Change=
 to>> DEV ID, APP ID CDAs:


=
§  “These functions are used to process the DEV and the APP Ide=
ntifiers.  The value can be computed from the Device ID present in the=
 Layer 2 header.  The computation is specific for each LPWAN technolog=
y and depends on the Device ID size.


o &nbs=
p; In 5.6 –=
; Add new subsections (5.6.1 and 5.6.2) to the compute-length and compute-c=
hecksum function paragraph descriptions, respectively

-    &=
nbsp;     S=
ection 6


o &nbs=
p; 6.2: wellknow=
n >> well-known


o &nbs=
p; 6.3: dpending=
 >> depending


o &nbs=
p; 6.7.2 IPv6 so=
urce and destination IID: “If the DEV or APP IID are based on an LPWA=
N address, then the IID can be reconstructed with information coming from t=
he LPWAN header.  In that case, the TV is not set, the MO is set to &q=
uot;ignore" and the CDA is set to "DEViid-DID" or "APPi=
id-DID".  Note that the LPWAN technology is generally carrying a =
single device identifier corresponding to the DEV.”=



o &nbs=
p; Change to>> “If the DEV or APP IID are based on an LPWA=
N address, then the IID can be reconstructed with information coming from t=
he LPWAN header.  In that case, the TV is not set, the MO is set to &q=
uot;ignore" and the CDA is set to "DEV IID" or "APP IID=
".  Note that the LPWAN technology is generally carrying a single=
 device identifier corresponding to the DEV.”


o &nbs=
p; The following paragraph is c=
ontradictory: 


=
§  For privacy reasons or if the DEV address is changing over time, i=
t maybe better to use a static value.  In that case, the TV contains t=
he value, the MO operator is set to "equal" and the CDA is set to=
 "not-sent".


§  If we are adding privacy features, the use of long-lasting ident=
ifiers should be avoided. It is not clear if in this case it is the source =
or the destination (compressor or decompressor) that is in charge of changi=
ng the identity, and what effect does this have on the CDA.


-    &=
nbsp;     S=
ection 7


o &nbs=
p; Figure 6: Con=
text rules (and rest of section 7)


=
§  Change all instances of “DEViid-DID” >> “D=
EV IID”


o &nbs=
p; Remove the fo=
llowing sentence: “The DEViid-DID value is found in the L2 header.=
221;


 


 


For comments on Section 8 onwards, I will wait for a new =
revision of the draft incorporating the potential changes to come after the=
 latest discussions about the fragmentation modes.


 


Best,


 


Juan Carlos 


 


 






--_000_DB6PR08MB2679AF369D523A04B708E65C89F00DB6PR08MB2679eurp_--


From nobody Wed May 31 00:39:58 2017
Return-Path: 
X-Original-To: lp-wan@ietfa.amsl.com
Delivered-To: lp-wan@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4278129501 for ; Wed, 31 May 2017 00:39:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.8
X-Spam-Level: 
X-Spam-Status: No, score=-3.8 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_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=imt-atlantique.fr
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 2CC4CfU3td7Q for ; Wed, 31 May 2017 00:39:53 -0700 (PDT)
Received: from zproxy210.enst-bretagne.fr (zproxy210.enst-bretagne.fr [192.108.117.8]) by ietfa.amsl.com (Postfix) with ESMTP id F02A0129508 for ; Wed, 31 May 2017 00:39:52 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by zproxy210.enst-bretagne.fr (Postfix) with ESMTP id D6DBD232058 for ; Wed, 31 May 2017 09:39:51 +0200 (CEST)
Received: from zproxy210.enst-bretagne.fr ([127.0.0.1]) by localhost (zproxy210.enst-bretagne.fr [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id Luh68vr2VPfL for ; Wed, 31 May 2017 09:39:50 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1]) by zproxy210.enst-bretagne.fr (Postfix) with ESMTP id 5C816232075 for ; Wed, 31 May 2017 09:39:50 +0200 (CEST)
DKIM-Filter: OpenDKIM Filter v2.9.2 zproxy210.enst-bretagne.fr 5C816232075
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=imt-atlantique.fr; s=50EA75E8-DE22-11E6-A6DE-0662BA474D24; t=1496216390; bh=hg44FcWfKw3BPde/B43jSH1l+jzpSVmyvTUU/1xM+U4=; h=MIME-Version:From:Date:Message-ID:Subject:To:Content-Type; b=QTs9YHgq3385J/lbRVdDbxwMvj0vWvbYWzONtSMItK7aTmGxNtVX7aJz8kbFLs/qr nc+hWOeJg5c3rD50/h/j5WDZgWCBl6BEY3asCmX1ZNkkhHbI47fIsEHC+MrfKqjxid ASkW+U7fpDMiNinHiY/SR/7zS62Gy8UqUH+w2jpk=
X-Virus-Scanned: amavisd-new at zproxy210.enst-bretagne.fr
Received: from zproxy210.enst-bretagne.fr ([127.0.0.1]) by localhost (zproxy210.enst-bretagne.fr [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id qZvp4daHGpX8 for ; Wed, 31 May 2017 09:39:50 +0200 (CEST)
Received: from mail-qt0-f172.google.com (mail-qt0-f172.google.com [209.85.216.172]) by zproxy210.enst-bretagne.fr (Postfix) with ESMTPSA id D38B023206B for ; Wed, 31 May 2017 09:39:49 +0200 (CEST)
Received: by mail-qt0-f172.google.com with SMTP id c13so5904431qtc.1 for ; Wed, 31 May 2017 00:39:49 -0700 (PDT)
X-Gm-Message-State: AODbwcAGnFi2UQ289Q/plRaqye9SEfpd8niRaQ9gmW2ifaH80kkJSvLG 5mXOj6M6aafZVgrWhmnYrl4209a6Jw==
X-Received: by 10.200.37.165 with SMTP id e34mr30148464qte.112.1496216388619;  Wed, 31 May 2017 00:39:48 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.12.132.4 with HTTP; Wed, 31 May 2017 00:39:08 -0700 (PDT)
In-Reply-To: 
References: <21798_1494839597_5919712D_21798_82_1_BC397CDFFDB82545B5E3571A77AB72043CC24ED4@OPEXCLILM21.corporate.adroot.infra.ftgroup>  
From: Laurent Toutain 
Date: Wed, 31 May 2017 09:39:08 +0200
X-Gmail-Original-Message-ID: 
Message-ID: 
To: weigengyu 
Cc: philippe.christin@orange.com, lp-wan 
Content-Type: multipart/alternative; boundary="001a113a862e5aec1c0550cd06a6"
Archived-At: 
Subject: Re: [lp-wan] Question on LoRaWAN and SCHC decompression architecture (Figure 1)
X-BeenThere: lp-wan@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Low-Power Wide Area Networking \(LP-WAN\), also known as LPWA or Low-Rate WAN \(LR-WAN\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 31 May 2017 07:39:57 -0000

--001a113a862e5aec1c0550cd06a6
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Gengyu,

Compression is an equivalence between 2 formats, one standard and generic
and another one adapted to a specific environment. It is not a protocol. If
you receive something encrypted and you don't know how to decipher it then
you cannot uncompress the header.

The  draft gives the architecture of the compression service.

        DEVICE                                            Appl Servers
   +---------------+                                  +---------------+
   | APP1 APP2 APP3|                                  |APP1  APP2 APP3|
   |               |                                  |               |
   |       UDP     |                                  |      UDP      |
   |      IPv6     |                                  |     IPv6      |
   |               |                                  |               |
   |    SCHC C/D   |                                  |               |
   |    (context)  |                                  |               |
   +--------+------+                                  +-------+-------+
            |   +--+     +----+     +---------+               .
            +~~ |RG| =3D=3D=3D |NGW | =3D=3D=3D |SCHC C/D |... Internet ...
                +--+     +----+     |(context)|
                                    +---------+

                          Figure 1: Architecture



SCHC C/D is between the  NGW and the Application. If encryption goes up to
the application then the SCHC C/C must be installed here.

Laurent

On Wed, May 31, 2017 at 4:57 AM, weigengyu  wrote:

> Hi,
>
> There is not any security considerations in IPv6/UDP/CoAP.
> If as Philippe mentioned =E2=80=9CThe LoRaWAN protocol is designed to enc=
rypt
> LoRaWAN MAC payload between the Device and the Application Server (End to
> End confidentiality)=E2=80=9D
> the SCHC Compressor/Decompressor relys on the MAC layer security, or not?
>
> Regards,
>
> Gengyu WEI
> Network Technology Center
> School of Computer
> Beijing University of Posts and Telecommunications
>
> *From:* Laurent Toutain 
> *Sent:* Monday, May 15, 2017 8:58 PM
> *To:* philippe.christin@orange.com
> *Cc:* lp-wan@ietf.org
> *Subject:* Re: [lp-wan] Question on LoRaWAN and SCHC decompression
> architecture (Figure 1)
>
> Hi Philippe,
>
> The location of the SCHC Compressor/Decompressor is not imposed by the
> draft, it can be either in a Network Gateway (if the key is known) or in
> the Application Server. IPv6/UDP/CoAP can be compressed within a single
> rule or a rule for IPv6/UDP can be set and another one for CoAP. In that
> case, IPv6/UDP headers can be compressed between the Device and the Netwo=
rk
> Gateway and the CoAP between the Device and the Application.
>
> Laurent
>
>
>
>
> On Mon, May 15, 2017 at 11:13 AM,  wrote:
>
>> Hi,
>>
>>
>>
>> The LoRaWAN protocol is designed to encrypt LoRaWAN MAC payload between
>> the Device and the Application Server (End to End confidentiality).
>>
>> And the NGW and the Application Server are connected through HTTPS link =
.
>>
>>
>>
>> How do you see for LoRaWAN a SCHC Decompression function running in
>> between of NGW and Application Server ?
>>
>> It should not be possible, except to host this function in the
>> Application Server.
>>
>>
>>
>> Thanks
>>
>>
>>
>> Philippe
>>
>>
>>
>> ________________________________________________________________________=
_________________________________________________
>>
>> Ce message et ses pieces jointes peuvent contenir des informations confi=
dentielles ou privilegiees et ne doivent donc
>> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez r=
ecu ce message par erreur, veuillez le signaler
>> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages=
 electroniques etant susceptibles d'alteration,
>> Orange decline toute responsabilite si ce message a ete altere, deforme =
ou falsifie. Merci.
>>
>> This message and its attachments may contain confidential or privileged =
information that may be protected by law;
>> they should not be distributed, used or copied without authorisation.
>> If you have received this email in error, please notify the sender and d=
elete this message and its attachments.
>> As emails may be altered, Orange is not liable for messages that have be=
en modified, changed or falsified.
>> Thank you.
>>
>>
>> _______________________________________________
>> lp-wan mailing list
>> lp-wan@ietf.org
>> https://www.ietf.org/mailman/listinfo/lp-wan
>>
>>
>
> ------------------------------
> _______________________________________________
> lp-wan mailing list
> lp-wan@ietf.org
> https://www.ietf.org/mailman/listinfo/lp-wan
>
>

--001a113a862e5aec1c0550cd06a6
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi Gengyu,

Compression is an e=
quivalence between 2 formats, one standard and generic and another one adap=
ted to a specific environment. It is not a protocol. If you receive somethi=
ng encrypted and you don't know how to decipher it then you cannot unco=
mpress the header. 

The=C2=A0 draft gives the architecture of =
the compression service. 

        DEVICE                       =
                     Appl Servers
   +---------------+                                  +---------------+
   | APP1 APP2 APP3|                                  |APP1  APP2 APP3|
   |               |                                  |               |
   |       UDP     |                                  |      UDP      |
   |      IPv6     |                                  |     IPv6      |
   |               |                                  |               |
   |    SCHC C/D   |                                  |               |
   |    (context)  |                                  |               |
   +--------+------+                                  +-------+-------+
            |   +--+     +----+     +---------+               .
            +~~ |RG| =3D=3D=3D |NGW | =3D=3D=3D |SCHC C/D |... Internet ...
                +--+     +----+     |(context)|
                                    +---------+

                          Figure 1: Architecture



SCHC C/D is between the=C2=A0 NGW and the Application. If enc=
ryption goes up to the application then the SCHC C/C must be installed here=
.

Laurent

On Wed, May 31, 2017 at 4:57 AM, weigengyu <weigengyu=
@bupt.edu.cn> wrote:








Hi, 


=C2=A0


There is not any security considerations in IPv6/UDP/CoAP. 


If as Philippe mentioned =E2=80=
=9CThe LoRaWAN=20
protocol is designed to encrypt LoRaWAN MAC payload between the Device and =
the=20
Application Server (End to End=20
confidentiality)=E2=80=9D


the SCHC Compressor/Decompressor relys on the MAC layer security, or=
=20
not?


=C2=A0


Regards,


=C2=A0


G=
engyu=20
WEI
Network Technology Center
School of Computer 
Beijing Universi=
ty of=20
Posts and Telecommunications






=C2=A0





Sent: Monday, May 15, 2017 8:58 PM




Subject: Re: [lp-wan] Question on LoRaWAN and SCHC decompressio=
n=20
architecture (Figure 1)


=C2=A0


=







Hi Philippe,

The location of the SCHC Compressor/Decompre=
ssor=20
is not imposed by the draft, it can be either in a Network Gateway (if the =
key=20
is known) or in the Application Server. IPv6/UDP/CoAP can be compressed wit=
hin a=20
single rule or a rule for IPv6/UDP can be set and another one for CoAP. In =
that=20
case, IPv6/UDP headers can be compressed between the Device and the Network=
=20
Gateway and the CoAP between the Device and the Application.=20


Laurent









=C2=A0


On Mon, May 15, 2017 at 11:13 AM, <p=
hilippe.christin@orange.com> wrote:



  

  

  
Hi,<=
/u>

  
=
=C2=A0

  
The=20
  LoRaWAN protocol is designed to encrypt LoRaWAN MAC payload between the D=
evice=20
  and the Application Server (End to End=20
  confidentiality).

  
And=20
  the NGW and the Application Server are connected through HTTPS link=20
  .

  
=
=C2=A0

  
How=20
  do you see for LoRaWAN a SCHC Decompression function running in between o=
f NGW=20
  and Application Server ?

  
It=20
  should not be possible, except to host this function in the Application=
=20
  Server. 

  
=
=C2=A0

  
Thanks<=
u>

  
=
=C2=A0

  
Philippe

  
=
=C2=A0
__________________________________________=
_________________________________________________________________=
______________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les message=
s electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.


_______________________________________________
lp-=
wan=20
  mailing list
lp-w=
an@ietf.org
https://www.ietf.org/mailman/lis=
tinfo/lp-wan



=C2=A0





_______________________________________________
lp-wan mailing=20
list
lp-wan@ietf.or=
g
https://www.ietf.org/mailman/listinfo/lp-wan





--001a113a862e5aec1c0550cd06a6--


From nobody Wed May 31 06:05:15 2017
Return-Path: 
X-Original-To: lp-wan@ietfa.amsl.com
Delivered-To: lp-wan@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2808D129463 for ; Wed, 31 May 2017 06:05:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.702
X-Spam-Level: 
X-Spam-Status: No, score=-4.702 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=-2.8, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sigfoxgroup.onmicrosoft.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 3e2zy2khiGyw for ; Wed, 31 May 2017 06:05:09 -0700 (PDT)
Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0124.outbound.protection.outlook.com [104.47.2.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E016127275 for ; Wed, 31 May 2017 06:05:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sigfoxgroup.onmicrosoft.com; s=selector1-sigfox-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=gN6DIVatGMLVQ4+DhUvB+iiysgMjr5iWdv5hcHYWvNc=; b=DA8CC3dAps856h+UVC/iLm+NG3OeFdzBM3nVT/PNpXH22D5YyxK13SRxQnaTSigf+i1mt1EKesP48oniXHN+UELC6c0vm3dTE76aqvDcBk/9ftty4bylZPmKjyyn/xuQiAY/AIbJjWK8IdJ/Tq+znr+Gh8u8s0kb1RJUew4bqdk=
Received: from DB6PR08MB2679.eurprd08.prod.outlook.com (10.175.235.12) by DB6PR08MB2677.eurprd08.prod.outlook.com (10.175.235.10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1124.9; Wed, 31 May 2017 13:05:07 +0000
Received: from DB6PR08MB2679.eurprd08.prod.outlook.com ([fe80::3c08:54b8:1c7c:498a]) by DB6PR08MB2679.eurprd08.prod.outlook.com ([fe80::3c08:54b8:1c7c:498a%13]) with mapi id 15.01.1124.009; Wed, 31 May 2017 13:05:06 +0000
From: Juan Carlos Zuniga 
To: weigengyu , "lp-wan@ietf.org" 
Thread-Topic: [lp-wan] I-D Action: draft-ietf-lpwan-ipv6-static-context-hc-03.txt
Thread-Index: AQHSxcmWE6nZkl3R706y6Booc4wueKHxql0AgACgpbCAACfGgIAAarLAgBsJAoCAAKj3AA==
Date: Wed, 31 May 2017 13:05:06 +0000
Message-ID: 
References: <149400726585.8434.8654374640287295976@ietfa.amsl.com>   <8C6EB16391684A7DB1E8C9040F48C612@WeiGengyuPC>  <40A3CE3DAE3B4E27ADBDF29595C222D4@WeiGengyuPC>
In-Reply-To: <40A3CE3DAE3B4E27ADBDF29595C222D4@WeiGengyuPC>
Accept-Language: en-CA, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: bupt.edu.cn; dkim=none (message not signed) header.d=none;bupt.edu.cn; dmarc=none action=none header.from=sigfox.com;
x-originating-ip: [104.163.152.104]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DB6PR08MB2677; 7:7CCr9ZCRj8UAJ26jnsyNZKfrN2yKFxTHLW+w/8CNBt5egOtJ9v7aJ97v44yPcPmM/sLx0mwbNDTJBLb16oX/ZEO3eHDJGTuKVUMJ6/KlrTs18f72Ve5qQOfhOD6o8EmAPbb+7Vq83LP1XEo6TAgGMncPsG8aIManmfOFdQAZy6rYt+vuGMmm/k7PAoYsmwOLZRZBSUPWjjOdVr8Da7BXb6dFzA0iCLUKaK+Dhrk+AK9ULlxig2xjMsN5cxlEcom8qlKlnClyizRQ9kTSjClkm4P70ogsSI9oUU41Xev6qlgJXbJenEYell3TJ1M3rQS1qVxc7AZuGfwWoY5tadbovA==
x-ms-traffictypediagnostic: DB6PR08MB2677:
x-ms-office365-filtering-correlation-id: 7b7c7eb5-4825-4096-7ca4-08d4a825a912
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:DB6PR08MB2677; 
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(120809045254105);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700073)(100105000095)(100000701073)(100105300095)(100000702073)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(100000703073)(100105400095)(3002001)(10201501046)(6041248)(20161123564025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123558100)(20161123562025)(6072148)(100000704073)(100105200095)(100000705073)(100105500095); SRVR:DB6PR08MB2677; BCL:0; PCL:0; RULEID:(100000800073)(100110000095)(100000801073)(100110300095)(100000802073)(100110100095)(100000803073)(100110400095)(100000804073)(100110200095)(100000805073)(100110500095); SRVR:DB6PR08MB2677; 
x-forefront-prvs: 0324C2C0E2
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39400400002)(39410400002)(39830400002)(39450400003)(377424004)(13464003)(377454003)(53754006)(3660700001)(53546009)(3846002)(6116002)(102836003)(229853002)(25786009)(8676002)(81166006)(6246003)(5250100002)(86362001)(14454004)(6506006)(2501003)(66066001)(8936002)(3280700002)(74316002)(2906002)(93886004)(76176999)(2950100002)(2900100001)(7736002)(305945005)(7696004)(5660300001)(966005)(230783001)(6436002)(478600001)(33656002)(54356999)(6306002)(38730400002)(189998001)(2171002)(50986999)(9686003)(55016002)(53936002); DIR:OUT; SFP:1102; SCL:1; SRVR:DB6PR08MB2677; H:DB6PR08MB2679.eurprd08.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: sigfox.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 31 May 2017 13:05:06.9274 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: fcbc8bb1-061e-4b94-9f70-3ad917b0c8d3
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR08MB2677
Archived-At: 
Subject: Re: [lp-wan] I-D Action: draft-ietf-lpwan-ipv6-static-context-hc-03.txt
X-BeenThere: lp-wan@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Low-Power Wide Area Networking \(LP-WAN\), also known as LPWA or Low-Rate WAN \(LR-WAN\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 31 May 2017 13:05:13 -0000

SGkgR2VuZ3l1LA0KDQpJbmRlZWQsIHRoZXkgZG9uJ3QuIE1pY3JvY29udHJvbGxlci1iYXNlZCBk
ZXZpY2VzIHdvdWxkIG5vdCBoYXZlIGFuIElQIHN0YWNrLiANCkluIG91ciBkZW1vIGl0IHdhcyB0
aGUgU0NIQyBDL0QgaW4gdGhlIENvcmUgd2hpY2ggcmVnZW5lcmF0ZWQgdGhlIElQL1VEUCBmcmFt
ZS4NCg0KQmVzdCwNCg0KSnVhbi1DYXJsb3MNCg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t
LS0tDQo+IEZyb206IHdlaWdlbmd5dSBbbWFpbHRvOndlaWdlbmd5dUBidXB0LmVkdS5jbl0NCj4g
U2VudDogTWF5IDMwLCAyMDE3IDEwOjUzIFBNDQo+IFRvOiBKdWFuIENhcmxvcyBadW5pZ2EgPGp1
YW5jYXJsb3MuenVuaWdhQHNpZ2ZveC5jb20+OyBscC13YW5AaWV0Zi5vcmcNCj4gU3ViamVjdDog
UmU6IFtscC13YW5dIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtbHB3YW4taXB2Ni1zdGF0aWMtY29u
dGV4dC1oYy0wMy50eHQNCj4gDQo+IEhpIEp1YW4sDQo+IA0KPiBJdCBpcyBub3QgcXVpdGUgY2xl
YXIgd2h5IHRoZSB2ZXJ5IGNvbnN0cmFpbmVkIG5vZGVzIG5lZWQgdGhlIFVEUD8NCj4gDQo+IFJl
Z2FyZHMsDQo+IA0KPiBHZW5neXUgV0VJDQo+IE5ldHdvcmsgVGVjaG5vbG9neSBDZW50ZXINCj4g
U2Nob29sIG9mIENvbXB1dGVyDQo+IEJlaWppbmcgVW5pdmVyc2l0eSBvZiBQb3N0cyBhbmQgVGVs
ZWNvbW11bmljYXRpb25zDQo+IC0tLS0t5Y6f5aeL6YKu5Lu2LS0tLS0NCj4gRnJvbTogSnVhbiBD
YXJsb3MgWnVuaWdhDQo+IFNlbnQ6IFN1bmRheSwgTWF5IDE0LCAyMDE3IDY6MDYgQU0NCj4gVG86
IHdlaWdlbmd5dSA7IGxwLXdhbkBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW2xwLXdhbl0gSS1E
IEFjdGlvbjoNCj4gZHJhZnQtaWV0Zi1scHdhbi1pcHY2LXN0YXRpYy1jb250ZXh0LWhjLTAzLnR4
dA0KPiANCj4gSGkgR2VuZ3l1LA0KPiANCj4gVGhleSB3ZXJlIHNoYXJpbmcgdGhlIHNhbWUgQ29B
UC9VRFAvSVB2NiBjb250ZXh0Lg0KPiBPbmUgZGV2aWNlIHdhcyBjb21wcmVzc2luZy9kZWNvbXBy
ZXNzaW5nLCBhbmQgdGhlIG90aGVyIG9uZSB3YXNu4oCZdC4NCj4gDQo+IEJlc3QsDQo+IA0KPiBK
dWFuIENhcmxvcw0KPiANCj4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+IEZyb206
IHdlaWdlbmd5dSBbbWFpbHRvOndlaWdlbmd5dUBidXB0LmVkdS5jbl0NCj4gPiBTZW50OiBNYXkg
MTMsIDIwMTcgMTE6NDAgQU0NCj4gPiBUbzogSnVhbiBDYXJsb3MgWnVuaWdhIDxqdWFuY2FybG9z
Lnp1bmlnYUBzaWdmb3guY29tPjsgbHAtd2FuQGlldGYub3JnDQo+ID4gU3ViamVjdDogUmU6IFts
cC13YW5dIEktRCBBY3Rpb246DQo+ID4gZHJhZnQtaWV0Zi1scHdhbi1pcHY2LXN0YXRpYy1jb250
ZXh0LWhjLTAzLnR4dA0KPiA+DQo+ID4gSGkgSnVhbu+8jA0KPiA+DQo+ID4g44CJd2VyZSBhYmxl
IHRvIGNvbW11bmljYXRlIHdpdGggYSBDb0FQL1VEUC9JUHY2IEludGVybmV0IGFwcGxpY2F0aW9u
IGJ5DQo+ID4gdXNpbmcgU0NIQyBydWxlcy4NCj4gPg0KPiA+IE9uZSBub2RlIGJlaW5nIGFibGUg
dG8gY29tbXVuaWNhdGUgd2l0aCBhbm90aGVyIG9uZSBtZWFucyB0d28gbm9kZXMNCj4gPiBzaG91
bGQgc2hhcmUgc29tZSBjb250ZXh0cy4NCj4gPiBXaGF0IGFyZSB0aGV5LCB0aGUgSVB2NiBjb250
ZXh0LCBvciBVRFAvSVB2NiBjb250ZXh0cywgb3INCj4gPiBDb0FQL1VEUC9JUHY2IGNvbnRleHRz
Lg0KPiA+DQo+ID4gUmVnYXJkcywNCj4gPg0KPiA+IEdlbmd5dSBXRUkNCj4gPiBOZXR3b3JrIFRl
Y2hub2xvZ3kgQ2VudGVyDQo+ID4gU2Nob29sIG9mIENvbXB1dGVyDQo+ID4gQmVpamluZyBVbml2
ZXJzaXR5IG9mIFBvc3RzIGFuZCBUZWxlY29tbXVuaWNhdGlvbnMNCj4gPiAtLS0tLeWOn+Wni+mC
ruS7ti0tLS0tDQo+ID4gRnJvbTogSnVhbiBDYXJsb3MgWnVuaWdhDQo+ID4gU2VudDogU2F0dXJk
YXksIE1heSAxMywgMjAxNyA5OjI2IFBNDQo+ID4gVG86IHdlaWdlbmd5dSA7IGxwLXdhbkBpZXRm
Lm9yZw0KPiA+IFN1YmplY3Q6IFJlOiBbbHAtd2FuXSBJLUQgQWN0aW9uOg0KPiA+IGRyYWZ0LWll
dGYtbHB3YW4taXB2Ni1zdGF0aWMtY29udGV4dC1oYy0wMy50eHQNCj4gPg0KPiA+IEhpLA0KPiA+
DQo+ID4gTm90IGFsbCBkZXZpY2VzIG5lZWQgdG8gaW1wbGVtZW50IHRoZSBJUCBzdGFjay4NCj4g
Pg0KPiA+IEluIENoaWNhZ28gd2UgZGVtb25zdHJhdGVkIGhvdyB0d28gdHlwZSBvZiBkZXZpY2Vz
LCBvbmUgUmFzcGJlcnJ5IFBpDQo+ID4gKHdpdGggZnVsbCBJUCBzdGFjaykgYW5kIG9uZSBzaW1w
bGUgc2Vuc29yIHdpdGggYSBtaWNyb2NvbnRyb2xsZXINCj4gPiAod2l0aCBubyBJUCBzdGFjaywg
VURQLCBldGMuKSwgd2VyZSBhYmxlIHRvIGNvbW11bmljYXRlIHdpdGggYQ0KPiA+IENvQVAvVURQ
L0lQdjYgSW50ZXJuZXQgYXBwbGljYXRpb24gYnkgdXNpbmcgU0NIQyBydWxlcy4NCj4gPg0KPiA+
IEJlc3QsDQo+ID4NCj4gPiBKdWFuIENhcmxvcw0KPiA+DQo+ID4gPiAtLS0tLU9yaWdpbmFsIE1l
c3NhZ2UtLS0tLQ0KPiA+ID4gRnJvbTogbHAtd2FuIFttYWlsdG86bHAtd2FuLWJvdW5jZXNAaWV0
Zi5vcmddIE9uIEJlaGFsZiBPZiB3ZWlnZW5neXUNCj4gPiA+IFNlbnQ6IE1heSAxMiwgMjAxNyAx
MTo0MyBQTQ0KPiA+ID4gVG86IGxwLXdhbkBpZXRmLm9yZw0KPiA+ID4gU3ViamVjdDogUmU6IFts
cC13YW5dIEktRCBBY3Rpb246DQo+ID4gPiBkcmFmdC1pZXRmLWxwd2FuLWlwdjYtc3RhdGljLWNv
bnRleHQtaGMtMDMudHh0DQo+ID4gPg0KPiA+ID4gSGkgYWxsLA0KPiA+ID4NCj4gPiA+IFRoZXJl
IGlzIGEgcXVlc3Rpb24sIG1heWJlIGEgc2lsbHkgcXVlc3Rpb24uDQo+ID4gPg0KPiA+ID4gRG9l
cyB0aGUgZW5kLWRldmljZSBpbiBMb3JhLCBTaWdmb3gsIG9yIHRoZSBsaWtlIG5ldHdvcmtzIG5l
ZWQgdGhlDQo+ID4gPiBmYWNpbGl0aWVzIG9mIFVEUCBwcm90b2NvbD8NCj4gPiA+IEl0IGlzIGhl
YXJkIHRoYXQgaXQgZ2VuZXJhbGx5IGlzIHNpbXBsZSBvbmUgZnVuY3Rpb24gZGV2aWNlLCB0aGUN
Cj4gPiA+IHBvcnQgbXVsdGlwbGV4aW5nIGlzIHJlcXVpcmVkIG9yIG5vdD8NCj4gPiA+DQo+ID4g
PiBSZWdhcmRzLA0KPiA+ID4NCj4gPiA+IEdlbmd5dSBXRUkNCj4gPiA+IE5ldHdvcmsgVGVjaG5v
bG9neSBDZW50ZXINCj4gPiA+IFNjaG9vbCBvZiBDb21wdXRlcg0KPiA+ID4gQmVpamluZyBVbml2
ZXJzaXR5IG9mIFBvc3RzIGFuZCBUZWxlY29tbXVuaWNhdGlvbnMNCj4gPiA+IC0tLS0t5Y6f5aeL
6YKu5Lu2LS0tLS0NCj4gPiA+IEZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZw0KPiA+ID4g
U2VudDogU2F0dXJkYXksIE1heSAwNiwgMjAxNyAyOjAxIEFNDQo+ID4gPiBUbzogaS1kLWFubm91
bmNlQGlldGYub3JnDQo+ID4gPiBDYzogbHAtd2FuQGlldGYub3JnDQo+ID4gPiBTdWJqZWN0OiBb
bHAtd2FuXSBJLUQgQWN0aW9uOg0KPiA+ID4gZHJhZnQtaWV0Zi1scHdhbi1pcHY2LXN0YXRpYy1j
b250ZXh0LWhjLTAzLnR4dA0KPiA+ID4NCj4gPiA+DQo+ID4gPiBBIE5ldyBJbnRlcm5ldC1EcmFm
dCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHMNCj4gPiA+IGRp
cmVjdG9yaWVzLg0KPiA+ID4gVGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUgSVB2NiBv
dmVyIExvdyBQb3dlciBXaWRlLUFyZWENCj4gPiA+IE5ldHdvcmtzIG9mIHRoZSBJRVRGLg0KPiA+
ID4NCj4gPiA+ICAgICAgICAgVGl0bGUgICAgICAgICAgIDogTFBXQU4gU3RhdGljIENvbnRleHQg
SGVhZGVyIENvbXByZXNzaW9uIChTQ0hDKQ0KPiA+ID4gYW5kDQo+ID4gPiBmcmFnbWVudGF0aW9u
IGZvciBJUHY2IGFuZCBVRFANCj4gPiA+ICAgICAgICAgQXV0aG9ycyAgICAgICAgIDogQW5hIE1p
bmFidXJvDQo+ID4gPiAgICAgICAgICAgICAgICAgICAgICAgICAgIExhdXJlbnQgVG91dGFpbg0K
PiA+ID4gICAgICAgICAgICAgICAgICAgICAgICAgICBDYXJsZXMgR29tZXoNCj4gPiA+IEZpbGVu
YW1lICAgICAgICA6IGRyYWZ0LWlldGYtbHB3YW4taXB2Ni1zdGF0aWMtY29udGV4dC1oYy0wMy50
eHQNCj4gPiA+IFBhZ2VzICAgICAgICAgICA6IDM2DQo+ID4gPiBEYXRlICAgICAgICAgICAgOiAy
MDE3LTA1LTA1DQo+ID4gPg0KPiA+ID4gQWJzdHJhY3Q6DQo+ID4gPiAgICBUaGlzIGRvY3VtZW50
IGRlc2NyaWJlcyBhIGhlYWRlciBjb21wcmVzc2lvbiBzY2hlbWUgYW5kDQo+IGZyYWdtZW50YXRp
b24NCj4gPiA+ICAgIGZ1bmN0aW9uYWxpdHkgZm9yIElQdjYvVURQIHByb3RvY29scy4gIFRoZXNl
IHRlY2huaXF1ZXMgYXJlDQo+ID4gPiAgICBlc3BlY2lhbGx5IHRhaWxvcmVkIGZvciBMUFdBTiAo
TG93IFBvd2VyIFdpZGUgQXJlYSBOZXR3b3JrKSBuZXR3b3Jrcw0KPiA+ID4gICAgYW5kIGNvdWxk
IGJlIGV4dGVuZGVkIHRvIG90aGVyIHByb3RvY29sIHN0YWNrcy4NCj4gPiA+DQo+ID4gPiAgICBU
aGUgU3RhdGljIENvbnRleHQgSGVhZGVyIENvbXByZXNzaW9uIChTQ0hDKSBvZmZlcnMgYSBncmVh
dCBsZXZlbCBvZg0KPiA+ID4gICAgZmxleGliaWxpdHkgd2hlbiBwcm9jZXNzaW5nIHRoZSBoZWFk
ZXIgZmllbGRzLiAgU3RhdGljIGNvbnRleHQgbWVhbnMNCj4gPiA+ICAgIHRoYXQgaW5mb3JtYXRp
b24gc3RvcmVkIGluIHRoZSBjb250ZXh0IHdoaWNoLCBkZXNjcmliZXMgZmllbGQgdmFsdWVzLA0K
PiA+ID4gICAgZG9lcyBub3QgY2hhbmdlIGR1cmluZyB0aGUgcGFja2V0IHRyYW5zbWlzc2lvbiwg
YXZvaWRpbmcgY29tcGxleA0KPiA+ID4gICAgcmVzeW5jaHJvbml6YXRpb24gbWVjaGFuaXNtcywg
aW5jb21wYXRpYmxlIHdpdGggTFBXQU4NCj4gPiA+ICAgIGNoYXJhY3RlcmlzdGljcy4gIEluIG1v
c3Qgb2YgdGhlIGNhc2VzLCBJUHY2L1VEUCBoZWFkZXJzIGFyZSByZWR1Y2VkDQo+ID4gPiAgICB0
byBhIHNtYWxsIGlkZW50aWZpZXIuDQo+ID4gPg0KPiA+ID4gICAgVGhpcyBkb2N1bWVudCBkZXNj
cmliZXMgdGhlIGdlbmVyaWMgY29tcHJlc3Npb24vZGVjb21wcmVzc2lvbiBwcm9jZXNzDQo+ID4g
PiAgICBhbmQgYXBwbGllcyBpdCB0byBJUHY2L1VEUCBoZWFkZXJzLiAgU2ltaWxhciBtZWNoYW5p
c21zIGZvciBvdGhlcg0KPiA+ID4gICAgcHJvdG9jb2xzIHN1Y2ggYXMgQ29BUCB3aWxsIGJlIGRl
c2NyaWJlZCBpbiBhIHNlcGFyYXRlIGRvY3VtZW50Lg0KPiA+ID4gICAgTW9yZW92ZXIsIHRoaXMg
ZG9jdW1lbnQgc3BlY2lmaWVzIGZyYWdtZW50YXRpb24gYW5kIHJlYXNzZW1ibHkNCj4gPiA+ICAg
IG1lY2hhbmltcyBmb3IgU0NIQyBjb21wcmVzc2VkIHBhY2tldHMgZXhjZWVkaW5nIHRoZSBMMiBw
ZHUgc2l6ZSBhbmQNCj4gPiA+ICAgIGZvciB0aGUgY2FzZSB3aGVyZSB0aGUgU0NIQyBjb21wcmVz
c2lvbiBpcyBub3QgcG9zc2libGUgdGhlbiB0aGUNCj4gPiA+ICAgIElQdjYvVURQIHBhY2tldCBp
cyBzZW50Lg0KPiA+ID4NCj4gPiA+DQo+ID4gPiBUaGUgSUVURiBkYXRhdHJhY2tlciBzdGF0dXMg
cGFnZSBmb3IgdGhpcyBkcmFmdCBpczoNCj4gPiA+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5v
cmcvZG9jL2RyYWZ0LWlldGYtbHB3YW4taXB2Ni1zdGF0aWMtY29udGV4DQo+ID4gPiB0LQ0KPiA+
ID4gaGMvDQo+ID4gPg0KPiA+ID4gVGhlcmUgYXJlIGFsc28gaHRtbGl6ZWQgdmVyc2lvbnMgYXZh
aWxhYmxlIGF0Og0KPiA+ID4gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYt
bHB3YW4taXB2Ni1zdGF0aWMtY29udGV4dC1oYy0NCj4gPiA+IDAzDQo+ID4gPiBodHRwczovL2Rh
dGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWlldGYtbHB3YW4taXB2Ni1zdGF0aWMt
Yw0KPiA+ID4gb24NCj4gPiA+IHRleHQtaGMtDQo+ID4gPiAwMw0KPiA+ID4NCj4gPiA+IEEgZGlm
ZiBmcm9tIHRoZSBwcmV2aW91cyB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBhdDoNCj4gPiA+IGh0dHBz
Oi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLWxwd2FuLWlwdjYtc3RhdGlj
LWNvbnRlDQo+ID4gPiB4dA0KPiA+ID4gLWhjLTAzDQo+ID4gPg0KPiA+ID4NCj4gPiA+IFBsZWFz
ZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1l
IG9mDQo+ID4gPiBzdWJtaXNzaW9uIHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZm
IGFyZSBhdmFpbGFibGUgYXQNCj4gPiA+IHRvb2xzLmlldGYub3JnLg0KPiA+ID4NCj4gPiA+IElu
dGVybmV0LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBhdDoNCj4g
PiA+IGZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvDQo+ID4gPg0KPiA+ID4gX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiA+IGxwLXdh
biBtYWlsaW5nIGxpc3QNCj4gPiA+IGxwLXdhbkBpZXRmLm9yZw0KPiA+ID4gaHR0cHM6Ly93d3cu
aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9scC13YW4NCj4gPiA+DQo+ID4gPiBfX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+ID4gbHAtd2FuIG1haWxp
bmcgbGlzdA0KPiA+ID4gbHAtd2FuQGlldGYub3JnDQo+ID4gPiBodHRwczovL3d3dy5pZXRmLm9y
Zy9tYWlsbWFuL2xpc3RpbmZvL2xwLXdhbg0KPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fDQo+ID4gbHAtd2FuIG1haWxpbmcgbGlzdA0KPiA+IGxwLXdh
bkBpZXRmLm9yZw0KPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbHAt
d2FuDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
Xw0KPiBscC13YW4gbWFpbGluZyBsaXN0DQo+IGxwLXdhbkBpZXRmLm9yZw0KPiBodHRwczovL3d3
dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xwLXdhbg0KDQo=


From nobody Wed May 31 08:25:29 2017
Return-Path: 
X-Original-To: lp-wan@ietf.org
Delivered-To: lp-wan@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6194212EAB7; Wed, 31 May 2017 08:25:28 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: IESG Secretary 
To: "IETF-Announce" 
Cc: lp-wan@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.52.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <149624432799.19789.4040158786504902563@ietfa.amsl.com>
Date: Wed, 31 May 2017 08:25:28 -0700
Archived-At: 
Subject: [lp-wan] IPv6 over Low Power Wide-Area Networks (lpwan) WG Virtual Meeting: 2017-07-05
X-BeenThere: lp-wan@ietf.org
X-Mailman-Version: 2.1.22
List-Id: "Low-Power Wide Area Networking \(LP-WAN\), also known as LPWA or Low-Rate WAN \(LR-WAN\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 31 May 2017 15:25:28 -0000

The IPv6 over Low Power Wide-Area Networks (lpwan) Working Group will hold
a virtual interim meeting on 2017-07-05 from 16:00 to 17:00 Europe/Paris.

Agenda:
This meeting may or may not take place - depending on the need of implementers, or people that would like to discuss topics other than the ones that will be discussed @IETF99, e.g. interop preparations.

The meeting agenda will be adjusted with appropriate information before the meeting (1 week before the meeting at the latest). 


----------------------
Information on joining the meeting:
JOIN WEBEX MEETING
https://cisco.webex.com/ciscosales/j.php?MTID=me7f536292c568c696a054a7ff7ef0746
Meeting number (access code): 203 453 401
Meeting password: chicalors (24422567 from phones)


JOIN FROM A VIDEO SYSTEM OR APPLICATION
Dial sip:203453401@cisco.webex.com
>From the Cisco internal network, dial *267* and the 9-digit meeting number.  If you are the host, enter your PIN when prompted.  

JOIN BY PHONE
+1-866-432-9903 Call-in toll-free number (US/Canada) 
+1-408-525-6800 Call-in toll number (US/Canada)

Global call-in numbers:
https://cisco.webex.com/ciscosales/globalcallin.php?serviceType=MC&ED=370387747&tollFree=1

Toll-free dialing restrictions: 
https://www.webex.com/pdf/tollfree_restrictions.pdf

Can't join the meeting?
https://help.webex.com/docs/DOC-5412

Information about remote participation:
https://cisco.webex.com/ciscosales/j.php?MTID=me7f536292c568c696a054a7ff7ef0746 (see Agenda for password/details how to join)


From nobody Wed May 31 09:35:30 2017
Return-Path: 
X-Original-To: lp-wan@ietf.org
Delivered-To: lp-wan@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BC1B8129BA8; Wed, 31 May 2017 09:35:24 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: IETF Meeting Session Request Tool 
To: 
Cc: lp-wan@ietf.org, lpwan-chairs@ietf.org, suresh.krishnan@gmail.com, a@ackl.io
X-Test-IDTracker: no
X-IETF-IDTracker: 6.52.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <149624852476.19848.10745529161673298155.idtracker@ietfa.amsl.com>
Date: Wed, 31 May 2017 09:35:24 -0700
Archived-At: 
Subject: [lp-wan] lpwan - New Meeting Session Request for IETF 99
X-BeenThere: lp-wan@ietf.org
X-Mailman-Version: 2.1.22
List-Id: "Low-Power Wide Area Networking \(LP-WAN\), also known as LPWA or Low-Rate WAN \(LR-WAN\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 31 May 2017 16:35:25 -0000

A new meeting session request has just been submitted by Alexander Pelov, a Chair of the lpwan working group.


---------------------------------------------------------
Working Group Name: IPv6 over Low Power Wide-Area Networks
Area Name: Internet Area
Session Requester: Alexander Pelov

Number of Sessions: 1
Length of Session(s):  2 Hours
Number of Attendees: 100
Conflicts to Avoid: 
 First Priority:  6lo 6tisch core detnet roll cbor t2trg teep lwig
 Second Priority:  bier netconf intarea artarea 6man ace anima
 Third Priority:  isis quic httpbis babel trill curdle


People who must be present:
  Pascal Thubert
  Suresh Krishnan
  Alexander Pelov

Resources Requested:

Special Requests:
  
---------------------------------------------------------


From nobody Wed May 31 10:05:12 2017
Return-Path: 
X-Original-To: lp-wan@ietfa.amsl.com
Delivered-To: lp-wan@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5B9F126B6D; Wed, 31 May 2017 10:05:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.1
X-Spam-Level: 
X-Spam-Status: No, score=0.1 tagged_above=-999 required=5 tests=[BAYES_50=0.8,  RCVD_IN_DNSWL_LOW=-0.7] 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 3Zzdg5YnDgD2; Wed, 31 May 2017 10:05:03 -0700 (PDT)
Received: from relay3-d.mail.gandi.net (relay3-d.mail.gandi.net [IPv6:2001:4b98:c:538::195]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6EA4127241; Wed, 31 May 2017 10:05:02 -0700 (PDT)
Received: from [IPv6:2001:660:7301:3728:f822:284f:bdb5:9996] (unknown [IPv6:2001:660:7301:3728:f822:284f:bdb5:9996]) (Authenticated sender: alex@ackl.io) by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id CDA6BA80D7; Wed, 31 May 2017 19:05:00 +0200 (CEST)
From: Alexander Pelov 
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Message-Id: <58E6D5AA-1F9D-4455-9D64-C59CCFF5E7B3@ackl.io>
Date: Wed, 31 May 2017 19:04:59 +0200
Cc: Core 
To: lp-wan 
X-Mailer: Apple Mail (2.3273)
Archived-At: 
Subject: [lp-wan] Agenda for LPWAN interim meeting next Wednesday, June 7th
X-BeenThere: lp-wan@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Low-Power Wide Area Networking \(LP-WAN\), also known as LPWA or Low-Rate WAN \(LR-WAN\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 31 May 2017 17:05:06 -0000

Dear all,

You=E2=80=99ll find the updated agenda at the following address: =
https://datatracker.ietf.org/doc/agenda-interim-2017-lpwan-04-lpwan-01/

We=E2=80=99re nearing the finalization of the LPWAN Overview and the =
IP/UDP SCHC document.

The CoAP SCHC document is also on track to be completed in the following =
month. (thus CCing CORE)

Best,
The Chairs of LPWAN=20