Re: [icnrg] Last Call: draft-irtf-icnrg-ipoc

Luca Muscariello <muscariello@ieee.org> Thu, 14 May 2020 21:49 UTC

Return-Path: <muscariello@ieee.org>
X-Original-To: icnrg@ietfa.amsl.com
Delivered-To: icnrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D8D23A0D88 for <icnrg@ietfa.amsl.com>; Thu, 14 May 2020 14:49:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.171
X-Spam-Level:
X-Spam-Status: No, score=-2.171 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.173, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, SPF_HELO_NONE=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=ieee.org
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 jTlGvv5ehnXx for <icnrg@ietfa.amsl.com>; Thu, 14 May 2020 14:49:39 -0700 (PDT)
Received: from mail-wr1-x431.google.com (mail-wr1-x431.google.com [IPv6:2a00:1450:4864:20::431]) (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 58E3D3A0D7F for <icnrg@irtf.org>; Thu, 14 May 2020 14:49:38 -0700 (PDT)
Received: by mail-wr1-x431.google.com with SMTP id l18so753876wrn.6 for <icnrg@irtf.org>; Thu, 14 May 2020 14:49:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ieee.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ucgAbWliofSmeJtUVZ8Fv9N4D2L6ARRBSK9Htz0iLqE=; b=cMO2QpHO7BEPBRZc8awxdBj6h81EYvy8SFRWx8C1hTtkahyd8C6TeiqGyZQRKt1HaP wqcE36NbXj8bwjx04m74VoICLwpz1PWdkmxiO7AYc5sFFSahY9lEtO18/1PFcpLjsc0j GKbmhPERPDK7/FTwzJqYp2PjlalqxILm10CxA=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ucgAbWliofSmeJtUVZ8Fv9N4D2L6ARRBSK9Htz0iLqE=; b=DDVh8ew+tkDBucqw6xfqeIpqIHzBg1YHLr1nr+HXnQFTz5TlnXH8NfD/vEg3k3W5X3 w+nofx9jnUkh/TzGJT/tdDfgj11vCqAWePNsxpO+EfdIVDuqU5NU/lhZV2/0M/L5LVdK McXuHF300oS5aiS1p7kpTe9bIrTFcZ8uK8KYnbMUlD6Kc6KUbMOmJt6G34PXMKwNKjWS LwtVggEOYf3ROdIYRd9nX77HYMhFLUXcDnpnFXaf0tnnG1usD//MV5A/oBP4ruUBTCNk oicYjzaUzT3V2AWJb3QMt/SKl8YOBOnBsj6nlajtwKkIpdsz1j8DBCPfUllwylPr/Xex NG4Q==
X-Gm-Message-State: AOAM531WOLtPME0DLe2c8eIS6FObkaXQChKRFlUQJL2Xrz8M8u1M56oO 4ISI8jfD/dYP2N/9P6mlnmLs8X5+0fDF6mNb/NsgOQ==
X-Google-Smtp-Source: ABdhPJw5OTi0OzRqza5PK1GetJcR4PqiwK/WseeVPhYtsauQv8UtFtSMh+UFC29i/YE/fxm4iQkpnc0SqDr5pNcQfcU=
X-Received: by 2002:a5d:6108:: with SMTP id v8mr505909wrt.286.1589492976321; Thu, 14 May 2020 14:49:36 -0700 (PDT)
MIME-Version: 1.0
References: <93E56749-73D1-4E34-81BB-B7F66DA30F7A@orandom.net> <CAH8sseRzHtrKpw5S+DKOUuysiZ7LaFM=ew5sgrwQjvSqnKL00A@mail.gmail.com> <C8616085-6FE7-4C4F-8048-4CD40C423261@cablelabs.com> <CAH8sseQ5Zn1T8DH2YzZaRqc-3cVf3M47aveWOPvjg1Rov6Sq2A@mail.gmail.com> <0A3AFADD-B47E-45BA-A08A-94971C861C34@cablelabs.com> <CAH8sseS4NEi3RE360NUcxhUrbVW_vnDZGbRFv1L3U1WKivx68g@mail.gmail.com> <D2C9AF4E-9E25-48FD-9E0D-9214D397DEA2@dkutscher.net> <CAH8sseSXU1MsoahzCT+9g8Tc9nY-3oH+JTsafYqp4k3BDhrHrg@mail.gmail.com> <65AE7F1B-D307-478B-9B86-E36E863C0918@dkutscher.net> <CAH8sseT0HhzixQ+ofnpF+p+bhOV13z6Uj-tpVuzni_jgJPd9Cg@mail.gmail.com> <28EA075D-75B4-4046-88C4-1CA28458EDE3@dkutscher.net> <CAH8sseQv7evCHgCVQ3aBLnDotnVQ5suGjbip-yBRYmAMjB8Z9w@mail.gmail.com> <395162EA-39AE-41B3-8B2B-A28008266BD5@orandom.net> <72624FB2-D813-42F4-B559-58E0F3AE085B@cablelabs.com> <CAH8sseStpoLoQfQP2q9my4nY0ZMd6o24jcrhnu+JcO4P2ShDsw@mail.gmail.com> <CAH8sseS9z14Rhd3J9j5GgsHuSeW3eXCyLO3-5fWY7042f1ZtSg@mail.gmail.com> <CAM4XVkoj=ayzqa1nvQ6GU=VSpT6XAgo+v7D79-6_GV+eSrHALg@mail.gmail.com>
In-Reply-To: <CAM4XVkoj=ayzqa1nvQ6GU=VSpT6XAgo+v7D79-6_GV+eSrHALg@mail.gmail.com>
From: Luca Muscariello <muscariello@ieee.org>
Date: Thu, 14 May 2020 23:49:25 +0200
Message-ID: <CAH8sseRrUwtxXNjnzrBCCqUhcP6xzSNKhZXe_2N45R-EgYmsGw@mail.gmail.com>
To: Susmit <susmit@cs.colostate.edu>
Cc: Greg White <g.white@cablelabs.com>, icnrg <icnrg@irtf.org>, "Oran, Dave" <daveoran@orandom.net>, Dirk Kutscher <ietf@dkutscher.net>
Content-Type: multipart/alternative; boundary="0000000000003a3b4f05a5a2acb9"
Archived-At: <https://mailarchive.ietf.org/arch/msg/icnrg/dccHzStJsB6AyM2r-cDgBfxxJz0>
Subject: Re: [icnrg] Last Call: draft-irtf-icnrg-ipoc
X-BeenThere: icnrg@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Information-Centric Networking research group discussion list <icnrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/icnrg>, <mailto:icnrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/icnrg/>
List-Post: <mailto:icnrg@irtf.org>
List-Help: <mailto:icnrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/icnrg>, <mailto:icnrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Thu, 14 May 2020 21:49:54 -0000

Hi Susmit,

AFAIK, there's no payload in the interest packet in NDN.
Is there?

Luca

On Thu, May 14, 2020 at 7:12 PM Susmit <susmit@cs.colostate.edu> wrote:

> Hi Luca,
>
> Would you mind expanding on why you think it will not work with NDN?
> BTW, here is the actual NDN code that implemented IPoC -
> https://github.com/named-data/IPoC.
>
> Susmit
>
> On Tue, May 12, 2020 at 5:21 PM Luca Muscariello <muscariello@ieee.org>
> wrote:
>
>> +list
>>
>> + one more comment
>> I would let you check that IPoC can also work with NDN.
>> The draft mentions NDN too but I'm not sure it would work.
>> At first glance, it cannot work with NDN. But maybe things have changed.
>>
>> Luca
>>
>>
>> On Wed, May 13, 2020 at 12:01 AM Luca Muscariello <muscariello@ieee.org>
>> wrote:
>>
>>> Hi Greg,
>>>
>>> Thanks for the clarifications.
>>> More comments in line.
>>>
>>>
>>> On Sat, May 9, 2020 at 7:36 PM Greg White <g.white@cablelabs.com> wrote:
>>>
>>>> Hi Luca,
>>>>
>>>>
>>>>
>>>> Sorry for the delay in responding.
>>>>
>>>>
>>>>
>>>> The IPoC draft has been presented at four ICNRG meetings (the first
>>>> being November 2016) and the draft has been available since December 2017.
>>>> Several ICNRG participants have provided comments at the mic or on the
>>>> mailing list in the intervening 3.5 years, and in November the chairs asked
>>>> the authors and the RG if the draft was ready for last call.  The view of
>>>> the authors and the RG participants was that a couple of changes were
>>>> needed, but it was otherwise ready.  Anyway, as Dave indicated, the purpose
>>>> of Last Call is to force final reviews, and I agree with him that it
>>>> succeeded.
>>>>
>>>>
>>>>
>>>> On to your comments.
>>>>
>>>>
>>>>
>>>> Thanks for pointing out the language in the abstract..  I agree it does
>>>> sound like marketing, and will revise it.
>>>>
>>>>
>>>>
>>>> Some of your questions echo questions that others in the RG have asked
>>>> in the past, and have previously been answered verbally. You are not the
>>>> first to read the draft with the mindset that it must be trying to provide
>>>> ICN features to IP applications, and thus failing to accomplish the goal.
>>>> While I hope that Dirk and I have made it clear what the point of IPoC is,
>>>> let me be doubly sure here (and we can look for ways to make the text
>>>> clearer on this point as well).
>>>>
>>>>
>>>>
>>>> The primary benefit of IPoC is for the network operator, not for the
>>>> application. Mobile networks support thousands of 3rd party
>>>> applications that are built for the IP world.  Updating these applications
>>>> to use NDN/CCNx (or replacing them) will not happen quickly.
>>>>
>>>
>>> The introduction of the document is misleading because it puts too much
>>> emphasis
>>> on mobility. The document is not about mobility but on a
>>> tunneling protocol.
>>> Assuming total absence of the IP network creates some issues to me in
>>> case EPC is considered.
>>>
>>> For instance the following I-D in this RG
>>> https://datatracker.ietf.org/doc/draft-irtf-icnrg-icn-lte-4g
>>> <https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-irtf-icnrg-icn-lte-4g&data=02%7C01%7Csusmit%40cs.colostate.edu%7C7bf4d49612b34646a3cd08d7f6c2c1ee%7Cafb58802ff7a4bb1ab21367ff2ecfc8b%7C0%7C0%7C637249188662441903&sdata=F3ROaggCfuq2bJtp9FpZxhMI8Xkad2a7EecmAqtPMMI%3D&reserved=0>
>>> makes use of ICN for the user plane only along with IP.
>>>
>>> If you remove IP entirely then EPC operations vanish.
>>> Several interfaces do not use GTP. Some components may be physically
>>> located
>>> out of the backhaul. EPC w/o IP cannot be obtained by just replacing GTP.
>>>
>>> This document is in a logical loop to me:
>>>
>>> 0) There is no IP in the hypothetical EPC. But:
>>> 1) IP in the UE
>>> 2) IP in the eNB
>>> 3) No IP in S1-U (also in S1-C?), S1-MME? S5/S8? SGi? etc.
>>> 4) IP in the IPoC GW
>>> 5) IP in the Cloud (or anywhere the other application head end is
>>> running).
>>> 6) CCNx replaces ONLY GTP,
>>> 7) Mobility management is absent in CCNx so we must assume
>>>    the rest of the EPC components are still there (MME, HSS, SGW, PGW,
>>> PCF...)
>>> 8) Hence, there must be IP in this hypothetical EPC.
>>>
>>> If the document did not mention anything about LTE/EPC or GTP
>>> and just focused on a bare-bones description of the IP tunnel over CCNx
>>> it would make more sense to me.
>>>
>>> I also realize that by rewriting the abstract and the intro only
>>> you would achieve that easily, as the rest of the document, from
>>> section 2 until the end of the document, IS a bare-bones description
>>> of the tunneling protocol.
>>>
>>>
>>>
>>>
>>>>
>>>>
>>>> If an MNO wishes to support native CCNx applications, they have
>>>> multiple options.  One option is to deploy native CCNx forwarding in the
>>>> mobile core (without IP as an underlay). This would allow them to take
>>>> advantage of the CCNx mobility features instead of using a legacy mobility
>>>> plane (e.g. GTP/IP). But what about all of the existing 3rd party IP
>>>> applications?  Does the MNO need to continue to maintain the GTP/IP
>>>> mobility plane indefinitely to support them?  IPoC provides a mechanism
>>>> that an MNO can use to transition off of GTP/IP as a backhaul with *
>>>> *zero** changes to legacy IP applications (and hence zero work for the
>>>> application developer). Since there are zero changes to the legacy
>>>> applications, their communication semantics are of course not changed. The
>>>> benefit to the application is that it can continue to work as it always has.
>>>>
>>>>
>>>>
>>>> You are correct that IPoC is fairly isomorphic with GTP.  In the paper,
>>>> we argue that it has some (relatively minor) benefits compared to GTP
>>>> tunnel management, but otherwise it is comparable.
>>>>
>>>>
>>>>
>>>> To be absolutely clear, IPoC presumes that an MNO has an a priori
>>>> desire to deploy CCNx, and it offers them a transition strategy that
>>>> decreases the complexity in doing so. IPoC is not intended to be the end
>>>> goal or the motivating factor in itself.  But, many times, removing hurdles
>>>> is just as important as providing motivations.
>>>>
>>>>
>>>>
>>>> Your points about performance and computation cost are fair ones.
>>>> Neither implementation has been optimized for computational performance, so
>>>> that remains an area for experimentation and assessment.   This is an
>>>> experimental protocol after all.
>>>>
>>>
>>> The cost in terms of performance makes IPoC (as a tunnelling protocol)
>>> way more complex
>>> and expensive than any other secure tunnel used today.
>>> Considering that IPoC is just a tunneling protocol, that IMO cannot use
>>> unauthenticated endpoints,
>>> you should consider efficient alternatives to full signatures, e.g. by
>>> using HMAC.
>>> Provenance in IPoC is not even a requirement as the namespace need not
>>> authentication of provenance,
>>> as the end-points are identified by an IP address which is a locator.
>>> In fact if the IP addresses change the tunnel is reset.
>>>
>>>
>>>
>>>
>>>>
>>>>
>>>> Let me know if you see an opportunity to make some of these aspects
>>>> more clear in the draft.   As mentioned I will revise the abstract per your
>>>> suggestion, and will do another review with an eye toward eliminating some
>>>> of the confusing aspects.
>>>>
>>>
>>> Hope comments above can help achieving that.
>>> Best
>>> Luca
>>>
>>>
>>>
>>>
>>>>
>>>>
>>>> Best Regards,
>>>>
>>>> Greg
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> *From: *"Dave Oran (oran)" <daveoran@orandom.net>
>>>> *Date: *Wednesday, April 22, 2020 at 8:55 AM
>>>> *To: *Luca Muscariello <muscariello@ieee.org>
>>>> *Cc: *Dirk Kutscher <ietf@dkutscher.net>et>, Greg White
>>>> <g.white@CableLabs.com>om>, ICNRG <icnrg@irtf.org>
>>>> *Subject: *Re: [icnrg] Last Call: draft-irtf-icnrg-ipoc
>>>>
>>>>
>>>>
>>>> Not to derail the discussion, but one clarification on process. Last
>>>> Call is both for technical review and to assess consensus or the lack
>>>> thereof. As chair I have no problem with Last-calling documents in order to
>>>> achieve both goals. Sometimes last call works as a forcing function to
>>>> produce good technical review and foster discussion that did not happen
>>>> while a document languished as an RG work item with little or no feedback.
>>>>
>>>> So, I’d make the observation that I think the process is working in
>>>> this case. We have a solid, comprehensive technical review and a discussion
>>>> with the authors on that. It would be helpful if more ICNRG participants
>>>> would also review IPOC and weigh in on these and possibly other issues that
>>>> get raised.
>>>>
>>>> Lastly, the IRTF doesn’t work by consensus formally, so let’s focus on
>>>> the technical questions. The document won’t have passed last call until we
>>>> get better understanding of whether the technical questions are of a nature
>>>> that would argue against publication.
>>>>
>>>> DaveO.
>>>>
>>>>
>>>>
>>>> On 21 Apr 2020, at 10:41, Luca Muscariello wrote:
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Tue, Apr 21, 2020 at 4:28 PM Dirk Kutscher <ietf@dkutscher.net>
>>>> wrote:
>>>>
>>>> Hi Luca,
>>>>
>>>> > I fail to understand the definition of review in this list.
>>>> > I made technical comments and got not a single technical answer.
>>>> >
>>>> > What's the point of having open reviews?
>>>> > We can shutdown the discussion right away if this is what it is.
>>>> >
>>>> > I'm not interested in fake reviews to let documents go through w/o
>>>> > an open technical debate.
>>>>
>>>> Not sure, I follow.
>>>>
>>>> Nobody has discouraged the technical review. I am hoping that the
>>>> discussion continues. I was trying to explain the nature of this
>>>> document in my view: documenting an experimental approach (which may
>>>> not
>>>> be the most desirable approach for all scenarios). I did not object to
>>>> your other technical comments.
>>>>
>>>>
>>>>
>>>> So let us focus on technical details.
>>>>
>>>> So far I got none.
>>>>
>>>>
>>>>
>>>> Let's avoid getting text published that may generate mockery from
>>>>
>>>> people working on the 3GPP EPC.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> It's great to get the technical review. Unfortunately, in many groups,
>>>> not just ICNRG, we don't have enough of it before we last-call things.
>>>>
>>>>
>>>>
>>>> do not last call something that has no consensus yet.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> > this is the abstract:
>>>> >
>>>> > This document describes a protocol that enables tunneling of Internet
>>>> >    Protocol traffic over a Content Centric Network (CCNx) or a Named
>>>> >    Data Network (NDN).  The target use case for such a protocol is to
>>>> >    provide an IP mobility plane for mobile networks that might
>>>> > otherwise
>>>> >    use IP-over-IP tunneling, such as the GPRS Tunneling Protocol (GTP)
>>>> >    used by the Evolved Packet Core in LTE networks (LTE-EPC)..  By
>>>> >    leveraging the elegant, built-in support for mobility provided by
>>>> >    CCNx or NDN, this protocol achieves performance on par with
>>>> > LTE-EPC,
>>>> >    equivalent efficiency, and substantially lower implementation and
>>>> >    protocol complexity [Shannigrahi].  Furthermore, the use of
>>>> > CCNx/NDN
>>>> >    for this purpose paves the way for the deployment of ICN native
>>>> >    applications on the mobile network.
>>>> >
>>>> > For me the above text is wrong with a marketing tone.
>>>>
>>>>
>>>> Yes, I get it. This should be discussed.
>>>>
>>>>
>>>>
>>>> The document should be cleaned up from this kind of text.
>>>>
>>>> Who's going to buy into this?
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Cheers,
>>>> Dirk
>>>>
>>>>
>>>>
>>>> >
>>>> >
>>>> > On Tue, Apr 21, 2020 at 3:26 PM Dirk Kutscher <ietf@dkutscher.net>
>>>> > wrote:
>>>> >
>>>> >> Hi Luca,
>>>> >>
>>>> >>> The IPoC paper compares to GTP and concludes that it is no worse.
>>>> >>> It makes a lot of sense to compare to GTP and I am not surprised
>>>> >>> the authors made that comparison in the first place.
>>>> >>
>>>> >> Sure, it's helpful to explain how it compares to the GTP approach.
>>>> >>
>>>> >>> If a transition mechanism should be used it has to bring advantages
>>>> >>> to
>>>> >>> create incentives to switch to another solution.
>>>> >>>
>>>> >>> if, like you say Dirk, it is just about enabling applications to use
>>>> >>> ICN, the mechanism has to let the application use ICN. Otherwise,
>>>> >>> what's
>>>> >>> for?
>>>> >>>
>>>> >>> For instance:
>>>> >>>
>>>> >>>
>>>> >>> NDNizing Existing Applications: Research Issues and Experiences
>>>> >>
>>>> >> There are different ways to support applications, from adapting them
>>>> >> to
>>>> >> ICN (perhaps ideal) or just running them unmodified (this is what
>>>> >> IPOC
>>>> >> could enable).
>>>> >>
>>>> >>> The above work shows that to get benefits you have to work a lot
>>>> >>> more on the namespace, otherwise if you just tie locators to names,
>>>> >>> like in IPoC, you get something that is isomorphic to GTP.
>>>> >>
>>>> >> Clearly, more invasive changes would leverage ICN better. IPOC is
>>>> >> just
>>>> >> for those that you cannot change, i.e., it's transparent to the
>>>> >> applications.
>>>> >>
>>>> >>> In IPoC there are no rewards and no incentives. But it takes
>>>> >>> implicitly the risk of having CCNx in the stack of the client
>>>> >>> and in the access/backhaul network. Who's gonna take that
>>>> >>> risk and why?
>>>> >>
>>>> >> I think we all agree that there are better ways. Optimistically
>>>> >> speaking, this would only be used for a short period of time -- until
>>>> >> all relevant apps have been ICNified. :-)
>>>> >>
>>>> >> As a general comment: in a Research Group, we don't have to converge
>>>> >> on
>>>> >> one (possibly optimal) protocol. Instead, we can publish competing
>>>> >> experimental specifications -- enabling more experiments which could
>>>> >> inform later standards work (for example).
>>>> >>
>>>> >> Cheers,
>>>> >> Dirk
>>>> >>
>>>> >>
>>>> >>>
>>>> >>>
>>>> >>>>
>>>> >>>> In that sense, it would not have to show improvements over existing
>>>> >>>> tunneling tech at all -- it just has to be good enough (and work
>>>> >>>> correctly, of course).
>>>> >>>>
>>>> >>>
>>>> >>>
>>>> >>>
>>>> >>>>
>>>> >>>> It is clearly experimental and needs more testing (which may
>>>> >>>> exhibit
>>>> >>>> problems) -- that's why it's not proposed as a standard.
>>>> >>>>
>>>> >>>
>>>> >>> It cannot be proposed as standard from the IRTF.
>>>> >>>
>>>> >>>
>>>> >>>
>>>> >>>>
>>>> >>>> Cheers,
>>>> >>>> Dirk
>>>> >>>>
>>>> >>>>
>>>> >>>>>
>>>> >>>>> On Tue, Apr 21, 2020 at 6:05 AM Greg White <g.white@cablelabs.com
>>>> >
>>>> >>>>> wrote:
>>>> >>>>>
>>>> >>>>>> Luca,
>>>> >>>>>>
>>>> >>>>>>
>>>> >>>>>>
>>>> >>>>>> Clearly you have a vested interest in hICN.  But, just as there
>>>> >>>>>> are
>>>> >>>>>> multiple technologies to enable the transition from IPv4 to IPv6,
>>>> >>>>>> there is
>>>> >>>>>> value in having multiple transition technologies for ICN.  IPoC
>>>> >>>>>> fills
>>>> >>>>>> a
>>>> >>>>>> different niche from hICN, and it seems you’ve failed to
>>>> >>>>>> understand
>>>> >>>>>> that.
>>>> >>>>>> Whereas hICN is a way to run limited ICN applications over a
>>>> >>>>>> modified
>>>> >>>>>> IPv6
>>>> >>>>>> network, IPoC is a way to run **unmodified** IPv4/IPv6
>>>> >>>>>> applications
>>>> >>>>>> over
>>>> >>>>>> a pure CCNx network.  Both approaches have their own
>>>> >>>>>> applicability,
>>>> >>>>>> and
>>>> >>>>>> their own tradeoffs.  In the context of a mobile network, hICN
>>>> >>>>>> does
>>>> >>>>>> not
>>>> >>>>>> provide a mobility solution for IP traffic, and thus requires the
>>>> >>>>>> operator
>>>> >>>>>> to deploy and maintain two parallel forwarding planes. On the
>>>> >>>>>> other
>>>> >>>>>> hand,
>>>> >>>>>> IPoC allows the operator to eliminate IP routing and legacy
>>>> >>>>>> mobility
>>>> >>>>>> mechanisms from the mobile core and support all services over
>>>> >>>>>> CCNx.
>>>> >>>>>> Yes,
>>>> >>>>>> IPoC assumes a bigger first step (deployment of CCNx), but it
>>>> >>>>>> makes
>>>> >>>>>> taking
>>>> >>>>>> that step easier, and once taken, native CCNx applications can be
>>>> >>>>>> deployed
>>>> >>>>>> getting the advantages of the full CCNx architecture.
>>>> >>>>>> Additionally,
>>>> >>>>>> other
>>>> >>>>>> transition technologies (like HTTP->CCN proxies) can be deployed
>>>> >>>>>> to
>>>> >>>>>> enable
>>>> >>>>>> certain applications to get more of the CCNx-native benefits.
>>>> >>>>>>
>>>> >>>>>>
>>>> >>>>>>
>>>> >>>>>> -Greg
>>>> >>>>>>
>>>> >>>>>>
>>>> >>>>>>
>>>> >>>>>>
>>>> >>>>>>
>>>> >>>>>> *From: *Luca Muscariello <muscariello@ieee.org>
>>>> >>>>>> *Date: *Thursday, April 16, 2020 at 1:29 AM
>>>> >>>>>> *To: *Greg White <g.white@CableLabs.com>
>>>> >>>>>> *Cc: *"Dave Oran (oran)" <daveoran@orandom.net>et>, ICNRG
>>>> >>>>>> <icnrg@irtf.org>
>>>> >>>>>> *Subject: *Re: [icnrg] Last Call: draft-irtf-icnrg-ipoc
>>>> >>>>>>
>>>> >>>>>>
>>>> >>>>>>
>>>> >>>>>> Hi Greg,
>>>> >>>>>>
>>>> >>>>>>
>>>> >>>>>>
>>>> >>>>>> comments in line.
>>>> >>>>>>
>>>> >>>>>>
>>>> >>>>>>
>>>> >>>>>> On Thu, Apr 16, 2020 at 12:50 AM Greg White
>>>> >>>>>> <g.white@cablelabs.com>
>>>> >>>>>> wrote:
>>>> >>>>>>
>>>> >>>>>> Hi Luca,
>>>> >>>>>>
>>>> >>>>>>
>>>> >>>>>>
>>>> >>>>>> Thanks for the review and for the questions and comments.
>>>> >>>>>>
>>>> >>>>>>
>>>> >>>>>>
>>>> >>>>>> On your first question, the IPoC naming convention and CCNx
>>>> >>>>>> routing
>>>> >>>>>> mechanism ensure that the IPoC client remains in communication
>>>> >>>>>> with
>>>> >>>>>> the
>>>> >>>>>> IPoC gateway that provides reachability to the client’s
>>>> >>>>>> assigned
>>>> >>>>>> IP
>>>> >>>>>> address
>>>> >>>>>> by other devices on the IP network.  If the IPoC gateway becomes
>>>> >>>>>> unreachable due to a network attachment change (e.g. if the
>>>> >>>>>> client
>>>> >>>>>> leaves
>>>> >>>>>> the current IPoC network and joins another), it would need to
>>>> >>>>>> establish
>>>> >>>>>> communication with a new IPoC gateway in the new network, using
>>>> >>>>>> the
>>>> >>>>>> mechanism described in Section 8.  It would thus be in a
>>>> >>>>>> different
>>>> >>>>>> subnet,
>>>> >>>>>> with a different IP address.   It would also be possible for a
>>>> >>>>>> client
>>>> >>>>>> to
>>>> >>>>>> periodically run the Section 8 mechanism in order to determine
>>>> >>>>>> whether it
>>>> >>>>>> was connected to the topologically nearest gateway..  If it
>>>> finds
>>>> >>>>>> a
>>>> >>>>>> nearer
>>>> >>>>>> gateway (and thus gets a new IP address) it could begin
>>>> >>>>>> transitioning
>>>> >>>>>> new
>>>> >>>>>> IP connections to the new IP address, while allowing existing
>>>> >>>>>> connections
>>>> >>>>>> that used the previous IP address to complete.
>>>> >>>>>>
>>>> >>>>>>
>>>> >>>>>>
>>>> >>>>>>
>>>> >>>>>>
>>>> >>>>>> The IPoC GW is very similar to what we do in enterprise networks
>>>> >>>>>> with
>>>> >>>>>> LISP
>>>> >>>>>> to optimize Wi-Fi mobility management and more. Even if this
>>>> >>>>>> happens
>>>> >>>>>> from
>>>> >>>>>> the AP to the switch it does not change much.
>>>> >>>>>>
>>>> >>>>>> Similarly from the eNB to the SGW using GTP tunneling. IPoC does
>>>> >>>>>> not
>>>> >>>>>> provide any advantage w.r.t. LISP or GTP which both rely on IP
>>>> >>>>>> only.
>>>> >>>>>> I'd
>>>> >>>>>> say that in this case I only see the disadvantages of IPoC as it
>>>> >>>>>> makes the
>>>> >>>>>> assumption that CCNx is the backhaul.
>>>> >>>>>>
>>>> >>>>>> The fact that IPoC binds IP addresses to the CCNx namespace
>>>> >>>>>> destroys
>>>> >>>>>> all
>>>> >>>>>> good features of CCNx which is used with hands and legs tied.
>>>> >>>>>>
>>>> >>>>>> In summary: No many-to-many communications, weak security
>>>> >>>>>> properties,
>>>> >>>>>> inferior mobility wrt the state of the art and also no incentives
>>>> >>>>>> to
>>>> >>>>>> move
>>>> >>>>>> from the current solutions to this one.
>>>> >>>>>>
>>>> >>>>>>
>>>> >>>>>>
>>>> >>>>>>
>>>> >>>>>>
>>>> >>>>>> Correct me if I am misunderstanding, but questions 2 & 4 seem to
>>>> >>>>>> be
>>>> >>>>>> essentially the same question, i.e.:  is it expected that
>>>> >>>>>> Interests
>>>> >>>>>> and
>>>> >>>>>> Content Objects are all signed, and if so, what are the
>>>> >>>>>> performance
>>>> >>>>>> implications?
>>>> >>>>>>
>>>> >>>>>> As you noted, section 14 mentions signing of Interests and
>>>> >>>>>> Content
>>>> >>>>>> Objects, and implies that it is optional.  It is in fact
>>>> >>>>>> optional.
>>>> >>>>>> As
>>>> >>>>>> section 14 discusses, the protocol is intended for use within a
>>>> >>>>>> managed,
>>>> >>>>>> CCNx-based, mobile core network where endpoint authentication and
>>>> >>>>>> authorization is managed via existing means. Interest and CO
>>>> >>>>>> signing
>>>> >>>>>> would
>>>> >>>>>> certainly add computational complexity perhaps on the order of
>>>> >>>>>> the
>>>> >>>>>> complexity associated with encrypted tunnels in IP, so the
>>>> >>>>>> benefits
>>>> >>>>>> of
>>>> >>>>>> doing so would need to be weighed against the scalability
>>>> >>>>>> impacts.
>>>> >>>>>> I’ll
>>>> >>>>>> add an explicit mention in Section 4 that signing is optional.
>>>> >>>>>>
>>>> >>>>>>
>>>> >>>>>>
>>>> >>>>>> Q2 and Q4 are distinct questions related to the usage of signed
>>>> >>>>>> interest
>>>> >>>>>> systematically, i.e. 100% of the interests.
>>>> >>>>>>
>>>> >>>>>> Q2: This is about the fact that interests are signed because they
>>>> >>>>>> carry
>>>> >>>>>> payload. So local flow balance is gone and this has performance
>>>> >>>>>> implications in terms of congestion management, loss recovery AND
>>>> >>>>>> mobility.
>>>> >>>>>> All gone. This is what Q2 is about. Sorry for being so compact,
>>>> >>>>>> but
>>>> >>>>>> I'm
>>>> >>>>>> assuming some terminology is well understood in this list.
>>>> >>>>>>
>>>> >>>>>> Also what are the security implications of signing every
>>>> >>>>>> Interest?
>>>> >>>>>> It
>>>> >>>>>> looks very similar to an IPSEC GW with all the certificate
>>>> >>>>>> business.
>>>> >>>>>>
>>>> >>>>>>
>>>> >>>>>>
>>>> >>>>>> Q4: This is about the computation cost. In the hICN project we're
>>>> >>>>>> spending
>>>> >>>>>> a lot of time to bring performance of a single transfer beyond
>>>> >>>>>> 10Gbps. All
>>>> >>>>>> forms of optimizations are required: manifests, hash computation
>>>> >>>>>> offloading, software/hardware tricks and many more.. This is not
>>>> a
>>>> >>>>>> negligible point. In practice one would be tempted to disable
>>>> >>>>>> signatures.
>>>> >>>>>> This is worse.
>>>> >>>>>>
>>>> >>>>>> The security implication of using non authenticated end-points
>>>> >>>>>> are
>>>> >>>>>> very
>>>> >>>>>> well known even in a managed network. Managed networks carry
>>>> >>>>>> customer'
>>>> >>>>>> traffic and security is MUST, not an option.
>>>> >>>>>>
>>>> >>>>>> Current solid deployments of LISP in enterprise networks make use
>>>> >>>>>> of
>>>> >>>>>> authentication, GTP tunnels too in the EPC backhaul. Tunnel
>>>> >>>>>> confidentiality
>>>> >>>>>> may be an option but authentication is not.
>>>> >>>>>>
>>>> >>>>>> It is an option in EPC for 4G but for 5G UPC confidentiality is
>>>> >>>>>> mandatory..
>>>> >>>>>>
>>>> >>>>>>
>>>> >>>>>>
>>>> >>>>>>
>>>> >>>>>>
>>>> >>>>>>
>>>> >>>>>>
>>>> >>>>>>
>>>> >>>>>>
>>>> >>>>>> On question 3, there are two implementations that have been made
>>>> >>>>>> available.  One was built on the PARC Metis libraries,
>>>> >>>>>> experimental
>>>> >>>>>> results
>>>> >>>>>> using this implementation were shared at the November 13, 2016
>>>> >>>>>> ICNRG
>>>> >>>>>> Interim Meeting, and it was mentioned as well at the March 20,
>>>> >>>>>> 2018
>>>> >>>>>> and
>>>> >>>>>> July 21, 2018 ICNRG meeting where IPoC was presented.  While this
>>>> >>>>>> implementation is not currently being maintained, the code is
>>>> >>>>>> available.
>>>> >>>>>> The second implementation was built in ndnSim, and is available
>>>> >>>>>> on
>>>> >>>>>> GitHub..
>>>> >>>>>> Experimental results and a link to the repo can be found in the
>>>> >>>>>> paper
>>>> >>>>>> listed in the Informative References of the IPoC draft.  That
>>>> >>>>>> paper
>>>> >>>>>> discusses the benefits compared to the existing GTP tunneling
>>>> >>>>>> mechanisms
>>>> >>>>>> used in LTE-EPC.  I’m not sure why you are questioning whether
>>>> >>>>>> CCNx
>>>> >>>>>> consumer mobility still holds.  This protocol makes use of CCNx
>>>> >>>>>> stateful
>>>> >>>>>> forwarding directly, and is designed precisely to make use of
>>>> >>>>>> that
>>>> >>>>>> feature.
>>>> >>>>>>
>>>> >>>>>>
>>>> >>>>>>
>>>> >>>>>> I read the paper that describes and evaluates IPoC and compares
>>>> >>>>>> to
>>>> >>>>>> GTP.
>>>> >>>>>> That's the whole point. The conclusion of the paper is that IPoC
>>>> >>>>>> is
>>>> >>>>>> no
>>>> >>>>>> worse than GTP. Which is my whole point.
>>>> >>>>>>
>>>> >>>>>> What is the reason to disrupt a technology (GTP) and replace it
>>>> >>>>>> with
>>>> >>>>>> something that is no worse?
>>>> >>>>>>
>>>> >>>>>> As soon as the IPoC namespace is tied to the IP addresses of the
>>>> >>>>>> end-points of the tunnel, IPoC becomes isomorphic to GTP or any
>>>> >>>>>> tunneling
>>>> >>>>>> protocol making use of locators.
>>>> >>>>>>
>>>> >>>>>> So it is no worse than any of those protocols. This does not look
>>>> >>>>>> like a
>>>> >>>>>> compelling reason to change the transport infrastructure. Worse,
>>>> >>>>>> it
>>>> >>>>>> looks
>>>> >>>>>> like an argument NOT to move towards ICN.
>>>> >>>>>>
>>>> >>>>>>
>>>> >>>>>>
>>>> >>>>>> I am surprised that this draft has moved to last call with this
>>>> >>>>>> implicit
>>>> >>>>>> message.
>>>> >>>>>>
>>>> >>>>>>
>>>> >>>>>>
>>>> >>>>>> I did not pay attention to all drafts moving forward in this RG
>>>> >>>>>> because
>>>> >>>>>> there are so many of them being pushed by the chairs, but I hope
>>>> >>>>>> we
>>>> >>>>>> pay
>>>> >>>>>> more attention to "shoot-yourself-in-the-foot" messages.
>>>> >>>>>>
>>>> >>>>>>
>>>> >>>>>>
>>>> >>>>>>
>>>> >>>>>>
>>>> >>>>>> Best
>>>> >>>>>>
>>>> >>>>>> Luca
>>>> >>>>>>
>>>> >>>>>>
>>>> >>>>>>
>>>> >>>>>>
>>>> >>>>>>
>>>> >>>>>>
>>>> >>>>>>
>>>> >>>>>>
>>>> >>>>>>
>>>> >>>>>> Best Regards,
>>>> >>>>>>
>>>> >>>>>> Greg
>>>> >>>>>>
>>>> >>>>>>
>>>> >>>>>>
>>>> >>>>>>
>>>> >>>>>>
>>>> >>>>>>
>>>> >>>>>>
>>>> >>>>>> *From: *icnrg <icnrg-bounces@irtf.org> on behalf of Luca
>>>> >>>>>> Muscariello
>>>> >>>>>> <
>>>> >>>>>> muscariello@ieee.org>
>>>> >>>>>> *Date: *Monday, March 23, 2020 at 2:01 AM
>>>> >>>>>> *To: *"Dave Oran (oran)" <daveoran@orandom.net>
>>>> >>>>>> *Cc: *ICNRG <icnrg@irtf.org>
>>>> >>>>>> *Subject: *Re: [icnrg] Last Call: draft-irtf-icnrg-ipoc
>>>> >>>>>>
>>>> >>>>>>
>>>> >>>>>>
>>>> >>>>>> Hi
>>>> >>>>>>
>>>> >>>>>>
>>>> >>>>>>
>>>> >>>>>> I went through the draft and I have a few comments and some
>>>> >>>>>> questions.
>>>> >>>>>>
>>>> >>>>>>
>>>> >>>>>>
>>>> >>>>>> 1 how does this system work when IP addresses at local interfaces
>>>> >>>>>> change?
>>>> >>>>>>
>>>> >>>>>>   My question is about both the underlying mechanics and also the
>>>> >>>>>> performance
>>>> >>>>>>
>>>> >>>>>>   of the system in such cases.
>>>> >>>>>>
>>>> >>>>>> 2 What are the implications of using signed Interests in this
>>>> >>>>>> way?
>>>> >>>>>> I
>>>> >>>>>> mean
>>>> >>>>>>
>>>> >>>>>>   100% of the Interests are signed in the tunneling scheme. My
>>>> >>>>>> question is
>>>> >>>>>> both
>>>> >>>>>>
>>>> >>>>>>   in terms of security and performance. And with performance I
>>>> >>>>>> mean
>>>> >>>>>> both
>>>> >>>>>>
>>>> >>>>>>   mobility and local flow balance.
>>>> >>>>>>
>>>> >>>>>> 3 Is there any reality check and running code of this scheme?
>>>> >>>>>>
>>>> >>>>>>   Every Internet draft comes with a security section but not a
>>>> >>>>>> cost
>>>> >>>>>> section
>>>> >>>>>>
>>>> >>>>>>   however it is unclear in this specific case, what are the
>>>> >>>>>> benefits
>>>> >>>>>> of
>>>> >>>>>> this
>>>> >>>>>>
>>>> >>>>>>   scheme and if one would need it compared to existing tunneling
>>>> >>>>>> technologies.
>>>> >>>>>>
>>>> >>>>>>   The alleged benefits of CCNx in terms of mobility are never
>>>> >>>>>> spelled
>>>> >>>>>> out
>>>> >>>>>> in the
>>>> >>>>>>
>>>> >>>>>>   draft but it is unclear if any mobility benefit still holds
>>>> >>>>>> using
>>>> >>>>>> this
>>>> >>>>>> technique.
>>>> >>>>>>
>>>> >>>>>> 4 The cost of signing every packet is significant and would
>>>> >>>>>> probably
>>>> >>>>>> kill
>>>> >>>>>>
>>>> >>>>>>   the performance of the tunnel. In the last section the authors
>>>> >>>>>> seem
>>>> >>>>>> to
>>>> >>>>>>
>>>> >>>>>>   consider interest/data signatures as optional. Can this be
>>>> >>>>>> clarified and
>>>> >>>>>> spelled
>>>> >>>>>>
>>>> >>>>>>   out clearly? Is the intent to use the tunnel w/o signatures?
>>>> >>>>>>
>>>> >>>>>>
>>>> >>>>>>
>>>> >>>>>> Thank
>>>> >>>>>>
>>>> >>>>>> Best
>>>> >>>>>>
>>>> >>>>>> Luca
>>>> >>>>>>
>>>> >>>>>>
>>>> >>>>>>
>>>> >>>>>>
>>>> >>>>>>
>>>> >>>>>>
>>>> >>>>>>
>>>> >>>>>> On Fri, Mar 20, 2020 at 2:51 PM David R. Oran
>>>> >>>>>> <daveoran@orandom.net>
>>>> >>>>>> wrote:
>>>> >>>>>>
>>>> >>>>>> Hello ICNRG,
>>>> >>>>>>
>>>> >>>>>> This is a last call for comments on draft-irtf-icnrg-IPOC
>>>> >>>>>> (Internet
>>>> >>>>>> Protocol Tunneling over Content Centric Mobile Networks).
>>>> >>>>>>
>>>> >>>>>> We want to publish this as an Experimental RFC. Please read it
>>>> >>>>>> and
>>>> >>>>>> let
>>>> >>>>>> us know if you think there are issues. The last call ends on
>>>> >>>>>> April
>>>> >>>>>> 15,
>>>> >>>>>> i.e., 3 weeks from today.
>>>> >>>>>>
>>>> >>>>>> https://datatracker.ietf.org/doc/draft-irtf-icnrg-ipoc/
>>>> <https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-irtf-icnrg-ipoc%2F&data=02%7C01%7Csusmit%40cs.colostate.edu%7C7bf4d49612b34646a3cd08d7f6c2c1ee%7Cafb58802ff7a4bb1ab21367ff2ecfc8b%7C0%7C0%7C637249188662441903&sdata=wnj3dsfrOFqaID%2FVdbhnK8Aic3%2BCFi48V3w3K8yBQWA%3D&reserved=0>
>>>> >>>>>>
>>>> >>>>>> Abstract
>>>> >>>>>>
>>>> >>>>>>     This document describes a protocol that enables tunneling of
>>>> >>>>>> Internet
>>>> >>>>>>     Protocol traffic over a Content Centric Network (CCNx) or a
>>>> >>>>>> Named
>>>> >>>>>>     Data Network (NDN).  The target use case for such a protocol
>>>> >>>>>> is
>>>> >>>>>> to
>>>> >>>>>>     provide an IP mobility plane for mobile networks that might
>>>> >>>>>> otherwise
>>>> >>>>>>     use IP-over-IP tunneling, such as the GPRS Tunneling Protocol
>>>> >>>>>> (GTP)
>>>> >>>>>>     used by the Evolved Packet Core in LTE networks (LTE-EPC).
>>>> >>>>>> By
>>>> >>>>>>     leveraging the elegant, built-in support for mobility
>>>> >>>>>> provided
>>>> >>>>>> by
>>>> >>>>>>     CCNx or NDN, this protocol achieves performance on par with
>>>> >>>>>> LTE-EPC,
>>>> >>>>>>     equivalent efficiency, and substantially lower implementation
>>>> >>>>>> and
>>>> >>>>>>     protocol complexity [Shannigrahi].  Furthermore, the use of
>>>> >>>>>> CCNx/NDN
>>>> >>>>>>     for this purpose paves the way for the deployment of ICN
>>>> >>>>>> native
>>>> >>>>>>     applications on the mobile network.
>>>> >>>>>>
>>>> >>>>>> Best regards,
>>>> >>>>>> ICNRG chairs
>>>> >>>>>>
>>>> >>>>>>
>>>> >>>>>> DaveO
>>>> >>>>>>
>>>> >>>>>> _______________________________________________
>>>> >>>>>> icnrg mailing list
>>>> >>>>>> icnrg@irtf.org
>>>> >>>>>> https://www.irtf.org/mailman/listinfo/icnrg
>>>> <https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.irtf.org%2Fmailman%2Flistinfo%2Ficnrg&data=02%7C01%7Csusmit%40cs.colostate.edu%7C7bf4d49612b34646a3cd08d7f6c2c1ee%7Cafb58802ff7a4bb1ab21367ff2ecfc8b%7C0%7C0%7C637249188662451898&sdata=QBeJLfVXip82j8i35KeXV6JPxT5zwRi0ctqBHxZvbHk%3D&reserved=0>
>>>> >>>>>>
>>>> >>>>>>
>>>> >>>>
>>>> >>>>
>>>> >>>>> _______________________________________________
>>>> >>>>> icnrg mailing list
>>>> >>>>> icnrg@irtf.org
>>>> >>>>> https://www.irtf.org/mailman/listinfo/icnrg
>>>> <https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.irtf.org%2Fmailman%2Flistinfo%2Ficnrg&data=02%7C01%7Csusmit%40cs.colostate.edu%7C7bf4d49612b34646a3cd08d7f6c2c1ee%7Cafb58802ff7a4bb1ab21367ff2ecfc8b%7C0%7C0%7C637249188662461892&sdata=0svH1%2FOhcmFTLNgzfeWQBwaZvNZr0nCMhebe1dfIO70%3D&reserved=0>
>>>> >>>>
>>>> >>
>>>> >>
>>>> >>> _______________________________________________
>>>> >>> icnrg mailing list
>>>> >>> icnrg@irtf..org <icnrg@irtf.org>
>>>> >>> https://www.irtf.org/mailman/listinfo/icnrg
>>>> <https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.irtf.org%2Fmailman%2Flistinfo%2Ficnrg&data=02%7C01%7Csusmit%40cs.colostate.edu%7C7bf4d49612b34646a3cd08d7f6c2c1ee%7Cafb58802ff7a4bb1ab21367ff2ecfc8b%7C0%7C0%7C637249188662461892&sdata=0svH1%2FOhcmFTLNgzfeWQBwaZvNZr0nCMhebe1dfIO70%3D&reserved=0>
>>>> >>
>>>>
>>>>
>>>>
>>>> DaveO
>>>>
>>> _______________________________________________
>> icnrg mailing list
>> icnrg@irtf.org
>>
>> https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.irtf.org%2Fmailman%2Flistinfo%2Ficnrg&amp;data=02%7C01%7Csusmit%40cs.colostate.edu%7C7bf4d49612b34646a3cd08d7f6c2c1ee%7Cafb58802ff7a4bb1ab21367ff2ecfc8b%7C0%7C0%7C637249188662491883&amp;sdata=WFBKE1r7FCuA0MJEygETfm0iavfjkzSVS90pqyP1Wqc%3D&amp;reserved=0
>>
>