Re: [nwcrg] [irsg] IRSG ballot closed: <draft-irtf-nwcrg-nwc-ccn-reqs-08.txt> to Informational RFC

Colin Perkins <csp@csperkins.org> Fri, 04 March 2022 23:48 UTC

Return-Path: <csp@csperkins.org>
X-Original-To: nwcrg@ietfa.amsl.com
Delivered-To: nwcrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 953C73A131B; Fri, 4 Mar 2022 15:48:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.109
X-Spam-Level:
X-Spam-Status: No, score=-2.109 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, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=csperkins.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 UDiUV40sGK7v; Fri, 4 Mar 2022 15:48:45 -0800 (PST)
Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2:1]) (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 CEFF63A098C; Fri, 4 Mar 2022 15:48:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=csperkins.org; s=mythic-beasts-k1; h=To:Date:Subject:From; bh=kB1MqZ0hjuRjFTeee2j4I+ds1eAB9ScgfMwA85s6Dkk=; b=vbhwfdllbq4JAtmQfp96Efh0f+ oYKVnWnh7mlrN9riCtBkPjNpz8zFx5RS3imw22FtJIktT6GXE3hmbuDWBCWcixnpqqNkClU62sE0A UdJWTwdZ6UmOy22vEEQrEr11nAkOga2pAPdUCkTyEYSjOuYpyaHoS1skxvXbSOFztWJkIBNMd1aLf lfTa06xyLXKwLKUsLo9+SdVjKKUZ7zAHUdoMYmXCisL5YHg0VCTW/Og/aq5tWw6pkzOdAQohYA+ef qEb7KpTo3lJ3pGUK1BaXatilzeaCyBEkCf8D3/W4ZiB8E1NUWRSXOUcZGFZXJjXNMWKTyOjlepmKp obZPIBHw==;
Received: from [81.187.2.149] (port=46796 helo=[192.168.0.67]) by haggis.mythic-beasts.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92.3) (envelope-from <csp@csperkins.org>) id 1nQHf3-0006FA-49; Fri, 04 Mar 2022 23:48:37 +0000
From: Colin Perkins <csp@csperkins.org>
Message-Id: <34B22A6D-6587-493E-BEA9-F522F77B106C@csperkins.org>
Content-Type: multipart/alternative; boundary="Apple-Mail=_7F9142A2-96DC-4951-BCC3-89614655C3AE"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.21\))
Date: Fri, 04 Mar 2022 23:48:26 +0000
In-Reply-To: <CAKKJt-fk3v-2M3Z1qW2A5pwN9L906ppXx517cGMrar5UBuheHw@mail.gmail.com>
Cc: matsuzono@nict.go.jp, Mirja Kühlewind <mirja.kuehlewind@ericsson.com>, amankin@salesforce.com, "irsg@irtf.org Steering Group" <irsg@irtf.org>, draft-irtf-nwcrg-nwc-ccn-reqs@ietf.org, nwcrg <nwcrg@irtf.org>, nwcrg-chairs@ietf.org, icnrg-chairs@ietf.org
To: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
References: <164433643983.1095.12436274460691964990@ietfa.amsl.com> <5A244216-1BC0-4F0E-B067-E77472CBFAF0@csperkins.org> <BYAPR13MB2805657BAAD98395965DD753FF2D9@BYAPR13MB2805.namprd13.prod.outlook.com> <324160DA-D9C4-4B2C-A74B-8E0DAE5905C4@csperkins.org> <20220228050110.00005589.0270@nict.go.jp> <CAKKJt-fk3v-2M3Z1qW2A5pwN9L906ppXx517cGMrar5UBuheHw@mail.gmail.com>
X-Mailer: Apple Mail (2.3445.104.21)
X-BlackCat-Spam-Score: 29
Archived-At: <https://mailarchive.ietf.org/arch/msg/nwcrg/1dCmkGkMN3g7jbdOk168JQ95cJY>
Subject: Re: [nwcrg] [irsg] IRSG ballot closed: <draft-irtf-nwcrg-nwc-ccn-reqs-08.txt> to Informational RFC
X-BeenThere: nwcrg@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IRTF Network Coding Research Group discussion list <nwcrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/nwcrg>, <mailto:nwcrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/nwcrg/>
List-Post: <mailto:nwcrg@irtf.org>
List-Help: <mailto:nwcrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/nwcrg>, <mailto:nwcrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Fri, 04 Mar 2022 23:48:51 -0000

