IETF Logo Mail Archive

Re: [Dots] Mirja's DISCUSS: Pending Point (AD Help Needed)

Benjamin Kaduk <kaduk@mit.edu> Wed, 24 July 2019 13:34 UTC

Return-Path: <kaduk@mit.edu>
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 7DF69120261; Wed, 24 Jul 2019 06:34:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 CaxLimO9gHVv; Wed, 24 Jul 2019 06:34:22 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 5FE2012024C; Wed, 24 Jul 2019 06:34:21 -0700 (PDT)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x6ODYGJO030819 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 24 Jul 2019 09:34:19 -0400
Date: Wed, 24 Jul 2019 08:34:16 -0500
From: Benjamin Kaduk <kaduk@mit.edu>
To: mohamed.boucadair@orange.com
Cc: "Konda, Tirumaleswar Reddy" <TirumaleswarReddy_Konda@mcafee.com>, Valery Smyslov <valery@smyslov.net>, "dots-chairs@ietf.org" <dots-chairs@ietf.org>, "dots@ietf.org" <dots@ietf.org>
Message-ID: <20190724133415.GG50840@kduck.mit.edu>
References: <011701d53ea2$74d81540$5e883fc0$@smyslov.net> <787AE7BB302AE849A7480A190F8B9330312E32E9@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <DM5PR16MB17050AC5EABA8D76DDB42ACBEAC40@DM5PR16MB1705.namprd16.prod.outlook.com> <787AE7BB302AE849A7480A190F8B9330312E3433@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <DM5PR16MB1705DFCE2F9B379A36FD79AAEAC40@DM5PR16MB1705.namprd16.prod.outlook.com> <787AE7BB302AE849A7480A190F8B9330312E34A0@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <DM5PR16MB170553F3A8B1F3F1ED59D509EAC40@DM5PR16MB1705.namprd16.prod.outlook.com> <787AE7BB302AE849A7480A190F8B9330312E3792@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <DM5PR16MB170505ABB7555E0ADCEC1BC6EAC40@DM5PR16MB1705.namprd16.prod.outlook.com> <787AE7BB302AE849A7480A190F8B9330312E3A41@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <787AE7BB302AE849A7480A190F8B9330312E3A41@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dots/kEHs3tP2fBcWTgltnycOMi5KHHk>
Subject: Re: [Dots] Mirja's DISCUSS: Pending Point (AD Help Needed)
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, 24 Jul 2019 13:34:27 -0000

On Mon, Jul 22, 2019 at 03:03:21PM +0000, mohamed.boucadair@orange.com wrote:
> Re-,
> 
> Please see inline. 
> 
> Cheers,
> Med
> 
> > -----Message d'origine-----
> > De : Konda, Tirumaleswar Reddy [mailto:TirumaleswarReddy_Konda@McAfee.com]
> > Envoyé : lundi 22 juillet 2019 16:02
> > À : BOUCADAIR Mohamed TGI/OLN; Valery Smyslov; 'Benjamin Kaduk'; dots-
> > chairs@ietf.org; dots@ietf.org
> > Objet : RE: [Dots] Mirja's DISCUSS: Pending Point (AD Help Needed)
> > 
> > 
> > Yes, it is YANG limitation but not stop the protocol from giving a
> > recommendation for TCP.
> 
> [Med] The issue is that we need to be consistent: the parameter applies for all transport. We cannot set two defaults for it.  

Sure, but we also can't set two default transports.  We can set a default
value that matches the default (i.e., recommended) transport, and make a
note that when the one parameter is changed, it typically makes sense to
change the other as well.  That's what I thought Tiru was asking for.

-Ben

v2.23.0 | Report a Bug | By Email