[Dots] draft-andreasen-dots-info-data-model-01 feedback

"Roman D. Danyliw" <rdd@cert.org> Fri, 11 November 2016 14:50 UTC

Return-Path: <rdd@cert.org>
X-Original-To: dots@ietfa.amsl.com
Delivered-To: dots@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08CB712999F for <dots@ietfa.amsl.com>; Fri, 11 Nov 2016 06:50:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.299
X-Spam-Level:
X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cert.org
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 0BpSQKYtGxl0 for <dots@ietfa.amsl.com>; Fri, 11 Nov 2016 06:50:57 -0800 (PST)
Received: from shetland.sei.cmu.edu (shetland.sei.cmu.edu [192.58.107.44]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E61731295BC for <dots@ietf.org>; Fri, 11 Nov 2016 06:50:56 -0800 (PST)
Received: from timber.sei.cmu.edu (timber.sei.cmu.edu [10.64.21.23]) by shetland.sei.cmu.edu (8.14.4/8.14.4/1543) with ESMTP id uABEorJe027220; Fri, 11 Nov 2016 09:50:53 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cert.org; s=jthatj15xw2j; t=1478875853; bh=aNylLCvIgWNUnnYl7nwZPQKEhNnDp2Zk++j6Ok2kzKo=; h=From:To:CC:Subject:Date:Message-ID:Content-Type:MIME-Version: Sender:Reply-To:In-Reply-To:References; b=J6xh9zZLVb9BYacwtJ2f0MVUS+gZPX6EfPd12eIa/2jwmNy5gtWy/HhBWt2fYIjG8 3NcRhCyr9FwG3rpgOp/Lbpg8bCHdvmjcmDZhnTgFlRJ9QVvR5f+uKgrC1oTi/yQkMe breo7KXT7OpMfVb2p7W0twqHIG5yjZeZxKCBR2JA=
Received: from CASSINA.ad.sei.cmu.edu (cassina.ad.sei.cmu.edu [10.64.28.249]) by timber.sei.cmu.edu (8.14.4/8.14.4/1543) with ESMTP id uABEoowd004899; Fri, 11 Nov 2016 09:50:50 -0500
Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASSINA.ad.sei.cmu.edu ([10.64.28.249]) with mapi id 14.03.0319.002; Fri, 11 Nov 2016 09:50:49 -0500
From: "Roman D. Danyliw" <rdd@cert.org>
To: Flemming Andreasen <fandreas@cisco.com>, "'Tirumaleswar Reddy (tireddy)'" <tireddy@cisco.com>
Thread-Topic: draft-andreasen-dots-info-data-model-01 feedback
Thread-Index: AdI8HNmty5hVyO32RvKRVPx3YhO6ig==
Date: Fri, 11 Nov 2016 14:50:48 +0000
Message-ID: <359EC4B99E040048A7131E0F4E113AFC0104EAEB7B@marathon>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.64.22.6]
Content-Type: multipart/alternative; boundary="_000_359EC4B99E040048A7131E0F4E113AFC0104EAEB7Bmarathon_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dots/sfVwaMFIt8Ih6O5NzunDRo9fcy0>
Cc: "dots@ietf.org" <dots@ietf.org>
Subject: [Dots] draft-andreasen-dots-info-data-model-01 feedback
X-BeenThere: dots@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." <dots.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dots>, <mailto:dots-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dots/>
List-Post: <mailto:dots@ietf.org>
List-Help: <mailto:dots-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dots>, <mailto:dots-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 11 Nov 2016 14:50:59 -0000

Hello Flemming and Tiru!

(chair hat off)
In reading through draft-andreasen-dots-info-data-model-01, I had the following comments/questions:

(1) The title suggests that the goal is for an information _and_ data model to be documented.  I didn't see much distinction made between the two in the text.  Is the thinking to cover both?

(2) I really like the enumeration of information elements in Section 3.4 and think this will be helpful for the authors of the solutions drafts.  I struggled with the Section 3.2 a bit and may not fully understand what you had in mind.  My thinking for an information model document would be enumerating and describing information elements; and where appropriate, the interrelationship between them.  The current text seems to go one step further with protocol semantics and abstract message formats.  I would have considered these out of scope for an information model.

(3) In Section 3.1, the parameters categorized as mandatory, optional and extensions.  Is the text implying that these are three mutually exclusive categories?  For example, an extension, when used, cannot have mandatory fields?

(4) Section 3.1 - 3.3 discuss message parameters.  Section 3.4 enumerates information elements.  The link between parameters and information elements is never explicitly stated.

Roman