[mile] comments on the draft-ietf-mile-rolie-vuln-00 draft

"Takeshi Takahashi" <takeshi_takahashi@nict.go.jp> Sun, 07 April 2019 06:41 UTC

Return-Path: <takeshi_takahashi@nict.go.jp>
X-Original-To: mile@ietfa.amsl.com
Delivered-To: mile@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 562201201AF for <mile@ietfa.amsl.com>; Sat, 6 Apr 2019 23:41:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.107
X-Spam-Level:
X-Spam-Status: No, score=-4.107 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTML_OBFUSCATE_10_20=0.093, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W9ZYwB_RFwef for <mile@ietfa.amsl.com>; Sat, 6 Apr 2019 23:41:34 -0700 (PDT)
Received: from ns1.nict.go.jp (ns1.nict.go.jp [IPv6:2001:df0:232:300::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3636212019C for <mile@ietf.org>; Sat, 6 Apr 2019 23:41:34 -0700 (PDT)
Received: from gw1.nict.go.jp (gw1.nict.go.jp [133.243.18.250]) by ns1.nict.go.jp with ESMTPS id x376fXLo082065 for <mile@ietf.org>; Sun, 7 Apr 2019 15:41:33 +0900 (JST)
Received: from mail2.nict.go.jp (mail2.nict.go.jp [133.243.18.15]) by gw1.nict.go.jp with ESMTP id x376fWmr082039 for <mile@ietf.org>; Sun, 7 Apr 2019 15:41:32 +0900 (JST)
Received: from LAPTOP9DLCDU5S (ssh1.nict.go.jp [133.243.3.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail2.nict.go.jp (NICT Mail Spool Server2) with ESMTPSA id 5024E12728 for <mile@ietf.org>; Sun, 7 Apr 2019 15:41:32 +0900 (JST)
From: "Takeshi Takahashi" <takeshi_takahashi@nict.go.jp>
To: <mile@ietf.org>
Date: Sun, 7 Apr 2019 15:41:31 +0900
Message-ID: <00a301d4ed0c$f1b2bbc0$d5183340$@nict.go.jp>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_00A4_01D4ED58.619B2710"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AdTtDMcDffZbVJr3TyWpHpICA9yR1Q==
Content-Language: ja
X-Virus-Scanned: clamav-milter 0.101.1 at zenith1m8
X-Virus-Status: Clean
Archived-At: <https://mailarchive.ietf.org/arch/msg/mile/5RP95VBLAepFeYzuIoixQxkSDRQ>
Subject: [mile] comments on the draft-ietf-mile-rolie-vuln-00 draft
X-BeenThere: mile@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" <mile.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mile>, <mailto:mile-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mile/>
List-Post: <mailto:mile@ietf.org>
List-Help: <mailto:mile-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mile>, <mailto:mile-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 07 Apr 2019 06:41:36 -0000

Hi Stephen,

 

I have read the draft-ietf-mile-rolie-vuln-00 draft and I generally like the
draft.

Here are some comments.

 

1.	"There must be one rolie:property with the name attribute equal to
urn.content-id" seems to be a common requirements for both XML CVE and JSON
CVE. Currently, it is written as a XML CVE requirement and as a JSON CVE
requirement, but it could be written as a common requirement.
2.	Regarding VDO, it is not a spec yet. How will you cope with VDO once
it becomes a spec (approved by NIST)?
3.	According to the current text, I could not find any field that
indicates that the content is "cve". By looking at the information-type, we
can see the content is a vulnerability information. But we cannot know the
content is a cve note or not until we see the content itself. Is my
understanding correct? Where can we know that the content is a cve note or
not?
4.	According to the current text, I understood that we will treat a VDO
as a plain text at this moment. Then, do we indicate that the content is a
vulnerability information or not? It seems to be that we do not indicate so
according to the current text. Is that so?
5.	Section 4 is concisely represented. I like it. However, having some
examples will help readers to understand the content properly. How about
adding some examples in its appendix or in this section?
6.	According to section5.1, we MUST send a severity information when
sending a vulnerability note. That means, we cannot send an early
vulnerability information without a score, correct? Just a clarification.
7.	I guess you will make this vulnerability rolie extensible enough.
Can you add some sentences how we could cope with the other vulnerability
notes that may emerge in the future?
8.	Is it going to be an informational RFC? It has several definitive
parts. So, I am just asking your intention.

 

Editorial comments are not important at this stage, but it won't harm to
list here.

 

"support Vulnerability use cases" -> "support vulnerability use cases".

"a automated and efficient fashion" -> "an automated and efficient fashion".

"a XML" -> "an XML"

In the reference, vdo cannot be a normative reference at this moment, due to
its document status.

 

Thank you, and kind regards,

Take