Re: [6tisch] Benjamin Kaduk's No Objection on draft-ietf-6tisch-msf-16: (with COMMENT)

[Tengfei Chang <[e-mail]>]

Alright, then I will keep the version 17 unpublished, until it's needed. 

Thanks a lot Pascal! 

Tengfei 

Stay Healthy! Stay Optimistic! 

Dr. Tengfei Chang 
Post-doctoral Researcher 
Wireless Networking for Evolving & Adaptive Applications (EVA) 
National Inst. for Research in Comp. Sci. and Automation ( Inria ) 
([phone] 
[e-mail] 
www.tchang.org 
____________________ 

> From: "Pascal Thubert, pthubert" <[e-mail]>
> To: "Tengfei Chang" <[e-mail]>
> Cc: "Benjamin Kaduk" <[e-mail]>, "tengfei chang" <[e-mail]>,
> "iesg" <[e-mail]>, "draft-ietf-6tisch-msf"
> <[e-mail]>, "6tisch" <[e-mail]>, "6tisch-chairs"
> <[e-mail]>
> Sent: Wednesday, May 13, 2020 11:08:03 AM
> Subject: Re: [6tisch] Benjamin Kaduk's No Objection on draft-ietf-6tisch-msf-16:
> (with COMMENT)

> Oh that’s cool then we can keep a note for the rfc editor no need for
> republishing

> I’ll ping Alvaro see if the doc can be queued now.

> Take care,

> Pascal

>> Le 13 mai 2020 à 11:03, Tengfei Chang <[e-mail]> a écrit :

>> Hi Pascal,

>> It turns out I missed read Benjamin's suggestion:

>> Benjiamin suggested:

>> I suggest '''one routing parent; this parent is referred to as the
>> "selected parent"'''.

>> I miss read it as the suggestion is to replace "one routing parent" by "the
>> selected parent", which I changed it to the "selected routing parent".
>> Will correct it and publish a new version.

>> Thanks for the catching!
>> Tengfei

>> Stay Healthy! Stay Optimistic!

>> Dr. Tengfei Chang
>> Post-doctoral Researcher
>> Wireless Networking for Evolving & Adaptive Applications (EVA)
>> National Inst. for Research in Comp. Sci. and Automation ( Inria )
>> ([phone]
>> [e-mail]
>> www.tchang.org
>> ____________________
>> <inria.jpg>

>>> From: "Pascal Thubert, pthubert" <[e-mail]>
>>> To: "Tengfei Chang" <[e-mail]>, "Benjamin Kaduk" <[e-mail]>
>>> Cc: "tengfei chang" <[e-mail]>, "iesg" <[e-mail]>,
>>> "draft-ietf-6tisch-msf" <[e-mail]>, "6tisch"
>>> <[e-mail]>, "6tisch-chairs" <[e-mail]>
>>> Sent: Monday, May 11, 2020 6:08:50 PM
>>> Subject: RE: [6tisch] Benjamin Kaduk's No Objection on draft-ietf-6tisch-msf-16:
>>> (with COMMENT)

>>> Hello Benjamin and Tengfei;

>>> What I did is pick one randomly, and picked this;

>>> “

>>> MSF works closely with RPL, specifically the routing parent defined
>>> in [RFC6550]. This specification only describes how MSF works with
>>> one routing parent, which is phrased as "selected parent". The

>>> nit: I suggest '''one routing parent; this parent is referred to as the
>>> "selected parent"'''.

>>> “

>>> Then I looked at 16 and the text is still

>>> MSF works closely with the IPv6 Routing Protocol for Low-Power and

>>> Lossy Networks (RPL), specifically the routing parent defined in

>>> [ [ https://tools.ietf.org/html/rfc6550 | RFC6550 ] ]. This specification only
>>> describes how MSF works with the

>>> selected routing parent, which is phrased as "selected parent". The

>>> activity of MSF towards the single routing parent is called a "MSF

>>> session". Though the performance of MSF is evaluated only when the

>>> "selected parent" represents the node's preferred parent, there

>>> This tells me that the handling of Benjamin’s review is not complete, so I asked
>>> Tengfei to double check.

>>> Take care;

>>> Pascal

>>> From: Tengfei Chang <[e-mail]>
>>> Sent: lundi 11 mai 2020 17:00
>>> To: Pascal Thubert (pthubert) <[e-mail]>
>>> Cc: tengfei chang <[e-mail]>; Benjamin Kaduk <[e-mail]>;
>>> iesg <[e-mail]>; draft-ietf-6tisch-msf <[e-mail]>;
>>> 6tisch <[e-mail]>; 6tisch-chairs <[e-mail]>
>>> Subject: Re: [6tisch] Benjamin Kaduk's No Objection on draft-ietf-6tisch-msf-16:
>>> (with COMMENT)

>>> Hi Pascal,

>>> If comparing the comments to draft-ietf-6tisch-msf-12 from another thread
>>> previously, you will find out they are actually the same.

>>> Those comments are indeed fixed with the MSF versions after 12, including
>>> draft-ietf-6tisch-msf-16 .

>>> Regards,

>>> Tengfei

>>> Stay Healthy! Stay Optimistic!

>>> Dr. Tengfei Chang

>>> Post-doctoral Researcher

>>> Wireless Networking for Evolving & Adaptive Applications (EVA)

>>> National Inst. for Research in Comp. Sci. and Automation ( Inria )

>>> ([phone]

>>> [ mailto:[e-mail] | [e-mail] ]

>>> [ http://www.tchang.org/ | www.tchang.org ]

>>> ____________________

>>> <image001.jpg>

>>>> From: "Pascal Thubert, pthubert" < [ mailto:[e-mail] |
>>>> [e-mail] ] >
>>>> To: "tengfei chang" < [ mailto:[e-mail] | [e-mail]
>>>> ] >, "Benjamin Kaduk" < [ mailto:[e-mail] | [e-mail] ] >
>>>> Cc: "iesg" < [ mailto:[e-mail] | [e-mail] ] >, "draft-ietf-6tisch-msf"
>>>> < [ mailto:[e-mail] | [e-mail] ] >,
>>>> "6tisch" < [ mailto:[e-mail] | [e-mail] ] >, "6tisch-chairs" < [
>>>> mailto:[e-mail] | [e-mail] ] >
>>>> Sent: Monday, May 11, 2020 4:23:12 PM
>>>> Subject: RE: [6tisch] Benjamin Kaduk's No Objection on draft-ietf-6tisch-msf-16:
>>>> (with COMMENT)
>>>> Hello Tengfei

>>>> My reading is that the comments below apply to version 16 as the title
>>>> indicates.

>>>> I randomly checked the proposed nit fixes and the issues are effectively still
>>>> left to be fixed.

>>>> Can you please have a look?

>>>> Take care,

>>>> Pascal

>>>> From: Tengfei Chang < [ mailto:[e-mail] | [e-mail]
>>>> ] >
>>>> Sent: lundi 11 mai 2020 14:06
>>>> To: Benjamin Kaduk < [ mailto:[e-mail] | [e-mail] ] >
>>>> Cc: The IESG < [ mailto:[e-mail] | [e-mail] ] >; [
>>>> mailto:[e-mail] | [e-mail] ] ;
>>>> 6tisch < [ mailto:[e-mail] | [e-mail] ] >; [
>>>> mailto:[e-mail] | [e-mail] ] ; Pascal Thubert
>>>> (pthubert) < [ mailto:[e-mail] | [e-mail] ] >
>>>> Subject: Re: [6tisch] Benjamin Kaduk's No Objection on draft-ietf-6tisch-msf-16:
>>>> (with COMMENT)

>>>> Hi Benjamin,

>>>> Thanks for updating the comments!

>>>> I believe the change from the current email comparing to previous one is that
>>>> the DISCUSSION part is removed as we fixed it in another previous thread.

>>>> The other comments from the current email are actually for old version of MSF,
>>>> which are all resolved in the latest version MSF-16.

>>>> For the administration,

>>>> I want to clarify that the draft-ietf-6tisch-msf-16 has resolved all comments
>>>> which were discussed.

>>>> Please advise me if there is any further action required. Thanks a lot!

>>>> Regards,

>>>> Tengfei

>>>> On Fri, Apr 3, 2020 at 5:38 AM Benjamin Kaduk via Datatracker < [
>>>> mailto:[e-mail] | [e-mail] ] > wrote:

>>>>> Benjamin Kaduk has entered the following ballot position for
>>>>> draft-ietf-6tisch-msf-16: No Objection

>>>>> When responding, please keep the subject line intact and reply to all
>>>>> email addresses included in the To and CC lines. (Feel free to cut this
>>>>> introductory paragraph, however.)

>>>>> Please refer to [ https://www.ietf.org/iesg/statement/discuss-criteria.html |
>>>>> https://www.ietf.org/iesg/statement/discuss-criteria.html ]
>>>>> for more information about IESG DISCUSS and COMMENT positions.

>>>>> The document, along with other ballot positions, can be found here:
>>>>> [ https://datatracker.ietf.org/doc/draft-ietf-6tisch-msf/ |
>>>>> https://datatracker.ietf.org/doc/draft-ietf-6tisch-msf/ ]

>>>>> ----------------------------------------------------------------------
>>>>> COMMENT:
>>>>> ----------------------------------------------------------------------

>>>>> Thanks for clarifying the non-issue nature of my original Discuss points!

>>>>> Original COMMENT section preserved below (possibly stale).

>>>>> I support Roman's Discuss -- we need more information for this to be a
>>>>> useful reference; even what seem to be the official DASFAA 1997
>>>>> proceedings ( [ https://dblp.org/db/conf/dasfaa/dasfaa97 |
>>>>> https://dblp.org/db/conf/dasfaa/dasfaa97 ] ) do not have an
>>>>> associated document).

>>>>> Basing various scheduling aspects on (a hash of) the EUI64 ties
>>>>> functionality to a persistent identifier for a device. How significant
>>>>> a disruption would be incurred if a device periodically changes its
>>>>> presented EUI64 for anonymization purposes?

>>>>> There seems to be a general pattern of "if you don't have a
>>>>> 6P-negotiated Tx cell, install and AutoTxCell to send your one message
>>>>> and then remove it after sending"; I wonder if it would be easier on the
>>>>> reader to consolidate this as a general principle and not repeat the
>>>>> details every time it occurs.

>>>>> Requirements Language

>>>>> "NOT RECOMMENDED" is not in the RFC2119 boilerplate (but is a BCP 14 keyword).

>>>>> Section 1

>>>>> the 6 steps described in Section 4. The end state of the join
>>>>> process is that the node is synchronized to the network, has mutually
>>>>> authenticated to the network, has identified a routing parent, and

>>>>> nit(?): I guess maybe "mutually authenticated with" is more correct for
>>>>> the bidirectional operation.

>>>>> It does so for 3 reasons: to match the link-layer resources to the
>>>>> traffic, to handle changing parent, to handle a schedule collision.

>>>>> nit: end the list with "or" (or "and"?).

>>>>> MSF works closely with RPL, specifically the routing parent defined
>>>>> in [RFC6550]. This specification only describes how MSF works with
>>>>> one routing parent, which is phrased as "selected parent". The

>>>>> nit: I suggest '''one routing parent; this parent is referred to as the
>>>>> "selected parent"'''.

>>>>> activity of MSF towards to single routing parent is called as a "MSF

>>>>> nit: "towards the"

>>>>> * We added sections on the interface to the minimal 6TiSCH
>>>>> configuration (Section 2), the use of the SIGNAL command
>>>>> (Section 6), the MSF constants (Section 14), the MSF statistics
>>>>> (Section 15).

>>>>> nit: end the list with "and".

>>>>> Section 2

>>>>> In a TSCH network, time is sliced up into time slots. The time slots
>>>>> are grouped as one of more slotframes which repeat over time. The

>>>>> nit(?): should this be "one or more"?

>>>>> channel) is indicated as a cell of TSCH schedule. MSF is one of the
>>>>> policies defining how to manage the TSCH schedule.

>>>>> nit: if there is only one such policy active at a given time for a given
>>>>> network, I suggest "MSF is a policy for managing the TCSH schedule".
>>>>> (If multiple policies are active simultaneously, no change is needed.)

>>>>> MSF uses the minimal cell for broadcast frames such as Enhanced
>>>>> Beacons (EBs) [IEEE802154] and broadcast DODAG Information Objects
>>>>> (DIOs) [RFC6550]. Cells scheduled by MSF are meant to be used only
>>>>> for unicast frames.

>>>>> If this paragraph was moved before the previous paragraph, then EB and
>>>>> DIO would be defined before their first usage.

>>>>> bandwidth of minimal cell. One of the algorithm met the rule is the
>>>>> Trickle timer defined in [RFC6206] which is applied on DIO messages
>>>>> [RFC6550]. However, any such algorithm of limiting the broadcast

>>>>> nit(?): "One of the algorithms that fulfills this requirement"?

>>>>> MSF RECOMMENDS the use of 3 slotframes. MSF schedules autonomous
>>>>> cells at Slotframe 1 (Section 3) and 6P negotiated cells at Slotframe
>>>>> 2 (Section 5) , while Slotframe 0 is used for the bootstrap traffic
>>>>> as defined in the Minimal 6TiSCH Configuration. It is RECOMMENDED to
>>>>> use the same slotframe length for Slotframe 0, 1 and 2. Thus it is

>>>>> Perhaps this is just a question of writing style, but if an
>>>>> implementation is free to use an alternative SF or a variant of MSF,
>>>>> could we not say that "MSF uses 3 slotframts", "MSF uses the same
>>>>> slotframe length for", etc.?

>>>>> Section 3

>>>>> Is there any risk of unwanted correlation between slot and channel
>>>>> offsets when using the same hash function and input for both
>>>>> calculations?

>>>>> hash function. Other optional parameters defined in SAX determine
>>>>> the performance of SAX hash function. Those parameters could be
>>>>> broadcasted in EB frame or pre-configured. For interoperability
>>>>> purposes, an example how the hash function is implemented is detailed
>>>>> in Appendix B.

>>>>> Given the lack of usable reference for [SAX-DASFAA], I assume that the
>>>>> content in Appendix B is going to be used as a specification, not just
>>>>> an example.

>>>>> * The AutoRxCell MUST always remain scheduled after synchronized.

>>>>> nit: s/synchronized/synchronization/

>>>>> AutoRxCell. In case of conflicting with a negotiated cell,
>>>>> autonomous cells take precedence over negotiated cell, which is
>>>>> stated in [IEEE802154]. However, when the Slotframe 0, 1 and 2 use
>>>>> the same length value, it is possible for negotiated cell to avoid
>>>>> the collision with AutoRxCell.

>>>>> Presumably this factors in to the recommendation to have the three
>>>>> listed slotframes use the same length, but mentioning it explicitly
>>>>> (whether here or where the recommendation is made) might be nice.

>>>>> Section 4

>>>>> network. Alternative behaviors may involved, for example, when
>>>>> alternative security solution is used for the network. Section 4.1

>>>>> nit: singular/plural mismatch "behaviors"/"solution is used"

>>>>> Section 4.1

>>>>> A node implementing MSF SHOULD implement the Minimal Security
>>>>> Framework for 6TiSCH [I-D.ietf-6tisch-minimal-security]. As a

>>>>> Didn't this get renamed to CoJP?

>>>>> Section 4.2

>>>>> I a little bit wonder if there is a better description than "available
>>>>> frequencies" but don't have one to offer.

>>>>> Section 4.3

>>>>> While the exact behavior is implementation-specific, it is
>>>>> RECOMMENDED that after having received the first EB, a node keeps
>>>>> listen for at most MAX_EB_DELAY seconds until it has received EBs
>>>>> from NUM_NEIGHBOURS_TO_WAIT distinct neighbors, which is defined in
>>>>> [RFC8180].

>>>>> nit(?): this phrasing implies that only NUM_NEIGHBOURS_TO_WAIT is
>>>>> defined in RFC 8180, but MAX_EB_DELAY is also defined there.

>>>>> not-nit: this phrasing is ambiguous as to whether one of MAX_EB_DELAY
>>>>> and NUM_NEIGHBOURS_TO_WAIT is sufficient to move to the next step or
>>>>> whether both are required.

>>>>> Section 4.4

>>>>> After selected a JP, a node generates a Join Request and installs an
>>>>> AutoTxCell to the JP. The Join Request is then sent by the pledge to
>>>>> its JP over the AutoTxCell. The AutoTxCell is removed by the pledge

>>>>> editorial: I'd suggest s/its JP/its selected JP/

>>>>> Response is sent out. The pledge receives the Join Response from its
>>>>> AutoRxCell, thereby learns the keying material used in the network,
>>>>> as well as other configurations, and becomes a "joined node".

>>>>> nit: maybe "other configuration values" or "other configuration
>>>>> settings"?

>>>>> Section 4.6

>>>>> Once it has selected a routing parent, the joined node MUST generate
>>>>> a 6P ADD Request and install an AutoTxCell to that parent. The 6P
>>>>> ADD Request is sent out through the AutoTxCell with the following
>>>>> fields:

>>>>> * CellOptions: set to TX=1,RX=0,SHARED=0
>>>>> * NumCells: set to 1
>>>>> * CellList: at least 5 cells, chosen according to Section 8

>>>>> Is this listing describing the contents of the ADD request or the
>>>>> AuthTxCell used to send it? (I presume the former, in which case I
>>>>> suggest to use "containing" or similar in preference to "with".)

>>>>> Section 5.1

>>>>> The goal of MSF is to manage the communication schedule in the 6TiSCH
>>>>> schedule in a distributed manner. For a node, this translates into
>>>>> monitoring the current usage of the cells it has to the selected
>>>>> parent:

>>>>> Is this goal strictly limited to traffic "to the selected parent" vs.
>>>>> all traffic?

>>>>> * If the node determines that the number of link-layer frames it is
>>>>> attempting to exchange with the selected parent per unit of time
>>>>> is larger than the capacity offered by the TSCH negotiated cells
>>>>> it has scheduled with it, the node issues a 6P ADD command to that
>>>>> parent to add cells to the TSCH schedule.
>>>>> * If the traffic is lower than the capacity, the node issues a 6P
>>>>> DELETE command to that parent to delete cells from the TSCH
>>>>> schedule.

>>>>> As written, this would potentially lead to oscillation when demand is
>>>>> basically at capacity, due to the quantization of capacity. Perhaps
>>>>> some provisioning for hysteresis is appropriate?

>>>>> The cell option of cells listed in CellList in 6P Request frame
>>>>> SHOULD be either Tx=1 only or Rx=1 only. Both NumCellsElapsed and
>>>>> NumCellsUsed counters can be used to both type of negotiated cells.

>>>>> Would this be more clear as "(Tx=1,Rx=0) or (Tx=0,Rx=1)"?

>>>>> * NumCellsElapsed is incremented by exactly 1 when the current cell
>>>>> is AutoRxCell.

>>>>> This holds for all peers/parents we're keeping counters for, so the
>>>>> AutoRxCell can get "double counted"?

>>>>> In case that a node booted or disappeared from the network, the cell
>>>>> reserved at the selected parent may be kept in the schedule forever.
>>>>> A clean-up mechanism MUST be provided to resolve this issue. The
>>>>> clean-up mechanism is implementation-specific. It could either be a
>>>>> periodic polling to the neighbors the nodes have negotiated cells
>>>>> with, or monitoring the activities on those cells. The goal is to
>>>>> confirm those negotiated cells are not used anymore by the associated
>>>>> neighbors and remove them from the schedule.

>>>>> I'm not sure that "monitoring the activities on those cells" is safe
>>>>> with the current level of specification; if a node negotiates a 6P
>>>>> transmit cell to a parent and uses it only sparingly, with the parent
>>>>> eventually reclaiming it due to inactivity, I don't see a mechanism by
>>>>> which the node will reliably discover the negotiated cell to be
>>>>> nonfunctional and fall back to (e.g.) the corresponding AutoTxCell. It
>>>>> may be most prudent to just not mention that as an example (a "periodic
>>>>> polling" procedure does not seem to have the same potential for
>>>>> information skew)

>>>>> Section 5.3

>>>>> schedule is executed and the node sends frames to that parent. When
>>>>> NumTx reaches MAX_NUMTX, both NumTx and NumTxAck MUST be divided by
>>>>> 2. For example, when MAX_NUMTX is set to 256, from NumTx=255 and
>>>>> NumTxAck=127, the counters become NumTx=128 and NumTxAck=64 if one
>>>>> frame is sent to the parent with an Acknowledgment received. This
>>>>> operation does not change the value of the PDR, but allows the
>>>>> counters to keep incrementing. The value of MAX_NUMTX is
>>>>> implementation-specific.

>>>>> Does MAX_NUMTX need to be a power of two (to avoid errors when the
>>>>> division occurs)?

>>>>> 4. For any other cell, it compares its PDR against that of the cell
>>>>> with the highest PDR. If the difference is larger than
>>>>> RELOCATE_PDRTHRES, it triggers the relocation of that cell using
>>>>> a 6P RELOCATE command.

>>>>> The recommended RELOCATE_PDRTHRES is given as "50 %". Is this
>>>>> "difference" performed as a subtraction (so that if the highest PDR is
>>>>> less than 50%, no cells can ever be relocated) or a ratio (a PDR that's
>>>>> half than the maximum PDR or smaller will trigger relocation)?

>>>>> Section 7

>>>>> Maybe reference Section 17.1 where the allocation will occur?

>>>>> Section 8

>>>>> * The slotOffset of a cell in the CellList SHOULD be randomly and
>>>>> uniformly chosen among all the slotOffset values that satisfy the
>>>>> restrictions above.
>>>>> * The channelOffset of a cell in the CellList SHOULD be randomly and
>>>>> uniformly chosen in [0..numFrequencies], where numFrequencies
>>>>> represents the number of frequencies a node can communicate on.

>>>>> Do these random selections need to be independent from each other? (I
>>>>> note that the selection for the autonomous cells are not.)

>>>>> Section 9

>>>>> Is there a reference for these three parameters (MAXBE, MAXRETRIES,
>>>>> SLOTFRAME_LENGTH)? SLOTFRAME_LENGTH seems new in this document and is
>>>>> listed in the table in Section 14, but the other two are not listed
>>>>> there.

>>>>> Section 14

>>>>> Why is MAX_NUMTX not listed in the table?

>>>>> Can we really give a recommended NUM_CH_OFFSET value, since this is in
>>>>> effect dependent on the number of channels available?

>>>>> KA_PERIOD is defined but not used elsewhere in the document.

>>>>> What are the considerations in using a power of 10 vs. a power of 2 as
>>>>> MAX_NUM_CELLS?

>>>>> Section 16

>>>>> MSF defines a series of "rules" for the node to follow. It triggers
>>>>> several actions, that are carried out by the protocols defined in the
>>>>> following specifications: the Minimal IPv6 over the TSCH Mode of IEEE
>>>>> 802.15.4e (6TiSCH) Configuration [RFC8180], the 6TiSCH Operation

>>>>> I'd suggest a brief note that the security considerations of those
>>>>> protocols continue to apply (even though it ought to be obvious);
>>>>> reading them could help a reader understand the behavior of this
>>>>> document as well.

>>>>> Sublayer Protocol (6P) [RFC8480], and the Minimal Security Framework
>>>>> for 6TiSCH [I-D.ietf-6tisch-minimal-security]. In particular, MSF

>>>>> [CoJP again]

>>>>> prevent it from receiving the join response. This situation should
>>>>> be detected through the absence of a particular node from the network
>>>>> and handled by the network administrator through out-of-band means,
>>>>> e.g. by moving the node outside the radio range of the attacker.

>>>>> "the radio range of the attacker" is not exactly a fixed constant ...
>>>>> attackers are not in general bound by legal limits and can increase Tx
>>>>> power subject only to their equipment and budget.

>>>>> MSF adapts to traffics containing packets from IP layer. It is
>>>>> possible that the IP packet has a non-zero DSCP (Diffserv Code Point
>>>>> [RFC2597]) value in its IPv6 header. The decision whether to hand

>>>>> RFC 2597 is talking more about specifically assured forwarding PHB groups
>>>>> than "DSCP codepoint"s per se.

>>>>> Section 18.1

>>>>> RFC 6206 seems to only be used as an example (Trickle), and could
>>>>> probably be informative.

>>>>> RFC 8505 might also not need to be normative.

>>>>> Appendix B

>>>>> In MSF, the T is replaced by the length slotframe 1. String s is

>>>>> nit: "length of"

>>>>> 2. sum the value of L_shift(h,l_bit), R_shift(h,r_bit) and ci

>>>>> Is this addition performed in "infinite precision" integer arithmetic or
>>>>> limited to the output width of h, e.g., by modular division? (It's not
>>>>> clear to me whether this is the role T plays or not.)

>>>>> 8. assign the result of Step 5 to h

>>>>> The value from step 5 *is* h, so taken literally this says "assign h to
>>>>> h" and is not needed.

>>>>> _______________________________________________
>>>>> 6tisch mailing list
>>>>> [ mailto:[e-mail] | [e-mail] ]
>>>>> [ https://www.ietf.org/mailman/listinfo/6tisch |
>>>>> https://www.ietf.org/mailman/listinfo/6tisch ]
>>>> --

>>>> ——————————————————————————————————————

>>>> Stay healthy, stay optimistic!

>>>> Dr. Tengfei, Chang

>>>> Postdoctoral Research Engineer , Inria

>>>> [ http://www.tchang.org/ | www.tchang.org/ ]

>>>> ——————————————————————————————————————