Re: [mile] [Gen-art] Genart last call review of draft-ietf-mile-jsoniodef-09

Alissa Cooper <alissa@cooperw.in> Wed, 04 September 2019 18:15 UTC

Return-Path: <alissa@cooperw.in>
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 85AFF120271; Wed, 4 Sep 2019 11:15:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=ShKc7S3Y; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=IZ1nsfm/
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 Lpsb6Huti0uC; Wed, 4 Sep 2019 11:15:10 -0700 (PDT)
Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFC57120ADE; Wed, 4 Sep 2019 11:15:09 -0700 (PDT)
Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 3D1C92215D; Wed, 4 Sep 2019 14:15:09 -0400 (EDT)
Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Wed, 04 Sep 2019 14:15:09 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm1; bh=s pCkVbQbzpfhSpqR47TD/HK8pYWkbEYzyMq9ecciAOM=; b=ShKc7S3YAfsYSmjyt wYvuYANUf1U6rpwl7COmZLHv4lSSOintVFIjrPcBZ+aXtyXMhkJjo88tpJnNkeKn /uUpyHfFPW3pxatKuLnLLzKHz4uvCts2S2cAYLub6d1SKImRpJaB+kmnMz17pLS4 CKm4RouPZvpqjbLh/MUGhMnVspu59Pd5OmEjdhZ9pZ6/1z+CPBWNxIw2ck4kV8oh Ztq7pDwZ5QwzdWOTrWB8/Uu3rh81xeW/AAgebg2btR27bLa748kRkLC25qcTZhXn T46DXQNF46EinLPKklPvKpheDbt8yT+ESsQRGb8mtENxchNiVHLa5L34KtCrZugM L8lSQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=spCkVbQbzpfhSpqR47TD/HK8pYWkbEYzyMq9ecciA OM=; b=IZ1nsfm/PwrG13+L84jZP1RXPk68DWAH/awSMJJcLG2Q5jqsAhjwVTYVj GE5tOlFYUnmOMZPJE94cUGrwF7e9Gg/8XUBlrWbf/R9NLIGyg5LVgKy7Qx/ELS74 RriGB5BSHUNXAcaaDnO5gmYuKlcBTTywmKiDUHLNcSUdaGWcmX8thcS710mW6xIU hkMz30lTFgr8H5fRV6SsnrEW0PeLZeW4QPS0niydC/ap0ciAw/MLjFQ9Fq5JhvPJ ylm85PiFGgJDOV4xM3i4bodzEBaXmDzt4KZhuCVgAiAbX6XvtVa2BKb7czJYCJay 7nAr7s2NW//WGaHW9U2tbTTepLg4w==
X-ME-Sender: <xms:LP9vXYSH--H83c62085fdrDsITo6jD3MdbdSrf2gilw77ivxctcn-Q>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddrudejhedguddvtdcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpegtggfuhfgjfffgkfhfvffosehtqhhmtdhhtdejnecuhfhrohhmpeetlhhi shhsrgcuvehoohhpvghruceorghlihhsshgrsegtohhophgvrhifrdhinheqnecuffhomh grihhnpehgihhthhhusgdrtghomhenucfkphepudejfedrfeekrdduudejrdejgeenucfr rghrrghmpehmrghilhhfrhhomheprghlihhsshgrsegtohhophgvrhifrdhinhenucevlh hushhtvghrufhiiigvpedt
X-ME-Proxy: <xmx:LP9vXQZ7CRsnUHSC-YS4eov2pf8NEx0_5OLzkJs7Q8vTsv82GaZ0ag> <xmx:LP9vXb17urbLHf53M8qOVEZeSI7gT8BMPSfYCZEHoGtTNTgRRgvz0w> <xmx:LP9vXbp51Rk1XcoWX8sI0BAaMJUaNmaPPRoMg6mcYRrCDfvlBdyCQQ> <xmx:Lf9vXb1886TzPephIIYqocciF-wC_Glrgu-QBUgwOcmkSeGC9t3yHw>
Received: from rtp-alcoop-nitro2.cisco.com (unknown [173.38.117.74]) by mail.messagingengine.com (Postfix) with ESMTPA id 4C4D080063; Wed, 4 Sep 2019 14:15:08 -0400 (EDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Alissa Cooper <alissa@cooperw.in>
In-Reply-To: <00f301d53f17$f279e490$d76dadb0$@nict.go.jp>
Date: Wed, 4 Sep 2019 14:15:07 -0400
Cc: gen-art <gen-art@ietf.org>, mile@ietf.org, IETF discussion list <ietf@ietf.org>, draft-ietf-mile-jsoniodef.all@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <E844C8DC-022F-4EB3-84E5-C64333416944@cooperw.in>
References: <156328777358.31683.16943185111751565258@ietfa.amsl.com> <00f301d53f17$f279e490$d76dadb0$@nict.go.jp>
To: Takeshi Takahashi <takeshi_takahashi@nict.go.jp>, Robert Sparks <rjsparks@nostrum.com>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/mile/mcDtNrb0I9XGO8ehYkwJQrgrZnE>
Subject: Re: [mile] [Gen-art] Genart last call review of draft-ietf-mile-jsoniodef-09
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: Wed, 04 Sep 2019 18:15:13 -0000

Robert, thank you for your review. Take, thank you for addressing Robert’s comments. I entered a No Objection ballot.

Best,
Alissa


> On Jul 20, 2019, at 12:26 PM, Takeshi Takahashi <takeshi_takahashi@nict.go.jp>; wrote:
> 
> Hi Robert,
> 
> Thank you very much for your kind feedbacks.
> All comments are very much appreciated.
> The revised version of the draft is available at: https://github.com/milewg/draft-ietf-mile-jsoniodef
> Below are the replies to each of your comments.
> 
>> Minor Issues:
>> 
>> * Section 2.2.5 says "base64 ... should be used for encoding". Why is this (a
>>  lower case) should? What happens if something doesn't base64 encode embedded
>>  raw data?
> 
> Changed to "SHOULD." Thanks.
> 
>> * In the table in section 3.1 (and I suspect the corresponding cddl and json
>>  schema, but I haven't verified that), in the block for 'Incident',
>>  'Indictator' is marked with a *. Looking at RFC7970, I think it should be
>>  marked with a ?. (0..1 instead of 0..*).
> 
> Thanks for the careful review. We appreciate this comment very much.
> Indeed, this was intentionally changed so.
> As the 5th bullet in Section 3.2 says, "IndicatorData class is deleted, and classes with its instances now directly have the instances of Indicator class that used to belong to the IndicatorData class."
> 
>> * There are places in the prose of RFC7970 that add restrictions to conformant
>>  XML documents that aren't captured in the schema. See "An instance of one of
>>  these children MUST be present." in section 3.11 of that document for example.
>>  That constraint is not present in this document (or did I miss it)? 
> 
> The sentence in RFC7970 could be misleading (but the sentence in RFC7970 is correct).
> "An instance of one of these children MUST be present" (in section 3.11) means that at least one of "Reference", "Description", "sci:AttackPattern", "sci:Vulnerability", "sci:Weakness", "AdditionalData" classes need to be presented, and it does not mean either "restriction" or "ext-restriction" needs to be presented.
> 
>> * In section 3.2, the 7th bullet is likely an artifact of an earlier idea that
>>  was replaced by the one in the 8th bullet. I suggest deleting the 7th bullet
>>  (The one that says "Record class is replaced by RecordData class, and
>>  RecordData class is renamed to Record class."
> 
> Removed. Thanks.
> 
>> Nits:
>> 
>> * I suggest removing 'abstract' from 'abstract IODEF JSON' in section 2.
> 
> Changed. Thanks.
> 
>> * Section 3.2 uses "CBOR/JSON IODEF" in some places (see the title and several
>>  bullets). The Introduction introduces this as just "JSON IODEF". I suggest
>>  removing the "CBOR/" wherever it occurs.
> 
> All of "CBOR/" were removed or changed. Thanks.
> 
>> * The example in Figure 6 is broken at the end. There is a BulkObservable list
>>  that says it is supposed to consist of ipv6-addr objects, but the list
>>  consists of one e-mail object.  (Same happens in Figure 7 of course).
> 
> Thank you for pointing this out.
> The type is now changed to "domain-name."
> 
> Once again, thank you very much for your reviews.
> 
> Kind regards,
> Take
> 
> 
> -----Original Message-----
> From: Robert Sparks via Datatracker <noreply@ietf.org>; 
> Sent: Tuesday, July 16, 2019 11:36 PM
> To: gen-art@ietf.org
> Cc: mile@ietf.org; ietf@ietf.org; draft-ietf-mile-jsoniodef.all@ietf.org
> Subject: Genart last call review of draft-ietf-mile-jsoniodef-09
> 
> Reviewer: Robert Sparks
> Review result: Almost Ready
> 
> I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair.  Please treat these comments just like any other last call comments.
> 
> For more information, please see the FAQ at
> 
> <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>;.
> 
> Document: draft-ietf-mile-jsoniodef-09
> Reviewer: Robert Sparks
> Review Date: 2019-07-16
> IETF LC End Date: 2019-08-01
> IESG Telechat date: Not scheduled for a telechat
> 
> Summary: Almost ready for publication as a proposed standard RFC, but with minor issues and nits to address before publication
> 
> I skimmed the various formal definitions. I have not verified they are complete or correct. If someone in the working group hasn't found a tool to do that, then the chairs should wrangle some intense volunteer labor to make sure these things are what you intend them to be.
> 
> Minor Issues:
> 
> * Section 2.2.5 says "base64 ... should be used for encoding". Why is this (a
>  lower case) should? What happens if something doesn't base64 encode embedded
>  raw data?
> 
> * In the table in section 3.1 (and I suspect the corresponding cddl and json
>  schema, but I haven't verified that), in the block for 'Incident',
>  'Indictator' is marked with a *. Looking at RFC7970, I think it should be
>  marked with a ?. (0..1 instead of 0..*).
> 
> * There are places in the prose of RFC7970 that add restrictions to conformant
>  XML documents that aren't captured in the schema. See "An instance of one of
>  these children MUST be present." in section 3.11 of that document for example.
>  That constraint is not present in this document (or did I miss it)? 
> 
> * In section 3.2, the 7th bullet is likely an artifact of an earlier idea that
>  was replaced by the one in the 8th bullet. I suggest deleting the 7th bullet
>  (The one that says "Record class is replaced by RecordData class, and
>  RecordData class is renamed to Record class."
> 
> Nits:
> 
> * I suggest removing 'abstract' from 'abstract IODEF JSON' in section 2.
> 
> * Section 3.2 uses "CBOR/JSON IODEF" in some places (see the title and several
>  bullets). The Introduction introduces this as just "JSON IODEF". I suggest
>  removing the "CBOR/" wherever it occurs.
> 
> * The example in Figure 6 is broken at the end. There is a BulkObservable list
>  that says it is supposed to consist of ipv6-addr objects, but the list
>  consists of one e-mail object.  (Same happens in Figure 7 of course).
> 
> 
> 
> _______________________________________________
> Gen-art mailing list
> Gen-art@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art