Re: [babel] Robert Wilton's No Objection on draft-ietf-babel-information-model-11: (with COMMENT)

"STARK, BARBARA H" <bs7652@att.com> Fri, 06 November 2020 21:40 UTC

Return-Path: <bs7652@att.com>
X-Original-To: babel@ietfa.amsl.com
Delivered-To: babel@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35C773A0D64; Fri, 6 Nov 2020 13:40:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=att.onmicrosoft.com
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 KH88MYsgf5-z; Fri, 6 Nov 2020 13:40:39 -0800 (PST)
Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (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 268863A0D2C; Fri, 6 Nov 2020 13:40:39 -0800 (PST)
Received: from pps.filterd (m0049295.ppops.net [127.0.0.1]) by m0049295.ppops.net-00191d01. (8.16.0.43/8.16.0.43) with SMTP id 0A6LXvB9016222; Fri, 6 Nov 2020 16:40:37 -0500
Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0049295.ppops.net-00191d01. with ESMTP id 34n9epfh2p-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 06 Nov 2020 16:40:37 -0500
Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 0A6Lea5T005152; Fri, 6 Nov 2020 16:40:36 -0500
Received: from zlp27128.vci.att.com (zlp27128.vci.att.com [135.66.87.50]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 0A6LeUv1005047 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 6 Nov 2020 16:40:30 -0500
Received: from zlp27128.vci.att.com (zlp27128.vci.att.com [127.0.0.1]) by zlp27128.vci.att.com (Service) with ESMTP id ED18A4016B7E; Fri, 6 Nov 2020 21:40:29 +0000 (GMT)
Received: from MISOUT7MSGED1DA.ITServices.sbc.com (unknown [135.66.184.175]) by zlp27128.vci.att.com (Service) with ESMTPS id C949A4016B62; Fri, 6 Nov 2020 21:40:29 +0000 (GMT)
Received: from MISOUT7MSGEX2DB.ITServices.sbc.com (135.66.184.188) by MISOUT7MSGED1DA.ITServices.sbc.com (135.66.184.175) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2044.4; Fri, 6 Nov 2020 16:40:29 -0500
Received: from MISOUT7MSGETA01.tmg.ad.att.com (144.160.12.221) by MISOUT7MSGEX2DB.ITServices.sbc.com (135.66.184.188) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2044.4 via Frontend Transport; Fri, 6 Nov 2020 16:40:29 -0500
Received: from NAM10-DM6-obe.outbound.protection.outlook.com (104.47.58.107) by edgeso1.exch.att.com (144.160.12.221) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2044.4; Fri, 6 Nov 2020 16:40:27 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=O29BXL/+7zqfigb5VgVoYmij5obLGSormk/Q8egcrVygUdZu7RBzf9Bw5H/kXFWm8SZ38jo+uOhcxVFBDuL1+4RlK5m7Co8WEvuelCYpL7G4XIvkrIc6hVXr9VhoTgvPe/CS/jj4r7MjHCt0SvWr/IE2GjPwrJlyjgcSlasgvmtZiNYIG6o60AIanq2N//goeMoI3Hz+2RkrtMJ2WsBMJusyKfqHguDK2MvmLCqVRkkmbpT9m9s+tD9DJ5+Qd9Ju1xZRKDHqcUHr03hkzeztmREdWulf2lHYldcFFrJBw32Tm3SOSlyLK/QFP1Tmvjq/ZGwx9BsGNVlXlt6i1DNvWw==
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=OAX8MMRnsxx0hmA9iZa5L0eXhYbJiXBr27WMNnXBSiA=; b=CuKmY4FmHrB5CRaeSHNcCP3SunEEfz6VSiZeVrnObOC9s0rugGg+zZYn3j/XTWLuSk9i+OgA269pz8J9tbHOkS1Nsf7z2u6FzGoJ7em3Tx7QhZAr4qTs2wD3se2YIrbrP1b/otW5AAE7YRbdZWlpt/1b5U3N51mQbXgvdBkLFCawzIiJBmaS4CU9iKILoza01mQOESXOF6SEYcTZ5vdFad4f3hkTaW9t7HmyJwdQYFzI/7ZN2/pM6YxpkFJRODcB+rPesxMrxMJ73aYboW9H/7ob+UlwjFg7Mw2E/EdGUTXygpK/hbL5v1DajLpMHKoFGNMLNgaw3s1EzSm9g0q5jg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=att.com; dmarc=pass action=none header.from=att.com; dkim=pass header.d=att.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.onmicrosoft.com; s=selector2-att-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=OAX8MMRnsxx0hmA9iZa5L0eXhYbJiXBr27WMNnXBSiA=; b=ZA+yESxpi2+DxY35b/FeDRwBKyJNB8TW2XTARi0naGB8S8sJ2S0oE+vfsu2EyM0YONVxTEhW1e4Z/D3Igt4BGCcYEe/Ho9zdm6gd0RXFhGW6TE7MUpytMVqlkfSPWncGeOBVNSgtsV9JiGHkKmWrOYy/JLN0HhG92fTjo919nLs=
Received: from SN6PR02MB4512.namprd02.prod.outlook.com (2603:10b6:805:a4::13) by SN6PR02MB4080.namprd02.prod.outlook.com (2603:10b6:805:2c::25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3499.27; Fri, 6 Nov 2020 21:40:26 +0000
Received: from SN6PR02MB4512.namprd02.prod.outlook.com ([fe80::dc3c:5ad:4df8:f8af]) by SN6PR02MB4512.namprd02.prod.outlook.com ([fe80::dc3c:5ad:4df8:f8af%7]) with mapi id 15.20.3499.032; Fri, 6 Nov 2020 21:40:26 +0000
From: "STARK, BARBARA H" <bs7652@att.com>
To: "'Rob Wilton (rwilton)'" <rwilton@cisco.com>, "'Mahesh Jethanandani'" <mjethanandani@gmail.com>
CC: "'The IESG'" <iesg@ietf.org>, "'draft-ietf-babel-information-model@ietf.org'" <draft-ietf-babel-information-model@ietf.org>, "'babel-chairs@ietf.org'" <babel-chairs@ietf.org>, "'Babel at IETF'" <babel@ietf.org>, "'Donald Eastlake'" <d3e3e3@gmail.com>
Thread-Topic: Robert Wilton's No Objection on draft-ietf-babel-information-model-11: (with COMMENT)
Thread-Index: AQHWstJ8CLomYVKETkWvjHAQXHsDcqm4SaMAgAEr5gCAAh0jcA==
Date: Fri, 6 Nov 2020 21:40:25 +0000
Message-ID: <SN6PR02MB451223DF60D6318008E15F70C3ED0@SN6PR02MB4512.namprd02.prod.outlook.com>
References: <160451197790.28880.17597785068103610213@ietfa.amsl.com> <0CA8EA3A-4BB0-46EF-8FAC-D11B846852B4@gmail.com> <MN2PR11MB4366AAC6DB8686B0B58601ABB5EE0@MN2PR11MB4366.namprd11.prod.outlook.com>
In-Reply-To: <MN2PR11MB4366AAC6DB8686B0B58601ABB5EE0@MN2PR11MB4366.namprd11.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=none action=none header.from=att.com;
x-originating-ip: [144.160.96.113]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 69534c48-65df-4c5d-f967-08d8829c92ab
x-ms-traffictypediagnostic: SN6PR02MB4080:
x-microsoft-antispam-prvs: <SN6PR02MB4080FCD2B15F6549DDBCCA97C3ED0@SN6PR02MB4080.namprd02.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: VzFDk+plIKGQwWgDfB09rLLmt23u9OEgGZJFqYd/TBMuzyHOXepNSX7eSrHMcerZyyQrqLVLNYDmBJiKwND4w95rpNd7ZLSShZkLdsO6ReODhA72e3UjonhQFXSzrywdmOfxzarQwOEd9WBdvZLOT+Zek8wmx/52R/fNQInpSpI58Jx17S0wZUTHhJENDSLCyomqUn9l+gynws6yUZ6vTZCHlL2fozZlRT81VsWOHkGodKwEDcY+zbYa+N2AJFcTqwBI5CWSXor7jKR2rnCqX5d4mWAAzYS6/u06G4xI4iXSOJ3KCYwD6nXIKwtAcW7pHd5FtIQO7MvuO8zRDAGytwr0ZbCArM5DGjeBdK+5xHnuZpz/GudY/MthaDLWVlHuUkwNpZmmD/JETxIAvrvjOg==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SN6PR02MB4512.namprd02.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(136003)(39860400002)(346002)(376002)(396003)(4326008)(66446008)(66556008)(9686003)(66574015)(8676002)(54906003)(8936002)(82202003)(316002)(186003)(966005)(53546011)(5660300002)(6506007)(66946007)(83380400001)(55016002)(7696005)(66476007)(110136005)(2906002)(71200400001)(478600001)(52536014)(26005)(76116006)(86362001)(33656002)(64756008); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: n3UuOLgRZ7Dm0GaYr4zDEdNKOridUT0LHgGFzPlTvVgMrKwCKcuZQNVcGwvVLBDLGulXVeKupWcnNWS/s//GqNo2Lbnp77ZY+S4Sar5UDuB3Qpfks+qT5qK49/jPSbue1GEKYfxegXmZ34P0GNjPOcAlJ+1dFwOQUxHyQzQC/m7ItHbW8h8r7NlMcso9mIvoJhqHX/hAkP1H4jwir2VPvpKzz3WWxph1iVvN+Io6n7Vj2Bq3seDf53Ws4Ft1qN9lgvEXB/2xn2eOgpOhadoKX+yh+CBEZDuQVQb0FeDuNwct3ZdqLt2tsfO6Hj14m370yDiW5sP/SD7zdNPLy4hMN2l621gp8fzt45e0nWF0LFHiBpryN4BC8L3moTruujuOyFX2waUuFaUsvxixW9WYQMygif25cW5h81nfTNpW3fUfB0aMVJHt8vEesM0qBgU7WrgkafWHXgcoRPrPgTzTYBPmfEjcqK3/+KL1pRoQBBNXGnrvtSfRzX0QGE7Rl0qFgNmHnBXz+mHzlJBQzz2vEWWcakkLaS3HiibTKjIhsn+7HhxSSjqfz/k3N09ceomkPoslIUyEi4mmm2zJLvHE/Of8GUey8I7olSTRVC+IX42qNOBDBCdc47MYF57f0v1ZJCcOcwt29cZfYOWK7BZ8+g==
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: SN6PR02MB4512.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 69534c48-65df-4c5d-f967-08d8829c92ab
X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Nov 2020 21:40:25.8659 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: e741d71c-c6b6-47b0-803c-0f3b32b07556
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 9luXNsqKORby9YrTY1fTOH8K/pSXSrqrOwCid/QFUxqMhq+L5j2YI2UX7qgw4nqX
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR02MB4080
X-OriginatorOrg: att.com
X-TM-SNTS-SMTP: 28E031DB815847E60633B0AEC113BAE346EAF158D77F645B5573F174690893382
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.312, 18.0.737 definitions=2020-11-06_06:2020-11-05, 2020-11-06 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 mlxlogscore=999 phishscore=0 lowpriorityscore=0 adultscore=0 mlxscore=0 priorityscore=1501 impostorscore=0 suspectscore=0 spamscore=0 clxscore=1015 bulkscore=0 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2011060150
Archived-At: <https://mailarchive.ietf.org/arch/msg/babel/Ze2EtZEidcE7t2WMF2EqblBJN7I>
Subject: Re: [babel] Robert Wilton's No Objection on draft-ietf-babel-information-model-11: (with COMMENT)
X-BeenThere: babel@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "A list for discussion of the Babel Routing Protocol." <babel.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/babel>, <mailto:babel-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/babel/>
List-Post: <mailto:babel@ietf.org>
List-Help: <mailto:babel-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/babel>, <mailto:babel-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 06 Nov 2020 21:40:41 -0000

Hi Rob and Mahesh,

> Hi Mahesh,
> 
> Making it a normative reference only means draft-ietf-babel-information-
> model contains some text (i.e. the text about datastores) that can only be
> properly understood by reading some of RFC 8342.
> 
> Making RFC 8342 an informative reference would mean that there isn't any
> text in draft-ietf-babel-information-model that needs RFC 8342 to properly
> understand it, but that it contains information that may be
> interesting/helpful to the reader.  If you want RFC 8342 to only be an
> informative reference (or potentially not be a reference at all), then I think
> that this document would either need to not talk about datastores at all, or
> provide more description about the concepts that it is ascribing to the
> 'enable' properties in the information model.

It seems that the terms causing a problem are "operational datastore" and "running
datastore"? I looked around on the Internet to see what I could find about these terms
(because I know the concepts have been around since long before RFC 8342).
Here is a link to a definition of "Operational Datastore" from 2013, that makes no
mention of YANG: 
https://www.techopedia.com/definition/1226/operational-data-store-ods
and the more generic "Datastore" definition (also from 2013):
https://www.techopedia.com/definition/23343/datastore

"Running datastore" does seem to be more specific to YANG. My brief searches
haven't found that term outside YANG (yet). The first use of it in YANG I find
is RFC6241, where both "running datastore" and "operational datastore" are used in
Appendix C (YANG Module for NETCONF Protocol Operations) in node descriptions.
For example:
anyxml config {
              description
                "Inline Config content: <config> element.  Represents
                 an entire configuration datastore, not
                 a subset of the running datastore.";

Note the lower case usage. Interestingly,
"operational datastore" does not appear in this RFC. Instead, it includes the term
"configuration datastore". In terminology, "configuration datastore" and "running
configuration datastore" are both there (lowercase), but they aren't described as
being concepts unique to YANG or NETCONF. They appear more to be defined as
terms of art.

I've never read RFC 8342, and had thought Mahesh was including them as well-
understood terms of art (I certainly immediately understood what concepts he
was referring to when he introduced the words, in spite of my lack of familiarity
with YANG or NETCONF). I note that babel-information-model uses the terms
in lowercase. 

I don't think a reference to RFC 8342 is appropriate to indicate where these
terms of art come from. They clearly predate RFC 8342 and NETCONF. There is no 
terminology section in this draft. I'm not keen on adding a terminology 
section to the draft just for these 2 rather well-understood terms of art.
But I would do that (and maybe find a few other terms of art to include
so they don't seem out of place), if that were a suitable compromise.
Barbara

> Thanks,
> Rob
> 
> 
> From: Mahesh Jethanandani <mjethanandani@gmail.com>
> Sent: 04 November 2020 18:24
> To: Rob Wilton (rwilton) <rwilton@cisco.com>
> Cc: The IESG <iesg@ietf.org>rg>; draft-ietf-babel-information-model@ietf.org;
> babel-chairs@ietf.org; Babel at IETF <babel@ietf.org>rg>; Donald Eastlake
> <d3e3e3@gmail.com>
> Subject: Re: Robert Wilton's No Objection on draft-ietf-babel-information-
> model-11: (with COMMENT)
> 
> Hi Rob,
> 
> 
> On Nov 4, 2020, at 9:46 AM, Robert Wilton via Datatracker
> <noreply@ietf.org<mailto:noreply@ietf.org>> wrote:
> 
> Robert Wilton has entered the following ballot position for
> draft-ietf-babel-information-model-11: No Objection
> 
> 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://urldefense.com/v3/__https://www.ietf.org/iesg/statement/discuss
> -
> criteria.html__;!!BhdT!zLVd1eLtHrXhlZziRBtQT2MAdZ6mm3waQWNOuByJpI
> 16Bb-pj5tYrjseBJzqy6yN$
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-
> babel-information-
> model/__;!!BhdT!zLVd1eLtHrXhlZziRBtQT2MAdZ6mm3waQWNOuByJpI16Bb
> -pj5tYrjseBOB6qxxt$
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> Thank you for this document.
> 
> I support Ben's discuss regarding reusing the terminology from NMDA.  I
> think
> that the document should have a normative reference to RFC 8342, and
> probably
> explain that in some places the information model is using the same concepts
> of
> configuration and operational data separation described in NMDA.
> 
> While I am not against a reference to the terminology from NMDA in the
> information model, (BTW, I am ignorant on what it means for an
> informational draft to have a normative reference), I am not sure whether it
> needs to normative or whether it can be informative. By making it normative,
> are we making this information model more YANG specific? Could the
> reference to NMDA be normative in the YANG model of this information
> model  (which the YANG model already does)?
> 
> Thanks.
> 
> 
> 
> I also support Alvaro's question about whether the source-routing
> component
> should be included.
> 
> This is just a comment, and I'm not proposing that you change tack, but I
> have
> to confess that I question how beneficial publishing an Information Model
> really is.  I understand that the goal here is to be able to publish two
> different data models,  one based on YANG and other based on BBF's [TR-
> 181]