Re: [mile] Benjamin Kaduk's No Objection on draft-ietf-mile-jsoniodef-13: (with COMMENT)

Takeshi Takahashi <> Mon, 02 March 2020 04:13 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EA5103A0AA4; Sun, 1 Mar 2020 20:13:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id AcEOR3J8-3MO; Sun, 1 Mar 2020 20:13:30 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3D52B3A0AA1; Sun, 1 Mar 2020 20:13:30 -0800 (PST)
DKIM-Signature: v=1;a=rsa-sha256;c=relaxed/simple;;h=From:To:Cc: References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type: Content-Transfer-Encoding;;s=20200225.smx;t= 1583122406; x=1584332006; bh=6VL8F0Vr09q1Hd27VlOwkEVfAaLUu3GwWeOm7DOxMwA=; b=Kyt wroh7JtHzuYRPsSs15MQROEH5nofYS8TAW20FIqhPWoj1XwyKd5qpX5/JxTgkuovelMaSwXBKAnVR q35TNwbun0Q3p2jiaT8W0BscWHAnfbryPlIqzg7tLT94BymZzeijXlCQJchdT1lAE91ten2hAa/ir x2vWArlUAAF1bs07ksiwo7NntqzkQ6LqtIdJPtM5KjLH2j3BR6vHUPmVf86/IG3PNZXSzP+NDkTB8 wMS8Xp1pz2VH0zw2ggz14vsiwierAN9hj50QKqvJhZKZyv5C7Z1r8of6eOQFu8nQ/C8u+pHfHzehU 6rfN8fVtI3yHnNu4zD4REjY2FdXtsgg==;
Received: by (mx-mo-csw1514) id 0224DO1I029823; Mon, 2 Mar 2020 13:13:25 +0900
X-Iguazu-Qid: 34tKBCeZ3LZ5lKWMIj
X-Iguazu-QSIG: v=2; s=0; t=1583122404; q=34tKBCeZ3LZ5lKWMIj; m=6MdNGTrDqyQiJqLPjme152/9PHYIGUws2jMb2SWFXes=
Received: from ( [IPv6:2001:df0:232:1200::f]) by (mx-mr1512) id 0224DNja033607 (version=TLSv1.2 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Mon, 2 Mar 2020 13:13:23 +0900
Received: from LAPTOP9DLCDU5S ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (NICT Mail Spool Server2) with ESMTPSA id 7D3ED3B442; Mon, 2 Mar 2020 13:13:22 +0900 (JST)
From: "Takeshi Takahashi" <>
To: "'Benjamin Kaduk'" <>, "'The IESG'" <>
Cc: <>, <>, <>
References: <>
In-Reply-To: <>
Date: Sun, 1 Mar 2020 20:13:20 -0800
Message-ID: <008201d5f048$eb44bdc0$c1ce3940$>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Content-Language: en-us
Thread-Index: AQG2PAq4F/b3IKOplm2JnGgfZtNu6Kh0GFjQ
Archived-At: <>
Subject: Re: [mile] Benjamin Kaduk's No Objection on draft-ietf-mile-jsoniodef-13: (with COMMENT)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 02 Mar 2020 04:13:33 -0000

Hello Benjamin,

We appreciate your kind feedbacks very much.
We believe your comments are very correct; so we have modified the draft

Thank you very much, and best regards,

-----Original Message-----
From: mile <> On Behalf Of Benjamin Kaduk via
Sent: Wednesday, February 26, 2020 1:00 PM
To: The IESG <>
Subject: [mile] Benjamin Kaduk's No Objection on
draft-ietf-mile-jsoniodef-13: (with COMMENT)

Benjamin Kaduk has entered the following ballot position for
draft-ietf-mile-jsoniodef-13: No Objection

When responding, please keep the subject line intact and reply to all email
addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:


Thank you for the updates in the -13; they are a good improvement!

I did notice a couple things while reviewing the diff from -12 to -13 that
I'll mention here, in case there might be any further tweaks to make.

In Figure 7 it looks like the encoded text includes an embedded CR+LF.
I don't think this is forbidden by anything, but is perhaps superfluous.

Thanks for the table of CBOR map keys in Section 5.  I note that slightly
shorter encodings might be possible by using negative integers as well as
positive ones, with "steps" for the encoding size occurring at 24, 256,
etc., and -25, -257, etc.

[I did not check the examples for correct use of the CBOR map key values, on
the assumption that they were mechanically generated.]

The definition of StructuredInfo underwent a change that was not quite
"(RawData: [+ BYTE] // Reference:[+ Reference])" became "(iodef-RawData =>
[+ BYTE], iodef-Reference => [+ Reference])" (dropping the grouping choice
operator "//").  I don't remember if there was a reason to make this change,
so I mention it in case it was not deliberate.

mile mailing list