Re: Benjamin Kaduk's Discuss on draft-ietf-bfd-yang-16: (with DISCUSS and COMMENT)
Jeffrey Haas <jhaas@pfrc.org> Wed, 11 July 2018 15:32 UTC
Return-Path: <jhaas@slice.pfrc.org>
X-Original-To: rtg-bfd@ietfa.amsl.com
Delivered-To: rtg-bfd@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31DB5130E34; Wed, 11 Jul 2018 08:32:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 09HJ5ok4U_tT; Wed, 11 Jul 2018 08:32:27 -0700 (PDT)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id C9C43130E2D; Wed, 11 Jul 2018 08:32:27 -0700 (PDT)
Received: by slice.pfrc.org (Postfix, from userid 1001) id 6F2851E28F; Wed, 11 Jul 2018 11:32:18 -0400 (EDT)
Date: Wed, 11 Jul 2018 11:32:18 -0400
From: Jeffrey Haas <jhaas@pfrc.org>
To: Benjamin Kaduk <kaduk@mit.edu>
Cc: Reshad Rahman <rrahman@cisco.com>, "Acee Lindem (acee)" <acee@cisco.com>, "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>, "draft-ietf-bfd-yang@ietf.org" <draft-ietf-bfd-yang@ietf.org>, The IESG <iesg@ietf.org>, "bfd-chairs@ietf.org" <bfd-chairs@ietf.org>
Subject: Re: Benjamin Kaduk's Discuss on draft-ietf-bfd-yang-16: (with DISCUSS and COMMENT)
Message-ID: <20180711153217.GO12853@pfrc.org>
References: <153064928232.4913.5177531623706237853.idtracker@ietfa.amsl.com> <69638E39-860F-4D2F-AE2B-3B0B0A7BA855@cisco.com> <20180704035647.GF60996@kduck.kaduk.org> <20180710234621.GD12853@pfrc.org> <DBDBAFD1-8280-4389-B7F9-08785FC01BF8@cisco.com> <650FCD2E-A555-447A-A7AA-87D67B4E2BDE@cisco.com> <D4C67FBF-10C0-4F22-B8C6-1D9DD9CFE7B0@cisco.com> <EB68C226-A9F7-4254-97D8-042FB6FB6DFF@cisco.com> <B14B0368-0795-4163-8A6D-A4D03B4568A1@pfrc.org> <20180711150238.GT59001@kduck.kaduk.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <20180711150238.GT59001@kduck.kaduk.org>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/fVuYV07TYRAkpirWIj0iBzuneYQ>
X-BeenThere: rtg-bfd@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <rtg-bfd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-bfd/>
List-Post: <mailto:rtg-bfd@ietf.org>
List-Help: <mailto:rtg-bfd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Jul 2018 15:32:30 -0000
Benjamin, On Wed, Jul 11, 2018 at 10:02:41AM -0500, Benjamin Kaduk wrote: > "may be overkill in some circumstances" sounds exactly like an RFC 2119 > SHOULD, does it not? Putting it slightly a different way, I am always wary of trying to embed too much operational and security wisdom in documents for the following reasons: - What's wise in one set of circumstances may not be in another. By being proscriptive, you may lead to implementations that lack necessary flexibility. - You're imposing a level of fate binding between mechanisms that may contravene desired behaviors from some operators that have split operational roles. [...] > To frame the same idea in a different fashion, we have this nice security > considerations boilerplate for YANG modules, talking about how the usual > access methods are NETCONF/RESTCONF, with MTI secure transport of ssh/TLS. > The scheme being described here is effectively providing a new access > mechanism (IGP) for a subset of the YANG module, This is perhaps my personal disconnect. Much of the point of providing a common configuration grouping for BFD for client protocols was to encapsulate, "I'm a client of BFD, here's my parameters". An implementation is free to use the "please use bfd with these parameters for my protocol" or perhaps ignore them. But in circumstances that an operator may wish to limit access to protocol BFD behavior, it has the existing ability in NACM to enforce its policy on those BFD nodes within the protocol tree. What I feel you're saying is we need to call special attention to these instantiations that may be imported by some module. What I'm confused about is why such an import is any more special than any other import from another module. -- Jeff
- Re: Benjamin Kaduk's Discuss on draft-ietf-bfd-ya… Reshad Rahman (rrahman)
- Benjamin Kaduk's Discuss on draft-ietf-bfd-yang-1… Benjamin Kaduk
- Re: Benjamin Kaduk's Discuss on draft-ietf-bfd-ya… Reshad Rahman (rrahman)
- Re: Benjamin Kaduk's Discuss on draft-ietf-bfd-ya… Benjamin Kaduk
- Re: Benjamin Kaduk's Discuss on draft-ietf-bfd-ya… Jeffrey Haas
- Re: Benjamin Kaduk's Discuss on draft-ietf-bfd-ya… Acee Lindem (acee)
- Re: Benjamin Kaduk's Discuss on draft-ietf-bfd-ya… Reshad Rahman (rrahman)
- Re: Benjamin Kaduk's Discuss on draft-ietf-bfd-ya… Acee Lindem (acee)
- Re: Benjamin Kaduk's Discuss on draft-ietf-bfd-ya… Reshad Rahman (rrahman)
- Re: Benjamin Kaduk's Discuss on draft-ietf-bfd-ya… Jeffrey Haas
- Re: Benjamin Kaduk's Discuss on draft-ietf-bfd-ya… Reshad Rahman (rrahman)
- Re: Benjamin Kaduk's Discuss on draft-ietf-bfd-ya… Benjamin Kaduk
- Re: Benjamin Kaduk's Discuss on draft-ietf-bfd-ya… Jeffrey Haas
- Re: Benjamin Kaduk's Discuss on draft-ietf-bfd-ya… Benjamin Kaduk
- Re: Benjamin Kaduk's Discuss on draft-ietf-bfd-ya… Reshad Rahman (rrahman)
- Re: Benjamin Kaduk's Discuss on draft-ietf-bfd-ya… Benjamin Kaduk
- Re: Benjamin Kaduk's Discuss on draft-ietf-bfd-ya… PFFC JHAAS
- Re: Benjamin Kaduk's Discuss on draft-ietf-bfd-ya… Reshad Rahman (rrahman)