Re: [Lsr] Benjamin Kaduk's Discuss on draft-ietf-ospf-yang-26: (with DISCUSS and COMMENT)

"Acee Lindem (acee)" <acee@cisco.com> Mon, 26 August 2019 21:54 UTC

Return-Path: <acee@cisco.com>
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 54FED120FB0; Mon, 26 Aug 2019 14:54:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level:
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=ADEJdshB; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=OB5LVrdF
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 XSEV3GSByMV3; Mon, 26 Aug 2019 14:54:10 -0700 (PDT)
Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABE9A12011F; Mon, 26 Aug 2019 14:54:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9710; q=dns/txt; s=iport; t=1566856449; x=1568066049; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=hnpkRVaKUoAgrLQ0bDr9oiVtXFGw3CreSKVw5uyIQ40=; b=ADEJdshBiP8Fw3089jSNtYwWGlKx2mhLsYx1til/qfry0cD47GP4ffX0 PrP79jrrowy53kx4vZ9gYEfxYsCI4a4lEr4aqABiGw+JQ/hEuTSbZi6B2 HGci2U5sDoikjtNxu/e/DEPzbel6n7NJAL/7VyBVZJjdkV8t0IdO7rSr5 Q=;
IronPort-PHdr: =?us-ascii?q?9a23=3AZ31vVhLgz3NCo30idtmcpTVXNCE6p7X5OBIU4Z?= =?us-ascii?q?M7irVIN76u5InmIFeCuKd2lFGcW4Ld5roEkOfQv636EU04qZea+DFKa5lQT1?= =?us-ascii?q?kAgMQSkRYnBZuMAkD2BPXrdCc9Ws9FUQwt8g=3D=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CqAADxU2Rd/4ENJK1kDgwBAQEBAQI?= =?us-ascii?q?BAQEBBwIBAQEBgWeBRVADbVYgBAsqhCGDRwOKcYJcl2iBQoEQA1QJAQEBDAE?= =?us-ascii?q?BGAsKAgEBgUuCdAIXglAjOBMCCgEBBAEBAQIBBgRthS0MhUsBAQEDAQEQERE?= =?us-ascii?q?MAQElBAMLAQ8CAQgYAgImAgICJQsVEAIEDgUigwABgWoDHQECDJ9GAoE4iGF?= =?us-ascii?q?zgTKCewEBBYFGQYJ/GIIWAwaBDCiKL4FDGIF/gREnH4JMPoJhAQEBAgGBKgE?= =?us-ascii?q?LBwEIgyIygiaMRIInMpxRCQKCHoZqhQGEYoN2G4IyhzCObZVTkDsCBAIEBQI?= =?us-ascii?q?OAQEFgWchZ1gRCHAVOyoBgkGCQgwXFYM6hRSFBDtyAYEoi1kPF4IsAQE?=
X-IronPort-AV: E=Sophos;i="5.64,433,1559520000"; d="scan'208";a="314840747"
Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 26 Aug 2019 21:54:08 +0000
Received: from XCH-ALN-016.cisco.com (xch-aln-016.cisco.com [173.36.7.26]) by alln-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id x7QLs81E007001 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 26 Aug 2019 21:54:08 GMT
Received: from xhs-aln-001.cisco.com (173.37.135.118) by XCH-ALN-016.cisco.com (173.36.7.26) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 26 Aug 2019 16:54:08 -0500
Received: from xhs-aln-003.cisco.com (173.37.135.120) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 26 Aug 2019 16:54:07 -0500
Received: from NAM03-DM3-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Mon, 26 Aug 2019 16:54:07 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=LPirqjtzd1zz6Snf3UBPX8rrXCyTvijRShXmvK6fnh9Dm4v5mR/Qr8PHUn2Zehgb9+s7GGNvhEtIdMsWy075o0KGNaRTpw/sp4cUVUvmrrJl4dGAxgkNa8bfVGkb3tOfGIaMTwiDOGjUiVEjC4CsgS6Ev4gQYjdKnNCzgv6pbzoeSh5AGs/I6RCirXV/oYxCpyhyT0SimWoCITcfpPQ2s+bF4DAscAOT5wEZzHa4rdNNRWqoLu7uB5Cb/PQHVrZfDlrjjmqm3k9TFib0FPZ3YYLfp7RRBVLGlKuQWxaQfoK4FAGerxJ51WgQdFzDpwA56Hus8YrIijT9Ne9Xf0ht1w==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=hnpkRVaKUoAgrLQ0bDr9oiVtXFGw3CreSKVw5uyIQ40=; b=eVT2oCfMnXUGU+o0o0rSWuxb1TDgNAOayhKRSTKl9+9M0jMqCJ1h9zrweK0fpHnFEaPMl7oNqTUp5c42xSJItZYZHeyKkNpsk/Hdwdjoonf+y04mxkNyF4lSjSmw3lNnxmjrzzG9DVKx3Pd285bgvgmp9xy1nklE24PJIxoZ35Uo0usxFG04wO7Imqk1FRsESLL3NTzkYz+TUJDuli2k5rD40kAul9vIA+zY7Vju03K+jXDHdOzXyEz/a/01hqR4Tfuv0+tUNqjZ/IBbn7OjA1TwEIsR8CB7LiVR7tnJzoBzV7Mvwa4b+W/sYRiMD7tAlicVhhC7CUyWbWY2YWMS/w==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=hnpkRVaKUoAgrLQ0bDr9oiVtXFGw3CreSKVw5uyIQ40=; b=OB5LVrdFUAwgCLXWBr0TDbFoFX/hrivlmRoCvwCLQDJUbQ3Pnj1KSo3wqNFHbFCll9H71fXjTC5zxcT+0Xm8tCUqz4QSq86z9739X76KyY9Dl/OFdIaokAlGzw79hrxZqgEXgwnf+LYUJJ1TSHri4t65B/lcR3rh7wompuJF1IM=
Received: from MN2PR11MB4221.namprd11.prod.outlook.com (52.135.38.14) by MN2PR11MB4429.namprd11.prod.outlook.com (52.135.37.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2199.21; Mon, 26 Aug 2019 21:54:06 +0000
Received: from MN2PR11MB4221.namprd11.prod.outlook.com ([fe80::cdc1:a2cf:eb3:a420]) by MN2PR11MB4221.namprd11.prod.outlook.com ([fe80::cdc1:a2cf:eb3:a420%6]) with mapi id 15.20.2199.021; Mon, 26 Aug 2019 21:54:06 +0000
From: "Acee Lindem (acee)" <acee@cisco.com>
To: Benjamin Kaduk <kaduk@mit.edu>
CC: Stephane Litkowski <stephane.litkowski@orange.com>, "aretana.ietf@gmail.com" <aretana.ietf@gmail.com>, "lsr-chairs@ietf.org" <lsr-chairs@ietf.org>, "draft-ietf-ospf-yang@ietf.org" <draft-ietf-ospf-yang@ietf.org>, The IESG <iesg@ietf.org>, "lsr@ietf.org" <lsr@ietf.org>
Thread-Topic: [Lsr] Benjamin Kaduk's Discuss on draft-ietf-ospf-yang-26: (with DISCUSS and COMMENT)
Thread-Index: AQHVWKzlv2qdUEtg30mdXATo61DUU6cHn4UAgABXnACABVL3gIAARSeAgAAt54A=
Date: Mon, 26 Aug 2019 21:54:06 +0000
Message-ID: <DCB578EA-F436-40A7-898E-CA5736C27458@cisco.com>
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> <20190826150946.GG84368@kduck.mit.edu>
In-Reply-To: <20190826150946.GG84368@kduck.mit.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=acee@cisco.com;
x-originating-ip: [2001:420:c0c4:1003::119]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: a8b57bc7-6863-4b28-137e-08d72a6feb01
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600166)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:MN2PR11MB4429;
x-ms-traffictypediagnostic: MN2PR11MB4429:
x-ms-exchange-purlcount: 3
x-microsoft-antispam-prvs: <MN2PR11MB442915BFD87F3CC31442292EC2A10@MN2PR11MB4429.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 01415BB535
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(346002)(366004)(376002)(396003)(39860400002)(189003)(199004)(305945005)(6306002)(76116006)(66476007)(14454004)(66946007)(66556008)(66446008)(76176011)(54906003)(6916009)(316002)(33656002)(7736002)(229853002)(64756008)(2906002)(99286004)(66574012)(25786009)(6506007)(5660300002)(476003)(2616005)(11346002)(486006)(81166006)(8676002)(81156014)(86362001)(8936002)(446003)(36756003)(186003)(6116002)(102836004)(53546011)(14444005)(71190400001)(6246003)(46003)(53936002)(478600001)(71200400001)(966005)(6436002)(4326008)(6486002)(6512007)(256004)(2171002); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB4429; H:MN2PR11MB4221.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: CEFvg1JB/Rv80K7BhK543TAtPOkXvLhUrOnBnZWkKMlOXCKdZydcDqcdTeaaDbAaTeb7hRryegTw2+VCmITuUxJdxk8oDYb2vDMtDYfwJtdFwc0QJpR38JwRhyyIIt4WcpudVpr138eorJ1cyN+mmpEeV5H3BMsQOfHALSmguPcpgP1eqMvavGzti9ni+7BF4ws192nkcaImMk5BZFeAwRFGX+D8KvBevjVS8RFKpBbaSOA4GqpK/vB6qNsmsO3F7LMSxBSYDGlqqVD0R7yG4VT0X6YzS1mxWBkRGQTLTEhgVMSviVlLROyacEbJMvnsZsk0zhiJSoKjDksJLDyVpeQOTyhlUaz1eRMKmbxbbRPMzy359J2k8oWFx+z6tp087ftFJA4bOZTodT0xFXUUtRwzsAPi6N/C2JFxQlWkkoo=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-ID: <B743D9313DA7864FAD85872AEF1C01BE@namprd11.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: a8b57bc7-6863-4b28-137e-08d72a6feb01
X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Aug 2019 21:54:06.4119 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 7tKFUvP6FFaDjfYmQ1xS5pc1GpPiYuTOv/ftXadHnOiv56UFOWgesc1SdXWLRVSj
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4429
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.26, xch-aln-016.cisco.com
X-Outbound-Node: alln-core-9.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/TxApcm3Ggv70wz1nvBt2GUIpqZw>
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 21:54:18 -0000

Hi Ben, 

´╗┐On 8/26/19, 11:11 AM, "Lsr on behalf of Benjamin Kaduk" <lsr-bounces@ietf.org on behalf of kaduk@mit.edu>; wrote:

    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.

Thanks much for the review - especially the detailed review of the YANG model.
Acee
    
    -Ben
    
    _______________________________________________
    Lsr mailing list
    Lsr@ietf.org
    https://www.ietf.org/mailman/listinfo/lsr