Re: [lp-wan] review of https://datatracker.ietf.org/doc/draft-moskowitz-lpwan-ipnumber/

Robert Moskowitz <rgm-ietf@htt-consult.com> Wed, 06 July 2022 19:41 UTC

Return-Path: <rgm-ietf@htt-consult.com>
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 0A3DAC15A74F for <lp-wan@ietfa.amsl.com>; Wed, 6 Jul 2022 12:41:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.78
X-Spam-Level:
X-Spam-Status: No, score=-3.78 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-1.876, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aUs1hRALvxZ5 for <lp-wan@ietfa.amsl.com>; Wed, 6 Jul 2022 12:41:13 -0700 (PDT)
Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [23.123.122.147]) (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 62A0BC15AD21 for <lp-wan@ietf.org>; Wed, 6 Jul 2022 12:41:13 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 52F7162769; Wed, 6 Jul 2022 15:40:27 -0400 (EDT)
X-Virus-Scanned: amavisd-new at htt-consult.com
Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id SV2pnizOFdhV; Wed, 6 Jul 2022 15:40:19 -0400 (EDT)
Received: from [192.168.160.11] (unknown [192.168.160.11]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id 795706247F; Wed, 6 Jul 2022 15:40:19 -0400 (EDT)
Content-Type: multipart/alternative; boundary="------------1vShy402dUD6fbTbG2A3Mxrr"
Message-ID: <8c4b58a0-04eb-2869-b7db-cfab87d9d131@htt-consult.com>
Date: Wed, 06 Jul 2022 15:41:01 -0400
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.10.0
Content-Language: en-US
To: sarikaya@ieee.org, "Pascal Thubert (pthubert)" <pthubert=40cisco.com@dmarc.ietf.org>
Cc: lp-wan <lp-wan@ietf.org>
References: <CO1PR11MB48815290EBCB484D4E4E3736D8809@CO1PR11MB4881.namprd11.prod.outlook.com> <CAC8QAcfJRes+T0xhLZd1uCjQ71tHa7d_=-d7udD6sS5SM8HhSg@mail.gmail.com>
From: Robert Moskowitz <rgm-ietf@htt-consult.com>
In-Reply-To: <CAC8QAcfJRes+T0xhLZd1uCjQ71tHa7d_=-d7udD6sS5SM8HhSg@mail.gmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/lp-wan/m1IY3TrPJ_OfCsw7R8IyWVwbNEg>
Subject: Re: [lp-wan] review of https://datatracker.ietf.org/doc/draft-moskowitz-lpwan-ipnumber/
X-BeenThere: lp-wan@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "Low-Power Wide Area Networking \(LP-WAN\), also known as LPWA or Low-Rate WAN \(LR-WAN\)" <lp-wan.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lp-wan>, <mailto:lp-wan-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lp-wan/>
List-Post: <mailto:lp-wan@ietf.org>
List-Help: <mailto:lp-wan-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lp-wan>, <mailto:lp-wan-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 06 Jul 2022 19:41:17 -0000

Air to ground communications over a constrained wireless tech.

But that would just be the 'job' of the wireless tech provider!

But consider some avionics on the UA that is ethernet connected to the 
controller that has the actual wireless adapter(s).  Then for E2E, we 
need to do the SCHC above IP.

It is the use case in the draft?

On 7/6/22 13:13, Behcet Sarikaya wrote:
> Hi all,
>
> I quickly read the draft.
> I don't understand why UA (unmanned aircraft, or a drone?) would need 
> LPWAN?
>
> Behcet
>
> On Wed, Jul 6, 2022 at 8:38 AM Pascal Thubert (pthubert) 
> <pthubert=40cisco.com@dmarc.ietf.org> wrote:
>
>     Dear all
>
>     I reviewed
>     https://datatracker.ietf.org/doc/draft-moskowitz-lpwan-ipnumber/
>
>     Please find my comments below.
>
>     In short, I believe that the document is useful and already well
>     advanced and I would support the adoption when times come. But I
>     need to ensure that a NH number is enough, vs. a new option that
>     would transport SCHC parameters like Rule Set ID and/or Instance ID.
>
>     I suspect we'll make the call at IETF 114 but we need feedback by
>     then, so please join in if you wish the draft to progress rapidly.
>
>     "
>     If the Next Header in the IP header were SCHC, not ESP, a clear
>     segregation of incoming traffic is directly supportable.
>     "
>     SCHC maintains P2P sessions (called Instances) that are associated
>     with a P2P transport. Can we have one and one only SCHC Instance
>     over SPI? How is the SCHC rule set determined?
>     In the case of SCHC over PPP,  the PPP connection indicates the
>     session one for one, and the rule set can be indicated as  URI in
>     the IPv6-Compression-Protocol Configuration option see
>     https://datatracker.ietf.org/doc/html/draft-thubert-intarea-schc-over-ppp-03#section-3
>
>     "
>     Where it is possible with ESP's SPI to mitigate inbound packet
>     processing challenges implicit SCHC would generate, DTLS header
>     does not safely even provide this and a SCHC IP number is
>     necessary to separate traffic.
>     "
>     Is the above undoable with TLS?
>
>     "
>     Operation starts using Veriport's WiFi service.
>     "
>     Can we avoid brand names?
>
>     "IANA" section: The new protocol should be added to
>     https://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xhtml
>     shouldn't it? And then, by ricochet it will effectively end in
>     https://www.iana.org/assignments/protocol-numbers.
>
>     Keep safe;
>
>     Pascal
>
>     _______________________________________________
>     lp-wan mailing list
>     lp-wan@ietf.org
>     https://www.ietf.org/mailman/listinfo/lp-wan
>