Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8E301200E9; Fri, 11 Oct 2019 09:31:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k2Jut2CI_A3Q; Fri, 11 Oct 2019 09:31:38 -0700 (PDT) Received: from mail-pg1-x529.google.com (mail-pg1-x529.google.com [IPv6:2607:f8b0:4864:20::529]) (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 BF57012004E; Fri, 11 Oct 2019 09:31:38 -0700 (PDT) Received: by mail-pg1-x529.google.com with SMTP id i32so6078942pgl.10; Fri, 11 Oct 2019 09:31:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=r4WmEz2rx+EywcJj5vwOytzfsLVO4LMFzAVIaldVS94=; b=B3pN4Ai0uTCzkhS6rnJVlseap9m0LjGP4CzmC1MbzQCHm5579KE7Jt2RTETHec3OTg VvFiJhIpMM4LV3OBh41p7HgSkSoNNDTiUb/zdfKF6lMfYrs2ugJibCmhtAdjxs+k8u+O pC2zXsYSQ1LRx/QxRXRkUyzACDQtSbhTh7/LqssPu3xNjiMZUKMMTKBjbwPDaMeQ8wfu QjgFfxFojlnMlr+Zi1btTUvbAPbLTH/7nKNLsamLEDdfxKgsv6X8MdQN4gFI/6pDlEGf VBgHNEfP9LXnBi7UJJcMzQBJEiwg/x8kN9oE/8Nz9b/AEEBhFbTZ6gTacXGzNWHsu06p lYsA== 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=r4WmEz2rx+EywcJj5vwOytzfsLVO4LMFzAVIaldVS94=; b=gk2lSuVdXAzUm+DKJClljsUp6spslgITFOO0yfxnsqO40kUw9ptk6DBOQ/2Im86uiv so4sRIUlbJkts1HcKZDx1Q2ptFXlJFhuGFdYKxGfgknMY0Qj69w6Xt8hzl6enGNzXpeu icWPV50yiBxviitU6Q8CEsN+wGgAf93m3VFOMuGiKTfulEb6JzwT14KYJso3shVEgjSl qnt8NXQdEp2AhQy3Fp1vS738l4FHzugwaAdP5kFpOu+KYoxsU3Z/42H+q57Pj2nER6Lr /l5nstOCj1KXNhdNsLr9e0R46GU4enlRnBzGHNi8Sjz28B8dgNRFojiA/VaHdZngf9v2 1G1Q== X-Gm-Message-State: APjAAAUa6OprsoKwGmzNPWNVmHv+kPkMsVtjQMQSNAGmJyc5PLBOL1fb FBU3pADk7+1ym+nmGlshEo7qSfqGDct7obE0P2A= X-Google-Smtp-Source: APXvYqwGlRgicjuX4wrRVGT8nnTKrv9XcIjI8gCVLozpT9KDowN9Tq4PjFqIQjqAoqbMp5nXxeJM1ysxgVku+ByrzbA= X-Received: by 2002:a65:6702:: with SMTP id u2mr18590103pgf.426.1570811498007; Fri, 11 Oct 2019 09:31:38 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Tengfei Chang Date: Fri, 11 Oct 2019 18:31:27 +0200 Message-ID: To: Abdussalam Baryun Cc: Christian Hopfner , "draft-ietf-6tisch-msf@ietf.org" , "6tisch@ietf.org" <6tisch@ietf.org> Content-Type: multipart/alternative; boundary="0000000000005921690594a50dcd" Archived-At: Subject: Re: [6tisch] Clarification on MSF-06 X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Oct 2019 16:31:49 -0000 --0000000000005921690594a50dcd Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks Abdussalam for the comments, I updated the text as following: The node SHOULD send some form of keep-alive messages to all its neighbors it has negotiated cell with. The node sends a keep- alive message to the neighbor if no frames is received from that neighbor within a period, which is defined as KA_PERIOD. This mechanism is used to poll its children to ensure the child is still reachable. If the keep-alive message to a child fails at the link layer (i.e. the maximum number of link-layer retries is reached), the node SHOULD declare the child as unreachable. This can happen for example when the child node is switched off. When a neighbor is declared unreachable, the node MUST remove all negotiated cells with that neighbor from its own schedule. In addition, it MAY issue a 6P CLEAR to that neighbor (which can fail at the link-layer). The node MAY be removed from the neighbor table. Does this read good to you? Tengfei On Fri, Oct 11, 2019 at 5:06 PM Abdussalam Baryun < abdussalambaryun@gmail.com> wrote: > Hi Tengfei, > > I am interested like Christian to see the poll mechanism into this draft. > I don't think it is right to refer to RFC7554 (problem statement) which i= s > an informational RFC, while this draft is a proposed standard, I think it > is better to state the mechanism into the use case of minimum scheduling. > Furthermore, the RFC7554 does not mention once Keep-Alive message, but > mentions signalling messages, which may confuse users. > > Best regards > AB > > On Fri, Oct 11, 2019 at 3:41 PM Tengfei Chang > wrote: > >> Hi Christian, >> >> Thanks for pointing this issue out! >> The neighbor polling section is removed at 03 version. Can't remember wh= y >> we removed it. >> >> I re-edited this sections to fit the current content of MSF draft. I >> paste it below. It will the be last step of boot behavior after it start= s >> sending EB and DIO. >> >> The node SHOULD send some form of keep-alive messages to all its >> neighbors it has negotiated cell with. The Keep-Alive (KA) >> mechanism is detailed in [RFC7554 ]. It uses the keep-alive messages >> to its preferred parent to stay synchronized. It MAY use the keep- >> alive messages to other neighbors to have statistics on link quality. >> It MAY use the keep-alive messages to its children to ensure the >> child is still reachable. The RECOMMENDED period for sending keep- >> alive messages is KA_PERIOD. >> >> >> If the keep-alive message to a child fails at the link layer (i.e. >> the maximum number of link-layer retries is reached), the node SHOULD >> declare the child as unreachable. This can happen for example when >> the child node is switched off. >> >> When a neighbor is declared unreachable, the node MUST remove all >> negotiated cells with that neighbor from its own schedule. In >> addition, it MAY issue a 6P CLEAR to that neighbor (which can fail at >> the link-layer). The node MAY be removed from the neighbor table. >> >> >> If this is good for you, I will update the MSF to 07 with this change an= d >> propose WGLC right after. >> Thanks! >> >> Tengfei >> >> On Fri, Oct 11, 2019 at 1:09 PM Christian Hopfner < >> christian.hopfner@endress.com> wrote: >> >>> Hi authors, >>> >>> I may raise a clarification question before issuing WGLC for this draft= . >>> >>> In the past there was a section in the draft dealing with neighbor >>> polling which seems to me beeing an important topic in terms of schedul= e >>> consistency. >>> >>> In the latest version I don't see a mechanism which explains how a >>> parent keeps its schedule clean after some children silently disappeare= d >>> (e.g.. batteries are gone). As per my understanding in such a case the >>> negotiated RX cell towards the child remains in the schedule forever ri= ght? >>> >>> Previously this was handled by neighbor polling. Which required the >>> parent to send KA packets in a periodic manner to its childset. (This c= ould >>> be identified by evaluation of the neighbor set where a negotiated RX c= ell >>> was scheduled to) >>> >>> What is the idea now how to deal with that issue? >>> >>> >>> Mit freundlichen Gr=C3=BC=C3=9Fen I Best regards >>> >>> Christian Hopfner >>> ------------------------------ >>> Developer | TPI F&E Plattform Informatik >>> Endress+Hauser SE+Co. KG | Hauptstrasse 1 | 79689 Maulburg | Germany >>> Phone: +49 7622 28 1883 >>> christian.hopfner@endress.com | www.pcm.endress.com >>> >>> ------------------------------ >>> >>> Endress+Hauser SE+Co. KG >>> Registergericht: Amtsgericht Freiburg i.Br. HRA 670225 >>> Sitz der Gesellschaft: Maulburg >>> Pers=C3=B6nlich haftender Gesellschafter: Endress+Hauser Administration= SE >>> Sitz des pers=C3=B6nlich haftenden Gesellschafters: Maulburg >>> Registergericht: Amtsgericht Freiburg i.Br. HRB 717326 >>> Vorstand: Dr. Peter Selders >>> Aufsichtsratsvorsitzender: Matthias Altendorf >>> ------------------------------ >>> >>> Gem=C3=A4ss der Datenschutzgrundverordnung (EU-DSGVO) sind wir verpflic= htet, >>> Sie zu informieren, >>> wenn wir personenbezogene Daten von Ihnen erheben. >>> >>> Dieser Informationspflicht kommen wir mit folgendem Datenschutzhinweis >>> nach. >>> ------------------------------ >>> >>> Endress+Hauser SE+Co. KG >>> Register Court: Local Court of Freiburg i.Br. HRA 670225 >>> Registered Office: Maulburg >>> General Partner: Endress+Hauser Administration SE >>> Registered Office of General Partner: Maulburg >>> Register Court: Local Court of Freiburg i.Br. HRB 717326 >>> Chief Executive Officer: Dr. Peter Selders >>> Chairman of the Board: Matthias Altendorf >>> ------------------------------ >>> >>> According to the General Data Protection Regulation, >>> we are obliged to inform you when collecting your personal data. >>> We comply with this information duty with the following Data Protection >>> Statement >>> >>> ------------------------------ >>> >>> >>> >>> Disclaimer: >>> >>> The information transmitted is intended only for the person or entity t= o >>> which it is addressed and may contain confidential, proprietary, and/or >>> privileged >>> material. Any review, retransmission, dissemination or other use of, or >>> taking of any action in reliance upon, this information by persons or >>> entities >>> other than the intended recipient is prohibited. If you receive this in >>> error, please contact the sender and delete the material from any compu= ter. >>> This e-mail does not constitute a contract offer, a contract amendment, >>> or an acceptance of a contract offer unless explicitly and conspicuousl= y >>> designated or stated as such. >>> >>> >>> _______________________________________________ >>> 6tisch mailing list >>> 6tisch@ietf.org >>> https://www.ietf.org/mailman/listinfo/6tisch >>> >> >> >> -- >> =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94 >> >> Dr. Tengfei, Chang >> Postdoctoral Research Engineer, Inria >> >> www.tcahng.org >> =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94 >> _______________________________________________ >> 6tisch mailing list >> 6tisch@ietf.org >> https://www.ietf.org/mailman/listinfo/6tisch >> > --=20 =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94 Dr. Tengfei, Chang Postdoctoral Research Engineer, Inria www.tcahng.org =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94 --0000000000005921690594a50dcd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks=C2=A0Abdussalam for the comments, I updated the tex= t as following:=C2=A0

   The node SHOULD send some form of keep-alive messages to =
all its
   neighbors it has negotiated cell with. The node sends a keep-
   alive message to the neighbo=
r if no frames is received from that 
   neighbor within a period, which is defined as KA_PERIOD=
. This mechanism
   i=
s used to poll its children to ensure the child is still reachable.
<= pre style=3D"white-space:pre-wrap;font-size:13.3333px;margin-top:0px;margin= -bottom:0px;break-before:page;color:rgb(0,0,0)"> If the keep-alive messag= e to a child fails at the link layer (i.e. 
   the maximum number of link-layer retries is reach=
ed), the node 
   SHO=
ULD declare the child as unreachable. This can happen for example
when the child node is swi= tched off.

= 
   When a neighbor is decl=
ared unreachable, the node MUST remove all
   negotiated cells with that neighbor from its own schedule.  In
   addition, it MAY issue a 6P CLEAR to that neighbor (which can fail at
   the link-layer). The node MAY be removed from the neighbor table.
<= pre style=3D"white-space:pre-wrap;font-size:13.3333px;margin-top:0px;margin= -bottom:0px;break-before:page;color:rgb(0,0,0)">
Does this read go= od to you?

Tengfei



On Fri, Oct 11= , 2019 at 5:06 PM Abdussalam Baryun <abdussalambaryun@gmail.com> wrote:
Hi Tengfei,

I am interested like Christian to see the poll mechani= sm into this draft. I don't think it is right to refer to RFC7554 (prob= lem statement) which is an informational RFC, while this draft is a propose= d standard, I think it is better to state the mechanism into the use case o= f minimum scheduling. Furthermore, the RFC7554 does not mention once Keep-A= live message,=C2=A0but mentions signalling messages, which may confuse user= s.

Best regards
AB

On Fri, Oct = 11, 2019 at 3:41 PM Tengfei Chang <tengfei.chang@gmail.com> wrote:
Hi Christia= n,

Thanks for pointing this issue out!=C2=A0
<= div>The neighbor polling section is removed at 03 version. Can't rememb= er why we removed it.

I re-edited this sections to= fit the current content of MSF draft. I paste it below. It will the be las= t step of boot behavior after it starts sending EB and DIO.

   The node SHOULD send some form of keep-alive message=
s to all its
   neighbors it has negotiated cell with.  The Keep-Alive (KA)
   mechanism is detailed in [=
RFC7554].  It uses the keep-alive messages
   to its preferred parent to stay synchronized.  It MAY use the keep-
   alive messages to other neighbors to have statistics on link quality.
   It MAY use the keep-alive messages to its children to ensure the
   child is still reachable.  The RECOMMENDED period for sending keep-
   alive messages is KA_PERIOD.


   If t=
he keep-alive message to a child fails at the link layer (i.e.
   the maximum number of link-layer retries is reached), the node SHOULD
   declare the child as unreachable.  This can happen for example when
   the child node is switched off.

   When a neighbor is declared unreachable, the node MUST remove all
   negotiated cells with that neighbor from its own schedule.  In
   addition, it MAY issue a 6P CLEAR to that neighbor (which can fail at
   the link-layer). The node MAY be removed from the neighbor table.

If this is good for you, I will upda=
te the MSF to 07 with this change and propose WGLC right after.=C2=A0
=
Thanks!

Tengfei

On Fri, Oct 11, 2019 at 1:09 PM Christian = Hopfner <christian.hopfner@endress.com> wrote:
Hi authors,

I may raise a clarification question before issuing WGLC for this draft.

In the past there was a section in the draft dealing with neighbor polling = which seems to me beeing an important topic in terms of schedule consistenc= y.

In the latest version I don't see a mechanism which explains how a pare= nt keeps its schedule clean after some children silently disappeared (e.g..= batteries are gone). As per my understanding in such a case the negotiated= RX cell towards the child remains in the schedule forever right?

Previously this was handled by neighbor polling. Which required the parent = to send KA packets in a periodic manner to its childset. (This could be ide= ntified by evaluation of the neighbor set where a negotiated RX cell was sc= heduled to)

What is the idea now how to deal with that issue?

Mit freundlichen Gr=C3=BC=C3=9Fen I Best regards

Ch= ristian Hopfner

Devel= oper | TPI F&E Plattform Informatik
Endress+Hauser SE+Co. KG | Haupt= strasse 1 | 79689 Maulburg | Germany
Phone: +49 7622 28 1883
christian.hopfn= er@endress.com | www.pcm.endress.com

En= dress+Hauser SE+Co. KG
Registergericht: Amtsgericht Freiburg i.Br. HRA= 670225
Sitz der Gesellschaft: Maulburg
Pers=C3=B6nlich haftender= Gesellschafter: Endress+Hauser Administration SE
Sitz des pers=C3=B6n= lich haftenden Gesellschafters: Maulburg
Registergericht: Amtsgericht = Freiburg i.Br. HRB 717326
Vorstand:=C2=A0Dr. Peter Selders
<= span style=3D"font-family:arial,helvetica,sans-serif;font-size:10pt">Aufsic= htsratsvorsitzender: Matthias Altendorf

Ge= m=C3=A4ss der Datenschutzgrundverordnung (EU-DSGVO) sind wir verpflichtet, = Sie zu informieren,
wenn wir personenbezogene Daten von Ihnen erheben.=

Di= eser Informationspflicht kommen wir mit folgendem Datenschutzhinweis nach.

En= dress+Hauser SE+Co. KG
Register Court: Local Court of Freiburg i.Br. H= RA 670225
Registered Office: Maulburg
General Partner: Endress+Ha= user Administration SE
Registered Office of General Partner: Maulburg<= /span>
Register Court: Local Court of Freiburg i.Br. HRB 717326
Chief Executive Officer: Dr. Peter Selders
Chairman of the Boar= d: Matthias Altendorf

Ac= cording to the General Data Protection Regulation,
we are obliged to i= nform you when collecting your personal data.
We comply with this info= rmation duty with the following Data Protection Stat= ement

=C2=A0

Disclaimer= :

The information transmi= tted is intended only for the person or entity to which it is addressed and= may contain confidential, proprietary, and/or privileged
material. Any = review, retransmission, dissemination or other use of, or taking of any act= ion in reliance upon, this information by persons or entities
other than= the intended recipient is prohibited. If you receive this in error, please= contact the sender and delete the material from any computer.
This e-ma= il does not constitute a contract offer, a contract amendment, or an accept= ance of a contract offer unless explicitly and conspicuously designated or = stated as such.

=C2=A0

_______________________________________________
6tisch mailing list
6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch


--
=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94

Dr. Tengfei, Chang
Postdoctoral Research Engineer, Inria

=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94
<= /div>
_______________________________________________
6tisch mailing list
6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch


--
=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94

Dr. Tengfei, Chang
<= span style=3D"background-color:rgb(255,255,255)">Postdoctoral Research Engi= neer, Inria
=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=
--0000000000005921690594a50dcd--