IETF Logo Mail Archive

Re: [Iotops] WG Adoption Call on draft-moran-iot-nets-02

AKRAM SHERIFF <sheriff.akram.usa@gmail.com> Fri, 03 March 2023 00:27 UTC

Return-Path: <sheriff.akram@gmail.com>
X-Original-To: iotops@ietfa.amsl.com
Delivered-To: iotops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37E0EC151AFF for <iotops@ietfa.amsl.com>; Thu, 2 Mar 2023 16:27:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.094
X-Spam-Level:
X-Spam-Status: No, score=-2.094 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_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 LFilyBgeIJQD for <iotops@ietfa.amsl.com>; Thu, 2 Mar 2023 16:27:42 -0800 (PST)
Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::22c]) (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 6FA06C15154E for <iotops@ietf.org>; Thu, 2 Mar 2023 16:27:42 -0800 (PST)
Received: by mail-lj1-x22c.google.com with SMTP id f16so730302ljq.10 for <iotops@ietf.org>; Thu, 02 Mar 2023 16:27:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1677803260; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=G44dIDZ8IXn7uvmj7POjm/qviGWq92D4Lm/+Lx0taQY=; b=S32tV8H9F+6b74G4JFIcnBsDAmMf3VTYPryKjvU3MWUwBXK/xtjLDF9ET0cUsIg2/P Y/76GVY3JIfdmTEdRWNvhG9Is6927gDh7EiIdNWNR+StwIkh8nOScv0V0+hDoUOdCU3P 7BHoe2npsyh3UmFozhshvyJp7ClEpAWmC4puwqopgbHdPIFN2fp9AyYGvbB/2PsbV4Ot JWs4cOqDRnNaFbD9zh++boA3+meIAoGmuxniizg6GEQuSd6jbXiWwWtQPirCU+CTcPnM PPA2cIo7POej7QM9cic3zuJmm+ooiWHCT9FvODjYMgZ8sht58ejEoRasZGtEoCT5eWM8 WSWA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1677803260; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=G44dIDZ8IXn7uvmj7POjm/qviGWq92D4Lm/+Lx0taQY=; b=5Os1KgQPEQF2L23RdHv1M2mojI7/AZNT3GBuW9/lbtxH/sbmRPuq2lCCPcjt1zyHOL y3iMZcLDf707XFk9xkUl6bCTb8PFm7tsUIKamnY6NJxZPuAmITqlATRvzgABtC05lmOt ieP+16IW9P7Ch4cxQABda242CSMruCpCLB59vf9mCWYpZuFLEmHg832rqzPABQi5g6DH /kLN710+/ObpE0E7EJqQmRf78YF6FIw79EZQMZ1voeG3XNB26vEK87Kaodr/6n9c4R73 ikphUA06SYLBYa/uK4L8hmkKy+ASmagH5xpJ0wgobpAcCw97zdK5z/xr+FNtFMUJBlJ1 n64A==
X-Gm-Message-State: AO0yUKXjsYKEv1kYTcx7z4TPx694jZFMx9hs/+auNwLBCcQC9bAVmsnB V8AGiashN5eN8pOkp5DScWjfVpnqhvDJbcsz89FAHtVvIOA=
X-Google-Smtp-Source: AK7set9d2O5QrpuhgLBjen1mFAbttR0bUYz20mOycvEK0zdOXu1DfmZ/Z1ZuXPECF/tErH4eMH8DGo/gJFyeQ4vXAbw=
X-Received: by 2002:a2e:58c:0:b0:295:944c:f335 with SMTP id 134-20020a2e058c000000b00295944cf335mr3871449ljf.1.1677803260340; Thu, 02 Mar 2023 16:27:40 -0800 (PST)
MIME-Version: 1.0
References: <2b042daf-a7a4-84b4-bd9a-bb293849ca43@isode.com> <2C446A21-E61A-408A-99EA-5B3B34CA9AFA@vigilsec.com> <1744680.1677792579@dyas> <6174B4C8-697B-464B-AB02-6DAEF3910B94@vigilsec.com>
In-Reply-To: <6174B4C8-697B-464B-AB02-6DAEF3910B94@vigilsec.com>
From: AKRAM SHERIFF <sheriff.akram.usa@gmail.com>
Date: Thu, 02 Mar 2023 16:27:28 -0800
Message-ID: <CANqCZ1DADJuqbSfDZmSQ=LH1z+PXLbXnJBVSNLPt32eU5VOYCA@mail.gmail.com>
To: Russ Housley <housley@vigilsec.com>
Cc: Michael Richardson <mcr+ietf@sandelman.ca>, iotops@ietf.org
Content-Type: multipart/alternative; boundary="00000000000055ed6405f5f40327"
Archived-At: <https://mailarchive.ietf.org/arch/msg/iotops/GQfFMxYzMGZsT6Ri6_FZwgfXnBo>
Subject: Re: [Iotops] WG Adoption Call on draft-moran-iot-nets-02
X-BeenThere: iotops@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: IOT Operations <iotops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/iotops>, <mailto:iotops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/iotops/>
List-Post: <mailto:iotops@ietf.org>
List-Help: <mailto:iotops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/iotops>, <mailto:iotops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 03 Mar 2023 00:27:44 -0000

Hi  Russ/ Michael  et  al,
                                      PFI  my response.

1) Store and  forward mode of  Data communication at rest  does  NOT  work
in all  IOT usecases  as  some of the usecases  have  "Data compliance" or
Data sovereignty norms associated  with the  source of  data generated. In
some other  cases  the  IOT  gateways running  at the edge  may be limited
with their  memory to store and  forward  the data if the IP WAN
connectivity gets disconnected for longer periods of time.

2)  We need to look at compressing the data , encrypting the  data at rest
and  then  encrypting the  data in motion  to  send it out to the  Cloud.
              Is  compression of  IOT data at rest  at  the edge of  the
network  not in this  IETF mandate as a sub-section ?


Regards
Akram

On Thu, Mar 2, 2023 at 3:06 PM Russ Housley <housley@vigilsec.com> wrote:

> Michael:
>
> > Russ Housley <housley@vigilsec.com> wrote:
> >> I have no objection to the adoption of this document, but I would like
> >> to see the discussion also cover protection of data at rest in the IoT
> >> device.  Currently, it talks about "information in transit on the
> >> networks or stored in the IoT application or in the Cloud."  However,
> >> the protections for data at rest are not really covered in the
> >> subsections that follow.
> >
> > While I agree that this is important, I am not entirely certain it's
> within
> > the IETF's mandate :-)
> > That doesn't mean we shouldn't do it though, but it may be too big a
> bite.
>
> We have mechanisms that were defines for store-and-forward communications
> that will work.  Just use them.
>
> Russ
>
> --
> Iotops mailing list
> Iotops@ietf.org
> https://www.ietf.org/mailman/listinfo/iotops
>

v2.23.0 | Report a Bug | By Email