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