Re: [Idr] [Can] Proposed CAN WG charter for discussion

"易昕昕(联通集团中国联通研究院- 本部)" <yixx3@chinaunicom.cn> Thu, 02 February 2023 06:45 UTC

Return-Path: <yixx3@chinaunicom.cn>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DFF2C14CE42; Wed, 1 Feb 2023 22:45:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.317
X-Spam-Level:
X-Spam-Status: No, score=-6.317 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, INVALID_MSGID=0.568, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pRqX8d7dbzUW; Wed, 1 Feb 2023 22:45:53 -0800 (PST)
Received: from senda.mailex.chinaunicom.cn (senda.mailex.chinaunicom.cn [123.138.59.136]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E18DC14F74B; Wed, 1 Feb 2023 22:45:42 -0800 (PST)
Received: from M10-XA-MLCEN03.MailSrv.cnc.intra (unknown [10.236.3.199]) by senda.mailex.chinaunicom.cn (SkyGuard) with ESMTPS id 4P6q8X3lPgz7fvf1; Thu, 2 Feb 2023 14:47:08 +0800 (CST)
Received: from smtpbg.qq.com (10.237.2.96) by M10-XA-MLCEN03.MailSrv.cnc.intra (10.236.3.199) with Microsoft SMTP Server id 15.0.1497.42; Thu, 2 Feb 2023 14:45:29 +0800
X-QQ-mid: Ymail-xx24b003-t1675320327t1c
Received: from yixx-PC (unknown [10.2.108.208]) by smtp.qq.com (ESMTP) with id ; Thu, 02 Feb 2023 14:45:27 +0800 (CST)
X-QQ-SSF: 00900000000000B0H410000A0000000
X-QQ-GoodBg: 0
From: "易昕昕(联通集团中国联通研究院- 本部)" <yixx3@chinaunicom.cn>
To: John Scudder <jgs=40juniper.net@dmarc.ietf.org>
CC: can <can@ietf.org>, idr <idr@ietf.org>
Date: Thu, 02 Feb 2023 14:45:28 +0800
References: <53B67919-AD61-489D-8115-EBCB5CCE1976@juniper.net>
X-Priority: 3
X-Has-Attach: no
X-Mailer: Foxmail 7.2.23.119[cn]
MIME-Version: 1.0
Message-ID: <2023020214452830405715@chinaunicom.cn>
Content-Type: multipart/alternative; boundary="----=_001_NextPart403244764124_=----"
X-QQ-SENDSIZE: 520
Feedback-ID: Ymail-xx:chinaunicom.cn:mail-xx:mail-xx24b003-zhyw44w
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/ktP5YFBaNW6_f0a5SfAcWRPwBko>
Subject: Re: [Idr] [Can] Proposed CAN WG charter for discussion
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 02 Feb 2023 06:45:57 -0000

Hi John,
     The updated charter looks reasonable to me, thanks for the update.
     I also think that “architecture and framework” should be part of the follow-up discussion of CAN. Furthermore, the architecture of CAN should not be limited to centralized way or distributed way now, and should be open for discussion in the future. It will be a good work item in the WG.
     We are also doing relevant researches on CAN, therefore I would like to contribute more to this project in the future.  Happy to see the progress.

Thanks.

________________________________
Xinxin Yi

发件人: John Scudder<mailto:jgs=40juniper.net@dmarc.ietf.org>
发送时间: 2023-01-25 06:29
收件人: can@ietf.org<mailto:can@ietf.org>
主题: [Can] Proposed CAN WG charter for discussion
TL;DR:

What we need now, before we go forward with the WG formation process, is an active discussion of the proposed charter. In the unlikely event that the proposal is now perfect, the discussion could take the form of “looks good to me”, but I still need to see evidence of ongoing and diverse interest to form a WG to do the work described in the charter, before I take this to the rest of the IESG.

More details are below.


Hi CAN Fans,

After further discussion with the proponents, I feel we’ve made enough progress on the draft charter to start wrapping up this phase of the discussion so we can move on to the next step of the WG chartering process. I’ve uploaded a proposed charter to the CAN BOF page, it is up for discussion by the CAN community. You can find it at https://datatracker.ietf.org/doc/charter-ietf-can/

As you’ll see, the proposed charter has been slimmed down by removing some of the historical content, rewriting other parts, and focusing the first-round deliverables on analysis and architecture rather than solutions. Depending on the WG’s output in that step, a future step might be to recharter to work on solutions, it might be to dispatch requests to other WGs to do extensions, or it might be a conclusion that existing protocols, cleverly used, might already be sufficient.

One thing I think is missing in the current draft charter is that in the bulleted list following "The CAN WG is chartered to work on the following items”, we don’t have anything specific about architecture and framework. The first major bullet, “Groundwork”, as the name implies lists items that will lead to architecture and framework. The second major bullet item,  "Applicability of existing tools and mechanisms”, is work that (I think) can’t be done without an architecture and framework to refer to. So, there’s something missing in between. I think the introduction plus milestones makes it reasonably clear that framework + architecture are key WG outputs, but it seems to me we should fix this inconsistency in the bullet list. (Could be done by removing the bullet list, although that seems potentially useful for organizing the WG’s work plan.) If this is agreed upon, perhaps someone could propose text.

I’d also like to note a detail — major bullet 1 notes "Groundwork may be … not necessarily for publication as an RFC”. I support this approach — not every document a WG uses to do its work needs to end up as an RFC, some can be intermediate steps. There is also a milestone, "Adopt the CAN Problem Statement, Use Cases, gap analysis, and Requirements documents”. I think these two things are not in contradiction, because note there is not a corresponding “Submit the CAN Problem Statement, Use Cases, gap analysis, and Requirements documents for publication” milestone. I view this as a feature, and not an oversight, but wanted to make sure the (potential) WG is aware of it.

Let’s leave this thread open for discussion until at least February 3 before taking any further steps, to hopefully allow everyone who may now be on holiday a chance to see it and have an opportunity to comment and discuss. Once we converge on a proposed charter, we can begin the IESG review and then IETF review steps. The earliest opportunity for IESG review would be the February 16 IESG meeting.

Thanks,

—John
--
Can mailing list
Can@ietf.org
https://www.ietf.org/mailman/listinfo/can
如果您错误接收了该邮件,请通过电子邮件立即通知我们。请回复邮件到 hqs-spmc@chinaunicom.cn,即可以退订此邮件。我们将立即将您的信息从我们的发送目录中删除。 If you have received this email in error please notify us immediately by e-mail. Please reply to hqs-spmc@chinaunicom.cn ,you can unsubscribe from this mail. We will immediately remove your information from send catalogue of our.