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

Tengfei Chang <> Wed, 13 May 2020 09:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 640D73A0D5A; Wed, 13 May 2020 02:27:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id R2dfqzpnTdYQ; Wed, 13 May 2020 02:27:21 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id ED6D63A0D1C; Wed, 13 May 2020 02:27:19 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="5.73,387,1583190000"; d="jpg'145?scan'145,208,145,217";a="449467635"
X-MGA-submission: =?us-ascii?q?MDHgVG8tLO/tpIOqxPLQR6l1so1/uMtl9qOdzH?= =?us-ascii?q?wfhIFyzjnPJywUg50VBf1RVuckV0lG05RiX0LwId3X/Wp9dAhD2f4VMs?= =?us-ascii?q?CVu65U6kZxKBgKgoH/RuPrebsI1uziDUksVLhrUWsDJROMxusHGboOz9?= =?us-ascii?q?mDkYOorJPeCjbKtNWV5SOIJw=3D=3D?=
Received: from ([]) by with ESMTP; 13 May 2020 11:27:04 +0200
Date: Wed, 13 May 2020 11:27:04 +0200 (CEST)
From: Tengfei Chang <>
To: "Pascal Thubert, pthubert" <>
Cc: Benjamin Kaduk <>, tengfei chang <>, iesg <>, draft-ietf-6tisch-msf <>, 6tisch <>, 6tisch-chairs <>
Message-ID: <>
In-Reply-To: <>
References: <> <> <> <> <> <> <>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_78162367-2872-4524-9ef4-e6d8ef3a047a"
X-Originating-IP: []
X-Mailer: Zimbra 8.7.11_GA_3800 (ZimbraWebClient - GC81 (Win)/8.7.11_GA_3800)
Thread-Topic: Benjamin Kaduk's No Objection on draft-ietf-6tisch-msf-16: (with COMMENT)
Thread-Index: AQHWJ4ybnh6Qi3kpc0am7qSSZwMhPqii39AQ8SgemAmO2A4YUDT/wawQ/lqyXCA2Nu7T/g==
Archived-At: <>
Subject: Re: [6tisch] Benjamin Kaduk's No Objection on draft-ietf-6tisch-msf-16: (with COMMENT)
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" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 13 May 2020 09:27:27 -0000

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

Thanks a lot Pascal! 


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 ) 
(+33)1 80 49 41 43 

> From: "Pascal Thubert, pthubert" <>
> To: "Tengfei Chang" <>
> Cc: "Benjamin Kaduk" <>du>, "tengfei chang" <>om>,
> "iesg" <>rg>, "draft-ietf-6tisch-msf"
> <>rg>, "6tisch" <>rg>, "6tisch-chairs"
> <>
> 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 <> 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 )
>> (+33)1 80 49 41 43
>> ____________________
>> <inria.jpg>

>>> From: "Pascal Thubert, pthubert" <>
>>> To: "Tengfei Chang" <>fr>, "Benjamin Kaduk" <>
>>> Cc: "tengfei chang" <>om>, "iesg" <>rg>,
>>> "draft-ietf-6tisch-msf" <>rg>, "6tisch"
>>> <>rg>, "6tisch-chairs" <>
>>> 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

>>> [ [ | 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 <>
>>> Sent: lundi 11 mai 2020 17:00
>>> To: Pascal Thubert (pthubert) <>
>>> Cc: tengfei chang <>om>; Benjamin Kaduk <>du>;
>>> iesg <>rg>; draft-ietf-6tisch-msf <>rg>;
>>> 6tisch <>rg>; 6tisch-chairs <>
>>> 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 )

>>> (+33)1 80 49 41 43

>>> [ | ]

>>> [ | ]

>>> ____________________

>>> <image001.jpg>

>>>> From: "Pascal Thubert, pthubert" < [ |
>>>> ] >
>>>> To: "tengfei chang" < [ |
>>>> ] >, "Benjamin Kaduk" < [ | ] >
>>>> Cc: "iesg" < [ | ] >, "draft-ietf-6tisch-msf"
>>>> < [ | ] >,
>>>> "6tisch" < [ | ] >, "6tisch-chairs" < [
>>>> | ] >
>>>> 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 < [ |
>>>> ] >
>>>> Sent: lundi 11 mai 2020 14:06
>>>> To: Benjamin Kaduk < [ | ] >
>>>> Cc: The IESG < [ | ] >; [
>>>> | ] ;
>>>> 6tisch < [ | ] >; [
>>>> | ] ; Pascal Thubert
>>>> (pthubert) < [ | ] >
>>>> 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 < [
>>>> | ] > 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 [ |
>>>>> ]
>>>>> for more information about IESG DISCUSS and COMMENT positions.

>>>>> The document, along with other ballot positions, can be found here:
>>>>> [ |
>>>>> ]

>>>>> ----------------------------------------------------------------------
>>>>> 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 ( [ |
>>>>> ] ) 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

>>>>> 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
>>>>> [ | ]
>>>>> [ |
>>>>> ]
>>>> --

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

>>>> Stay healthy, stay optimistic!

>>>> Dr. Tengfei, Chang

>>>> Postdoctoral Research Engineer , Inria

>>>> [ | ]

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