Re: [Lsr] Benjamin Kaduk's Discuss on draft-ietf-ospf-yang-26: (with DISCUSS and COMMENT)
Benjamin Kaduk <kaduk@mit.edu> Mon, 26 August 2019 15:09 UTC
Return-Path: <kaduk@mit.edu>
X-Original-To: lsr@ietfa.amsl.com
Delivered-To: lsr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55F9D12001B; Mon, 26 Aug 2019 08:09:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 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] 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 4MeUQ1zB4GbA; Mon, 26 Aug 2019 08:09:55 -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 98AB2120071; Mon, 26 Aug 2019 08:09:55 -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 x7QF9lk5022522 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 26 Aug 2019 11:09:50 -0400
Date: Mon, 26 Aug 2019 10:09:47 -0500
From: Benjamin Kaduk <kaduk@mit.edu>
To: "Acee Lindem (acee)" <acee@cisco.com>
Cc: The IESG <iesg@ietf.org>, "draft-ietf-ospf-yang@ietf.org" <draft-ietf-ospf-yang@ietf.org>, Stephane Litkowski <stephane.litkowski@orange.com>, "aretana.ietf@gmail.com" <aretana.ietf@gmail.com>, "lsr-chairs@ietf.org" <lsr-chairs@ietf.org>, "lsr@ietf.org" <lsr@ietf.org>
Message-ID: <20190826150946.GG84368@kduck.mit.edu>
References: <156645274645.25722.10228898924938704759.idtracker@ietfa.amsl.com> <DCC2B37B-7E04-4D6B-8C77-C48650CDA4B9@cisco.com> <20190823014342.GY60855@kduck.mit.edu> <549A7648-4E8E-421F-91E7-B704D1F31B4A@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <549A7648-4E8E-421F-91E7-B704D1F31B4A@cisco.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/5RXmCT7Ca3VDVRw9v8dMvC0Qbr4>
Subject: Re: [Lsr] Benjamin Kaduk's Discuss on draft-ietf-ospf-yang-26: (with DISCUSS and COMMENT)
X-BeenThere: lsr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Link State Routing Working Group <lsr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lsr>, <mailto:lsr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lsr/>
List-Post: <mailto:lsr@ietf.org>
List-Help: <mailto:lsr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lsr>, <mailto:lsr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 26 Aug 2019 15:09:59 -0000
Hi Acee, On Mon, Aug 26, 2019 at 03:02:18PM +0000, Acee Lindem (acee) wrote: > Hi Ben, > > On 8/22/19, 9:44 PM, "Benjamin Kaduk" <kaduk@mit.edu> wrote: > > On Fri, Aug 23, 2019 at 12:30:27AM +0000, Acee Lindem (acee) wrote: > > Hi Ben, > > > > On 8/22/19, 1:46 AM, "Benjamin Kaduk via Datatracker" <noreply@ietf.org> wrote: > > > > Benjamin Kaduk has entered the following ballot position for > > draft-ietf-ospf-yang-26: Discuss > > > > When responding, please keep the subject line intact and reply to all > > email addresses included in the To and CC lines. (Feel free to cut this > > introductory paragraph, however.) > > > > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-ospf-yang/ > > > > > > > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > > > > (1) Can we check whether it's okay to use the yang "string" type for raw > > cryptographic keys (e.g., ospfv2-key, ospfv3-key)? My understanding was > > that yang strings were limited to human-readable, but that the crypto > > keys could be raw binary values. > > > > It does only include human-readable keys. Here is the RFC 7950 YANG ABNF definition. > > > > > > ;; any Unicode or ISO/IEC 10646 character, including tab, carriage > > ;; return, and line feed but excluding the other C0 control > > ;; characters, the surrogate blocks, and the noncharacters > > yang-char = %x09 / %x0A / %x0D / %x20-D7FF / > > ; exclude surrogate blocks %xD800-DFFF > > %xE000-FDCF / ; exclude noncharacters %xFDD0-FDEF > > %xFDF0-FFFD / ; exclude noncharacters %xFFFE-FFFF > > %x10000-1FFFD / ; exclude noncharacters %x1FFFE-1FFFF > > %x20000-2FFFD / ; exclude noncharacters %x2FFFE-2FFFF > > %x30000-3FFFD / ; exclude noncharacters %x3FFFE-3FFFF > > %x40000-4FFFD / ; exclude noncharacters %x4FFFE-4FFFF > > %x50000-5FFFD / ; exclude noncharacters %x5FFFE-5FFFF > > %x60000-6FFFD / ; exclude noncharacters %x6FFFE-6FFFF > > %x70000-7FFFD / ; exclude noncharacters %x7FFFE-7FFFF > > %x80000-8FFFD / ; exclude noncharacters %x8FFFE-8FFFF > > %x90000-9FFFD / ; exclude noncharacters %x9FFFE-9FFFF > > %xA0000-AFFFD / ; exclude noncharacters %xAFFFE-AFFFF > > %xB0000-BFFFD / ; exclude noncharacters %xBFFFE-BFFFF > > %xC0000-CFFFD / ; exclude noncharacters %xCFFFE-CFFFF > > %xD0000-DFFFD / ; exclude noncharacters %xDFFFE-DFFFF > > %xE0000-EFFFD / ; exclude noncharacters %xEFFFE-EFFFF > > %xF0000-FFFFD / ; exclude noncharacters %xFFFFE-FFFFF > > %x100000-10FFFD ; exclude noncharacters %x10FFFE-10FFFF > > > > However, this is the intent as this is support for implementations that don't support key-chains (RFC 8177). The "Security Considerations" recommend key chains. We'll add the hexadecimal specification as another reason for preferring key-chains. > > Okay, that's enough to resolve the discuss. > > > > > > > (2) Do we need to say anything about how to indicate when there are > > discontinuities for the various "counter" types? > > > > I've never heard any mention of counter discontinuities in the context of OSPF control plane counters. > > Oh, I think this is more of a YANG thing than an OSPF thing (and I'm hardly > a YANG expert). That is, the yang:counter32 and similar types are > constrained to only ever increment ("count events that happened", roughly), > as opposed to a gauge32 that measures the current level of something and > can go up or down, or a generic uint32. Of course, in the real world > software crashes or restarts, so a YANG consumer might in practice see the > value of a "counter" type go backwards, even though that's forbidden by the > spec. In some cases (and I don't know exactly when it becomes most > relevant), the YANG model includes a "discontinuity time" (e.g., router > restart time) to indicate when the counters were last reset to zero, in > order to give consumers a sense for how long it took the counter to get > that big. It's entirely possible that this doesn't make sense for the OSPF > counters, and if you tell me that I'm happy to clear. > > Searching for "RFC YANG discontinuity" brings up several representative > results, such as RFC 8343, which says: > > leaf discontinuity-time { > type yang:date-and-time; > mandatory true; > description > "The time on the most recent occasion at which any one or > more of this interface's counters suffered a > discontinuity. If no such discontinuities have occurred > since the last re-initialization of the local management > subsystem, then this node contains the time the local > management subsystem re-initialized itself."; > > I did some research and the OSPF MIB (RFC 4750) did have a discontinuity time (ospfDiscontinuityTime). I added discontinuity-time for each applicable object in the -28 version. Thank you for doing the research -- I had forgotten to even check for an analogous MIB! The updates in the -28 look good, and I've cleared in the datatracker. -Ben
- [Lsr] Benjamin Kaduk's Discuss on draft-ietf-ospf… Benjamin Kaduk via Datatracker
- Re: [Lsr] Benjamin Kaduk's Discuss on draft-ietf-… Acee Lindem (acee)
- Re: [Lsr] Benjamin Kaduk's Discuss on draft-ietf-… Benjamin Kaduk
- Re: [Lsr] Benjamin Kaduk's Discuss on draft-ietf-… Acee Lindem (acee)
- Re: [Lsr] Benjamin Kaduk's Discuss on draft-ietf-… Benjamin Kaduk
- Re: [Lsr] Benjamin Kaduk's Discuss on draft-ietf-… Acee Lindem (acee)
- Re: [Lsr] Benjamin Kaduk's Discuss on draft-ietf-… Ladislav Lhotka