Hi all,

Thank you for the update. This version looks to address the IRSG review comments, from Mirja, Allison, and Spencer. 

Chairs, if you could please confirm you’re okay with this moving forward, then I’ll send it to the IESG for conflict review.

Colin



> On 28 Feb 2022, at 16:53, Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> wrote:
> 
> Hi,  Kazuhisa,
> 
> Just top-posting to say that the updated draft version looks fine to me. Thanks to you and your co-authors for your quick response!
> 
> Best,
> 
> Spencer
> 
> On Sun, Feb 27, 2022 at 11:01 PM Kazuhisa Matsuzono <matsuzono@nict.go.jp <mailto:matsuzono@nict.go.jp>> wrote:
> Dear Colin, Mirja, Allison, Spencer, all,
> 
> Thank you so much for the useful comments and your help !
> We’ve addressed the comments and uploaded the new version.
> 
> > The IETF datatracker status page for this draft is:
> > https://datatracker.ietf.org/doc/draft-irtf-nwcrg-nwc-ccn-reqs/ <https://datatracker.ietf.org/doc/draft-irtf-nwcrg-nwc-ccn-reqs/>
> 
> Please see inline for more details.
> Many Thanks!
> 
> Best regards,
> Kazuhisa (on behalf of all authors)
> 
> 
> > ----------------------------------------------------------------------
> > COMMENT:
> > ----------------------------------------------------------------------
> >
> > One high level comment (which isn't anything that would prevent
> > publishing or
> > would actually need to be addressed before publishing): For me the
> > motivation
> > why NC is specifically beneficial for ICN is not clear. It rather
> > seems to me
> > that NC would be kind of equally beneficial to any other kind of network
> > interaction scheme. Section 6 even notes that a base principe in ICN
> > is that a
> > "forwarder or producer cannot initiatively inject unrequested data"
> > which seems
> > actually to make the application of NC (where N stands for network) quite
> > complicated. The approaches and consideration presented are fine and make
> > sense, I'm just saying the synergy of specifically combining these two
> > techniques is less clear to me.
> Thanks!
> We modified some sentences to address the specific relationship between
> ICN and NC, as follows:
> 
> NC allows for recovery of missing packets by encoding the information
> across several packets.  ICN is synergistic with NC, as it allows for
> caching of data packets throughout the network. In a typical network
> that uses NC, the sender must transmit enough packets to retrieve the
> original data.  ICN offers an opportunity to retrieve network coded
> packets directly from caches in the network and this makes the
> combination of ICN and NC particularly effective.  In fact, NC has
> already been implemented for information/content dissemination [6] [7]
> [8].  Montpetit, et al., first suggested that NC techniques be exploited
> to enhance key aspects of system performance in ICN [9]. Although
> CCNx/NDN excels to exploit the benefits of NC (as described in Section
> 5), some technical considerations are needed to combine NC and CCNx/NDN
> owing to the unique features of CCNx/NDN (as described in Section 6).
> 
> > One editorial point: For the ICN terminology you refer to RFC8793. For
> > NC you
> > have a rather lengthly list with terms which not necessarily are all used.
> > Wouldn't it make sense to similarly refer to RFC8406 instead?
> Thanks for the comment.
> As with the case of ICN terminology, we referred to RFC8406, and
> explicitly described that we referred RFC8406:
> "This section provides the terms related to NC used in this document,
> which are defined in RFC8406 [21] produced by NWCRG."
> And then, we listed the NC-related terms, as there are several confusing
> terms (e.g., source packet, repair packet, encoding, re-coding,
> generation, etc).
> In addition, as you pointed out, since there were some terms which were
> not used in main sections, we removed them from the lists.
> 
> > Nits:
> > - sec 7.2: "would be effective, an effective deployment approach" ->
> > "would be
> > an effective deployment approach"? - Maybe spell out CS on first
> > occurrence.
> Many thanks, we modified the relevant sentences  as follows:
> 1. "From this perspective, an effective deployment approach (e.g., a
> forwarder-supported approach that can provide benefits under partial
> deployment) is required."
> 2. "in the cache storage called Content Store (CS) (in Sec. 3)"
> 
> > ----------------------------------------------------------------------
> > COMMENT:
> > ----------------------------------------------------------------------
> >
> > I do have some questions for the authors to consider, but nothing
> > blocking that
> > I can see. Thanks for the opportunity to review this document.
> >
> > This is the kind of silly question one wonders about, but the top of
> > the first
> > page says
> >
> > Network Coding Research Group
> >
> > But the abstract says
> >
> > Abstract
> >
> > This document is
> > the product of the Coding for Efficient Network Communications
> > Research Group (NWCRG) and the Information-Centric Networking
> > Research Group (ICNRG).
> >
> > My understanding is that the Abstract is correct. Perhaps both
> > research groups
> > could be named at the top of the first page? In my limited experience,
> > that’s a
> > free-form field.
> Thank you for pointing it out.
> We added "ICNRG" at the top of the first page.
> (We already asked ICNRG-chairs whether there's any problem.)
> > In section 3, could you expand CS on first use?
> Thanks, we modified as follows: "in the cache storage called Content
> Store (CS) (in Sec. 3)"
> >
> > This text
> >
> > In the case of non-
> > coherent NC, that often comprises the use of Random Linear Coding
> > (RLC), it is not necessary to know the network topology nor the
> > intermediate coding operations [33].
> >
> > Didn’t parse well for me. Perhaps
> >
> > In the case of non-
> > coherent NC, which often uses Random Linear Coding
> > (RLC), it is not necessary to know the network topology nor the
> > intermediate coding operations [33].
> Many thanks, we changed as you pointed out.
> 
> 
> > I agree with Mirja’s first comment, that if there’s a reason why ICN
> > is special
> > and either benefits from NC differently or needs to be handled
> > differently,
> > explaining that would be great. I think Section 5 is getting at that,
> > but maybe
> > a forward pointer earlier in the document would be helpful.
> Thanks! As respond to the Mirja's comment, we updated considering the
> Mirja's and your comment.
> 
> > In addition, I’m looking at
> >
> > NC combines multiple packets together with parts of the same content,
> > and may do this at the source or at other nodes in the network.
> > Network coded packets are not associated with a specific server, as
> > they may have been combined within the network. As NC is focused on
> > what information should be encoded in a network packet instead of the
> > specific host at which it has been generated, it is in line with the
> > architecture of the CCNx/NDN core networking layer.
> >
> > And wondering if NC could happen at a source OR in other nodes in the
> > network,
> > what would happen if it happened at a source AND in other nodes in the
> > network.
> > Whether both would be OK, or not, it’s probably worth saying something
> > about
> > that.
> Thank you.
> Because both can be fine, we modified as follows: "content, and may do
> this at the source and/or at other nodes in the network."
> 
> > In Section 6.1,
> >
> > Naming content objects is as important for CCNx/NDN as naming hosts
> > is in the current-day Internet [24]. In this section, two possible
> > naming schemes are presented.
> >
> > I wasn’t sure which naming schemes are being presented (do they have
> > names?
> > References? Or are they being described in this document for the first
> > time?) I
> > THINK I can tell where one description ends and the other begins, but
> > if you
> > could put each in its own subsection (6.1.1 and 6.1.2), that would be
> > easier
> > for readers to navigate.
> Thanks for the comment!
> We split Sec 6.1 into two sub-sections: 6.1.1 Unique Naming for NC
> Packets, 6.1.2 Non-Unique Naming for NC Packets
> 
> > In Section 6.2,
> >
> > This means that forwarder or producer cannot
> > initiatively inject unrequested data.
> >
> > I had to check, but “initiatively” is a perfectly good English word
> > that I was
> > not familiar with. I’m understanding the text, the sentence might be
> > clearer as
> >
> > This means that a forwarder or producer cannot
> > ^
> > inject unrequested data packets on its own initiative.
> > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> >
> > Do the right thing, of course.
> Thanks, we modified it, because the sentence is clearer.
> 
> > In Section 6.2.1, I couldn’t parse this text, and I think I know why.
> >
> > On the other hand, if interest has a
> > partial name without any coding vector information or NC packets have
> > a same name,
> > ^^^^^^^^^^^
> >
> > Is this (I’m guessing)
> >
> > On the other hand, if interest has a
> > partial name without any coding vector information or multiple NC packets
> > ^^^^^^^^
> > have the same name,
> > ^^^
> > ?
> Thanks, we modified as pointed out.
> 
> > In 6.2.3,
> >
> > In another possible case, when receiving interests only for source
> > packets, the forwarder may attempt to decode and obtain all the
> > source packets and store them (if the full cache capacity are
> > available), thus enabling a faster response to the interests.
> >
> > I didn’t understand how this works. Is this enabling a faster response to
> > subsequent interests, which is what I would have guessed because of the
> > references to storing and to a cache), or to a single interest? And if
> > this is
> > obvious, I apologize to the authors.
> Many thanks!,
> As you pointed out, the phrase of “subsequent interests” is appropriate
> and much clearer. We modified the sentence.
> 
> > As an aside, 6.2.4 does an EXCELLENT job of saying
> >
> > There are multiple strategies,
> > Here is what the multiple strategies are, and
> > Here are the advantages and disadvantages of each strategy.
> >
> > This is the kind of presentation I was hoping for in my comment on 6.1
> > above.
> Thanks, this was actually done by Dave-san's lots of help.
> We hope that Sec. 6.1 becomes much clear.
> 
> > This text in Section 6.2.5 was hard for me to parse, and I think I
> > know why.
> >
> > NC operations should be applied in addition to the regular ICN
> > behavior. Hence, nodes should be able to not support network coding
> > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > (not only in forwarding the packets, but also in the caching
> > mechanism).
> >
> > Perhaps something like
> >
> > NC operations should be applied in addition to the regular ICN
> > behavior. Hence, nodes should should not perform network coding
> > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > (not only in forwarding the packets, but also in the caching
> > mechanism).
> >
> > Would be clearer? Or am I missing the point here?
> Thanks so much.
> To make it clearer, we modified as follows:
> NC operations should be applied in addition to the regular ICN behavior,
> and should function alongside regular ICN operations. Hence, nodes which
> do not support NC should still be able to properly handle packets, not
> only in being able to forward the NC packets, but also to cache these
> packets.
> 
> > In Section 7.2 (“Rate and Congestion Control”), I didn’t understand
> > how the
> > first sentence in this paragraph is connected to the second sentence
> > in the
> > same paragraph.
> >
> > As described in Section 6.4, NC can contribute to seamless consumer
> > mobility by obtaining innovative packets without receiving duplicated
> > packets through multipath data retrieval. It can be challenging to
> > develop an effective rate and congestion control mechanism in order
> > to achieve seamless consumer mobility while improving the overall
> > throughput or latency by fully exploiting NC operations.
> >
> > Maybe the reference to seamless consumer mobility is confusing me. Is it
> > correct to say
> >
> > As described in Section 6.4, NC can contribute to seamless consumer
> > mobility by obtaining innovative packets without receiving duplicated
> > packets through multipath data retrieval, and avoiding duplicated
> > ^^^^^^^^^^^^^^^^^^^^^^^
> > packets has congestion control benefits as well. It can be challenging to
> > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > develop an effective rate and congestion control mechanism in order
> > to achieve seamless consumer mobility while improving the overall
> > throughput or latency by fully exploiting NC operations.
> >
> > ?
> Many thanks!
> We modified as you pointed out.
> 
> 
> ----- Original Message -----
> > Thanks – and yes, that’s how the review process works.
> > Colin
> > 
> > 
> > 
> > > On 8 Feb 2022, at 18:07, Cedric Westphal <cedric.westphal@futurewei.com <mailto:cedric.westphal@futurewei.com>> wrote:
> > > 
> > > Hi,
> > >  
> > > Yes, we’ll need a minor update to address Spencer’s and Mirja’s comments. Hopefully we can get this done soon and run it by Spencer/Mirja and move forward. If there was a way for the update to not reset the review process, just have Spencer/Mirja/you check on it, that would be fantastic. 
> > > Thanks!
> > >  
> > > C. 
> > >  
> > > From: Colin Perkins <csp@csperkins.org <mailto:csp@csperkins.org>> 
> > > Sent: Tuesday, February 08, 2022 8:17 AM
> > > To: draft-irtf-nwcrg-nwc-ccn-reqs@ietf.org <mailto:draft-irtf-nwcrg-nwc-ccn-reqs@ietf.org>
> > > Cc: The IRSG <irsg@irtf.org <mailto:irsg@irtf.org>>; nwcrg@irtf.org <mailto:nwcrg@irtf.org>; nwcrg-chairs@ietf.org <mailto:nwcrg-chairs@ietf.org>
> > > Subject: Re: [irsg] IRSG ballot closed: <draft-irtf-nwcrg-nwc-ccn-reqs-08.txt> to Informational RFC
> > >  
> > > The IRSG ballot has closed on this draft, and it has enough positions to proceed towards publication. 
> > >  
> > > There are some non-blocking comments from Mirja and Spencer in the datatracker athttps://datatracker.ietf.org/doc/draft-irtf-nwcrg-nwc-ccn-reqs/ballot/irsg/ <http://datatracker.ietf.org/doc/draft-irtf-nwcrg-nwc-ccn-reqs/ballot/irsg/> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-irtf-nwcrg-nwc-ccn-reqs%2Fballot%2Firsg%2F&data=04%7C01%7Ccedric.westphal%40futurewei.com%7Cb3db1a81197144494bf708d9eb1e849d%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637799338586905103%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=u9uvWmyRlWpJuySv3VtpEJ6p95pYivnyFmhfxsGrMCg%3D&reserved=0 <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-irtf-nwcrg-nwc-ccn-reqs%2Fballot%2Firsg%2F&data=04%7C01%7Ccedric.westphal%40futurewei.com%7Cb3db1a81197144494bf708d9eb1e849d%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637799338586905103%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=u9uvWmyRlWpJuySv3VtpEJ6p95pYivnyFmhfxsGrMCg%3D&reserved=0>>. Authors/chairs can you please review and let me know if an update is needed to address any of these comments?
> > >  
> > > Thanks,
> > > Colin
> > >  
> > >  
> > >  
> > > 
> > > 
> > > On 8 Feb 2022, at 16:07, IESG Secretary <iesg-secretary@ietf.org <mailto:iesg-secretary@ietf.org> <mailto:iesg-secretary@ietf.org <mailto:iesg-secretary@ietf.org>>> wrote:
> > >  
> > > The IRSG ballot for <draft-irtf-nwcrg-nwc-ccn-reqs-08.txt> has been closed.
> > > The evaluation for this document can be found at
> > > https://datatracker.ietf.org/doc/draft-irtf-nwcrg-nwc-ccn-reqs/ <https://datatracker.ietf.org/doc/draft-irtf-nwcrg-nwc-ccn-reqs/> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-irtf-nwcrg-nwc-ccn-reqs%2F&data=04%7C01%7Ccedric.westphal%40futurewei.com%7Cb3db1a81197144494bf708d9eb1e849d%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637799338587061345%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=%2FVikS4x%2FSsiwmAjwvuh5mBAZdbPi2oUBgXbuUMXBv%2FM%3D&reserved=0 <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-irtf-nwcrg-nwc-ccn-reqs%2F&data=04%7C01%7Ccedric.westphal%40futurewei.com%7Cb3db1a81197144494bf708d9eb1e849d%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637799338587061345%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=%2FVikS4x%2FSsiwmAjwvuh5mBAZdbPi2oUBgXbuUMXBv%2FM%3D&reserved=0>>
> > >  
> > > 
> > > 
> > > -- 
> > > Colin Perkins
> > > https://csperkins.org/ <https://csperkins.org/> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcsperkins.org%2F&data=04%7C01%7Ccedric.westphal%40futurewei.com%7Cb3db1a81197144494bf708d9eb1e849d%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637799338587061345%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=QhDeCgRD9Ja4vpSrMjhUn7Lggt24sunFiFUxYDdmrvg%3D&reserved=0 <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcsperkins.org%2F&data=04%7C01%7Ccedric.westphal%40futurewei.com%7Cb3db1a81197144494bf708d9eb1e849d%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637799338587061345%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=QhDeCgRD9Ja4vpSrMjhUn7Lggt24sunFiFUxYDdmrvg%3D&reserved=0>>
> > 
> > 
> > -- 
> > Colin Perkins
> > https://csperkins.org/ <https://csperkins.org/>