IETF Logo Mail Archive

[Dots] Data Channel - Deletion of Aliases when manually configured on DOTS Server

"Jon Shallow" <supjps-ietf@jpshallow.com> Wed, 05 September 2018 10:26 UTC

Return-Path: <supjps-ietf@jpshallow.com>
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 6EFB3130DF7 for <dots@ietfa.amsl.com>; Wed, 5 Sep 2018 03:26:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.5
X-Spam-Level:
X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_MESSAGE=0.001, 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 tiSIZT-Gu5wG for <dots@ietfa.amsl.com>; Wed, 5 Sep 2018 03:26:42 -0700 (PDT)
Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9135F130DC5 for <dots@ietf.org>; Wed, 5 Sep 2018 03:26:42 -0700 (PDT)
Received: from [127.0.0.1] (helo=N01332) by mail.jpshallow.com with esmtp (Exim 4.90_1) (envelope-from <jon.shallow@jpshallow.com>) id 1fxV1C-0000fC-G3 for ietf-supjps-dots@ietf.org; Wed, 05 Sep 2018 11:26:39 +0100
From: Jon Shallow <supjps-ietf@jpshallow.com>
To: dots@ietf.org
Date: Wed, 05 Sep 2018 11:26:39 +0100
Message-ID: <006401d44502$eedc4090$cc94c1b0$@jpshallow.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0065_01D4450B.50A144D0"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AdRFAu54VN0AjTquSDWy2o8cWBv6Ow==
Content-Language: en-gb
Archived-At: <https://mailarchive.ietf.org/arch/msg/dots/_liF9uQMFzSCZdRGJnx6vuRIaSE>
Subject: [Dots] Data Channel - Deletion of Aliases when manually configured on DOTS Server
X-BeenThere: dots@ietf.org
X-Mailman-Version: 2.1.29
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: Wed, 05 Sep 2018 10:26:45 -0000

Hi There,

 

When there is a manual configuration on the DOTS server of an alias by an
operator, not created by the DOTS client, what should happen if the DOTS
client tries to delete the alias?

 

The DOTS client will see the alias in a GET request for all aliases (as it
is entitled to use it)

 

Returning a 404 (Not Found) could be confusing

 

Returning a 204 (No Content) is not right as it has not been deleted per se.

 

Should the alias in the GET response be marked as permanent (or some
equivalent)?

 

The same is true for ACLs

 

Regards

 

Jon

v2.23.0 | Report a Bug | By Email