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

Behcet Sarikaya <sarikaya2012@gmail.com> Thu, 07 July 2022 14:35 UTC

Return-Path: <sarikaya2012@gmail.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 C41BCC15B268 for <lp-wan@ietfa.amsl.com>; Thu, 7 Jul 2022 07:35:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.854
X-Spam-Level:
X-Spam-Status: No, score=-1.854 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=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=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wAFBYDpAUjBW for <lp-wan@ietfa.amsl.com>; Thu, 7 Jul 2022 07:35:16 -0700 (PDT)
Received: from mail-lj1-x232.google.com (mail-lj1-x232.google.com [IPv6:2a00:1450:4864:20::232]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30EC9C157B56 for <lp-wan@ietf.org>; Thu, 7 Jul 2022 07:35:16 -0700 (PDT)
Received: by mail-lj1-x232.google.com with SMTP id bn33so1094503ljb.13 for <lp-wan@ietf.org>; Thu, 07 Jul 2022 07:35:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:reply-to:from:date:message-id :subject:to:cc; bh=ElC7tvd1gycS0Hcg+OFLw7e41Vm31kADtUjOmP7hUBc=; b=YW2YLv5wiFnz+RCvqrlSA/iZayw/WLmq1r2aplgKd//Fxu85eeCCj2ptqH5yG1Svtc K1HI05G8MKzRlQ94tqDPvuOGSstlnhy2vUYNzfixYQNCty39vW0cYJTA6V9tfTLDehZ1 Sz368qH5N0WKDY2ktlcDkAaEzdDAdu4BUO2590Fx6RiPS28yMSB1IpGOIuKREehubxBE 6EVJ4A0rlpMOboLp28DNbm7tVdDIAZACCqoakPZqF5sK/7kg2rcTIpvK9Wr8VD2IsLky nx3oZp2W6enrqJ9prX9hhr8MFqq52dY9G6MPTWPbr2oaxn9teUHMm069Nlz7JmJPlD7U B2AA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:reply-to :from:date:message-id:subject:to:cc; bh=ElC7tvd1gycS0Hcg+OFLw7e41Vm31kADtUjOmP7hUBc=; b=tjThyDpKxFR9znt/iPr7AB5a8zEmnh53reefS/TmwkhSfWTfTvmMOaTrTlTrvmqtrj ZK+nNxb422f22ppGOEda51Ga9z5Sv06SwlX/pOOo58PO/V63DuC8gshOr0d6arD69fpb cjOrN7pkzeL8M27Oh8mUiA2NHGXWTqWY0LibkN1aLLY33p08vevtCHhD2aOwT/ygOJn2 KkAqBXwClJTPQwd0Gz9L8QWLMxk2Kwrgt+nUD3frwczOG0EH/Qz1cfnuo10L2Cb7kVaQ hwpd1fm7NmhWWtWUM6foVKWH/Qb/dlwQT8CoLLZzVMEFoIdr0TGfJSRRbn+4E6g7EU9y Bt+g==
X-Gm-Message-State: AJIora/9UOdEZ9X3fnF+MRMy7DUTVDi/URoN1MplsiLFqAZNen1gtMpL 79ei/IJ3PuUPdY9fQWZCH8CLWaZL7he9XJA86mWDiR84
X-Google-Smtp-Source: AGRyM1tds7sLH5Yx1kJ1X9ob2nHdfZgdl55wbH4SEQPEIQfdGxTqCVd73FDCtSUMph8Ee1GHMJXVYzRtt9vJNNq6FDo=
X-Received: by 2002:a05:651c:4cf:b0:25a:9cbe:bf4b with SMTP id e15-20020a05651c04cf00b0025a9cbebf4bmr28048871lji.379.1657204514088; Thu, 07 Jul 2022 07:35:14 -0700 (PDT)
MIME-Version: 1.0
References: <CO1PR11MB48815290EBCB484D4E4E3736D8809@CO1PR11MB4881.namprd11.prod.outlook.com> <CAC8QAcfJRes+T0xhLZd1uCjQ71tHa7d_=-d7udD6sS5SM8HhSg@mail.gmail.com> <8c4b58a0-04eb-2869-b7db-cfab87d9d131@htt-consult.com>
In-Reply-To: <8c4b58a0-04eb-2869-b7db-cfab87d9d131@htt-consult.com>
Reply-To: sarikaya@ieee.org
From: Behcet Sarikaya <sarikaya2012@gmail.com>
Date: Thu, 07 Jul 2022 09:35:02 -0500
Message-ID: <CAC8QAcdYBN6ddpMuEsNbREtJjezfCLgS7=B-PeqCSYgqYvXV9w@mail.gmail.com>
To: Robert Moskowitz <rgm-ietf@htt-consult.com>
Cc: "Pascal Thubert (pthubert)" <pthubert=40cisco.com@dmarc.ietf.org>, lp-wan <lp-wan@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000061eb8d05e337feb5"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lp-wan/vAA1ZSWRPUCKnMVj66Q1GvI0wuo>
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:35:19 -0000

Hi Bob,

I am still puzzled on why a UA LPWAN.

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
>>
>
>