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

Robert Moskowitz <rgm-ietf@htt-consult.com> Thu, 07 July 2022 14:53 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 91CBBC15A72E for <lp-wan@ietfa.amsl.com>; Thu, 7 Jul 2022 07:53:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.781
X-Spam-Level:
X-Spam-Status: No, score=-3.781 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-1.876, 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 Fv9OEuN8x3fR for <lp-wan@ietfa.amsl.com>; Thu, 7 Jul 2022 07:53:17 -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 54B60C15D47B for <lp-wan@ietf.org>; Thu, 7 Jul 2022 07:53:17 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 32ACC6250B; Thu, 7 Jul 2022 10:52:30 -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 hstQrrzGlTt0; Thu, 7 Jul 2022 10:52:21 -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 E2B4C62434; Thu, 7 Jul 2022 10:52:20 -0400 (EDT)
Content-Type: multipart/alternative; boundary="------------Pu0OUvHLgWEm6HCZYm06xVtf"
Message-ID: <3a2aaeb7-59ba-46a7-4f2d-5ec7b52ff0c4@htt-consult.com>
Date: Thu, 07 Jul 2022 10:53:02 -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
Cc: "Pascal Thubert (pthubert)" <pthubert=40cisco.com@dmarc.ietf.org>, lp-wan <lp-wan@ietf.org>
References: <CO1PR11MB48815290EBCB484D4E4E3736D8809@CO1PR11MB4881.namprd11.prod.outlook.com> <CAC8QAcfJRes+T0xhLZd1uCjQ71tHa7d_=-d7udD6sS5SM8HhSg@mail.gmail.com> <8c4b58a0-04eb-2869-b7db-cfab87d9d131@htt-consult.com> <CAC8QAcdYBN6ddpMuEsNbREtJjezfCLgS7=B-PeqCSYgqYvXV9w@mail.gmail.com>
From: Robert Moskowitz <rgm-ietf@htt-consult.com>
In-Reply-To: <CAC8QAcdYBN6ddpMuEsNbREtJjezfCLgS7=B-PeqCSYgqYvXV9w@mail.gmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/lp-wan/Y4utbivRUgucfDulDuoxNaE9SVs>
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: Thu, 07 Jul 2022 14:53:21 -0000


On 7/7/22 10:35, Behcet Sarikaya wrote:
> Hi Bob,
>
> I am still puzzled on why a UA LPWAN.

How would you connect the UA to the ground?  And don't spout 3GPP. It 
does not have the coverage in many areas and never will.  Even Canada 
Transport wants alternatives to 3GPP.

>
> On Wed, Jul 6, 2022 at 2:41 PM Robert Moskowitz 
> <rgm-ietf@htt-consult.com> wrote:
>
>     Air to ground communications over a constrained wireless tech.
>
>     But that would just be the 'job' of the wireless tech provider!
>
> So this doesn't cut it.
>
>     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.
>
>
> This sounds like a hypothetical scenario?
>
>     It is the use case in the draft?
>
>
> Is it? Then please add some text to the draft.
>
> Behcet
>
>     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
>>
>
>
> _______________________________________________
> lp-wan mailing list
> lp-wan@ietf.org
> https://www.ietf.org/mailman/listinfo/lp-wan