Dear Linda,

After a second look, I noticed that the ASN acronym only had a couple of 
occurrences in the text. To address your comment, I replaced the occurrences of 
“ASN" with the expanded version “absolute slot number” without defining the 
acronym in our document. The changes following your review can be found at:

Please let me know whether I should go ahead and upload the new version to the 


> On 10 Oct 2019, at 18:42, Linda Dunbar <> wrote:
> Malisa, 
> Thanks for the changes. 
> I didn't realize that IEEE802.15 uses ASN for completely different purpose 
> than the IETF's ASN. Maybe add a note stating "this ASN is completely 
> different from the BGP's ASN". 
> Linda
> -----Original Message-----
> From: Mališa Vučinić < 
> <>> 
> Sent: Monday, October 07, 2019 10:39 AM
> To: Linda Dunbar < 
> <>>
> Cc: <>; 6tisch < 
> <>>; <>; 
> <>
> Subject: Re: [6tisch] Opsdir last call review of 
> draft-ietf-6tisch-minimal-security-12
> Dear Linda,
> Many thanks for your review. Please find the responses inline.
> Kind regards,
> Mališa
>> On 5 Oct 2019, at 01:54, Linda Dunbar via Datatracker <> 
>> wrote:
>> Reviewer: Linda Dunbar
>> Review result: Has Nits
>> Reviewer: Linda Dunbar
>> Review result: Has Nits  & with comment
>> I am the assigned Ops area reviewer for this draft. The Ops 
>> directorate reviews all IETF documents being processed by the IESG for 
>> the IETF Chair.  Please treat these comments just like any other last call 
>> comments.
>> This document is written very clear, specifying a framework for a new 
>> device to securely join a 6TiSCH network.
>> One question: the document assumes that there is pre-shared key (PSK) 
>> between the device and the controller. The Security Consideration does 
>> describe the common pitfall of  a single PSK shared among a group of 
>> devices. Is there any way to prevent it? Is it necessary to require 
>> the Key to be periodically changed?
> Please note that the document mandates unique PSKs between each device and 
> the JRC (Section 3, PSK), thus a compromise of a single device does not leak 
> the PSK of other devices in the network. The discussion you refer to in the 
> Security Consideration section makes an attempt to draw attention to the 
> unsafe practices, but beyond mandating the PSK to be unique for each pledge, 
> which is already a strong requirement, I am not sure we can do much more 
> about it. Requiring the PSK to be periodically changed would require periodic 
> in-situ manipulation of devices (by the 100s or even 1000s), something that 
> is not realistically going to happen…What we could do, however, is to mandate 
> the PSK to be changed upon device re-commissioning to a new owner, when it is 
> likely that a device needs to be manipulated, so I would propose the 
> following sentence be added at the end of Section 3, PSK:
> NEW:
> In case of device re-commissioning to a new owner, it is REQUIRED to change 
> the PSK.
> Would that work?
>> Another  suggestion:
>> Section 5.1 introduces an acronym ASN to represent "Absolute slot number".
>> Can you use a different acronym because ASN has been widely used in 
>> networking as the Autonomous System Number.
> ASN for "Absolute slot number” was defined in the IEEE 802.15.4 specification 
> and the acronym is widely used in our community. I would refrain from 
> re-defining it as it would cause confusion, given that is already used in 
> other documents produced by the 6TiSCH working group (RFC8180, RFC7554).
>> ---
>> An autonomous system number (ASN) is a unique number that's available 
>> globally to identify an autonomous system and which enables that 
>> system to exchange exterior routing information with other neighboring 
>> autonomous systems.
>> Thank you.
>> Linda Dunbar
>> _______________________________________________
>> 6tisch mailing list
>> <>.
>> <>%2Fmailman%2Flistinfo%2F6tisch&amp;data=02%7C01%7Clinda.dunbar
>> <>%7C4b48bea8289a448fc54308d74b3c7064%7C0fee8ff2a3b24018
>> 9c753a1d5591fedc%7C1%7C1%7C637060595293959400&amp;sdata=eD9OiaPzigRIqt
>> 66tBC1fANtpgzVzIX2SxldjSYwsq4%3D&amp;reserved=0

6tisch mailing list

Reply via email to