[6lo] 答复: FW: I-D Action: draft-ietf-6lo-plc-03.txt

"Liubing (Remy)" <remy.liubing@huawei.com> Wed, 20 May 2020 07:46 UTC

Return-Path: <remy.liubing@huawei.com>
X-Original-To: 6lo@ietfa.amsl.com
Delivered-To: 6lo@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 9A61B3A3B3F for <6lo@ietfa.amsl.com>; Wed, 20 May 2020 00:46:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id UrmI13BtMYFp for <6lo@ietfa.amsl.com>; Wed, 20 May 2020 00:46:22 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com []) (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 3C12C3A3B3E for <6lo@ietf.org>; Wed, 20 May 2020 00:46:22 -0700 (PDT)
Received: from lhreml713-chm.china.huawei.com (unknown []) by Forcepoint Email with ESMTP id DCB1C835D3605E726410; Wed, 20 May 2020 08:46:20 +0100 (IST)
Received: from lhreml713-chm.china.huawei.com ( by lhreml713-chm.china.huawei.com ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Wed, 20 May 2020 08:46:20 +0100
Received: from DGGEMM423-HUB.china.huawei.com ( by lhreml713-chm.china.huawei.com ( with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.1913.5 via Frontend Transport; Wed, 20 May 2020 08:46:20 +0100
Received: from DGGEMM506-MBX.china.huawei.com ([]) by dggemm423-hub.china.huawei.com ([]) with mapi id 14.03.0487.000; Wed, 20 May 2020 15:46:16 +0800
From: "Liubing (Remy)" <remy.liubing@huawei.com>
To: Michael Richardson <mcr+ietf@sandelman.ca>, "6lo@ietf.org" <6lo@ietf.org>
CC: Carles Gomez Montenegro <carlesgo@entel.upc.edu>
Thread-Topic: [6lo] FW: I-D Action: draft-ietf-6lo-plc-03.txt
Thread-Index: AQHWK9trXBeulQWszESIy2ZRihXsW6iwPYbg
Date: Wed, 20 May 2020 07:46:16 +0000
Message-ID: <BB09947B5326FE42BA3918FA28765C2E012BD078@DGGEMM506-MBX.china.huawei.com>
References: <BB09947B5326FE42BA3918FA28765C2E0128A6A2@DGGEMM506-MBX.china.huawei.com> <2e56eb0840af0b28df181ca9730be333.squirrel@webmail.entel.upc.edu> <6565.1589672355@localhost>
In-Reply-To: <6565.1589672355@localhost>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
x-originating-ip: []
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/6lo/_ChbWcZsHKIB30NyMoEexfjCox0>
Subject: [6lo] 答复: FW: I-D Action: draft-ietf-6lo-plc-03.txt
X-BeenThere: 6lo@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Mailing list for the 6lo WG for Internet Area issues in IPv6 over constrained node networks." <6lo.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6lo>, <mailto:6lo-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/6lo/>
List-Post: <mailto:6lo@ietf.org>
List-Help: <mailto:6lo-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6lo>, <mailto:6lo-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 20 May 2020 07:46:25 -0000

Hello Michael,

Sorry for this late reply. Thank you for your review.

Please see my response below.

Best regards,

发件人: 6lo [mailto:6lo-bounces@ietf.org] 代表 Michael Richardson
发送时间: 2020年5月17日 7:39
收件人: 6lo@ietf.org
抄送: Liubing (Remy) <remy.liubing@huawei.com>; Carles Gomez Montenegro <carlesgo@entel.upc.edu>; Liyizhou <liyizhou@huawei.com>
主题: Re: [6lo] FW: I-D Action: draft-ietf-6lo-plc-03.txt

Hi, I have reviewed the changes from 02 to 03.
I had suggested that the term PLC Device be used consistently, and I see that.
At the end of the first paragraph of 3.2, "PANC" is used which surprised me, but I see it in the glossary.  I'm not sure if you want to add "JRC"
to the list of aliases for PANC.
[Remy] I can add the full name in 3.2. "PAN Coordinator" is a term that is inherited form the PLC standards. We wanted to abbreviate it as "PCO", but PCO refer to "proxy coordinator" in IEEE 1901.1. Thus we use PANC instead. Do you have any suggestion on this abbreviation? In term of the functionality during the joining process, JRC is an alias of the PAN coordinator.

Thank you for mentioning 6tisch-minimal-security.
There is also a BRSKI-like 6tisch mechanism that uses IDevID.
[Remy] I think you must be talking about [draft-ietf-6tisch-dtsecurity-zerotouch-join]. The minimal security is considered to be one-touch since the PSK has to be configured a priori. And this document provides a zero-touch method, in which the IDevID (provided by the manufacturer) in 802.1AR is used as the credential for authentication. The authentication is done with the help of the MASA. Am I understanding it correctly? I think the method simplifies the provisioning procedure. However, the PLC standards have not supported 802.1AR yet, thus this zero-touch method couldn't be used in the implementation at this moment.

Is it the case that the PLC devices can have no L2 security as an option?
I believe that you may wish to outlaw that situation.

[Remy] All the PLC standards we mentioned in this document have L2 security mechanisms, such as encryption, data integrity, and anti-replay. Since this document is focused on the adaptation layer and above, the L2 security is considered to be applied by default. 
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works  -= IPv6 IoT consulting =-