[Dots] Alignment with architecture document

"Roman D. Danyliw" <rdd@cert.org> Thu, 21 July 2016 09:39 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 405C412DC0B for <dots@ietfa.amsl.com>; Thu, 21 Jul 2016 02:39:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.3
X-Spam-Level:
X-Spam-Status: No, score=-4.3 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_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 C_wzCkVdzjgr for <dots@ietfa.amsl.com>; Thu, 21 Jul 2016 02:39:10 -0700 (PDT)
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 9FE7912D10B for <dots@ietf.org>; Thu, 21 Jul 2016 02:39:10 -0700 (PDT)
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 u6L9d9vf032305 for <dots@ietf.org>; Thu, 21 Jul 2016 05:39:09 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cert.org; s=jthatj15xw2j; t=1469093949; bh=R9xugZEPrdmSp82DLuWhJk11Z+vIWY+7M8MvuO425GY=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version:Sender:Reply-To:Cc: In-Reply-To:References; b=N+GKFZnppeDLslRdg4+oochtb6R7yuGbLzcTKvh56xcxrUojvK3Ny6DI/zGqjAdLB Pmnv6vm+Z6bln/TfKi8LPfUN4PB/Qxk2Pq/ZAdu0eM8CEjwruJwi64Gmm423xjiGM+ oF3OR6qLW41DNmmDu88/daOS8aQZyvmNSduvgK4w=
Received: from CASCADE.ad.sei.cmu.edu (cascade.ad.sei.cmu.edu [10.64.28.248]) by timber.sei.cmu.edu (8.14.4/8.14.4/1543) with ESMTP id u6L9d7GO024866 for <dots@ietf.org>; Thu, 21 Jul 2016 05:39:07 -0400
Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASCADE.ad.sei.cmu.edu ([10.64.28.248]) with mapi id 14.03.0279.002; Thu, 21 Jul 2016 05:39:05 -0400
From: "Roman D. Danyliw" <rdd@cert.org>
To: "dots@ietf.org" <dots@ietf.org>
Thread-Topic: Alignment with architecture document
Thread-Index: AdHishtQstvji5VhRRW6cZRJEraRiw==
Date: Thu, 21 Jul 2016 09:39:04 +0000
Message-ID: <359EC4B99E040048A7131E0F4E113AFC0104E1D534@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: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dots/zaIVDQDEOf-BJIoJGpEqnXSYEnk>
Subject: [Dots] Alignment with architecture document
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: Thu, 21 Jul 2016 09:39:12 -0000

Hello WG!

Chair hat off ...

In an attempt to validate the current thinking on the DOTS architecture, I reviewed the four individual solutions drafts [2][3][4][5] currently discussed by the WG to see whether the messaging they describe aligned with the text in the newly published (thanks Andrew, Flemming, Tiru, Chris and Rich) WG architecture document [1].  I found:

(1) The protocol drafts [2], [3] and [5] express their messaging in architecture terms described in [1].  Specifically:

** [2], [3] and [5] delineate that messages are sent by or to a DOTS server, client or gateway/relay per Section 2.2 of [1]
** [2] defines signal and data channel communications; and [3] and [5] define signal channel communication per Figure 2 of [1]
** [5] references an older version of [1]; and [2] and [3] do not reference [1].

(2) The protocol draft [4] does not express messaging in terms of the components (i.e., DOTS server, client or gateway) or interfaces (i.e., signal and data channels) described in [1].

The lack of alignment in [4] is the finding that is most interesting for me.  Does this draft [4] suggest we need new components or interfaces in the architecture? New use cases?

Regards,
Roman 

[1] draft-ietf-dots-architecture-00
[2] draft-reddy-dots-transport-05
[3] draft-francois-dots-ipv6-signal-option-00
[4] draft-fu-dots-ipfix-extension-01
[5] draft-nishizuka-dots-inter-domain-mechanism-01