[mile] [Technical Errata Reported] RFC7970 (5351)

RFC Errata System <rfc-editor@rfc-editor.org> Mon, 07 May 2018 17:27 UTC

Return-Path: <wwwrun@rfc-editor.org>
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 F0B6B1275AB for <mile@ietfa.amsl.com>; Mon, 7 May 2018 10:27:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 qqVyU9C3Ul44 for <mile@ietfa.amsl.com>; Mon, 7 May 2018 10:27:01 -0700 (PDT)
Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFCC81273E2 for <mile@ietf.org>; Mon, 7 May 2018 10:27:00 -0700 (PDT)
Received: by rfc-editor.org (Postfix, from userid 30) id 50B29B80FCB; Mon, 7 May 2018 10:26:50 -0700 (PDT)
To: rdd@cert.org, kaduk@mit.edu, ekr@rtfm.com, ncamwing@cisco.com, takeshi_takahashi@nict.go.jp
X-PHP-Originating-Script: 30:errata_mail_lib.php
From: RFC Errata System <rfc-editor@rfc-editor.org>
Cc: logan.widick@gmail.com, mile@ietf.org, rfc-editor@rfc-editor.org
Content-Type: text/plain; charset="UTF-8"
Message-Id: <20180507172650.50B29B80FCB@rfc-editor.org>
Date: Mon, 07 May 2018 10:26:50 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/mile/ymAPuY9RNVClYJ3znChdoFGOzN0>
Subject: [mile] [Technical Errata Reported] RFC7970 (5351)
X-BeenThere: mile@ietf.org
X-Mailman-Version: 2.1.22
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: Mon, 07 May 2018 17:27:03 -0000

The following errata report has been submitted for RFC7970,
"The Incident Object Description Exchange Format Version 2".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata/eid5351

--------------------------------------
Type: Technical
Reported by: Logan Widick <logan.widick@gmail.com>

Section: 2.16

Original Text
-------------
The attributes of the iodef:ExtensionType type are:

   name
      Optional.  STRING.  A free-form name of the field or data element.

   dtype
      Required.  ENUM.  The data type of the element content.  The
      default value is "string".  These values are maintained in the
      "ExtensionType-dtype" IANA registry per Section 10.2.

      1.   boolean.  The element content is of type BOOLEAN.

      2.   byte.  The element content is of type BYTE.

      3.   bytes.  The element content is of type HEXBIN.

      4.   character.  The element content is of type CHARACTER.

      5.   date-time.  The element content is of type DATETIME.

      6.   ntpstamp.  Same as date-time.

      7.   integer.  The element content is of type INTEGER.

      8.   portlist.  The element content is of type PORTLIST.

      9.   real.  The element content is of type REAL.

      10.  string.  The element content is of type STRING.

      11.  file.  The element content is a base64-encoded binary file
           encoded as a BYTE[] type.

      12.  path.  The element content is a file-system path encoded as a
           STRING type.

      13.  frame.  The element content is a Layer 2 frame encoded as a
           HEXBIN type.

      14.  packet.  The element content is a Layer 3 packet encoded as a
           HEXBIN type.

      15.  ipv4-packet.  The element content is an IPv4 packet encoded
           as a HEXBIN type.

      16.  ipv6-packet.  The element content is an IPv6 packet encoded
           as a HEXBIN type.

      17.  url.  The element content is of type URL.

      18.  csv.  The element content is a comma-separated value (CSV)
           list per Section 2 of [RFC4180] encoded as a STRING type.

      19.  winreg.  The element content is a Microsoft Windows registry
           key encoded as a STRING type.

      20.  xml.  The element content is XML.  See Section 5.2.

      21.  ext-value.  A value used to indicate that this attribute is
           extended and the actual value is provided using the
           corresponding ext-* attribute.  See Section 5.1.1.

Corrected Text
--------------
The attributes of the iodef:ExtensionType type are:

   name
      Optional.  STRING.  A free-form name of the field or data element.

   dtype
      Required.  ENUM.  The data type of the element content.  The
      default value is "string".  These values are maintained in the
      "ExtensionType-dtype" IANA registry per Section 10.2.

      1.   boolean.  The element content is of type BOOLEAN.

      2.   byte.  The element content is of type BYTE.

      3.   bytes.  The element content is of type HEXBIN[].

      4.   character.  The element content is of type CHARACTER.

      5.   date-time.  The element content is of type DATETIME.

      6.   ntpstamp.  Same as date-time.

      7.   integer.  The element content is of type INTEGER.

      8.   portlist.  The element content is of type PORTLIST.

      9.   real.  The element content is of type REAL.

      10.  string.  The element content is of type STRING.

      11.  file.  The element content is a base64-encoded binary file
           encoded as a BYTE[] type.

      12.  path.  The element content is a file-system path encoded as a
           STRING type.

      13.  frame.  The element content is a Layer 2 frame encoded as a
           HEXBIN[] type.

      14.  packet.  The element content is a Layer 3 packet encoded as a
           HEXBIN[] type.

      15.  ipv4-packet.  The element content is an IPv4 packet encoded
           as a HEXBIN[] type.

      16.  ipv6-packet.  The element content is an IPv6 packet encoded
           as a HEXBIN[] type.

      17.  url.  The element content is of type URL.

      18.  csv.  The element content is a comma-separated value (CSV)
           list per Section 2 of [RFC4180] encoded as a STRING type.

      19.  winreg.  The element content is a Microsoft Windows registry
           key encoded as a STRING type.

      20.  xml.  The element content is XML.  See Section 5.2.

      21.  ext-value.  A value used to indicate that this attribute is
           extended and the actual value is provided using the
           corresponding ext-* attribute.  See Section 5.1.1.

Notes
-----
Section 2.5.2 (explanation of HEXBIN and HEXBIN[] types) says:
" A binary octet encoded as a character tuple consistent of two
   hexadecimal digits is represented in the information model by the
   HEXBIN data type.  A sequence of these octets is of the HEXBIN[] data
   type.
   The HEXBIN and HEXBIN[] data types are implemented in the data model
   as an "xs:hexBinary" type per Section 3.2.15 of [W3C.SCHEMA.DTYPES]."

If I am reading that section correctly, HEXBIN is for hex-encoded things that decode to exactly one byte, while HEXBIN[] is for hex-encoded things that decode to one or more bytes. Thus, things that may decode to multiple bytes should be HEXBIN[], not HEXBIN. 

The extension types in Section 2.16  that are currently HEXBIN should probably be HEXBIN[]. The name "bytes" implies decoding to multiple bytes (so it should be HEXBIN[]). Frames and packets (regardless of layer) tend to be multiple bytes long (so they should be HEXBIN[] as well).

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC7970 (draft-ietf-mile-rfc5070-bis-26)
--------------------------------------
Title               : The Incident Object Description Exchange Format Version 2
Publication Date    : November 2016
Author(s)           : R. Danyliw
Category            : PROPOSED STANDARD
Source              : Managed Incident Lightweight Exchange
Area                : Security
Stream              : IETF
Verifying Party     : IESG